Open Source Realtime Strategy Game Engine
https://springrts.com/phpbb/
you can continue it like this:aegis wrote:Game.version = "0.81.2.0 (0.81.2-0-g76e4cf5{@}-cmake-mingw32)"
split on the first space to get "0.81.2.0"
split on periods to get ['0', '81', '2', '0']
then parse as ints to get [0, 81, 2, 0]
I didn't know you could compare list like that. Thanks.aegis wrote:
I don't want any number, I want a number that gets higher the more recent Spring is. For instance, 0.8.5 is older than 0.81.3 despite 0.85>0.813jK wrote:
Yeah but if we end up with something like version 0.89.11.2 you're screwed.jK wrote:you can continue it like this:aegis wrote:Game.version = "0.81.2.0 (0.81.2-0-g76e4cf5{@}-cmake-mingw32)"
split on the first space to get "0.81.2.0"
split on periods to get ['0', '81', '2', '0']
then parse as ints to get [0, 81, 2, 0]
table.concat({81, 2, 0},"") -> tonumber("0." .. "8120") =: version-float
so you just have one float number which can be compared with others
zwzsg wrote:I have monkeyed something that use Lua's regexp to extract digits seperated by dots
So, yeah, you workarounded that one KDR_11k exemple. But you that still didn't adress the spirit of it: Trying to make a number out of that version string is inherently ugly and prone to error. I request a robust way to know if a Spring is under or over a given version. A way that won't break when you sudently decide to change a dash by a dot in the version string. A way that knows if a 0.81+ is under or over 0.81.2.jK wrote:%02d
Code: Select all
if (tonumber(string.sub(Game.version,1,3) or 0) or 0)>=0.80 and (tonumber(string.sub(Game.version,6,6) or 0) or 0)>=1 thenCode: Select all
local function GetBetterSpringVersion()
local version=100*string.match(Game.version,"^(%d+%.%d+)")
local subversion=string.match(Game.version,"^%d+%.%d+%.(%d+)")
local subsubversion=string.match(Game.version,"^%d+%.%d+%.%d+%.(%d+)")
local TestBuild=string.match(Game.version,"^[%d%.]+(%+)")
if subversion then
version=version+subversion/100
end
if subsubversion then
version=version+subsubversion/10000
end
if TestBuild then
version=version+0.9
end
return version,test
endCode: Select all
local version=tonumber(string.match(Game.version,"^(%d+%.%d+)"))+(string.match(Game.version,"^[%d%.]+(%+)") and 0.009 or 0)Thanks!Argh wrote:I agree with that request.
Code: Select all
local gameSubVersion = Game.version
local gameVersion = Game.version
local catch
for k in string.gmatch(gameSubVersion,"-(%w+){") do
catch = k
end
gameSubVersion = tonumber(catch,35)
local catchTwo= string.match(gameVersion,"%d+.%d+.%d+.%d+")
gameVersion = catchTwo
local version = tostring(gameVersion).."."..tostring(gameSubVersion)
version = "0."..string.gsub(version,"(%p)","")
version = tonumber(version)
Spring.Echo("Clean version is: ",version)I hadn't thought of branching. Indeed when Spring starts forking, the whole concept of ordering Spring version falls down. But then, since I knew Spring, there always was a main "official" branch and all the forks were limited in use to the one person that coded them. I have yet to see binaries based on unofficial branches being distributed.2. this approach fails with different branches, which are already used relatively extensively, and this will more likely increase then decrease.
Well, then if one day Spring is getting built with something else than buildbot, that something else will have to keep increasing the build count? If someone builds his own version of Spring, I'm not worried about the build count not being properly set as long as he keeps that version to himself. If someone builds his own version of Spring then start distributing it, or if self-built Spring have to sync with bot-built Spring, then yeah we have an issue.1. this number will only be set with buildbot builds, and be empty or 0 or something, otherwise.
Basically because since the Swedish Yankspankers left, Spring developpers don't care much about retro-compatibility, so periodically a function behavior will change, or will require a different input, etc...could you possibly explain what exactly you need to compare the versions? cause.. usually you should rather care whether versions are different or not, and not so much which one is ahead of which (exactly because this is sometimes impossible).
Maybe the build number could be stored in some .h, and the buildbot would run a script to increment it. People who pull the source locally and compile without the build bot script would get a fixed build number until they update their source, which sounds like an acceptable compromise.Linux builds aren't built by buildbot and often there is no access to the internet (for security reasons) in the environment where packages are build, so unless the build number is hardcoded in the source package that solution will not work.
Yeah, we never thanks the dev for the 100s of changes that go well. We only bitch and rant about the 1 that went not so well.Also you're plain wrong about Spring devs not caring much about retro compatibility. In your comparison you forget to list the 100s of changes in behaviour for which backward compatibility was preserved, you only mention the occasional bug. (Hints: TDF still works, legacy AI API, many Lua functions have new arguments be optional, etc.)
Wrt the map name suffix, you didn't even report that in mantis yet
I tend to avoid checking version number whenever possible too. For exemple, regarding the gl.Text exemple I mentionned earlier, nowadays instead of doing a version check, I simply add the "d" option when there is no option. Or when package.loadlib got removed, then Spring.Restart got added instead of checking version number I just check "if Spring.Restart then" and "elseif package and package.loadlib then". For the Mapname I could just check if the one in Game.mapName has the suffix. And for GetTextWidth I guess I could check its output on a string I already know the width of. But sometimes analysing the game behavior to guess which engine version is running would be as complicated and hacky as getting the version itself. And there's some cases where it's plain impossible, like for when the result is different only graphically, or when testing could cause a crash.I haven't found one yet except checking for the specific behaviour when possible. (E.g.: in the spawn gadget, instead of doing complicated checks against version number, I check whether engine already spawned start units and only if it didn't then the gadget spawns them.)
Probably such an approach could work for GetTextWidth and the .smf suffix too.
Cool, we agree!Wrt the topic, I would like a better method too
Yes please. One commit to increase the number for each real commit ftw.zwzsg wrote:Maybe the build number could be stored in some .h, and the buildbot would run a script to increment it. People who pull the source locally and compile without the build bot script would get a fixed build number until they update their source, which sounds like an acceptable compromise.Linux builds aren't built by buildbot and often there is no access to the internet (for security reasons) in the environment where packages are build, so unless the build number is hardcoded in the source package that solution will not work.
If you would use the lua callins for getting archive names and / or unitsync you wouldn't have that problem, as those will return the right names in every version.zwzsg wrote:Wrt the map name suffix, you didn't even report that in mantis yet
- I know that Auswaschbar knows about it since he mentionned it.
- I was under the impression it was not a bug but a deliberate change (to make it "cleaner" or something).
- I'm pretty sure that if I had complained about that change I would just have been told to use SpringLobby instead of coding my own start-script-writer.
- As soon as I saw the problem, it didn't took me long to write a workaround by checking the version and adding or removing the suffix as needed. I tend to be quiet about bugs I can fix modside, cause it draw enough energy to draw attention about the unavoidable bugs already.