Api update#1577
Conversation
originalfoo
left a comment
There was a problem hiding this comment.
Code looks OK, not tested in-game though.
Elesbaan70
left a comment
There was a problem hiding this comment.
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. |
| @@ -0,0 +1,9 @@ | |||
| namespace TrafficManager.API.Traffic.Enums { | |||
| public enum TrafficLightType { | |||
There was a problem hiding this comment.
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.
what should I call it?
There was a problem hiding this comment.
TrafficLightFlags?
There was a problem hiding this comment.
Paused traffic light acts like normal vanilla traffic light.
I also have the option of dropping paused.
There was a problem hiding this comment.
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.
And no, I say don't drop paused. Under my interpretation, it belongs there.
krzychu124
left a comment
There was a problem hiding this comment.
Minor suggestions for consideration, nothing blocking
|
|
||
| Texture2D VehicleRestriction(ExtVehicleType type, bool allow); | ||
|
|
||
| Texture2D GetTrafficLightIcon(ushort nodeId); |
There was a problem hiding this comment.
| Texture2D GetTrafficLightIcon(ushort nodeId); | |
| Texture2D TrafficLightIcon(ushort nodeId); |
There was a problem hiding this comment.
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.
| public bool HasTrafficLight(ushort nodeId); | |
| bool HasTrafficLight(ushort nodeId); |
implicitly public so redundant
There was a problem hiding this comment.
@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.
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.
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.
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.
Elesbaan70
left a comment
There was a problem hiding this comment.
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