[Csantucci]

A blueprint https://blueprints.l...er-change-event has been generated to specify a WeatherChange activity event. I repeat here the specification.

Following block can be added within an Event Block (be it a Location or a Time event) of an .act file:

ORTSWeatherChange (
ORTSTransitionTimeS ( double )
ORTSWeatherType ( double )
ORTSOvercast ( float )
ORTSFog ( float )
ORTSPrecipitationIntensity ( float )
)

The weather changes consequentially.
The event can also include an ORTSContinue ( 0 ) line, therefore not displaying messages and not suspending activity execution.
Manual commands related to weather interrupt the weather change triggered by the above events.
If a new WeatherChange event is triggered before the action of the preceding has terminated, the old one is interrupted.

MSTS operation is not damaged by the WeatherChange events.
Editing the .act file with the MSTS AE after inclusion of WeatherChange events clears them, so they should be backed up separately.
Opening with the MSTS AE an .act file with WeatherChage events and packaging it without editing it generates an .apk file that contains such events.

Using the location event it is possible to have another weather e.g. when climbing uphill or exiting a continental divide tunnel; using the time event it is possible to have weather changing during the day.

Implementation work not yet started.

[Driver]

Csantucci, on 01 June 2015 - 12:39 PM, said:

A blueprint https://blueprints.l...er-change-event has been generated to specify a WeatherChange activity event. I repeat here the specification.

Following block can be added within an Event Block (be it a Location or a Time event) of an .act file:

ORTSWeatherChange (
ORTSTransitionTimeS ( double )
ORTSWeatherType ( double )
ORTSOvercast ( float )
ORTSFog ( float )
ORTSPrecipitationIntensity ( float )
)

The weather changes consequentially.
The event can also include an ORTSContinue ( 0 ) line, therefore not displaying messages and not suspending activity execution.
Manual commands related to weather interrupt the weather change triggered by the above events.
If a new WeatherChange event is triggered before the action of the preceding has terminated, the old one is interrupted.

MSTS operation is not damaged by the WeatherChange events.
Editing the .act file with the MSTS AE after inclusion of WeatherChange events clears them, so they should be backed up separately.
Opening with the MSTS AE an .act file with WeatherChage events and packaging it without editing it generates an .apk file that contains such events.

Will this also work in timetable mode?

[James Ross]

Driver, on 01 June 2015 - 10:40 PM, said:

Will this also work in timetable mode?

Timetable mode doesn't use activity files, so it'll need a separate implementation.

[James Ross]

Csantucci, on 01 June 2015 - 12:39 PM, said:

ORTSWeatherChange (
ORTSTransitionTimeS ( double )
ORTSWeatherType ( double )
ORTSOvercast ( float )
ORTSFog ( float )
ORTSPrecipitationIntensity ( float )
)

I am generally happy to try exploring these kinds of ideas. Being able to tie it in to other activity events through the usual means seems very useful, as does the transition time.

Shouldn't ORTSWeatherType be int or string with limited values?

I think we'll also need to double-check how precipitation intensity is working related to real life. :)

[Csantucci]

Re weather type in effect a better choice could be made than the one I did. As Weather type is already present in the Activity file as int, I will use that format. That will be then converted in an enum, as already used in OR.
Referring precipitation intensity maybe I'll try to integrate Edward's patch, if he agrees. It would be nice also to have a smooth transition from rain to snow, but that requires fine graphics work.
Another parameter that could be added is wind (intensity, direction, variance - meaning intensity and direction are not constant).

[Genma Saotome]

Please set it up so the visual effects may be evoked as a solo effect -- meaning someone can create commands for only wind w/o having to use precipitation as well. Ditto for cloud cover.

The route I work on (The Cal-P) has ~1/3 of the mainline located in a natural wind tunnel: >50km/hr blowing east is standard afternoon wind in the summer months; The west end sees high fog most mornings until noon and a light eastward breeze in late afternoon whereas the inland east end sees little wind, no clouds, and the brightest sun etc. etc. It's quite varied from one end to other and so KUJU's approach of managing it all as a route-wide effect would never serve. All of those natural effects occur w/o rain or snow from May into October.

[Csantucci]

Dave,
it is foreseen that it will be possible to have solo effects.

[Genma Saotome]

Can the trigger be a time of day instead of an action by the player?

[Csantucci]

You can use time event, that is events that start at a predetermined time interval from activity start.

[Genma Saotome]

Great! Sounds like everything is all lined up!

[BasilP]

The ability to change precipitation in OR is good. It is good that it can be changed manually as you go.

I think it would be nice to not only set the season and precipitation at the beginning of an explore or timetable session but to also have sliders for overcast, fog, and precipitation at the beginning of the session.

I do like the idea of having progressive weather changes.

Thanks
Basil

[edwardk]

Csantucci, on 02 June 2015 - 11:14 AM, said:

Re weather type in effect a better choice could be made than the one I did. As Weather type is already present in the Activity file as int, I will use that format. That will be then converted in an enum, as already used in OR.
Referring precipitation intensity maybe I'll try to integrate Edward's patch, if he agrees. It would be nice also to have a smooth transition from rain to snow, but that requires fine graphics work.
Another parameter that could be added is wind (intensity, direction, variance - meaning intensity and direction are not constant).

I have no problem here. Just let me know when you need it. The type of work that needs to be done is applying some random action to the individual particles. Wind would of course push the precipitation in a certain direction, but as it is now, the particles fall the same way.

Edward K.

[edwardk]

I also want to add some information concerning precipitation intensity. Changing the precipitation box by breaking it down to length, width, and height opened up the ability to using a higher precipitation intensity value. The first question I would ask is "MaxIntensityPPSPM2" still actually needed? Right now, MaxIntensityPPSPM2 is used as a max setting that can't be exceeded so as long as this is set high enough, intense precipitation is possible. Of course we have to keep in mind the computer's ability to process such a weather set up. One snow condition as an example is a white out condition. Even if this can be achieved which I admit would be great, the resources needed would probably drag the frame rates down.

Edward K.

[James Ross]

edwardk, on 04 June 2015 - 12:51 PM, said:

The first question I would ask is "MaxIntensityPPSPM2" still actually needed?

We need some sort of maximum to be defined, for at least two obvious reasons:

• The audio volume is based on current/maximum intensity.
  
• The user can dynamically change the intensity and there needs to be a limit to avoid breaking things (like running out of space in the vertex buffer).

[edwardk]

I asked a question which was a bit too obvious. At one point I was questioning the need, but not now. I am now set with what I have so once Carlos is ready, I will provide the patch file.

Edward K.