Saving rooms as XML

Started by Monsieur OUXX, Thu 13/08/2015 13:38:44

Previous topic - Next topic

Monsieur OUXX

Naive question here : What is the current technical difficulty for storing rooms as plain XML, at the moment, apart from "someone has to do it" ?
I mean, I know the code has to be compiled and stuff, and then it all gets binary stored into the CRM file.
But like, is there a genuine catch? For example: is it tricky because it's complex to insert a hook somewhere in the CRM compiling process, or anything like that?

If not, I could lay the base for that in the git repo. I've just pulled an "ouxx" branch.
 

Alberth

The first question is imho what do you gain? What new things can you do by switching?
The immediate second question, what about the entire installed base? You can ditch the old format, but euhm, I think some people have a few files here and there :)


Crimson Wizard

#2
Monkey0506 has started a work in similar direction two years ago. It has since been forgotten.
He moved a lot of room reading code to C#. This code is also much cleaner than the one in current branch.
(Actually the engine code is cleaner too, but I am yet to copy it to current WIP branch).

These changes are located in the "multi_room_edit" branch. I would advise to use them as a reference, but there is one problem: there are things that are not (yet) compatible with neither 3.3 or 3.4 release, so blind copying won't always work.
https://github.com/adventuregamestudio/ags/commits/multi_room_edit


Quote from: Alberth on Thu 13/08/2015 14:01:08
The first question is imho what do you gain? What new things can you do by switching?
You do not store source data in a compiled binary format, but have all data separated instead. Being able to effectively use room files under source control, as I explained here:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=52550.msg636518884#msg636518884


Quote from: Alberth on Thu 13/08/2015 14:01:08
The immediate second question, what about the entire installed base? You can ditch the old format, but euhm, I think some people have a few files here and there :)
This is solved by keeping an loading code for importing old projects.

Monsieur OUXX

Quote from: Crimson Wizard on Thu 13/08/2015 14:14:44

These changes are located in the "multi_room_edit" branch. I would advise to use them as a reference, but there is one problem: there are things that are not (yet) compatible with neither 3.3 or 3.4 release, so blind copying won't always work.
https://github.com/adventuregamestudio/ags/commits/multi_room_edit

Dammit, I skipped that branch because I thought it was only targetted at multiple opened rooms, not the file format too :)
 

Crimson Wizard

Quote from: Monsieur OUXX on Thu 13/08/2015 16:03:52
Quote from: Crimson Wizard on Thu 13/08/2015 14:14:44

These changes are located in the "multi_room_edit" branch. I would advise to use them as a reference, but there is one problem: there are things that are not (yet) compatible with neither 3.3 or 3.4 release, so blind copying won't always work.
https://github.com/adventuregamestudio/ags/commits/multi_room_edit

Dammit, I skipped that branch because I thought it was only targetted at multiple opened rooms, not the file format too :)


I guess, I was not clear enough; it was not directly related to changing file format.
The new code defines a C# RoomLoader class which loads room from CRM.

Thing is that in the Editor room data is "split" between C# object of class 'Room' and native C++ instance of "roomstruct" type, which is present as a global variable "thisroom".
I think I was investigating their relation some time ago, but forgot how much native part is used during Editor work.

This needs to be researched first, because if you will just substitute CRM for XML, you may need to init native object "by hand" from what you read of XML. This could be rather complicated.

Monsieur OUXX

Thanks for the detailed answered.

I think that monkey05_06 has modified Native.dll, because when I download his branch, it won't compile, it says it's missing a definition for "UpdateRegionCount". I works with neither Native.dll from AGS 3.4.0.6, nor the one in \Editor\References

Do you thikn I'm overlooking something?
 

Crimson Wizard

#6
Quote from: Monsieur OUXX on Thu 13/08/2015 16:42:29
Thanks for the detailed answered.

I think that monkey05_06 has modified Native.dll, because when I download his branch, it won't compile, it says it's missing a definition for "UpdateRegionCount". I works with neither Native.dll from AGS 3.4.0.6, nor the one in \Editor\References

Do you thikn I'm overlooking something?

I did definitely modify AGS.Native a lot.
We also stopped updating it in the repository, and even removed it later (you won't find it in recent branches).
I think you may try using AGS.Native from the 2013th experimental release here:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=48629.0


BTW, if you cannot compile AGS.Native yourself, or work on its code, I fear you will need someone's help to fix Native code. The big parts of game compilation are still in Native library.
This depends on what exactly are you going to do though.

Monsieur OUXX

#7
Quote from: Crimson Wizard on Thu 13/08/2015 17:05:00
I did definitely modify AGS.Native a lot.
Sorry, I got confused when reading the several branches, I didn't realize it was you who did that one.

Quote from: Crimson Wizard on Thu 13/08/2015 17:05:00
We also stopped updating it in the repository, and even removed it later (you won't find it in recent branches).
I think you may try using AGS.Native from the 2013th experimental release here:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=48629.0
BTW, if you cannot compile AGS.Native yourself, or work on its code, I fear you will need someone's help to fix Native code. The big parts of game compilation are still in Native library.
This depends on what exactly are you going to do though.
Thanks a lot for pointing me to a proper compiled version. EDIT: It worked! :D
I don't know if I'll have to modify the native code, i think that at first I could just try to save a replica of the CRM file, but as xml, to the disk, even if it's not used by the Editor. That could be useful for source control, to do compares.
Then if I'm brave enough I could write a C# loader. And then some day maybe a C++ wizard will be able to hook that code where appropriate.


 

Monsieur OUXX

There's a file called "RoomLoader.cs" but I'm confused it doesn't seemt o be part of any project.
 

Crimson Wizard

Quote from: Monsieur OUXX on Thu 13/08/2015 17:59:09
I don't know if I'll have to modify the native code, i think that at first I could just try to save a replica of the CRM file, but as xml, to the disk, even if it's not used by the Editor. That could be useful for source control, to do compares.
...Can you elaborate, please? I did not like the way it sounds... maybe I do not understand correctly.

Monsieur OUXX

Quote from: Crimson Wizard on Thu 13/08/2015 19:27:37
Quote from: Monsieur OUXX on Thu 13/08/2015 17:59:09
I don't know if I'll have to modify the native code, i think that at first I could just try to save a replica of the CRM file, but as xml, to the disk, even if it's not used by the Editor. That could be useful for source control, to do compares.
...Can you elaborate, please? I did not like the way it sounds... maybe I do not understand correctly.

Well, as a first step, when the room gets saved to CRM, I could at the same time dump it to XML, as a file that is not meant to be read back by the Editor (for now) but acts as a testimony of what is currently contained in the CRM file. Imagine you add that file to source control: then you can do compares with other files modified by other contributors. You can't do merges (because the "real" file is still the CRM file) but at least you can see easily what they changed.
 

Crimson Wizard

Quote from: Monsieur OUXX on Fri 14/08/2015 08:29:51
Well, as a first step, when the room gets saved to CRM, I could at the same time dump it to XML, as a file that is not meant to be read back by the Editor (for now) but acts as a testimony of what is currently contained in the CRM file. Imagine you add that file to source control: then you can do compares with other files modified by other contributors. You can't do merges (because the "real" file is still the CRM file) but at least you can see easily what they changed.
Oh, okay. This sounds like an interesting experiment. This may also show if we lack something in the code to make it work for real

Monsieur OUXX

#12
.

[CW]: mistakenly modified Monsieur OUXX's post instead of quoting :[.
The question was about room password and encrypted data.
 

Crimson Wizard

Room messages were encrypted. These are old feature, I do not even remember when they got removed.

cat

I was using source control when working on my OROW entry and the room files are really painful there. You don't know what changes from version to version, cannot make a div, clutter the repo with copies of the binary etc.

I'd really appreciate if the room data could be stored in a non-binary, less obscure format.

SMF spam blocked by CleanTalk