[dmrick44]

Other than making announcements about the Siskiyou Route that I'm building, I haven't really had time to read much here on Elvas Tower. When I spend 16 hours a day, 7 days a week, for over 5 years, I get a sense of urgency to get things done... it's difficult to justify spending time browsing forums. At 70 years young, I'd like to finish the route before I can't hold a mouse. I tried doing some searches here and couldn't find anything posted about two of my BIGGEST concerns... I plan on spending a lot of time here once I get my Beta release out to the public.

This is directed primarily at those making decisions on what will be included in OpenRails... Of all the things that bug me about MSTS, there are 2 really big issues that make creating activities a real headache.

(1) Car spawners: In the Siskiyou Route, the tracks follow many miles of roads of all types... from single lane paved roads to long stretches of Interstate, as well as small town roads and city roads. The way MSTS is set up, you can only have one set of cars that are used for any and all roads, however, on the Interstate about every 5th vehicle is a tractor trailer. In city back streets there's hardly ever a tractor trailer. Some country roads here in Oregon have almost as many log trucks as they have cars. So, PLEASE in OpenRails make it so we can have numerous sets of cars to choose from for each spawner.

(2) This is what I consider to be the MOST IMPORTANT thing that needs to be included in OpenRails! Even if you are not part of the OpenRails "Team", please reply to this post with you own remarks. PLEASE PLEASE include the ability to create a "Location" event that will trigger the start of an AI train. It has always been been extremely difficult and time consuming to set up an activity in such a way that an AI train will meet your train at or near a specific location. Not only is it difficult to have an AI train reach a location near a certain time, but because people take different amounts of time as they progress through an activity, it is near impossible to know when the user will reach certain places along the route. If we had a "Location" event that would trigger an AI Train to begin a few miles away, it would make things not only easier, but more interesting. As it is, I have found times that it's difficult to even avoid head on collisions with AI trains. Let me mention an example...

Let's say that you are progressing south in an activity. You have to pull of the main line to drop off a car or two at some business. (This happened to me just lately.) While your train is off the main line on an unprotected siding (no signal protecting it) an AI train will get a green light allowing it to enter the block that you're working in. Then, unaware that the AI train is headed your way, you pull back out onto the main and a few minutes later... train wreck! If we had a Location event that would trigger the start of an AI train, it could be triggered after you are back out onto the main so that the AI train would detect you.

These two things, ESPECIALLY the Location event, are of the utmost importance! Anyone else agree?

Much thanks for taking the time to read this. Dale

[roeter]

Rather than 'fabricated' tooling like exactly triggering when a train drops out of the air - what about proper control as alternative? That's much more realistic.
Deadlock control already offers much better protection against such situations as was ever offered by MSTS. The timetable concept has even more options, with active interaction between trains using wait and follow commands. Presently, most control is signal-based, but it's early days yet wrt the timetable development, so hopefully further commands will be added as time goes by.
As developer, I'd much rather spend my time on proper train control, than on 'fabricated' solutions.

Regards,
Rob Roeterdink

[dmrick44]

I guess you didn't get the "gist" of my post... At this place in time I can not justify stopping and spending days reading over 200 pages of a user manual just to find out if a situation that existed in MSTS still exists in OpenRails. I use open rails and think that those who are creating it are doing a marvelous job, however, at this point I have it and use it more like a web designer has all of the important browsers that enable him to see how his creations look and function on all browsers. I realize that my route will eventually be ran on OpenRails, but as I mentioned, I'm simply a disabled vet who sits behind a computer for 16 to 22 hours a day trying to finish a project before I get so I can't work on it... I've promised people that I'm doing all I can to get the route done, and I strongly feel that I have to keep driving on to keep from disappointing them and myself.

I admit that I don't know much about the inner workings of OpenRails... My comments were just that... comments hoping that the two things that irritate me most with MSTS don't exist in OpenRails. I have no idea what "proper control" consists of or what "deadlock" is... If the situation that I tried to explain that happens inside MSTS has been handled in other ways with OpenRails, then I am indeed happy and look forward to a time when I can get more acquainted with it.

I was also curious about car spawners in my post, but I can wait to get that answered when I have more time to read your manual.

Thanks for taking the time to answer, and again, you chaps are doing a great job. Much Kudos!

[Csantucci]

Your request about multiple spawner lists is reasonable, however there is a problem: how could this be encoded in the .w file? I don't see free spaces in the CarSpawner block.

	CarSpawner (
		UiD ( 1615 )
		CarFrequency ( 15 )
		CarAvSpeed ( 25 )
		TrItemId ( 1 74 )
		TrItemId ( 1 75 )
		StaticFlags ( 00000100 )
		Position ( 550.083 678.212 321.977 )
		QDirection ( 0 0 0 1 )
		VDbId ( 4294967295 )
	)

If a new parameter were added, MSTS compatibility aspects should be considered. As of now no changes or additions to the MSTS structure of the .w files have been introduced in OR, as far as I can remember.

[DRelyea]

Hi,

Would it be possible for ORTS to have CarSpawnerXX(s) in addition to the MSTS one? The idea is ORTS will read the CarspawnerXX while MSTS will ignore it. It will require a CarspawnerXX list for each one needed.

The temporary fix would be to place the default spawner in the MSTS Route editor, then in the w file, the route builder can add the digits to the W file entry. The carspawnerXX won't show in MSTS, but should in ORTS.

Doug Relyea

[Csantucci]

I would do it so:

	CarSpawner (
		UiD ( 1442 )
		CarFrequency ( 25 )
		CarAvSpeed ( 7 )
		TrItemId ( 1 19 )
		TrItemId ( 1 20 )
		StaticFlags ( 00000100 )
		Position ( 695.706 1593.61 -801.968 )
		QDirection ( 0 0 0 1 )
		VDbId ( 4294967295 )
		ORTSCarGroup ( carspawn1.dat )
	)

The last line in the block is skipped by MSTS (both at runtime and in the RE), that handles the CarSpawner in the usual way. OR could instead get the car list from file carspawn1.dat (or any other compatible file).

However this is an extension to the .w format and must be approved, or at least must not be rejected, by the OR management team, before implementing the function. I could try to do it.

[roeter]

The main question here is : what happens if you edit that part of the route in the route-editor?
Does MSTS copy that line back into the world file when you save, or is it lost?

If it is lost, then each time you load your route in the RE, you might loose the specific car-spawner information.
It's the fact that the RE rewrites the world files and thus (probably) removes any additional ORTS information which was behind the decision not to allow ORTS additions to the world files.

By the way, you should also check the various compress/decompress tooling if those can and will properly handle such additions.

Regards,
Rob Roeterdink

[Csantucci]

I have checked. If I edit that part of route with the RE, the change is lost. That for sure is an inconvenience, however adding that line can be done at the end of the route creation.

I have also checked compressing with RR. I get an error and can't compress. Are there other compressing/decompressing tools for .w files?

[roeter]

Csantucci, on 04 February 2015 - 08:29 AM, said:

I have checked. If I edit that part of route with the RE, the change is lost. That for sure is an inconvenience, however adding that line can be done at the end of the route creation.

Doesn't sound very user-friendly. If the unsuspecting user edits a route, e.g. to move a tree out of the way, he looses all carspawners in that area.

Quote

I have also checked compressing with RR. I get an error and can't compress. Are there other compressing/decompressing tools for .w files?

Various, e.g. Comp.exe and Decomp.exe, Zipper, and a few more.
Many relate back to the original MSTS compress/decompress files. Some (but not all) might use worldfile.bnf for keyword checks.

In all, though, it does not sound a very healthy exercise. Patientently waiting for OR's own route editor still seems by far the best option.

Regards,
Rob Roeterdink

[eric from trainsim]

re: Spawners... If we have to leave the .W, RDB and RIT entries alone for the sake of the RE and general MSTS happiness, how about introducing a new OR-only fie which is read at the same time as the RIT, RDB, TIT, TDB?

Spawners are just one case I can think of where we'd want to extend interactive capabilities, but there may be others.

Routename.OIT    (OpenRails Interactive Table) 


CarSpawner (
		UiD ( 4747 )
		TrafficFile ( carspawn.dat )   <---- need a default for MSTS happiness...
	)
CarSpawner (
		UiD ( 4740 )
		TrafficFile ( carspawn-interstate.dat )   
	)
CarSpawner (
		UiD ( 4744 )
		TrafficFile ( carspawn-city )
	)

The existing tools and utilities shouldn't barf if the references are all external to the native file structures...