taskLordsAWar! - Tasks: task #11020, backwards compatibility for...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #11020: backwards compatibility for saved-games and other files

Submitter:  Ben Asselstine <benasselstine>
Submitted:  Sun 20 Mar 2011 06:20:44 PM UTC
   
 
Should Start On:  Sun 20 Mar 2011 04:00:00 AM UTC Should be Finished on:  Sun 20 Mar 2011 04:00:00 AM UTC
Category:  None Priority:  5 - Normal
Status:  None Privacy:  Public
Assigned to:  None Percent Complete:  100%
Open/Closed:  Closed Effort:  0.00

Jump to the original submission

Fri 11 Jul 2014 03:23:05 PM UTC, comment #7: 

this has been added, and tested minimally.  seems to work.

Ben Asselstine <benasselstine>
Group administrator
Tue 19 Apr 2011 11:38:32 AM UTC, comment #6: 

the backwards compatibility code has been written, but not really tested.

the most difficult thing to implement will be when we need to add a graphics file of the right tilesize to upgrade a tileset/armyset.


Ben Asselstine <benasselstine>
Group administrator
Mon 21 Mar 2011 11:48:45 AM UTC, comment #5: 

To retain attributes use:
<xsl:copy-of select="d_name"/>

instead of:
<d_name><xsl:value-of select="d_name"/></d_name>


Ben Asselstine <benasselstine>
Group administrator
Mon 21 Mar 2011 11:32:30 AM UTC, comment #4: 

The xml:lang attribute needs to be retained in the <d_name> element of <itemproto>, so that translations are preserved in the items.xml file.


Ben Asselstine <benasselstine>
Group administrator
Mon 21 Mar 2011 12:19:34 AM UTC, comment #3: 

Attached is the xslt stylesheet for converting a saved game xml file from 0.2.0 to 0.2.1.

the idea is that:
1. items that aren't usable do not get a <d_uses_left> entity.
2. items that have a bonus of "STEAL_GOLD" get a <d_steal_gold_percent> entity
3. items that have a bonus of "BANISH_WORMS" get a <d_army_type_to_kill> entity.

This affects <itemproto>, and <item> which inherits from it.

Everything else is the same.

I think this will also work for the items.xml file.

(file #22975)

Ben Asselstine <benasselstine>
Group administrator
Sun 20 Mar 2011 07:13:58 PM UTC, comment #2: 

Maybe we should just execute the xlstproc program to do the transformations, instead of bothering with a new api.

So, we could get away with not adding another build dependency.

the xsltproc program is included with libxslt on fedora.

Ben Asselstine <benasselstine>
Group administrator
Sun 20 Mar 2011 06:40:58 PM UTC, comment #1: 

Here's the xslt engine that would fit best with lordsawar:

http://xmlsoft.org/XSLT/html/libxslt-lib.html
http://en.wikipedia.org/wiki/Libxslt

License: MIT License

Ben Asselstine <benasselstine>
Group administrator
Sun 20 Mar 2011 06:20:44 PM UTC, original submission:  

I've been adding a backwards compatibility layer in the form of the FileCompat class.

It culminates in a program called lordsawar-upgrade-file (src/upgrade-file.cpp)

The way it works is that various classes register support for backwards compatibility for their file types.

And then they also register support for backwards compatibility "upgrade" functions that convert a file from version X to version Y.

The FileCompat class walks the upgrade through the various version changes.

What isn't implemented is how that the files are actually upgraded.

I figure it can be done in one of two ways:

1. the XSLT way, where i do a transformation to the xml files.

2. or by putting the C++ code that reads in that version
into it's own library.


Here's an example of what i'm dealing with:

The xml format for items just changed in 0.2.1.

if <d_bonus> in <itemproto> contains a value of ItemProto::STEAL_GOLD,
then there needs to be another entity called <d_steal_gold_percent/>.
The <d_bonus> value can look like:
"ItemProto::STEAL_GOLD | ItemProto::BURN_BRIDGE"
So we're not dealing with exact text matches.

(Before I was just having the item steal 50% of an opponent's gold when it was "used", and now it can be any percent the map designer picks.)

Copying the old C++ classes into a library doesn't scale well.  The tarball would get really huge if I were doing backwards compatibility of 10 versions.

Also, the xslt transformations would require another build and run-time dependency.  And lastly, I'm not familiar with xslt at all.

Ben Asselstine <benasselstine>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #22975:  version-0.2.0-to-0.2.1.xsl added by benasselstine (2KiB - application/xslt+xml)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by benasselstine (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-07-11 benasselstine Percent Complete0% 100%
        Open/ClosedOpen Closed
    2011-03-21 benasselstine Attached File- Added version-0.2.0-to-0.2.1.xsl, #22975
    2011-03-20 benasselstine Summarybackwards compatibility backwards compatibility for saved-games and other files

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code