Grimrock

This is the one time of year I allow myself to agree with minmay

You are definitely making things harder on yourself unnecessarily, bongobeat. I am only saying that because I care about your mental well being buddy lol

In my Myst Demo I had some Placeholder levels named: Stoneship, Channelwood, Mechanical, Selentic, Rime. After I published the current working Demo, I took a small break before working on the final product. When I got back to work, I ended up created several level "add ons" to my Stoneship Map. Each and every one of these Stoneship add-on levels are sitting under the Rime level in my Editor. Why? Because if I try to move them up next to the actual Stoneship map, a lot of Teleporters and certain scripts would suddenly need to be fixed. And there's just no reason for it. Making the Mod would suddenly become frustrating and the only thing I would gain is... not having to use my mouse to scroll down a bit.

In your case, I assume because you have a large number of levels that you want all of them close together to make Mod'ing life a little easier to manage, however, you are better off just using a pen and paper to keep track of which levels are connected to each other. This might be a good time for some self-reflecting, to evaluate level consolidation. Sometimes, less is more

minmay wrote:But you don't need to do this! You don't need to insert new levels in the middle; you can just put them at the end and adjust the levels' world coordinates.

What I mean, is for some reason, I needed to make a new level to extend "old" levels. I just wanted to move the new level next to the old levels, because it is more clean. It's purely visual. I prefer same levels to be grouped.

Fair enough. I organize levels that way as well, but my scripting library eliminates explicit level numbers and absolute coordinates entirely, so I can rearrange levels without having to change anything else at all.

interesting,

what is this miraculous script?

The library is very large, and will not be released any time soon.

If you want a quick hack to eliminate level numbers, just have an object on each level with an id that you want to use to refer to that level. So, for example, you can place an object with an id of "south_beach" on level 43 and then instead of you'd use For teleporters and teleporting stairs, you can slightly modify your TeleporterComponent definitions to set the teleport target to the location of a corresponding object on initalization. Like, say, use the location of the object called self.go.id.."target". Then "teleporter1" will teleport to the location of "teleporter1target" instead of using absolute coordinates, so you can move the level however you want (and to change the target you just move teleporter1target).

My library does things a bit differently because each level has a bunch of extra information associated with it (weather, various water/sky material parameters...), but the principle is the same: automatically map string identifiers to each level so that the level number no longer matters.

Azel wrote:This is the one time of year I allow myself to agree with minmay

You are definitely making things harder on yourself unnecessarily, bongobeat. I am only saying that because I care about your mental well being buddy lol

In my Myst Demo I had some Placeholder levels named: Stoneship, Channelwood, Mechanical, Selentic, Rime. After I published the current working Demo, I took a small break before working on the final product. When I got back to work, I ended up created several level "add ons" to my Stoneship Map. Each and every one of these Stoneship add-on levels are sitting under the Rime level in my Editor. Why? Because if I try to move them up next to the actual Stoneship map, a lot of Teleporters and certain scripts would suddenly need to be fixed. And there's just no reason for it. Making the Mod would suddenly become frustrating and the only thing I would gain is... not having to use my mouse to scroll down a bit.

In your case, I assume because you have a large number of levels that you want all of them close together to make Mod'ing life a little easier to manage, however, you are better off just using a pen and paper to keep track of which levels are connected to each other. This might be a good time for some self-reflecting, to evaluate level consolidation. Sometimes, less is more

no problem, I don't need a paper, because I know which level are connected, even if the level is separed from his group by 37 another leves (all is written into my head)
thank you for thinking of me, I feel better now

minmay wrote:The library is very large, and will not be released any time soon.

If you want a quick hack to eliminate level numbers, just have an object on each level with an id that you want to use to refer to that level. So, for example, you can place an object with an id of "south_beach" on level 43 and then instead of

Code: Select all

Dungeon.getMap(43)

you'd use

Code: Select all

south_beach.map

For teleporters and teleporting stairs, you can slightly modify your TeleporterComponent definitions to set the teleport target to the location of a corresponding object on initalization. Like, say, use the location of the object called self.go.id.."target". Then "teleporter1" will teleport to the location of "teleporter1target" instead of using absolute coordinates, so you can move the level however you want (and to change the target you just move teleporter1target).

My library does things a bit differently because each level has a bunch of extra information associated with it (weather, various water/sky material parameters...), but the principle is the same: automatically map string identifiers to each level so that the level number no longer matters.

humm, this is quite complex for me and give me headache.
Thank you, very interesting way but I don't think I can do something like that. This is for some skilled scripter.