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

Huh, we're talking about MAPINFO in this thread as if the UMAPINFO stuff hadn't occurred. I'd mentally tossed that item in the "already got it figured out" bucket.

Share this post


Link to post

UMAPINFO exists for the exact reasons I listed for nixing the idea of just using ZDoom's format, i.e. it contains too many semantics that are useless for a basic Doom port. Although I am going to un-INI the format of it, bringing it closer to ZMAPINFO.

 

Share this post


Link to post

Just to chime in: it would be nice if it's also EDF-compatible, like this:

MAP01
{
 music ddtblu
 name "Blue citadel"
}

Given that DECORATE also uses a braced syntax like that, I'm hopeful.

Share this post


Link to post

What mechanism does EDF have to distinguish between additional parameters and a new keyword? Does it forbid multiline values, require a separator character (other than space) between additional parameters, something else?

 

That was the main cause for ZDoom adopting a new MAPINFO syntax, as the old Hexen-derived was too ambiguous.

Share this post


Link to post

What this needs is at least one of two things:

 

- a ';' as terminator

- a ',' between arguments.

- a '=' alone is not sufficient without also having a ','.

 

ZMAPINFO went with both '=' and ',' so that it could have parameter-less properties - as required by precedent -, but if those are disallowed the '=' is not needed.

 

Share this post


Link to post
7 hours ago, Xaser said:

Huh, we're talking about MAPINFO in this thread as if the UMAPINFO stuff hadn't occurred. I'd mentally tossed that item in the "already got it figured out" bucket.

Maybe split the discussion into separate threads for

  • (hardcoded) linedef/sector/thing types
  • Thing customisation - currently filling up @kb1 Boom+ thread ;)
  • Episode customisation - the UMAPINFO thread
  • other stuff?

Then I can just browse the linedef/sector thread

 

;D

Share this post


Link to post
On jeudi 4 mai 2017 at 11:30 PM, Gez said:

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

So. I have since checked Eureka, and it looks like it's unsigned there too so I'm gonna say that editor support is 100% already here for line types in the 32768-65535 range.

Share this post


Link to post
3 hours ago, traversd said:

Maybe split the discussion into separate threads for

  • (hardcoded) linedef/sector/thing types
  • Thing customisation - currently filling up @kb1 Boom+ thread ;)
  • Episode customisation - the UMAPINFO thread
  • other stuff?

Then I can just browse the linedef/sector thread

 

;D

That's basically what we've got, if we're careful to post in the right spot! But these ideas are interconnected and somewhat inseparable. I am becoming overwhelmed as it is.

 

49 minutes ago, Gez said:

So. I have since checked Eureka, and it looks like it's unsigned there too so I'm gonna say that editor support is 100% already here for line types in the 32768-65535 range.

Very good news.

 

 

@Rayziik Nice ideas! Already considering some of them.

Share this post


Link to post

I'll probably end up reiterating stuff already mentioned, but from my recent experience, the short comings of Boom/MBF that bothered me the most were (in no particular order...):

 

Action 242 : Create Fake Floor & Ceiling.

 

It's rare that you need to create both a fake floor and ceiling in the same sector, and thus creating a body of water or bridge beneath an uneven ceiling requires multiple tags.

This action really needs splitting up into two additional actions, such as 'Create Fake Floor' and 'Create Fake Ceiling'.

 

The other issue with 242 is underwater passages. In BOOMEDIT a silent teleport is used to avoid HOMs caused by looking into a 'fake' sector from a normal sector, which isn't ideal since monsters have to be blocked off from entering the field of vision of the silent teleport. I don't know if addressing this issue is beyond the scope of this thread or indeed engine capabilities, but it would be nice for mappers to be able to create underwater passages more cleanly.

 

Swim-able water, and lifts that can pass through 'water' surfaces would be nice but it seems beyond the terrority of 'small improvements'.

 

Action 271 : Sky Transfers.

 

An additional action that has no tag, and liberally applies a new sky texture to entire maps, would simplify things. Alternatively a MAPINFO type entry to define a sky texture might be cleaner.

 

Action ??? : Static Flat Displacement/Offsets.

 

There's any number of floor scrollers that dynamically displace flats. The lack of an action that allows to a mapper to offset flats, seems a bizarre oversight.

 

Action ??? : Linked Sectors

 

The ability to override various sector properties, such as lighting, floor/ceiling heights, from another sector would be a very powerful tool to have, for things like multi-sector lifts, random light effects, etc.

 

Action ??? : Display text.

Action ??? : Play Sound.

Action ??? : Change Music Track.

 

These actions seem like a small, simple additions to make.

 

UMAPINFO & DECOLITE

 

Probably not small improvements, but so useful that I would be delighted to see added. In terms of MBF Dehacked, the present lack of a generic projectile attack code-pointer seems like a major oversight. And a charge attack similar to SkullAttack but without the odd 'floating backwards through the air after it hits an obstacle' behaviour would be nice to have.

Edited by Urthar

Share this post


Link to post

The adjustments to 242 logic that you suggest simply aren't possible, or at least not without major issues. The reason those limitations exist to begin with is because the feature is based on a hack of redirecting the engine to look at a different sector while rendering the one it's currently drawing. This is why both the ceiling and the floor have to come from the fake sector - the renderer determines what to use for both floor and ceiling at the same time.

 

As for changing music, MUSINFO already exists for this purpose and is already supported by just about every port.

Share this post


Link to post
3 minutes ago, Quasar said:

The adjustments to 242 logic that you suggest simply aren't possible, or at least not without major issues. The reason those limitations exist to begin with is because the feature is based on a hack of redirecting the engine to look at a different sector while rendering the one it's currently drawing. This is why both the ceiling and the floor have to come from the fake sector - the renderer determines what to use for both floor and ceiling at the same time.

FWIW, it is possible to do. ZDoom's transfer heights special allows for it.

Share this post


Link to post

The parts of disabling the upper part and sanitizing the texture choice for the floor are simple tweaks of R_FakeFlat. All it does is create a copy of the sector with adjusted properties. And since this is a copy, there's no restrictions of what the respective fields may contain.

 

Share this post


Link to post
11 hours ago, esselfortium said:

FWIW, it is possible to do. ZDoom's transfer heights special allows for it.

Some quick questions: (Sorry for asking stuff that can probably be found elsewhere. I just want to verify a thing or two).

  1. What, specifically does ZDoom's 242 implementation provide beyond what Boom's 242 does? And, are the differences available in Doom format without scripts, or do I need UDMF format, Hexen format, or scripting, to get this new functionality?
  2. Is there any way to get an offline copy of the ZDoomWiki?
  3. I need a quick lesson on UDMF. In the Eternity Wiki, the linedef tables show columns UDMF# and Doom format #. So, if I want a PolyObj_StartLine in a Doom format map, I use LineDef #348, but if my map is in UDMF format, I use UDMF Linetype 1, and it's that simple?
  4. If 3 is True, and I make a UDMF map for, say, ZDoom, would I still use UDMF #1 for PolyObj_StartLine, or, is it possible that, in ZDoom, I might need a different UDMF number for PolyObj_StartLine?
  5. Does the Eternity Wiki include info for all the latest stuff (is it up to date?)

Thanks.

Share this post


Link to post

-alt-solo-net: loads multiplayer things in singleplayer, allowing the experience of -solo-net, but without elements many people have noted as kludgy, such as keys and weapons remaining even after you pick them up.

 

16 hours ago, Urthar said:

In terms of MBF Dehacked, the present lack of a generic projectile attack code-pointer seems like a major oversight.

 

This would be especially cool if you could specify the angle, a homing rate, and whether or not the projectile triggers infighting when it hits another monster (which is especially necessary with many types of 'wide angle'). Perhaps even splash damage. Nothing too extensive that it becomes anywhere near DECORATE level, but enough to have interesting new projectiles beyond 'stuff fired in a straight line towards the player'. 

 

Edited by rdwpa

Share this post


Link to post

Instant death sectors would be nice. Perhaps a generalized way to specify pain sector damage amounts, something like "Sector Damage according to Line Length."

Share this post


Link to post
2 hours ago, kb1 said:

I need a quick lesson on UDMF. In the Eternity Wiki, the linedef tables show columns UDMF# and Doom format #. So, if I want a PolyObj_StartLine in a Doom format map, I use LineDef #348, but if my map is in UDMF format, I use UDMF Linetype 1, and it's that simple?

It depends on the namespace.

 

ZDoom's "native" format is based on the Hexen map format, so it uses Hexen numbers, and that means 1 is PolyObj_StartLine. But it's also able to process maps through its xlat translator, so if you use the ZDoomTranslated namespace in UDMF it'll use Doom numbers and 1 is a door. (Or it could be just about anything, depending on whether you provide a custom xlat...)

 

Due to general lack of demand, there aren't editor configs made for the vanilla namespaces or for ZDoomTranslated, though they'd be simple enough to make if someone really wanted them. EE decided to use a ZDoom-compatible approach for its UDMF namespace which means, again, using Hexen numbers as a baseline.

Share this post


Link to post
4 hours ago, kb1 said:

Some quick questions: (Sorry for asking stuff that can probably be found elsewhere. I just want to verify a thing or two).

  1. What, specifically does ZDoom's 242 implementation provide beyond what Boom's 242 does? And, are the differences available in Doom format without scripts, or do I need UDMF format, Hexen format, or scripting, to get this new functionality?

 

It has a few options that can be set in a second arg. If you want to do the same with Doom-type specials you will have to use a different one for each option. If you look at the linked Wiki page, there's maybe only two types of real interest:

1) Ignore the upper part (Type 2)

2) Ignore upper part with sanitized texture usage and proper clipping of the fake sector. (Type 6)

 

The second one is what is optimal for defining actual water, i.e. it is the fake sector that defines the water surface texture (and that's all it defines, aside from the colormap) and only show it if it is above the real sector floor. These are also the only ones that ZDoom's standard XLAT exposes for Doom format maps.

 

 

 

Share this post


Link to post
3 hours ago, Benjogami said:

Instant death sectors would be nice.

 

Way back when E2 used a MBF port, customized by Joel Murdoch. Amongst some other stuff, it featured instant-death sectors (by setting its flag to 18) and even toggleable instant-death linedefs if crossed.

Share this post


Link to post
9 hours ago, rdwpa said:

-alt-solo-net: loads multiplayer things in singleplayer, allowing the experience of -solo-net, but without elements many people have noted as kludgy, such as keys and weapons remaining even after you pick them up.

Really good idea.

 

Maybe another thing to consider: -alt-fast. A gameplay modifier that does everything nightmare does except respawning monsters. Just because the little differences between fast and nightmare bug me.

Share this post


Link to post

Infinite height fixed. Blockmap fixed. Other bugs fixed. xBRZ resize added. Maintains demo compatibility.

Share this post


Link to post

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

 

“Boss Death” lock table

A new internal data table that stores a ThingID (column1) and a sector/linedef tag (column2) for the purpose of creating “upon death” or “upon pickup” actions for 1 or more specific ThingIDs in a map (without needing .EXE BossDeath alterations). The table is populated by ThingIDs that cross a WR linedef special. This function would allow in-map defined “Boss Death” actions from a single or group of monsters (and they need not be the same) to implementation of “waves” with actions triggering after completion.

 

  1. WR - Add to lock table (adds the ID of the activating monster, or item, and linedef tag to the lock table)
  2. When the monster is killed (or item picked up), it is removed from the lock table
  3. New linedef specials (x4)
  • D1 - Door open fast *if* tag is not present in lock table (column2). If present in table display "This object cannot be activated yet" to activator
  • S1 - Door open fast *if* tag is not present in lock table (column2). If present in table display "This object cannot be activated yet" to activator
  • DR - Door open, wait, close fast *if* tag is not present in lock table (column2). If present in table display "This object cannot be activated yet" to activator
  • SR - Door open, wait, close fast *if* tag is not present in lock table (column2). If present in table display "This object cannot be activated yet" to activator

New exit level linedef specials

New linedef specials to allow map changes to map slots specified by linedef tag. Expected tag format would be 2 digits (MM) and zero padded or truncated if required. Activation of linedef specials would set new variable (nextmapoverride?) to linedef tag, trigger exit of the level and override nextmap variable (wminfo.next?) as part of level completion routine.

  • S1 - Set “nextmapoverride” to linedef tag and exit level
  • W1 - Set “nextmapoverride” to linedef tag and exit level
  • S1 - Set “nextmapoverride” to linedef tag, reset inventory, health and armour for “pistol start”, and exit level
  • W1 - Set “nextmapoverride” to linedef tag, reset inventory, health and armour for “pistol start”, and exit level

 

Item teleportation

When items (a thing with “can be picked up” flag set) teleport via non-silent specials - they use DM item respawn fog and sound.

 

New teleport linedef specials

New linedef specials that choose a random teleport destination as found in all sectors with corresponding tag#

  • SR - Teleport random
  • W1 - Teleport random
  • WR - Teleport random
  • W1 - Teleport random (monsters only)
  • WR - Teleport random (monsters only)
  • SR - Silent teleport random
  • W1 - Silent teleport random
  • WR - Silent teleport random
  • W1 - Silent teleport random (monsters only)
  • WR - Silent teleport random (monsters only)

Some sort of reverse teleport? player crosses line and all items in tagged sector are teleported/given to them?

 

“Voodoo Doll” replacement v1 (stationary thing) - prompted by @esselfortium in the source ports thread

A new thing type that can activate all D(oor)/W(alkover)/S(witch)/G(unshot) linedef specials. It cannot be killed and can teleport using any/all teleport specials (ie: is considered both a player and a monster). Visually in an editor we could use a gold coloured player sprite so it still emphasises linedef activation but stands apart from normal player starts. A thing like this would better allow skill settings and MP specific actions by accessing the standard thing flags that player starts do not utilise.

 

It only activates D/S type specials when:

  • They are directly in front of it
  • Within activation range
  • Forward movement is blocked
  • After activating a D/S type special, no more D/S type specials are activated until the thing moves and is again blocked from moving (prevent immediate repeat activation of DR/SR specials)

G type specials activate on line of sight test (as if shot by player hitscan). The thing would attempt hitscan along thing direction every 18(?)tics (18 tics=.5 sec?)

 

“Voodoo Doll” replacement v2 (moving thing)

A new thing type that can activate all D(oor)/W(alkover)/S(witch) linedef specials. It moves at “doomguy walking pace”? continuously in the direction it is facing. It cannot be killed and can teleport using any/all teleport specials (ie: is considered both a player and a monster). Visually in an editor we could use a gold coloured player sprite so it still emphasises linedef activation but stands apart from normal player starts. A thing like this would better allow skill settings and MP specific actions by accessing the standard thing flags that player starts do not utilise. Being a moving thing would remove the need for conveyor specials to move the thing along. Additionally the “ambush” flag could be used to define the stationary behaviour in v1 described above.

 

It only activates D/S type specials when:

  • They are directly in front of it
  • Within activation range
  • Forward movement is blocked
  • After activating a D/S type special, no more D/S type specials are activated until the thing moves and is again blocked from moving (prevent immediate repeat activation of DR/SR specials)

New linedef specials allow basic “if/then” conditions

  • SR - Turn left 90 degrees
  • SR - Turn right 90 degrees
  • SR - If (light-level of sector that thing is in <= 0) then turn left 90 degrees
  • SR - If (light-level of sector that thing is in >=255) then turn right 90 degrees

Share this post


Link to post

Oh, one more idea that I'd love to have (the above post reminded me):

 

Voodoo Doll replacement "V3":

For teleportation. When it crosses a teleport linedef, the actual player is teleported as if he had crossed the line himself. That would be great IMO.

Share this post


Link to post
15 minutes ago, bzzrak said:

Oh, one more idea that I'd love to have (the above post reminded me):

 

Voodoo Doll replacement "V3":

For teleportation. When it crosses a teleport linedef, the actual player is teleported as if he had crossed the line himself. That would be great IMO.

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

Share this post


Link to post
4 minutes ago, esselfortium said:

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

Wouldn't it still be interesting for single player purposes regardless, while this problem could be avoided by not having/using it as a feature in MP maps? Or is it just not doable because of some inner quirk that would partially "break" maps?

Share this post


Link to post
1 hour ago, esselfortium said:

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

While we're adding hypothetical stuff to the engine, there's a possibility to work around this.

 

If you have a bunch of special voodoo doll mobjs (not extra player starts), you could have, say, 64 of them occupying a range of free editor number, let's say 13000 to 13063. (I think this range is free.) Add a new generalized line types that is for voodoo doll ownership. We have 64 (types of dolls) * 3 (activation types: W, S, G) * 2 (1 or R) = 384 combinations.

 

So how does it work? when a player triggers a voodoo doll ownership line, the corresponding voodoo doll gets associated to that player (e.g. puts it in its target pointer or whatever). Then effects triggered by the doll affect the owning player.

 

You could also have WR lines for the voodoo dolls to cross, for fine-tuning the effect: one that locks the owner (preventing another player from changing ownership by triggering the same line while the doll is on its conveyor belt), one that unlocks it (allowing players to once again claim ownership), and a last that clears the owner. A doll can pick up items only when it has an owner.

 

(Honestly I'd rather see Doom 64 macros get adopted, but at least with that setup voodoo dolls wouldn't hijack player starts and they'd allow to design for multiplayer.)

Share this post


Link to post
3 hours ago, traversd said:

“Voodoo Doll” replacement v1 (stationary thing)

“Voodoo Doll” replacement v2 (moving thing)

New linedef specials allow basic “if/then” conditions

Even though I personally prefer writing text scripts over creating conveyor-belt-based "pseudo" scripts out of map geometry, I consider it an awesome idea to enhance the engine with new behaviors / thing types / specials that will make it as easy as possible to create conveyor-belt-based scripts with unlimited possibilities to affect the game, including advanced algorithms that require a Turing complete system to implement them - I mean, conveyor-belt-based scripts are already Turing complete (capable of simulating any abstract algorithm in some way), but implementing advanced algorithms with them is often inconveniently complicated, and again, I'm talking about enhancing the engine to make things like that as easy as possible. To me, conveyor-belt-based scripts are a very interesting phenomenon in Doom mapping, and they should be helped to survive and prosper even after the arrival of regular text-based scripting, IMO.

Share this post


Link to post
On 5/14/2017 at 6:35 AM, Spectre01 said:

Infinite height fixed. Blockmap fixed. Other bugs fixed. ... Maintains demo compatibility.

I feel like you don't quite understand what these words mean.

Share this post


Link to post

^ His post isn't so self-contradictory if you interpret it as a request for options that can be toggled on when you want to play with bugs fixed and toggled off when you want to play with demo compatibility maintained. The two aren't possible at the same time, but they could still be made possible at different times in the same source port. 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. And if you want demo compatibility, use source port B, but you must accept the fact that source port B has no option to sacrifice demo compatibility for fixing bugs. It would be nice to have a single port that could support both, even if not both at the same time, just so you wouldn't have to change ports when you want to change how the game works, but just toggle an option.

Edited by scifista42

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
×