[ErickC]

Csantucci, on 07 October 2017 - 10:54 AM, said:

Saying "diesel reefer" is not enough. You should also specify at least the railway era and the country. It's not so easy.

I was thinking that, too, yes. I was also thinking that, if we had such a system, you wouldn't necessarily need to download specific pieces of rolling stock to run most activities, so long as the sim eventually came with its own basic set of content. Adding more rolling stock would increase the variety available.

The section could look a bit like this, maybe:

ORTSCarClass ( 	Type 		(reefer_mechanical)
				Country		(USA)
				Date_min	( 1950 )
				Date_max	( 1990 )
			)

The activity designer would then specify the type of car, the country (we don't need a list here, as one might think, since the randomizer could just look for cars with a "Country" line that matches), the maximum length of the car, and the year. Cars falling within those parameters could then be loaded.

There could be a similar system for locomotives, I think. If we came up with a set of basic rolling stock standards* to make stock more or less compatible, it could make for some interesting results depending on the user's installed content.

*I don't think this is too far-fetched, since things like coupler height and whatnot got to be fairly consistent near the twilight of MSTS. As model resolution improved, there seemed to be a bit of convergent evolution here. I remember coupling my GP10 to the 3DTrains SP GP9 demo, and my Hilevels to the SLI Superliners. Everything seemed to mesh together really well.

[cjakeman]

Genma Saotome, on 04 October 2017 - 09:10 PM, said:

Seeing as you've taken the plunge and done something to replace KUKU's AE, please check w/ Chris on the OR team to see if he still has a list of ideas that was compiled several years ago -- all sorts of ideas for new features.

You have a terrific memory, Dave.

Back in 2011, adding the activity events from MSTS that were missing/incorrect was one of the first code changes I made. I couldn't have done it without help from Eric Swenson in building and testing them.

Here are my notes from 2013, in which I tried to capture lots of useful comments from the forums on this subject. Rob Roeterdink also sent me ideas, most of which ended up in his Timetable feature.

 Notes on an Activity Editor.pdf (606.99K)
Number of downloads: 272

[Genma Saotome]

cjakeman, on 09 October 2017 - 10:58 AM, said:

You have a terrific memory, Dave.

I wish a good portion of it hadn't dulled a bit w./ age.

Anyhow, here's one more idea for the list: It has always bothered me that switching operations ore so tightly scripted -- do this task first, go here, uncouple, backup, go there, stop, pick your nose, spit, go somewhere else... rather totalitarian. It seems to me it would be much more relatistic for the player and easier for the activity designer for the events to be result oriented instead of task specific. Something like this:

Switching Event
- Sub Event: Spot (specific ID recorded by Activity Designer) car at Appleby's spur
- Sub Event: Spot (multiple ID recorded by Activity Designer) cars at Grain Silo spur
- Sub Event: Pick up (specific ID recorded by Activity Designer) car from House Track.
- Sub Event: Move (multiple ID recorded by Activity Designer) cars from Miller's Coal Yard to Yard Track 4.
End Switching Event

Where the main event occurs between two turnouts (identified in the activity) between which any and all throwing of switches are not passed tot he signalling system.
Where the main event isn't completed until all of the sub events are done.
Where the sequence and specific movements of doing the sub events is determined by the end user.
Where certain words become reserved words, verb phrases like Spot (or drop), pickup, move, maybe a few others, that are essentially Activity events.

[Lindsayts]

Genma Saotome, on 09 October 2017 - 03:08 PM, said:

I wish a good portion of it hadn't dulled a bit w./ age.

Anyhow, here's one more idea for the list: It has always bothered me that switching operations ore so tightly scripted -- do this task first, go here, uncouple, backup, go there, stop, pick your nose, spit, go somewhere else... rather totalitarian. It seems to me it would be much more relatistic for the player and easier for the activity designer for the events to be result oriented instead of task specific.

Sorry for being late into the discusion.....................

Anyway I assume you are talking about shunting activities in MSTS............
Then reason it so so tightly specified (in MSTS) is there is little to no shunting intelligence in MSTS so it requires a very tightly specified activity. The more indefinite the instructions are the more intelligence is needed in the simulator to handle it. I believe OR has a decent amount of intelligence in its shunting, if this is the case all that is need is a standard way of specifing what to do in the new activity files.

Quote

Something like this:

Switching Event
- Sub Event: Spot (specific ID recorded by Activity Designer) car at Appleby's spur
- Sub Event: Spot (multiple ID recorded by Activity Designer) cars at Grain Silo spur
- Sub Event: Pick up (specific ID recorded by Activity Designer) car from House Track.
- Sub Event: Move (multiple ID recorded by Activity Designer) cars from Miller's Coal Yard to Yard Track 4.
End Switching Event

Where the main event occurs between two turnouts (identified in the activity) between which any and all throwing of switches are not passed tot he signalling system.
Where the main event isn't completed until all of the sub events are done.
Where the sequence and specific movements of doing the sub events is determined by the end user.
Where certain words become reserved words, verb phrases like Spot (or drop), pickup, move, maybe a few others, that are essentially Activity events.

Lindsay

[Genma Saotome]

Lindsayts, on 10 October 2017 - 01:20 AM, said:

Sorry for being late into the discusion.....................

Anyway I assume you are talking about shunting activities in MSTS............
Then reason it so so tightly specified (in MSTS) is there is little to no shunting intelligence in MSTS so it requires a very tightly specified activity. The more indefinite the instructions are the more intelligence is needed in the simulator to handle it. I believe OR has a decent amount of intelligence in its shunting, if this is the case all that is need is a standard way of specifing what to do in the new activity files.

Lindsay

Lindsay, I do not understand your point at all (I've only started my second cup of coffee this morning so I guess I'm still a bit dull in the head). I do not understand why, in OR, there is any need for such uber=controlling scripting to be used. If the script says put this car over there, where both "this car" and "over there" are known to the software, why is there a need to lay out the path? Why is the position in the serial order of this task required?

The objective needs to be revealed but IMO how you go about and one task, or the set of tasks, should be entirely chosen by the end user.

So what am I missing here?

[ebnertra000]

I was thinking the same thing, Dave. If the car and where it needs to go are both known to the software, then does it really matter when or how said car gets to it's destination? If this method is used, the activity shouldn't be all that difficult for the software to figure out, and it would be considered complete when the last car reaces its destination track

[cjakeman]

ebnertra000, on 10 October 2017 - 11:00 AM, said:

I was thinking the same thing, Dave. If the car and where it needs to go are both known to the software, then does it really matter when or how said car gets to it's destination? If this method is used, the activity shouldn't be all that difficult for the software to figure out, and it would be considered complete when the last car reaces its destination track

This ties in with one of the ideas in that old document I posted.

It should be possible to record an activity by driving the loco and taking a series of snapshots. Similar to taking a screendump but the simulator prompts you to confirm which of the elements are required - which might be this wagon in that siding and those wagons coupled in a consist or this train in that platform by this time.

[Genma Saotome]

I think I can properly phrase my "issue" about this stuff: Both OR or any route editor need to do:

• Defining an interlocking with its rules (e.g., no stopping, no backing up)
  
• Defining a temporary work zone to signal "do not enter" to the signalling system. This would often be some fixed distance beyond where the train is doing its work, generating either a full red stop at the appropriate signal head or the more useful proceed be prepared to stop at temporary point X where point X is specified by the Activity AND generates an aspect with the correct indication in the f4 window.
  
• Defining right by direction and class in the signalling system as the default means to resolve any movement conflicts, leaving the Activity itself to represent dispatcher changes.

[roeter]

I don't want to be a spoil-sport, but when working on the 'new' signal code some years ago I also tried to include a 'shunt state' which would lock an area off for other moves and allow the train free movement withing the area.
I found it was so complicated to define the actual area, set up the rules and properly release the area again that the idea was abandoned.
It's all very complicated, in particular keeping the path for the train out of the area clear of other trains and so avoid deadlocks.
Such logic probably would require more and more complex definitions of the area to lock off etc. than it would take to define an actual path.

Regards,
Rob Roeterdink

[Lindsayts]

Genma Saotome, on 10 October 2017 - 10:16 AM, said:

Lindsay, I do not understand your point at all (I've only started my second cup of coffee this morning so I guess I'm still a bit dull in the head). I do not understand why, in OR, there is any need for such uber=controlling scripting to be used. If the script says put this car over there, where both "this car" and "over there" are known to the software, why is there a need to lay out the path? Why is the position in the serial order of this task required?

I probably could have put it clearer... The reason why the "uber=controlling" script exists is because in MSTS there is NO shunting inteligence so one needs to specfiy everything, hence the high detail. If you wish to be able to specify "put the 3rd wagon into track 3", the program will need plenty of intelligence to be able to do that.

Quote

The objective needs to be revealed but IMO how you go about and one task, or the set of tasks, should be entirely chosen by the end user.

So what am I missing here?