How many Garibaldi's

So, how many Garibaldi's constitute one of your five a day?

I ask, because I've been continuing to experiment with biscuits and sweets whilst I code... Garibaldi's are not my favourite biscuit, but they're one of the few, alongside fig rolls & fruit shortcake, with a promise of some actual roughage in them...

Also, they come in those long slices, which scores marking the slice into 5 biscuits.. Do you eat the whole slice, or just a few biscuits?

The multiboxer has also had new work, the filtering works, we can transmit strings, it will auto logon... Quite neat watching 39 clients open, move and then log into their respective games.  Next is a hot-spot mouse clicker, to let us select a window remotely and click on it, so we can potentially accept quests on all clients together...

Why I don't like Lambda's (C++)

Why I don't like Lambda's (C++)

I think I'm going to be in the minority of programmers when I say that I don't like Lambda's, in case  you don't know, a Lambda is a piece of code you an run inline, so you can create it and run it where you're working... like this:

#include <iostream>

int main ()

{

int sum10 = []

{

int i = 0;

for (int k = 0; k < 10; ++k)

{

i += k;

}

return i;

}();

}

When the code here is compiled & run, the value entered into "sum10" is the result of the function which follows, traditionally we'd write this code like this:

#include <iostream>

int Sum10Function ();

int main ()

{

int sum10 = Sum10Function();

}

int Sum10Function ()

{

int i = 0; 

for (int l = 0; k < 10; ++k)

{

i += k;

}

return i;

}

You can see this "Sum10Function" is actually a function, it has a declaration and a definition.  And this is how I'd always prefer to do work with functions, I do not like Lambda's because they ignore the greatest power of functions like "Sum10Function".

And that power is having a known location, a location you can find and a location which one can easily find all references to, you know if you have a problem in the function that you have one body to find and you can find it easily.  Finding a Lambda, written inline, in a mass of source is not a boon, it is in fact a major headache.

Other authors on the topic, such as "Alex Allain" (http://www.cprogramming.com/c++11/c++11-lambda-closures.html) actually have the balls to intimate that the fact you can write the function inline like the lambda, without having to stop and go create a prototype and a body declaration is a strength, but he; like many others; totally ignores the elephant in the room and that is the maintainability of code.

Alex's other examples on that page also start to use function pointer or functor examples, the first "AddressBook" class example he gives is taking a type, and yes we can assign a lambda to a type "auto"... but we can also assign a function pointer to an "auto", so there's no difference in using a function pointer or using a lambda in that example, except the Lambda falls foul of my point, it's harder to find and manage the source for the function.

The article linked there is also one of the major references if one googles for Lambda's in C++.  And it has code examples, which work, but which he describes as "pretty good looking", but which I see as horrible... here's the examples, cleaned up in the same program:

#include <iostream>

#include <vector>

#include <algorithm>

int main()

{

using namespace std;

vector<int> v;

v.push_back(1);

v.push_back(2);

//...

for (auto itr = v.begin(), end = v.end(); itr != end; itr++)

{

cout << *itr << endl;

}

vector<int> vw;

vw.push_back(1);

vw.push_back(2);

//...

for_each(vw.begin(), vw.end(), [](int val)

{

cout << val << endl;

});

return 1;

}

They both do the same thing, they output the vector, but I don't think the second code looks better, I in fact think both examples need cleaning up, because to my eye they're miss leading, but my argument about the maintainability of Lambda's aside the second example does hint at the only use for them.  It hints that they can take the loop variable "val" as an input from the left, i.e. from the iteration over the vector in the "for_each" loop, rather than need to declare that iterator as in the first loop "auto itr = v.begin()"...

But I would still argue that this ease of throwing the code in there, leads to hard to maintain code, I think the first example cleaned up would leave a much more wholesome and maintainable code base...

#include <iostream>

#include <vector>

int main()

{

using namespace std;

vector<int> v = { 1, 2 };

for (auto itr = v.begin(); itr != v.end; ++itr)

{

cout << (*itr) << endl;

}

}

And there is my preferred implementation of that example, I find it simpler and easier to understand, and as you can see I'm using the C++11 declaration of the vector contents to ease understanding, so I'm not throwing an anti C++11 rant here, far from it, I've looked at Lambda's in Python and C# as well as here in C++ and I really don't like the syntax maintenance questions they bring up.

Sometimes they look and can behave very powerfully, but even with the for_each example above, I'd still much prefer this:

#include <iostream>

#include <vector>

#include <algorithm>

void Output (int p_Value)

{

std::cout << p_Value << std::endl;

}

int main ()

{

std::vector<int> v = { 1, 2 };

for_each (v.begin(), v.end(), Output);

}

I can see the "for_each" I can see it calls Output with each iteration, that code clearly has a semi-colon, and I can go find "Output" very easily.  I find this code is much cleaner and simpler to follow.

C++ (Passing by Reference) Programmer Insecurity

Sometimes even the smartest, and I mean proper mind blowing good, programmers can have an off day... And I just ran into one.  Now, let me just say I consider myself a good C++ programmer, and an excellent Pascal programmer, I prefer C++ however and am taking every chance I get to use it, and use it cross platform.

Now, the chap I'm talking about, is a bit of a mega brain, he is really good, but he's just had a massive problem on his hands, and I don't think he liked my input...

First of all, he was working with "int", on a 32bit machine... But he was using this "int" as an unsigned value... So why not use "unsigned int"... apparently, he is having the kind of day where he doesn't want to type "unsigned " everywhere, so I suggested, replace "int" with "uint" and do "typedef unsigned int uint;" the silence was palpable...

He did it, and his code started to work, but it seemed he really wanted to just continue having an off day, rather then have me intereject with a solution...

Secondly, when he was done, he was getting a lot of memory used, he reckoned his code was fast and not creating copies... "int ValueReturn (int _lhs, int _rhs)".... A second suggestion, which I gave him via another member of staff "void ValueReturn (const uint& _lhs, const uint& _rhs, uint& _retVal)" to cut down the number of parameter copies and return copies he makes also went down like a tonne of bricks, he's stormed off, moaning that "that lot are a bunch of know it alls"

I can relate to his frustration, he's had a major problem, and we've effectively solved it for him in a few seconds, with what could be assumed to be obscure pieces of C++ code, but these practices of passing by reference, and even constant reference, and if you want to avoid creating more memory returning a reference to an [in/out] parameter is all normal fair.  Scott Meyer points this out a lot in his books.

I think I grew out of this tantrum "my code is right, the system is wrong" attitude about three years ago, it feels longer, but I know it takes a long time for a programmer to be comfortable enough with their ability to sit back and say "yeah, I got that wrong" and fix it, rather than think admitting fault lowers their value to everyone.  I certainly know from experience that those programmers who sit on their pedestal and are never challenged about shoddy code they do (even code which gets the job at hand done) will never progress and improve.

Anyway, something funny...

Back to Work & Multiboxing Plans

It's a back to work kind of day, and oh boy have I got a lot on at work, but enough of that... Something is bugging me, and it's this damn sponge rubbish keyboard.

After using my lovely Cherry Mechanical keyboard at home all week, and actually getting code done (see the multiboxer project on prior posts) it is a real shock to the fingers to come back to this horrid rubber dome equipped monster.

It's a bod standard Dell keyboard, the keys are horrible, they don't depress nicely, when they bottom out they just stop dead and they wobble nearly all the time, the whole experience is only saved by the fact that my office desk here is brilliant and I've had the desk over 10 years, so I'm very used to it.  But the keyboard, argh.

Now, I'm in an open office space so mechanical keyboards would not go down well at all, though I'm about to go work for an adjunct company of ours, where I hear well they have mechanical keyboards, we'll see.

How's the multiboxer?... Well, I'm going to be working tonight on a filter, this is different key mappings shifted into and out of on a key press... So you could for example have a set of keys you ONLY want to sent to game client 1 and 3 (the healers) you press the toggle... "Shift" perhaps... and it shifts into that set of mappings.... the healers do their thing, let go of shift and you're back sending to clients 2 and 4 the ranged DPS...

I may spend my lunch break reading up on other multiboxers, I've seen one other multiboxer which embeds the game clients into its windows, so you can size and resize them within a single GUI... I think that's very intrusive on the client, and the game might detect it's parent is not the desktop window but some other user created window and call that a hack/exploit.  So I'm sticking with just letting the game clients open, then using "SetWindowPos" to put them into a known x, y, width & height.

Addendum... Does a first day back at work get any worse, when all your development machines start saying this to you....

Damn you, Damn you all to Hell!

Multiboxing in World of Warcraft

I am writing a multiboxer, if you are interested, read the posts from all this week.

Donate using the PayPal links for exclusive early access, and discounts on the final software!

The project has tonight reaches a new level of performance and stability, literally rolling my four level 1 mages around with the paladin they've been stable in movement in and out of Stormwind and through Goldshire, they've taken on (and won) at level 1 level 9 mobs (the highest available) and have even started to make levels - even without being in a group - I can let the mages pull and they seem to take it in turns being the one to either hit first or get the first key stroke.

If I had full accounts I could of course just group them and everyone would share the rained down XP, and believe me it does rain down on you... playing solo you get about 120XP a mob when you start, so share that between 5 and you're getting only about 20-30XP... BUT... You kill 5-6x more mobs!

So what has this all got to do with multiboxing in general?  Well, multboxing in WoW is nothing new to me, I did it originally with a C# written key sender, but it was very primitive in comparison with this sender, and it was during the good old Vanilla days, so there were fewer group combinations you could use it for.

Now, I first became aware of multiboxing in 2004 when Southshore/Tarenmill world PVP was the only PVP, and this was on Thunderhorn EU server, which is a PVE server... Some knuckle head actually attacked southshore... and in Ironforge the commons between the bank and AH suddenly became a wash of people screaming to head North and defend the borders.  So it was about 65 various level (and PVP disabled) Alliance rattled into Southshore to see what was going on.  What met us was a level 60 undead warlock with four identically geared level 60 undead mages, and they moved in one fluid motion and owned any lone alliance who went PVP enabled to take them on.

They moved together, right with one another, they were the first Multibox I ever saw, and they started the first ever World PVP I saw, as more and more alliances then whole allliance level 60 groups came up and went PVP active and the war flowed.  The multiboxer disappeared soon, but I'd seen him and saw the power.

WSG was the first major location I saw PVP multiboxing take off, but vanilla PVP queues were hugely long on Thunderhorn, and the realm was PVE.  And I had a good guild around me working tier 0/1 gear, so just enjoyed the game.

Later when the guild had gone, when the groups became shit and when Burning Crusade gave us new instances, then my mind cast back to Multiboxing, and I wanted to do it to cover all the PVE content I'd no longer get to play because BC had totally devalued it.  I never ever got to play Nax properly... So I set about writing a key sending program in C# to run my own small group of level 70's through the content, I figured I could... Sure enough I could use my hunter, and a second account with a priest to run most of the content.

But I lost interest in the game and as wrath came along I just PVP'd more and more so lapsed the account and multiboxer.

It was only this year I realised I'd missed out on a big band wagon, I realised people were selling their Multiboxing set up, and that new rigs (PC's) could run multiple copies of the WoW client, so I could run group raids on my own single machine?... And then multiple groups of clients over the LAN!... WOW for WoW!

This project was then born, it soon was up to the old level, but its now oh so much more.  So much smoother, and with so much potential.  I've looked at, but not bought other multiboxers out there, because... Well I don't trust them, a multiboxer suite basically monitors your key strokes and transmits them around, what's to stop that strange multiboxer from transmitting my username and password as I type it in?.. NOTHING... Plus I'm a software engineer, why buy when I can write.

Features complete:

• Launch multiple local clients
• Use/save window positions for clients
• Automatic login to accounts
• Launch different games (WOW & RoM so far)
• Configure source (input) keys to map to different receiving (output) key
• Network (WAN & LAN) transmit of key strokes on a 1-to-1 pattern (1-to-many to come)
• IPv4 & IPv6 suppport
• Monitor mode to help configure the system

Development Items:

• Transmit strings of commands/keys on a single key press
• Manual select of target window preference (so you can set a specific client you opened to pull for instance - "CTRL+1" the next pull shot (action bar #1) will go to client 1 so that client gets the aggro)
• ALT transmit - stops mapping keys and just sends the raw key strokes
• Mouse click on screen location, you click on main client or one subclient and all the other clients do the same - allows you to talk to a quest giver and then accept the quest, or on your main get a quest and "share" it with your group and they can all accept it from your single mouse click
• Select a certain character after logon - based on profile settings, e.g. Client 1 opens 3rd character down, Client 2 opens 1st... etc.  But this is an optional item, I think its too close to a bot feature, so the player may have to just select each too
• DPS client switch - You can set in the profile which clients are DPS clients and so you use one set of key mappings for them
• Healing Client Switch - You can set in the profile which clients are healers and so you use a different set of key mappings for them
• Dynamic switch between key mapping sets as you use toggling keys - e.g. Hold CTRL - to switch between them

 Game Macro's

In Wow the key to getting the multiboxer to work is to use the macro command to call a single key on the receiving end, but that one key do multiple things, step up the Macro.

A feature built into the game, the two main macro's I'm using at the moment are:

/target <main toon name>

/follow

/target <main tool name>

/assist

With these to simple macros my gang can follow me, and then target my target, this is fine for nukers.... If one of my followers were a healer, I could make them /target <main toon> /heal...

And for a round robing "top up" I could have a macro to target each player in the group in turn and cast a top up heal... The Wow forums explain Macro's better than I can, but you get the idea I hope.

Planned Beta Release

The closed alpha is well advanced, the closed beta is therefore slated (very roughly) for the 21st March 2014.  If you want to get into the Beta now's the time to send a donation!

Send your donation, with a valid e-mail address and I'll be able to send you details of how to sign up.

MMORPG Multiboxer (Multiple WoW Clients) #4

Welcome to my dev diary number 4, for the Multiboxer project, I've had a lot of people viewing the posts, far more than the videos (there's like 190 of you viewing the posts, but only like 6 views on the videos; which tells me my tagging either sucks or the videos are so crap you're not watching them).

Well, today's video is interesting in that you will see the code base (its files) and you'll see me using it from Visual Studio, and showing you some of the ease-of use features I'm adding in.  The fact I'm adding ease of use items, and showcasing them is really just a demonstration that I'm thinking about how I, and hopefully you would want to use this software, it really is going to be driven by your guys... So donate now to spur me on!

The demonstration today will focus on the window positions settings, how they're automatically saved for you and how they're used when you start up.  We're handling 4 clients at the same time, but if we opened more the known positions for these 4 would be used and then the rest would default, all being handled seamlessly for you, as you'll see in the video.

You will also see some of the included features of the software, how we switch into "monitor mode" easily to map key codes for the "Key Mappings" configuration, which you'll also see for the first time!

You can donate directly to this project and help fund development today, any donators will receive goodies!

MMORPG Multiboxer (World of Warcraft, Runes of Magic, LOTRO) #3

A fresh development update, the launching of the more complex (than WoW) clients is now working and input is going to multiple local clients in Runes of Magic, here's my level 1 mages backing up a new level 1 Knight.  I'd never played Knight in Runes before, so this is going to be interesting, I plan to have one knight, two mages for DPS and then two priests of healing.  To nuke through the content.

The challenge will be when I come to run multiple clients, Runes of Magic seems to take about 1GB (at least while loading) per client.  Lowering the settings on the slave clients is working well however.

I am of course still looking for Donations to help pay to continue this project more actively, I'm specifically looking for WoW sponsors now as I think I need to cough up for 5 accounts, and that's going to go down with the wife like a tonne of bricks.

I will however take a saunter over to LOTRO, just as soon as I've cloned the install to my many virtual machines to multi-head testing and then cloned it to my laptop for network testing.

I'm also adding ipv6 support to the networking!

 

You can donate directly to this project and help fund development today, any donators will receive goodies, I'm not sure what you'll get yet, but it will be software related!  Or perhaps in game items to help you in your favourite games (e.g. Diamonds in Runes of Magic).

All donators receive a discount on the final product.

Any donator posting £10 or more will receive access to the software to help with the closed Beta test.

Any donator posting £100 or more can join what I'm terming the "premium" club, and have exclusive access to the development process - bug tracking, Alpha & Beta access.

Any donator posting £200 or more can come and have dinner with me and discuss direct requirements they might have for the software, or just shoot the shit about gaming and blogging in general (You have to travel to approximately the UK M1 Junction 25).

Todays video is some more, freshly taken, video of WoW.  The reason we have video of WoW and not the Rom Session above is that Rom takes so much ram it crawled - the development VM is only 32bit, so only has access to 3.5gb of ram... Wow runs much better, seems to be much more optimised.  And of course you can run WoW in DirectX9 mode to save yet more resources.