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

[kb1]

On 7/24/2017 at 6:17 PM, Coraline said:

Yeah, it's just "edge". No pronunciation difference. ^_^

 

And, I am always open to hearing constructive criticism regarding the port -- however, maybe this thread isn't the best place for it. And don't get me wrong, there's a ton of reasons it's not as popular as it once was, or maybe as popular as it can be. I also know there's major issues with it at the moment, but we are trying to work through it. We just take things one day at a time. ^_^

 

@Jon: Also, if the ladder type clashes I'll go ahead and push it farther back as to not conflict with more current trigger types. Not the first time EDGE's custom linetypes had to have been pushed back, so it's no big deal ^_^

@CoralineYou'll get it going. Don't worry about conflicts - they will all be resolved in time. I am interested in what linedef numbers your port currently uses, outside of the Doom/Boom numberspace.

[Quasar]

I've remained somewhat silent on this so far, but, here's my Giant Wish List of things I would be including into a "Boom-Plus" spec:

 

https://gist.github.com/haleyjd/1c906346f68e2046584751b886971d9d

 

These are editing concepts largely based on things that are available in other Doom engine games, many of which are things that Boom turned a total blind eye toward and could be enormously useful for mappers who don't want to go full-Hexen with their projects. Note these aren't necessarily suggestions that the implementations be exactly the same, but similar enough that ports that already implement this stuff won't have trouble adding new bindings to access such functionality in Doom-format maps.

[printz]

Any reason you posted that on gist.github? It requires me to sign in just to read it. I can post a copy on pastebin if you're fine with that so everyone can read it.

[Graf Zahl]

Most of those suggestions are reasonable but obviously too much of it suffers from deficiencies in the Doom map format.

I guess it'd be a better idea to implement the UDMF "Doom" namespace first so that the biggest issues (lack of tid, only one parameter to a line special) can be solved before inventing more crutches to handle them.

 

[printz]

If this means UDMF will replace the MBF format in PrBoom+, awesome. It may also mean GZDBBF will have to update its UDMF UI to be less GZDoom hard coded. I think you had planned for this when you designed the "doom" format more than a decade ago 😁

[Graf Zahl]

1 hour ago, printz said:

If this means UDMF will replace the MBF format in PrBoom+, awesome. It may also mean GZDBBF will have to update its UDMF UI to be less GZDoom hard coded. I think you had planned for this when you designed the "doom" format more than a decade ago 😁

 

The hope of the Doom format has always been that ports like PrBoom would adopt it. But what can you do if a port's maintainer has no interest in such features. I still have no good plan how to proceed here wth the branch I created for UMAPINFO. I'd really need a second developer to take care of it. Working on two ports at the same time is not going to work out.

 

Regarding editor support, GZDBBF seems to be in good hands, but unfortunately it appears to have inherited a lot of baggage from GZDB that's not easy to sort out and there's probably more pressing issues right now.

[Jon]

55 minutes ago, Graf Zahl said:

 

The hope of the Doom format has always been that ports like PrBoom would adopt it. But what can you do if a port's maintainer has no interest in such features. I still have no good plan how to proceed here wth the branch I created for UMAPINFO. I'd really need a second developer to take care of it. Working on two ports at the same time is not going to work out.

 

I've been basing my prototypes on your github fork of prboom2, and could take a look at UMAPINFO. Possibly.

 

I think I actually have commit access to the prboom svn, although I may have long since forgotten my password. Perhaps I could just merge this stuff, once ready, into prboom (not +) and really throw a cat amongst the pigeons :)

 

Have we had any response from @entryway at all on this effort?

 

 

[VGA]

Good to see that more and more people are realizing how much prboom+ has held Doom's modding innovation and source port innovation back.

[Graf Zahl]

3 hours ago, Jon said:

Have we had any response from @entryway at all on this effort?

 

 

The only thing I ever got was some PR right at the start to fix the autotools project.

 

[Quasar]

My idea was to keep to features that wouldn't be onerous to implement even given a port like Chocolate Doom to work off of as a base. Requiring UDMF is really raising the bar of entry to the standard quite a bit. Just the amount of overhaul it requires to the level loading mechanisms, the entire issue of the engine being limited to 32767 entities via use of shorts, lack of support for anything but the normal node format... that's a huge undertaking when you're working off something that's closer to the original source code than it is to EE or ZDoom already.

 

At some point we have to establish a target audience - how broadly is this intended to be adaptable?

[VGA]

It has to be reasonably easy to implement in prboom+ or a fork of it so that there is incentive for modders to use it. Then any other current or future boom-compatible ports will follow.

 

And it will be easy to implement in GZDoom and Eternity, that is a given because they already have support for more advanced features and the authors are expressing interest in this thread.

 

So the new standard will replace the "boom" standard. Which actually means "prboom" standard since no one tests in actual Boom.

[Jon]

I Agree. I think UDMF is too far. This is meant to be short of that, short of a proper scripting language; a useful litmus test might be to think of it as things which Boom/MBF "could" have included but didn't.

[Coraline]

On 7/25/2017 at 2:01 AM, Jon said:

[ But: if you could explain to me how the ladder types are supposed to work, that'd be great! I tried applying it to a linedef which was on a sector boundary with a floor height difference of 64; I couldn't find a way of "scaling" the wall in game, which is how I thought it would work. ]

@Jon sure thing! Here's a quick tutorial on that:

 

1) Make a platform in your map of a height of around 112. Give one of the lines an appropriate texture for a ladder.

2) Place a two-sided linedef on the map, just in front of the line with the ladder texture. Don't give it any textures so it stays invisible to the player. Make sure the line is two-sided and that it's not set to impassable or block player.

3) Give this line a type of 472, which corresponds to our pre-defined custom Ladder of 120 units high in Lines.ddf.

This is the code for the line (validated here):

[472] // EDGE Ladder, 120 units high
TYPE=WALK;
ACTIVATORS=PLAYER;
LADDER.HEIGHT=120;

Now, just press "JUMP" to start moving up the ladder.

Hope that works out - if you need any other assistance feel free to let me know.

 

23 hours ago, kb1 said:

@CoralineYou'll get it going. Don't worry about conflicts - they will all be resolved in time. I am interested in what linedef numbers your port currently uses, outside of the Doom/Boom numberspace.

@kb1: The 3DGEWiki has the current linetype list available here. These linetypes are the default that ship out with EDGE. Also of interest is that linetypes 600-799 are not hardcoded in that list. So there could be potential there. The HUB linetypes bring up the rear to occupy 800-825. Regarding the sudden skip from 600 into HUB linetypes... I don't remember why they ended up not occupying 600-725...I guess I could change that, and it would free up starting from 800^{^}..

 

If we could just bump the new linetypes much farther down the chain (I think I saw a thread Graf had mentioned about it) it'd be preferable. Maybe from ~900 on?

 

However, seeing as EDGE 2.1.0 (the next major version) has not even reached Release Candidate yet (sigh), there is still time for me to potentially change ALL of the conflicting linetype numbers and move them forward as to retain compatibility with other ports/standards. It would definitely give 3DGE modders enough of a heads up that default linetypes would be changing well before that version releases. I'm absolutely open to whatever the main authors of this think is best. I know nothing is set in stone yet, but I'm just saying that you guys have my support. =)

 

2 hours ago, Quasar said:

At some point we have to establish a target audience - how broadly is this intended to be adaptable?

 

On the issue of the namespace - I tend to agree with @Graf Zahl in just calling it "UDMF - Doom" and using UMAPINFO. Calling it "prboom" or something seems a bit strange, because in my eyes, it would just create more confusion (is PrBoom standard now? Assumes port is 100% Boom-compatible? But I'm not using PrBoom, I'm using Doom Legacy? and so on). But, @Quasar makes a very valid point in that other ports that don't support UDMF would give users the wrong idea. . .

 

However, if the overall goal is to define to a new standard that isn't necessarily an explicit part of UDMF, why not just call it "Doom - Modern"? I think that is the cleanest way to go here -- that way it's not nailed down to a port, there's no confusion, and "modern" is pretty easy to comprehend (but feel free to trade modern for any other synonym that might fit the bill). If it is planning on having a wide-adoption, calling it "Doom - Modern" might actually be distinguishable enough. I would be okay with calling it "Boom, format2", "prboom+" or whatever, but wouldn't ports require 100% Boom compatibility in order to really use that distinction?

 

At least, that namespace suggestion seems the least confusing for comprehension's sake. ^_^

But alas, I'm very rarely not confused. ;-) ^#ADHDLife

[EmotionalFelineinaMadstate]

I'm interested in seeing a new MBF/Boom.

[kb1]

@Quasar: Yay! Quasar's in, with a nice set of proposed additions! These look very good. You also had some lighting linedefs that took up a semi-large range of linedefs, but you said that it didn't include everything you wanted. Are you still wanting those, and can you specify what else you wanted to see?

I think I might need some help on some of the engine-specific ones, like the Strife, and more the Doom 64ish ones. If you don't mind, and can find the time, I'd like to spend some time writing up a list of questions for you, to help me understand exactly what you are describing. Finally, I wanted to ask: About the idea of providing a block of empty DeHacked slots and empty sound slots, is there a workaround that can allow this to be possible for Eternity? (You mentioned previously that it might conflict with EDF.)

 

I appreciate your carefulness in sticking to a 'generically implementable' feature set - that falls in line with my hopes exactly. You asked: "how broadly is this intended to be adaptable?". For now, any port with good Boom and MBF support should be able to implement the first few phases of the spec, anyway. The feature set must be kept simple, because, at this stage, I want the spec to be able to be easily adopted by any "enhanced" (read Boom/MBF) port.

 

Having said that, with the spec, I am also trying to pave the way for ports to rise to the occasion, so to speak, for more aggressive updating, like UDMF, Hexen w/ACS, and compatible Thing/frame/sound definitions. And, maybe more. As the Phase number gets higher, things become more optional. I am aware that some ports may never want to support Hexen or Heretic, for example. For that reason, later specs will be optional, and with careful planning, the omission of one phase will not prevent the adoption of another phase. We'll see if it can be done.

 

@Graf Zahl: I fully intend to provide a clear upgrade path towards Hexen and UDMF support, while, at the same time, providing the most possible support for new features in the original Doom format. And, yes, getting some of these to work in Doom format will require overloading existing structures. There are actually quite a lot of ways to get that extra data into the Doom map format, and some a lot uglier than others. I am hoping to find a middle ground. I think it is important to support the Doom map format to its fullest potential. Our mappers are brilliant, bright people who are capable of handling some deeper concepts, for the ability to have extra capabilities. And, when that's not enough, they will have to use a newer format. But, we are far from exhausting the possibilities of the original format.

Adding this type of capability might simply mean dropping in a new module. If we can provide this capability, why not? It's not going to be that ugly. A side-benefit is that we're getting ports to start to understand these new concepts, which will make the transition to Hexen or UDMF that much easier.

 

I don't want to throw Doom format, or its mappers under the bus. I think we have an obligation to take the Doom format as far as it can be taken. Wesley has brought up a lot of ways this can be done. I admit that I haven't spent enough time comprehending some of what he described, but, from what I have seen, there's a lot of potential left untouched.

 

But, this thread is not the place to decide on such things. I'll be sure to present some options in the spec, which we can hash over in depth, when the time comes :)

 

I do intend on getting UDMF support into my version of PrBoom+ and KBDoom.

 

@printz: Augment, not replace. There's lots of good Boom/MBF wads out there. I don't want to have to run them through some converter before playing them! UDMF support is intended, but, certainly not in Phase 1. It's too big, and it requires lots of preliminary work (var sizes, node formats, parsers, etc).

 

 

@Jon:  Entryway gave me his blessing to expand upon PrBoom+, as long as I took care not to mess up compatibility, so, I think we're good, there. I like your definition: "Things Boom could have included, but didn't." That sums it up well!

 

@Coraline: Thanks for the list - that's very helpful. I would suggest keeping your numbers as they are. I have some ideas for handling compatibility within the spec. But, I might also suggest that you start using the in-between numbers just to keep your "impact" upon the range small.

 

@VGA: I'd be a bit careful about proclaiming how easy it is to support new things. The devil is in the details. I'd be inclined to say "Hopefully, it will be easy." :)

 

@Angry_Cat: Me too!

 

 

 

[Graf Zahl]

9 hours ago, Jon said:

I Agree. I think UDMF is too far.

I don't think so. All it would need is a simple, easy to port reference implementation that directly fills the existing data structures

The main problem with definition lumps seems to be on a different level: Instead of using the working reference parser, some people seem to be intent on reimplementing it with their own parsing framework.

 

There's too much discussion here on crutch solutions that only come up because 'native Doom map format' is deemed to be the ultimate limiter.

Sorry, but that's not going to work out. The Doom map format has such stringent limitations that some things simply cannot be done. The lack of a thing ID is one of the most grating one of all. And let me be clear: Extradata like invented by Eternity is not a solution.

 

The UDMF base namespace is actually simple to implement because it does not contain any feature that cannot be trivially supported. There's only two minor differences from binary: Allowing separate spawn flags for all skills and the separation of a line's tag into the actual special parameter and a line ID.

 

24 minutes ago, kb1 said:

Entryway gave me his blessing to expand upon PrBoom+, as long as I took care not to mess up compatibility, so, I think we're good, there. I like your definition: "Things Boom could have included, but didn't." That sums it up well!

That's good to hear. My main issue with PrBoom+ is that it still uses Subversion as its version control software. Unfortunately for any cooperative effort, SVN is one huge clusterfuck of a tool and cannot compete even remotely with Git. So how do we deal with that?

 

[Jon]

2 hours ago, Graf Zahl said:

There's too much discussion here on crutch solutions that only come up because 'native Doom map format' is deemed to be the ultimate limiter.

Sorry, but that's not going to work out. The Doom map format has such stringent limitations that some things simply cannot be done. The lack of a thing ID is one of the most grating one of all. And let me be clear: Extradata like invented by Eternity is not a solution.

Well sure, some things can't be done in doom format, and discussion around those areas is still taking place (by some people) but plenty can still be done (improved scrollers, better 242, the trig-wake and insta death stuff I've already prototyped out, etc.) and for me at least that's what's interesting about this discussion at the moment.

 

2 hours ago, Graf Zahl said:

My main issue with PrBoom+ is that it still uses Subversion as its version control software. Unfortunately for any cooperative effort, SVN is one huge clusterfuck of a tool and cannot compete even remotely with Git. So how do we deal with that?

 

Maybe entryway would like to move on from SVN. With just one person hacking on the project, SVN isn't as much pain, so it was unlikely to be high up his priority list.

[kb1]

15 hours ago, Graf Zahl said:

I don't think so. All it would need is a simple, easy to port reference implementation that directly fills the existing data structures

The main problem with definition lumps seems to be on a different level: Instead of using the working reference parser, some people seem to be intent on reimplementing it with their own parsing framework.

I might be wrong, but I don't think it's wise to include UDMF in Phase 1, if we're going for mass adoption - it'll scare everyone away! It's scaring me away, at the moment. UDMF is an optional add-on that some ports may not be willing to implement right away. It can be thought of as an isolated package without forward dependencies. UDMF will eventually become a prerequisite for later phases, but, as of yet, it's not essential, and we have plenty of things that are.

Quote

There's too much discussion here on crutch solutions that only come up because 'native Doom map format' is deemed to be the ultimate limiter.

Sorry, but that's not going to work out. The Doom map format has such stringent limitations that some things simply cannot be done. The lack of a thing ID is one of the most grating one of all. And let me be clear: Extradata like invented by Eternity is not a solution.

Let me be clear: I fully intend on providing proposals to extend the Doom format as much as possible, provided that reasonable, practical solutions present themselves. There is no reason that this has to hinder other efforts, such as Hexen and UDMF mapping, and even Heretic/Strife mapping. I intend on supporting the broadest possible mapping capabilities, for all map formats.

 

Having said that, it may make sense to work backwards a bit: Implement some Hexen/UDMF primitives, and "back-port" those into the Doom format. That might save some coding effort, and avoid some duplicate code.

 

Let me please re-iterate the goal: The original goal is to update the baseline mapping capabilities that a mapper can reasonably expect to be able to use, in ANY enhanced port. That does not suggest UDMF, Hexen, ThingDefs, or any of that. I think we can eventually get there, and I'd love to get there. We both said it: We need to start small, and get some enhancements out there in the major ports. Your UMAPINFO was a huge step in that direction. As an idea thread, discussing eventual UDMF support is most welcome. Ideas are one thing, but implementation is another.

 

We cannot rush into it - we need to produce easily adoptable stuff. If we are really careful, and if we plan ahead, we can pave the road, so to speak, so that the newer features can be dropped in without too much difficulty. But, if we rush, we could end up creating nightmares for the various port devs who believed in our plan. I want to avoid that at all costs.

 

So, what can be easily adoptable? Again, UMAPINFO, some needed bug fixes/replacements on existing stuff, some new features in existing structures (read "Doom format").

 

Quote

 

The UDMF base namespace is actually simple to implement because it does not contain any feature that cannot be trivially supported. There's only two minor differences from binary: Allowing separate spawn flags for all skills and the separation of a line's tag into the actual special parameter and a line ID.

So, a couple of questions for you: (Sorry if I've already asked, and/or if the info can be found elsewhere:)

1. If I make a UDMF map, and mark it as a "Doom" map, I cannot set, for example, TIDs, or use any of the 5 special args? Even if my engine supports Hexen?
2. Asked differently: Does the map type (namespace?) of a UDMF map simply tell the port to interpret a linedef type 1 as a Hexen linedef type 1 vs. a Doom linedef type 1?

 

Quote

 

That's good to hear. My main issue with PrBoom+ is that it still uses Subversion as its version control software. Unfortunately for any cooperative effort, SVN is one huge clusterfuck of a tool and cannot compete even remotely with Git. So how do we deal with that?

I'm not the best person to ask, but, if Subversion is difficult to use, why not move your fork to Git, provide entryway full access, and give the port a slightly updated name? (Still like "PrBoom+" ...hmmm - I have no idea. Maybe a new thread is required...)

 

 

 

Edited July 27, 2017 by kb1

[Gez]

21 minutes ago, kb1 said:

Phase 1

Shouldn't it be Phase 2? Boom was Phase 1...

 

21 minutes ago, kb1 said:

• If I make a UDMF map, and mark it as a "Doom" map, I cannot set, for example, TIDs, or use any of the 5 special args? Even if my engine supports Hexen?
• Asked differently: Does the map type (namespace?) of a UDMF map simply tell the port to interpret a linedef type 1 as a Hexen linedef type 1 vs. a Doom linedef type 1?

Yes. The namespace defines the featureset. If you want to use a feature that is not part of the "Doom" namespace specs, you need to use a different namespace that does include that feature in its specs.

[Graf Zahl]

Regarding UDMF, right now ZDoom, Eternity and 3DGE already support it. I don't see who might be scared away, especially if a ready-to-use reference implementation already exists. UDMF's "Doom" namespace is merely a map loader, a very minor extension to the mapthing spawn function and a very minor extension to the linedef structure and P_FindLineForTag, its impact on the engine is significantly less than UMAPINFO.

 

On the downside, without UDMF many features would require a crutch implementation first which would probably scare away even more people - it would definitely make me think twice about it.

 

I believe that before adding new features the basics need to be done and that includes a map format that can handle it without throwing up its hands in despair. I only need to think about ZDoom's history which is now saddled with countless of such crutches because the features were shoehorned into the binary map formats - and actually USED! Let's avoid that mistake!

 

 

[kb1]

15 hours ago, Graf Zahl said:

Regarding UDMF, right now ZDoom, Eternity and 3DGE already support it. I don't see who might be scared away, especially if a ready-to-use reference implementation already exists. UDMF's "Doom" namespace is merely a map loader, a very minor extension to the mapthing spawn function and a very minor extension to the linedef structure and P_FindLineForTag, its impact on the engine is significantly less than UMAPINFO.

 

On the downside, without UDMF many features would require a crutch implementation first which would probably scare away even more people - it would definitely make me think twice about it.

 

I believe that before adding new features the basics need to be done and that includes a map format that can handle it without throwing up its hands in despair. I only need to think about ZDoom's history which is now saddled with countless of such crutches because the features were shoehorned into the binary map formats - and actually USED! Let's avoid that mistake!

 

 

Are we creating a specification, or a new engine? For a dozen pages, we've been rejecting the addition of too many things for mass adoption's sake. Maybe you're right, and there is no "mass" to worry about. I suppose we could count the number of widely-used active ports on one or two hands.

 

Believe me, I am all for adding UDMF (though I think Hexen format should be a prerequisite, but a lot more work), but it seems like the goal keeps moving. My infamiliarity with the ins-and-outs of UDMF format aren't helping much. You see, I have been doing my research in a specific order, based on things being broken into phases, and you're talking about adding things in a different order, which is not helping me. Maybe that's ok, though.

 

Some of this pain is alleviated if you are actually the person doing the UDMF implementation, into your fork of PrBoom+. Don't get me wrong - I am not asking you to do that. I know you have plenty of responsibilities with your *ZDoom ports and your script engine. I fully intended to mock up all the code described in my spec, before releasing the spec, so a working implementation could be directly referenced. I did not expect to have help doing that. But, you've already done UMAPINFO, and Jon has started with some new linedefs - again, a pleasant surprise, though it's causing me to shift gears.

 

The specification is more important than even the implementation, though. AFAIK, we don't even have a fully-specified Doom UDMF implementation. We have 2 versions of ZDoom UDMF, and an Edge UDMF, right? I do not want to create a situation where we just "slap it in", and let the users tell us what's lacking. The specifications must come first. Adding features is something totally different than supporting compatibility, and the specification is first and foremost about unifying the way ports handle certain constructs. (I know that UDMF is a wonderful way to "start over" with a new, clean implementation. So, let's do it right, take our time, and create exacting specifications, before it's too late. We should be able to write the code, based on those specs, once, and it be correct.)

 

So, exactly what abilities does a Doom version of UDMF afford the mapper? I know the mapper gets the ability to apply properties directly, without "crutches". Does that describe the bulk of it?

 

Speaking of Crutches:

Please do think twice about it. Here's the facts:

FACT #1: There is a hierarchy of roles that we should respect, in order:

1. Mappers - Without them, we have no new maps to play, and all the new features in the world mean nothing. Mappers are at the top of the food chain.
2. Players - Without them, what are we doing this for?
3. Editor and Engine Developers - Yep, we're at the bottom of the stack. I don't like it, but that's how it is. It is our job to cater to the 2 higher levels, cause the mappers use our tools and features to create greatness, and the players depend on our engines to have their fun.

FACT #2: Most mappers make Doom maps, vs. Heretic, Hexen, or Strife.

FACT #3: A good percentage of those mappers are going to stick to Doom format, despite better format support.

FACT #4: Boom, Legacy, and even vanilla used "inventive" ways to implicitly encode more information into the Doom map format, to accomplish specific effects.

 

My point is, there is precedent for expanding the Doom feature set within the Doom map format. Some of our old-school mappers have made some beautiful maps within these constraints. Other mappers embrace the new possibilities afforded by more-powerful formats. I want to provide new tools to ALL our mappers.

 

Graf, you state that implementing UDMF does not have to be scary, if a working implementation is presented. I would argue that the same could be said for a new, drop-in module that supports a handful of powerful new Doom-format editing constructs.

 

I admit that I did not fully understand Boom's genlin.c (Generalized Linedefs) when I dropped it into my port. I didn't have to understand it to use it. (Granted, it had a few bugs in it :)

 

I am not talking about seriously ugly hacks. Maybe we would need an extra function, to support a new way for linedefs to find their targets. Maybe Quasar's generalized lighting effects. The insta-death lines. A linedef that triggers all actions in an adjoining sector. There's lots of possibilities. And these could also be used in Hexen and UDMF maps. I think it would be a disservice to avoid "getting a little bit dirty" with the format.

 

You are known for wanting and enforcing cleanly formatted and structured code, and I commend you for that. I like clean code constructs as well. This is a difficult problem. There is nothing dirty about a well-documented solution to a tough problem. I am not afraid to type (as you can tell), and I intend on documenting my solutions completely.

 

I am hoping, after reading this wall of text, that when you are presented with a rock-solid, well-defined set of Doom-format editing enhancements, you can get behind the implementation, and hopefully appreciate what I am trying to accomplish, with an open mind. Really, I just ask for an open mind until the spec is presented. We can all present our arguments at that time. Sound reasonable?

 

[floatRand]

As far what I would be hankering for, just sound-producing line actions, step-on-sector actions and lines that block LoS/projectiles.

Also vertically repeating double-sided midtextures and no-infighting flag for things?

 

[Death Egg]

2 hours ago, floatRand said:

Also vertically repeating double-sided midtextures

Please.

[printz]

How would you limit no-infighting? Is it a species flag or an individual flag? The thing should avoid fighting whom?

[Graf Zahl]

3 hours ago, floatRand said:

Also vertically repeating double-sided midtextures

 

 

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.

 

[scifista42]

1 hour ago, printz said:

How would you limit no-infighting? Is it a species flag or an individual flag? The thing should avoid fighting whom?

I can imagine multiple kinds of useful no-infighting flags. A species flag to avoid fighting between monsters of the same specific species even when they hit each other with non-projectile attacks (see infighting of Lost Souls and hitscanners), an individual flag to make a specific thing avoid fighting anything else than the player (for localized fight setups that wouldn't work efficiently if the monsters turned onto each other), and a global flag to apply the individual flag's behavior to all things in the game (when every fight setup in the game is like that).

Edited July 29, 2017 by scifista42

[printz]

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

[NEANDERTHAL]

What about a stair action that goes down instead of up? Stair actions that work on cielings?

[BigDickBzzrak]

8 hours ago, floatRand said:

vertically repeating double-sided midtextures

 Just stacking linedefs on top of each other is not good enough?

(make 2 separate lines and drag one onto the other, after turning off "merge geometry" in DB2. Or just make them 1 unit apart from each other.)

1 hour ago, NEANDERTHAL said:

What about a stair action that goes down instead of up? Stair actions that work on cielings?

Umm, this already exists.

[Jon]

33 minutes ago, bzzrak said:

 Just stacking linedefs on top of each other is not good enough?

(make 2 separate lines and drag one onto the other, after turning off "merge geometry" in DB2. Or just make them 1 unit apart from each other.)

 

I think that only works with certain/some nodebuilders and not necessarily in all situations?