Page 1 of 1

Retroactive (Z)MAPINFO Editing...

Posted: Wed May 30, 2018 2:26 pm
by DoomKrakken
Dear developers...

Here I am again, with the same issue presented in this thread: viewtopic.php?f=18&t=60734

Now I advocate for a different solution that does not yet exist. I request for the ability to retroactively edit (Z)MAPINFO in order to allow custom maps to be linked to pre-existing maps as hubs.

Examples can be seen here (thank you, Nash!):

viewtopic.php?f=7&t=35343
viewtopic.php?p=948276#p948276 (Rachael's post)
viewtopic.php?p=822827#p822827

Re: Retroactive (Z)MAPINFO Editing...

Posted: Wed May 30, 2018 6:06 pm
by RockstarRaccoon
I'm trying to figure out how this is different from just, like, writing a MAPINFO yourself which does this...

Re: Retroactive (Z)MAPINFO Editing...

Posted: Wed May 30, 2018 11:16 pm
by Graf Zahl
My guess is he wants to inject some additional flags into existing mods.

Re: Retroactive (Z)MAPINFO Editing...

Posted: Thu May 31, 2018 4:09 am
by Rachael
RockstarRaccoon wrote:I'm trying to figure out how this is different from just, like, writing a MAPINFO yourself which does this...
It's nowhere near the same as what you are thinking. While yes, that is feasible to do, then you are stuck with a map definition that may or may not actually match the map that is currently loaded. That can be disastrous if you want to load on top of anything except vanilla Doom.
Graf Zahl wrote:My guess is he wants to inject some additional flags into existing mods.
This is pretty close, although to be fair I'm going to guess this was a typo. He wants to be able to change all previously defined maps with a single set of flags, rather than having to redefine all the maps.

Re: Retroactive (Z)MAPINFO Editing...

Posted: Fri Jun 01, 2018 9:28 pm
by JPL
Here's some thoughts on how this could work from the data side.

The top-level feature would be a new MAPINFO keyword called something like "overridemap", which works exactly like "map" keyword except that its block's contents override properties on any already-defined map by the same name instead of outright replacing the entirety of any previously defined one.
No idea what the code implications of this are, what the code for loading map defintions looks like, or more importantly when it runs in relation to other stuff, but if it's straightforward to just load in these overridemap blocks as each new wad is loaded, that's how I'd expect it to work as a user and modder.

As far as use cases, here are a few I can think of:
- make an existing map's exit switch travel to a special map not included in the original wad
- make a vanilla IWAD / PWAD level revisitable by declaring it part of a hub
- add one of the many useful map definition properties, eg NoIntermission, to an already-defined map
(obviously, mods doing these things would have additional logic that makes it a meaningful change, eg scripting that tracks the player across levels, RPG mechanics, etc)

As for what kind of mods would take advantage of this: there are a huge number of existing WADs that have identical structure (32 maps with secret exits at 15 and 31, etc) which could be modified without having to override meaningful wad-specific data like map names, specials, skies, etc.
As far as I can tell, there are still some things that can be defined in a map defintion that can't be defined or worked around in Zscript or ACS. As Rachael says, the current method of replacing map defintions doesn't work when you just want to make a tweak.

Re: Retroactive (Z)MAPINFO Editing...

Posted: Fri Jun 01, 2018 9:56 pm
by Rachael
@ Graf:

If I were to do this what would be the best way? Something that actually modifies the data structure of previous maps, or to use a single overlaying structure that is |'d over the individual maps on load? I feel like the latter will by far produce the cleanest code, but wanted your thoughts first.

Each method has different ending consequences, obviously.

Re: Retroactive (Z)MAPINFO Editing...

Posted: Fri Jun 01, 2018 11:28 pm
by Graf Zahl
What do you mean by "single overlaying structure"?

Re: Retroactive (Z)MAPINFO Editing...

Posted: Sat Jun 02, 2018 12:05 am
by Rachael
Originally I meant that all flags defined in such a definition would just be OR'd upon map load when filling the structs, but I realized that solution might be unworkable due to the presence of strings and how they work, so never mind about it. >_<

Re: Retroactive (Z)MAPINFO Editing...

Posted: Sun Jun 03, 2018 3:30 am
by DoomKrakken
@RockstarRaccoon Because it won't work generically, that's why. If I had the patience to write a custom MAPINFO lump for every single map mod out there in order to turn certain maps into hubs, then I wouldn't even be here requesting a feature to do that during runtime.

@JPL What I wanted to do was create an item that, upon using it, would transfer the player to a different map. Once that map is completed, it'd transport the player back to the original map, with no progress lost.

Re: Retroactive (Z)MAPINFO Editing...

Posted: Thu Jun 07, 2018 11:36 am
by Apeirogon
Double this dommkrakken.
With this some one can make something like....emmm "battle for life" from conan games. Like, if player die in battle with enemies (important), player will be teleport to "divine arena" where he must kill pair of strong mobs using starting/very weak sword. In case of success resurrection on place of death, if defeat go to save/load screen.

Re: Retroactive (Z)MAPINFO Editing...

Posted: Thu Jun 07, 2018 11:54 am
by JPL
DoomKrakken wrote: @JPL What I wanted to do was create an item that, upon using it, would transfer the player to a different map. Once that map is completed, it'd transport the player back to the original map, with no progress lost.
I believe this would require a combination of what I described above, plus some ACS/ZScript. The ACS function ChangeLevel can load the player into a different level, so your "divine arena" map would have its own unique name within your mod's WAD. When the player uses the item, ZScript could save out the player's current level, then call some ACS to ChangeLevel to the arena. Then when the player completes the arena, ChangeLevel back to the previous level name stored in ZScript. But without the MAPINFO override capability I described (giving all unspecified vanilla maps Hub status), this would restart the level instead of loading the player back in to its previous state.

I could be wrong, but I think it would be possible with what I described plus that existing tech.

Re: Retroactive (Z)MAPINFO Editing...

Posted: Fri Jun 08, 2018 9:55 am
by RockstarRaccoon
I have an idea. What about a new MAPINFO flag to tell it not to unload the last map, maybe add an ACS function to go back to that last map... Would that work?

I've actually been thinking about requesting a system to give the mapper more control over which maps are loaded at one time...

Re: Retroactive (Z)MAPINFO Editing...

Posted: Fri Jun 08, 2018 1:01 pm
by JPL
RockstarRaccoon wrote:I have an idea. What about a new MAPINFO flag to tell it not to unload the last map, maybe add an ACS function to go back to that last map... Would that work?
I'm not sure I understand what you mean by "not unloading the last map"; as far as I can tell GZDoom only ever has a single map loaded at a time. I guess maybe you mean the serialized data it keeps in memory/savegames to preserve hub travel changes?
I've actually been thinking about requesting a system to give the mapper more control over which maps are loaded at one time...
Anything that's not covered by the current cluster system functionality?

Re: Retroactive (Z)MAPINFO Editing...

Posted: Sun Jun 10, 2018 5:13 pm
by RockstarRaccoon
JPL wrote:Anything that's not covered by the current cluster system functionality?
I'm not sure. I'd have to look at exactly what it does under the hood, but if Membrane turns out to be a good idea, I'd like to do something with a non-linear open world setup next. Being able to fine tune the handling of large, interconnected maps would be useful for that...

That's another request for another time though.