-
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
Api update #1577
Api update #1577
Conversation
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.
Code looks OK, not tested in-game though.
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 didn't dive too deeply into implementation, but focused on the API instead. Implementation can always be changed. API, we're stuck with.
@kvakvs @Elesbaan70 I made changes to UI API. Do you like my new |
Nice, keep it simple. One point access to all future UI interfaces. |
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.
These changes are mostly good, but the renaming of JunctionRestrictionFlags
and its members needs to be rolled back, and CanToggleTL
needs to be renamed to CanToggleTrafficLight
and privately implemented to protect compatibility.
@@ -0,0 +1,9 @@ | |||
namespace TrafficManager.API.Traffic.Enums { | |||
public enum TrafficLightType { |
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 don't think TrafficLightType
is the right name for this. It includes things like "paused."
It's pretty UI-centric. Maybe its name should reflect that?
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 should I call it?
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.
TrafficLightFlags
?
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.
Paused traffic light acts like normal vanilla traffic light.
I also have the option of dropping paused.
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 consider this to be a specifically UI-related enumeration. Basically, it indicates which traffic light tool has control of the light, and indicates additional state information. So why not call it TrafficLightToolState
, and then ITrafficLightManager.GetTrafficLightToolState
and ITheme.TrafficLightToolState()
?
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.
And no, I say don't drop paused. Under my interpretation, it belongs there.
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.
Minor suggestions for consideration, nothing blocking
TLM/TMPE.API/UI/ITheme.cs
Outdated
|
||
Texture2D VehicleRestriction(ExtVehicleType type, bool allow); | ||
|
||
Texture2D GetTrafficLightIcon(ushort nodeId); |
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.
Texture2D GetTrafficLightIcon(ushort nodeId); | |
Texture2D TrafficLightIcon(ushort nodeId); |
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.
must be public though.
/// <summary> | ||
/// returns if the node as any kind of traffic light (vanilla, manual, timed). | ||
/// </summary> | ||
public bool HasTrafficLight(ushort nodeId); |
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.
public bool HasTrafficLight(ushort nodeId); | |
bool HasTrafficLight(ushort nodeId); |
implicitly public so redundant
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.
@krzychu124 no that does not work
Interface Implementation has to be public.
But that is not necessary in this case.
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 might not be a bad idea to implicitly define all API implementations that we do not want to use internally. If we want to go that route we need to have a discussion about it and apply the rule consistently everywhere.
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.
you get an error probably because you are explicitly implementing the interface and implementation you shown is private then making it explicit you force us to cast to the interface to use that method (is there another one with the same signature?). Explicit and implicit implementation are completely different things with some implications.
Basically when you create explicit implementation you won't be able to use it like this
TraffLightManager.Instance.CanToggleTrafficLight()
(assuming that Instance
returns TrafficLightManager
, not the interface)
but forced to do this instead:
((ITrafficLightManager)TraffLightManager.Instance).CanToggleTrafficLight()
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 you said first does not work:
public bool HasTrafficLight(ushort nodeId); | |
bool HasTrafficLight(ushort nodeId); |
but this will work:
public bool HasTrafficLight(ushort nodeId); | |
bool ITrafficLightManager.HasTrafficLight(ushort nodeId); |
I understand how implicit/explicit works.
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 second the last couple of recommendations from @krzychu124, for naming consistency and clean-looking code. Otherwise looks good.
Cool. I will update NC/HUT/DCR/HTC (AN already uses TMPE API) after both stable and Test are using this Hotfix |
API update for compatibility with NC/DCR/HUT * TrafficLights/JunctionRestrictions: updated API * LaneEndTransitionGroup : Added Bicycle and Pedestrian for future proofing. * Expose Road sign theme in API. (cherry picked from commit 2a4c104)
API update for compatibility with NC/DCR/HUT * TrafficLights/JunctionRestrictions: updated API * LaneEndTransitionGroup : Added Bicycle and Pedestrian for future proofing. * Expose Road sign theme in API.
API update for compatibility with NC/DCR/HUT * TrafficLights/JunctionRestrictions: updated API * LaneEndTransitionGroup : Added Bicycle and Pedestrian for future proofing. * Expose Road sign theme in API.
added API so that node controller access TMPE through API.
node controller is still patching Junction restriction manager. that I can fix in next PR.
also added not implemented pedestrian/bike lane transition groups for better future proofing of AN.
Tested with:
AN-alpha
HUT-DCR.zip
Hide crossings