Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Altazimuth

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

Recommended Posts

1 hour ago, scifista42 said:

 The current situation is: If you want bugs fixed, use source port A, but you must accept the fact that source port A has no option to re-enable bugs to maintain demo compatibility.

Actually a lot of port "A"s (Zs?) have the options to re-enable "bugs" (features?), usually called compatibility flags, but still lack vanilla/boom/fossil demo compatibility I guess.

 

On the other hand, I feel like every time I see these threads and features people want along with vanilla demo compat they forget Odamex exists, which has relatively good "feature" support (emphasis on relatively) while also maintaining vanilla standards. I hate to shill out odamex but honestly from my admittedly limited understanding of these things, odamex seems to be a good starting place instead of trying to figure out how to make a new source port with goals already being somewhat met by one in existence.

Share this post


Link to post
1 hour ago, Ribbiks said:

infinite height is a bug?

sure it was intentional to save calculations, but Its always been inconvenient

Share this post


Link to post
7 hours ago, esselfortium said:

A problem with this is that there's no way to determine which player should be affected in multiplayer.

I think that could be covered with either 4 x WR teleport player N to tagged sectors (random landing if multiple destinations exist) specials. Ports that support >4 players could overload them (the special for player 1 is also player 5, 9, 13 etc) or even go to 8 or 16 specific specials before overloading may be needed. Ports with >4 players already need to account for this in other areas correct?

 

Share this post


Link to post
3 hours ago, Decay said:

Actually a lot of port "A"s (Zs?) have the options to re-enable "bugs" (features?), usually called compatibility flags, but still lack vanilla/boom/fossil demo compatibility I guess.

 

On the other hand, I feel like every time I see these threads and features people want along with vanilla demo compat they forget Odamex exists, which has relatively good "feature" support (emphasis on relatively) while also maintaining vanilla standards. I hate to shill out odamex but honestly from my admittedly limited understanding of these things, odamex seems to be a good starting place instead of trying to figure out how to make a new source port with goals already being somewhat met by one in existence.

AFAIK these discussions are about raising the current common standard of map editing features (Boom) slightly so that map authors can use some new stuff and providing the changes aren't too wholesale port authors may agree to implement and we then have a new common standard of editing features across a wide range of ports. Ports are then free to aim for demo compatibility to whatever degree they like, the intent here is play compatibility (that the new standards features operate roughly the same across all ports that look to support it).

Share this post


Link to post

New damage linedef specials and sector types

  • WR instant kill of the activating player
  • WR instant kill of the activating player (scream death)

  • W1/WR kill all monsters in tagged sector (barrels would also explode)
  • Sector type - Kill instantly when touching the floor

Thing interactive linedef types?

  • W1/WR set target to line activator (player only) for things in tagged sector
  • W1/WR set target to line activator (monsters only) for things in tagged sector
  • WR Trigger ranged attack on things in tagged sector.

Share this post


Link to post
11 hours ago, traversd said:

WR instant kill of the activating player

WR instant kill of the activating player (scream death)

Why not just use a regular WR warp to telefrag a voodoo doll?

Share this post


Link to post
12 hours ago, traversd said:
  • WR instant kill of the activating player
  • WR instant kill of the activating player (scream death)

  • W1/WR kill all monsters in tagged sector (barrels would also explode)
  • Sector type - Kill instantly when touching the floor

No, instant death traps should be banned.

Share this post


Link to post
1 hour ago, Grain of Salt said:

Why not just use a regular WR warp to telefrag a voodoo doll?

Did Hell upgrade all their lava to the magical teleporting kind? Sounds expensive.

Share this post


Link to post
16 minutes ago, printz said:

No, instant death traps should be banned.

That's silly, everything can be used for good and bad reasons. For instance a level set on a cliffside could use an "instant death on touch floor" to kill the player if they fall off, which is something that has been done in other, less straightforward ways (there's a level in... Epic 2? I forget? where there are W1 lines 16 units off the cliff edge that crush barrels next to a voodoo doll to simulate the same effect).

Share this post


Link to post

I don't see how magic teleporting lava is a problem if you're already chosen to use a WR line for the effect, and thus decided to potentially insta-kill the player in midair above the lava.

Share this post


Link to post

I have to agree with Linguica and Grain of Salt here... I find it insufferable to wait for 20 dmg ticks to finish me off in a pit with no way out. Kill the player right away if it's a death trap and be done with it...

Share this post


Link to post

Another idea: would it be possible to have an exit linedef that, in addition to exiting the level (duh), kills all monsters on the level when activated?

(Kinda like that Quake boss level.)

Share this post


Link to post

I don't really see the purpose of that unless you want to make it literally impossible to not 100% the map.

Share this post


Link to post

Instant death on hitting the ground seems a better idea for bottomless pits of no return (BPONR) than a walk-through line that causes a voodoo doll to telefrag another. For example in the Doom video thread there's a playthrough of Epic 2 with a gameplay mod where the player has the ability to dash quickly. Player dashes across a chasm instead of walking all around it as vanilla gameplay requires, arrives safely on the other side, then suddenly dies a second or two later from voodoo doll telefragging.

 

A sector flag for falling damage could be used too. These sectors would kill you if your vertical velocity is more than X units downward. Pretty simple effect.

Share this post


Link to post
1 hour ago, Linguica said:

That's silly, everything can be used for good and bad reasons. For instance a level set on a cliffside could use an "instant death on touch floor" to kill the player if they fall off, which is something that has been done in other, less straightforward ways (there's a level in... Epic 2? I forget? where there are W1 lines 16 units off the cliff edge that crush barrels next to a voodoo doll to simulate the same effect).

Yeh, the sector type has obvious uses as above, and perhaps the equivalent linedef special could be redundant if the sector type existed, but I listed it as an suggestion as there are possibly situations not immediately apparent (in DM perhaps), deadly force fields etc where it is more applicable than telefragging a voodoo doll.

 

EDIT: I suppose TNT MAP30 is fun that all players die in the puzzle at the start if 1 player gets it wrong? But perhaps the overall setup would have been nicer if the player that went along the wrong path simply gibbed and fell into the lava below?

Share this post


Link to post

Not sure why you guys are still debating this. Like I mentioned earlier, instant death sectors and linedefs have been implemented before in a MBF-based port and Joel did not give the impression this was hard to implement.

Share this post


Link to post

Strife also has an instant death sector and that didn't even have Boom. In short: It's a one-liner.

 

Share this post


Link to post

My cheeky post seemed to bounce off the head a bit. Replace "lava" with "death lasers" and repeat.

 

Or to be explicit: I was trying to illustrate the absurdity of suggesting a blatant half-solution with an obvious drawback (teleporting the player away looks ridiculous in this circumstance), which is entirely counterproductive and inappropriate in a "let's brainstorm new ideas" thread.

 

[Also, what Mord & Ling said.]

Share this post


Link to post

Another thing which hasn't been talked about much is some linedef/thing definitions that aid in simple scripting. The voodoo doll/conveyor/teleport stuff is brilliant, but prone to error (unless done very carefully), and a lot of work to implement. For example, maybe a linedef that triggers another linedef, when a lift reaches a certain height (or depth), or maybe even some boolean logic triggers ({NOT} AND/OR/XOR) that require 2 switches to be set a certain way, or 2 lifts, etc. I really don't know what mappers need, so it's a shot in the dark.

 

So the question: Voodoo doll scripters!: What abilities are you lacking? What linedefs might assist in voodoo doll, or voodoo-less scripting?

 

RE: Insta-death: The engine might be able to have different animations based on the type of insta-death. For falling, maybe the floor getting progressively bigger, then splat! Everything turns red. Or, for burning death: Maybe the player view spins around at high speed, while turning red. By defining different types of insta-death, the engine is free to animate it accordingly. It doesn't just have to apply damage - it could also look unique and cool.

Share this post


Link to post
On 5/15/2017 at 5:05 AM, traversd said:

Whilst I'm still making a list here are some more thoughts @kb1

 

“Boss Death” lock table

...

 

New exit level linedef specials

...

Aren't those things covered in the new UMAPINFO format?  Presumably we wouldn't need to define them again here.

Share this post


Link to post

S1/SR Floor start moving up and down. Sure I know it can be done with voodoo dolls.

Share this post


Link to post
14 minutes ago, Bauul said:

Aren't those things covered in the new UMAPINFO format?  Presumably we wouldn't need to define them again here.

Boss death - yes.

New exit level specials - depends on what this means. While you can redirect both regular and secret exit you are still limited to two maps to go to - and be limited to one starting point in the next map.

Both Hexen and Strife have types that allow specifying the map explicitly and also have separate starting points in a map. That's not that useful for a non-hub game, but I have seen maps that had multiple exists in ZDoom, leading to different starting points in the next map.

 

Share this post


Link to post
1 hour ago, Xaser said:

I was trying to illustrate the absurdity of suggesting a blatant half-solution with an obvious drawback (teleporting the player away looks ridiculous in this circumstance), which is entirely counterproductive and inappropriate in a "let's brainstorm new ideas" thread.

It is actually productive and appropriate to ask for clarification when someone's suggestion is unclear. Since "WR instant kill of the activating player" is obviously possible in several ways in boom (I chose the example of teleporting into a voodoo doll because it's a simple one) I wanted to ask traversd to further describe what he wanted from the new action. 

Share this post


Link to post

I can't imagine how it could've possibly been made more clear, but just in case: I'm fairly certain that by "WR instant kill," traversd meant "WR instant kill," not "WR pseudo-instant kill with often-undesirable side-effects."

Share this post


Link to post

Example: player #2 crosses a WR Teleport linedef, and telefrags a voodoo doll. Player #1 is now mysteriously dead with no clear idea of why, and player #2 is now stuck in a small dark untextured cell.

Share this post


Link to post
3 hours ago, Bauul said:

Aren't those things covered in the new UMAPINFO format?  Presumably we wouldn't need to define them again here.

 

2 hours ago, Graf Zahl said:

Boss death - yes.

New exit level specials - depends on what this means. While you can redirect both regular and secret exit you are still limited to two maps to go to - and be limited to one starting point in the next map.

Both Hexen and Strife have types that allow specifying the map explicitly and also have separate starting points in a map. That's not that useful for a non-hub game, but I have seen maps that had multiple exists in ZDoom, leading to different starting points in the next map.

 

Does the intended UMAPINFO spec allow the below setups?

 

1. Locking a door special until the following monsters (specific ones, not just the last in a map) are all killed?

 

2 x arachnotrons

4 x barons

2 x cybers

 

 

Then allow door to be opened (or using the new voodoo doll thing it opens it via a preset script and a new wave of monsters, that lock another door/sequence, are released upon the player.

 

2. Allow a hub setup for SP/Coop or a lobby with different exits to 99 different maps to play? I appreciate that UMAPINFO and like also allow specifying inter-level text sequences which is fine, but if an exit special can define the next map, specifying what is considered the secret map becomes redundant perhaps?

Share this post


Link to post

I feel like what you really want here is Hexen features in Doom, which, um.

 

( and also Eternity )

 

Not that I'm exactly opposed to it happening for more ports, but I feel like ... well, those ports should implement Hexen ( and UDMF ) format maps and ACS instead of trying to maim Boom format to force those features in. Especially since the latter is kinda impossible to not implement with proper Hexen support and the former is made incredibly simpler via thing IDs and a script that while( ThingCount( T_NONE, tid ) ) Delay( 1 ); loops and then performs the door opening afterwards.

 

Seriously, it's as simple as

#include "common.acs"
  
script 1 OPEN {
  while( ThingCount( T_NONE, 10 ) )
    Delay( 1 );
  
  Door_Open( 10, 16, 0 );
}

and the Hexen source code is freely available.

Share this post


Link to post
3 hours ago, riderr3 said:

S1/SR Floor start moving up and down. Sure I know it can be done with voodoo dolls.

How is that different than a simple lift? What am I missing?

 

 

42 minutes ago, traversd said:

 

Does the intended UMAPINFO spec allow the below setups?

 

1. Locking a door special until the following monsters (specific ones, not just the last in a map) are all killed?

 

2 x arachnotrons

4 x barons

2 x cybers

 

 

Then allow door to be opened (or using the new voodoo doll thing it opens it via a preset script and a new wave of monsters, that lock another door/sequence, are released upon the player.

 

2. Allow a hub setup for SP/Coop or a lobby with different exits to 99 different maps to play? I appreciate that UMAPINFO and like also allow specifying inter-level text sequences which is fine, but if an exit special can define the next map, specifying what is considered the secret map becomes redundant perhaps?

For #1, yes the UMAPINFO could be used to say "act like MAP07", where tag 666/667 is triggered when all spiders and fatsos are killed, or "act like E1M8" when barons are killed, etc. Those are built in, hard-coded functions of Doom/Doom II, and there's no reason a different map could not use the same trigger. But the conditions, and the results are the same as in the original game.

 

But, for the rest of #1, UMAPINFO is not set up to deal with scripts. Scripts are a very port-specific feature. The thing is, UMAPINFO, and Boom+ are not immediately going to benefit users of the most advanced ports, because those ports already have ways to handle all manners of custom capabilities. UMAPINFO and Boom+ are attempting to provide a simple subset of these advanced capabilities to lesser ports, in a way that is identical across all non-vanilla-like ports.

 

#2: I've logged the map-dest-in-exit-linedef idea. It sounds like it could be useful. I'd still define a secret and non-secret variety, so the port can track that you've taken a secret exit or not, for purposes to be defined by the port author. Ports currently expect there to be both kinds of exits. Naturally, if implemented, this would override the UMAPINFO map designations. I don't recommend building too many ways to accomplish the same result, but this allows a new kind of flow through the WAD, which is an interesting idea.

Share this post


Link to post
1 hour ago, Arctangent said:

I feel like what you really want here is Hexen features in Doom, which, um.

 

( and also Eternity )

 

Not that I'm exactly opposed to it happening for more ports, but I feel like ... well, those ports should implement Hexen ( and UDMF ) format maps and ACS instead of trying to maim Boom format to force those features in. Especially since the latter is kinda impossible to not implement with proper Hexen support and the former is made incredibly simpler via thing IDs and a script that while( ThingCount( T_NONE, tid ) ) Delay( 1 ); loops and then performs the door opening afterwards.

 

Seriously, it's as simple as


#include "common.acs"
  
script 1 OPEN {
  while( ThingCount( T_NONE, 10 ) )
    Delay( 1 );
  
  Door_Open( 10, 16, 0 );
}

and the Hexen source code is freely available.

Adding just Heretic support to a Doom port is a task, daunting enough that many good source port authors will never achieve it. It calls for radical changes to an otherwise stable engine. Hexen support adds quadruple complexity, even without ACS. I do not know what Raven had as far as nice script coding tools - I imagine they were shoving ACS byte sequences together, at least at first.

 

Boom+ is a stopgap measure inbetween Boom and Hexen, that provides more power to the mappers, a more-obtainable goal for the programmers, and, if done correctly, paves the way to the larger eventual goal of Heretic/Strife/Hexen resources, Hexen and UDMF, scripting, etc.

 

You have to give credit to the ZDoom (and Doomsday) teams for figuring out how to marry the games together. But this was a rough road, requiring some workarounds and tricks, tons of bug-fixing and testing, etc. Part of the fun of programming is to figure out how to do these things yourself. For me, it's going to take a lot of time. But, I can provide Boom+ a lot more quickly - that's the idea. And, unlike the script example, the extensions should be able to be available anywhere Boom is, quickly. It's not going to replace any cool scripting capability, or even close. But mappers will be able to target more ports, with more features.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×