Talk:Point angularvelocitysensor

From Valve Developer Community
Revision as of 11:09, 9 June 2007 by Angry Beaver (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The AngularVelocity output of the point_angularvelocitysensor is fired like ten times per millisecond when the angular velocity changes. Does someone has an idea on how to prevent it from flooding the engine ? --NykO18 16:21, 7 Jun 2007 (PDT)

maybe you could include a logic_timer thats your sampling frequency and just disable the target entity cause it looks like this doesn't have an enable/disable to target it directly... I'd code you a fix but that may not work depending on what your doing. --Angry Beaver 16:28, 7 Jun 2007 (PDT)

Hmm, I'm trying to increase/reduce the pitch of a sound depending on the angular speed of a given func_physbox constrained to a phys_hinge and since it's a sound, I can't stop the pitch from beeing changed. You could possibly code something yes, but I believe it wouldn't be useful for a standard HL2 map.. and I don't want to make a mod, this is just a map. The thing is that it works somewhat great, but due to the overwhelming amount of outputs sent by the point_angularvelocitysensor, the ambient_generic doesn't know how to deal with it and the inputs are treated in a chaotic order. I tried to use several point_angularvelocitysensor with the OnGreaterThan and OnLesserThan outputs, but it doesn't work because : when the physbox is turning at a speed of 150 degrees per second, it triggers the angularvelocitysensor for the "10 degree step", the "20 degree step", the "30 degree step", and so on.. --NykO18 17:35, 7 Jun 2007 (PDT)

Theres no possibly about the coding a fix I know exactly what I'd do, the entity would gain a frequency property and then if it tried to fire before the frequency timer had elapsed then it wouldn't fire. but thats neithier here nor there as it doesn't help inside regular HL2 DM. As for fixing your problem directly why not force the engine to slow it down... use a math_counter SetValueNoFire it with the new number to be used. Then using a logic_timer Add 0 at a given time preiod. The math_counter will be set up so it OutValues to the sounds pitch, it wont fire before hand as we were SetValueNoFire which doesn't trigger OutValue. It wont deal with the chaotic order thing well but at least it will smooth out what the player hears. --Angry Beaver 23:49, 7 Jun 2007 (PDT)

point_angularvelocitysensor AngularVelocity → math_remap InValue
math_remap OutValue → ambient_generic Pitch
You leave the parameters blank to pass the original AngularVelocity. For math_remap you set in1 to the lowest angular velocity that enables the sound and in2 to the highest angular velocity that should produce the highest pitch...out1 would be some initial pitch that you want and out2 is the highest pitch. You can also make it so when you get OnLessThan in1 you stop the sound and OnGreaterThan in1, you enable the sound (Put logic in between to make sure the sound is already playing/stopped)—ts2do 23:51, 7 Jun 2007 (PDT)
@Angry Beaver> Ok, I'll try your solution asap and let your know about the result.
@Ts2do> Yeah, that's exactly what I'm doing right now, and that's exactly where the problem is. You should read my first paragraph again.
--NykO18 05:36, 8 Jun 2007 (PDT)
@Angry Beaver> Ok, I tried, it does not work. The problem is really the point_angularvelocitysensor, who is sending way too much outputs. Filtering these outputs to catch only one every 0.25 or 0.5 second doesn't prevent the game from lagging because of this stupid huge number of outputs sent. I don't really know what I'm supposed to do right now. --NykO18 13:12, 8 Jun 2007 (PDT)
Theres not much to be done then, the entity doesn't have enable/disable input or anything to stop it from generating all these inputs while it present... The only thing you might be able to do is have it tied to a point_template then ForceSpawn a version of it every time you want to sample (which is tied to your timer). Then just have the entity kill itself once its given you the sample with a !self kill output. That way it wont be around to generate all the outputs that slow things down. --Angry Beaver 14:40, 8 Jun 2007 (PDT)

Try increasing the threshold—ts2do 16:34, 8 Jun 2007 (PDT)

Increasing the threshold wont decrease the number of outputs generated by the entity which is the major problem as it slows the system down. --Angry Beaver 17:06, 8 Jun 2007 (PDT)
Would adding a "delay before reset" keyvalue with "1" set work in this case? Solokiller 04:21, 9 Jun 2007 (PDT)
It would/might if delay before reset was present on any of the entities involved in the problem. Depends which entities had it but none involved in the setup do, thats part of why a fix could be coded but you cant inject new code into a HL2DM level. --Angry Beaver 11:09, 9 Jun 2007 (PDT)