ORTS Wish List - 2013-12
#11
Posted 03 December 2013 - 12:58 PM
#12
Posted 03 December 2013 - 01:09 PM
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.
#13
Posted 03 December 2013 - 08:30 PM
#14
Posted 03 December 2013 - 09:40 PM
R H Steele, on 03 December 2013 - 08:30 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.
#15
Posted 03 December 2013 - 09:50 PM
Genma Saotome, on 03 December 2013 - 09:40 PM, said:
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)
#16
Posted 04 December 2013 - 12:02 PM
R H Steele, on 03 December 2013 - 09:50 PM, said:
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,
#17
Posted 04 December 2013 - 12:22 PM
cjakeman, on 04 December 2013 - 12:02 PM, said:
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)
#18
Posted 04 December 2013 - 03:40 PM
Shay 5, on 01 December 2013 - 05:06 PM, said:
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?
#19
Posted 14 December 2013 - 12:45 AM
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
#20
Posted 14 December 2013 - 10:12 AM
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.