Create a new version of paste:

Consider assigning each skill an id number (I'd assume something like this is being used). Index each 'slot' of each hot bar, starting at 1 to 12 for hotbar one, to 108 to 120 for hotbar 10. This would be an array of 120 (at worst, integer/chars) or ideally an unsigned short integer. Assuming C or C++ was used - 16 bits minimum size, gives us a value range 0 to 65536. If a signed short is used then you'd have any value from –32,768 to 32,767 which should easily account for every skill, macro and command you can set to the hotbar. Worst case? Double the memory size by using an array of pointers for each skill, command, emote etc set to the bars. 

For each hotbar, you could record for each slot what skill you're using based on the number (starting with say, WHM's Stone at #0 to the Main Command #1008 or whatever id# it has in the game). So at 16 bits per indexed value (2 bytes), you should be [I]at 240 bytes[/I] used to save one hotbar set, plus the address of the array. At 32 bits (4 bytes) for the pointer option you'd have [I]480 bytes/I] for each set. (I'm glossing over the total size requirements for saving these sets to a hard drive, as I can't guess at how the crystal engine handles this, but best case this should be super tiny)

If space is still a concern with this, consider letting us save a limited number of 'hotbar sets', whatever you can budget for this feature. We players can easily manage to set a macro for this, or similar to our gearsets - drag the hotbar set to our hotbar!

So to break this down though. If you were to limit us to 10 hotbar settings, we're looking at best case around 2.4KB for all 10 sets, worst case 4.8KB (using the array of pointers method).

Now if you want to get real fancy, reserve one of the values as an 'ignore' value (65535 say) Any slot in the set set to this value would not overwrite whatever is set to that particular hotbar. Why do this? We have hotbar sharing of course, and you can set a hotbar to be the same for every job/class. For these hotbars set the value to 65535, in the code this would tell the game to not replace that particular set of slots - thus preserving hotbar sharing.
The problem you'd need to solve next is, how do we handle players altering their hotbar sharing settings? The easiest would be to alert the player with a warning message that their hotbar sharing settings have changed, and the set may not load correctly.

Since it's unlikely that players will be changing their hotbar sharing settings frequently, at worst this would mean a rare case that players will have to update their hotbar sets. This should be noted in the help entry in game for hotbar sets that would be needed, just as it was for gearsets; so players are aware of this.

The size requirement to add tracking for this feature? Well if we want to track the settings on a set by set basis, if you want to be super efficient but a little lazy? Use an extra unsigned short integer variable. Use this as a binary value, and each bit from the LSB to the 10th bit represents a bar. Set the value to 0 for 'shared' and 1 for 'not shared'. If the current hotbar settings and the setting saved to the variable don't match, then we'll know the hotbar settings have changed since this hotbar set was made. Add 2 bytes to each hotbar set.

This is of course, a very rough, quick and dirty idea with a bunch of assumptions. But I have to put my comp sci degree to use somehow. Hey, lemme know if you guys need another programmer by the way ;)