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

[Gez]

2 minutes ago, kb1 said:

I don't understand what this effect renders. You can supply different skies in the same map, ala MBF, so it should be definable. But, what is the effect supposed to render?

It's not a question of which sky is used. It's, well, I best use a screenshot.

 

So, just like the image on the wiki article for sky hack: highlighted in blue are sky flats; highlighted in yellow is a placeholder texture that's not displayed (appreciate the wit of the Midway employees who made sure that it would be very noticeable if it were accidentally visible in-game). You can recreate this structure in PC Doom, and see what happens: the sky hack makes the "I suck at making maps" textures disappear into the sky, and you don't see the stuff that is behind the sky, namely the non-sky ceiling and the top of the walls.

 

However, how does it look in-game? Like this:

The sky in Doom 64 does not hide geometry that is behind it, and this is what allows to create these purely-visual 3D platforms. They're not really 3D, it's just that the stuff that is behind them gets drawn over them, you don't get geometry hiding behind "columns of sky". It's a clever trick.

[kb1]

That looks very cool. Forgive my mapping ignorance, but, can't PC Doom mapping have that same visual result, with more work? I can swear that I've seen that look a bunch of times in Doom? Is it that it's much easier to do in Doom64? I know sometimes you have to build invisible sectors around buildings outside, to get the sky to behave, but I don't yet understand it. (I've only begun dabbling in mapping) - I spend too much time coding :(

 

But what is it about those screens that differentiate it? I'm really wondering what it would take to get the renderer to do it. My poor mapping skills are inhibiting me - maybe I'll try to recreate the effect.

 

EDIT: Never mind - I looked in the Doom64 Tech Bible - the pods are part of the effect. That's cool. You know, this .PDF might help me generate some ideas for Boom+... heh heh.

[Bauul]

11 hours ago, Lollie said:

Wise words

Quoted for truth.  Thank you for expressing my exact thoughts in a much more cohesive way than I was able to!

 

All games have their own unique and idiosyncratic coding language, and Doom is certainly no exception.  When 99% of the code is unique to Doom anyway (does anything else use states, frames and actors in the same way?) is there really any benefit in standardising to non-Doom formats the 1% that isn't?

[Arctangent]

MUGEN doesn't use 'em exactly like Doom does, but it's still pretty similar principles. I imagine quite a few 2D fighting games are similar in that regard, because it's a pretty natural fit for the genre.

[Graf Zahl]

6 hours ago, Gez said:

It's not a question of which sky is used. It's, well, I best use a screenshot.

 

So, just like the image on the wiki article for sky hack: highlighted in blue are sky flats; highlighted in yellow is a placeholder texture that's not displayed (appreciate the wit of the Midway employees who made sure that it would be very noticeable if it were accidentally visible in-game). You can recreate this structure in PC Doom, and see what happens: the sky hack makes the "I suck at making maps" textures disappear into the sky, and you don't see the stuff that is behind the sky, namely the non-sky ceiling and the top of the walls.

 

However, how does it look in-game? Like this:

The sky in Doom 64 does not hide geometry that is behind it, and this is what allows to create these purely-visual 3D platforms. They're not really 3D, it's just that the stuff that is behind them gets drawn over them, you don't get geometry hiding behind "columns of sky". It's a clever trick.

 

Actually you can do that in GZDoom. If you give a sector the special type 89, no skies will be drawn on upper parts of two-sided linedefs. I once tried to port the first few maps of D64: The Absolution to work in GZDoom. That project was quickly abandoned due to the work involved but the sky hack special remained.

The caveat: This is basically unsupportable in the software renderer due to how it works.

 

[Graf Zahl]

8 hours ago, kb1 said:

This is a perfect opportunity to work together - all ports need a lot of the same stuff defined. You can't define things and states without also defining sounds. And, what I called "sound lists": You know, the PistolGuy/ShotGuy chase sounds which pull from their own list randomly.

As much as I'd like to, I fear that this is not really possible anymore. Eternity chose to go an entirely different route here as ZDoom. For example, in Eternity, Dehacked support is hard coded into the definitions, whereas in ZDoom it is an external mapping lump. Eternity also chose to create a 1:1 mapping of sound lumps to logical sounds, whereas in ZDoom many physical sounds got multiple logical mappings, e.g. dsposact is mapped to 'grunt/active', 'shotguy/active', 'fatso/active' and 'chainguy/active', while Eternity just named it 'posact' and used the same logical definition for everything.

 

And ZDoom's player sound are a story all of their own. This was done for skin support but today is just legacy baggage in the sound system. But for obvious reasons the feature needs to be kept.

 

All these differences make it very hard to define a common SNDINFO format, and similar problems exist in other parts as well.

 

 

8 hours ago, kb1 said:

 

 

 

For demo support to work with modding, those must be defined in the right order. Of course, there's many datasets. The Boom SWITCHES/ANIMATED format really sucks. ZDoom made it pure text, right?

ANIMDEFS is inherited from Hexen, but had been extended for flexibility. For example in Hexen, animation frames were specified by index from the base texture, but in ZDoom you also can use texture names here so order in the mod is not important.

SWITCHES/ANIMATED was a typical 90's brainfart, but if you look closer, lots of Boom's 'cool' stuff were poorly thought through cheap shots. The sector transfer type 242 has completely stupid semantics, the friction was done with a really bad thinker algorithm, the accelerated scrollers are a pain in the ass of unimaginable proportions and I'm sure I forgot some stuff in that list.

 

ZDoom once also had such binary formats that had to be compiled, btw, that were DEHSUPP and XLAT with the compilers being part of the actual project but separate executables. I integrated both compilers into the main EXE later, because for XLAT I actually had a mod that needed to do changes here (my Caverns of Darkness patch) and when I had to extend the feature set of DEHSUPP it would have exploded the binary format, so I just took the parser, put it into ZDoom itself and dumped the crap.

[Lollie]

On 5/6/2017 at 4:17 PM, Bauul said:

Quoted for truth.  Thank you for expressing my exact thoughts in a much more cohesive way than I was able to!

 

All games have their own unique and idiosyncratic coding language, and Doom is certainly no exception.  When 99% of the code is unique to Doom anyway (does anything else use states, frames and actors in the same way?) is there really any benefit in standardising to non-Doom formats the 1% that isn't?

Yeah! I wanted to touch on that point of discussion, but it felt kind of snarky at the time. Really though, if you're making new content for Doom: Surprise, it's already Doom-specific by nature! What difference does it make whether Doom-specific formats are used or not? You're going to be learning Doom-specific syntax anyway. It's a non-issue.

 

On 5/6/2017 at 0:28 PM, kb1 said:

But what is it about those screens that differentiate it? I'm really wondering what it would take to get the renderer to do it. My poor mapping skills are inhibiting me - maybe I'll try to recreate the effect.

 

EDIT: Never mind - I looked in the Doom64 Tech Bible - the pods are part of the effect. That's cool. You know, this .PDF might help me generate some ideas for Boom+... heh heh.

It sounds like you figured it out, but yes, the effect apparently is that much easier to produce in Doom 64. Lucky bastards. I've spoilered a quick breakdown & attached a wad demonstrating what happens in PC Doom (in this case, Crispy Doom). What's interesting is that Doom does render F_SKY into the background layer just like Doom 64 does, allowing hidden detail to show through, but it's the upper walls of the "floating" sectors that cause trouble.

 

FloatingCeiling.zip

 

Spoiler

 

Anyway! I appreciate knowing that this would need to be supported in renderers before it could be considered as a future feature, I kinda expected as much.

 

On 5/6/2017 at 9:38 AM, kb1 said:

And, yes, some of the linedef ideas are possible. Wesley has been looking at designing a system that, frankly, I don't yet understand (I need time to study it further), but if I read it correctly, it concerns additive effects using multiple linedef types.

Additive effects sounds like a really nice feature, if that's really the case. Is this the ability to define multiple effects to a single line, or the ability to add effects to an existing line/sector during gameplay? (or both?)

Edited May 7, 2017 by Lollie : Updated WAD + images to take advantage of GZDoom

[scifista42]

3 hours ago, Bauul said:

When 99% of the code is unique to Doom anyway (does anything else use states, frames and actors in the same way?)

Names of the features, definition formats, and levels of moddability vary, but the concepts of states, frames and actors are commonly used in game AI of all kinds of games.

[Gez]

2 hours ago, Graf Zahl said:

Actually you can do that in GZDoom. If you give a sector the special type 89, no skies will be drawn on upper parts of two-sided linedefs.

That's the very first time I hear about that. It's not documented anywhere AFAIK.

[Linguica]

7 hours ago, Lollie said:

it's the upper walls of the "floating" sectors that cause trouble.

Yes. For all the Doom engine's bugs and glitches and shortcomings, there is one thing that is bulletproof as far as I can tell - the segs drawing code is VERY strict about cutting off the available drawing area for future segs as it goes along. When the game draws a seg with an upper texture, you will NOT be able to draw another seg above it, and when it draws a lower texture, the engine can NOT then draw another seg below it, no matter how clever you are trying to be.

 

"So why not mess with the BSP tree to change the seg draw ordering to draw the further ones first and then the closer ones below them?" Perhaps, but that way lies madness.

[printz]

Well, any madness can be sanitized through programming.

[Graf Zahl]

 

10 minutes ago, printz said:

Well, any madness can be sanitized through programming.

[citation needed]

 

Sorry, you will have to prove that. So far any code I have seen that tried to sanitize madness through programming ended up even more insane than what it tried to address.

 

[Gez]

I see a couple of possible approaches but they'd be very hacky.

[printz]

1 hour ago, Graf Zahl said:

 

[citation needed]

 

Sorry, you will have to prove that. So far any code I have seen that tried to sanitize madness through programming ended up even more insane than what it tried to address.

 

I'm assuming Linguica was talking as a user who hand-modifies the BSP tree. What programming can do is transfer the madness from the user (who has to do it every time) to the code (which is written once).

[Graf Zahl]

10 minutes ago, printz said:

I'm assuming Linguica was talking as a user who hand-modifies the BSP tree. What programming can do is transfer the madness from the user (who has to do it every time) to the code (which is written once).

Like I said: The result would be even more insane: Instrad if the odd map out it'd become a regular occurence and making everybody's life harder who is working at Doom ports.

 

[wesleyjohnson]

I looks like today the Doomworld reply box is going to work.  Thursday all I could get was a thin grey line.

I have but a few minutes to copy 4 more pages of this discussion for later reading on my machine, because the owner of this machine has appeared and is harassing me for being on their machine, again.  So I do not know what has been said yet.

 

INI:  Is that not a old Windows format, and you know I work in Linux.  Nothing about INI is appealing.  Making games fast and compact means working in game custom formats for everything.   Standard non-gaming Libraries may be your thing, but requiring such things for most of us will be like dragging an anchor.  The standard libraries that I can see as being practical are those for PNG format, but that really is too slow too, so it requires some caching.

 

I spend a night reading the EDF format.  Was impressed how it covered so many things, up to a point, and then the features got really EE specific.  No format should expose implementation decisions to the end-user.  I don't care if the endif() is implemented as a function, the end-user should only see it as syntax endif, and all references to IF be implemented as functions should be removed entirely.

 

The EE specific stuff in EDF just won't work for other ports.  The flags2 and flags3 will have different bits than EE has.

 

DECORATE, I think, was implemented in DoomLegacy2, which is promising.  It is also compact.

 

I am on the second week of trying to drop MBF BOUNCES, TOUCHY, and FRIEND flags into DoomLegacy   At first it was only a few annoying conflicts, but now it has broken out into a totally square peg round hole kind of problem.   Ideas that someone else's code is going to drop in to some other port is really not reality.  It has become dependent upon several other port decisions that DoomLegacy does not implement, making the effort snowball into a hairball.

It may be able to play MBF maps, but cannot be demo compatible with MBF, won't even be close.

 

These ideas for new monsters and linedefs that I have been accumulating.

Some are simple like a new lamp type, so we have more of a choice.  Won't work to redefine an existing lamp type because I want to have 3 or 4 choices, and have the ability to customize the OpenGL drawing based on their characterisics.  The tech lights seem to be laboratory stuff, which should make them behave differently in OpenGL lighting than a real outdoor lamplight, or a wall light.

 

The more complicated new objects and linedefs have radically new capabilities. There are internal interacting messages and states which do not have any existing support.  I might be able to make fragglescript come close, but the point of making them a real object is so that any mapper could drop them in like any other boss monster.   These boss monsters have new abilities, like having minions that they can control and command.  If the boss is attacked it can summon its fighter minions, and when it is really hurt it summons all it minions to defend itself.

I am not sure if I could even implement the security system objects in DECORATE, as their states are triggered by other objects that detect the proximity of the player.

[Xaser]

15 hours ago, Gez said:

That's the very first time I hear about that. It's not documented anywhere AFAIK.

Oh wow -- same here. This is fantastic. O_O

 

brb time to make a zillion gzdoom maps that [ab]use this.

 

[since the nested quote went away: referring to sector type 89 in gzdoom being the d64 skyhack]

[Hell Theatre]

9 hours ago, wesleyjohnson said:

I spend a night reading the EDF format.  Was impressed how it covered so many things, up to a point, and then the features got really EE specific.  No format should expose implementation decisions to the end-user.  I don't care if the endif() is implemented as a function, the end-user should only see it as syntax endif, and all references to IF be implemented as functions should be removed entirely.

 

The EE specific stuff in EDF just won't work for other ports.  The flags2 and flags3 will have different bits than EE has.

 

So true.

 

Ironically this goes for all ports that tried to build a  'Let's define everything through universal magic' format, i.e. Doomsday's DED, EDGE's DDF and Eternity's EDF.

They all contain good ideas, do an ok job at exposing the engine's innards - but in the end are complicated, unwieldy clunkers that all fell into the same trap of making the defined data parsing friendly, not modding friendly, by lacking a crucial degree of abstraction in some departments And because these formats are the foundation on which the engines work, they are non-negotiable.

 

Funny that ZDoom with its multitude of different different lumps, each with its own syntax, that are all being parsed separately was the only one that had success gaining traction among mappers and modders. Although Doomsday is a relatively successful engine, we cannot consider DED a success, because - where's the mods?

 

I'm not sure what this should tell us, but one thing that's for sure is that the mappers should not really be bothered by engine internals if it can be avoided.

[Lollie]

On 5/6/2017 at 6:14 PM, Graf Zahl said:

 

Actually you can do that in GZDoom. If you give a sector the special type 89, no skies will be drawn on upper parts of two-sided linedefs. I once tried to port the first few maps of D64: The Absolution to work in GZDoom. That project was quickly abandoned due to the work involved but the sky hack special remained.

The caveat: This is basically unsupportable in the software renderer due to how it works.

 

I ended up testing this real quick with the WAD I posted, and sure enough, Special 89 works in GZDoom with the Hardware renderer. It also adds a -10 damaging effect to the sectors, which I assume is the price we must pay for playing God with rendering tricks.

 

edit: vvv Exactly what happened. Good to know, Graf. Funny how that worked out.

Edited May 7, 2017 by Lollie

[Graf Zahl]

49 minutes ago, Lollie said:

I ended up testing this real quick with the WAD I posted, and sure enough, Special 89 works in GZDoom with the Hardware renderer. It also adds a -10 damaging effect to the sectors, which I assume is the price we must pay for playing God with rendering tricks.

 

 

I assume you used Doom format, not Hexen format. In that case it works differently, because 89 gets decomposed into Boom's sector damage flag (64) and sector special 25, which is actually undefined.

 

If you want to use this in Doom format you'll have to define a special mapping through a special translation lump.

 

[Quasar]

How about we jump right off this attacking EDF train. EDF is not more complicated than the menagerie of different syntaxed ZDoom lumps so, this is extremely hypocritical bullshit to be coming from anybody who uses that port.

[Gez]

EDF is cool, on some points better than DECORATE or ZScript (delta structures), though wesley's point about flags2 and flags3 is valid; it'd be better if the modder didn't have to worry about which flag goes where. Just parse the user-side name of the flag and let the parser sort it out.

 

[printz]

Or just use cflags, which aggregates all flags together.

[wesleyjohnson]

Reply to topic is not working today, so have to type this into a tiny box with the style sheets turned off, so it is going to be very rough. Was editing a wad make by Jon. Got to the final bit of connecting the walkover trigger to the 2 level elevator, and then discovered that there was no linedef that would work. The kind problems like this that arise at 2 AM is what the TRIG_TAG system addresses. You can connect two linedefs to make it work, thus keeping it from becoming a 4 AM problem. There would probably only be 1 or 2 linedefs on a level map that needed this so the extra linedefs are not a problem. Finishing the innovative bits of a level map the way you want, without having to redesign everything to work around missing linedefs is worth a few linedefs. Sector types are even more constrained. Been using objects to give properties to sectors. PHYSICAL_SKY: A linedef or object uses the associated sky sector to set the physical sky height for the entire level map. All sectors with sky ceilings then have a physical height of the global physical sky height. The individual sector height is still used to set the adjacent texture height defining buildings. The sectors used to set building heights no longer interfere with flying monsters physically or visually. All sky is drawn at the physical sky height. The gap between physical sky height and any adjacent building height would always be drawn with sky. It would also be possible to have the physical sky height and visual sky height as separate values, but I do not know what that would be used to do. Separate values would seem to make trouble. Even using thin sectors to define building heights still often creates flying monster occlusions. It is one of the things that takes considerable time to fix. It makes it much easier for all mappers.

[Gez]

3 hours ago, printz said:

Or just use cflags, which aggregates all flags together.

Good to know.

[rhinoduck]

Silly question: What does 'cflags' mean in this context?

[Quasar]

3 hours ago, rhinoduck said:

Silly question: What does 'cflags' mean in this context?

"Combined" flags. The original EDF only had the separate fields because I simply didn't think of having them combined or of a way to cleanly implement it yet at that point; the cflags field was added later and is preferred.

 

Most things people think are messy in EDF are probably legacy stuff like this. Such as, for example, the other ways of defining frames besides DECORATE. That stuff sticks around for backward compatibility, not because people should continue using it. Some of the stuff is documented as being considered deprecated.

[rhinoduck]

Thanks! I wasn't familiar with EDF at all, so I didn't even know that that's where I should have been looking.

For those who might be in the same situation as I was: cflags

[kb1]

On 5/6/2017 at 4:36 AM, Graf Zahl said:

As much as I'd like to, I fear that this is not really possible anymore. Eternity chose to go an entirely different route here as ZDoom. For example, in Eternity, Dehacked support is hard coded into the definitions, whereas in ZDoom it is an external mapping lump. Eternity also chose to create a 1:1 mapping of sound lumps to logical sounds, whereas in ZDoom many physical sounds got multiple logical mappings, e.g. dsposact is mapped to 'grunt/active', 'shotguy/active', 'fatso/active' and 'chainguy/active', while Eternity just named it 'posact' and used the same logical definition for everything.

 

And ZDoom's player sound are a story all of their own. This was done for skin support but today is just legacy baggage in the sound system. But for obvious reasons the feature needs to be kept.

 

All these differences make it very hard to define a common SNDINFO format, and similar problems exist in other parts as well.

 

 

ANIMDEFS is inherited from Hexen, but had been extended for flexibility. For example in Hexen, animation frames were specified by index from the base texture, but in ZDoom you also can use texture names here so order in the mod is not important.

SWITCHES/ANIMATED was a typical 90's brainfart, but if you look closer, lots of Boom's 'cool' stuff were poorly thought through cheap shots. The sector transfer type 242 has completely stupid semantics, the friction was done with a really bad thinker algorithm, the accelerated scrollers are a pain in the ass of unimaginable proportions and I'm sure I forgot some stuff in that list.

 

ZDoom once also had such binary formats that had to be compiled, btw, that were DEHSUPP and XLAT with the compilers being part of the actual project but separate executables. I integrated both compilers into the main EXE later, because for XLAT I actually had a mod that needed to do changes here (my Caverns of Darkness patch) and when I had to extend the feature set of DEHSUPP it would have exploded the binary format, so I just took the parser, put it into ZDoom itself and dumped the crap.

I know ports define stuff differently - that's what I'm hoping to help standardize. But that's going to require conference between port devs to see if we can come together. I don't want to be in the middle mitigating each setting with each dev. That'll require hundreds of forum posts, full of bickering, etc. But, imagine if we enumerated all of the known types of settings, and how each port stores them, in one place. For example, sounds:

 

Sounds

• ZDoom: thing.activesound = thing_name/action, like 'psitolguy/active';
• Eternity: thing.activesound = sound_name, like 'posact1';
• KBDoom: thing.activesound = sound_name, or sound_list_name, like 'posact1', or 'posact_list';
• PRBoom: vanilla (sounds.h)

Something like that, for each setting type, listed together, so we can all evaluate what we can do to synchronize. It may be true that some settings are too different to be able to standardize. But, please note that I am not trying to get ports to remove their own special ways of doing things. Instead, this would be a second, maybe more primitive way to just get the job done. Each port may need a translation layer,, to convert the 'universal' definition into each port's favorite way of defining things. But that complexity should be hidden from the mapper.

 

I guess what I'm asking for is for you to move more slowly, until I can catch-up. I'm asking you to hold off on implementing your streamlined settings stuff a bit, so I can talk to the other devs, analyze how each port does things, and see if we can agree to some form of standardization, for at least for a large portion of the definition types. But, it's ok if you can't wait - I don't want to hold you back. So, if you can think of some areas which should be easy for cross-port compat., please let me know, if you get a chance.

 

Everyone does it a bit different, and every dev is proud of his/her own way of doing things - that's where most of the resistance comes from. I'm the same way. Because of this, I think the best course of action is to continue allowing each dev to do things their own way, but develop an add-on method that is standard. This way, all existing WADs keep working, and all ports can keep their superior ways of doing things. It means that ports will have some more code, but not that much. It can be done fairly cleanly, and, once it's done, additions to the standard are much easier to share.

 

It *is* possible, but like all things good, it'll take some upfront research, and some work to implement in various ports. I am motivated, because I can imagine the awesome new possibilities.

 

On 5/6/2017 at 5:10 AM, Lollie said:

It sounds like you figured it out, but yes, the effect apparently is that much easier to produce in Doom 64. Lucky bastards. I've spoilered a quick breakdown & attached a wad demonstrating what happens in PC Doom (in this case, Crispy Doom). What's interesting is that Doom does render F_SKY into the background layer just like Doom 64 does, allowing hidden detail to show through, but it's the upper walls of the "floating" sectors that cause trouble.

 

FloatingCeiling.zip

 

  Hide contents

 

Anyway! I appreciate knowing that this would need to be supported in renderers before it could be considered as a future feature, I kinda expected as much.

 

Additive effects sounds like a really nice feature, if that's really the case. Is this the ability to define multiple effects to a single line, or the ability to add effects to an existing line/sector during gameplay? (or both?)

Thanks to you and Gez for going out of your way to explain this!

 

On 5/6/2017 at 0:48 PM, Linguica said:

Yes. For all the Doom engine's bugs and glitches and shortcomings, there is one thing that is bulletproof as far as I can tell - the segs drawing code is VERY strict about cutting off the available drawing area for future segs as it goes along. When the game draws a seg with an upper texture, you will NOT be able to draw another seg above it, and when it draws a lower texture, the engine can NOT then draw another seg below it, no matter how clever you are trying to be.

 

"So why not mess with the BSP tree to change the seg draw ordering to draw the further ones first and then the closer ones below them?" Perhaps, but that way lies madness.

That's the secret to how Doom gets its high frame rates: avoiding overdraw. I do think there's probably an easy way to do the effect, without disturbing the normal logic. Maybe, by getting it to consider the sky first, thereby preventing the upper to draw. Hopefully it's simple...  The nice thing is that we now have a nice test map to play with, thanks to Lollie.

 

On 5/6/2017 at 5:56 PM, wesleyjohnson said:

I looks like today the Doomworld reply box is going to work...

...(INI format sucks)...
...(EDF stuff)...

 

DECORATE, I think, was implemented in DoomLegacy2, which is promising.  It is also compact.

Do you plan to bring it over to your port? I think that'd be a step in the right direction!

 

On 5/6/2017 at 5:56 PM, wesleyjohnson said:

I am on the second week of trying to drop MBF BOUNCES, TOUCHY, and FRIEND flags into DoomLegacy   At first it was only a few annoying conflicts, but now it has broken out into a totally square peg round hole kind of problem.   Ideas that someone else's code is going to drop in to some other port is really not reality.  It has become dependent upon several other port decisions that DoomLegacy does not implement, making the effort snowball into a hairball.

It may be able to play MBF maps, but cannot be demo compatible with MBF, won't even be close.

MBF does go a bit deeper than Boom. But I don't really believe that there's no way Legacy can support MBF or the new standard. You just have to study its changes a bit more, and make them fit. I am hoping, one day, to be able to point out ALL changes - all deviations from Vanilla, imposed on the source. I definitely will, in my source, even though all the comments are going to blow up the size of the files. But, with a document like that, integration of Boom, MBF, and the standard, into a port should become a lot easier.

 

On 5/6/2017 at 5:56 PM, wesleyjohnson said:

These ideas for new monsters and linedefs that I have been accumulating.

Some are simple like a new lamp type, so we have more of a choice.  Won't work to redefine an existing lamp type because I want to have 3 or 4 choices, and have the ability to customize the OpenGL drawing based on their characterisics.  The tech lights seem to be laboratory stuff, which should make them behave differently in OpenGL lighting than a real outdoor lamplight, or a wall light.

 

The more complicated new objects and linedefs have radically new capabilities. There are internal interacting messages and states which do not have any existing support.  I might be able to make fragglescript come close, but the point of making them a real object is so that any mapper could drop them in like any other boss monster.   These boss monsters have new abilities, like having minions that they can control and command.  If the boss is attacked it can summon its fighter minions, and when it is really hurt it summons all it minions to defend itself.

I am not sure if I could even implement the security system objects in DECORATE, as their states are triggered by other objects that detect the proximity of the player.

More on getting MBF to work: MBF has friendly monsters. This is the predecessor to team support. With team support, new game modes become possible. And, with team support, you'd be able to set up your minions to be on the same team as the boss monster with a new codepointer. This could be built "generically" if your code was a direct descendant of MBF friendly monsters. Adopting this "MBF+ standard" mindset requires some prioritization, where first you try the built in stuff. If that absolutely cannot work, you consider adding a new codepointer, but think of how to build it to avoid hard-coded values, and so that it can be useful in other contexts. Only when you've exhausted those options should you consider a scripted design. Note: These are rules for the port dev. The mapper cannot add codepointers, and therefore must use built-in functions, or scripting.

 

The point I'm trying to make is that, the actions you describe could be added in a way that was cross-port-friendly, if you define a useful codepointer, and that those effects are a natural extension of MBF. I'd suggest getting MBF to work, even if you temporarily break Legacy stuff. Once MBF works, the Legacy stuff can be added back in a compliant way. If you don't get MBF working, your port will deviate more and more from the standard, making it progressively more difficult to load non-Legacy maps. Wouldn't it be nice if your custom monsters were not as custom as they used to be?

 

On 5/7/2017 at 9:57 AM, Quasar said:

How about we jump right off this attacking EDF train. EDF is not more complicated than the menagerie of different syntaxed ZDoom lumps so, this is extremely hypocritical bullshit to be coming from anybody who uses that port.

Agreed. Quasar, what's the best place to find the latest documentation for EDF? I know you've put a lot of effort into it, and I want to understand what benefits and/or limitations it imposes, and, essentially what it can do.

[Graf Zahl]

11 hours ago, kb1 said:

I know ports define stuff differently - that's what I'm hoping to help standardize. But that's going to require conference between port devs to see if we can come together. I don't want to be in the middle mitigating each setting with each dev. That'll require hundreds of forum posts, full of bickering, etc. But, imagine if we enumerated all of the known types of settings, and how each port stores them, in one place. For example, sounds:

 

Sounds

• ZDoom: thing.activesound = thing_name/action, like 'psitolguy/active';
• Eternity: thing.activesound = sound_name, like 'posact1';
• KBDoom: thing.activesound = sound_name, or sound_list_name, like 'posact1', or 'posact_list';
• PRBoom: vanilla (sounds.h)

 

Ultimately that part is just names. The basic feature is the same, it's merely the different naming conventions. If we had a common definition format this part can be worked out to everybody's satisfaction with no big problems, all that needs to be done is agree on a set of common names for the sounds.

 

 

 

11 hours ago, kb1 said:

Something like that, for each setting type, listed together, so we can all evaluate what we can do to synchronize. It may be true that some settings are too different to be able to standardize. But, please note that I am not trying to get ports to remove their own special ways of doing things. Instead, this would be a second, maybe more primitive way to just get the job done. Each port may need a translation layer,, to convert the 'universal' definition into each port's favorite way of defining things. But that complexity should be hidden from the mapper.

 

Agreed here. I think for a basic definition format the sounds are the only relevant resource and this can certainly be handled.

 

 

11 hours ago, kb1 said:

 

I guess what I'm asking for is for you to move more slowly, until I can catch-up. I'm asking you to hold off on implementing your streamlined settings stuff a bit, so I can talk to the other devs, analyze how each port does things, and see if we can agree to some form of standardization, for at least for a large portion of the definition types. But, it's ok if you can't wait - I don't want to hold you back. So, if you can think of some areas which should be easy for cross-port compat., please let me know, if you get a chance.

 

No problem. I am still working on reformatting the UMAPINFO to use curly syntax, so I won't touch other things for the time being.

 

 

 

 

11 hours ago, kb1 said:

MBF does go a bit deeper than Boom. But I don't really believe that there's no way Legacy can support MBF or the new standard. You just have to study its changes a bit more, and make them fit. I am hoping, one day, to be able to point out ALL changes - all deviations from Vanilla, imposed on the source. I definitely will, in my source, even though all the comments are going to blow up the size of the files. But, with a document like that, integration of Boom, MBF, and the standard, into a port should become a lot easier.

 

The thing is that internally Legacy and MBF are very different, and the features wesleyjohnson spoke about are among the more involved stuff. The bouncing code is, sorry to say that, quite messed up, the TOUCHY flag should be no problem, but friendly monsters will require a LOT of work. There's a reason that ZDoom never implemented this fully, and mostly stuck with Strife's base implementation. I'd love to but it requires quite a bit of heavy refactoring of some data - and Legacy is mostly in the exact same situation.

 

 

11 hours ago, kb1 said:

 

More on getting MBF to work: MBF has friendly monsters. This is the predecessor to team support. With team support, new game modes become possible. And, with team support, you'd be able to set up your minions to be on the same team as the boss monster with a new codepointer. This could be built "generically" if your code was a direct descendant of MBF friendly monsters. Adopting this "MBF+ standard" mindset requires some prioritization, where first you try the built in stuff. If that absolutely cannot work, you consider adding a new codepointer, but think of how to build it to avoid hard-coded values, and so that it can be useful in other contexts. Only when you've exhausted those options should you consider a scripted design. Note: These are rules for the port dev. The mapper cannot add codepointers, and therefore must use built-in functions, or scripting.

 

I'll be honest here: If you are out to have friendly monsters, but do not really need all of MBF's bells'n whistles, it's probably easier to build upon ZDoom. It does not have the separate thinker lists, unlike MBF it already features association with a specific player and other team related features. MBF's code was very much geared towards dog support (hence the port's name!)