Defining a new enhanced source port standard (Boom+/MBF+)

[kb1]

On 7/29/2017 at 1:10 PM, Graf Zahl said:

 

The main problem here is that it requires some change to the renderer. It's hard to say if that's a good idea as there's people among the devs which wouldn't dare touch this part of the source code.

 

Wouldn't these bleed downward into the floor forever with the software renderer (without a new form of clipping)?

 

On 7/29/2017 at 2:18 PM, printz said:

Keep in mind the only reason certain Doom 1 species don't fight is because they don't deal projectile damage to each other in the first place. You'll also have to specify whether friendly fire is allowed or not, not just the retaliation behaviour — which also is a valid criterion (see the archviles and the Heretic boss monsters).

Yes, these flags and more must be handled *somehow* (hard-coded, or as separate flags) just for vanilla behavior. As you know, printz, thing flags are so different, port-to-port, that a feature like this must wait until full-blown thing definitions, where flags can be used by name. Then, we just need to standardize the names :)

[Altazimuth]

In the UMAPINFO thread (posting here as it's the correct place to do so):

1 hour ago, Graf Zahl said:

If you fork, use the UDMF-only branch. The master contains some preliminary work for actor definitions which are probably not wanted for this.

How preliminary are we talking here? Like are you starting to define language at all? This was one of those real sticking points, to the point that I'm surprised it's being acted upon so soon when there's smaller things to take stabs at. I thought the general agreement was to disagree for now and try and push any and all work on this to later on? I just see a scenario where somebody disagrees with the implementation due to lack of discussion, then are painted as unreasonable obstacles to progress due to this.

 

This is fine if it's just like, starting to add stuff that will later on allow for use of a content definition language for this (like how weaponinfo_t works in non weapons-branch Eternity).

Edited August 3, 2017 by Altazimuth : I only spot grammatical errors after I finish posts

[Graf Zahl]

I just think it's better if the UDMF-stuff remains clear of the actor definition stuff in case it gets forked by someone else.

The main problem is that there are some changes to turn hardcoded stuff into flags which are not tested yet.

 

[Altazimuth]

My main concern here hasn't been addressed. How far along is the actor definition, in relatively objective terms? What capabilities are planned for the initial phase, if any?

Edited August 3, 2017 by Altazimuth

[Graf Zahl]

Right now there is no working parser. The capabilities are merely the existing vanilla properties plus a few generalizations of hard coded stuff, i.e. most of the specific changes for MT_* constants in the play code have been changed to flags and in a few cases where actual values were involved to new properties.

 

In other words: nothing fancy. All the new stuff was mainly done so that inheriting can be done by just copying the parent's mobjinfo and that those behavioral traits be preserved (like the instant target switch of the Arch Vile or the special melee handling of the Revenant, and similar things.)

 

[kb1]

6 hours ago, Graf Zahl said:

Right now there is no working parser. The capabilities are merely the existing vanilla properties plus a few generalizations of hard coded stuff, i.e. most of the specific changes for MT_* constants in the play code have been changed to flags and in a few cases where actual values were involved to new properties.

 

In other words: nothing fancy. All the new stuff was mainly done so that inheriting can be done by just copying the parent's mobjinfo and that those behavioral traits be preserved (like the instant target switch of the Arch Vile or the special melee handling of the Revenant, and similar things.)

 

Cool that you've gotten this far with it. The bulk of thing defs are not fancy: we're just moving the hard-coded data into user-changable space. The biggest thing right now, I think, is casting into stone the exact syntax: What is needed, what is optional, what is allowed, etc. The "fancy" stuff is the action function pointers, and how arguments are passed to them, right? There's a lot of room for ideas and improvements here.

[kb1]

7 hours ago, Altazimuth said:

In the UMAPINFO thread (posting here as it's the correct place to do so):

How preliminary are we talking here? Like are you starting to define language at all? This was one of those real sticking points, to the point that I'm surprised it's being acted upon so soon when there's smaller things to take stabs at. I thought the general agreement was to disagree for now and try and push any and all work on this to later on? I just see a scenario where somebody disagrees with the implementation due to lack of discussion, then are painted as unreasonable obstacles to progress due to this.

Yep, it's that familiar forum "fly-by-the-seat-of-your-pants" "free-for-all" style argument that turns everything into chaos. This is precisely what I am hoping to avoid by creating a rough-draft in isolation, then presenting it as a whole, in a special forum where topics can be focused better, and a big picture approach can be presented. A more controlled,, more focused discussion where the ideas are numbered, and presented at the top, and discussed, tweaked, and addressed in a logical manner.

 

Some topics will be postponed when discussing the first spec, but an important topic is the creation of a timeline that encompasses this multi-phase approach, and where postponed topics will fit within this timeline. We can postpone difficult ideas, but we must have an idea where they fall within the proposed sequence, postponed or not.

[Coraline]

@Graf Zahl is the spec completed, or rather suitable for parsing? I would like to take a stab at writing a parser for EDGE. Does UMAPINFO rely on MAPINFO at all? 

 

Maybe I should start with MAPINFO and work my way up from there. .

[kb1]

My understanding is that UMAPINFO is stand-alone, and includes a suitable parser. The remaining unsolved issues are how it's going to work with complevels, and in general how it affects the complex demo sync structure present specifically in PrBoom+, and more generally in other ports. As far as the syntax, Graf has finished that. There's no reason you could not take a stab at dropping it into your port, with the understanding that a few changes may become important down the road.

[Graf Zahl]

7 hours ago, Coraline said:

@Graf Zahl is the spec completed, or rather suitable for parsing? I would like to take a stab at writing a parser for EDGE. Does UMAPINFO rely on MAPINFO at all? 

 

Maybe I should start with MAPINFO and work my way up from there. .

Both are completely separate entities. Actually, UMAPINFO should be simpler to handle, because originally ZDoom's MAPINFO made one huge implementation mistake, i.e. tying intermission texts to clusters, which meant adding an entirely redundant structure into the mix. This made sense for hubs but not for independent maps.

UMAPINFO (and a very recent ZMAPINFO addition) fix this and allow assigning these messages to the actual map exits where they should have gone right from the start.

 

[kb1]

16 hours ago, Graf Zahl said:

Both are completely separate entities. Actually, UMAPINFO should be simpler to handle, because originally ZDoom's MAPINFO made one huge implementation mistake, i.e. tying intermission texts to clusters, which meant adding an entirely redundant structure into the mix. This made sense for hubs but not for independent maps.

UMAPINFO (and a very recent ZMAPINFO addition) fix this and allow assigning these messages to the actual map exits where they should have gone right from the start.

 

Nice. So, you do, in fact, feel like it's a finished spec, right? (Or, at least, ready for testing).

[printz]

No, it's not finished. It will be finished when its documentation becomes accurate. As of now, I saw mistakes which made me stop:

- wrong comment character (and no info on what is a comment)

- what is endgame=true supposed to do?

- bugs in the port branch by the umapinfo author.

[kb1]

1 hour ago, printz said:

No, it's not finished. It will be finished when its documentation becomes accurate. As of now, I saw mistakes which made me stop:

- wrong comment character (and no info on what is a comment)

- what is endgame=true supposed to do?

- bugs in the port branch by the umapinfo author.

Finished? Maybe not. But, testable...within PrBoom+? Within another PrBoom-ish port? Maybe.

 

I know I am in charge of putting together the specs for all things CDX (DEX?). But I am open to any assistance (and should not have implied that I wasn't earlier). I just wanted to make sure we eventually have something that is consistent and workable. And, that probably means PrBoom+ first, since its compatibility stuff requires the most stringent setup.

 

Can you shed any light on your list? Doesn't endgame=true specify that the port should not load another level? (shareware notice/bunny/cast call?) I haven't looked at the port in depth yet. Are there prevalent bugs to iron out? (I'm making my way to UMAPINFO.) printz, you may have looked at it more than anyone so far...I haven't heard of a lot of testing happening yet.

 

@Coraline I guess the best advice is to proceed cautiously, as there may be a few issues to clean up along the way. With any luck, I'll be able to provide exacting specs on UMAPINFO and much more, but that's going to be a while. Reporting any discovered shortcomings/bugs would help me out a lot, that's for sure.

[Graf Zahl]

Endgame=true should end the game. End of story. Whether it's broken in my current PrBoom repo is irrelevant to that. This is a bug that needs to be fixed when I find some time to debug it.

 

[printz]

3 hours ago, Graf Zahl said:

Endgame=true should end the game. End of story. Whether it's broken in my current PrBoom repo is irrelevant to that. This is a bug that needs to be fixed when I find some time to debug it.

 

Yeah but how? Unspecified, just end the game, using whatever the port finds easiest? Or should I examine the level name in a hard coded way and use the episode ending depending on whether it's E1Mx and so on? That feels hacky and redundant when we have more explicit means.

 

Eternity has the special from Hexen Teleport_EndGame. It's quite generic. When ran in Doom1, if the level has no special info, it will just say "YOU HAVE WON." in the story text and present the id credits. No episode context.

[Quasar]

5 hours ago, printz said:

Yeah but how? Unspecified, just end the game, using whatever the port finds easiest? Or should I examine the level name in a hard coded way and use the episode ending depending on whether it's E1Mx and so on? That feels hacky and redundant when we have more explicit means.

 

Eternity has the special from Hexen Teleport_EndGame. It's quite generic. When ran in Doom1, if the level has no special info, it will just say "YOU HAVE WON." in the story text and present the id credits. No episode context.

This is because Eternity requires you to fully specify end game properties for any level that doesn't normally have an end-of-game or end-of-episode situation that occurs after it. Those maps are considered to have defaults, but others do not. So some synthesis (like that default message) will occur if an end-game is requested without all the proper settings being made available through the mapinfo system.

[kb1]

KBDoom defines each exit too, as follows:

 

Doom:

Spoiler

mapsetup Doom.E1M8
{
  gamemission Doom
  episode 1
  mapnum 8
  mapname HUSTR_E1M8
  mapnameimage WILV07
  interpic WIMAP0
  music E1M8
  skytexture SKY1
  partime 30
  bossexittype E1M8
  finaleflags TEXT ENDPIC NOINTERMISSION NONEXTLEVEL
  endpic CREDIT
  endtext E1TEXT
  endflat FLOOR4_8
  endmusic Doom1_Victory
  worldmapx 135
  worldmapy 29
}

mapsetup Doom.E2M8
{
  gamemission Doom
  episode 2
  mapnum 8
  mapname HUSTR_E2M8
  mapnameimage WILV17
  interpic WIMAP1
  music E2M8
  skytexture SKY2
  partime 30
  bossexittype E2M8
  finaleflags TEXT ENDPIC NOINTERMISSION NONEXTLEVEL
  endpic VICTORY2
  endtext E2TEXT
  endflat SFLR6_1
  endmusic Doom1_Victory
  worldmapx 148
  worldmapy 140
}

mapsetup Doom.E3M8
{
  gamemission Doom
  episode 3
  mapnum 8
  mapname HUSTR_E3M8
  mapnameimage WILV27
  interpic WIMAP2
  music E3M8
  skytexture SKY3
  partime 30
  bossexittype E3M8
  finaleflags TEXT BUNNY NOINTERMISSION NONEXTLEVEL
  endtext E3TEXT
  endflat MFLR8_4
  endmusic Doom1_Victory
  worldmapx 140
  worldmapy 25
}

mapsetup Doom.E4M8
{
  gamemission Doom
  episode 4
  mapnum 8
  mapname HUSTR_E4M8
  mapnameimage WILV37
  interpic INTERPIC
  music E4M8
  skytexture SKY4
  bossexittype E4M8
  finaleflags TEXT ENDPIC NOINTERMISSION NONEXTLEVEL
  endpic ENDPIC
  endtext E4TEXT
  endflat MFLR8_3
  endmusic Doom1_Victory
}

 

 

Doom II:

Spoiler

mapsetup DoomII.MAP30
{
  gamemission Doom2
  episode 1
  mapnum 30
  mapname HUSTR_30
  mapnameimage CWILV29
  interpic INTERPIC
  music MAP30
  normalexitmapnum 31
  skytexture SKY3
  partime 180
  finaleflags TEXT CAST NOENTERING NONEXTLEVEL
  endflat RROCK17
  endtext C4TEXT
  endmusic Doom2_Victory
}

 

 

The relevant lines, of course, being "finaleflags", "endflat", "endtext", and "endmusic", each of which require flag name definitions, flat name lookup, a named string functionality, and named sounds. This tends to explain why some of this might be missing from UMAPINFO: For endgame functionality to be customizable, these additional concepts need to be handled in some fashion. Therefore, to include the endgame stuff in UMAPINFO as a standard, we will also need a compatible, standard way to define the texts, and, optionally the sounds (though you could get away with lumpname for sounds, but, if you're managing text scripts anyway...)

 

What all of this suggests is that the UMAPINFO parser should really be thought of as "The Parser", and should be built to be able to handle some various textual definitions, beginning with endgame strings (which easily expands to other strings), nice names for sound lookup, usable in a future ThingDef implementation.

 

Basically, Graf gave us everying that is possible, without worrying about this additional functionality. Therefore, it makes complete sense why the complete endgame setup is not currently present. He got the ball rolling, which has the nice effect of highlighting some of the additional requirements for the new "C_DEX" extensions. I would add 2 additional requirements to this parser, right off the bat:

 

1. If the parser could be made to handle arbitrary key name/value pairs, it could get used for a variety of things, for an efficient, clean solution.

2. I would add the ability to have multiple types of data within the same lump, by using a section identifier key at the top. For example:

SOUNDS
{
   sound lookups
}

TEXTS
{
  endgame, UI, and other strings
}

UMAPINFO
{
  the umapinfo data...
}

Optionally, if that header line is omitted, the name of the lump would be used instead. That way, you could have a UMAPINFO lump, separate from another TEXTS lump, for example, or you could have a SETTINGS lump, with "UMAPINFO" and "TEXTS" sections, which would do the same thing.

 

These suggestions will be part of the spec for Phase 1, because these types of lookups are an essential part of a compatibility standard, as they provide an easily-editable way to define the types of data that all ports use. In Vanilla, of course, this data was hard-coded. Unfortunately, many ports have already devised a solution. I am hoping that this will not create a huge burden on those ports, and I am open to suggestions. I would strongly advise a simple, powerful solution that supports the abilities I just described, as a bare minimum.

[Jon]

Is there any more progress (or enthusiasm) for this?

[Graf Zahl]

If there was any movement to actually create some specs and base implementation I'd be in immediately. But someone has to come forward and create a project to work on and use as a baseline. I'm afraid that my time is too short for this. I cannot handle two ports plus a full time programming job all at once.

[Misty]

It's depressing. I guess, mappers will be stucked in the old boom format as usual and rely on old methods. Well, if I was programmer I would try to do something, but now I'm not programmer, just a mapper and I  hope that someone will continue on this. 

[Jon]

3 hours ago, Graf Zahl said:

If there was any movement to actually create some specs and base implementation I'd be in immediately. But someone has to come forward and create a project to work on and use as a baseline. I'm afraid that my time is too short for this. I cannot handle two ports plus a full time programming job all at once.

I guess the closest thing we have to that publically is my proof-of-concept for how a draft spec could look at https://doomwiki.org/wiki/User:Jdowland/boom%2B%2B

 

but I'm wary to work on it any further because I don't want to appear to be doing a parallel effort to @kb1.

[Quasar]

16 hours ago, Jon said:

but I'm wary to work on it any further because I don't want to appear to be doing a parallel effort to @kb1.

I think after this length of time we should be moving on with the process independently. This is absolutely not something that should be getting carried on behind closed doors. He can either open up what he has for review by everybody or we can come up with something on our own.

[Spectre01]

Hey, can we get -longtics for -cl9? Thanks!

[Graf Zahl]

1 hour ago, Quasar said:

I think after this length of time we should be moving on with the process independently. This is absolutely not something that should be getting carried on behind closed doors. He can either open up what he has for review by everybody or we can come up with something on our own.

 

Agreed. This needs

 

a) to be an open discussion

 

and

 

b) require a spec document in some public place, preferably open to several trusted contributors for editing

 

and most importantly

 

c) there needs to be some baseline port that actually DEVELOPS the spec, once an item has been approved - because without this it all will be for nothing.

 

If it's all just talk the entire effort will become vaporware very quickly.

 

 

[Jon]

3 hours ago, Spectre01 said:

Hey, can we get -longtics for -cl9? Thanks!

 

I'm not sure that this is the right place for this request. It would mean importing the whole notion of compatibility levels into the spec, which is something it might be very hard to get multiple port authors to agree on. Perhaps you should request in the prboom+ thread (if you haven't already)? Or are you actually suggesting we should consider complevel standardisation as part of this?

 

4 hours ago, Quasar said:

I think after this length of time we should be moving on with the process independently. This is absolutely not something that should be getting carried on behind closed doors. He can either open up what he has for review by everybody or we can come up with something on our own.

 

 

OK.

2 hours ago, Graf Zahl said:

b) require a spec document in some public place, preferably open to several trusted contributors for editing

 

Would https://doomwiki.org/wiki/User:Jdowland/boom%2B%2B suffice? I think it works.

 

2 hours ago, Graf Zahl said:

c) there needs to be some baseline port that actually DEVELOPS the spec, once an item has been approved - because without this it all will be for nothing.

 

This is a good point and I don't have an answer for this just yet. The stuff I've focussed on so far already exists in most ports of concern (e.g. insta-death floor from strife). The elephant in the room is/was prboom+ and we don't know what @entryway's opinion is on the whole effort. I'm happy to continue to work on proof-of-concept implementations on top of prboom+'s codebase, but as you say, it would probably be for nothing if prboom+ isn't interested in adopting it.

 

Why don't we work on developing the spec a little bit until we have something that might be more attractive prospect for prboom+ and/or other ports? and project the idea of a realistic prospect and not just vaporware

[Graf Zahl]

I think the only way to go forward with PrBoom+ is to fork it, like I already did for UMAPINFO and work on that. With all due respect to entryway , I think the fact that he hasn't made a single public comment about UMAPINFO speaks volumes and if you check the PrBoom repo you'd notice that there isn't really any work being done anymore. I think if a fork reaches a stable state with its added features, all it needs is a bit of promotion (and a nice showcase mod) to supplant PrBoom+, if things do not change over there.

 

 

[Jon]

2 hours ago, Graf Zahl said:

I think the only way to go forward with PrBoom+ is to fork it, like I already did for UMAPINFO and work on that. With all due respect to entryway , I think the fact that he hasn't made a single public comment about UMAPINFO speaks volumes and if you check the PrBoom repo you'd notice that there isn't really any work being done anymore. I think if a fork reaches a stable state with its added features, all it needs is a bit of promotion (and a nice showcase mod) to supplant PrBoom+, if things do not change over there.

 

 

That's something I would consider further down the line (being seriously involved in a fork). There's a lot of arguments to be had about managing a prboom+ fork, not least whether to move it to C++ or not (and I know which side of the fence you are on there ;)). That would be a distraction from the spec at this early putative stage IMHO.

I'm planning to restructure/simplify the wiki page a bit more today to move things forward.

[kb1]

I am responding to 5 of the recent posts, cause I can't handle more than 5, and I think these 5 cover most of the discussion.

On 11/23/2017 at 6:02 AM, Jon said:

Is there any more progress (or enthusiasm) for this?

Tons of enthusiasm, a small amount of progress. I'm still swamped with 2 major projects that have to take priority over Doom stuff.

 

On 11/23/2017 at 6:18 AM, Graf Zahl said:

If there was any movement to actually create some specs and base implementation I'd be in immediately. But someone has to come forward and create a project to work on and use as a baseline. I'm afraid that my time is too short for this. I cannot handle two ports plus a full time programming job all at once.

Graf, I know you were a big part of these discussions, but I did not know that you were this enthusiastic and ready to move forward. That's both encouraging, and depressing: Encouraging for obvious reasons, and depressing, because I haven't been able to get to a point where I am ready to be as ready as you are.

 

On 11/23/2017 at 6:40 AM, Myst.Haruko said:

It's depressing. I guess, mappers will be stucked in the old boom format as usual and rely on old methods. Well, if I was programmer I would try to do something, but now I'm not programmer, just a mapper and I  hope that someone will continue on this. 

Please don't be depressed - it will happen, but it's going to take time.

 

On 11/23/2017 at 9:34 AM, Jon said:

I guess the closest thing we have to that publically is my proof-of-concept for how a draft spec could look at https://doomwiki.org/wiki/User:Jdowland/boom%2B%2B

 

but I'm wary to work on it any further because I don't want to appear to be doing a parallel effort to @kb1.

Jon, I appreciate that you don't want to step on my toes. Please see my response to Quasar below:

 

On 11/24/2017 at 2:02 AM, Quasar said:

I think after this length of time we should be moving on with the process independently. This is absolutely not something that should be getting carried on behind closed doors. He can either open up what he has for review by everybody or we can come up with something on our own.

It's been about 7 months since I started this thread. Last year, at work, I got derailed from my current project. I was asked to recover a massive database from a team of programmers that really messed things up. This was an absolute nightmare - I had to build a bunch of tools that used "fuzzy logic" to rebuild the data, column by column, record by record, table by table. At the end, it all worked. But it set me back about 15 months. Since then, I've been working day and night on my current project, all-the-while putting out current fires that have accumulated.

 

At home, I've been working on a major project for my Dad, which, of course, must also take priority.

 

You're supposed to work to live, not live to work..., right?

 

Anyway, I never intended for this to be a "closed door" project. The idea was that I'd type up a very rough first draft. Having one person do this is beneficial, as that one person can have a "whole project" world view, which would be difficult to communicate.

 

The rest of the idea was that, as soon as that rough draft was done, I'd submit it to everyone, making it an "open door" project.

 

So, that was the idea. The reality is that, yes, 7 months have gone by since the topic was created. I have been killing myself to try to get ahead of my responsibilities, and open up some serious time to devote to this project. That is what I've been striving for, and I still am. But, yes, it's taking longer than I wanted it to.

 

I am not against the idea of sharing everything I have so far, and starting without that first rough draft, in theory, anyway. But, I foresee a few problems going down that road. Here's why I wanted to do the first rough draft:

• I know that I know enough about Doom, and the compatibility issues, that I can do a competent job.
• I have a high-level vision of what systems need to be in place, to handle the current needs in an efficient, compatible way.
• The standard could be built a million different ways, and still be a good standard. But, there are far fewer ways to build a great standard - a standard that covers all of the little issues with grace. This is the biggest point: It is difficult to describe such an all-encompassing plan in a forum thread, without having the entire backbone written up in outline form in a first draft.

It doesn't have to be me - I am not looking for some special credit for being the architect. But I do believe there is a significant danger of using "design-by-committee" for the first draft. Traditionally, we have difficulty discussing even simple concepts, without a dozen people chiming in about how we should use file format X, or how we don't want to "become too ZDoom-y", or whatever. A full draft covers how using Format X allows 1 parser to handle 5 separate tasks. A full draft answers the question of how A is going to work alongside B and C.

 

If we all go off and separately build several pieces, and then discuss how to fit them together, they may not quite fit. We need a rough plan to start with, and that rough plan should be built with an understanding that all of the pieces must fit tightly. I want a specification that is lean, optimal, and efficient, as well as being logical and powerful.

 

That is what is required of the first draft, in my book. I want this spec to be exceptional. Not just to add features, but also to help clean up the problems that currently exist.

 

If you got this far, I have a request:

If you guys are willing to give me until the 2nd week of January 2018, I will present the first rough draft at that time, regardless of my other commitments. I don't like to shift around priorities like that, but I will: This spec is very important to me. I know that there are some people on DW that can do a great job on the spec. Regardless, I know that I will be disappointed if certain aspects of the plan aren't presented. And, let's face it: I'll be disappointed in myself if, after all this discussion, I cannot do my part by developing that first rough draft.

 

So, what do you say? 2nd week of January?

[kb1]

On 11/24/2017 at 7:44 AM, Graf Zahl said:

I think the only way to go forward with PrBoom+ is to fork it, like I already did for UMAPINFO and work on that. With all due respect to entryway , I think the fact that he hasn't made a single public comment about UMAPINFO speaks volumes and if you check the PrBoom repo you'd notice that there isn't really any work being done anymore. I think if a fork reaches a stable state with its added features, all it needs is a bit of promotion (and a nice showcase mod) to supplant PrBoom+, if things do not change over there.

 

 

Graf,

entryway gave me his blessing to fork PrBoom+. Specifically, I asked him about using PrBoom+ as a new SDL2 frame for KBDoom to live in. But, I also talked about this effort, and he was fine with it. I'm sure he doesn't mind, and not just me either. He said that he wanted to see what could become of PrBoom+. If you think about it, he basically accomplished what he wanted to do with PrBoom+: support the gameplay and demos of "dead" ports.

 

So, it makes a lot of sense for a PrBoom+ fork to adopt the new standard. In fact, it was my goal for this fork to be the flagship go-to port for the new standard.

[Graf Zahl]

Good to hear that. To be honest, I was somehow expecting something along those lines.

 

I think my UMAPINFO fork is a good point to start for this, right?

UMAPINFO will probably require a bit of fixing before being ready, though. At the end I just ran out of time to finish it, unfortunately. But this should be the first thing to do, considering that both Eternity and GZDoom have already adopted it.

 

(And as a note to myself, what absolutely should be there is a 'jump' flag. IIRC even PrBoom+ supports jumping as a feature, so being able to control this would come in handy in many cases.)