Make a brush come and go.

(=PoW= Kernel 2.6.5) #1

Hi all,

This is another question based on the fact that I can’t find any info on the properties of objects.

I want to make a brush and a misc_model go away and come back in a script.

I can make a trigger_hurt brush invisible with:
setstate brushname invisible

This is not working for a detail brush that is in a func_group and not working on misc_model.

So how do I make the brush and misc_model go away and comeback in a script. I need these items to not only be unseen, but also not block a players path.

Thanks

(Shaderman) #2

You could make the brush a script_mover and use a misc_gamemodel instead of a misc_model and setstate them.

(Ifurita) #3

Correct, you need some sort of scriptable entity for the brushwork to appear/disapper (func_contructible, func_static, script_mover, etc). For models, you have to use misc_gamemodels. misc_models are baked into the bsp and aren’t dynamic.

(=PoW= Kernel 2.6.5) #4

Thanks,

I’ll try your suggestions.

Why won’t a func_group work?

(Ifurita) #5

because a func_group is an editing entity, not a run_time entity. Another example are lights. You see them in the compiler, but after you perform the light compile, they go away, being replaced by the light map. Try decompiling a map, you’ll notice that all of your func_groups are gone.

(=PoW= Kernel 2.6.5) #6

Well, your suggestions worked.

In the process I discovered a new problem.
Rather that spam the forums with a new thread I’ll state my finding here.

I made a func_door that opens with a remote func_invisible_user.

The info for the func_door states that when the entity is assigned a targetname, no touch field will be spawned.
This does NOT seem to be true.

I can activate the door from both my func_invisible_user and from the door itself.

I only want to door to work with the remote switch since it also triggers a script related to the topic above (hiding brushes).

It would seem I have to make the door locked, then have the func_invisible_user 's script unlock the door and activate it.
This really seems like the long way around.

Someone else on the forums asked a similar question and was told to use a script_mover.
That seems like overkill since I’m 99% of the way to what I need my door to do.

So can I get rid of the touch field on the door like the entity info says I can or will I have to use a script_mover instead of a func_door ?

Thanks again - you all have been a big help.

(BTW Iifurita - I like Byzatine and we play it a lot on =Shit-Storm=Exterme)

(kamikazee) #7

Well, in that thread we’d advise him to a script_mover since he wanted to get rid of the ‘locked’ symbol popping up when you approached the door.
If you don’t get the ‘locked’ symbol but an ‘activate’ hint, you probably set the ‘key’ property. Remove it if so.

(=PoW= Kernel 2.6.5) #8

So… what you’re implying is that there is NO WAY to remove the touch field from a func_door
even though it says you can in the entity information.

(kamikazee) #9

You can. Make sure the touch box isn’t checked, and that targetname is the only key/value pair it has.

(=PoW= Kernel 2.6.5) #10

That’s what I did but the door still has a touch field.
Give it a try and see it it’s the same for you.

I have NOT updated my entities.def file.
I am using the one that came with GTKRadiant 1.4.
Not sure if this mattered but figured it was worth mentioning.