Maybe a way for third-party programs to interact with RND...

Discussion around programming R'n'D, its source code and its tools.

Moderators: Zomis, Flumminator

Post Reply
Zomis
Posts: 1501
Joined: Mon Jun 21, 2004 1:27 pm
Location: Sweden
Contact:

Maybe a way for third-party programs to interact with RND...

Post by Zomis » Fri Feb 17, 2006 12:16 pm

Okay Holger, let me know what you think about this idea...
It may be a little crazy, and it would be a little work for you, but it could make the work for me (and maybe some other rnd-utility-makers) much easier..

Let's say that we start RND using
rocksndiamonds.exe --putfile C:\025.level

This would load the level C:\025.level and output (to stdout or some other place...) the LevelInfo bytewise - as it is stored in the LevelInfo (and ElementInfo, of course... and those other structures) structure according to the RND source.

Then, RNDTool could load this file and - with the LevelInfo structure translated into Delphi code - load the LevelInfo stored in the file to Delphi, for any kind of manipulation...

And then, when done with the manipulation inside RNDTool, RNDTool saves the LevelInfo bytewise into C:\Games\rocksndiamonds-3.1.1\loadme.dat

And then, we run this command on RND:
rocksndiamonds.exe --loadfile loadme.dat C:\025.level
which then saves 025.level out from the bytewise loadme.dat file.

Hope you understand, and yes... it may sound a little crazy, but it was just an idea. It was just an idea to hopefully make RND interact with 3-rd party programs (or vice versa)
Let me know what you think...
Or should I go back to translate the 174kB files.c? (or fix all those hundreds of problems an auto-converter created in "files_c.pas", 237kB...)

User avatar
Holger
Site Admin
Posts: 3225
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Fri Feb 17, 2006 4:45 pm

I think I have a vague idea of what you were thinking of, but I may be wrong.

Your idea is (virtually) taking the raw level file, fill in the internal structures (like LevelInfo and ElementInfo) and then dump them bytewise?

But what would you have then what you don't have now with the current level format (which is also a binary ("bytewise") format)?

I see major disadvantages: The internal format of LevelInfo etc. may dramatically change from version to version, while the chunk-based level file format stays 100% the same. It would be enough to just swap around a few variables (maybe only for reasons of clearness) in the structure to totally confuse your loader code, while the level file format did not change at all. I'm sure this would do more harm than that it helps.

> Or should I go back to translate the 174kB files.c?

Of course not -- just use "diff" (or any graphical tool that does the same in a GUI environment -- something like "Eclipse", for example) and only look at changes that affect the functions "LoadLevel...()" and "SaveLevel...()" -- there are only *very* few changes in the last years, believe me!

Another thing that might help more would be something that can be used just as you described, but that would read/write native (binary) level files and translates them to/from XML. This way it would be quite easy to read newer levels with a level loader that is a bit older (and that would just ignore some new entries). In fact, the current chunk based model works exactly the same (ignoring new, unknown chunks or ignoring bytes that did not have a meaning in an earlier version), but may appear harder to handle to the current generation of programmers who grew up with Java and XML. ;-)

But seriously: As there are quite a lot of tools and libraries available to parse through a bunch of XML data, this might indeed help third-party programmers to read or write or convert R'n'D levels easier.

Other thoughts or ideas about this?

HerzAusGold
Posts: 326
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

HerzAusGold

Post by HerzAusGold » Fri Feb 17, 2006 5:02 pm

Hi,
XML is a interesting idea .

Hm, rndtest09 include loading from local file too.
May be you have only combine the option with dump (ok, it's not binary)
Please test this (I'm far away from my computer)

> rndTest09 -url=C:\025.level
And the answer is ... 42 !

Zomis
Posts: 1501
Joined: Mon Jun 21, 2004 1:27 pm
Location: Sweden
Contact:

Post by Zomis » Fri Feb 17, 2006 5:25 pm

Holger wrote:I see major disadvantages: The internal format of LevelInfo etc. may dramatically change from version to version, while the chunk-based level file format stays 100% the same. It would be enough to just swap around a few variables (maybe only for reasons of clearness) in the structure to totally confuse your loader code, while the level file format did not change at all. I'm sure this would do more harm than that it helps.
Hmm... yeah, that's true. That thought came to my mind for an hour ago or so... I thought "oh well... I've already posted it now... let's see what Holger says at least". But you're right here of course. This is a huge disadvantage.
Holger wrote:Of course not -- just use "diff" (or any graphical tool that does the same in a GUI environment -- something like "Eclipse", for example) and only look at changes that affect the functions "LoadLevel...()" and "SaveLevel...()" -- there are only *very* few changes in the last years, believe me!
Yeah, I've used Total Commander to compare the source between 3.1.0 and 3.2.0-6, found 185 differences. I don't know yet how many of those affect the functions LoadLevel___ and SaveLevel___.
Seriously, what are all those other things beside the Load and Save functions? like the "element_conf" struct? Aren't some of those also used for LoadLevel and SaveLevel?
Holger wrote:Another thing that might help more would be something that can be used just as you described, but that would read/write native (binary) level files and translates them to/from XML. This way it would be quite easy to read newer levels with a level loader that is a bit older (and that would just ignore some new entries). In fact, the current chunk based model works exactly the same (ignoring new, unknown chunks or ignoring bytes that did not have a meaning in an earlier version), but may appear harder to handle to the current generation of programmers who grew up with Java and XML. ;-)
Hmm... XML... interesting idea... but not my favorite... haven't learned at all how to use XML yet. But it would be cool anyways to have RND output a level to XML... but not neccessary, I think.
HerzAusGold wrote:Hm, rndtest09 include loading from local file too.
May be you have only combine the option with dump (ok, it's not binary)
Please test this (I'm far away from my computer)

> rndTest09 -url=C:\025.level
Yes, rndtest can load localfile as well... but rndtest can only load them to RND, not modify them in several ways like RNDTool can (or at least will be able to do someday...)

User avatar
Holger
Site Admin
Posts: 3225
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Fri Feb 17, 2006 5:25 pm

> May be you have only combine the option with dump (ok, it's not binary)

You mean extending '-e "dump level <file>"' to print the level (as XML, for example)? Could be extended that way, though the "dump" option was merely intended to print some level information in a user readable way. But this could be extended indeed...

HerzAusGold
Posts: 326
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold » Fri Feb 17, 2006 10:24 pm

You mean extending '-e "dump level <file>"'
Yep this is the right way .
But dont try > rndTest09 -xml (..may be in the next version)
But this could be extended indeed...
Yes indeed...
But in C - writing a xml parser (or writer) with C++ is easier (imo).

* Zomis:
IFF is near to XML (like Holger wrote), and XML is easy like HTML.
For first steps you can look here:

http://en.wikipedia.org/wiki/Interchange_File_Format

btw: Credits to all the wikipedia writers
And the answer is ... 42 !

Post Reply