Railway Operations

[kujuSabrina]

We have a wealth of experience on both European and US railway operations and have planned Kuju Rail Simulator from the very beginning to cover both. In fact we have always kept an eye on railway operations across the world.

We can’t cater for everything in Rail Simulator's first release but we have ensured that our base systems we create now don’t rule out additional features to cover the vast diversity in the railway world.

Considering there are many differences between European and US railway operations, we thought it might be worth having a discussion on your preferences - if you have any and why?

[ENRguy32]

Sabrina I can't speak for all of us across the pond, but I'll tell you what I'd like to see included. Firstly I think KRS shoud be a vast improvment in terms of simulating steam engines than it's forruner. I'm sorry to say, but Train Sims core way of handling steam engines has left me wanting more. For example, I think KRS shoud have some sort of open-ended particle-efects system. One where the user can script particle systems and then have the said particle FX be linked to and ocur when diferent events happen in the simulation. For instance say the user is runing a shay geared locomotive, a type of steam locomotive with three vertical cylinders mounted on the right-hand side, (Your right if you're standing in the center of the cab.) so the model in question would have three cylinder-cock valves because it has three cylinders, the user could then use the open partical system to tell the simulator to activate the three steam-particle efects to when the cylinder-cocks are opened and the sim would also play a wave file of the steam blowing the water and condensation out of the cylinders both inside and outside the cab that looped until they where closed again. Something that was and is not possible with Train Simulator because it only allows two particle efects for the cylinder-cocks and will only play the sound for that function inside the cab. This is not a smackdown of your efforts with Microsoft and Train Sim but constructve help disigned to hilight some of Train Sims shortcomings and how they could be made better with KRS.


NOTE: I've kept this short and only to one subject to both make your life easyer and to save me typing time. There is much more I'd like to discuss but my messages would be too long then!

Sincerly, Greg.

[MariasRailfan]

Hi Sabrina,

Many i suggest having two routes in the US, one covering western mountin railroad and one covering "flatlands" operations in the east. Possibilities in the east are endless, but Id like to see some other feedback also. Try not to set the route in a definite period also, be flexible so that people can run steam and "fairly-up-ti-date" operations.

Thomas

[lateagain]

>Hi Sabrina,
>
>Many i suggest having two routes in the US, one covering
>western mountin railroad and one covering "flatlands"
>operations in the east. Possibilities in the east are endless,
>but Id like to see some other feedback also. Try not to set
>the route in a definite period also, be flexible so that
>people can run steam and "fairly-up-ti-date" operations.
>
>Thomas

Hi Thomas,

What Kuju have announced for two of the UK routes are the Somerset and Dorset, one of the UK's most loved and documented lines which sadly was completely torn up at the end of the Steam era but an excellent choice for a base route as it carried such a wide variety of traffic from many different regions and Paddington to Oxford which is part of the original route built by Brunel for his Broad Guage trains but is still in use today for modern high speed traffic. The S&D had some steep grades, a single track section and ran through beautiful countryside. The Paddington route westward from London was always meant to be a multi tracked fast route and features some classic bridges and viaducts. A similar choice your side of the pond would be great. I'd love to see the PRR with it's great variety of traffic and wide selection of motive power and something more modern but with the greatest variety of traffic. It's difficult to compromise routes anywhere in the world as the changes in rail usage, signalling practice and even the type and number of lines makes that unreal.

Geoff

[OTTODAD]

Hi Greg !

Don't forget that a successful Train Simulator has got to have mass appeal to railway fans of all ages and sexes, who are less interested in the intricate technical details of how to run a loco, steam, diesel or electric, but provides realistic and accurate representations of Scenery, Tracks and Rolling stock with all basic functions working as they should and at reasonable frame rates with no stuttering ! ;-)

The number of MSTS users who are constantly referring to such operational technicalities in the forums are a minute proportion of the million said to be using MSTS worldwide.

O t t o

[Macster]

I'll chime a few key objects here.

US Railroad operations directing towards BNSF and Union Pacific are quite different in terms to Eastern roads such as CSX and NS. Since I know more about Western roads, I'll start here.

One thing I really really need to suggest is the ability to switch locomotives. Example if I was a helper consist assisting an MRL train up Mullan pass, I'm going to have to be able to cut off from the train I am helping out on the fly at 7mph. Once I do that, I rather switch ends and isolate some motors to save fuel and drag the engines down the hill.

Another MAJOR grip about Train Simulator that bugged me from the beginning, a train doesn't get a clear signal when the car clears the switch. There is usually anywhere between a 20 second to 3 minute delay before a train gets the clear signal due to the electronics. (Train clears Home signal, switch lines for mainline or siding, signal then gives proper signal to intermeditate) I'd also like to see this simulator take consideration the difference of ABS signaling and CTC signaling. Many railroads still use a mix of both especially BNSF and UP. There are some divisions that are CTC with push button switchs. Not totally sure how those operations fair but it is out there.

Steam locomotives are all different, they all fire different, sound different, act different and all have there different "attitudes" One thing I have learned during my time at Mt. Rainier Scenic Railroad that a 2-8-2T is going to fire much different than a 3 truck Heisler and run very much different because of one locomotive being a Rod type engine and the other being a Geared type engine.

An example of this would be that a 2-8-2T on a slight downhill will increase speed regardless of where your johnson bar is at and you'll have to squeeze off alittle bit of air to keep your train under control. The Heisler on the other hand could be adjusted and thanks to the gearing will hold the speed or in some cases slow the train down, this holds especially true for a Shay. Think of it like a manual transmission car but in a much bigger version.

As for the whistle or a diesel locomotive, it should be much more variable, not simply hit space and "whooo, whooo, whoo, whoooo"... if I wanted to do jingle bells on it, I want to be able to have that ability and the same goes for diesel locomotives. If you like various recordings of examples, I can get you them so you can directly understand what I am talking about.

All steam locomotives I have seen and have the pleasure of running or seeing have one common thing though. You shut off the throttle, you don't hear "chuff chuff chuff" anymore.. if your not working the engine then it shouldn't be making any sounds :)

In terms of track, I would LOVE IT if the sounds were simular to BVE in every since of the way. Anthony Bowden did an amazing job with his BVE routes on transitioning from welded rail to jointed rail and back. This is something that really brings the experience to it's peak.

Now the less important things is the motion of the locomotives and cars bouncing up and down and swaying from side to side. Though most will probably say otherwise. If this is added to this sim then random derailments will need to be added since this is what the real boys have to deal with.

Example... pulling hard with 4 D9s in Run 8, 12-14mph on jointed rail..harmonic rocking is the worst ememy to any unit coal or grain train. You look in your mirror only to see your cars violently swaying back and forth, then it happens.... a loud sudden release of air as the train dumps the air to full service and you see your train piling up on the right of way.

A bit much, yes... but if it is about realism, may as well take it to the next level.

I've done plenty of play tests and such and really know how to give feedback when due, I'm looking very much forward to it. I hope we'll see some sort of in-game screen shots soon.

Thank you all for your efforts.

[ENRguy32]

>Hi Greg !
>
>Don't forget that a successful Train Simulator has got to have
>mass appeal to railway fans of all ages and sexes, who are
>less interested in the intricate technical details of how to
>run a loco, steam, diesel or electric, but provides realistic
>and accurate representations of Scenery, Tracks and Rolling
>stock with all basic functions working as they should and at
>reasonable frame rates with no stuttering ! ;-)
>
>The number of MSTS users who are constantly referring to such
>operational technicalities in the forums are a minute
>proportion of the million said to be using MSTS worldwide.
>
>O t t o

Hi Otto, I didn't mean to sound so bent on having Kuju include what I want in KRS. I was only giving Sabrina and the rest of them my ideas so they can mine concepts from them as they see fit. I'm not worrying about what or what not might get included in the final product thats to my liking, since Kuju are actively programing KRS to be able to deal with recreating a wide range of eras and equipment types I'll see some of what I enjoy being included. As for the rest, who dosen't love inproviseing and tricking a program into doing what you want it to. ;)

Greg.

[SurvivorSean]

Hello:

My previous post on operations goes across the board on what I'd like to see. I think one of the biggest things that need to be fixed (which would apply worldwide) is how AI trains react to other trains, and in particular restricting signals. If these 2 things were correct in MSTS, many of the add ons such as activity changer and switch list generator would work much better because of this.

1) AI trains not returning back to full speed.

In MSTS when an AI train passes a restricting signal, it stays at restricting speed. What this ends up doing is if your a player service behind them leaves you left to crawl. This can also cause delays in opposite directions as things build up and trains hold at sidings (in many cases sease to run with MSTS due to the signal cleared ahead parameter).

2) AI trains not recognizing other traffic or player services.

I've seen many times either AI trains plowing into each other (even merging) or despite being restriciting still fast enough to come onto your tail causing a derailment when your a player service.

I'm not sure how the rule applies to Europe, but in North America if a train is at restricing he travels at restricted speed and must be slow enough below this to stop his train within half the distance of any obstruction. This would eliminate, or minimize a collision as by rule the train ahead of it should not of had a signal or dispatcher authority to reverse the other direction, but if the dispatcher did so by error the other train would also have to proceed at restricting speed (this is also known as rule 105, and is generally used as rule in unsignalled territory, where there is no clearances issued).

As others have mentioned having the ability to manipulate parameters for the differences in countries to me is more than enough.

As for the AI dispatching I know real life attempts (I think some do exist in interurban systems like in Vancouver) have been made to have automaded dispatching signal systems. Interurban is much easier because the lengths are fairly standard, as well as sidings, double track, etc. Things start to go a drift when you deal with single track mainlines (lines with sidings or loops I believe they're called in the UK), and trains that could potentially be bigger than those sidings.

What I would strongly recommend for an AI dispatcher is to play it safe first (even if it means less efficiency and holding back trains) then slowly add procedures that make the dispatcher more efficient without risking stale mates. Having the ability to be dispatched by a remote system in multi-player through TD3 (already capable) can help for those that thirst for higher capacities. In a stand alone version however having the player have the ability to override signals, or at least knowing why that person is being held at a red signal would go along way in dealing with some of the imperfections of a signal system.

Thanks

Sean

[MRRextreme]

1) The ability to switch locomotives.

2) The ability to add locomotives to an existing train for "helper" operations.

3) The ability to have track and turnouts/switches made from flexible track AND stand-alone sectional track.

4) The ability to change the profile of the flexible track.

5) Please keep the parameter files open like the original MSTS so that 3rd party vendors and users can modify as much as possible.

Thank you for making another effort at a train simulator.

[SAL]

From my experience with MSTS and some of the problems I've had in working with various parts of the sim, I'd like to toss out a few suggestions regarding operations. -- This is coming from a Southeastern U.S. interest in railroad operations...

#1.) The biggest thing I would like to see is the ability to set brake retainers. This is used quite extensively in various operations in the south (e.g. Southern's Saluda Mountain and Old Ford Mountain, several branch lines off of the Clinchfield, Interstate and Norfolk & Western).

#2.) Different choices of speed limits. Currently, MSTS has only two choices: passenger and freight. My interest is in the 1950s, but these can still be applied in modern-day scenarios. Some railroads (Southern Railway being one) used to have separate speed limits for Passenger trains, Freight trains, and steam-led freight trains. This later evolved into having speed limits for Passenger, Express, Trailer-Train, and regular freights. Theoretically, more choices could be added, but having three would suffice (Passenger, Express, and Freight, for example).

#3.) Classes of trains, and types of trains. I would like to suggest the ability to define a consist as "Passenger," "Freight," or "Express." This would be more convenient (in my mind) than the current way of defining it in each car's definition file. The ability to define a service as a First, Second, or Third class service would be excellent, and that leads into my fourth suggestion.

#4.) Ability to use class-based logic in activity editing. To more closely imitate US (and I'm sure European) operations, there are multiple classes of trains. Currently, in MSTS, I can be running a third class local train and hold up the railroads crack passenger train. This would not be tolerated in real operations. I can see, though, that this might be extremely difficult to program. It would be nice, though, if we could have the Class 3 local wait at the first available siding for the Class 1 instead of proceeding ahead and holding up the passenger train.

#5.) Humping and kicking cars. Something done in some rail yards is "humping" or "kicking" cars. You basically cut the car and let it slide into the next car as you are building a train.

#6.) Better control for helper locomotives. Currently, if a helper attaches onto the back of a train, it acts as if it were the lead locomotive, and the real lead locomotives headlamp is extinguished, etc.

#7.) Something that tells us how long our train is and how much it weighs. An EoT sort of device.

#8.) The ability to set a point as you are riding that will remain there until the last car of the train passes, then alerts you that the rear of the train is clear. THIS would also be important to speed limits, as trains are supposed to (in general) follow the previous speed until the last car of the train clears the speed post. Currently on the track monitor the speed changes as soon as the locomotive passes it.

Those are some issues I thought up off the top of my head, I will probably have more later.

I appreciate you setting this forum up and taking the time to listen to our concerns, I am looking forward to your product. I bought MSTS the day it came out and have loved it ever since then.

Thank you for your time in reading this post!!! :-)

[OTTODAD]

Hi Brian !

One thing I really really need to suggest is the ability to switch locomotives.

This has been at the top of my Wish List since MSTS-2 was on the cards, like making up a freight train with a yard loco and then hand it over to more powerful locos to haul it up into the mountains !

The other is being able to switch cabs, which we now have with MSTSBin-1.5.7, but not quite functioning as far as switches are concerned facing the rear cab and coupling one consist onto another when the rear cab is active, causing ghost units !

KUJU are taking notes of all suggestions, but not all will be feasible to be included in order to keep the retail price at an affordable level.

However, there could perhaps be a PRO version of it one day ? ;-)

O t t o

[mjs2101]

Being a fan of the steam locomotive, I hope that you are able to recreate a more realistic sound environment for these wonderful locomotives.

1) Sound based on piston stroke rather than wheel diameter.

2) Being able to listen to your train and tell if it is running light or pulling a heavy load. What is known as Stack Talk!

3) Having unique sounds linked to the engine itself, or customizable within the file but linked to the model; such as wheels slipping, or your pop valves going off.

4) Would be great if you could have an interactive world environment. Being able to hear the sounds of an approaching train off in the distance as it echos off the valley walls, getting louder as it draws closer. Or while riding said train, being able to listen to your engine echoing through the valley before you.

5) A more customizable sound package. Being able to link sounds to in simulation indicators. Such as air pumps, injector

To me, sounds really help to make a sim! When I watch a train video, I love to listen to the train and NOT the narrators. :) And while MSTS does a decent job with sounds, there is definitely much room for improvement in this department!

As for content creation, I hope you will keep in mind the existing programs used for creating content for MSTS. Being a user of 3D Canvas, I am hopeful I could use this program for creating content for your new sim, rather than having to learn something new.

I do wish you all luck on this simulator and hope you will take your time and get it done right!

Mykel

[seern]

Being able to have AI trains pull into a yard or station and remain there. It is so disconcerting to see an AI train come to a stop and go 'poof'. Being able to have realistic helper locomotives is also high on my list of wishes. Better control of the AI dispatcher, being able to set a signal at stop for a player even though there is no AI train in the few blocks ahead, and have this signal stay at stop until the designated AI is past. This would allow us to have a player wait for say 2 AI trains with the second being the designated clearing AI. Easier control on overtaking meets, the double reverse point works ok, but a way to set this up in the dispatching system would be great.

Just a few of my 'wants'.

[sstyrnol]

>Better control of the AI dispatcher, being able to set a signal at stop for a player even though there is no AI train in the few blocks ahead, and have this signal stay at stop until the designated AI is past.

Could this be done with a train priority matrix or something? I.e. when designing an activity, that you pull up a list of trains and designate a train type or something and thus specifiying how "important" a given train is and that the AI decides which train has priority on the main based on that table...

[OTTODAD]

Hi Sebastian !

Don't know how this works in Germany but here in the UK I think a passenger train running to a time table is given priority by a dispatcher or automated signaling system ?

O t t o

[bnsf4794]

I completely agree with point #5 that Mrrextreme made, keeping program parameters and variables open for tweaking! Having played a part in 4 commercial route projects and setting up rolling stock of my own, I can tell you that being able to play with variables is vitally important and usually pretty fun too. Being able to write signalling scripts made MSTS quite versatile, even with its limitations. Being able to tweak rolling-stock physics, sounds, visuals, etc was where I got most of my enjoyment from the sim. Even something as simple as being able to change the game's FOV setting is a big plus. These types of versatility are the major things I've always loved about MSTS.

Also, having program variables available whilst in-game would be nice for KRS. An example of what I mean by this is the freeware "Orbiter" Space Simulation, where people can write there own scripts to achieve certain functions as desired, because many of the program's variables\functions are available for polling or changing, and custom-made .DLL files can be loaded into the sim. For example, if this was possible in KRS, someone could write their own CTC dispatching program, instrument panels could be custom-designed for any locomotive, really the sky is the limit on what could be done if only we could poll and\or change variables on the fly.

John Greenstone

[ragtimer]

Yes Otto,here in UK the passengers get priority even if they go slower than a freight!The freight may run at only 60mph but it is relentless (signalling and speed restrictions permitting) whereas the passenger keeps stopping and the freight's possible average speed will be higher but we still come second and keep getting those darn yellows and reds!

[sstyrnol]

That is because in most European countries passenger operations are the main focus of railroading throughout the day.

In the US, passenger trains make up only a minor amount of the daily traffic.

[USRailFan]

Here in Norway, container trains are actually prioritised before passenger trains on long-distance lines, the only times passenger trains take priority is if it is a night train that is very late (ie a lot of people in danger of losing their connections, meaning the railroad will have to pay through the nose for aeroplane tickets or hotel reservations), or on regional/suburban lines.

[OTTODAD]

This shows how difficult it must be to design a Train Simulator to cater for all variations in worldwide railroad practices and differences in the operation of country specific locos of many types.

It would be easier to create different versions rather than trying to make just one to fit all, or it will again be left to experts in the community to modify what needs to be ?

From what I have seen on TV over the years, class 1 railroads in the USA even have their own individual signaling and dispatcher systems, whereas here in the UK the entire railway network has used the same, now being gradually modernized, which will take years to complete !

O t t o

[sstyrnol]

Here in Germany we have

- Semaphores (being slowly phased out, but still around)
- Standard German Railways type color light signals
- Ex-East German Reichsbahn color light signals in East Germany
- Simplified new-style color light signals for new highspeed lines
- Simplified signalling for branchlines under branchline operating regulations (Vereinfachter Nebenbahndienst = similar to the US train orders system).

[Bill Hobbs]

Mykel,
I have been working on steam sound for over a year now. Your item 5 is pretty much possible now, except for the fact that not all the toggles were fully implemented in the original.
The big difficulty lies in creating true stack talk. I have been relying on my own library of steam sounds, recorded over a number of years mostly on the C&TS. If the new sound works anything like the current sound, I doubt that anyone out there would have the sound recordings needed to create realistic stack talk. Here is the problem: recordings of different cutoffs at different speeds for the loops are quite difficult to come by unless one can simply "lease" a locomotive for a day and have it run to one's specifications on throttle and cutoff settings. And once one had such sounds, it would require a means of switching between loops based on rotation rate and cutoff settings to implement.
Back when model RR sound was created using analog devices, it was quite easy to simulate variations in cutoff at different speeds: chuffs were synthesized by the machine and the attack and decay could be regulated by pots on the device. Going to digital sound has made that much more difficult to handle and I have yet to find a completely satisfactory solution in the market.

[ChrisS68]

Of course, you can't possibly design the sim for every eventuality - this is where having an open architecture is vital. The signaling in MSTS appears to be rather open to customization (at this point that's from a layman's point of view).
I believe that offering a few standard preset systems, that are able to be customized, would be the way to go - again, like MSTS.

Chris

[ChrisS68]

I hope you folks at KUJU know what you've opened yourselves up for. Folks around here can be somewhat... opinionated!
There's some good suggestions here. Some of my wants are reiterations of what has been said already. I guess some of this stuff might be hard or impossible to implement, depending on where you're at in production. Some of these are issues from MSTS that may, or may not, have been solved already.

1. The front coupler problem. One should be able to couple onto and move or otherwise operate a train or cars at either end of the locomotive or consist - this is imperatave for some operations. Along the same lines (a minor gripe) is that cars (wagons) should behave normally, no matter which side the locomotive is coupled to.

2. The ability to change locomotives within the game, particularly within the player's consist. This suggestion is also related to suggestion #1. IF you drop of cars, and/or pick some up, you want to be able to tie onto cars and travel in the direction from which you came, without having to wye the power.

3. Waiting points (AI traffic). An AI train should be able to wait at the beginning or end of its path, or at any point in between for a specified amount of time. This helps with timing, and avoids the issue of trains suddenly appearing and disappearing when this is undesireable.

4. Prioritization of traffic. Different trains should have different levels of importance, perhaps along the lines of; A (hotshot or passenger), B (standard priority trains), and C (local jobs and such). Maybe there's a way to give "A" trains 3 blocks ahead of movement, "B" trains would get two, and "C" trains would get one block at a time. If multiple trains attempted to get a clear at a particular control point at the same time, then the order would, obviously, be A, B, and C.

5. The ability to bleed-off the brakes from cars, and "kick", "hump", or otherwise cut off in motion for switching/classification.

6. Signaling. From what I can tell, the signaling in MSTS works rather well. I think the important thing is to make the scripting open enough to allow changes to be made. One thing that would be nice, would be the ability to enter an occupied block by receiving a restricting signal, or by permission to pass a red. Obviously, if the trains' movements are opposing, this would be a bad thing, but if movements are in the same direction, the following train should be able to get permission from the dispatcher to proceed at restricted speed.

Now we're starting to get into the real "wish list" realm - stuff that would be really neat, but may be prohibitively difficult to do.

6. AI trains performing "player" type actions, including dropping off cars, assembling trains, etc. This would make operations far more dynamic and, I suppose, would eliminate any differences between Player and AI services. Yards with AI switchers working to assemble trains. Riding by on a through-freight, while the AI local job works some industries. Assembling a train and then having the AI road power come out of the service track to take the train to its destination or, conversely, waiting for your train to be assembled by the AI switcher before starting your trip.

7. True multi-player capability. Having the ability to have more than one member on a crew; engineer, conductor, and maybe brakeman, as well as the ability for someone take on the role of dispatcher. Perhaps this could be done along the lines of a first-person "shooter" type game.

Above all, I think it's really important to keep the architecture open, as with MSTS. It's impossible to create something that will be all things to all people, but the ability to modify scripts, and generally tinker with settings and parameters, will allow people to customize the sim to their taste and make it better for everyone.

Chris

[plainsman]

Some other things that need attention:
1) In MSTS Geared locomotives operate in reverse such that they take off like a rocket. They should operate the same in forward and reverse.

2) In dynamic braking, the dynamics don't just fall out completely once the DynamicBrakesMaximumSpeedForFadeOut is reached, which is what happens in MSTS. Rather the force just stays about flat from that point on as speed increases.

3) Obviously, having traction motors overheat appropriately and fail if not corrected, is a very essential part of the operation of heavy freight consists.

4) Having AC units able to report in cab data as prototypical units would. This means you don't have an amp meter, but a direct readout of tractive effort. The TE should account for the characteristics of AC traction motors.

5) Curve resistance or friction needs to be modeled and straight line resistance or friction needs to be more easily and fully replicable of Davis and other equations, including a better ability to model friction bearings. Use of the large negative coefficient in current fudges to get MSTS to model these creates issues as well.

6) Blended braking needs to be available.

7) Retainer sets need to be available for braking.

8) Slack run and runup need to be modeled.

9) Diesel Electric locomotives need to be able to change gearing directly, rather than having to completely rewrite the entire .eng file. Gear selection needs to be an operative parameter. An F9 unit with 57:20 gears needs to be appropriate for speeds and pull as should a F9 with 62:15 gears, and they will be very different.

10) There should be no max weight or size limitations for units.

11) Sanding adhesion should be a variable not a fixed parameter.

12) MSTS has slightly too little reduction in adhesion for wet rail and too much reduction in adhesion for icey rail (as set in the default .wag). Wet rail usually has oil and grease that accumulate on rail and reduce wet rail more than default accounts. High pressure under wheels, tends to make snow and ice behave unlike snow and ice at normal pressure.

13) Wheelslip should allow for creep which will increase adhesion up to about 12-14% slipage, then it should fall rapidly beyond that.

14) Power limiting needs to be able to be modeled. A GP40 for example does not have full 3,000 HP available below about 23 mph, and at 14-15 mph is only able to create 2,000 HP. This is because of the limitations of the traction motors to absorb current.

Enough for one post.
Thanks for listening,
Bob Boudoin

[rfranzosa]

1) Fixed camera locations that do not 'travel' with the train (i.e. a train-watching spot). Auran allows camera's to be placed at 'junctions', crossings, station platforms would be good locations as well.

2) Allow AI trains to reverse direction (AI switching moves)

3) Allow player trains to couple to AI trains (helpers, engine changes, etc)

4) Allow player to switch to another (AI) train.

Thanks

Rick Franzosa
ZosaTrains

[plainsman]

Three more physics suggestions:

1) Get rid of NumWheels ( x ) parameter. This has always been very confusing to a lot of the community. Instead, just have two parameters, total mass or weight, and mass or weight on drivers. Then have adhesion input as its actual respective amounts, slipping, clean dry, and with sanding with the adhesion adjusted based on the ratio of weight on drivers to total weight.

2) Allow for brake pipe propagation. Air is a compressable fluid. It is not like hydraulic fluid used in automotive brake lines. It takes time for the brake line to transmit a signal down a long freight, so the front of the train can be braking, while the back of the train has not yet acquired the signal to apply the brakes. This is very important in North American freight operation.

3) Create a better way to handle multiple unit lashups. Not only should sound and effects like smoke apply to all operative units, but the physics model should be comprehensive enough to model the 4 and 5 unit consists often seen at the front of North American freights. If you put an AC6000 in front of a GP7 on a heavy freight, and then switch with the GP7 unit as lead, in MSTS, the consist suffers too much penalty for the GP7 lead. This is because the program did not really plan for the multiple unit operation in the game engine, and thus had to oversimplify the trailing unit performance. I know this is not a combination likely to run in real railroading, but it illustrates the problem in the extreme.

[mjs2101]

That is probably the biggest problem with creating sound for steam locomotives, the fact that good recordings don't really exist for most of them.

But, if they could in some way, link the "chuff" sounds with the throttle, reverser and train load, then that would give a great foundation for doing more realistic sounds. Then, maybe in the sound file, give the ability to adjust various aspects of the sound clip (.wav); such as pitch, bass, etc.... when certain conditions are met.

Of course, not knowing anything about programming, not sure what is and what isn't possible. At least we can keep our fingers crossed. :)

Mykel

[jovet]

With programming in general, practically anything imaginable is possible.

It's just a matter of deciding how much time and money to devote to the end goal.

I would pay a lot of money for an insanely-great train simulator, now realizing how addicted to them I am. I'd also wait quite a while, too. (Though, I hadn't even heard of MSTS 8 months ago.) The bottom line is it isn't always an easy decision for a developer to decide where to draw the line on a feature versus time. With something as complicated as a simulation game, it's even harder.

I think MSTS is pretty darn good, and it has impressed and even awed me in a lot of ways. (It's also caused me to swear virulently.)

MSTS's biggest drawback was always that MSTS 2 was cancelled, though. The great thing about programming is that it can always be improved, so even if the first go of the new Kuju sim is dissapointing to some, it isn't a reason to give up on it.

I hope that Kuju has been prepared for the amount of feedback they are going to receive from the train simulator community. There are lots of good (and detailed) ideas that can be focused upon, and I don't envy their task of prioritizing them.

Just as long as they fix my biggest MSTS gripe: the flat, 2D, unhumped, completely-foreign-looking, often-sorely-textured trackbed. :)

[plainsman]

Another few items:

Add a parameter called transmission efficiency. This will reduce power at the rail by the efficiency of the design modeled. This can range from as low as 80% for some first generation diesels, up to 89-90% for moden DC locomotives, and up to almost 95% for the latest AC locomotives.

Make starting tractive effort and continuous tractive effort function correctly, and allow DieselEngineSpeedOfMaxTractiveEffort( 9mph ) to set the speed for traction motors to begin to overheat. Allow considerable time at speeds near but below this before the traction motors actually fail. You can find time ratings at various speeds below speed at CTE in some operators manuals.
Bob

[CajunRon]

In reading these post it is obvious that we are a diverse group with diverse interest and items of importance and I appreciate the challenge and the efforts of Kuju to listen to what must seem like a bunch of "spoiled brats" at Christmas time ;).

Personally I am not too demanding. I would be more than pleased with a product equal in graphics quality and physics modeling of MSTS but with three major fixes.

1) Most importantly, properly modeled real world signaling systems and AI train control movements that work. (No stalemate standoffs, accurate AI timings, etc)
2) No severe punishment (like having to start all over on a 1 hour acitivity) for accidentally running a red signal by as much as a coupler knuckle.
3) Fixed front coupler operation

Very modest requests. Of course anything more will just be icing on the cake for me ;)

[MRRextreme]

<<equal in graphics quality and physics modeling of MSTS >>
yup!

<<Very modest requests. >>
...but good ones :)

[plainsman]

I quite disagree that the points addressed here are "spoiled brat" issues. Each of these represents many many hours of frustrations in trying to create realistic files to model various equipment in MSTS. If the physics are no better than MSTS even without the bugs, we will still be stuck with hardwired limitations that are not recognizing that computing power has made giant stides since MSTS was written, and no need is now there to design the physics around computing power of a typical user 5 years ago.
Secondly, and I do think this is IMPORTANT, since MSTS was unsupported, many of these things would have been addressed in fixes that should have been addressed for MSTS, or then added to MSTS2, neither of which occured. None of these things were omitted in the community expectations discussed with other competing simulator projects when they were on schedule or alive as the case may be. We have had 5 years of waiting to get some attention from Kuju on many of these issues, and had some of them been addressed as timely support patches, these long lists would not be needed.
Third, In one of the earlier posts, the Kuju representative asked what needed to be done to accomodate North American railroading and each of these things is a problem in modeling NA operations at this time in MSTS. If they had not asked for input, I would not have created the lists.
I am not trying to create a conflict here, I only wanted to point out my reasons for noting these issues. I was not trying to be a spoiled brat, in fact I am painfully close to 60 years old, and have spent the last 5 years with more hours than many of you might imagine as related to a hobby, on developing realistic physics files for MSTS. I think that investment in time has earned a right to voice my physics issues concerning a new simulator.
Hope this has made this more clear.
Bob Boudoin

[plainsman]

To illustrate, lets take the first point...
1) In MSTS Geared locomotives operate in reverse such that they take off like a rocket. They should operate the same in forward and reverse.

Back in 07-11-2001 Ron Paludan and I (it was Ron's excellent repaint and mostly my .eng file mods) released a repaint of the KIHA31 into a facsimilie of a Santa Fe Doodlebug, sfwbdb.zip. Now to judge by todays standards, it would be unthinkable to use such an unrelated default file to model a Doodlebug, but keep in mind this was one of the first repaints out there, and may have been the first to edit the .eng file to a significant degree?
One of the early activities using this locomotive was to park a passenger car south of Columbia Falls at the airport siding, and have the Doodlebug arrive from Kalispell, back into the siding and couple with the passenger car and proceed with tourists up to Essex Lodge. This sounds pretty simple, until you try to back the Doodlebug into the siding. Whoa.. that thing accelerates like it has rocket assist in reverse. Now most may have forgotten this download by now, but I did spend enough time to come back in 08-05-2005 and issue a revised .eng file doodlud.zip, which fudged around some of the issues as well as possible.
Now in between, I did another project with Ron on a little switcher locomotive that was supposed to have multiple gears. This same bug just ate our lunch in trying to design a realistic version of that switcher using the geared type file.
Now I know that bug may not be important to many here, (although at least 332 folks took the time to upload a patch .eng file for a 4 year old repaint file), but if you look at all the time I spent trying to fix this issue, or mitigate it, so a simple activity would work, you may understand why I generated the list of things that seem petulant to you.
Bob Boudoin

[JLChauvin]

I agree with you Bob, we are in the obligation to spend countless hours only trying to fix even a small issue, only to see an other one comming! If only we had a begin of support from the MSTS designers...
There are so many things to say about the lack of support... as if MSTS was in beta version since 5 years!
Even for European trains, it's nearly impossible to make good modern electric engine physics for exemple... dynamic brake AND blended brake, without speaking of not working Graduated_release_triple_valve, letting us with modern European trains with triple_valves!!!!!

--------------------------------------
Jean-Louis tchouftchouf Chauvin
Wheelbarrow "driver"

[MRRextreme]

<<I do think this is IMPORTANT, since MSTS was unsupported, many of these things would have been addressed in fixes that should have been addressed for MSTS, or then added to MSTS2,>>
You are right and I support your comments.

<<with more hours than many of you might imagine as related to a hobby, on developing realistic physics files for MSTS.>>
My affirmation of the comments was not meant to be dismissive of your efforts. I am just glad Kuju is back.

<< If only we had a begin of support from the MSTS designers...>>
Hopefully Electronic Arts won't let this happen again

[ozdriver]

Graduated_release_triple_valve

When was that invented ????
Don't you mean Grade control , where the triple valve is restricted in it's release time thereby extending the braking time

[OTTODAD]

I do think this is IMPORTANT, since MSTS was unsupported, many of these things would have been addressed in fixes that should have been addressed for MSTS, or then added to MSTS2.

There seems to be an attitude here in the U.K., manufacturers saying "don't talk to us about problems with our product, talk to the supplier who sold it to you" !

Is this the case in the USA also ?

Microsoft having been the vendor of MSTS should have noted all complaints and suggestions and done something about them. But unless doing that makes billions for them or is likely to affect future sales then it is not a priority ! :-(

O t t o

[JLChauvin]

>Graduated_release_triple_valve
>
>When was that invented ????
>Don't you mean Grade control , where the triple valve is
>restricted in it's release time thereby extending the braking
>time

This is a very, very old invention! It's a triple valve with graduated release capacity... long time utilized by Central-Europ Railways and US Passenger cars!
All of the curent UIC roling stock is equiped with that device, also named Distributor, even the simplest freight wagon.
You are confusing with "Retainer" or retaining vave ( called "dispositif Plaine-Montagne" in France ) alowing mountain operations.
--------------------------------------
Jean-Louis tchouftchouf Chauvin
Wheelbarrow "driver"

[Bill Hobbs]

Jean-Louis,
I too have found myself spending many hours trying to make small improvements in the physics of cars and locos, in good part because the Tech Docs explanations were not sufficient to enable on to figure out what was going on and testing the black box was required.

Improvements in documentation would be an immense help to those of use who like to add on to the basic platform.

[muskokaandtahoe]

> There seems to be an attitude here in the U.K., manufacturers
> saying "don't talk to us about problems with our product, talk to
> the supplier who sold it to you" !

> Is this the case in the USA also ?

Only for automobiles and you can see where that attitude got them.

Generally Americans have a much, much higher expectation of service -- both as a consumer and on the sales side -- than do the Brits.

[b]Dave Nelson
SLW Route Design: The Cal-P, 1950.[b]
http://i3.photobucket.com/albums/y51/muskokaandtahoe/Avatars/Dancing_Genma.gif
http://i3.photobucket.com/albums/y51/muskokaandtahoe/Avatars/4ad3d633.jpg

[OTTODAD]

Generally Americans have a much, much higher expectation of service -- both as a consumer and on the sales side.

Yes, Dave, we are getting a taste of that too, WALMART now having stores in the UK ! ;-)

O t t o

[mjs2101]

"WALMART now having stores in the UK ! "

You have my sympathies Otto! :+ Besides, I don't think many people today would equate GOOD customer service with Walmart. As the saying goes; "You get what you pay for". Fortunately KUJU is not a giant company like MS, so hopefully they will be more interactive with their consumer base!

Mykel

[ozdriver]

Can you explain the operation of this Graduated triple valve a bit more?

A normal triple valve connected to a single brake pipe system can only be in the release or applied position, there is a sort of lap position but this is only when the air on both sides of the triple piston is equal
About a 4 psi difference in the brake pipe and the face of the triple piston is enough to change it to applied or release
The driver can only do this 2 and Half times before he runs out of air in the auxiliary reservoir that supplies air to the brake cylinders
The triple valve got its name because it does three (3) things
Controls the air from brake pipe to the auxiliary reservoir
Auxiliary reservoir to brake cylinder
And brake cylinder the atmosphere

So to have a Graduated triple valve you would need to have a supply of air connected to the auxiliary reservoir to supply endless air to the brake cylinders
This would mean a twin pipe arrangement and an electrical control of the slide valve in the triple valve
So what we really have is an EP brake

[JLChauvin]

>Can you explain the operation of this Graduated triple valve
>a bit more?
>
>A normal triple valve connected to a single brake pipe system
>can only be in the release or applied position, there is a
>sort of lap position but this is only when the air on both
>sides of the triple piston is equal
>About a 4 psi difference in the brake pipe and the face of the
>triple piston is enough to change it to applied or release
>The driver can only do this 2 and Half times before he runs
>out of air in the auxiliary reservoir that supplies air to the
>brake cylinders
>The triple valve got its name because it does three (3)
>things
>Controls the air from brake pipe to the auxiliary reservoir
>Auxiliary reservoir to brake cylinder
>And brake cylinder the atmosphere
>
>So to have a Graduated triple valve you would need to have a
>supply of air connected to the auxiliary reservoir to supply
>endless air to the brake cylinders
>This would mean a twin pipe arrangement and an electrical
>control of the slide valve in the triple valve
>So what we really have is an EP brake
>
>

No,no, no...

It seem you have only partial informations about train braking.
You only need the single Brake pipe and Auxiliary reservoir, the internal feature make the graduated release. Here, in Europ, all the rail vehicles are equiped with "Distributors", alowing the graduate release with the Brake pipe only. Most of Passenger cars have a second pipe, only to accelerate the Auxiliary reservoir filling.

EP brake is not a single system, there is many ways to command the train brake.
One of the most common is to control application and release on each vehicle at the same time with the help of electric valves, only to accelerate the reaction rate, but the brake work also without the electrical and second pipe.
An other is to command the brake valve itself with electric wires, but in this case the vehicle can't brake without the EP feature (except in Emergency).

I think you are confused by the MSTS "Distributor" designation: once again the lack of support let us in the dark...

PS: I am on the rails since 1977, engineer since 1981, so I believe to have some basic knoledge about railway operations...
--------------------------------------
Jean-Louis tchouftchouf Chauvin
Wheelbarrow "driver"

[ozdriver]

I ask my question again then

Can you explain the operation of this Graduated triple valve?

As my forum name suggests I too was a driver 72-98

>It seem you have only partial information about train braking
I had to know the operation of the triple valve, and had to describe it to an examiner before I even got to sit in an engine

>You only need the single Brake pipe and Auxiliary reservoir, the >internal feature makes the graduated release
So how can you make something that was designed to be two positions, only ON or OFF, do something else without external control

>All the rail vehicles are equipped with "Distributors
So how does this work then?
It must be connected to the auxiliary reservoir or the slide valve in the triple valve
And without a supply of air apart from the Auxiliary reservoir you still only have two and a half applications of the brakes before you run out of air

>Most of Passenger cars have a second pipe, only to accelerate the >Auxiliary reservoir filling.
A very good idea but there still comes a time if the driver uses the brake too much that he runs out of air in the brake pipe instead of the Auxiliary reservoir

>One of the most common is to control application and release on each >vehicle at the same time with the help of >electric valves, only to >accelerate the reaction rate, but the brake work also without the >electrical and second pipe
Exactly, an EP brake, and the vehicle is fitted with a triple valve although it must be incorporated into the EP brake for failsafe operation

>I think you are confused by the MSTS "Distributor" designation: once >again the lack of support let us in the dark...
I think everyone was confused by MSTS description of parameters
Distributor valve being one ,I think should ONLY apply to engines, controlling air between the automatic brake and independent brake on the engine

>engineer since 1981, so I believe to have some basic knowledge about >railway operations
You should have more than basic knowledge then
I await you description

[ragtimer]

This thread explains why Kuju need to get technical assistance from real railroad people.Even those of us who do work in the industry perhaps do not understand properly the operation of Westinghouse type air brakes.I do know you can run out of air,something which is more difficult with an EP type brake because it can be inched on and off once the initial application has been made.I have seen it explained on several occasions but it still confuses me.If they do not understand it,how can they simulate it?

[JLChauvin]

>I ask my question again then
>
>Can you explain the operation of this Graduated triple valve?
>
>As my forum name suggests I too was a driver 72-98
>
>>It seem you have only partial information about train
>braking
>I had to know the operation of the triple valve, and had to
>describe it to an examiner before I even got to sit in an
>engine
>
> >You only need the single Brake pipe and Auxiliary reservoir,
>the >internal feature makes the graduated release
>So how can you make something that was designed to be two
>positions, only ON or OFF, do something else without external
>control
>
>>All the rail vehicles are equipped with "Distributors
>So how does this work then?
>It must be connected to the auxiliary reservoir or the slide
>valve in the triple valve
>And without a supply of air apart from the Auxiliary reservoir
>you still only have two and a half applications of the brakes
>before you run out of air
>
>>Most of Passenger cars have a second pipe, only to accelerate
>the >Auxiliary reservoir filling.
>A very good idea but there still comes a time if the driver
>uses the brake too much that he runs out of air in the brake
>pipe instead of the Auxiliary reservoir
>
>>One of the most common is to control application and release
>on each >vehicle at the same time with the help of >electric
>valves, only to >accelerate the reaction rate, but the brake
>work also without the >electrical and second pipe
>Exactly, an EP brake, and the vehicle is fitted with a triple
>valve although it must be incorporated into the EP brake for
>failsafe operation
>
>>I think you are confused by the MSTS "Distributor"
>designation: once >again the lack of support let us in the
>dark...
>I think everyone was confused by MSTS description of
>parameters
>Distributor valve being one ,I think should ONLY apply to
>engines, controlling air between the automatic brake and
>independent brake on the engine
>
>>engineer since 1981, so I believe to have some basic
>knowledge about >railway operations
>You should have more than basic knowledge then
>I await you description
>
>

I don't want to be rude, but it seem to me you are not aware of the rest of the world practice.
I am working with this kind of valve since the begining, like all the European drivers, I can assume you that this is a real thing!
This is from an old book ( 1947 ) description of a graduated release triple valve used in Central-Europ...
The second is about US D-22-AR Control Valve...
The last one is a modern UIC distributor...
You can see that the Auxiliary Reservoir (Ra) is alway filled by the Brake Pipe (CG) across the Antireturn Valve (Clapet de retenue), so the pressure inside Ra can't be under the CG pressure. It's the same thing for the Command Reservoir (Rc) across the Command Reservoir locking (Verouillage Rc), but this one stay at reference Brake Pipe pressure, acting like a ressort. You have an almost innexhaustible brake, you can make all application / release you need... The only think is to have a perfect Rc air-tightness.
For sure, this is a simplified model, because there is many improvments and other features.
Hope this will help to clarify the situation.
--------------------------------------
Jean-Louis tchouftchouf Chauvin
Wheelbarrow "driver"

[JLChauvin]

>Even those of us who do
>work in the industry perhaps do not understand properly the
>operation of Westinghouse type air brakes.

Because some of us are looking from their own system only, but for someone interested this is a big chalenge to understand how a train brake works over other horizon!
The problem is the way each continent is using the same invention.
There is many differences between the AAR (American) standard, UIC (European) Standard, Russian Standard... The same system diverged into many solutions. And we don't talk about Vacuum Brake, this is an other story!
This is why we can say KUJU need more than one "expert" about braking, same thing for all others features.
--------------------------------------
Jean-Louis tchouftchouf Chauvin
Wheelbarrow "driver"

[Erick_Cantu]

You're all forgetting the most important item - multiple units notching in synch. Speed based trailing unit sounds suck.

[ragtimer]

That is just one of the many obvious bugs their testers missed.

[plainsman]

Hi Erick,
From #3 in my second list;
"Not only should sound and effects like smoke apply to all operative units"
Repetition may be a good thing here!
Bob

[muskokaandtahoe]

> but we have ensured that our base systems we create now don’t rule out additional features to cover the vast diversity in the railway world.

Ok, pulling back to the basenote I see a comment about the diversity found in the real world. This immmediately brings to mind a couple of features found in the railway world that were not handled very well in MSTS that I hope will be better addressed in KRS.

Not all places have snow in winter, but have rain instead. Or either. If a directory tree is going to be used to hold skins of a seasonal nature please create optional directories under each season for both of thess types of precipitation, leaving the parent directory as the default for "dry" weather.

Spring and fall seasons in most places of the temperate world also look quite different than summer or winter.

Different bodies of water often look quite different. Lakes do not look like seashores and swampy sloughs don't look like mountain streams. Had MSTS allowed for two terrtexes per subtile -- the water one being optional, we'd have had a decent solution (pardon the pun). Something like that would be most welcome.

There are lots of "rough" places where the result of game terrain vertex editing would be greatly improved by a much smaller mesh of polys. Using MSTS-speak for an example, allowing a user toggle the occasional poly from 8m to, say, 2m would have greatly improved the look of many cuts and cliffs.

Urban density... Please use all the memory a machine has to offer.

Documentation. I know it may seem to be giving away state secrets, but please document the performance formulas for things like braking, friction, steam locomotive power and fuel consumption. You know we're going to tweek the numbers. It'll save us loads of time. :D Steam locomotives in particular remain the least like the real thing in MSTS.

Cameras. The phrase train spotting has a certain air to it in the UK but we all still do it. More cameras, incl those that can be afixed to one spot just like any other object would be most welcome.

Slack action will probably take more than a few cpu cycles but if it can be done w/o bringing the whole game down on it's knees it'll be good.

and lastly, please keep the water level adjustable-by-seasons (just for me!) as the water level route I'm building does include both tide and flood conditions!

And if Miss L. Lohan could deliver my cd....

[oakpalms]

Some of the guys have given some very good suggestions.

1. I would like to see some system of standards set from the beginning as to how engines and cars will be identified and named. Every download requires much time simply renaming everything. One suggestion would be to have all rolling stock (cars) start with the type of car, followed by the company name, followed by identifying feature, followed by either loaded or empty, followed by builder. An example: BOX ATSF 315754 LD KUJU. This would be a boxcar from the Santa Fe number 315754 loaded and built by Kuju. MT would designate cars that are empty. Engines would be the same: SD40-2 ATSF 8558 WB 3DTS. This would equate to an SD 40 engine from the Santa Fe with warbonnet paint scheme and built by 3DTS. Whatever is determined, it should help bring uniformity to the hobby.

2. We need an improved sorting method to be used with engines and cars as well as a search capability to be included in the Activity Editor or what ever you call the replacement tool for the Activity Editor.

3. We need graduation of environments concerning mountainous terrain. When an activity is set up for snow we should be able to determine what elevations that relates to or it should be built into the program. For example, the Seligman Sub freeware route starts at 500 feet in elevation and climbs to over 7000 feet. At the 500 foot level along the California-Arizona state line, they never get snow, but at the 7000 feet level it can be a blizzard like experience. There are many routes that would be similar since most of the routes climb over the mountains and back down. Since much of western America is concerned with mountainous terrain this should be a big feature. Some type of graduation of the snow effect according to elevation would be more realistic. However, eastern America is quite different. Eastern routes do not go much above 4000-5000 feet in elevation so you can have a lot of snow at the top and even at sea level elevations.

It would be nice if the the Activity Builder had a means to determine the type of environment that would occur based upon know elevations and route characteristics. For example, elevation 0 could be set as clear, elvation 1 to be set as cloudy, elvation 2 to be set as rain, elevation 3 to be set as light snow, elvation 4 to be set as heavy snow and elvation 5 to be set as a blizzard. This would divide the total rise and fall in elevation into six different elevations and create a change in climate.

Route builders should have a place where the total rise and fall in elevation of their route is included to make use with this system. Of course, this would allow clear skies, rain, or snow to be falling over the entire route is so selected by the Activity Builder.

Bob Edwards
North Port, FL

[SurvivorSean]

I'd personally like to see in addition to the naming convention of the cars, an actual base model as opposed to a number. By this I mean say a title "BOX CN 50 foot former IC". Now from this of course you say where is the number?

To me it's a waste of memory and hard drive space having different numbers represented for the same type of rolling stock. Besides grafitti, the car number would be the only thing unique to the stock.

Why not have a font file built in with the 3d model, so that users and or the program can assign the appropriate number for the stock. This would also eliminate the number system that MSTS uses for identifying cars to switch, where it should be identified by the actual number anyways.

On a side note (this is not a FYM plug) but there are advantages to such programs like FYM, switch list generators, etc to allow the use of similar cars, and call them up to ID them based on actual car numbers, not those manufactured by the program itself.

Thanks

Sean

[oakpalms]

Sean,
One of the problems in locating cars in the Activity Editor list is the amount of space provided for the name. The same goes with Conbuilder, Route Riter and so on. A roadname, type of car, and number could be used with other software to form a data base for keeping track of cars both in the game and for making activities. The data base could provide even more identifying features concerning the car.

The MT and LD is essential in identifying cars for consist makeup and especially switching activities. If a switch engine has to pick up six boxcars at a siding and add them to a train that is almost maxed out on pulling power it makes a big difference whether they are empty or loaded. The activity builder has to know whether the mass tonnage is for loaded or empty when arranging the activity otherwise you can end up with the player train getting stuck on the first hill. Of course, the activity builder can remake the activity until the proper number of cars will make it over the hill. But, a bit of info will make it so that remaking does not have to be done.

Many downloads do not identify how the car is configured--whether as empty or loaded. Many users may not know that the configuration in mass tons plays a big role with the actual pulling power of the train to which the car becomes attached. All open space cars, such as, coal cars, gondolas, flat cars, etc. usually come with a loaded and unloaded version if a load is included. It is the enclosed cars, such as, boxcars, tankers, reefers, etc. that usually only comes unidentified either as empty or loaded, but which makes for a problem.


Bob

[OTTODAD]

Hi guys !

This subject has been brought up by me some time ago, finding it difficult to easily identify much of the rolling stock by the names their trainsets folders and files within which have been given to them by their vendors.

I started to rename many items in need of improving. No problem for me as I usually do not use the supplied activities consists and their rolling stock, much of which I have not got anyway.

Ian Macmillan is doing similar with his "Low Poly" versions of wagons for use as loose consists in activities, prefixing their folder and files with LP and me prefixing all their consists names with LP also.

Other trainsets folders are being named by me:
D-BR = Diesel - British Rail
D-DB
D-US-DASH9
E-BR = Electric - British Rail
E-DB-ICE3
E-US-ACELA
F-BR
F-DB = Freight - Deutsche Bahn
F-US-CSX
P-BR
P-DB
P-US = Passenger - USA
S-BR-SCOT
S-DB
S-US = Steam - USA

This being a basic sorter it can then be sub-divided in other ways, like the name of the railway company using it: BNSF, the type of loco: DASH9, or the other way around, etc, avoiding names too long, remembering that space in selection list displayed on screen will always have to be limited to a certain number of characters.

Also don't forget that some of these descriptive rolling stock and their folder names have to be used describing consists using them also, externally as well as internally ! ;-)

The same goes for the naming of tracks pieces, to make their sensibly named and sorted by display in Route Editors selection lists more usable !

No matter which system will be introduced, it will not suit everybody's ideas of how it should be done, but should be possible to design a common method to suit most ! ;-)

O t t o

[SurvivorSean]

Thats why I say again numbers should be something that is not part of the uniqueness of a particular car. In fact now that you mention it neither should the Load/Empty status either. I realize what you mentions is good for Conbuilder and MSTS but I really hope this program goes way beyond what MSTS already does. Creating activities that are run once and can't be versatile in my opinion hurt the progression of MSTS. When the activity itself becomes versatile enough to populate cars either randomly, or systematically then activities can be played over and over again. The AI/Path system also needs to be dynamic enough to not be so hard coded. This is where variables like loads/empties/car number can be fully appreciated.

Each car has a 3d model of what the car looks like.

A load layer (if applicable to something like a coal, lumber load etc) is added and shows up only if the status of the car becomes a load by the program's activity system. Applicable weight values for load and empty would then apply also.

A font file is included for the car, and once again the value in the program's activity system will specify the car number to appear on the car.

In total each car would have 2 layers - 1 always on, the other on when it's a load. 1 font file to apply the car number. I'm not an expert on Trainz but I do believe a load layer of some type must already exist with their simulation. Though I don't believe that this simulator needs to see industries dumping coal into a hopper etc. Simply changing the state of load to empty is adequate for both proper physics (weight) and appearance.

Car numbers should be taken totally out of the equation of the design of a car, and since all cars prototypically use a font then the font itself would be part of the model when it is designed.

Thanks

Sean

[kujuSabrina]

Thanks for all your responses on this topic - there are a number of things we can discuss and provide more details on later. For now, however, and whilst it's too early to provide specific information, I can confirm we will have split documentation. We have always said that we are supportive of the community as a whole and as a result documenting the tools to some depth is part of that. We are also looking at the possibilities of on-line chats with some of the developers and releasing specific tutorials/hints & tips post release to ensure the information you require is easily available.

[oakpalms]

Sean and Otto,
I sure appreciate your conversation on the topic of naming rolling stock. The main thing I want to see is some type of uniformity so that everyone has some way of knowing what rolling stock is what.

While I think that a random list of cars to redo an activity might be worthwhile for some individuals, I would simply hope for a simpler way of making an activity than with MSTS. I have not tried the switch list generator, but it appears to work very well. There may be more problems in developing such a program where two or mains are involved do to having to crossover from track to track to approach a siding, but I would think it could be done.

I would like to see some type of work order that would be made which in turn would build the activity. The work order could determine the beginning location, switching to be accomplished if any, and the end of the run. It could also assign AI trains and times. It would have to use a controlled path for all AIs in response to the player train.

I like being able to select types of companies, businesses or public and government locations that are located on a route and develop a train to take care of them just like a local would for a real railroad. If a work order was used then one could easily change the work order and thus change the activity.

I would assume that any type of work order would also determine the type of motive power that would be required to execute the work order. I for one do not like the idea of a random listing--it just creates a lot of unknowns.

Bob Edwards

[SurvivorSean]

A uniform system is definately in order, and if anything comes from it that would be good. In fact the program should determine the file names to keep it uniform where as you enter the info for the rolling stock in fields. In this case nobody has to know the uniform code for filenames, and the software handles this.

As for randomness I do agree that just creating random cars throwing them anywhere is not the way to go. SLG goes a little beyond this as it actually fills workorders by car types, and capacity at different sidings. I believe this was possibly going to be upgraded down the road in a 3rd version, but it should go beyond just moving cars.

Having comdoities in a database, and a list of where they come from and where they go to me is the ultimate objective. Many model railroad programs already know this, and do a good job at exactly this. Unfortunately it has yet to become as developed in a 3d simulator as of yet, though I strongly support SLG2 as a good evolution.

I'm also very encouraged by the documentation aspect Sabrina has mentioned if I understand correctly. Being able to know how to manipulate files (not for destructive purposes, but taking advantage of open source) will allow many programmers the opportunity to contribute to a system that will be as complex or simple as the add on installed to deal with this.

Bottom line is keeping things simple at the activity level with enough adaptability to get complex should keep everyone happy.

Thanks

Sean

[muskokaandtahoe]

> Thanks for all your responses on this topic....

Your thanks are welcome Sabrina.

[muskokaandtahoe]

> Thats why I say again numbers should be something that is not part of the uniqueness of a particular car.

This is going to drive you nuts Sean :) but the best designed systems always use an assigned alphanumeric serial code as the value for a unique identifier. Sometimes an add'l field caled Revision is coupled to the identifier. When you do this you are absolutely assured of no duplications. What is needed for the user is something quite different: a bunch of add'l fields, usually named Call-out fields which are displayed for easy understanding. Whether that Call-out is one field (e.g., Description) or many (e.g., Road, Number, Model) is a choice made by the development team. Usually this is all inside a database and not done with file or directory names.

In MSTS we've had to move those Call-out files into the directory and file names and frankly it's a pain in the butt to manage. But absent a central database and a good app to access that DB, there are not many -- if any -- good ways to solve the problems you've raised.

[b]Dave Nelson
SLW Route Design: The Cal-P, 1950.[b]
http://i3.photobucket.com/albums/y51/muskokaandtahoe/Avatars/Dancing_Genma.gif
http://i3.photobucket.com/albums/y51/muskokaandtahoe/Avatars/4ad3d633.jpg

[SurvivorSean]

I think your missing my point here. I understand that in a database a unique number (known as the key) identifies the record. A key can also be concatenated over a number of fields as well. The index is where the unique number lies and it points to the keys. In any case car number would never be the unique item to identify it.

Here's is an example of what I speak of, and is currently NOT possible with MSTS. I'm hoping KRS tries this, and it really isn't that hard.

A piece of rolling stock is created. Let's say it's a 50 foot box car, Canadian National, International Paint Scheme. So hopefully a record will go along with the model (in fields) that indicate the road name of CN, the length of 50, and perhaps the comment International. It could be further unique by adding the creator's name, and version if need be.

What I am suggesting is the number NOT BE INCLUDED in any models. The combined fields of the road name, length, comment with name and version is plenty to make a model unique. I've already described how the numbers and fonts would come into play.

What this simply does is allow different numbers in a train, yard, system with the use of the same car. You can go even further with this by the comparing the necessity of MSTS AE to have you download each and every car. Imagine simply having a file call for a CN Box car 50 foot and it looks on your system for the suitable file.

Thanks

Sean

[muskokaandtahoe]

> The combined fields of the road name, length, comment with name and version is plenty to make a model unique.

Perhaps it is enough for you -- and that's ok -- but that doesn't mean everybody else is going to want to do it the same way. Even if there are a couple of "standardized" fields that are accessible.

For instance, LD vs. MTY, Mass, lading, and year (or range of years) are all attributes that could be used to differentiate a single instance of a skinned model from another (all other things being equal) -- and for the use of every one of those attributes you might/probably want something else that tells you it's not the chunky model you downloaded 3 years ago, it's the really nice one you got last week -- such as car number, OR who made it, or something else. What that something is doesn't need to be the car number (your point) but car number usually does distingush a from b rather well.

I guess what I'm getting at is the number of attributes that truely provides uniqueness is likely to be very unwiedely and often unworkable if held as a concatenated string... but the alternative of a long serial number, not fun for us to use but it guarentees uniqueness, probably requires another app to make it easy to find what you want. Hence, there are some nasty issues for us either way Kujo goes w/ this.

[b]Dave Nelson
SLW Route Design: The Cal-P, 1950.[b]
http://i3.photobucket.com/albums/y51/muskokaandtahoe/Avatars/Dancing_Genma.gif
http://i3.photobucket.com/albums/y51/muskokaandtahoe/Avatars/4ad3d633.jpg

[SurvivorSean]

I don't know if it's really that nasty. In the days of dos where your limited to 8 characters for a file name I'd totally agree. But I think simply having a version number or date say in the last 6 characters of the file name will distinguish how old or new the car may be. Will it 100% guarantee uniqueness, no, but it's sure alot safer then a similar system would be used to track ATM transactions at 20,000 instant tellers worldwide if you know what I mean.

Perhaps it can be taken a step further to allow the 6 digits to represent the car number, and some how have an optional marker in the wagon file to indicate weather or not to use fonts for car numbers or removeable loads. This will allow those that say are modeling a car from a picture that has certain grafitti on it to be accurately modeled with the "screw nafta", "Clinton likes cigars" or "I hate bush" slogans :)

Thanks

Sean

[OTTODAD]

All these are good ideas, guys, but whichever common format will be decided upon should avoid going into extreme details.

Take Internet IP addresses forinstance, a seemingly endless variety of combinations being available, there being an underlying system which tells what individual parts of it stand for. The same goes for Bank Sorting codes here in the U.K., each bank having a unique identifier which is part of it as well as the branch number. Similar is being used for phone numbers, Country + Area + Subscriber + optional Extension. In many years to come these will have to be prefixed with a galactic identifier ! :7

As an Accounting Software programmer I have learned to design the indexes of it's databases in "B-Tree" fashion, starting with the main part of the index key at the top of it and then "Branching" out to identify other parts of it so that instant searching for and retrieval of data is the result, at the same time making sensible sorting possible:

http://forums.flightsim.com/vbts/up1/107923.jpg

If some thought were also given to this when deciding on the format of track sections file names then finding individual pieces in a selection list would be easy ! ;-)

Take an alpha-numerical index key name which is 8 characters long and using numbers and UPPER case letters only has: 2,821,109,907,456 options ! :o

O t t o