[jonas]

Hi everyone,

it would be great to have an option to make the "G" key turning only the next switch ahead which really forks the route (MSTS like).

Best regards,
Jonas

[Rogue]

Hi everyone,

my first entry here in this forum and already a wishlist :-)

I really appreciate the possibility to provide some input for this promising Simulator.

1) I recently installed the first version of the 3D-Cab and saw, that outside shadows (from bridges, trees, etc.) are now also visible inside the cab. And as far as I can remember, the same goes for the outside daylight.
So I wondered, if this effect would also be possible with todays static MSTS-Cabs.
I know it wouldn't as this is a totally different format but maybe OR can convert the graphic-file into a format that would realize these effects during in-game (if the user selects the option)....like a 2D-Cab with the 3D-preferences.
I'm not a programmer but I think this is not totally unrealistic, isn't it ?

2) is it possible to add a tick-box in the graphic-options menu where the user can enable the option that every object throws a shadow ?

3) I am a big fan of the discover-mode and therefore was thrilled by the implementation of the Dispatcher-features, where I can set the route in advance.
However, when I want to set something in the Dispatcher-Window, I have to leave the Full-Screen-Mode. Is there a solution to display the Dispatcher-Window during Full-Screen-Mode ?

Well, that's it for now but I'm sure that more will come.

All the Best
Boris

[markus_GE]

Whoops, looks like the last two posts would rather belong to the ORTS Wish List -- 2014-05 thread (which has not yet been started, AFAIK). Any chance to split them off to there (including this post, as I´m going to answer to the above)?

:lol2: to ET, Boris :lol:

The problem with Shadows in a 2D cab is, as far as I can tell, that it simply is a two-dimensional graphics overlay, drawn on top of the surrounding 3D world. Thus, there is not only the problem that there is no shape data to cast shadows of or onto, as far as I can imagine from what I´ve learned in Geometry in school, but there is also not relation to the graphics code doing shadows.

I´m, however, just the translator to German, and though I´ve taken a few looks on the code and can do some programming, I might be wrong. Please correct me then :oldstry:

Cheers, Markus

[James Ross]

markus_GE, on 20 May 2014 - 12:23 AM, said:

The problem with Shadows in a 2D cab is, as far as I can tell, that it simply is a two-dimensional graphics overlay, drawn on top of the surrounding 3D world. Thus, there is not only the problem that there is no shape data to cast shadows of or onto, as far as I can imagine from what I´ve learned in Geometry in school, but there is also not relation to the graphics code doing shadows.

What might be possible - although it will probably be fiddly - is simply darkening all or none of the cab based on whether a single point in 3D space is "in shadow" or not. That may give a reasonable impression of passing under bridges and such, or it may feel quite jarring. (We do something a bit similar for tunnels.)

[markus_GE]

That would be way cool. :lol:

Geometrically speaking, one would need to check if the plane in which the 2D cab is drawn is in shadow or not. How to do that - no idea :lol2: But probably, the four edges of the plane should be enough.

Cheers, Markus

[Rogue]

The idea from James sounds promising.

But the idea of a "conversion" still floats in my head....but I don't know if this is too complicated or unrealistic for a new feature:

1) while loading the engine, OR recognizes the regular MSTS-Cab

2) if the user selected the feature, OR somehow converts the graphic and puts it into a 3D-Cab-Enviroment ( a special default cab for this purpose), which isn't proper 3D and maybe has only the front view. But all the shadow-functionalities are available.

I know, a very progressive idea but worth a shot for the wish list :-)

Boris

[Tve4]

Signalling related wish (or a couple):

Signal Trigger:
could OR be made to recognise a certain type & name of a signal as an "zero-second waiting point"? I'm in the process of starting a route that has looong blocks, and I would like to make sure that the signals at a station remain at 'stop' until the approaching train has passed over a some-sort of a trigger located at a fixed place. This trigger could be as simple as a dummy signal with an entry in sigcfg.dat file, say, by the name of SignalTrigger and coded as an INFO signal. It wouldn't even need any sort of script other than some sort of "I'm here" statement so that the program recognises this.

Basically this would just act as a fixed zero-second waiting-point (or a NORMAL signal with SignalNumClearAhead value of zero). As soon as the head-end of a train passes over it, the signals ahead would be enabled and function as coded. The best of all, it would be invisible in track monitor, and any NORMAL signals would not need special coding.

It would also be useful for trains coming to a signalled main line from an unsignalled branch. That way the train would not get the signal to enter the main line too early.


Crossing Info Signals:
Functioning crossing state info signals for train driver. These would be of INFO type with two states, and could have distant signals. In short, they would be signals telling the driver wheter the crossing ahead is activated or not. The best possible solution would be if it could recognise when the gate animation has stopped (ie. gates closed) but I would be happy if it could atleast recognise if all the crossingitems are activated.

In real life (the example is from Sweden), crossing info signals and their distants are usually activated to show 'clear' when the half-barriers are starting to close, or when the full-barriers are in fully closed position. The info signals return to 'stop' when the gates begin to open. I don't know if the data structure provides facilities for this kind of function.


Level Crossing Activation:
Somehow there should be a work-around for the MSTS level-crossing activation. I would like to have my crossings to activate at a fixed distance rather than estimated time of arrival. Could this be done with some sort of config file in route folder, saying that insted of using the "activate early by __ seconds" multiply it by a given value and use it as a distance.

Some things would have to be taken account, regarding red flasher animations activated by an approacing train, so here's a list what needs to be noted:

• Activate level crossing early by __ seconds
  This value multiplied by a value given in levelcrossings.dat.orts file would define the fixed warning distance for approaching trains.
  
  
• Initial warning phase lasts
  The crossing activates as soon as the train is within the fixed distance. This value would define the time gates remain open after the activation. Use 0.0 seconds to start flasher animation immediately.
  
  
• More serious warning phase lasts
  Complete change: this would be used only with the flasher objects, and it would tell how long the flashers should keep flashing after the train has cleared the crossing (the duration it takes to open the gates). For gates you could use 0.0 seconds, meaning that they open immediately after the train is clear of minimum warning distance, or a positive value if you want to delay the opening for some reason.
  
  
• Minimum warning distance
  The length of the island (center) track circuit. If possible, all levelcrossingitems within this diameter should operate in unison.
  
  
• Gate open/close animation
  Positive values for gate animation. Existing Flasher animations use negative values.
  
  
• Crossing is invisible
  If ticked, the crossing is invisible and should operate similarly to MSTS invisible crossing (time-triggered instead of distance). Used only at crossing where there are no gates/lights.
  
  
• Crash propablility
  Not used nor needed. At least not in the stupid MSTS fashion.

A Question:
Can OR's signalling extended to produce alternately flashing lights? I know Italian signal system has aspects which have alternately flashing lights. It could also be used to provide an alternate method of making railroad crossing lights (also related to the second suggestion above).

I know most likely all of the above might be too difficult to make happen, but I wanted to bring the ideas around...

[Lindsayts]

A note on level crossings,

Remember OR is meant to be a simulator for serious train people, the stated intention is for it to be as accuarte as possible.

As far as I am aware there is three ways to activate level crossing in he end it would nice to have access to all three.

1: Track circuits, this is the traditional autoatic level crossing, the track circuits can get very complex with crossings close together.

2: Manual, either by the driver or one of the station staff. This method of activation is used when a crossing is adjacent to a station. Manual activation is used by ethier a key switch, some kind of radio control from the train or a switch at the station. The reason this activation is used is to prevent the crossing being closed to long when the tain is stationary.

3: Predictive crossing controlers, eg like the ones made by the US company Harmon. These electronical measure the trains speed and activate the crossing to give a decent amount of advancd warning. These are specially usefull on major routes with both fast pass's and slow freights as all crossing give the same amount of warning time regardless of the trains speed. The detection circuits are independent of each controler (Note 1) so the controlers can be used without difficulty on crossings very close together.

Note: just in case anyone is interested, the Harmon controlers measure the impedance of the loop made up of both rails and the leading bogie of the train to detemine the distance. The measurements are done in the low VF range aprox 250 to 600 hz. Harmon provide filters at the apropriate frequencies to allow such things as signal track circuits or other nearly adjacent Harmon conrolers to be bypassed, they being either DC or on a differnt frequency.
These hold the gates done longer than track circuits as the controler has to be satisfied the train is on the other side of the crossing before it releases the gates.

LIndsay

[jonas]

Hi everyone,

it would be great to have an option to individualize CarSpawners. It was one of the first things I really missed in MSTS.

Maybe it would work, for example with OR Track Viewer. You click on a single CarSpawner symbol there and the general list of cars from the "carspawn.dat" can be changed individual for this carspawner only.

In order to respect the principle that MSTS files must not be modified, the individualized CarSpawner lists could be saved in separate files in a own directory of the route (maybe named as "CS-Lists" or similar) instead in the associated world file.

However, this would be a real advantage for OR when you could have certain vehicles on certain roads. For example, one could have an automatically running tram without any tracks on an 4 lane road in the middle lanes. On fields could drive tractors or horse and carriage individual. Not to mention what would be possible thereby with ships or even aircraft or migrating bird swarms etc.

In combination with hidden railroad crossings it will be a great chance to let the trian interact with certain vehicles.

Best regards,
Jonas

[CRVRR]

I was wondering if you guys could get Teamspeak to work with openrails like to simulate cab radios for multiplayer. They do have sdk's free for that such of thing. Just a thought. Wilson