Spring 87.0! 2nd Run!

[Pako]

-isCommander tag

why?

-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.

[very_bad_soldier]

BA reclaim range thing: http://springrts.com/phpbb/viewtopic.ph ... 6&p=516931
imo first try to fix the game and only if it is unfixable scream for server revert

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...

[knorke]

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.)

[zwzsg]

-isCommander tag

why?

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

[albator]

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 (or so slow that their installers uses 0.82 or something) that it seems acceptable, for players too.

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.

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.......

[smoth]

-isCommander tag

why?

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

Is there no replacement?

[knorke]

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

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.

[zwzsg]

Is there no replacement?

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.

[albator]

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

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.

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.

[smoth]

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

[Google_Frog]

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.

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.

[Jools]

Is there no replacement?

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.

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).

[Beherith]

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 is no logical connection between the two halves of this paragraph.

[CarRepairer]

Is there no replacement?

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.

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.

[Google_Frog]

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.

[very_bad_soldier]

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

[losbellos]

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!

[jamerlan]

The new "fixed" version MT spring.exe doesnt work.

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

[zerver]

The new "fixed" version MT spring.exe doesnt work.After executing the .exe file, it starts to look for dlls like libstdc+++6.dll

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

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

[100Gbps]

This crashes too. Especially on Windows 7 64bit