Post
by Holger » Sat Feb 11, 2006 2:51 pm
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"...
> Well, maybe setup.c contains setup files loading... Wrong! It's in files.c.
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... ;-)
Splitted 2 posts from the old thread..
