- Nov 4, 2019
- 13
- 0
TL;DR What are good patterns for preventing race conditions when using sequential logic?
----
I have a KOTH map with a lot of logic point entities. The operations these entities perform must be completed in a certain order, based on which team caps the point and when.
Previous versions of this map have created race conditions regarding the map's logic that I am unsure how to prevent in the future. Currently I have "fixed" these race conditions using delays, but all that really does is make the race conditions less likely to happen. I would like to know if there is a way to ensure operations are executed in a specific order using Hammer's I/O system.
For example, I need to set a model's animation BEFORE I change the playback rate on said animation. If I set the playback rate first, changing to a new animation will automatically reset the playback rate to 1.
I can fire the SetPlaybackRate output with a delay of 0.01s after SetAnimation, but what if SetAnimation ends up taking longer than 0.01s? I can set the delay higher, but what if SetAnimation ends up taking longer than to whatever value I set the delay?
The only potential solution I can think of is to use two relays. The first relay calls SetAnimation and triggers the second relay. The second relay calls SetPlaybackRate. In this situation, is it guaranteed that SetAnimation occurs before SetPlaybackRate, assuming no command is delayed?
Are there any real solutions to prevent these types of race conditions, or are delays the only way to deal with them?
----
I have a KOTH map with a lot of logic point entities. The operations these entities perform must be completed in a certain order, based on which team caps the point and when.
Previous versions of this map have created race conditions regarding the map's logic that I am unsure how to prevent in the future. Currently I have "fixed" these race conditions using delays, but all that really does is make the race conditions less likely to happen. I would like to know if there is a way to ensure operations are executed in a specific order using Hammer's I/O system.
For example, I need to set a model's animation BEFORE I change the playback rate on said animation. If I set the playback rate first, changing to a new animation will automatically reset the playback rate to 1.
I can fire the SetPlaybackRate output with a delay of 0.01s after SetAnimation, but what if SetAnimation ends up taking longer than 0.01s? I can set the delay higher, but what if SetAnimation ends up taking longer than to whatever value I set the delay?
The only potential solution I can think of is to use two relays. The first relay calls SetAnimation and triggers the second relay. The second relay calls SetPlaybackRate. In this situation, is it guaranteed that SetAnimation occurs before SetPlaybackRate, assuming no command is delayed?
Are there any real solutions to prevent these types of race conditions, or are delays the only way to deal with them?