Custom formations 2 v3.0 - Relevant changes
Posted: 13 Apr 2010, 14:40
So I just updated custom formations2 to version 3.0, and there's a few changes that will influence current/future widgets/gadgets.
1) Custom formations now uses the correct option format in CommandNotify.
Previously, custom formations would call CommandNotify with options in array form i.e. {"alt", "shift"}. It now calls with the correct map form, i.e. {['alt']=true/false, ['coded']=32, ...}.
Note that with custom formations running even single-clicks were 'formations', and hence CommandNotify was sent (in the wrong format) by custom formations.
2) Custom formations no longer calls CommandNotify for multi-unit formations.
Previously if you issued a formation order custom formations would call CommandNotify with the command parameter being the first nodes position, despite only one of the many units having those parameters for its order. Custom formations would detect any widget handling this, and give an error message about a conflict.
What happens now with formations is that custom formations will look for a function 'UnitCommandNotify' in each widget, and call it with 'uID, cmdID, cmdParams, cmdOpts', i.e. the same arguments as you get for CommandNotify but prefixed with a unit ID.
This will be done for every unit in the formation (with cmdParams being the parameters relating to the specified unit), where a widget returning true will stop the command being issued (as well as further UnitCommandNotify calls for that unit).
3) Custom formations still calls CommandNotify for orders that have a single set of parameters for the entire selection (single-click, unit paths), and will abide by the return value.
---
So that's about it. If any of those changes breaks your lua, then the problem is in your lua. All the changes make custom formations more transparent, i.e. spring will behave the same with or without custom formations, so any problems you get are the same ones you'd get by simply disabling custom formations.
1) Custom formations now uses the correct option format in CommandNotify.
Previously, custom formations would call CommandNotify with options in array form i.e. {"alt", "shift"}. It now calls with the correct map form, i.e. {['alt']=true/false, ['coded']=32, ...}.
Note that with custom formations running even single-clicks were 'formations', and hence CommandNotify was sent (in the wrong format) by custom formations.
2) Custom formations no longer calls CommandNotify for multi-unit formations.
Previously if you issued a formation order custom formations would call CommandNotify with the command parameter being the first nodes position, despite only one of the many units having those parameters for its order. Custom formations would detect any widget handling this, and give an error message about a conflict.
What happens now with formations is that custom formations will look for a function 'UnitCommandNotify' in each widget, and call it with 'uID, cmdID, cmdParams, cmdOpts', i.e. the same arguments as you get for CommandNotify but prefixed with a unit ID.
This will be done for every unit in the formation (with cmdParams being the parameters relating to the specified unit), where a widget returning true will stop the command being issued (as well as further UnitCommandNotify calls for that unit).
3) Custom formations still calls CommandNotify for orders that have a single set of parameters for the entire selection (single-click, unit paths), and will abide by the return value.
---
So that's about it. If any of those changes breaks your lua, then the problem is in your lua. All the changes make custom formations more transparent, i.e. spring will behave the same with or without custom formations, so any problems you get are the same ones you'd get by simply disabling custom formations.