Api update

[kianzarrin]

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

[originalfoo]

Code looks OK, not tested in-game though.

[Elesbaan70]

I didn't dive too deeply into implementation, but focused on the API instead. Implementation can always be changed. API, we're stuck with.

[kianzarrin]

@kvakvs @Elesbaan70 I made changes to UI API. Do you like my new ITheme and IUIFactory?

[kvakvs]

@kvakvs @Elesbaan70 I made changes to UI API. Do you like my new ITheme and IUIFactory?

Nice, keep it simple. One point access to all future UI interfaces.

[Elesbaan70]

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.

[Elesbaan70]

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?

[kianzarrin]

what should I call it?

[kianzarrin]

TrafficLightFlags?

[kianzarrin]

Paused traffic light acts like normal vanilla traffic light.
I also have the option of dropping paused.

[Elesbaan70]

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()?

[Elesbaan70]

And no, I say don't drop paused. Under my interpretation, it belongs there.

[krzychu124]

Minor suggestions for consideration, nothing blocking

[krzychu124]

Suggested change

	Texture2D GetTrafficLightIcon(ushort nodeId);
	Texture2D TrafficLightIcon(ushort nodeId);

[kianzarrin]

must be public though.

[krzychu124]

Suggested change

	public bool HasTrafficLight(ushort nodeId);
	bool HasTrafficLight(ushort nodeId);

implicitly public so redundant

[kianzarrin]

@krzychu124 no that does not work

Interface Implementation has to be public.

unless if I do like this:

But that is not necessary in this case.

[kianzarrin]

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.

[krzychu124]

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()

[kianzarrin]

What you said first does not work:

Suggested change

	public bool HasTrafficLight(ushort nodeId);
	bool HasTrafficLight(ushort nodeId);

but this will work:

Suggested change

	public bool HasTrafficLight(ushort nodeId);
	bool ITrafficLightManager.HasTrafficLight(ushort nodeId);

I understand how implicit/explicit works.

[Elesbaan70]

I second the last couple of recommendations from @krzychu124, for naming consistency and clean-looking code. Otherwise looks good.

[kianzarrin]

Cool. I will update NC/HUT/DCR/HTC (AN already uses TMPE API) after both stable and Test are using this Hotfix