Page 1 of 1

[0.14.21] on_train_changed_state does not always fire

Posted: Wed Dec 21, 2016 7:37 am
by Optera
When adding/removing carriages to an automatic train parked at a train stop it switches to manual without raising on_train_changed_state.
Expected behavior would be to raise on_train_changed_state(event.train.state = defines.train_state.manual_control)

Re: [0.14.21] on_train_changed_state does not always fire

Posted: Wed Dec 21, 2016 8:04 am
by Rseding91
In that instance the state is not changing. The old train is deleted and a new train in a different state is created. Thus no event is fired.

That's expected behavior.

Re: [0.14.21] on_train_changed_state does not always fire

Posted: Wed Dec 21, 2016 4:28 pm
by Optera
Is there an on_create event fired or do you have to check for this in on_tick?

Re: [0.14.21] on_train_changed_state does not always fire

Posted: Wed Dec 21, 2016 4:33 pm
by Nexela
Optera wrote:Is there an on_create event fired or do you have to check for this in on_tick?
You should be able to find some ideas on how to handle this by looking at smart-trains mod or stdlib/trains stuff.

Re: [0.14.21] on_train_changed_state does not always fire

Posted: Wed Dec 21, 2016 8:31 pm
by Optera
Nexela wrote:
Optera wrote:Is there an on_create event fired or do you have to check for this in on_tick?
You should be able to find some ideas on how to handle this by looking at smart-trains mod or stdlib/trains stuff.
Quite some hacks needed to get a train stop notice changed train states reliably through on_built_entity, on_preplayer_mined_item, on_entity_died.
It still feels like on_train_changed_state should fire when creating a new train with the same unit numbers, backer names and object references.