-
Notifications
You must be signed in to change notification settings - Fork 85
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
Junction restrictions hook #1579
base: master
Are you sure you want to change the base?
Junction restrictions hook #1579
Conversation
@@ -574,5 +576,17 @@ public interface IJunctionRestrictionsManager { | |||
/// Updates the default values for all junction restrictions and segments. | |||
/// </summary> | |||
void UpdateAllDefaults(); | |||
|
|||
event Action<FlagsChangedEventArgs> FlagsChanged; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's incomplete. It's an event that will be invoked when junction restrictions flags change on a segment end, but FlagsChangedEventArgs
is missing some properties right now.
Great example of this being a work in progress. I've just created the draft pull request so there's visibility on what I'm doing. 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To further elaborate, it's intended to be a clear and supported way for mods like AN to know when junction restrictions change. That way you don't have to detect changes based on assumptions about the implementation. Instead, you have a direct promise that this will always work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mods like AN to know when junction restrictions change.
isn't that what notifier does?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mods like AN to know when junction restrictions change.
isn't that what notifier does?
Yes, but INotifier
is limited in the amount of specific information it can share about the change. By adding specific events at the manager level, you can provide more useful information. And if implemented correctly, when no one is using them all they cost is a check for null.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I notifier does tell which manager caused the update. and it has space for manager specific even args. although the event args is just an object and do not have hard-coded type safety.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
although the event args is just an object and do not have hard-coded type safety.
And that's the key difference. Manager-owned events put less responsibility on the consumer. Fewer opportunities for error.
AllowForwardLaneChange = 1 << 3, | ||
AllowEnterWhenBlocked = 1 << 4, | ||
AllowPedestrianCrossing = 1 << 5, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to control TrafficLights too. not sure if it would fit here. segmnetId would be irrelevant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe this could be a rule override hook?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe this could be a rule override hook?
I anticipate that in general, hooks would correspond to managers. There might be exceptions, but since that's the existing organization of the API, it's the pattern that makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am patching Traffic lights too. and could be causing problems because my patch will break if we overload those methods. I can easily fix my patch but I don't know about NCR.
Traffic light manager does not seem to manage default value for traffic lights though. so that is a difference. I am only patching if traffic lights are configurable.
…with compatibility
This is basically done now, but I want to get NCR working before taking it out of draft status. |
I had originally planned make this change before beginning the optimization/reorg of |
Solve conflicts and sync with |
We need to determine the correct resolution to the duplication of @kianzarrin's |
The number of external mods patching junction restrictions is increasing. This really needs to get merged. |
The end objectives here were:
The ordinary way to do this would be to make a new cached API, and have the existing methods call the new ones. Unfortunately, this could not be done straightforwardly, because the API methods are being patched by Node Controller, and now also by Adaptive Networks. The conventional approach would leave the new API methods unaffected by the patches, breaking those mods. Therefore, the following strategy is being followed:
This PR represents Phase 1. |
Since most of the TMPE implementation was calling the API methods directly via This means that a lot of files were changed. Following is a list of the files with functional changes. All other changes are refactoring and eliminating deprecated API calls. API Declaration and InstantiationTLM/TLM/Constants.cs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm OK with this
StartNode = startNode; | ||
} | ||
|
||
public static bool operator ==(SegmentEndId x, SegmentEndId y) => x.Equals(y); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, no override Equals
and GetHashCode
?
It will generate garbage, not to mention it will be quite slow compared to version with the Equals
=> segmentRestrictions[segmentId].GetValue(segmentId.AtNode(startNode), flags); | ||
|
||
public bool GetValueOrDefault(ushort segmentId, bool startNode, JunctionRestrictionFlags flags) | ||
=> segmentRestrictions[segmentId].GetValueOrDefault(segmentId.AtNode(startNode), flags); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if it's a good idea to do lazy recalculation, especially on "get" while that method might be called by multiple threads at the same time (main, simulation, or any of pathfinding threads (1+)).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I double that.
} | ||
|
||
public bool IsDefault() { | ||
private bool Set(SegmentEndId segmentEndId, JunctionRestrictionFlags flags, JunctionRestrictionFlags newValues, JunctionRestrictionFlags newMask) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe rename flags to values?
@@ -1368,70 +973,219 @@ private struct JunctionRestrictions { | |||
|
|||
private JunctionRestrictionFlags defaults; | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the difference between mask and valid? maybe a bit of doc?
Resolves #902
An
IJunctionRestrictionsHook
API implementing the idea discussed in #1557.I had originally planned make this change before beginning the optimization/reorg of JunctionRestrictionsManager, but it turned out that I had to do most of that work in conjunction with this. But all the redundancies can't finally be eliminated until the patches are gone from the stable builds of NC2 and NCR.
Relevant PRs for the Node Controller projects:
MacSergey/NodeController30#55
kianzarrin/NodeController#33