Spring releases
Moderator: Moderators
Spring releases
Is it possible to make it so that each mod/game uses whatever spring version he wants?
so if a game uses a certain spring version as soon as that version is replaced the mod/game wont die.
Could a mod/game carry his own spring version and all of these different versions be in the same directory using the same lobbies?
so if a game uses a certain spring version as soon as that version is replaced the mod/game wont die.
Could a mod/game carry his own spring version and all of these different versions be in the same directory using the same lobbies?
Re: Spring releases
semivalid idea actually.Gota wrote:Is it possible to make it so that each mod/game uses whatever spring version he wants?
so if a game uses a certain spring version as soon as that version is replaced the mod/game wont die.
Could a mod/game carry his own spring version and all of these different versions be in the same directory using the same lobbies?
Re: Spring releases
do you really need to quote OP?... in first reply?...
</off-topicness>
afaik that would require separate servers for the multiplayer for each version of the engine, which i imagine is not an option.
or you could just not have multiplayer i guess. but that sounds lame
</off-topicness>
afaik that would require separate servers for the multiplayer for each version of the engine, which i imagine is not an option.
or you could just not have multiplayer i guess. but that sounds lame
Re: Spring releases
not required actually. six line patch, ten or so to maintain backwards compatibility.Wartender wrote:afaik that would require separate servers for the multiplayer for each version of the engine, which i imagine is not an option.
Re: Spring releases
sounds like a feature request...
The issue is with the server. Having a mod tied to a spring version is a bad idea. Unlike certain mods, many of the games are quite a large download.
The issue is with the server. Having a mod tied to a spring version is a bad idea. Unlike certain mods, many of the games are quite a large download.
Re: Spring releases
You could have latest lobbies and spring version and all players would join the same server.smoth wrote:sounds like a feature request...
The issue is with the server. Having a mod tied to a spring version is a bad idea. Unlike certain mods, many of the games are quite a large download.
When a game or mod is launched and it has its own spring version(in whatever way such a thing would be implemented) the lobby than decides,based on its lists,which spring version to use with this particular mod or game.
If the game or mod have no spring versions attached with them the lobby will just act like it does now.
This will enable mod/game makers to,at will,create versions that will run as intended always until the moment comes and the game/mod devs want to synchronize their product with the latest spring.
This will give total freedom for devs to work at their own pace without the fear of breaking something major and not having to synchronize with game/mod makers on when to release a new spring version and what changes to include in it.
And,it will also mean that game/mod makers can relax knowing that newbies coming to try their game will always get the same thing that is known to work and in a certain,specific manner.
Now,I have no idea how all these interactions between mods/lobbies/spring actually operate but can something similar be achieved?
Re: Spring releases
IMO, what we need is
(if e.g. BA doesn't upgrade for a long time, it would almost certainly reduce the testing of new Spring versions with > 90%, in particular testing of big games.)
Introducing a window of time (instead of a point in time) to give mods a chance to test and upgrade to a new Spring release would be very good though. E.g. the minimum required version could lag 2 months behind the most recent version, giving game developers a 2 month time window to test and adapt to new Spring version.
That is what should be done IMO if we want to keep going forward.
- the server to allow multiple Spring versions (version set per battle or something)
- the server to check client for minimum required Spring version (as opposed to an exact required Spring version)
- a game package being able to specify the Spring version it wants to run with by default (so there's no need to confuse user with this choice)
(if e.g. BA doesn't upgrade for a long time, it would almost certainly reduce the testing of new Spring versions with > 90%, in particular testing of big games.)
Introducing a window of time (instead of a point in time) to give mods a chance to test and upgrade to a new Spring release would be very good though. E.g. the minimum required version could lag 2 months behind the most recent version, giving game developers a 2 month time window to test and adapt to new Spring version.
That is what should be done IMO if we want to keep going forward.
Re: Spring releases
+1Tobi wrote:IMO, what we need isI believe allowing any version on the server will kill Spring, as we know already that most people are not willing to test unless they are forced to, or unless there is a big new feature. This implies that if any Spring version is allowed, the majority of people would stick with one that works, and there wouldn't be much incentive for upgrades, except maybe for those with problems in current version, or if there's a big new feature. All in all this would break down the entire release early release often model and/or result in a wildgrow of Spring versions.
- the server to allow multiple Spring versions (version set per battle or something)
- the server to check client for minimum required Spring version (as opposed to an exact required Spring version)
- a game package being able to specify the Spring version it wants to run with by default (so there's no need to confuse user with this choice)
(if e.g. BA doesn't upgrade for a long time, it would almost certainly reduce the testing of new Spring versions with > 90%, in particular testing of big games.)
Introducing a window of time (instead of a point in time) to give mods a chance to test and upgrade to a new Spring release would be very good though. E.g. the minimum required version could lag 2 months behind the most recent version, giving game developers a 2 month time window to test and adapt to new Spring version.
That is what should be done IMO if we want to keep going forward.
Re: Spring releases
but why should it be implemented? noobs will dont understand why, me neither, so nearly all updates brings benefits
Re: Spring releases
To make it easier for game developers to adapt to and test (in MP environment) a new Spring release for a while, and to reduce the dependency of this testing on the timing of Spring releases.
Re: Spring releases
also, that you can still watch replays from old versions.
Re: Spring releases
yan, I am aware of the possible benefits this is an old request. Hell I think I even made it at one point in time, either in lobby or in the appropriate forum.
Re: Spring releases
OK.
I shell write this in my list of "good ideas Smoth came up with first".
I shell write this in my list of "good ideas Smoth came up with first".
Re: Spring releases
When I was coding on battlehub I requested an engine parameter be added to the battles in uberserver, and then a version number. Aegis reported that he implemented it.
Re: Spring releases
no add it to the list of MTR and the list of times Yan fails at knowing what subforum to use.Gota wrote:OK.
I shell write this in my list of "good ideas Smoth came up with first".
Re: Spring releases
I'll assign a commity to ponder over your proposals.smoth wrote:no add it to the list of MTR and the list of times Yan fails at knowing what subforum to use.Gota wrote:OK.
I shell write this in my list of "good ideas Smoth came up with first".
- CarRepairer
- Cursed Zero-K Developer
- Posts: 3359
- Joined: 07 Nov 2007, 21:48
Re: Spring releases
I'd make it one month tops if you want new spring versions to be taken seriously.Tobi wrote:E.g. the minimum required version could lag 2 months behind the most recent version, giving game developers a 2 month time window to test and adapt to new Spring version.