Quick question on func_button

[Mystic Monkey]

Just a quick question, what number should I set speed if I want the button to move instantaneously?

To sum it up I had these elaborate brush-made containers that automatically break when attacked or touched and give an item. But given how many brushes they were made from (about 12-20 or so parts) they were a bit to elaborate constructs so I eventually figured out how to make and import models to replace them.
However I dunno how to make a prop_dynamic have the same functions as a func_breakable and even though I figured out how to break them their hit boxes are naff for some reason and cause some player harm.

So instead, I replaced the multiple_trigger and web of outputs with an invisible func_button which is now the containers hit box and surprisingly convenient as I no longer need the multiple_trigger anymore given it can be both touch and attack activated.

The only problem is it's not fast enough. I set the Delay for 10 seconds (the container itself respawns after 10 seconds) and Lip for -10 because I couldn't figure out how to make the button non-solid for 10 seconds, that and want to prevent accidental activation during it's 10-second hiatus.
Setting it to 9999 does make it go fast... so fast it breaks it and the switch cannot reset after its delay
But the movement of the button is too slow, even with the Speed set to 0 which I figure would make it instant, the button slides up a second or so after the container respawns.

[Mystic Monkey]

Originally posted by cshotgspot:

https://developer.valvesoftware.com/wiki/Prop_physics]Prop_physics entities have a "Break on Touch" flag, and can be configured to break once their health reaches zero. Given what you've written, this seems like an easier method to accomplish the desired result.

However, if you specifically want to use a func_button entity, there's a "Don't move" flag that prevents the button from moving.

I will experiment more with prop_physics given it does show potential as a more easy route (though for some reason ithe prop_physics is gone wen I run the game.)

But there are two problems with going with "Break on Touch" method.
1. Depending on how fast the player runs into the object it cause them about a point or two of harm. Even with a close-range trigger_multiple telling the object to break.
2. While I'm sure I did the models _physics.smd properly, when it comes to shooting the model as an alternative to break it open you have to hit it at some correct spot. Dunno what I goofed up with with that.

Using func_button is ideal alternative given it can have both Touch and Damage Activates to allow simple methods of trigger and serve as a hit-box for the object.

However, I do not know how to make the func_button become temporary non-solid for ten seconds. The only alternative way to do so would be the use of Delay which along with Lip allows the button to hide in the ground.
So ticking "Don't move" will not allow the func_button to hide.

But if I set the speed to slow then the button will lower and rise too slowly to sync with the containers respawn (and hitting when it's lowering still outputs to the point_template allowing it to spawn multiple containers over one another)
Or if I set it too fast then the button will only work once.

[Stonewool Jackson]

Why not use the same respawn system on the container and button?

[Mystic Monkey]

That's (sort of) what I did in the end.

I made the func_button serve as both activation and hitbox to the item I wanted to break and figured out how to make the buttn "hide" underground whenever activated and come up whenever the object respawned. This efficiently prevented the player getting stuck in the item box whenever it respawned and also prevented causing 1 or 2 points of harm whenever the item box breaks.

Having the func_button as a still button that breaks along with the item box also works as long as the point_template has the button included.

The only downside, as far as my testings go, is that you can't give outputs on the itembox that is suppose to break, it cause a delay in the first break but not in later breaks. Instead give all the outputs to the func_button instead.

[gumballᒷ⊣ᔑꖎ]

try using it as a parent

[Mystic Monkey]

That was going to be an alternative, but I have the matter sorted now.
I just can't (✔) my own posts.