-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Path reservation fixes #115
base: master
Are you sure you want to change the base?
Conversation
10a058e
to
4af18d8
Compare
1873009
to
5b1a08a
Compare
Maybe we can add some tests to check e.g. reservation and changing state of a direction tile while it is reserved. |
I created a small test for the direction tile state change while it is reserverd, can you apply the patch to you branch? I zipped it because GitHub refuses to attach the PATCH file...but the error explains that PATCH is supported 🤷🏼♂️ |
Hi, I've applied your patch. |
Awesome. It is indeed required to be adjacent to a block but, passive tiles are ignored. On the |
What about bridges? In my test board it didn't work if a bridge was inbetween NX button and block tile.
PS. Let's see ho replying by mail works out...
Il 25 aprile 2024 19:39:20 CEST, Reinder Feenstra ***@***.***> ha scritto:
…Awesome.
It is indeed required to be adjacent to a block but, passive tiles are ignored. On the `boardModified` event a new graph network is built of the board. It only creates nodes for tiles that have a function, passive tiles like straight en curved rail pieces are ignored. So for a NX button there may be straight/curved rail pieces between them, but not something like a signal/turnout/direction control etc.
--
Reply to this email directly or view it on GitHub:
#115 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
A bridge is a node (due to two seperate reservation paths), so that's why it doesn't work, That is a bug, a bridge is a passive tile so it should be allowed. Going to fix that. |
If you merge/rebase latest |
5a579f9
to
1150a31
Compare
1150a31
to
cd42b12
Compare
Rebased on current master. |
Also react to external output changes and revert to reserved position if sneeded.
- Allow setting to "Both" while reserved
TODO: this is HACKY and bypasses some logic
- Now release timer is stopped when pressing a third button which becomes first button of new pair. - Timer is also stopped when editing mode is enabled - Hold timer is stopped if same button is clicked again
cd42b12
to
cb60d0f
Compare
Fixed missing include in |
Nice improvements, I'm going to do some test with it :) |
Hi Reinder. Yes I should add an assert. But if you test the code and it works I could change this to avoud using QTimer which requires a new heap allocation every time we start it and instead use `QTimerEvent` and `startTimer()` `killTimer()`
Functionality is the same and assert would become timer ID equal to zero.
Il 11 giugno 2024 23:09:08 CEST, Reinder Feenstra ***@***.***> ha scritto:
…
@reinder commented on this pull request.
> @@ -778,6 +768,61 @@ void BoardWidget::rightClicked()
rotateTile(true);
}
+void BoardWidget::startHoldTimer(const std::shared_ptr<NXButtonRailTile>& nxButton)
+{
+ stopTimerAndReleaseButtons();
+
+ m_releaseButton1 = nxButton;
+
+ m_timer = new QTimer(this);
I suggest to add a `assert(m_timer);` here, to check if `m_timer` is `nullptr` as expected.
--
Reply to this email directly or view it on GitHub:
#115 (review)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
- This avoids heap allocation - Added asserts for timerId to be null before being created again
Good suggenstion, Just did some simulations tests, it works as expected :) I was thinking, should we log a warning if a turnout is modified externally an Traintastic corrects it? Should we also have some kind of max retry to prevent loops? and maybe Estop the train if the max retry count is reached and log an error then too? For the path release, there must be some kind of delay I think, the train can still be on the turnout but already left the tail block. (Ideally we have occupy sensors on the turnout's too offcourse, but Traintastic should be able to handle both situations.) |
Yes we should log a warning when turnout is externally changed. But I don't know how to add a new log message... I think I've added the retry count logic to signals, if it's working fine I'll copy it also to turnouts. For the path release, I bet very few layouts have dedicated occupy detectors for switches so yes we should workaround it with some kind of delay. |
To add a log message you need to add a enum value in I've numbered all the log messages so it is easy to look up, in the source and if we receive a screenshot/log text in a language we don't understand :)
Good suggestion to add a world setting for that, maybe we can add three options:
I didn't test that yet, but it seems fine, else we can improve it later :)
Good suggestions/ideas! I think it is best we move that to a separate PR, then we can finish this one :) |
- If position is externally changed while a path is reserve Turnout will try to reset it's position to reserved one If it fails and reaches maximum retry count it will stop trains in path.
- When locked and retry count is reached, stop trains in path - Evaluate only if a path is reserved
Nice improvements! Just some thoughts:
|
Sure. I was thinking about moving the "stop all trains" code inside |
- New messages when position/aspect is externally changed - New messages when position/aspect is corrected - New messages when train is stopped - Separate messages for Signals and Turnouts - Avoid stopping twice the same Train - Italian and English translations
Last things missing should be:
|
Yes, you can add a I think stop the whole world is also a nice option to have, so then we need an enum.
That would be nice indeed. |
Some experiments with path reservation system.
Based on #113
Some issues already noted in #114