Some thoughts (and questions) on backwards-compatible resources..

Started by monkey0506, Tue 22/02/2011 06:50:56

Previous topic - Next topic

monkey0506

In working with my recent Verbcoin template, I'm now back-dating for the second time to a lower version of AGS (I'm working on porting the 3.1 template back to 3.0). In doing so I've discovered that a lot of resources have changed immensely since 3.0 was first released.

Unfortunately due to these changes, there isn't presently a simple or easy way of porting an AGS project to a prior version of AGS. The way that resources are read in is very unfriendly if the resources are coming from a newer version of AGS than the one trying to read them.

All this has got me thinking though, would it perhaps be better for AGS to provide some type of dialog whereby the user might have the opportunity to simply ignore errors such as these? For example, just off the top of my head, the Character.MovementLinkedToAnimation property didn't exist until AGS 3.1.1, but 3.1.1 uses the same file format for exported characters as AGS 3.1 did. So how then is the end-user to know from looking at the CHR file whether it's an AGS 3.1 character, an AGS 3.1.1 character, or an AGS 3.2.1 character?

Obviously ignoring errors upon import could potentially lead to other issues, but I'm thinking something along the lines of the user being granted the opportunity to ignore functions or properties of the imported item that the current version of AGS does not understand, prompting the user at each conflict. If the user so chooses to ignore these errors, then upon an otherwise successful import a log could be generated and a message displayed to the user, something such as:

Quote-----------------------------------------------
Adventure Game Studio
-----------------------------------------------

Import character 'cEgo':


Character.MovementLinkedToAnimation: Referenced property or function undefined, ignored.
Character.SpeechAnimationDelay: Referenced property or function undefined, ignored.


The above functions and properties could not be understood by this version of AGS, most likely because the imported character comes from a newer version of AGS. You may need to set the values for any of these properties elsewhere.

I understand that this type of thing is not strictly optimal, but it seems to me that it would be better to at least have the ability to share the resources backwards across prior versions of AGS than to simply abort the import with an error that the resource comes from a newer version of AGS.

Also, clearly it's too late for anything on this front to be done in the retrospective for past versions of AGS, but looking forward it might be worthwhile to consider this now, especially as the open-source movement is underway.

Thoughts?

Specifically Characters, GUIs, and Rooms are resources that I would like to see better cross-version compatibility for.

Pumaman

Hmm, what is happening at the moment if you try and import a 3.2.x CHR file into 3.0.x?

monkey0506

AGS 3.1+ uses the CHR type whereas AGS 3.0.x used the CHA type, so you can't import a 3.1+ CHR into a 3.0.x project at all.

A 3.2 CHR upon import into a 3.1/3.1.1 project:

Quote---------------------------
Adventure Game Studio
---------------------------
An error occurred importing the character file. The error was:



The property 'SpeechAnimationDelay' could not be read. This game may require a newer version of AGS.
---------------------------
OK   
---------------------------

I don't actually have a copy of 3.1.2 readily available (the first version to implement Character.SpeechAnimationDelay), but presumably a 3.2 CHR would be able to be imported into 3.1.2 (since the 3.2 manual lists no other compatibility requirements higher than 3.1.2 in the Character functions and properties). However, as I said, you definitely can't import a 3.1.2+ CHR into a 3.1.1- project.

Pumaman

Hmm good point. This does need to be improved, we need to consider the implications further.

monkey0506

Thanks Chris. As I said, it wouldn't be optimal (for obvious reasons) to just ignore these issues silently, but I think that the current method of simply aborting isn't the best route either.

Monsieur OUXX

In my humble opinion it should be like in some graphics programs (Photoshop, etc.) or in Adobe Reader (if I recall properly) :

- the Editor should be able to detect what features in the resource are newer than the editor's current version (that is: it can't read them, obviously, but at least it can tell "that it new, I can't read it")
- it should load the rest just the way it's used to
- it should discard the newer features it couldn't read, and, after it finishes loading the resource, produce a list of compatibility issues that were encountered .

That way, the resource will be loaded, but there will be some glitches (a bit like in MS Word 2003 when you manage to load a file that was made with Word 2007, but the formatting is screwed up). the user will now what feature caused the problem when reading the report.
 

monkey0506

The way I'm reading that sounds exactly to me like my original suggestion in the first post, with the exception that you seem to be suggesting AGS do this silently. I do not think that silently ignoring the errors and only notifying the user afterwards is a good idea since not every user would understand what to do with that list of ignored functions/properties/etc.

I think it would be better to have people posting that they got a warning about the resource they are trying to import being newer than the current AGS version, and what can they do about it, than to have them posting much more cryptically that something is not working as expected with their character (or whatever other resource), only to leave it up to us to discover the reason why.

SMF spam blocked by CleanTalk