-Real time strategy games are about commanding
-Almost all strategy games have some more important units.(base, commander, first unit, leader units)
-there was no need for removing it, no speed gain nothing, it just introduced bunch of ugly hacks to get some of the old functionality back
-It is "impossible" to get most of the old functionality back like non-game specific shortcut for selecting(cycling) the "most important unit", now it is hacked to the uikeys for *A with canManualfire tag and is just broken
-current situation: isCommander tag is still left in the engine just hacked to unusable and in engine AIs too used about 50 times.

When removing something remove it completely and make sure all workarounds and old functionality are possible or don't remove at all.

So every spring game out there is supposed to do a new release immediately to include this hack and then everything the other way round again when a fixed engine is available (2 days? 2 weeks? 2 months?)?
Wow, not cool...

Imo in cases like this it is okay if games temporay have to include a workaround.
Was there ever a actively maintained game that did not release a new version for every engine update anyway?
Games either update so fast* that it seems acceptable, for players too.
*or so slow that their installers uses 0.82 or something. afaik even games with longer release cycles like s44 are usually played with some testversions, that released fast-ish.

Imo there are no alternatives? (beside better testing)
Reverting the server/forcing players to revert engine seems more troublesome then copying one file into some games and publish a new version. It would potentially also break games that were updated.

(just talking about the reclaim-range thing.)

It was super convenient to have the same comm-related gadgets and widgets work for every every mod.

Yep I asked question 2 times too, but no answer.

In the mean time, at 20h GMT, number of pips playing are less than half what it is usually.

But dev have the rights not caring about the game not being played so we should not ask anymore I guess.......

Is there no replacement?

You mean game or BA dev? Because BA devs could test if the reclaim-fix for zeroK works for BA as well, if yes make BA7.65 and everybody would be playing since yesterday.

The replacement is not as easy and standard.

Each game is going to implement is own way to replace the removed game:
- So you cannot anymore share commander-related widgets accross all *A mods.
- You cannot anymore grab a comm death end gadget from one mod and plug it into another.
- Lua code dealing with commander now has to become more complicated and more dangerous.

You exactly know what I mean, that should not be mod dev who should code a new piece of gadget for each part of the engine that sometimes works one way, sometime another - especially if that is an easy bug to fix - if they want to keep a base of player. They should not expect every single player to get interested into the game dev and code their own gadget, even if they are developer, each time a pb happen, cause player want to play


And for the record, the CA gadget is not the solution, each unit you send to location because you wanted to build/reclaim/etc, but with a time-delay, is, assisting everything / moving where you dont want to, to reclaim-repair / interacting with your micro: that the reason most of player get ride of the autorepair widget, years ago.

There have been several doing that over the years. you are getting uppity with one of them.

I don't understand this at all. Have you looked at the Zk gadget or played with it?

Workaround will always exist because things break. Noone is suggesting that my workaround is a final solution and I didn't even write it to fix everything. It just fixes area reclaim which at least makes ZK playable.

You can say "why not fix in the engine instead" but this case clearly demonstrates that approach does not work. The bug is fixed in the engine but if I waited around for an engine release ZK would still be broken.

Is there a replacement that works? The only thing I know of is .CanManualFire, but that's a bad replacement. At least for XTA it doesn't work, because also the decoy commander can D-Gun.

We have an engine that's based on the revolutionary TA, revolutionary because it made the starting base a moving unit instead of a building. Now we don't even have a way of selecting that unit without confusion. But I guess the long term goal is to make the engine so abstract so that you can make a chess-game based on it (no offense to all chess players here, I really think chess is a great game).

There is no logical connection between the two halves of this paragraph.

If it's a gadget just find/replace isCommander with customparams.commander=='1' or something. The only complication lies with selectkeys and ctrl-c. I made a standalone widget for it but never committed when someone added the functionality to an existing one in zk.

The main issue is cross game compatibility but frankly I don't care about that. Gone is the era of user made widget spam because all the active games have a UI. Additionally the games are diverse enough that there are many non-trivial issues with compatibility so find-replace for isCommander is not much extra work.

Would a dev bother to give a short statement when we can hope for a fixed engine release?

Hej Guys,

The new "fixed" version MT spring.exe doesnt work.After executing the .exe file, it starts to look for dlls like libstdc+++6.dll... the previous version seems to work better. Also my firewall/antivirus system first time detected it as malware. Pretty disturbing. :D

Thanks!

I compiled under linux like described here: viewtopic.php?f=11&t=27804
and it works fine!

Sorry, it was compiled with a different compiler or settings, I have added the file now:

http://springfiles.com/spring/game-inst ... cutable-v2

This crashes too. Especially on Windows 7 64bit