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

 
 

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

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

Submitted by:  Ben Asselstine <benasselstine>
Submitted on:  Sun 20 Mar 2011 06:20:44 PM UTC  
 
Should Start On: Sun 20 Mar 2011 04:00:00 AM UTCShould be Finished on: Sun 20 Mar 2011 04:00:00 AM UTC
Category: NonePriority: 5 - Normal
Status: NonePrivacy: Public
Percent Complete: 0%Assigned to: None
Open/Closed: OpenEffort: 0.00

(Jump to the original submission Jump to the original submission)

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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project Administrator

 

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

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 21 Mar 2011 12:19:34 AM UTCbenasselstineAttached File-=>Added version-0.2.0-to-0.2.1.xsl, #22975
    Sun 20 Mar 2011 06:21:03 PM UTCbenasselstineSummarybackwards compatibility=>backwards compatibility for saved-games and other files

    Back to the top


    Powered by Savane 3.1-cleanup