by Shadow Hog » Mon Jun 17, 2019 5:12 pm
A strange observation I had when toying with "Episode = clear" to illustrate an unrelated bug in PrBoom+/UMAPINFO 2.5.1.7 - if "Episode = clear"
is not present in this example UMAPINFO lump, the episode listing lists the episodes in the order they are defined (i.e.: "Main Attraction" shows up before "Extra Levels"). If "Episode = clear"
is present, the episodes are
not listed in the order they're defined (i.e.: "Extra Levels" shows up before "Main Attraction"). In either case the episode listings presented still take you to the appropriate starting map, but it's weird that this is happening at all. I'm not sure what the rhyme or reason behind the ordering when the episode listing is cleared actually is; I tried redefining the first episode from:
Code: Select all
Episode = "M_EPMAIN", "Main Attraction", "M"
to:
Code: Select all
Episode = "M_EPMAIN", "Aain Attraction", "M"
or:
Code: Select all
Episode = "M_EPMAIN", "Main Attraction", "A"
as I figured it might be an alphabetical-order thing, but in neither case did this reassert the correct positioning for "Main Attraction"; it still gets listed after "Extra Levels", despite "Main Attraction" starting at MAP01 and "Extra Levels" starting at MAP11.
Here is a ZIP file containing three WADs. Specifically:
- UMAPINFOBugExample.wad: The base WAD for UMAPINFO mod I am making, stripped down to the barest essentials for illustrating some tickets. Use Doom II for the IWAD. This will illustrate the episode listing in the intended order.
- UMAPINFOBugExampleAddon_EpisodeEqualsClear.wad: A small WAD containing a copy of the above WAD's UMAPINFO, but with "episode = clear" before any new episode definitions. To use it, load it after "UMAPINFOBugExample.wad" in the load order. This will illustrate the episode listing showing the wrong order when "episode = clear" is present.
SIGIL_UMAPINFO_full.wad is also in this ZIP file; it is not relevant to this bug report, but is relevant to other ones (I'm using the same ZIP file for like five separate reports, if it wasn't clear by now).
A strange observation I had when toying with "Episode = clear" to illustrate an unrelated bug in PrBoom+/UMAPINFO 2.5.1.7 - if "Episode = clear" [b]is not[/b] present in this example UMAPINFO lump, the episode listing lists the episodes in the order they are defined (i.e.: "Main Attraction" shows up before "Extra Levels"). If "Episode = clear" [b]is[/b] present, the episodes are [i]not[/i] listed in the order they're defined (i.e.: "Extra Levels" shows up before "Main Attraction"). In either case the episode listings presented still take you to the appropriate starting map, but it's weird that this is happening at all. I'm not sure what the rhyme or reason behind the ordering when the episode listing is cleared actually is; I tried redefining the first episode from:
[code]Episode = "M_EPMAIN", "Main Attraction", "M"[/code]to:
[code]Episode = "M_EPMAIN", "Aain Attraction", "M"[/code]or:
[code]Episode = "M_EPMAIN", "Main Attraction", "A"[/code]
as I figured it might be an alphabetical-order thing, but in neither case did this reassert the correct positioning for "Main Attraction"; it still gets listed after "Extra Levels", despite "Main Attraction" starting at MAP01 and "Extra Levels" starting at MAP11.
[url=https://dl.dropbox.com/s/tk7okh6ylvjwbn5/20190617a_UMAPINFOBugExample.zip]Here is a ZIP file containing three WADs.[/url] Specifically:
[list][*]UMAPINFOBugExample.wad: The base WAD for UMAPINFO mod I am making, stripped down to the barest essentials for illustrating some tickets. Use [i]Doom II[/i] for the IWAD. This will illustrate the episode listing in the intended order.
[*]UMAPINFOBugExampleAddon_EpisodeEqualsClear.wad: A small WAD containing a copy of the above WAD's UMAPINFO, but with "episode = clear" before any new episode definitions. To use it, load it [b]after[/b] "UMAPINFOBugExample.wad" in the load order. This will illustrate the episode listing showing the wrong order when "episode = clear" is present.[/list]
SIGIL_UMAPINFO_full.wad is also in this ZIP file; it is not relevant to this bug report, but is relevant to other ones (I'm using the same ZIP file for like five separate reports, if it wasn't clear by now).