Reflections and Aspirations: MBF21 in 2024

[bofu]

On 6/2/2024 at 10:05 PM, Xaser said:

Another sorta-related thing: in addition to a "set velocity" / "add velocity" sort of special, it'd also be nice to have new versions of MBF's A_Turn and A_Face that also modify the actor's velocity -- right now you can't do something like call A_SkullAttack and then use A_Turn to make the charge inaccurate, since it only rotates the actor and doesn't update the velocity vector at all.

 

[A_Turn and A_Face also suck in other ways: they don't work with negative numbers or units smaller than 1 degree. May as well fix those while in the neighborhood too. :P]

 

I think this would be great. I'll have to figure out the math, and it may turn out to be beyond my abilities, but I imagine it would be quite possible to reverse engineer something from the NewChaseDir code or whatever it's called. And that would allow us to perhaps also add a codepointer for simply moving a step in the thing's current direction (or even a relative direction, for sidestepping), no turns required.

[Obsidian]

A quick feature request that arose from some conversations earlier today: transparency/translucency on player weapon sprites and/or muzzle flashes. It's curiously one of the few places where the concept hasn't been implemented and, while somewhat niche, it could make for some interesting visual effects. GooberMan trialed a method for achieving this in their Rum and Raisin Doom source port by introducing an additive transparency map to their state table, so there is potentially some precedent for this working in DSDA-Doom as well.

 

(Any more details and you'd have to ask Goober specifically, I'm not terribly learned on this subject. :P)

[Doomy__Doom]

I've been messing around with "control objects" in the little spare time I have, mixing SpawnObject and LineEffect to get rid of some closets/voodoos, make dynamic tp dests and such, and existing A_SpawnObject is not great for use in the broad sense of "I want things here and there on the map". It's barely usable, but awkward (especially the relative angle affecting dx/dy calc) and brittle (moving geometry = pain), keeping it "cool in theory but impractical".

 

Ergo, tossing more codepointer suggestions at the wall:

• Low-hanging fruit - A_SpawnObjectFixed - like SpawnObject, but without relativity to calling actor. Just treat args as straight x/y/z/angle to use.
• Higher-hanging - A_SpawnObjectByDestination - find a valid TP destination by sector tag like a TP special would, spawn at those coordinates/angle.
• High effort - JumpIfSpawnObject[Fixed|ByDestination] - versions that respect collision like a TP would and produce detectable spawn success/failure.

 

Even just with the simplest A_SpawnObjectFixed, straight copypaste of coordinates would be a massive W over relative calcs, the primary reason that makes workflow ugly and annoying compared to traditional methods.

 

A couple tech demo maps for illustrative purposes, decohack in lumps: voodooless_nonsense.zip. The core concept is killflooring an object via numeric change effect special to run logic in death state.

 

Edited June 9, 2024 by Doomy__Doom
formatting fix

[Xaser]

I really really dig the idea of an A_SpawnTeleport that takes a tag as an arg and uses the teleport landing as its origin+angle. Could see a ton of cool stuff coming from that type of concept.

 

Bonus points: the ability to spawn in a new teleport landing.

 

Double bonus points: an actor flag that tells an actor to behave like a teleport landing*, so you can make 'em move around.

 

And for good measure: an A_Teleport, which does exactly what it says on the tin.

 

 

[*This one is somewhat only useful in the context of UDMF or other formats that have a TID, so you can do shit like have a moving teleport destination, or an actor  that throws a projectile and then have it teleport to that projectile. Crazy nonsense like that. :P ]

[Hebonky]

Idea for a decoration only variety of a teleport line. very situational but it would be very useful.

[camper]

Before I express my thoughts, I would like to ask a question: MBF21 is not only the purpose of new things, changes in weapons and game functions, but also new features for building levels (such as 3D floor or slopes)? Or is this wrong?

[Gez]

3 hours ago, Xaser said:

so you can do shit like have a moving teleport destination

Shub-Niggurath says that, in hindsight, it's actually a bad idea.

[Enator18]

31 minutes ago, camper said:

Before I express my thoughts, I would like to ask a question: MBF21 is not only the purpose of new things, changes in weapons and game functions, but also new features for building levels (such as 3D floor or slopes)? Or is this wrong?

it is meant to continue the line of the more feature-conservative source ports (vanilla -> boom -> mbf) so this means any general features that expand what you can do with the game while still staying true to the general engine limitations and style of the original game. So it could add map feature and it did (stuff like instakill floors and the block land monsters line flag) but things like 3d floors and slopes wouldn’t really fit with this idea.

[Gez]

17 minutes ago, Enator18 said:

it is meant to continue the line of the more feature-conservative source ports (vanilla -> boom -> mbf) so this means any general features that expand what you can do with the game while still staying true to the general engine limitations and style of the original game.

This is incredibly suggestive and fuzzy.

 

Pretty much any of the existing addition can be said not to be staying true to the limitations and style of the original. After all, the only way to stay true to the limitations and style of the original is to not do any change at all.

 

Why wouldn't 3D floors and slopes fit with this idea? I'm pretty sure that if they happen (and I'm not saying they will), they'd be immediately embraced. Just like the sort of complex multi-stage enemy behavior that used to require DECORATE mods back in the ZDoom days are now possible in MBF21+DSDHacked and I haven't seen anyone complaining about it.

 

Just for reference, 3D floors in Doom first appeared, I believe, way back in 1999 in good old DOSDoom, even before it got renamed to EDGE. The following year, they appeared in Doom Legacy. So we're talking about last century stuff. We're talking about this happening in the first 20% of the Doom history. Other games of the era had 3D floors, too; they existed in Ultima Underworld (1992); they existed in Elder Scrolls Arena (1994).

[camper]

4 minutes ago, Gez said:

Just for reference, 3D floors in Doom first appeared, I believe, way back in 1999 in good old DOSDoom, even before it got renamed to EDGE. The following year, they appeared in Doom Legacy. So we're talking about last century stuff. We're talking about this happening in the first 20% of the Doom history. Other games of the era had 3D floors, too; they existed in Ultima Underworld (1992); they existed in Elder Scrolls Arena (1994).

When I asked my question, I unspokenly had this in mind. Then there is odamex, which is also considered to continue the traditional school, but nevertheless it has slopes (and Legacy does not have them).

[bofu]

5 hours ago, Xaser said:

I really really dig the idea of an A_SpawnTeleport that takes a tag as an arg and uses the teleport landing as its origin+angle. Could see a ton of cool stuff coming from that type of concept.

 

Bonus points: the ability to spawn in a new teleport landing.

 

Double bonus points: an actor flag that tells an actor to behave like a teleport landing*, so you can make 'em move around.

 

And for good measure: an A_Teleport, which does exactly what it says on the tin.

 

 

[*This one is somewhat only useful in the context of UDMF or other formats that have a TID, so you can do shit like have a moving teleport destination, or an actor  that throws a projectile and then have it teleport to that projectile. Crazy nonsense like that. :P ]

 

You could probably workaround the TID thing by using an argument to use a TID mode or a "first found thing in sector tag X" mode via args, if you really wanted to. I love these ideas though and will definitely see what I can do.

 

(Just to manage expectations since there are a lot of other ideas floating around: the draft I'm working on is only for Thing/Weapon behaviors and compflags.)

Edited June 9, 2024 by bofu

[Gez]

45 minutes ago, bofu said:

You could probably workaround the TID thing by using an argument to use a TID mode or a "first found thing in sector tag X" mode via args, if you really wanted to. I love these ideas though and will definitely see what I can do.

The OG method is using the thing's angle. If you've ever wondered why Hexen polyobjects use those instead of TID, it's because it's a leftover from an early implementation before they changed the map format...

[Plerb]

Couple more things I thought of:

Floor skyhacks.

A flag for sectors to disable flat bleeding on its walls. For example, when you raise a floor and don't texture it, it's basically like a self referencing sector when you're below the line of sight for the floor, but when you're above it, it bleeds into where the walls would be. With this flag, the parts underneath the floor would still be transparent. Combined with midtextures, this would be useful for various decorations like tables and desks. (hope I explained that well enough)

[Scorcher]

On 6/11/2024 at 8:13 PM, Plerb said:

Couple more things I thought of:

Floor skyhacks.

A flag for sectors to disable flat bleeding on its walls. For example, when you raise a floor and don't texture it, it's basically like a self referencing sector when you're below the line of sight for the floor, but when you're above it, it bleeds into where the walls would be. With this flag, the parts underneath the floor would still be transparent. Combined with midtextures, this would be useful for various decorations like tables and desks. (hope I explained that well enough)

I suggested something similar a while ago. I really hope this is able to be done. +1

[ChopBlock223]

Had a another idea, defining gibhealth for monsters. Again also, it would be the coolest thing ever if moving sectors could be forcibly synced by their tag, so that if they bump a caco or something in the wrong spot, they can either stop until the obstruction is gone, start crushing until the crushable obstruction is crushed or gone, or it bumps and then decides to reverse back.

[stonedbaroness]

My wishlist:

 

• 3D Floors
• Easy colored lighting for sectors
• Slopes
• Portals
• Super customizable parameters for things in map editor (For example, someone mentioned things like checking a box that determines if an enemy attacks you but doesn't chase you.)
  • Adding on to what I said, just all the low hanging fruit and more for this category that others have discussed
• Proper implementation of voodoo that triggers play actions but is still compatible w/ multiplayer  (Like how Odamex handles voodoo things)
• Support for 8 player starts
• LINE HORIZON PLEASE!

If DSDA is trying to support UDMF... then yea I think these things are realistic for a wishlist. Even just a couple of these would streamline which format I'd choose to map in. Hexen format is my favorite because its Odamex compatible but its dated as hell. Something to take its place and do its own thing would be nice. 

[inkoalawetrust]

4 hours ago, stonedbaroness said:

My wishlist:

 

• 3D Floors
• Easy colored lighting for sectors
• Slopes
• Portals
• Super customizable parameters for things in map editor (For example, someone mentioned things like checking a box that determines if an enemy attacks you but doesn't chase you.)
  • Adding on to what I said, just all the low hanging fruit and more for this category that others have discussed
• Proper implementation of voodoo that triggers play actions but is still compatible w/ multiplayer  (Like how Odamex handles voodoo things)
• Support for 8 player starts
• LINE HORIZON PLEASE!

If DSDA is trying to support UDMF... then yea I think these things are realistic for a wishlist. Even just a couple of these would streamline which format I'd choose to map in. Hexen format is my favorite because its Odamex compatible but its dated as hell. Something to take its place and do its own thing would be nice. 

Okay so I don't use anything besides GZDoom and maybe ZDoom in general so I have no actual experience with anything besides that. But all these features you're describing sound like you want DSDA to basically have GZDoom's own UDMF format instead.

[camper]

8 hours ago, inkoalawetrust said:

Okay so I don't use anything besides GZDoom and maybe ZDoom in general so I have no actual experience with anything besides that. But all these features you're describing sound like you want DSDA to basically have GZDoom's own UDMF format instead.

This is also in Risen3D, and there are even 3D lines that are not in GZDoom
https://md2.sitters-electronics.nl/tut_lines.htm
 

p.s. and Ladders based on them, which are much easier to do than in GZDoom

Edited June 19, 2024 by camper

[stonedbaroness]

9 hours ago, inkoalawetrust said:

Okay so I don't use anything besides GZDoom and maybe ZDoom in general so I have no actual experience with anything besides that. But all these features you're describing sound like you want DSDA to basically have GZDoom's own UDMF format instead.

In a way, yea! I think if a mapping format that is fully demo compatible, forgoes ACS/ZScript and focuses on adding new voodoo-oriented features while also adding a couple of modern level design bells and whistles, It would be my preferred format. I know people can say "Well ZDoom/GZDoom/Eternity Already exists" and to that say "Ok, that's great!". I feel like GZDoom and other related engines are focusing more on innovation than anything, which is good! But it accommodates doom while giving resources to those looking to make something different, where as MBF should be the format that innovates when it needs to and hones in on anything and everything doom-related, with the goal of making all of dooms low-hanging-fruit parameters accessible and easy to use. UMAPINFO is on the right path, excited to see scrolling skies one day. 

[8088mph]

Going to add my two cents and say we're most likely not going to get 3D floors if we're getting a new expanded standard, we're more likely to get flat portals like in Build.

[Gez]

2 hours ago, camper said:

This is also in Risen3D, and there are even 3D lines that are not in GZDoom

This seems like the same basic idea as 3D middle textures/walkable middle textures, though with more customization capabilities at the expense of a more complex setup.

[camper]

1 hour ago, Gez said:

This seems like the same basic idea as 3D middle textures/walkable middle textures, though with more customization capabilities at the expense of a more complex setup.

I think these are much more flexible objects than middle  textures. And creating them in the game did not create any difficulties for me. At least I still haven’t figured out the ladders in gzdoom. In this video I give an example of 3D ladders and 3D lines with textures in doom port Risen3D. You can walk over and under them (but in the video only over them). I think they can be used for long 3D models in map for collisions.

[stonedbaroness]

3 hours ago, 8088mph said:

Going to add my two cents and say we're most likely not going to get 3D floors if we're getting a new expanded standard, we're more likely to get flat portals like in Build.

This at the very least, I can work with this to overcome the lack of 3D floors!