AmbientLight,DirectionalLight and LightDirection arewant to change anytime.

Now, at the sunset time or sunrise time, color to set orange color.
But, if a driving train into the tunnel, the color is not change.
So, the tunnel is orange colored.
LightDirection and Lighting can change by DynamicLighting.

Route.AmbientLight and Route.DirectionalLight are set only one time.
We cannot force change anytime these colors.
And these commands are have to keep compatibility.

To escape this trouble, we create some new object, and use Setcolor.
But, to create the new object is a bit bose.
So, my suggestion, add some functions for example:

Track.SetLightingMode 0 or 1:0:defalt.Use Route.XXColor and one time 1:Use Track.SetxxColor
Track.SetAmbientColor R;G;B
Track.SetDirectionColor R;G;B

To set On and Off, we have to resume default Route.XXcolor's  lighting.
Only set to On/Off, we can change easily at the tunnel.
And, we necessaly change anytime the another light.
So I thought we need Track.SetLightingMode.

If we use Track.Brightness and these commands, I think that we can create more real lighting.
Plese consider about  this suggestion.

How about switching the dynamic lighting based on distance?
Define an XML file like the following:

Code:

<TrackDynamicLighting>
  <Entries>
    <Entry>
      <TrackPosition>track position [m]</TrackPosition>
      <FilePath>file path to a dynamic lighting xml</FilePath>
    </Entry>
    <Entry>
    ...
    </Entry>
  </Entries>
</TrackDynamicLighting>

File switching is defined as an event on the route, and the camera track follower handles that event.
Wouldn't this method be more flexible?

Would the ability to simply define a dynamic light file as per a freeobj be better there?

Assume that this applies from the point of placement onwards.
Not sure the track distance part is necessary.

I feel that if the DLihgitng is link to freeobj, the define is a bit bozer.
For example, if we are create the another tunnel object, we have to write all DLighting define to connect.
If DLighting connect to distance, these define is not need.

So, If link to the Dlighting, I think more better that it is link to distance as @S520 say.

My idea is also link to distance, and that when I create the route, I feel that my idea is easy to create.

(If mr.leeser3 can create more easily, please link to freeobj)

@leezer3
Is your idea to add a link to the dynamic lighting file to the parameters of the Track.FreeObj command?

@leezer3, @Midnight Express Ginga81
I thought of simplifying my previous idea and adding the Track.DynamicLight command.
This command takes a dynamic lighting file as a parameter and can be written multiple times in a route file.
At the distance this command is written, the program creates an event that switches dynamic lighting.

Code:

1000
            Track.DynamicLight Dlight1.xml

If we will use XML file, I think also that this idea is more nice.
A XML file write each distance is also good idea.
But, new idea is more easy to create route.
Some files parallel writing is a bit bozer.

This new idea is first define to the XML, and write to route file only.
XML file is recycle to use.
So, the new idea is feel good for me.

But, I think will perhaps that a bit confusion about Route.DynamicLight and Track.DynamicLight.

S520 wrote:@leezer3
Is your idea to add a link to the dynamic lighting file to the parameters of the Track.FreeObj command?

@leezer3, @Midnight Express Ginga81
I thought of simplifying my previous idea and adding the Track.DynamicLight command.
This command takes a dynamic lighting file as a parameter and can be written multiple times in a route file.
At the distance this command is written, the program creates an event that switches dynamic lighting.

Your revised thing is essentially what I meant. You could also just use the XML file in the command, either way works.

Code:

Structure.DynamicLight(0) Object\MyRoute\DynamicLight_Outside.xml
Structure.DynamicLight(2) Object\MyRoute\DynamicLight_Tunnel.xml

.....

2500, .DynamicLight(0)
3500, .DynamicLight(1)
4000, .DynamicLight(0)



Not sure immediately how to handle this with regards to the existing light definitions.
We could over-write with the first dynamiclight command, but how then to drop back to default would be the question...

Mr.leeser3's idea is also good!
My opinion, 1.easy change for route create and 2.another lighting only.
So, both idea is feel very good!