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

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 :)

Share this post


Link to post

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 by Altazimuth
I only spot grammatical errors after I finish posts

Posted (edited)

Share this post


Link to post

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.

 

Share this post


Link to post

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 by Altazimuth

Posted (edited)

Share this post


Link to post

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.)

 

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

@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. .

Share this post


Link to post

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.

Share this post


Link to post
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.

 

Share this post


Link to post
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).

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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.

 

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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.

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