Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
DaniJ

BOOM generalised lines

Recommended Posts

Ok I need to know a couple of things about Boom's generalised lines:

If I use a move floor line where the target is Highest Adjacent Floor is this an absolute or does it depend on the direction (up/down)?

For example if I set that to up and my target sector's floor is at 256 but the highest adjacent floor is lower (128) what happens - Does it not move or does it actually go down?

How about if the target floor is 256 and it has one adjacent floor that is 128 and another that is 384: the one that is chosen as the destination height depends on the 'move direction'(up/down) set in the line, correct?

Share this post


Link to post
DaniJ said:

For example if I set that to up and my target sector's floor is at 256 but the highest adjacent floor is lower (128) what happens - Does it not move or does it actually go down?

I checked BOOMREF.TXT and it says: if the floor is moving up but the computed target is lower then it jumps instantly down.


How about if the target floor is 256 and it has one adjacent floor that is 128 and another that is 384: the one that is chosen as the destination height depends on the 'move direction'(up/down) set in the line, correct?

No, if it's highest-neighbour-floor then it's always 384. So if the floor is lowering, it will jump instantly up.

This is based on my understanding of BOOMREF.TXT anyway.

Share this post


Link to post

So it's not that clever then. A bit annoying from my point of view as I would have logicaly expected it to do what I described. Oh well.

I forgot about BOOMREF.TXT... I'll check there first for my answers.

Is there anything odd that you can think of that has been abused by users regarding Boom's gen lines behaviour that I should watch out for/keep in mind while planning Boom support for jDoom?

Share this post


Link to post
DaniJ said:

Is there anything odd that you can think of that has been abused by users regarding Boom's gen lines behaviour that I should watch out for/keep in mind while planning Boom support for jDoom?

I personally haven't seen many maps with generalised types, so I dunno about users doing weird things, but another counter-intuitive thing are the line-to-line teleporters: if you wanted the player to end up facing in exactly the same direction, the target linedef must be rotated 180 degrees compared the source linedef. IOW, if both lines were parallel, the player is flipped 180 degrees.

There's a wad called BOOMEDIT.WAD with quite a few generalised types in it. I could send you a copy if (or when) you want it. Two other boomy wads are RAGE and DAWN (IIRC), I think they come in one of the Boom binary packages (I've lost my copy of them).

Share this post


Link to post

Thanks.

If you could send me a copy of BOOMEDIT.wad that would be great (my email is in my profile).

EDIT:
How are the these meant to be used?
271 = " Transfer Sky Texture to Tagged Sectors";
272 = " Transfer Sky Texture to Tagged Sectors (flipped)";

I tried them on a linedef in a sector with F_SKY1 ceiling, tagged the line to an ordinary sector (ceil FLOOR7_2) but nothing happended in my tagged sector.

I checked BOOMREF it doesn't help on this one.

Share this post


Link to post

To use transfer sky you tag the sector you want to receive the sky (ceiling must be F_SKY1). It will then take the main texture from the line with the action and tag and use it as the skybox, instead of the default one for the level. I used this trick in Community Chest 2 Map 26 to use a non-default sky (as did many other mappers).

Share this post


Link to post
Ajapted said:

I personally haven't seen many maps with generalised types, so I dunno about users doing weird things, but another counter-intuitive thing are the line-to-line teleporters: if you wanted the player to end up facing in exactly the same direction, the target linedef must be rotated 180 degrees compared the source linedef. IOW, if both lines were parallel, the player is flipped 180 degrees.


That makes sense when you think about their normal use. You want to be able to go back and forth across such a teleporter, don't you?

Share this post


Link to post
DaniJ said:

Thanks.

If you could send me a copy of BOOMEDIT.wad that would be great (my email is in my profile).

EDIT:
How are the these meant to be used?
271 = " Transfer Sky Texture to Tagged Sectors";
272 = " Transfer Sky Texture to Tagged Sectors (flipped)";

I tried them on a linedef in a sector with F_SKY1 ceiling, tagged the line to an ordinary sector (ceil FLOOR7_2) but nothing happended in my tagged sector.

I checked BOOMREF it doesn't help on this one.



You won't find any information in BOOMREF becasue these types are from MBF . Here's the original documentation from MBF's extended version of BOOMREF.TXT:

=== New to MBF ===

271 Ext -- Transfer sky texture to tagged sectors
272 Ext -- Transfer sky texture to tagged sectors, flipped

These linedefs transfer wall textures to skies. F_SKY1 must still be used as
the floor or ceiling texture in the sectors for which sky is desired, but the
presence of a 271 or 272 property-transfer linedef can change the sky texture
to something other than a level-based default.

Every sector with F_SKY1 floor or ceiling which shares the same sector tag
as the 271 or 272 linedef will use a sky texture based on the upper texture
of the first sidedef in the 271 or 272 linedef. Sectors with F_SKY1 floors or
ceilings which are not tagged with 271 or 272 linedefs, behave just like Doom.

Horizontal offsets or scrolling in the transferred texture, is converted into
rotation of the sky texture. Vertical offsets or scrolling is transferred as
well, allowing for precise adjustments of sky position. Unpegging in the sky
transfer linedef does not affect the sky texture.

Horizontal scrolling of the transferred upper wall texture is converted into
rotation of the sky texture, but it occurs at a very slow speed relative to
the moving texture, allowing for long-period rotations (such as one complete
revolution per Doom real-time hour).

Effects other than sky-transfer effects are not excluded from the affected
sector(s), and tags can be shared so long as the effects are unambiguous.
For example, a wall-scrolling linedef can share a sector tag with both its
affectee linedef (the one being scrolled), and with the sector that the
latter controls. There is no ambiguity because one effect (scrolling) applies
to a linedef, while the other effect (sky transfer) applies to a sector.

If a sector underneath a special sky needs to be set up to have a different
purpose (for example, if it is a lift or a stairbuilder), then two tags will
need to be created, and the transfer linedef and any scrolling linedefs will
need to be duplicated as well, so that the same effect as far as the sky goes,
is duplicated in two separate sector tags. This will not affect sky appearance,
but it will allow a special sector which needs a unique tag, to sit under such
a sky.

Animated textures may be transferred to skies as well.

In Doom, skies were flipped horizontally. To maintain compatibility with this
practice, the 272 linedef flips the wall image horizontally. The 271 linedef
does not flip the wall image, and it is intended to make it easier to take
existing non-flipped wall textures and transfer them to skies.

Sky textures which are different must be separated by non-sky textures, or
else the results are undefined.

Share this post


Link to post
Guest
This topic is now closed to further replies.
Sign in to follow this  
×