|
|
Goombert
|
|
Reply #2 Posted on: August 24, 2014, 11:15:00 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
I was already aware that this was going to happen and was planning a topic on the issue. Really we just need to ask Josh or Ism to weigh in.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
|
egofree
|
|
Reply #4 Posted on: August 24, 2014, 01:58:27 pm |
|
|
Joined: Jun 2013
Posts: 601
|
How about a crazier idea and splitting the format in two, since nobody seems to think LGM deserves incremental version numbers
As we are speaking of adding only a few variables, it seems to me a little bit overkill ! I propose this : let's add a 'version.txt' file inside the egm file, which will contain the version number. (An Egm file is a zipped archive). When reading the file we would test the version number : for (int j = 0; j < noinstances; j++) { Instance inst = rm.addInstance(); inst.setPosition(new Point(in.read4(),in.read4())); // Read new properties if (version ==1.1) inst.setScale(new Point2D.Double(in.readD(),in.readD())); .....
I know it seems perhaps a 'quick and dirty' solution, but we are speaking only about adding a few variables and to my knowledge we rarely have to change the data structure. If one day we would have to change a lot of things, a whole new class could be added to read the new version. Another solution would be to change the structure of the egm format, and add for example metada, but as egm format has been made to be as quick as possible, i don't think it would fit the bill. (c.f http://enigma-dev.org/docs/Wiki/EGM) For writing, i propose not to test the version. This means we would have always the new properties and the user should always use the latest version of Enigma/LateralGm. But as we have speaking of a free and open-source software, this should not be a problem. And again, we are not changing often the data structure.
|
|
« Last Edit: August 24, 2014, 02:19:29 pm by egofree »
|
Logged
|
|
|
|
IsmAvatar
|
|
Reply #5 Posted on: August 25, 2014, 09:05:33 am |
|
|
LateralGM Developer
Location: Pennsylvania/USA Joined: Apr 2008
Posts: 877
|
The binary format was intended to be temporary, and was the reason that the EGM format never left alpha. As long as it remains binary, it should definitely be versioned. If it isn't versioned already, that was definitely an oversight. The goal is to switch all resources towards E-Yaml. Since EGM has always been alpha, it's perfectly acceptable to abandon support of the old version and add the properties to the new version, however I would also strongly encourage you to add versioning while you're in there too. If there are people with important files on the old versions, someone could write a converter to convert files to the new version. For example, a very simple converter would be to just custom-build an LGM with both the old Room Reader and the new Room Reader, and only the new Room Writer. They would simply make a backup, open the file in this custom LGM, and then re-save the file.
In EGM, versioning is intended to be done on a resource-by-resource basis. If there was a global version number for the EGM, it should be in the manifest file, and would virtually never changes since the EGM format is designed to be as modular and final as possible. One of the only changes I would see that would warrant changing the version number outside of the manifest would be if we switched away from E-Yaml.
|
|
« Last Edit: August 25, 2014, 09:27:10 am by IsmAvatar »
|
Logged
|
|
|
|
egofree
|
|
Reply #6 Posted on: August 25, 2014, 10:23:03 am |
|
|
Joined: Jun 2013
Posts: 601
|
IsmAvatar: Thanks for your feedback. So the egm format needs a lot of refactoring, but this is not my goal right now, i just want to add a few properties. Therefore, i think my quick fix is acceptable for the moment : with a few lines of code, it will allow the user to import old egm files. If there was a global version number for the EGM, it should be in the manifest file, and would virtually never changes since the EGM format is designed to be as modular and final as possible But this doesn't seem the case at the moment : actual data are saved sequentially in binary format, without any description. Concerning the manifest file, my understanding is that it's linked to a jar file, and the egm format is currently not a jar file (even if a jar file is also a zipped archive).
|
|
« Last Edit: August 25, 2014, 10:29:56 am by egofree »
|
Logged
|
|
|
|
IsmAvatar
|
|
Reply #7 Posted on: August 25, 2014, 11:50:43 am |
|
|
LateralGM Developer
Location: Pennsylvania/USA Joined: Apr 2008
Posts: 877
|
"Manifest" was probably the wrong word. I meant something similar to a Jar's manifest file - it is a file in the main directory that provides information about the archive (not the TOC). Maybe we don't have one. I don't recall. It's been a while since I've touched an EGM file.
Point is, the actual EGM format should never really change, since it's so modular. If it ever does, it would be a different format, so would probably warrant a new extension. All that changes are the internal resource formats, which have their own readers for handling that.
Also, I was looking through the code, and I saw that we do have a RoomEefWriter/Reader (as an alternative to the RoomGmDataWriter/Reader), it's just not hooked in because it was experimantal. Again, the intent is to eventually switch to something like that, so if you want, go ahead and thoroughly review that code to make sure it doesn't have any logic errors, and feel free to switch over to it and try it out.
|
|
|
Logged
|
|
|
|
time-killer-games
|
|
Reply #8 Posted on: August 25, 2014, 01:15:51 pm |
|
|
"Guest"
|
Wonderful news! Whoop whoop!
|
|
|
Logged
|
|
|
|
egofree
|
|
Reply #9 Posted on: August 25, 2014, 02:36:21 pm |
|
|
Joined: Jun 2013
Posts: 601
|
Also, I was looking through the code, and I saw that we do have a RoomEefWriter/Reader (as an alternative to the RoomGmDataWriter/Reader), it's just not hooked in because it was experimantal. Again, the intent is to eventually switch to something like that, so if you want, go ahead and thoroughly review that code to make sure it doesn't have any logic errors, and feel free to switch over to it and try it out.
Yes, i saw these files, and i was wondering what was the use. Sorry but i don't intend to try them now. I am sure that it would need a lot of testing. I spent already a lot of time on the new properties and my goal is to finish this task correctly as soon as possible. (At first i thought also that it would need only a few days, but as usual in programming, there is almost never easy tasks ) So i hope my quick fix is still ok. Of course if someone would like to propose and IMPLEMENT a new and better solution, i am open.
|
|
« Last Edit: August 25, 2014, 02:41:46 pm by egofree »
|
Logged
|
|
|
|
egofree
|
|
Reply #10 Posted on: August 26, 2014, 04:37:08 am |
|
|
Joined: Jun 2013
Posts: 601
|
I've implemented the new properties in egm files : https://github.com/enigma-dev/lgmplugin/pull/26It works for old egm files too, but egm files come also with gb1 files which can cause problem and must be deleted. I don't know the use of this file.
|
|
« Last Edit: August 26, 2014, 04:40:59 am by egofree »
|
Logged
|
|
|
|
|
|
egofree
|
|
Reply #13 Posted on: August 26, 2014, 10:06:57 am |
|
|
Joined: Jun 2013
Posts: 601
|
Since EGM has always been alpha, it's perfectly acceptable to abandon support of the old version and add the properties to the new version, however I would also strongly encourage you to add versioning while you're in there too. If there are people with important files on the old versions, someone could write a converter to convert files to the new version. For example, a very simple converter would be to just custom-build an LGM with both the old Room Reader and the new Room Reader, and only the new Room Writer. They would simply make a backup, open the file in this custom LGM, and then re-save the file.
As i will not write such a converter and as IsmAvatar asked me to remove the support of old versions, this means it will not be possible to read old egm files, except of course if someone will work on a new converter. But as for the moment nobody else is likely to work on LateralGm, this seems to be a dangerous situation. Well, anyway that's was my 2 cents.
|
|
|
Logged
|
|
|
|
|
|