func_door bug?

[Gringo_Starr]

Sorry, but I couldn’t think of a much better subject line. Here’s the situation. I have alpha railings which I made into a func_door, so I could use the shoot_thru_scale key on them. Of course I don’t want them to work like a door, or spawn a touch field, so I added a targetname to it. In a previous version of Gtk/Q3map2, it worked as implied. But, using 2.5.11, it now works like a door even though it is targetted. I don’t really need help making a workaround, I just wanted to help figure out why it happens. I don’t know if it’s not just related to Gtk somehow.

[phobos]

Post the entity from your .map file. Compare that with an old map if you have one. GTK just writes the output, it’s only an editor.

[Gringo_Starr]

Other than the order, it’s the same.

Old:

// entity 696
{
“classname” “func_door”
“targetname” “railings”
“type” “4”
“shoot_thru_scale” “.69”
// brush 0

New:

// entity 117
{
“shoot_thru_scale” “.69”
“type” “4”
“targetname” “railings”
“classname” “func_door”
// brush 0

[Hewster]

mmm… well I’ve had a look at this again Gringo, and it looks like my original assumption that
“shoot_through” is not a viable key in is true. (this is for RtCW)… I’ve looked at the
source code again, and can not find it being tested for, or used anywhere except in the
description of the func_door

I have taken a look at your old map, and tried shooting through the railings, and found that
bullets always pass through with full power, ie no reduction.

I have built a test map, and tried compiling with various Q3map2’s, and still the same result,
I get a door with a hint that stops bullets.

In conclusion I think you may have had some kind of bug in your original map,
and the railings were not being compiled into a func_door, and thus didn’t work as a door.
In your new map, the railings are being compiled into a func_door, and so are acting as one

I may be wrong, if so, someone please show me where the shoot_through key
is tested for in the code

Hewster

[ratty_redemption]

@Gringo Starr, I know you said you didnt need help with a workaround, but is there a reason you couldnt use a func_static, instead of a func_door?

and if you then had a nodraw, weapon clipping script_mover that moved into the position of the railings every few seconds, that might let some bullets through while blocking others, yes?

Id like to know of a way to do this if that key doesnt work in rtcw.

edit: I`ve personally had np with the q3map2.5.15 version, so is there a reason your still using 2.5.11?

[Gringo_Starr]

@Ratty I’m not using 2.5.15 because I don’t want to break my current version (from my own inexperience with the dll’s and stuff). I will look into that soon.

@Hewster There’s one problem with your logic though Hew. If it wasn’t being compiled as a door, and it was just nodraw texture, bullets wouldn’t pass thru! Touche! And who’s side are you on dude?

I already changed it in the map. I just put a clip texture on the railings, so every weapon now goes thru. No biggie.

[ratty_redemption]

@Gringo Starr, understood but it`s really not that difficult to have multiple q3map2 folders and point radiant to which ones we want to compile with.

either by the editing the paths in the .proj and .game files in the script or radiant folders, or by using multiple bat files with different paths.

[Gringo_Starr]

Maybe changing to Radiant 1.4 did it somehow? Seriously guys, I didn’t change anything with that entity, and I’m not trying to make anyone look foolish. But, you can imagine what a jackace I looked like when my railings took off across the map! I guess this is the payback I get for being crafty with entities.

[Gringo_Starr]

Ratty, if I have problems when I DO upgrade, I’ll come callin’! Thanks dude.

I’m not that concerned with the shoot_thru_scale. I’m more concerned that a targetted entity was not functioning as stated. Imagine a door previously targetted by a script or some other entity, which can all of a sudden be used directly by the player to gain access to some restricted area on the map. Ok, fat chance, but it could theoretically mess up some maps.

Don’t map files usually get corrupted, not fixed? I’m just busting your chops a bit Hew.

[ratty_redemption]

np and understood, and occasionally throughout my years of mapping and modding Ive seen some very odd things happen in my own maps, similar what youve just encountered or even worse, its not as bad when its just us who find the bugs, but when in a public release, that is cringe and bad head on desk time

[Gringo_Starr]

Well, luckily the WildWest crew is always willing to help test. Shout out to Ignacio, who actually found it (even though the cursorhint appears from about 5 feet away!) lol That’s another thing. I put “cursorhint” “hint_none” on it, yet it still gives me a cursor. I guess I’ll steer clear of func_doors!

[Gringo_Starr]

Still don’t know what it is. I compiled the old map file, but that too has the same effect. Maybe you’re right Ratty, it’s just one of those things. Notice I did put a question mark after the bug in the subject.

[SCDS_reyalP]

yup, in my experience neither shoot_thru_scale nor hint_none work on doors. If you are getting unpredictable brush behavior in different builds it is more likely a content param issue, where the ‘first’ plane in the brush is defining the contents. Or maybe a bad brush.

The editor certianly has no influence on this (aside from reordering the planes every time you save), and it seem unlikely that the compiler would either. Hmm, is the compiler responsible for making the trigger around func_doors, or does gamecode do that ?

[ratty_redemption]

@reyalP, good point about the reordered and mixed content parms, that probably does explain some of the random type things we`ve seen in the past, including the well know nodraw water bug.

[SCDS_reyalP]

indeed, greping the q3map source for func_ makes it seem like func_group is the only func_* entity that the compiler does anything specific with.