Hi.
I have got a problem with TRS2019 (build 96000) , TRS2019 BETA (build 97420) that exist also with Tane SP3 BETA (build 97285) but did not exit (works fine) under Tane SP3 (build 94916).
The problem is with the rule Interlocking Tower Enhanced Manager ( <kuid2:61392:8130:54> ) that enables to edit properties of any Interlocking Tower or Enhanced Interlocking Tower available on the current route and session from a centralized rule. Every thing works while your are editing the towers using the rule, but when you save after edition your session, the updated data is lost when you later reload the session (in build 96000 - 97420 - 97285 / works fine in 94916).
After debugging a little, it seems that now when you edit only a rule and do no other updates in surveyor, the system optimises the next session save operation by saving only the edited rule data and not saving at all any other objects, while in previous Tane SP3 build 94916 the save operation saves both all the rules data but also all the objects data inside the session.
The particularity of Interlocking Tower Enhanced Manager is to be a rule that edits some other objects data, which means that when you finish your rule edition the updated data is not inside the rule but is spread over all the other objects edited with the rule. This works fine only if when saving a session, all the data is saved : both the rules data and also all the interlocking tower objects data, as it is done under build 94916. But as now the save operation does save only the rule data and no longer the other session objects like the edited interlocking tower objects data, all the edition is lost, which makes now the rule loose most of its interest. …
I wonder if this new behavior during save operation is a bug, or is an optimisation wanted by N3V to reduce the volume and the time needed for a save operation. I may understand the idea of optimising save operations by limiting the data saved to only the session data updated, but in the case of rules you have some rules that updates other objects data and limiting the data saved to only the internal data of the edited rules makes the data saved incomplete.
If this optimisation exists, at least, we need the possibility from a rule script to tell Trainz which other objects data have been modified and need also to be saved in next save data operation.
Thanks to N3V team to say if it is only a bug or if it is a side effect of some new optimisation done in TRS2019 and Tane SP3 Beta for save operation. And for my rule, do I only need to wait for the fix ? Do I need to use some undocumented interface to tell Trainz which objects have been updated and need to be saved during next save operation ? Or do I need to rethink totally how the interlocking towers enhanced monitor run to save the updates inside the rule data, and consolidate later the previous existing interlocking tower data inside the tower objects with the modifications saved inside the rule (can be done, but much more complex to implement and may be not so performant).
A copy of this post will be send also as beta bug report, so that it is traced and not forgotten whatever will be the answer.
Regards.
Pierre.
I have got a problem with TRS2019 (build 96000) , TRS2019 BETA (build 97420) that exist also with Tane SP3 BETA (build 97285) but did not exit (works fine) under Tane SP3 (build 94916).
The problem is with the rule Interlocking Tower Enhanced Manager ( <kuid2:61392:8130:54> ) that enables to edit properties of any Interlocking Tower or Enhanced Interlocking Tower available on the current route and session from a centralized rule. Every thing works while your are editing the towers using the rule, but when you save after edition your session, the updated data is lost when you later reload the session (in build 96000 - 97420 - 97285 / works fine in 94916).
After debugging a little, it seems that now when you edit only a rule and do no other updates in surveyor, the system optimises the next session save operation by saving only the edited rule data and not saving at all any other objects, while in previous Tane SP3 build 94916 the save operation saves both all the rules data but also all the objects data inside the session.
The particularity of Interlocking Tower Enhanced Manager is to be a rule that edits some other objects data, which means that when you finish your rule edition the updated data is not inside the rule but is spread over all the other objects edited with the rule. This works fine only if when saving a session, all the data is saved : both the rules data and also all the interlocking tower objects data, as it is done under build 94916. But as now the save operation does save only the rule data and no longer the other session objects like the edited interlocking tower objects data, all the edition is lost, which makes now the rule loose most of its interest. …
I wonder if this new behavior during save operation is a bug, or is an optimisation wanted by N3V to reduce the volume and the time needed for a save operation. I may understand the idea of optimising save operations by limiting the data saved to only the session data updated, but in the case of rules you have some rules that updates other objects data and limiting the data saved to only the internal data of the edited rules makes the data saved incomplete.
If this optimisation exists, at least, we need the possibility from a rule script to tell Trainz which other objects data have been modified and need also to be saved in next save data operation.
Thanks to N3V team to say if it is only a bug or if it is a side effect of some new optimisation done in TRS2019 and Tane SP3 Beta for save operation. And for my rule, do I only need to wait for the fix ? Do I need to use some undocumented interface to tell Trainz which objects have been updated and need to be saved during next save operation ? Or do I need to rethink totally how the interlocking towers enhanced monitor run to save the updates inside the rule data, and consolidate later the previous existing interlocking tower data inside the tower objects with the modifications saved inside the rule (can be done, but much more complex to implement and may be not so performant).
A copy of this post will be send also as beta bug report, so that it is traced and not forgotten whatever will be the answer.
Regards.
Pierre.