What small improvements from BOOM/MBF could be made in a new standard?

Consider this an offshoot of the "Defining a new enhanced source port standard (Boom+/MBF+)" thread, which is a bit stuck in talk over thing definitions.

Ideally smaller quality of life changes could be posted here, or just bringing up annoyances within Boom/MBF that could be fixed.

On 26/04/2017 at 5:40 PM, esselfortium said:

If an extended Boom feature set is developed, please consider making sane versions of the line scrollers. The ones Boom comes with are truly baffling, and all but useless in most situations. The line-vector scrollers are based on relative angle, so it's literally impossible to synchronize scrolling of different-angled lines, and the offset-based scroller can't be controlled via a tagged line, so it's impossible to use texture alignment with it.

This is an example of a problem that we could try and address. Let's try and break this down into sub-questions.

What would the functionality of a sane version of a scroller look like, given that we stay in the Doom map format?
How can we keep sane functionality without giving away too many special numbers (as this number is finite)?

Now, I personally cannot think of easy answers to these questions.

Bear in mind this is an open discussion, and this particular issue could be shelved whilst other people come forward with their gripes with the standard, and we try and solve them.

This is a good idea for a discussion, I think -- there's a lot of low-hanging fruit and small additions that would make mappers' lives easier, without having to delve into circular discussions about defining new formats.

For sane scrollers, I'd think the easiest way would just be to have one new offset-based scroller, one that can be applied to multiple lines from a dummy control. To make it capable of slower scrolling (for better parity with ZDoom's parameterized scrollers), its scroll-speed values could be interpreted as less than 1 texel per tic. Maybe 1 = 1/10th of a texel per tic? Or maybe that'd still be too fast. Precise speed control of super-slow scrollers are of more practical use than precise speed control of super-fast scrollers, so I'd err on that side. A floor/ceiling scroller that accepts matching values would also be of use.

On 1.5.2017. at 1:00 AM, bzzrak said:

Another little feature request if it's doable: having teleporters that preserve Z-height, like that buggy Final Doom executable. I could do so much...

Having both silent and non-silent ones would be great, too.

13 minutes ago, esselfortium said:

Maybe 1 = 1/10th of a texel per tic?

IMHO 1/8 or 1/16 would be better, as Doom generally works with powers of 2.

--

Also, a sky transfer that affects the whole map without using tags would be useful, provided that it can be overriden with regular action 271.

I think the very first thing is to find what linedef and sector specials can be used and make a list. Then we can enter what we deem worthy right there and maybe add support in the ports right away if a consensus is reached. As long as it's just abstract talk without ongoing construction of a specification I fear this will end up as vaporware, just like everything else.

So, to start, ZDoom can use all line specials from 440 to 12000, and sector specials 25-31, the values below are occupied by some Heretic and Hexen effects, of which I'd only consider Hexen's phased lighting as useful and simple enough for a simple Boom+ standard.

Regarding wall scrollers, what I'd like to add is a scroller type that uses the tag as speed parameter. That alone would cover more than 90% of all use cases with 4 simple to use types, one for each cardinal direction. More flexible types are still possible but let's make the easy stuff as simple as possible.

I moved this to the Editing forum where it is more likely to be seen by mappers who might have relevant suggestions.

Boom has two flat light transfer actions: 213 for floors and 261 for ceilings. Way back when I proposed extending this with a light transfer action that take a light level from its master sector plus or minus 8 units. This way you can create light gradients that change accordingly when the master sector has a flicker, glow or blink light effect.

22 minutes ago, Mordeth said:

Boom has two flat light transfer actions: 213 for floors and 261 for ceilings. Way back when I proposed extending this with a light transfer action that take a light level from its master sector plus or minus 8 units. This way you can create light gradients that change accordingly when the master sector has a flicker, glow or blink light effect.

More powerful synced lighting specials would be amazing to have, yes please!

I think the specific method might need some more thought, though -- I'm already imagining some gaps in functionality with that one, namely that the amount of flickering would be identical on every part of the gradient, with no way to set an ambient-light-level 'floor' that each sector's brightness can't ever go below. As such, the edges of the gradient wouldn't be able to fade completely seamlessly into the surrounding sector brightness.

If there were a handful of synced random-flicker sector specials, you could probably accomplish anything you'd need using some dummy sectors to pull the ambient light level from, similarly to how Doom's existing lighting specials work already. 8 sync groups would probably be enough to be able to have plenty of different random synced-flicker lightsources in view at a time. What do you think?

Boom/MBF introduced their own bugs which should be fixed, also fuck monsters being knocked off of ledges while alive so much

The wall light transfer should also not be forgotten. ZDoom already has this.

@Marcaek:

The monsters being pushed off ledges was a consequence of making conveyor belts work. I have no idea if it can be done better without breaking lots of stuff.

2 hours ago, esselfortium said:

If there were a handful of synced random-flicker sector specials, you could probably accomplish anything you'd need using some dummy sectors to pull the ambient light level from, similarly to how Doom's existing lighting specials work already. 8 sync groups would probably be enough to be able to have plenty of different random synced-flicker lightsources in view at a time. What do you think?

I have a feeling you can't sync random-flicker light levels. The flicker 'pattern' seems to depend on the (absolute) light difference between the flagged sector and its surroundings. You would probably still have to go with a 'master' sector and adjust your gradient sectors' light level accordingly. Eg. if master's 'base' light level is 192 and a gradient sector is 160, a drop of 16 light units in the master also translates to a drop of 16 for the gradient one. You control the base ambient light level by making sure your master sector borders a (dummy) sector with this light level, so it would oscillate between those max / min values only.

I currently do this with a generalized ACS script in EE that automatically detects the gradient sectors, the surrounding minimal ambient lighting and polls the master sector in a loop for its current light level and adjusts the gradient automatically without going below ambient lighting.

For controlled lighting effects that's probably the best thing anyway. You simply have far more control if you can drive the whole thing programmatically instead of having to rely on various thinkers not to go out of sync.

Non-buggy versions of linetypes 166 and 186 (supposed to move both the floor and the ceiling, but because of a basic programming error (confusing bitwise "or" | with boolean "or" ||) it only moves the floor if the ceiling is blocked, otherwise it only moves the ceiling).

Bugfixed version of generalized crushers, which currently don't work with walkover trigger.

Hexen phased light effects

Hexen's synchronized stair builders

Attached sectors (can use EE's implementation)

3 hours ago, esselfortium said:

More powerful synced lighting specials would be amazing to have, yes please!

 

I think the specific method might need some more thought, though -- I'm already imagining some gaps in functionality with that one, namely that the amount of flickering would be identical on every part of the gradient, with no way to set an ambient-light-level 'floor' that each sector's brightness can't ever go below. As such, the edges of the gradient wouldn't be able to fade completely seamlessly into the surrounding sector brightness.

 

If there were a handful of synced random-flicker sector specials, you could probably accomplish anything you'd need using some dummy sectors to pull the ambient light level from, similarly to how Doom's existing lighting specials work already. 8 sync groups would probably be enough to be able to have plenty of different random synced-flicker lightsources in view at a time. What do you think?

If you're not afraid of horrible hacks, you can take advantage of how an effect line like this can be placed outside of the visible and playable area to hijack several extra values as "parameters". Notably, you have the linedef's X and Y texture offsets, the line's length and angle, the line's upper and lower textures, and the line's front sector's attributes (floor height, ceiling height, light level). All these things can be largely arbitrary without consequences if the line is part of a single triangle sector outside of the map proper, and most of these things have precedents for having been exploited this way.

6 hours ago, Graf Zahl said:

So, to start, ZDoom can use all line specials from 440 to 12000

There needs to be buffer space reserved on the low and high ends of that range. You've also not addressed my question as to whether or not the top bit of the line special should be usable, which would free up the range from 32768 to 65535. I do not know of any use for negative line special numbers and thus I see no reason this should continue to be treated as a signed int. That's why I brought it up, to understand what if any technological challenges would be in the way.

10 minutes ago, Quasar said:

You've also not addressed my question as to whether or not the top bit of the line special should be usable, which would free up the range from 32768 to 65535. I do not know of any use for negative line special numbers and thus I see no reason this should continue to be treated as a signed int.

For what it's worth, SLADE and GZDB already treat it as unsigned[1][2], so there is zero work needed for editor support. (I haven't checked Eureka, though.)

I haven't answered because I still needed to check if the translation code can handle it. And from a quick look it does so the high numbers are all available.

Making the variable unsigned should be all that is needed here for all ports.

Let's not forget something really, really important:

A Boom 242 alternative that uses sane semantics for texture use and omits the upper part, so that water areas are easier to create. I guess making the water swimmable would be a bit beyond the scope here, but investigating feasibility may make sense anyway.

You'd need a key to swim up, at least.

Although PrBoom+ supports jumping, so there's that. As a more universal solution, trade the speed key for ascending while underwater a la Marathon.

I need to have a refresh of boom stuff, the things that stand out for me was the limited translucency support (single fixed value), floor/ceiling transfers can't be made translucent without hacks (useful for water or glass ceiling etc). I dont know if this next idea is reasonable, is it possible to have a conditional floor height transfer? such as transfer if sector height is lower? imagine a column lowering into deep water, you want the water to be drawn over the column as drops below the water surface but not before.

As long as you can climb walls by pressing against them while in a swimmable sector, you don't even need a swim up key (even if it's still a lot more convenient to have one).

• Fix boom's longtics behaviour.
• A MAPINFO-esque thing, I guess.
• Give the user more choice with the HUD (prb+ cycles through various options but doesn't allow true customisation, and iirc doesn't offer some features I'd like, such as a visual indication of when you have the chainsaw/berserk/ssg, and gameplay statistics like I outlined here)
• An option to have the intermission screen say something like 76/77 kills instead of percentages might be nice. As I understand it, there's a demo compatibility issue here, but if this were a new compatibility standard that might not be a problem.
• A few carefully chosen extensions/clarifications to the bex system, such as control over a monster's splash immunity, control over whether or not flying monsters fall when they die, and true control over the archvile resurrection frames and codepointer. Not to mention fixing the weird issues with weapons and ammo.
• The ability to change the engine strings that deh/bex doesn't let you change for some reason (IE, the exit messages).
• The ability to "uncouple" sound/music resources that are used in two places by default, such as MAP31 using the end screen music, and the main menu using various gameplay sounds.
• The ability to use different colormaps in different levels, a la Hexen's fog effect, would be very nice.
• Using cl2 (or whatever) should disable HUD features that vanilla didn't have, in my opinion.

Besides that, I have a more informal request: please have some clear plan in mind for how your new standard is going to avoid being ZDoom. People use boom compatibility because they see it as like vanilla with a few new features (they usually don't realise how vast and potentially un-doomlike the new features are, but that's beside the point), and they don't want a thousand new features. The difficulty of adding new monsters in dehacked/bex, for example, is an advantage, because it forces the creator to think about what they're doing instead of throwing in anything they think of. A new standard should mainly fix problems with boom compat and offer a more reliable/internally consistent/user-friendly version of the features boom already has.

Also, no dynamic lights.

...Are you guys seriously talking about making swimmable water?

Maybe not seriously.

17 minutes ago, Grain of Salt said:

...Are you guys seriously talking about making swimmable water?

only knee deep

@Grain of Salt:

We are actually discussing a standard extension. Most of what you suggest is quite specific to PrBoom+.

20 minutes ago, Grain of Salt said:

...Are you guys seriously talking about making swimmable water?

One can ask for some opinion, even though I don't really think it's a good feature for a 'simple' Boom extension. One issue is that I know two implementations that are quite different in how they work (ZDoom and Legacy.)

Hmm, is this the place to bring up that old idea of adding a bunch of dummy states and things for BEX to play around with? That would be a fantastically handy stopgap feature in lieu of any mythical actor definition language.

What I would enjoy having:

• A generic MBF-style monster missile/bullets attack codepointer (for Dehacked)
• Generic bullet/projectile weapon codepointers (for Dehacked)
• Extra unused Sound slots
• Extra unused frames and thing slots (doesn't Doom Retro or Crispy Doom have these? Basically just copy/paste that in)
• Extra map slots and CWILV graphics for those levels (CWILV54 = MAP55, to follow the vanilla scheme)
• The ability to change the duration of the powerups like Invulnerability and Partial Invis via Dehacked
• More weapon slots even? Maybe just add extra slots where other weapons are; like shotgun and SSG
• Edit ALL the strings
• Fix any of the missing Generalized linedef types, I don't recall exactly which are missing. Crushers?
• MAPINFO, my preferences being control over where a secret exit or normal exit in a map leads to, ability to define new intermission positions and subsequently disable existing ones (override Dehacked for the background flats as well), ability to end the game at whichever map, probably just override the Dehacked for par times and map name strings (automap), define the name of the music track for a level... I think that's all relevant data?
• A new -complevel to specify this as a standard, and so that it isn't simply added to without extreme considerations or only if an addition won't affect demo compatibility. Further additions should be added to default -complevel.

My idea is that a barebones MAPINFO would be used so that nothing would need changed/added to zdoom, and the lump could still be simply named "MAPINFO". Example entries:

map MAP01 "Automap String Here"
{
next = "MAP02" - use "ENDGAMEC" for the MAP30 cast call like zdoom
secretnext = "MAP43"
cluster = 1
music = "D_MUSIC1"
par = 210
}

Intermissions would be defined in MAPINFO as well, just like zdoom:

clusterdef 1
{
    entertext = "YOUR TEXT HERE"
    exittext =  "YOUR TEXT HERE"
    flat = "FLATNAME"
}

I must say that personally the Boom/MBF format to me is very much "Doom with a few extra things". The way vanilla Doom plays is how I like my Doom, and I feel like these things add more flexibility to the base game without being totally new features, like how generalized linedefs allow you better control over sector movements or door types. Essentially, I think a "Boom+/MBF+" format should simply expand how much control you have over the game, not necessarily add more and more new features to it. I don't want to come off in a bad way by saying "That's what GZDoom is for", but otherwise why even bother having different ports?

I would love to see this become thing in the future, and I do hope something comes of it.

1 minute ago, Rayziik said:

My idea is that a barebones MAPINFO would be used so that nothing would need changed/added to zdoom, and the lump could still be simply named "MAPINFO". Example entries:

Some thoughts here:

You cannot name it MAPINFO. That would make it incompatible with older ZDoom forks like ZDaemon.

ZMAPINFO could be made to work but I'd rather not do that for a few reasons:

- ZDoom's clusters are - well - a rather bad clusterfuck. I have no idea why they were implemented for other things than hubs. I always felt that transition texts should be tied to maps, not clusters. That's a lot easier to understand.

- To allow menu definitions without adding new top level blocks, again a few new map properties are needed.

- Boss death actions need to be expressed in Doom-style specials, not Hexen style as ZDoom does.

- default fallbacks need to be handled. This was one of the biggest failures in ZDoom that each MAPINFO entry overrides everything that came before with a clean slate and for obvious reasons that cannot be changed.

To summarize. ZDoom's MAPINFO comes saddled with some bad legacy design decisions made 17-18 years ago that should never be part of a cross-port standard. Such a standard should start clean and do it *right*.

1 minute ago, Rayziik said:

I must say that personally the Boom/MBF format to me is very much "Doom with a few extra things". The way vanilla Doom plays is how I like my Doom, and I feel like these things add more flexibility to the base game without being totally new features, like how generalized linedefs allow you better control over sector movements or door types. Essentially, I think a "Boom+/MBF+" format should simply expand how much control you have over the game, not necessarily add more and more new features to it. I don't want to come off in a bad way by saying "That's what GZDoom is for", but otherwise why even bother having different ports?

I mostly agree here. New features should mostly be refinement. The two exceptions for me is a) MAPINFO and b) some lightweight actor definition capabilities - clearly significantly less complex than full blown DECORATE but also better than Dehacked/BEX.

1 hour ago, Graf Zahl said:

Most of what you suggest is quite specific to PrBoom+

2 out of 9 isn't "most".

3 hours ago, Quasar said:

 

There needs to be buffer space reserved on the low and high ends of that range. You've also not addressed my question as to whether or not the top bit of the line special should be usable, which would free up the range from 32768 to 65535. I do not know of any use for negative line special numbers and thus I see no reason this should continue to be treated as a signed int. That's why I brought it up, to understand what if any technological challenges would be in the way.

No problem here - I think it's crucial to solve.

2 hours ago, Graf Zahl said:

I haven't answered because I still needed to check if the translation code can handle it. And from a quick look it does so the high numbers are all available.

Making the variable unsigned should be all that is needed here for all ports.

 

Great news. Let's push to always talk about these as positive (unsigned) numbers. No need to confuse anyone, you know?

2 hours ago, Graf Zahl said:

Let's not forget something really, really important:

 

A Boom 242 alternative that uses sane semantics for texture use and omits the upper part, so that water areas are easier to create. I guess making the water swimmable would be a bit beyond the scope here, but investigating feasibility may make sense anyway.

 

Sure, we can discuss it, but for it to become real, I think we'd have to do the following:

• Use a new number (not 242), of course.
• Define ALL of the mechanics of swimming: Speed (a MBF-like friction...maybe exactly MBF friction), effect on monsters, etc. With specific values for every new effect. For example, does the player sink to the bottom? Can the player float on top (swimming)? Can the player dive? Oxygen issues? Air tank power-up built into the game?

KBDoom bastardizes 242, and defines a particular swimming effect that I never felt 100% comfortable with. (But some of it was cool). I'll describe it, just to get the conversation going:

• If you step or fall a small distance into the water, you swim on the surface. As you move, a splash sound is heard at regular intervals. A sprite change would be awesome, but I never got around to trying to draw DoomGuy ot top of Duke's swim frames!
• If you fall far into the water, you dive to the bottom. Bubbles are spawnned.
• Corpses sink slowly to the bottom.
• Swimming uses Heretic-like fly up/down code. If you "swim" (fly up) to the surface (PGUP), you pop-out a few feet, then fall onto the surface, into swim mode. One of 3 deep breath sounds are played, based on your oxygen level.
• If you dive (fly down) under the surface (PGDN), you automatically begin to sink slowly.
• Oxygen counter begins underwater, and torches are extinguished. Gasping sounds are played when oxygen is low.
• If you move forward against a wall, you "scale" up the wall to the surface. I added this so the player did not have to actually use the PGUP command to get back out of the water. There will always be a wall nearby, underwater (hopefully), so it seemed to be a natural way to keep movement "as easy as Doom", as well as semi-realistic, and not require the player to have to steer up and down, and still support above/below swimming.
• Sounds are played a bit slower underwater, making them deeper pitch (though this is not really accurate, it adds to the immersion).

It plays pretty well - and it's pretty realistic and fun. I'm pretty happy with it. I would like to tweak it a bit.

Please understand: I am not stuck on my own implementation. But I wanted to portray everything that is involved when you add real swimming. And frankly, a demo-compatible port should really define those default values, and perfect swimming. The reason is, this feature is very touchy demo-wise, and PrBoom+ has to respect demo compatibility. There are A LOT of hard-coded default values to consider (speed of descent/rise, oxygen times, friction, you name it). It's a can of worms, which is worth doing, but sync is of utmost importance. I don't know if we should try full-blown swimming in Phase 1!

It's kind-of like slopes: The angles should be standard: The max angle you can scale, the angle which starts you sliding down under gravity. Do the ports coordinate on these?

By the way, thanks guys, for creating this thread - I just found it! There's some good stuff in here, and the other has become unwieldy.

6 hours ago, kb1 said:

Sure, we can discuss it, but for it to become real, I think we'd have to do the following:

• Use a new number (not 242), of course.
• Define ALL of the mechanics of swimming: Speed (a MBF-like friction...maybe exactly MBF friction), effect on monsters, etc. With specific values for every new effect. For example, does the player sink to the bottom? Can the player float on top (swimming)? Can the player dive? Oxygen issues? Air tank power-up built into the game?

Of course it cannot be 242. ZDoom has ine extended special which only does the sector transfer parts. Swimming can be done with an additional type or, like in ZDoom placing a special thing in the sector. But like I said: The swimming part is a secondary concern because it involves changing game physics. The main issue here is compatibility between ports, if that cannot be achieved it'd be better to drop the feature from the standard. ZDoom's in a somewhat awkward position because its swimming feature is so old hand has been used in so many maps already.

6 hours ago, kb1 said:

It's kind-of like slopes: The angles should be standard: The max angle you can scale, the angle which starts you sliding down under gravity. Do the ports coordinate on these?

 

No idea. I don't think anything has ever been coordinated. The only other port aside from ZDoom with a competing slope physics implementation  is Risen3D and it chose to do a totally incompatible implementation.