I recently found interesting fact - source codes of whole engine (without libs - but possibly some older version i got locally) is smaller than just pure gadgets+widgets sources in CA :)
I think that lots of people don't realize the gigantic ammount of work put into games and tools for this project..
Many recent engine versions make me rage because it often breaks mods, degrades performance, breaks working features or introduces new bugs.
Dev meeting minutes 2010-10-10
Re: Dev meeting minutes 2010-10-10
As I see it its mostly problem of no testing and slow turn around.
I would like to implement support for multiple engine version at least in Zero-K lobby on windows.
I would like these features to do it properly:
* spring installer creates file or entry which lets lobby discover what version is installed where. It could be in the form of simple files in same path where engine settings is. "spring.0.80.6.txt" and inside the file would be path to executable/unitsync.
- If no support, i will let user specify paths
* lobby server support for custom dictionary of values associated with battle (and preferably with user too!). So that i can store it in there.
- If no support, i will abuse modoptions, CPU of player or whatever.
* there should be clear difference between official "stable" release and "test" release .Test release installer could be simple and install just engine to different folder than default spring.
* there should be simple way to locate installer for given version on web (that already exists afaik)
I would like to implement support for multiple engine version at least in Zero-K lobby on windows.
I would like these features to do it properly:
* spring installer creates file or entry which lets lobby discover what version is installed where. It could be in the form of simple files in same path where engine settings is. "spring.0.80.6.txt" and inside the file would be path to executable/unitsync.
- If no support, i will let user specify paths
* lobby server support for custom dictionary of values associated with battle (and preferably with user too!). So that i can store it in there.
- If no support, i will abuse modoptions, CPU of player or whatever.
* there should be clear difference between official "stable" release and "test" release .Test release installer could be simple and install just engine to different folder than default spring.
* there should be simple way to locate installer for given version on web (that already exists afaik)
-
Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Dev meeting minutes 2010-10-10
Assuming I understood what I read right, in 82.6, SL supports multiple engine versions. I agree, it would def be a good thing for ZK Lobby to support multiples.
Regarding the pathing troubles, well last night I played a game on greenhaven remake and other than a few units stuck on hills here or there (which is nuts btw), it wasn't that bad, but it was pretty silly.
Regarding the pathing troubles, well last night I played a game on greenhaven remake and other than a few units stuck on hills here or there (which is nuts btw), it wasn't that bad, but it was pretty silly.
Re: Dev meeting minutes 2010-10-10
It supports it? Meaning games in same server can each be for different engine version and it runs it with correct one?
Is there any spec for this?
If it does then there is no excuse for not testing and not making separate test-only releases which still work on main server :)
Is there any spec for this?
If it does then there is no excuse for not testing and not making separate test-only releases which still work on main server :)
Re: Dev meeting minutes 2010-10-10
only thing i could imagine that Forb means, is that SL (like TASC) allows to ignore the spring version specified by the server. this is not multi spring version support of course.
as was said, the most important thing is, that the lobby server supports it.
to improve support for this in the engine, the launcher executable would be useful. other things would have to be done, like a per version base and cache dir and so on, but the launcher is the most work intensive thing, i would guess.
each engine and unitsync version would be a separate dll, and the launcher would be able to list available versions (eg launcher.exe --list-versions).
as was said, the most important thing is, that the lobby server supports it.
to improve support for this in the engine, the launcher executable would be useful. other things would have to be done, like a per version base and cache dir and so on, but the launcher is the most work intensive thing, i would guess.
each engine and unitsync version would be a separate dll, and the launcher would be able to list available versions (eg launcher.exe --list-versions).
Re: Dev meeting minutes 2010-10-10
Oh Zero-K can also ignore server version and work, that has always existed, but thats not really what i meant :)
As for installers - perhaps there could be simple simple zips containing only the important stuff to run engine - base files, executable, dll.
Lobby would then download and put to some folder automatically.
Because spring by default uses local (to executable) cache folder and local archivecache file there wont be a problem with engine itself i believe.
As for installers - perhaps there could be simple simple zips containing only the important stuff to run engine - base files, executable, dll.
Lobby would then download and put to some folder automatically.
Because spring by default uses local (to executable) cache folder and local archivecache file there wont be a problem with engine itself i believe.
Re: Dev meeting minutes 2010-10-10
Tobi wrote:We just skipped it because not the right people were present.
We have just discussed it again, I will create the forum soon.
-
Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Dev meeting minutes 2010-10-10
+1FLOZi wrote:Tobi wrote:We just skipped it because not the right people were present.
We have just discussed it again, I will create the forum soon.
-
BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
Re: Dev meeting minutes 2010-10-10
no, it really supports handling multiple spring installations at the same time since years, switching to the appropriate one as neededhoijui wrote:only thing i could imagine that Forb means, is that SL (like TASC) allows to ignore the spring version specified by the server. this is not multi spring version support of course.
I never added the gui for it since I tough that atm there'd be very little use for it and it would be just confusing for the user, but all the internal code supports it and it should be trivial to expose an interface for it
Re: Dev meeting minutes 2010-10-10
Oh boy, old code the nobody uses. :D