Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Death Egg

"UMAPINFO" discussion

Recommended Posts

Apologies for the double-post, but I managed to get a build of the current git repository made. See, for some reason my INI-format UMAPINFO lump stopped getting parsed by GLBoom+ (according to Task Manager it'd open, do nothing visible to the end user, and then silently close itself, but would stop doing that if I deleted the UMAPINFO lump - hell if I know) which gave me the impetus to get my compile of the curly-brace-format EXE working. Fortunately, I was able to figure out what was going on this time (two instances of "uint64_t" when VS2017 wanted "uint_64_t", and having to rename "pcre.lib" and "pcreposix.lib" to "pcre3.lib" and "pcreposix3.lib", respectively) and get a build compiled.

 

I guess that makes the first question moot for now, though answers for the other three questions in my previous post would still be appreciated.

 

But, while we're mostly hunky-dory there, there's still a problem - and since this is based on the current code, I figure @Graf Zahl might appreciate the bug report: for some reason, if a map entry's InterText gets too long, the program crashes on start-up with this error message:

 

Quote

 

Microsoft Visual C++ Runtime Library

 

Debug Error!

 

Program: D:\DOOM\prboom-plus-2.5.1.4um\prboom-plus (Curly Brace).exe

 

HEAP CORRUPTION DETECTED: after Normal block (#4301) at 0x00DC3C18.

CRT detected that the application wrote to memory after end of heap buffer.

 

(Press Retry to debug the application)

 

Abort/Retry/Ignore

 

Removing some lines from InterText lets it boot, but then the InterText obviously isn't as long as it needs to be. Seemingly, only line count matters, not line length; shortening the last line to an empty string still throws the error.

 

Example WAD here. Trimmed out all the other fluff from the mod I'm making to one UMAPINFO lump with a single map entry for MAP01; with my build, at least, it still consistently breaks in the above fashion, though the Normal block number and the pointer changes with each run (as you'd expect).

Share this post


Link to post

Slight bumpo, since this thread's more relevant than the other one.

 

Is there a reference example of a UMAPINFO lump in curly-brace format somewhere? Someone was asking about it earlier in Discord-land and I'm having trouble finding one.

 

[EDIT] I should clarify I'm seeking something comprehensive. The post above is a start, but it's just a small subset.

Edited by Xaser

Share this post


Link to post

I suppose I can try and port NERVE.WAD's entry in ZMAPINFO to UMAPINFO and see where that gets us? It'd be something immediately usable with PrBoom+2.5.1.4u, at least.

Share this post


Link to post

Double post for new content. While it turns out PrBoom+ already handles NERVE.WAD just fine and didn't need a UMAPINFO lump in the first place, I still went ahead and made one just to illustrate how it'd look:

 

Spoiler

// No Rest for the Living
MAP MAP01
{
	LevelName = "the earth base"
	LevelPic = "CWILV00"
	Next = "MAP02"
	NextSecret = "MAP09"
	SkyTexture = "SKY1"
	ParTime = 75
	Music = "D_MESSAG"
}

MAP MAP02
{
	LevelName = "the pain labs"
	LevelPic = "CWILV01"
	Next = "MAP03"
	NextSecret = "MAP09"
	SkyTexture = "SKY1"
	ParTime = 105
	Music = "D_DDTBLU"
}

MAP MAP03
{
	LevelName = "canyon of the dead"
	LevelPic = "CWILV02"
	Next = "MAP04"
	NextSecret = "MAP09"
	SkyTexture = "SKY1"
	ParTime = 120
	Music = "D_DOOM"
}

map MAP04
{
	LevelName = "hell mountain"
	LevelPic = "CWILV03"
	Next = "MAP05"
	NextSecret = "MAP09"
	SkyTexture = "SKY1"
	ParTime = 105
	Music = "D_SHAWN"
}

map MAP05
{
	LevelName = "vivisection"
	LevelPic = "CWILV04"
	Next = "MAP06"
	NextSecret = "MAP09"
	SkyTexture = "SKY1"
	ParTime = 210
	Music = "D_IN_CIT"
}

map MAP06
{
	LevelName = "inferno of blood"
	LevelPic = "CWILV05"
	Next = "MAP07"
	NextSecret = "MAP09"
	SkyTexture = "SKY1"
	ParTime = 105
	Music = "D_THE_DA"
	InterText = clear
}

map MAP07
{
	LevelName = "baron's banquet"
	LevelPic = "CWILV06"
	Next = "MAP08"
	NextSecret = "MAP09"
	SkyTexture = "SKY1"
	ParTime = 165
	Music = "D_IN_CIT"
	BossAction = Fatso, 23, 666
	BossAction = Arachnotron, 30, 667
}

map MAP08
{
	LevelName = "tomb of malevolence"
	LevelPic = "CWILV07"
	EndCast = true
	SkyTexture = "SKY1"
	ParTime = 105
	Music = "D_SHAWN"
	InterText = "TROUBLE WAS BREWING AGAIN IN YOUR FAVORITE",
				"VACATION SPOT... HELL. SOME CYBERDEMON",
				"PUNK THOUGHT HE COULD TURN HELL INTO A",
				"PERSONAL AMUSEMENT PARK, AND MAKE EARTH",
				"THE TICKET BOOTH.",
				"",
				"WELL THAT HALF-ROBOT FREAK SHOW DIDN'T",
				"KNOW WHO WAS COMING TO THE FAIR. THERE'S",
				"NOTHING LIKE A SHOOTING GALLERY FULL OF",
				"HELLSPAWN TO GET THE BLOOD PUMPING...",
				"",
				"NOW THE WALLS OF THE DEMON'S LABYRINTH",
				"ECHO WITH THE SOUND OF HIS METALLIC LIMBS",
				"HITTING THE FLOOR. HIS DEATH MOAN GURGLES",
				"OUT THROUGH THE MESS YOU LEFT OF HIS FACE.",
				"",
				"THIS RIDE IS CLOSED."
	InterBackdrop = "SLIME16"
	InterMusic = "D_READ_M"
}

map MAP09
{
	LevelName = "march of the demons"
	LevelPic = "CWILV08"
	Next = "MAP05"
	NextSecret = "MAP05"
	SkyTexture = "SKY1"
	ParTime = 135
	Music = "D_DDTBLU"
}

 

A few notes:

  • I'm pretty sure that commented-out line works.
  • MAP07 has Map07Special defined in gzdoom.pk3's internal MAPINFO lump, even though, as far as I can tell, no tags 666 or 667 are present in the map. Nevertheless, I tried to replicate the general effect, just to show off how that works. (I've used this feature in a few maps now, and yeah, that's what it looks like. ZDoom monster name, Boom line special number, and sector tag number, in that order.)
  • This actually doesn't appear to run on my compiled build of Graf's repo, for much the same reason that my own UMAPINFO adventures don't - InterText seems to be kind of broken for some reason. I have a stack trace, though! I'll toss it in a spoiler tag.

Was there anything else you wanted to know?

 

(That stack trace:)

Spoiler

 	Doom.exe!free_dbg_nolock(void * const block, const int block_use) Line 940
 	Doom.exe!_free_dbg(void * block, int block_use) Line 1011
>	Doom.exe!free(void * block) Line 16
 	Doom.exe!Z_Free(void * p, const char * file, int line) Line 516	C
 	Doom.exe!Z_Realloc(void * ptr, unsigned int n, int tag, void * * user, const char * file, int line) Line 653
 	Doom.exe!ParseMultiString(Scanner & scanner, int error) Line 112
 	Doom.exe!ParseStandardProperty(Scanner & scanner, MapEntry * mape) Line 235
 	Doom.exe!ParseMapEntry(Scanner & scanner, MapEntry * val) Line 345
 	Doom.exe!ParseUMapInfo(const unsigned char * buffer, unsigned int length, void(*)(const char *) err) Line 367
 	Doom.exe!D_DoomMainSetup() Line 1844
 	Doom.exe!D_DoomMain() Line 1995
 	Doom.exe!SDL_main(int argc, char * * argv) Line 577
 	Doom.exe!main_utf8(int argc, char * * argv) Line 127
 	Doom.exe!WinMain(HINSTANCE__ * hInst, HINSTANCE__ * hPrev, char * szCmdLine, int sw) Line 190
 	[External Code]
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]

Share this post


Link to post

I know that stable releases of [G/Q]ZDoom have had it in place for a while now. I'm not sure if anything else has implemented it; people aren't really using it yet, though I'm not sure if it's because they don't care, or if they're waiting for broader support from Boom-format engines (who are probably waiting for maps that require it to force their hand, creating a bit of a Catch-22).

Share this post


Link to post

So I assume the syntax is decided on then? I haven't read the topic in some time but I know that was an issue for a while.

Share this post


Link to post

With some luck, UMAPINFO is going to become very big in the near future. UMAPINFO is a big part of the compatible Doom extensions spec, if I can ever find the time to finalize and submit the rough draft.

Share this post


Link to post

I keep meaning to convert the reference implementation to C, but I haven’t. 

Share this post


Link to post
3 hours ago, Jon said:

I keep meaning to convert the reference implementation to C, but I haven’t. 

I thought it was C (I haven't done much looking into it yet.) Are there some C++-isms in there? Real C++, or just some operator/type enhancements to otherwise C code?

Share this post


Link to post

I haven’t read it all thoroughly; it’s mostly very C like with the odd thing like extern TArray<const char *>

Share this post


Link to post
Posted (edited)

Sorry to wake up this dormant thread but I think it's such a pity that this didn't get any more attention.

As far as I can see, UMAPINFO support was actually also added to Eternity, correct?

 

With 2 of the mayor engines supporting it, it's already a useful lump for simple WADs so that they don't have to include both ZMAPINFO & EMAPINFO for the simple addition of a new episode (SIGIL.WAD is a very good example... I'm not sure if it'll include UMAPINFO, but it'd be a pity if it didn't, and I'd blame it on the lack of advertisement and zero adoption among mappers ...I bet most mappers don't even know it's a thing).

 

Not only it's already useful as a bridge between ZMAPINFO/EMAPINFO but it's also intended to be relatively simple so it can be supported also by others ports in the future (it seems there was also some intent to add it to Doom Retro, even though it was shortly reverted, but it would be great to do this instead of pushing for yet another format for Doom Retro such as "RMAPINFO" which seems to be what it uses), maybe it would be a good idea to publicize UMAPINFO a bit more since it seems there's people who don't even know about it (as brought up here), and most of the ones who do know it may think that it's not ready to be used, since it wasn't clearly advertised that GZDoom/Eternity do now support it.

 

At the very least I think it should be mentioned in the wikis. It would be a pity to see this effort wasted, considering it would be quite convenient and a noble effort at bringing up some needed unification, on a feature that's relatively not really that much disruptive for simpler ports to support, imho. A C 89 implementation of the parser would help though, I could try and add it to the libretro PrBoom port.

 

Btw, for a moment I thought the documentation was still outdated, but I've just re-checked and realized it's actually up to date already with the curly-braces syntax, so I've edited my comment about that:  here's the ummapinfo.txt doc, it includes a short example of what the lump must look like.

It'd still be a good thing to mention it in doomwiki/zdoom wiki, and maybe also update the release of the PrBoom+ fork, since the latest version precompiled that's hosted there uses the old ini-like syntax and could get people confused.

Edited by Ferk

Share this post


Link to post

I don't want to sound like a broken record, but someone really needs to take over PrBoom so that this type of baseline feature can become really useful.

 

It should also be mentioned that even though both GZDoom and Eternity support this lump, it's likely that active use of it will uncover some potential issues, because it never saw any real life testing.

Share this post


Link to post
Posted (edited)

Wait. It's not yet supported in Eternity. I started the code and wrote most of it, but didn't enable its support yet. 

 

I think the latest format is very similar to EDF, and this makes it attractive: I may just turn UMAPINFO into another autoloading EDF lump, and let users place level definitions wherever they like. However, it's not Eternity's original work. This means that I'll have to somehow mark any Eternity additions with a prefix or container block to avoid the risk of colliding with other ports' additions. New features aren't even that original to deserve special EE naming: think of all the Hexen-like effects such as double skies. I wouldn't like to have to prefix them with ee- just because PrBoom is Doom only. I can't trust that UMAPINFO won't get enhanced by popular consensus while I'm away from Eternity, with the risk of using names I might have added. I can't trust that UMAPINFO remains feature-frozen. So adding my own additions under the same namespace may spell trouble. 

 

Also, last time I saw it, it had rough assumptions about game ending sequences. It looked to me like it checked whether the ending level was episode 1, 2 or 3. Either that or something else which made me reluctant to support in Eternity, because it would add undesired logic. 

Share this post


Link to post

@printz A safe way to go for things that aren't yet in the UDMF standard but probably ought to be is give them an `eternity-` vendor prefix now, then deprecate & alias the prefixed version if a spec-supported version comes down the line later.

 

It does make sense to have some sort of shared standard for game-specific stuff -- whether that be a `hexen-`prefix or just adding 'em to the base namespace with a "ports may ignore these if they don't support game 'x'" clause (UDMF has some things like this, kinda), but that can't come until the base implementation exists, I'd not like to see this become a chicken-and-egg situation.

Share this post


Link to post
Posted (edited)

For what it's worth, the thing I've been laboring on for the past... Christ, almost two years now, all on my own without showing anyone, is a little UMAPINFO-using project. I had been shooting for 28 maps eventually, but given the nature of the feature we're talking about and the nature of the mapset in question, I'm almost at 10 (I had the bright idea of doing a city map and it turns out I am not very quick at making those, whoops), and that's probably a sufficient example WAD. If we're waiting for content to justify support, then... well, I'm definitely no skillsaw, but it's a start, I suppose?

 

And yes, it does pull up a few more bugs as @Graf Zahl suggested it would. For instance, it doesn't play too nicely with ZDoom's cluster setup, such that leaving one cluster for another, which doesn't trigger an interstitial text screen in the version of PrBoom+ that added UMAPINFO support, does in GZDoom, and the music for said interstitial text screens (if specified in the UMAPINFO lump) also plays in the general KILLS/ITEMS/SECRETS/TIME intermission screen as well, which seems unintended. I should probably report those on the ZDoom forums instead of here, though.

Share this post


Link to post
8 hours ago, Xaser said:

@printz A safe way to go for things that aren't yet in the UDMF standard but probably ought to be is give them an `eternity-` vendor prefix now, then deprecate & alias the prefixed version if a spec-supported version comes down the line later.

 

It does make sense to have some sort of shared standard for game-specific stuff -- whether that be a `hexen-`prefix or just adding 'em to the base namespace with a "ports may ignore these if they don't support game 'x'" clause (UDMF has some things like this, kinda), but that can't come until the base implementation exists, I'd not like to see this become a chicken-and-egg situation. 

 

I already started on defining a combined namespace, but for some reason this got never picked up so it went dormant again, but considering the rather large cross-section of common features between Eternity and ZDoom it really makes sense to properly define one. Having something more feature-rich than Boom/MBF that can be played both with a demo compatible engine and with an advanced hardware renderer could be a large boost to making more advanced map sets (which I'd really like to see, actually!) Of course one other thing that might need unification then is actor definitions. Having to do these twice is not really the best thing for this kind of map set. (If push came to shove I'd have to see how to parse EDF actor definitions to have something in common there... ;) )

 

 

 

 

Share this post


Link to post
On ‎4‎/‎20‎/‎2019 at 9:53 AM, Graf Zahl said:

 

I already started on defining a combined namespace, but for some reason this got never picked up so it went dormant again, but considering the rather large cross-section of common features between Eternity and ZDoom it really makes sense to properly define one. Having something more feature-rich than Boom/MBF that can be played both with a demo compatible engine and with an advanced hardware renderer could be a large boost to making more advanced map sets (which I'd really like to see, actually!) Of course one other thing that might need unification then is actor definitions. Having to do these twice is not really the best thing for this kind of map set. (If push came to shove I'd have to see how to parse EDF actor definitions to have something in common there... ;) )

 

 

 

 

What about overriding ? Keep the definition as is on ports that don't support a new feature and change it to something new based on the port's features. I know it ain't perfect but it can help out with this kind of situation. 

 

(P.S. : You also might want to check Classic RBDoom's ActMap. It adds new logic to maps based on the sector tags but also it keeps the map compatible with older ports (even vanilla))

Share this post


Link to post

In regards to what @Ferk said about publicity, I personally think that there should be some sort of website or something about UMAPINFO and such so that there is...

A:A place to easily find how to use UMAPINFO.

B:A place to know which ports do support UMAPINFO.

C:Downloads for the code to support that in your own port.

 

This could be supremely useful to people who want to support the specifications that UMAPINFO belongs to, since the information and the code becomes more easily accessible.

Share this post


Link to post

As long as this thread has come up again, I was able to fix the bug with the intermission texts for the PrBoom+ fork Graf made. I know Graf already made a fix, but for whatever reason, even with two additional bytes being allocated to account for the NUL terminator of both strings (instead of only one as originally published), I was still getting the same error - but adding three extra bytes didn't. Given that adding more memory to fix fatal crashes isn't usually a good sign, with a suggestion by @Edward850 I just rewrote the offending code to use strcat() (instead of strcpy() and direct array accesses as before), and the error's not come up since. IDK why the realloc() was crashing things in the prior code, by my reckoning it should've worked fine.

 

I'm not particularly well-versed in Git (more used to SVN); do I do a git Commit or git Push to submit the changes for review? I'd kind of like to distribute this EXE in the future, but it doesn't feel right to me to do so when the code on the repository wouldn't behave quite the same as the executable supplied.

Share this post


Link to post
1 hour ago, Shadow Hog said:

I'm not particularly well-versed in Git (more used to SVN); do I do a git Commit or git Push to submit the changes for review? I'd kind of like to distribute this EXE in the future, but it doesn't feel right to me to do so when the code on the repository wouldn't behave quite the same as the executable supplied.

 

The workflow is normally as follows:

 

- First fork the repo at Github into your own account and then clone your own fork to your hard drive.

- create a local branch for the change.

- Make your changes and commit to your local copy.

- Push the changes and the new branch to your Github repo.

- Go to Github and make a pull request of the new branch.

 

Then the master repo will get a notification so that your change can be reviewed and added if deemed proper.

Share this post


Link to post
Posted (edited)

I've also ported the parsing logic to more idiomatic C for the libretro PrBoom port (not merged yet, but here's my branch). It's halfway C89 with C99 comments so it can compile for PSP with psp-gcc. Since Retroarch has a PSP port.

It seems to work fine mostly, but I did not completely test all the logic, and I didn't add support for the bossactions yet.

Share this post


Link to post

If I'd ever seriously pick up work on this I'd convert it all to C++, actually. I find working with plain C and its laxness very painful. C++ makes coding so much easier...

 

Share this post


Link to post
Posted (edited)

I'm not sure how worth it such a rewrite would be. At that point why not just work on the Eternity engine which is also demo compatible and loosely similar to an extended PrBoom+ in C++?

 

However, my intention wasn't to open a PR against the PrBoom+ fork to change it to C (I think it's good to also have a C++ parser if it helps others implement it). The codebase I used isn't really exactly the same, it's meant for merging in libretro's PrBoom (not PrBoom+). I'm just sharing it here in case someone else needs it in C (I think most chocolate derivatives wouldn't want to use C++ just for this, for example).

Edited by Ferk

Share this post


Link to post
1 hour ago, Ferk said:

I'm not sure how worth it such a rewrite would be. At that point why not just work on the Eternity engine which is also demo compatible and loosely similar to an extended PrBoom+ in C++?

 

Because I have my doubts that this would help solve the underlying problem. People use PrBoom mainly for playing Boom compatible mods, so anything that wants to replace PrBoom needs to be based on it.

 

If we could take Eternity's feature set (minus portals) for granted, a lot more would be possible and most of its port-exclusive definition stuff could easily be ported to other ports as well to have some unified standard.

 

I'm not saying that I plan to pick up work on this - maintaining two ports is simply too much - but if I was I'd go C++, because a) I'm far more comfortable with the language and b) it'd make it a lot easier to borrow code from GZDoom.

 

 

 

Share this post


Link to post
Posted (edited)

Wouldn't it be wiser to just make a version of PrBoom+ that is merely a "reference implementation" for UMAPINFO and leave it at that? (at least until other engines do catch up on the UMAPINFO support). No further maintenance other than maybe getting it to compile and run well once the  UMAPINFO standard implementation is stable and works as documented.

 

I get that C++ would be more comfortable, but I feel like changing the code too much would not help the underlying problem either. And I think the engines that are most likely to be reluctant to implement support for this would be in C, so if they see that the only reference implementation is all refactored into C++ classes, that might not help.

Edited by Ferk

Share this post


Link to post

The holy grail would be getting UMAPINFO into PrBoom-Plus proper (without doing a full fork), and for that it's gotta be C.

 

Either way, the feature definitely needs a champion, 'cause Graf is busy (and so am I, before anyone tells me to DIY :P ) and entryway is a bit reclusive.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×