Is it possible to distinguish between maps with the same ID (MAPINFO/DED/package ID)?

I would like to "attach" map e1m4b (https://www.moddb.com/groups/doomdb/downloads/john-romeros-e1m4b) to the original Ultimate Doom episode in the following way. From E1M4 go to E1M4b, from E1M4b go to E1M5. It seems that the problem is that the map ID in e1m4b PWAD is E1M4 (so it is exactly the same as in doom.wad). I tried the following approach: I created a DED file as here: https://manual.dengine.net/ded/episode#map and modified it in the following way

Map {
ID = "E1M4";
Warp Number = 4;
Exit { ID = "next"; Target Map = "file.pwad.e1m4b:E1M4"; }
Exit { ID = "secret"; Target Map = "E1M9"; }
}

Map {
ID = "file.pwad.e1m4b:E1M4";
Warp Number = 4;
Exit { ID = "next"; Target Map = "E1M5"; }
Exit { ID = "secret"; Target Map = "E1M9"; }
}

Then I load that DED file and e1m4b.wad as packages.

The exit from E1M1 sends me to E1M1, so the map E1M4 from e1m4b.wad is not recognized. It seems it should be.
I tried also several similar modifications in the MAPINFO file, but nothing worked.

Is there another way to reach my goal? I do not want to modify the file e1m4b.wad in any way (in particular I do not want to rename the map from E1M4 to something else).

Comments

  • Edit: In the above it should be "E1M4" instead of "E1M1".

    It seems that my goal will be achievable after future#1394 (https://tracker.dengine.net/issues/1394) is implemented.

    I just wonder whether it is possible to achieve the goal in the current stage of Doomsday (without waiting for feature#1394)?
  • At the moment, I don’t think this is doable without renaming the map in e1m4b.wad. There is a basic assumption that lumps with the same name get overridden (i.e., the standard Doom PWAD behavior).

    The good news is that I have several building blocks in place for accessing lumps from arbitrary packages. They just need to be taken into use for map loading.
  • It is good to hear your "good news". When do you plan to have it available?
  • Currently I don't have it scheduled for any particular release. In practice this will tie into other internal resource management changes that are on the to-do list. But generally I'll just need to decide when is the appropriate time to work on this topic area.

    The short term roadmap is looking like this:
    • 2.1 released in December
    • 2.2 released before April, with SDL 2 replacing Qt plus other internal upgrades — not many user-facing changes as such
    • 2.3 maybe sometime in 2019 with user-facing features / nice-to-have stuff
    • 3.0 replaces the renderer <= will necessitate resource management overhaul as well — work on this will be concurrent with the 2.x releases
  • Thanks for an update. It would be cool to see new renderer in 2019...
  • I agree with Drako, thanks for the update.
Sign In or Register to comment.