Francesco wrote:Furthermore - little off-topic now - I'd like to have the mentioned scripting tool. I could make one if I knew the level file structure (records identifiers and lenghts), but I'm not able to figure it out from the souce code - for the obvious reason that I'm a C dummy.
I've seen from RnDtool that you are already using the original code to load the levels, maybe you can provide me something for the above task: even if you or Alan are going to make it, I'd like to try, just to practice.
Yes... We'll see about that scripting tool... it would indeed be useful... I can't promise anything though
Last edited by Zomis on Thu Feb 09, 2006 2:35 pm, edited 3 times in total.
Recently I tried to create a CE scripting tool, but I wasn't able to export level loading code from RnD source... (And I consider myself relatively experienced C programmer.) For example: where is the declaration for setup structure? No, it's not in setup.h, it's in system.h. Well, maybe setup.c contains setup files loading... Wrong! It's in files.c. And guess when do you set if a CE is indestructible... No, it's not in ElementInfo structure (as most other information about CEs), but in a bitmask "Properties". (Probably for historic reasons?) Of course, don't take this personally, Holger, I think I just use different coding style. RnD is a great game.
P.S. I recommend LUA as a scripting language, but it may be hard to port to Delphi/Pascal, because it's programmed in ANSI C.
Tomi wrote:Maybe this is soo off topic, but here goes...
Nope, not anymore Splitted 2 posts from the old thread..
Yes, it's hard to find the fileloading code... and when you've found that, then you need to find the element structure... which is located in main.h if I remember correctly (not sure about this though...)
Wouldn't it be better to have all that structure code and functions for loading the different files in for example "files.c".. so it would be easier for external programmers (for example Alan and I) to see & copy the file structure code and stuff...? Or at least let us know where the code actually is
I converted the loading-code to Delphi once (resulting in RNDTool), but it was pretty much work actually... which is a big reason to why I haven't worked much with RNDT lately...
I'm also thinking of converting the loading-code to PHP (which SHOULD be easier, since PHP and C are more similar than C and Delphi), so that you could click a file in the archive and see the level layout, or take a look at the configured CEs and so on. I'm also thinking about a "Tape explainer" (or whatever it could be called) which would open a .tape file and explain how you should solve it (Press left for 12 frames for example)
Not so sure about the following (Holger will surely explain it as he will read these posts) but the code needed...
It would be the file "src/files.c". Look for functions "LoadLevel()" and "SaveLevel()", and also for functions like "LoadLevel_<chunk name>()", which load certain chunks and is called from "LoadLevel()".
I'm just reporting his words, as I asked the same things directly to him by e-mail. Maybe it was just a first direction, but I think he meant that all the stuff can be figured out from there.
For now my contribution ends here, sorry, but I'm looking for the time to gain some knowledge about all this. Maybe I'll be able to say something in the (far) future
but I'm not able to figure it out from the souce code - for the obvious reason that I'm a C dummy.
Me too... I figured out where all the data is stored in a level simply by loading it into a hex editor with a duplicate of itself. I then went into RNDs editor and changed something, then back to the hex editor and compared the two levels. It took a while but I managed to map everything in a level and for all level versions.
As for scripting.....
Confedit's Basic has lots of level functionality like changing elements in a map (poke and peek), change all the level's settings (including size), draw shapes, convert it's version (up and down), save and load all the CE data, rotate, mirror and best of all a powerful search and replace feature that uses groups. Currently working on A* pathfinding (for making your own level solving programs) random mazes, and plasma shapes!
The only thing it doesn't do automatically is custom element changing, since Zomis has already done it there's no point.
Hi Alan,
release your confEdit, I cant wait...
Dont add more features.
For zip support I change all this places where data loaded and written.. see some chunks (good old IFF from amiga) .. and now sometimes I have a bits and bytes fighting nightmare..
You can search for #HAG#ZIP# in my rndTest release to see it all too.
Level is loaded in "files.c"
Alan wrote:Me too... I figured out where all the data is stored in a level simply by loading it into a hex editor with a duplicate of itself. I then went into RNDs editor and changed something, then back to the hex editor and compared the two levels. It took a while but I managed to map everything in a level and for all level versions.
*Simply*???
...terrific, I started a similar work but I gave up as soon as I knew that maybe you were solving it for us all.
I agree and sign in under HerzAusGold's request: release it as soon as you can, even if it's a pre-release alpha beta or whatsoever... pleez, Alan...
Alan wrote:The only thing it doesn't do automatically is custom element changing, since Zomis has already done it there's no point.
Well... RNDT can't do all changes... currently it's just copying CEs from level to another level and it changes the internal CE-links between them. But since it was a long time ago I worked on RNDT and there's many RND-versions which has been released since then, I doubt that it still works...
But a Custom Element scripting tool is still missing...(or will ConfEdit BASIC be able to do that?)
Maybe next week I can extract some information from the C source and explain a little about how the properties are stored, and how the chunk-structure is like... We'll see if I have time for that.
Tomi:
> Recently I tried to create a CE scripting tool, but I wasn't able to export
> level loading code from RnD source... (And I consider myself relatively
> experienced C programmer.)
Just a little hint on how to do this: Start with "LoadLevel()" in "src/files.c", and then add all dependent functions (which are not necessarily stored in "src/files.c" -- if in doubt, use "grep" under Unix or some sort of IDE like "Eclipse" if you prefer a more graphical approach).
> For example: where is the declaration for setup structure? No, it's not in
> setup.h, it's in system.h.
Yes, you are probably right that it should better be stored in "setup.h"...
Here you have to differ between game specific code and the general game library functions in "src/libgame". Everything in "src/libgame" is (or at least should be) independent from the current game (which could be R'n'D, or Mirror Magic, or ...), while stuff directly under "src" is related to the specific game, That's why "src/libgame/setup.c" mainly contains functions for generic setup file handling, like loading artwork. Besides that, "src/files.c" contains all file handling functions for the specific game -- unfortunately, setup files also belong to this category, so the existence of a file "src/libgame/setup.c" might be misleading here. :-/
> And guess when do you set if a CE is indestructible... No, it's not in
> ElementInfo structure (as most other information about CEs), but in a
> bitmask "Properties". (Probably for historic reasons?)
You guessed right -- this indeed has historic reasons, and comes from a version where CEs were in an very early state, and there were more or less no generic element properties (like those which are now stored in the ElementInfo structure), but only very specific properties for each "classic" element in the code.
But you are perfectly right, so I just fixed this and replaced "Properties[e][p]" with "ElementInfo[e].properties[p]".
> Of course, don't take this personally, Holger, I think I just use different
> coding style.
Absolutely no problem -- indeed I'm thankful if somebody throws some light on some old parts of the code from time to time, and asks the right questions. :-)
Remember that some parts of the code are more than ten years old, so it's no surprise that some things are not as logical or structured as they should be (or as they would be if I would have written everything from scratch in a short time).
Redesign and refacturing of the code is a normal process, and I'm happy to clean up the mess a bit from time to time, so it's easier to understand (also for myself). :-)
Zomis:
> Wouldn't it be better to have all that structure code and functions for
> loading the different files in for example "files.c".. so it would be easier
> for external programmers (for example Alan and I) to see & copy the file
> structure code and stuff...?
About the game specific file loading code, I agree, and this should be more or less in "src/files.c" already. About the game structure code, I would prefer to keep this in "src/main.h", as it is used by various parts of the game, like the game engine, the level editor etc.
> I converted the loading-code to Delphi once (resulting in RNDTool), but it
> was pretty much work actually... which is a big reason to why I haven't
> worked much with RNDT lately...
If your project would be in C or C++, it would indeed be worth thinking about providing some sort of API which could just be included and linked to your project's code, enabling you to just use the structures and functions to load and save game data.
Alan:
> Me too... I figured out where all the data is stored in a level simply by
> loading it into a hex editor with a duplicate of itself. I then went into RNDs
> editor and changed something, then back to the hex editor and compared
> the two levels. It took a while but I managed to map everything in a level
> and for all level versions.
This is of course the die-hard hacker method, which always works and which I also used quite some times for other games which did not offer the comfort of providing the whole source code... ;-)
> Remember that some parts of the code are more than ten years old
Namely ten years and four months?
I also experienced another problem: Most structures/#defines are in main.h and it's hard to tell which ones do I need. It's also hard to integrate them into scripting languages.
> > Remember that some parts of the code are more than ten years old
> Namely ten years and four months?
That's the age of the first version (0.9) of R'n'D, yes. :-)
But in fact, it's even older than that: The code of R'n'D is based on Mirror Magic, which is from 1994. And large parts of Mirror Magic are based on the code of the Amiga version of Mirror Magic (released under the name "Mindbender"), which was written as early as (around) 1988! That's what I call evolution! ;-)
And although the R'n'D code already saw some redesigns, there are still some very old pieces of code lurking in dark corners... ;-)
> I also experienced another problem: Most structures/#defines are in
> main.h and it's hard to tell which ones do I need. It's also hard to
> integrate them into scripting languages.
About the "#define"s: You can just change them to constants.
About "which ones are needed": Just add nothing and compile. The compiler will tell you then which ones should be added. ;-) (Although it may sound funny, it really is the easiest approach!)
> P.S. Did I already recommend Lua?
Yeah, you did! I had a deep look at the web site, and I think I like it! If I should ever add external scripting to R'n'D, I'm quite sure I will use Lua for it! :-)
Splitted 2 posts from the old thread..
