[eric from trainsim]

Multiple FA's would be great for managing containers, TOFC's, or any number of other items you might want to address thru a FA in a gondola or on a flat car...

[Traindude]

Here's an idea I want to see, specifically for the steam department:

Driver-and-Fireman Multiplayer Mode

Two players have control over one steam locomotive. However, instead of each player having equal control over the same loco, the player's controls are tailored to the player's role as either driver or fireman (this obviously only would work with the AI fireman disabled). Player 1, the driver, can operate the reverser, throttle, brakes and such, but cannot operate the fireman's controls (stoker, blower, water supply, etc), while the opposite holds true for player 2, the fireman.

[R H Steele]

In another thread it was mentioned that the switch from Throttle to Dynamic Brake no longer had a short time delay for the relays to kick over. I liked having the delay for the relays, wish I could implement it myself, makes running the engine much more realistic. The topic then went into "Simulation vs "Game" for Open Rails. This got me to thinking (never a good thing).... this is always going to be a matter of choice or player preferences. So how about having a global option that sets all the "switches" or preferences to either Simulator or Game. If a global option is not a good idea how about a menu tab that gives degrees of choice between simulator and game for some of the most important control items. Something like the simple controls vs advanced controls in MSTS only offering more choices of specific controls. I don't have enough experience to suggest what those would be, but it would provide more flexibility to Open Rails and provide for a wider degree of player participation. Personally I prefer the simulator mode, the closer to prototypical the better, within practical limits. Cheers rhs (aka gerry)

[Genma Saotome]

 R H Steele, on 03 December 2013 - 08:30 PM, said:

<snip> The topic then went into "Simulation vs "Game" for Open Rails. <snip>

The original set of objectives, as recorded by Wayne Campbell from a discussion w/ the original team members clearly came down on the side of simulator, not game. FWIW that group also decided to not debase the simulator on account of the needs of old, poorly performing PC's.

None of those people are still active on the OR project so there is no telling how things will turn out.

Having contributed to the original decisions, I do hope the current team sticks with them.

[R H Steele]

 Genma Saotome, on 03 December 2013 - 09:40 PM, said:

The original set of objectives, as recorded by Wayne Campbell from a discussion w/ the original team members clearly came down on the side of simulator, not game. FWIW that group also decided to not debase the simulator on account of the needs of old, poorly performing PC's.

None of those people are still active on the OR project so there is no telling how things will turn out.

Having contributed to the original decisions, I do hope the current team sticks with them.

Thanks for that, I was wondering what the original objectives were, I'm happy they came down on the side of a simulator. Is that information published anywhere, here at Elvas for instance? (I'll look on the Open Rails site) In light of that ... how about changing the option to Advanced simulator for you folks that got the skill set already, with lower simulator settings for players with learners permits? Still something like the simple vs advanced options in MSTS. I really miss having to wait for the relays to switch when going into Dynamic Brakes, it requires that you are paying attention to the route, planning ahead, I liked it. Cheers rhs (aka gerry)

[cjakeman]

Hi Gerry,

 R H Steele, on 03 December 2013 - 09:50 PM, said:

Thanks for that, I was wondering what the original objectives were, I'm happy they came down on the side of a simulator. Is that information published anywhere, here at Elvas for instance? (I'll look on the Open Rails site)

You'll find the Mission statement here - "Our goal is to enhance the railroad simulation hobby through a community designed and supported platform built to serve as a lasting foundation for an accurate and immersive simulation experience." and "We benefit from community expertise to deliver accuracy not just in appearance, but also operationally. It's this area that we find existing products lacking."

I, for one, am quite comfortable with this approach and Genma's comment. For example, we will continue to add time-savers such as Initialise Brakes, Save and Resume but I would be surprised to find the team putting effort into modelling game effects like collisions.

Best wishes,

[R H Steele]

 cjakeman, on 04 December 2013 - 12:02 PM, said:

Hi Gerry,
but I would be surprised to find the team putting effort into modelling game effects like collisions.

Best wishes,

I"ll read the Mission Statement, was aware of it, had not made the effort, will do so. Thank goodness --- no collisions, yipes! I am quite satisfied with the direction Open Rails is going. The closer to a well thought out simulation the better. Cheers rhs (aka gerry)

[That Genset Foamer]

 Shay 5, on 01 December 2013 - 05:06 PM, said:

Last is a unique whistle interface that would allow custom sequences or "Whippoorwills" . That is what I wish.

I suggested this awhile back as a CTRL+Spacebar or SHIFT+Spacebar permutation, which reads the ORTS as *****_quill.wav with no added code needed to the SMS file. One of my friends thinks the quill should be bound to an entirely separate key, but that chews up an additional key that could be bound to an additional function.

Another thing I'd like to see is something like the .WS file, maybe ".ORW"--this file refers to world file UiDs, and contains data for custom crossing.sms files, i.e. null sounds, custom bell effects, etc. Also, it could support multiple animation nodes per crossing, such as flashing gate lights.
Also, I noticed ORTS has began to calculate wheel amounts. Could a looping sum over a specific node in the TDB be implemented in order to make a working defect detector?

[StevenMasters]

My items:

1) I would like to see the animation frames for switches/points increased from the three frames(keys) currently allowed. This would allow for better animation of switches that have the stands, indicators, rods, etc. directly attached. A different method would still be compatible with the default three key limit.

2) Working single/double slip switches. The current work around is to use up to five track sections to replace the improperly coded default ones. This is a programming issue, not a shape issue.


Steven

[Genma Saotome]

With Steven Masters posting the Tsection.dat file comes to mind... I thought I'd mention an idea I've been experimenting with: track and roads shapes, as defined in the Tsection, as a simple vertical plane (it's a bit 3d so think long, narrow box) located on the center line of each path -- no specific appearance of any kind. That places the origin point into the world file. Because the "shape" has no shape it means just 1 TrackShape() definition is needed for each set of unique geometry. At some later time the route builder adds 1 to n static shapes as replacements for these vertical planes and it is these replacements that look like the real thing.

Why? Because you can then swap in and out whatever cad mesh you want bearing whatever textures you want, in whatever combination you want.

As an example, I'm doing roads along these lines... some of the 2L road shapes are 40 feet wide, others 60 feet, and more 66 feet. Those all lack sidewalk/subroadbed, so those shapes also get added... some are gravel, others have sidewalks, others still have parkways. But they're all 2L roads. Need a driveway to fit the building? Pretty trivial to make a static shape for that. Change your mind about the sidewalk? Take out that static shape and put in another. Don't have the driveway shape built right now? Put in sidewalks and deal with the driveway shape next month. It works because this sort of fiddling is w/ the static shapes it has no effect whatsoever on the .TDB / .RDB.

IOW what is important to the software -- the path that makes up the nodes -- is a completely different issue to the route builder relative to the physical appearance of the path. KUJU mooshed the two together because it was easier to do things that way. So imagine how it might have worked had the two been separated: The Tsection file would be a fraction of it's current size. The route editor would place these vertical planes just like one places roads or track now, but then with a right click of the mouse the route builder could specify now insert this rail shape, this tie shape, this roadbed, and this subroadbed ( in the form of 1 to n static shapes ). If somebody else, at some other time, wanted to backdate those 133 lb/yard rails on concrete ties with 80 lb/yard rails on wood ties it's merely replacing one set of static shapes for another... no change to the .tdb, no impact on interactives.

Food for thought.