Egoboo Forum

[xenom]

Hello everyone,

I am currently trying to get into Egoboo development, because I wanted to start an own little game project based on Egoboo.

One basic requirement for that project is module linking.

I already looks around the net, but I didn't find anything useful.
There seems to be a version of Egoboo called "Randegoboo" with module linking. Sadly, the page seems to be offline and I was not able to find any alternative download.

Does anyone still have the source code of "Randegoboo"?

If not, I'll have to code it by myself.

I already looked at script.c, where all scriptable thing are defined.
Do I have to care about something special for module linking, or does it work like the following:
- Create a new valuecode "SWITCH_MODULE" for run_function()
- Save some player data (health, items, ...)
- Call release_module
- Call load_module
- Load the player data again
- Call an own function that teleports the player to the right location (like the top of the module if you left the previous module at the bottom)

Thanks for your help!

Greetings,
xenom

[PurpleSquerkle]

Module linking isn't working, currently, but I think it's fairly high on the todo list.
_________________

+ PurpleSquerkle

--My website--
Latest update= 7/15/08; Three new midi loops.

{new Squerkle coming as soon as I stop being lazy}

[xenom]

Oh, it isn't even working with Randegoboo?

Ok, so I'll have a try by myself on the weekend

[PurpleSquerkle]

I believe Randegoboo doesn't use the new source thing with the better menus and everything; the one we use now.
Out of curiosity, what is your "little game project?"
_________________

+ PurpleSquerkle

--My website--
Latest update= 7/15/08; Three new midi loops.

{new Squerkle coming as soon as I stop being lazy}

[Zefz]

Randegoboo does support Linking. Linking should not be too hard to add. We plan to add it into the game at some point...
_________________
http://egoboo.sourceforge.net

"The pen is mightier than the sword- IF it is sharpened, dipped in poison and thrown really really hard at your target. But seriously, you are better off with a sword."

[Chainsaw]

Module linking was possible at some point, i remember the world map module that let you enter the palaces by bumping into them on the map, but i think it won't work with the current version of Egoboo.
And i can't find that map anywhere either, just the test module without the linking.
_________________
"To err is human, to really mess up requires a computer."
Chainsaw's Cell [Last update: 27th May '08]

[xenom]

[PurpleSquerkle]

Hm, sounds fun.
_________________

+ PurpleSquerkle

--My website--
Latest update= 7/15/08; Three new midi loops.

{new Squerkle coming as soon as I stop being lazy}

[Agent of Dread]

I like your ideas.
_________________
FACEPLANT

[bgbirdsey]

I have the source for randegoboo, but the problem is that it depends on code written in C++ and integration with an older version of Lua.

[xenom]

Ok, here is my concept for handling the whole linking stuff.

This version of module linking requires two new entities (don't know how they are called in egoboo):
link_source
This works like a trigger box (call an event when you step onto a certain fan / tile).
If the player steps into this box, he will get teleported to another module.
To get more accurate linking, a link_target is placed into the link_source.

The link_source entity has the following options:
- "mod" - specifies the name of the target module to load
- "target" - specifies the name the link_target in the destination module


link_target
This entity marks the spot where the player will be after switching the module (like the player start position).

Options:
- name / number - specifies the name of the link_target (I don't know if you can specify a string in a script. Maybe you have to specify a number here)

An improved version will be a "per-pixel" linking:
This method requires an extra link_target which is placed in the link_source box. Then the engine will calculate the difference between the player's coordinates and the coordinates of the link_target in the source module. This allows the engine to place the player relative to the link_source at the target module.

When this improvement is implemented, it should be allowed to switch it off. So the player will be directly placed at the link_target (useful for stairs / doors).


Procedure of the module linking
The following things will happen if a player enters the link_source:
- Save the game data* using a save() function
( - Improvement: calculate the needed coordinates relative to the link_taret for much finer placement at the target)
- End the current module (without a winning messace )
- Load the module specified in the link_source
- Look for the link_target (don't know what happens when none is found. Maybe exit the game with an error or load the old module again)
- Load all game data*
- Place the player at the target location
- Return playing

*The module linking will depend on save / load functions. Everything you add to the save / load function will be transported to the new module. Another improvement would be to specify different save / load functions (like saveplayer(), saveallies(), savepets(), savemonsterinrange()), so the module developer can choose what to save.

Any comments on this?

[bgbirdsey]

The old method used the existing "passage" system with a script that initiated the module swap. There was also an additional data structure(s) that kept track of the character spawning and what modules were connected to the current module.

[xenom]

bgbirdsey:
Thanks for the hint of the passage system. I took a deeper look into the randegoboo source code, but (as far as I've seen) that code is only useful for random generated maps. My version will be a bit different (so it fits my needs), but it will be based on the passage system, too.

Those "linking passages" will be a bit different from the existing ones. Those passages are always open and they don't have any special masks.
Once a player enters this linking passage, the module swap will get triggered.

The linking passages are generated using a link.txt file (one for each module). In this file you specify the shortname of the new module and the object id of the link_target for each passage.


The only thing that currently works is the generation of standard passages with predefined attributes based on the link.txt file.

I'm currently creating three small test modules for working on the module swap.

What comes next:
- Trigger the module linking
- Teleport the player to the defined link_target
- Don't loose player info / stats at the module swap

I hope I can finish a first working version at the end of the week.

[xenom]

Status update
I now got a first working version of the module linking (at least I don't get any more segmentation faults when triggering the module switch ).

How does it work?
"My" implmentation is similar to the one in randegoboo. The main difference is that the module developer can specify the target module / target position via an external file called links.txt.

The links.txt file has the following layout:

[bgbirdsey]

Cool good to see you've made a simple implementation for the linking code. I want to add randegoboo back in, but that may be a while because of some complexities.

How does the code know that a given passage is a module linking passage? Are they completely different structures, or are they a mod eot the existing passage system?

My simple idea was to add a bits to the "passmask[]" variable to flag certain special kinds of passages. Right now, they only contain mods to the meshfx bits for the tiles inside the passage.

I was also wanting to attach a script to the passage itself. Right now, I think you can only make a shop passage and have the "moduletool.obj" as the owner, or something. There is no real reason that passages could not have their own scripst, though.