Please fix:games contain version in "name" tag (modinfo.lua)

[abma]

most games contain version tag in modinfo.lua.

unitsync already contains a hack to add a version to the name, if it isn't added. To get versioning working the games needs also to remove this tag

for example change
return {

name='Balanced Annihilation V7.31',

to
return {
name='Balanced Annihilation',

in modinfo.lua

The hack:
https://github.com/spring/spring/blob/m ... r.cpp#L121

Update: The Engine now annoys about names that contains the Version tag:

for example:
"Warning: Invalid Name detected, please contact the author of the archive to remove the Version from the Name: <name><version>, Version: <version>"

[Forboding Angel]

Most of the Games use the version tag as intended. It's generally only the Mods that don't use it correctly. (From what I've seen anyway)

[FLOZi]

How is 'versioning' going to work? Different games have their own version conventions.

fwiw, Forb, S44 doesn't use the version tag and does include version in the name, so we evidently need to change.

[Forboding Angel]

Wut???

You guys are on rapid!

For svn version name you should be using $VERSION

Then your test revisions would be test-<revnumber>

And then to release a actual version to the masses, in your commit message:

VERSION{Operation Suck My Balls}

Resulting in it looking like:

Spring: 1944 - Operation Suck My Balls

Name would of course be:

Spring: 1944 -

[FLOZi]

You guys are on rapid!

Guess again.

[abma]

ba + zero-k used it the wrong way. i didn't check others.

versioning works this way:

(example of fixed modinfo.lua)

Code: Select all

return {
  name='Zero-K',
  description='Zero-K',
  shortname='ZK',
  version='v0.8.5.2',
  mutator='1',
  game='',
  shortGame='',
  modtype=1,
  depend = {
    'Spring content v1',
  },
  NTAI = {
    tdfpath='ZK';
  },
}

modinfo.lua for spring 1944 is wrong too:

is:

Code: Select all

local modinfo = {
		name						=	"Spring: 1944 v1.53 Operation Market Garden",
		shortName				= "S44",
		game						= "Spring 1944",
		shortGame				= "S44",
		mutator					= "Official",
		description			=	"Epic World War II RTS!",
		url							=	"http://www.spring1944.net/",
		modtype					=	"1",
}

return modinfo

should be:

Code: Select all

local modinfo = {
		name				=	"Spring: 1944",
		version 				= "v1.53 Operation Market Garden"
		shortName			= "S44",
		game				= "Spring 1944",
		shortGame			= "S44",
		mutator				= "Official",
		description			=	"Epic World War II RTS!",
		url					=	"http://www.spring1944.net/",
		modtype				=	"1",
}

Evolution RTS, Kernel Panic, XTA, Tech Annihilation, did it correctly.
The tutorial game did it.. ehm.. undecided. Version should always contain a number. (its "sdd" there)
Nota did it wrong.

the name tag should never change!

[Licho]

But what should be the standard for version?
Can it cntain text?
How will the system determine whats newer and what older verison?

[abma]

i think this way is fine: http://de3.php.net/manual/en/function.v ... ompare.php

if we want a "Your game version is old, please update it" messages in lobby, then we need some stricter rules.

IMO text is ok, but it should be comparable, that means, always keep the same style.

[Licho]

So this function will be implemented in unitsync too?

[jK]

How will the system determine whats newer and what older verison?

It was never designed for that. It is a subtitle of the name. And the engine will always need game name + version to start an instance.
What you want is already done via the "replace" tag.

So this function will be implemented in unitsync too?

The unitsync can already return the version.

[knorke]

The tutorial game did it.. ehm.. undecided. Version should always contain a number. (its "sdd" there)

if you mean my game:
i always use "sdd" for the "currently being worked on version" that is in .sdd form.
when i pack it as .sdz i change the version.
ie http://springfiles.com/spring/other/spr ... z-download
has version = "27 april 2011",

for the svn there is probally some way to make it autoupdate version on each commit but didnt figure that out yet.

Must it really always be a number?
From engine source it seems a string (like the date) is ok too, even the example says "v2.3"

[Licho]

it probably is but aim is i think to make further automated processing on springfiles/plasma server - to determine latest verison of given map/mod.

So it should follow some convention.

That way you can have simple upload (just grab file -> upload to some service) - upload service extracts data from modinfo/mapinfo and fills all stuff for the web and replaces "current" version with it if its newer.
For this last step it needs to determine which version is newer.

[abma]

@licho:

exactly! :)

@knorke:

no, please don't use that. If you want the date as version, please use something like this: 2011.04.27 (like ubuntu it does)

an increased number should always mean a newer version.

"1 Januar 2012" would be older than "27 april 2011" because 1<27. thats not what we want here. if we really need a release date, we should better add a tag like "releasedate". imo we have already enough tags in modinfo.lua, so we should use the existing tags.
For the release date, better use the description tag.

[smoth]

Code: Select all

return {
  name='Gundam RTS',
  description='Gundam RTS',
  shortname='Gundam',
  version='1.26',
  url="gundam.smoth.net",
  mutator='Official',
  game='',
  shortGame='',
  modtype=1,
  -- depend = {
    -- 'Spring content v1',
  -- },
}

[knorke]

ah ok.
i was not aware that the version tag was being compared for new/old anywhere, i thought it just checks if versionA==versionB.
btw thanks for thread + issue.

[abma]

@smoth:

this is fine. imo url="gundam.smoth.net" should start with http://, but this is currently used nowhere.

[jK]

From engine source it seems a string (like the date) is ok too, even the example says "v2.3"

That's because the example is for the OUTPUT, and the engine auto appends the version string to the name string.

[hoijui]

in the future (in spring master already), we will support arbitrary tags in modinfo. the engine will not make use of them of course, but they will be scanned, and available through unitsync.

[knorke]

nice.
I hope lobby, downloadsystem, etc developers will decide on some standard tags.

[Pxtl]

I remember being disappointed with toolchain support for this - launching from Spring.exe had terrible support for it. I assume the newer Spring.exe GUI fixes that?