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

linedef to trigger wall-switch?

Recommended Posts

I'm wondering if there's a way to get a linedef (walk-over type) to change the state of a switch on a wall nearby.

What I'm going for is...I have a smaller dark room, the player enters, turns a corner and right as you turn the corner, you walk over this linedef that visibly and audibly changes a wall-switch so the player realizes that crossing that invisible line made something happen.

I looked here:

http://zdoom.org/wiki/Linedef

but I'm not seeing the kind of thing I'm looking for...

Share this post


Link to post

Thanks for the help, I'm hitting a problem I'm sure is common though.

Doom Builder/GZdoom builder show switches with some other wall texture, and if you mess with sectors and heights, you can "crop" it down to just the switch.

Over in Slade, it shows you texture SW1S0 (off) and SW1S1 (on) which is JUST the switch...so it looks like there's some other code that layers the switch on top of the wall textures, and gzdoom builder just treats them as one texture ( I guess?)

In any event, when I try to set that linedef to SW1S1 or SW1S0, it shows up as an unknown texture....so it's weird that in slade, you can only see the switches on their own and then in gzdoom builder you can only see the switches pre-added to wall textures and they're all named different things.

Share this post


Link to post

SW1S1 and SW1S0 are patches, not textures. You can't use patches as textures, unless you explicitly define them as textures via TEXTURE1 or ZDoom's TEXTURES. Mapping editors should only let you see textures, no mere patches, when you are selecting textures to assign to walls.

Share this post


Link to post

Ahh ok, I wondered if it was something like that...so if I'm to set a switch to a different texture (turning on or off) and that's defined in patches...how do I get a linedef to change its switch texture?

Share this post


Link to post

It is impossible to change the patch composition of a specific texture at runtime. But it is possible to change any linedef's texture to a different texture at runtime - via SetLineTexture. What you need is to change your linedef's texture to another texture which looks exactly the same as the original texture except that the switch patch is different.

Share this post


Link to post

So if I'm understanding this correctly..I need to find a texture that happens to display the switch as off by default, and another one that displays it as on by default?


Edit:
I've found
SW1STON1 (default off)
SW2BRIK (default on)


gounna give this a whirl..

Share this post


Link to post
volumetricsteve said:

Edit:
I've found
SW1STON1 (default off)
SW2BRIK (default on)

All switch textures in the official IWADs follow a naming convention ensuring that each "SW1*****" texture has a "SW2*****" counterpart and vice versa. They form identical pairs, only with the switch patch on/off. The ingame switch animation is actually performed by swapping these 2 textures at runtime, not by changing only the patch. So you'd better use either "SW1STON1" and "SW2STON1", or "SW1BRIK" and "SW2BRIK". Mixing them doesn't seem elegant at all.

(Note that this naming convention is indeed just an arbitrary naming convention, though. You can't define new switch texture animations simply by making your textures named SW1-something and SW2-something. But this was just off-topic, not related to your current issue.)

Share this post


Link to post

Oh....huh....I hadn't noticed that

So noted, I'll check for the right match. Oddly, now I can't seem to get the texture swap to work.

My code:

script 15 (void)

{
PrintBold(s:"script in loop");
SetLineTexture(5798, SIDE_FRONT, TEXTURE_MIDDLE, "-");
}


I threw in the PrintBold to make sure it was actually getting into the script, and that works fine.

However, the SetLineTexture configured as above should remove the texture, which should result in a hall of mirrors effect for the linedef I have it set to, I've also tried other texture names in there, but no change seems to take place.

I've confirmed that the texture I'm changing is the front and the middle...but still no sign of change.

Share this post


Link to post

That number 5798 in your code is probably a linedef index, not a line id. You must give the linedef a line id and use that id as a parameter for SetLineTexture.

Share this post


Link to post

is a line id like a tag?

going from this, i've found two numbers that /don't/ belong in the script.



I don't see a field that says line id here or in the properties, so i'm just taking random stabs. Thanks again for your help.

Edit:

AH. so it IS a tag. why don't they call of these things tags...since they're all addressed as tags in the editor? Anyway, I'm good now, thanks again!

Share this post


Link to post
scifista42 said:

SW1S1 and SW1S0 are patches, not textures. You can't use patches as textures, unless you explicitly define them as textures via TEXTURE1 or ZDoom's TEXTURES. Mapping editors should only let you see textures, no mere patches, when you are selecting textures to assign to walls.



Oh, but you actually CAN do that in ZDoom! Of course no switch is defined for them.

Share this post


Link to post
volumetricsteve said:

AH. so it IS a tag. why don't they call of these things tags...since they're all addressed as tags in the editor?

Now that I have looked at it, GZDoom Builder indeed refers to "line id" as a "tag". I'm pretty sure that GZDoom Builder didn't call them "tags" until recently. "Line ids" were a thing before GZDB even existed, the wiki documentation calls them that way, the UDMF specification calls them that way, so I also don't quite understand why the author of GZDB changed their name.

Share this post


Link to post
scifista42 said:

.... , so I also don't quite understand why the author of GZDB changed their name.


Tag numbers are often referred to as TID, a combination of tag and id.
I guess they can be called thusly interchangably.

Share this post


Link to post
Kappes Buur said:

To specify a lineid you use the Line_SetIdentification action special

Only if you're mapping in Hexen format. In UDMF, you set the "line id" property directly (as a "tag" in GZDoom Builder).

(I know that you know, Kappes Buur, I'm saying this for volumetricsteve.)

Kappes Buur said:

Tag numbers are often referred to as TID, a combination of tag and id.

I associate "TID" with "Thing ID". And I don't buy the argument that "tag" is supposed to be a literal simplification of "line id".

Share this post


Link to post

Tag is basically synonymous to ID. The norm is to call them "sector tag" and "line ID", but it could just as well be "sector ID" and "line tag", it wouldn't change anything. I think the difference in naming convention comes from the fact in Doom there are only sector tags, but line ID and thing ID were added by Raven Software in Hexen.

TID is explicitly "Thing ID".

Share this post


Link to post

People without technical knowledge about the engine apparently have problems understanding that linedef indexes are a different thing than line ids/tags when they first hear about them, understandably so. Every time something has more than one name OR when two different things have similar names, it leads to confusion whether there is actually a difference between meanings of the two terms or not. I consider that a case of bad naming.

Share this post


Link to post

I figured it was something going on engine-side that made all these things namned differently, but my perspective is...if they're all the same to the end user, they should be presented to the end user the same way. I like the idea that all of these arbitrary unique identifiers are called tags in the editor, that name makes as much sense as any other arbitrary ID name that I could imagine.

I see they used to be called line ids (etc) in the editor, and that'd be cool so someone unfamiliar would be able to more easily figure out what's going on if the naming were consistent. Seeing as how they're called one thing in the editor and something else in the engine is odd.

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
×