Units organization

Development directions, tasks, and features being actively implemented or pursued by the development team.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Post by charlieg »

safemode wrote:if you dont want any N.X.y to break for all values of y, then you have to alter X when they do break. Now there are only 4 more numbers between 0.5 and 1.0 where then we would allow to break the game backwards compatibility. I believe that's an impossible restriction...
You just completely ignored my point.

I'll be less subtle.

0.5 -> 0.6 -> 0.7 -> 0.8 -> 0.9 -> 0.10 -> 0.11 etc

Version numbers are not fractions.

Want a popular example? Current Linux kernel is 2.6.27 - where version 2.6.9 was released years ago.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Post by Deus Siddis »

Tired of people thinking your decimals represent decimals? Then stop using decimals to represent decimals!

"This message sponsored by the foundation for the conservation of natural numbers."



Decimal versions:

0.5, 0.6, 0.9, 0.12, etc.

Natural (or Whole) versions:

5, 6, 9, 12, etc.

Sometimes if you say what you mean it makes it easier for people to understand what you mean. :wink:
Seriously, up until now, I always thought these did represent decimals- some projects take advantage of this and make 1.0 the first post-beta version.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

i edited my post prior to charlie's, but apparently too late.

in any case, versioning is a contentious thing. everyone has a slightly different method.

I have to agree though, I really dont want to see minor-minor versions breaking compatibility with their minor version.

Then we have to look at the issue of the /data version vs the engine version. Do we consider any change in /data where the engine is no longer compatible to be a new minor version, or any change in /data where old data savegames to be a new minor version, both, or any change in /data where gameplay would be affected regardless of compatibility to the save game?

Then, if we disconnect them, how do we go about telling the user which releases of each are compatible with eachother? Do we add an automatic self-check to a special whitelist that gets updated continuously?
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

I think it wouldn't hurt to have a changes log thread for each.
All changes we do to PU are logged to a forum thread:
PU Revision Counter (changelog)
And the VSgame changelog could state engine compatibility changes.
Or you could put the info in the svn commit comments.
We prefer to log changes to a forum thread so it's easier for users
to see what has changed recently.
jackS
Minister of Information
Minister of Information
Posts: 1895
Joined: Fri Jan 31, 2003 9:40 pm
Location: The land of tenure (and diaper changes)

Post by jackS »

Regardless of what version number we call the next revision: given that the format of the save game has not changed, and that the quantity of information encoded in the savegame has not changed, and in fact the only change affecting existing savegames is the capitalization of a subset of the keys, we would be horribly remiss were we not to provide facilities for automatically upgrading their savegames as part of the update process.
Even if we, for some reason, decide not to do so, we're going to want to write the same braindead perl script to update all of the predefined .mission files, so we'll have already written the regexps.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

Is there really a reason why we have to be case sensitive for units and files? Why can't we search first for the spelling as it's given, if not found, try all lower case, if not found, try first letter capitalized.

Really, if this is simply a matter of case-adjustment, then we should be able to handle _all_ possibilities while slowly (or rapidly) converting the /data over and still allowing save-games created during or before this change to work. It's not like we have any distinctions between a unit called Llama and llama. So there will be no behavioral errors in supporting any of the 3 possibilities.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Getting rid of case-sensitivity would be a huge leap forward for mankind. But why can't we just do it data-side? Change all filenames to lower-case, and change all units.csv, xml file and python file and bfxm file calls to lower case?
It would have to use csv rename commands, of course.
Might take a while to write such a script or program, but it would be worth it; more intuitive than having to remember that filenames are case-insensitive.
Then unit converter could be changed to change all filenames to lowercase, as well. I bet it would improve the graphics, as well; --at least in PU many textures that don't show ARE actually there, but they have case-problems.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

because changing it in the engine, means you dont have to care about what it is in /data. And changing it in data means redownloading like half a gig of data just for a case change in the filename or references to them.

edit: Of course, changing it in the engine still means you will need to modify /data for when scripts there reference data files directly without going through vsfilesystem
Last edited by safemode on Fri Oct 10, 2008 6:57 pm, edited 1 time in total.
Ed Sweetman endorses this message.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

Actually I have just adapted ALL unit keys to title case and set UnitConverter to work accordingly. Most of the changes were related to vessels naming anyway. There is no point going back to lowercase. The reason was for the standard followed for new commits from some time on (probably before my time). It was quite error prone to remember which unit was lowercase (older ones) and which was title case (newer ones). Now all is title case. Period.

At the same time all data file names are (should be) lowercase.

Old savegames remain compatible, the user only needs to run "Replace All" for each unit that has changed. Plus there were some old name to new name changes. I can provide the full list of changes. Ok, I do it now:

Vessels:
* vark -> Agasicles
* vitik -> Agesipolis
* yrilan -> Anaxidamus
* yavok -> Leonidas
* huldra -> Ruizong
* shundi -> Shundi
* tesla -> Tesla
* Corvette -> Thales
* watson -> Watson

Installations:
* commerce_center -> Commerce_Center
* factory -> Factory
* fighter_barracks -> Fighter_Barracks
* medical -> Medical
* outpost -> Outpost
* refinery -> Refinery
* research -> Research
* starfortress -> Starfortress

We are talking about 17 changes out of a data set of 95 units.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

I'm not saying not to make the changes in /data, just that the game shouldn't care about case of filenames, and when filenames are referred to from unit names. The side-effect being, we can make these rename-corrections at our leisure or in steps and that save game files that may span such renaming-corrections will still work as expected without having to run additional utilities to "fix" them.

The downside being nil.


edit: obviously, this wouldn't work for changing the actual name to something else. Though, i would expect that to be much much more rarer than case issues. The case issue has bitten us many times.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

True; no downside that I can think of.
Your initial description of it was a bit complicated, though; I think it's just a matter of masking out the case bit when comparing strings, rather than trying different capitalizations.
Post Reply