| 1 |
[quote]I don't know how to properly reference CMD_UNIT_SET_TARGET. What am i doing something wrong in that implementation?[/quote]
|
1 |
[quote]I don't know how to properly reference CMD_UNIT_SET_TARGET. What am i doing something wrong in that implementation?[/quote]
|
| 2 |
Set target is not an engine command, which means the engine does not put its ID in the CMD table. Behold: you can include a header file containing custom commands' IDs to use the CMD_BLA mnemonics instead of numbers thus (at least in ZK):
|
2 |
Set target is not an engine command, which means the engine does not put its ID in the CMD table. Behold: you can include a header file containing custom commands' IDs to use the CMD_BLA mnemonics instead of numbers thus (at least in ZK):
|
| 3 |
[i]VFS.Include("LuaRules/Configs/customcmds.h.lua")[/i]
|
3 |
[i]VFS.Include("LuaRules/Configs/customcmds.h.lua")[/i]
|
| 4 |
\n
|
4 |
\n
|
| 5 |
[quote]I don't understand the impact of using "shift" versus "ctrl" and "alt". What problem is that particular usage causing?[/quote]
|
5 |
[quote]I don't understand the impact of using "shift" versus "ctrl" and "alt". What problem is that particular usage causing?[/quote]
|
| 6 |
These modifiers have the same meaning they normally would, so in this case your orders always go to the end of the queue (even if the player is not holding shift because he wants the split now).
|
6 |
These modifiers have the same meaning they normally would, so in this case your orders always go to the end of the queue (even if the player is not holding shift because he wants the split now).
|
| 7 |
\n
|
7 |
\n
|
| 8 |
[quote]The more compressed code is, the harder i find it to decode mentally, and even harder to debug. Is that a bad habit/mindset/lack of skill i need to change?[/quote]
|
8 |
[quote]The more compressed code is, the harder i find it to decode mentally, and even harder to debug. Is that a bad habit/mindset/lack of skill i need to change?[/quote]
|
| 9 |
Extreme verbosity makes code more difficult to read (and debug), for it makes it easier to miss the important parts in the flood of the copypasta. In your case it is also inferior performance-wise because you're calling the same function many times. The stacked if's are non-scaling because making the widget support eg. 500 units with this method would be insane, whereas creating a loop is not only much cleaner but allows you to work with arbitrarily high numbers.
|
9 |
Extreme verbosity makes code more difficult to read (and debug), for it makes it easier to miss the important parts in the flood of the copypasta. In your case it is also inferior performance-wise because you're calling the same function many times. The stacked if's are non-scaling because making the widget support eg. 500 units with this method would be insane, whereas creating a loop is not only much cleaner but allows you to work with arbitrarily high numbers.
|
| 10 |
\n
|
10 |
\n
|
| 11 |
[quote]spBla vs Spring.Bla: Is there something objectively performance reducing about those methods?[/quote]
|
11 |
[quote]spBla vs Spring.Bla: Is there something objectively performance reducing about those methods?[/quote]
|
| 12 |
Using localized functions, you can save about a second of CPU time on a million function calls so using them for functions that will get called maybe 3 times a game is not useful.
|
12 |
Using localized functions, you can save about a second of CPU time on a million function calls so using them for functions that will get called maybe 3 times a game is not useful.
|
|
|
13 |
\n
|
|
|
14 |
[quote]I am working to generate a copy of all the various useful spring functions to keep locally in all of my widgets, so i can stop getting lost in the spring-wiki and other such reference sources to double-check how something should be used! [/quote]
|
|
|
15 |
Why not improve the wiki for everyone instead?
|
Minefield Grid Widget by Autowar