Why does my ‘switch.wav’ sound play after a state change?
Is it not the case that it should only play if Level detector on my always sensor would be set?
Thanks for your answers.
Edit:
To be a bit more precise:
The sound actuator only gets activated after the player leaves the near sensor.
So, I guess the timer sensor gets triggered somehow. But I dont get it. Why?
Whenever you enter a state, it will evaluate all the sensors for that state. Hence, even if the property value changed in a different state, when you return to the state with the property sensor, it will be triggered.
The level option is used in situations where sensors are shared across states, so that the same sensor will trigger the controllers of the new state (if the condition of the sensor is met, e.g a key is pressed), because it caused a change of state. Otherwise, shared sensors will not trigger the new controllers because they already triggered the previous frame.
The same behaviour can be mimicked by creating a new sensor for each state.
It seams that the property sensor triggers on activation (after state change).
I did some tests:
sensors ignoring activation:
keyboard
mouse button
sensors triggering on activation:
property
collision
always
delay
message (this triggers on all messages regardless the settings)
mouse movement (triggers on all movements regardless the settings)
mouse over (any)
near
radar
ray
others:
random is untestable
action (I have not tested this)
This behavior does not match my expected behavior. in my eyes it makes no sense. Why do I have a configuration when it is ignored? Therefore I think this can be declared as a bug.
Someone might argue this is the most common situation. That is true, but … with that implementation it is impossible to configure the other configurations. I think it would make more sense to get the most common situation configured as default setting. That means when I add a sensor (or change the sensor type) the according buttons gets set automatically. This way I can explicitly disable them when I want. [this is just a proposal].
I wonder why I did not notified that before?
I guess I just tested with keyboard sensors. In other cases I used Always sensors … with [Level] enabled.
Finally I think there are workarounds to deal with that situation. But still it feels inconsistent.
Sensors are evaluated each frame and triggered for a number of reasons, most commonly if their previous state no longer is their current state. Keyboard and Mouse sensors will trigger if their event changes from active to inactive, i.e if their state is JUST_ACTIVATED or JUST_RELEASED. I believe that this is to enable users to detect when events happened, rather than being unable to detect this. The property changed sensor doesn’t have any system to detect the event when the property was changed, so it must do it manually, which means that the triggering only happens when the state becomes active.
In summary, this seems more of a feature than a bug, but needs better explanation.
That is the point, the evaluation state did not change. The property is still the same as it was in active state. Activating the sensor is not a change of the evaluation result. Therefore the sensor should not trigger unless the Level-flag is enabled.
I see it that way if you enable the Level-flag the sensor should trigger when the evaluation is positive and the (logic) state changed. But the above sensors do exactly that regardless of the Level-flag. Therefore it is not possible to disable that behavior by disabling the Level-flag … as it is disabled already.
If that is the wanted behavior we can remove the Level-flag as it has no function.
It seems I getting old … no wait … I remember - I just forget a lot of things ;).
Edit: strange. The bug is closed as invalid but still there are code changes. This makes a bit hard to guess what these “unwanted effect” are. Anyway thanks for the investigation.