Bah, I know that, maybe I was using sarcastic language. But ally-team is a stupid construction, it means nothing sensible (if you are a team then it's assumed you are also allied, how can you e.g. be a foe-team? It makes no sense).

If you comshare then I consider that as a variant of sharing a player, not a team. I know that spring has different stance in internal functions, but there is no need to bring that crap out in the light.

Take the analogy of a football game: you have players and then you have teams. Even though there are some games where many people can control the same players (remember kick-off), it's doesnt make that player a team.

One possible concept to use could be alliance instead of ally-team.

There's nothing stopping you modifying your game to include an endgame stats widget with the word 'Alliance' or 'Team'

Oh cool, I thought I needed to hack the spring.exe

Or if the engine team wants to be objective, why not just revert to the old "You lost/won" or even just "Defeat/Victory".

springsettings.cfg --> AdvMapShading=0

You act like kids, seriously :D

Cool, thanks. With new spring my fps nearly doubled, now I get 120 fps.

Nice, good to see Spring is still alive :D

Does anyone know?

1-2 days, we will possibly go straight to 84.0 due to issues found in 83.0.

I think older versioning was better. Now it will be like chrome or emacs with uber version changing. (I suppose 84 will be bugfix release when you say it will be in next few days)

In this case a sync-breaking bugfix release, therefore 84 instead of 83.1

Well, a version is just a version. Problem with old versioning system was that we were approaching 1.0. People may have certain expectations for a 1.0 release that we may not be able to meet.

So instead they expect spring to be 82 revision beyond 1.0 now?

+1 zerver now chrome and emacs is far behind and wont be likely even close for moderate time amount

I would just name it 0.1xx and writen something silly with ending "HAHA" who expected 1.

Just joking. Good job pathing fixes are really nice in this version.

We still haven't decided if our naming scheme is base-10, rather than 82 versions we may have jumped 130 versions if it's a hexadecimal version scheme

I thought it was
major.sync.release?

You could always make version 0.100 after 0.99

There seems to be some issue when automatically installing Spring through ZKLobby - it gives map checksum error with every map.
Some people using TasClient had this problem too so I post the solution that worked for me and potential cause here.

It seems that downloading Spring manually and installing it manually fixes the problem.

I think the issue has to do with folders:
- I had Spring version 0.82 in D:\Games\Spring
- the ZKLobby installed Spring into D:\Games\Spring\engine\83
- I run ZKLobby from D:\Games\Spring because my shortcut pointed here
- checksum error every game
- I installed Spring 83 manually into D:\Games\Spring and run ZKLobby again
- now it works

The current versioning scheme ensures there is never more than 1 single decimal place.

vMajorRelease.Minorfix

The details of what constitutes a major and a minor release are in the thread in development complete with fancy graphs by Hoijui

And you don't think they'd have even higher expectations for version 83.0? I read that as "we have made 82 new stable releases since version 1.0. Spring is older than your grandfather."

Well, those expectations only build up once you approach 1.0, and this OMGWTFBBQ!1!!11!! 83 all of a sudden mega-surprise prevents that gradual buildup nicely.

I assume you have seen projects having versions like 0.999.99.99, and there is a reason for that.