[eric from trainsim]

New item for when the editor comes about.... being able to support more than one CarSpawner.dat

On a route which covers a lot of territory, it's a little aggravating to have to endure the same vehicles on the interstate, on rural backroads, and city streets. It would be helpful if there was a way to give an index to a specific set of vehicles, and reference that on the individual car spawners. That way, I can have my city buses, school buses, and soccer mom vehicles in the city, trucks on the interstate, and farm trucks & other things on the back roads.

[BenDragon1337]

Hi there, a friend came up with an idea, interactive industries, a functionality which would make ordinary rail vehicles loadable and industries process freight so that they can be picked up again and transferred to other industries within the map.

I don't expect it to be included until a 1.X release (AKA: not for a long, long while (something that my point out when it could be implemented would be when the OR team start designing their new editor as this feature does require a modification to it)), but here goes.

Interactive industries has not been a new idea in the simulation world (the earliest example would be trainz railway simulator 2004) and it basically includes a variety of features including:

• New waybill functionality (only views industries which require a certain amount of cargo, I will return to discuss this point later).
  
• New GUI, allowing users see the current level of product there is in both the production, consumption piles and how long it will take to empty.
  
• Added functionality of processing loads when a set of conditions are true.

Then came Railwork's interactive industries isn't really "eye-popping" to say the least.

Before I go in too deep into the subject, here's an underlying note: Since I prefer Open Rails for its multiplayer capabilities, my point of view will be highly tied to multiplayer's features for the best user experience.

Interactive Industries will adjust gameplay factor overall by a LOT, including multiplayer because of the features which are needed to support a successful endeavour including changing the UI.

Gameplay with be affected in the following ways:

• Users will be able to deliver physical loads to industries which require them.
  
• Existing content has to be altered and new content will have to be created in order to carry those loads.
  
• New User Interfaces (both in-game and dispatcher's view) would be created which would be capable of:
  
  • doing everything listed above, but with an additional feature of checking what industries supply which cargo
    
  • displaying information in a nice, consistent and easily accessible manor.
  
  
• Loads would have to be delivered from point A to point B
  
• Passengers could take shape on the platform, going to a random destination.
  
• Shunting could take place in map-based yards for cargo going to different destinations (users will have to interact with the dispatcher's view in order to find out where that cargo in a specific wagon can go to).

This could also be modified into the form which has custom cargos and industries placed on custom maps.

Speaking about the editor, it will have to be modified to suit this new game-play element.

If this goes ahead, this interactive industry feature will change the user's experience in explore mode dramatically due to how many GUI elements it will change to make it viable.

Because it will change so many elements about the simulation, it requires deep and careful thought about how they will be implemented, along with the various required gameplay elements.

I am not really going to show you my extended ideas list for this feature, since I believe it should be up to OR's team to discuss the implementation of it, if they decide to in the first place. :sign_rockon:

[markus_GE]

A good idea, actually liked it a lot in Trainz :sign_rockon: . Until, with Trainz 1008 the Feature was once broken, and I got acustomed to the MSTS way of not having it.

CHeers, Markus

[Genma Saotome]

Sprite text specific to the camera set, in this case Brakeman:



The data could be held as default values in the .wag file and overwritten in the Activity file(s) on a case by case basis as desired.

Key point tho is not all sprite text is relevant to all views, not all sprite behavior (e.g., every car) is relevant to all views.

[BenDragon1337]

Actually, marking it with car ID (MSTS comes equipped with the feature), load and total weight would be the only thing you'd need for car interaction.

As far as car configuration is concerned, there needs to be references to load within the .eng and .wag files like Genma Saotome suggests.

A couple of things I didn't like about trainz, was the fact it didn't list compatible loads in relation to the wagon during multilayer sessions, loads which could only be loaded into specific wagons (liquid, solid and bulk wagons), statistics should be able to be displayed in-game when the user requires it when selecting wagons for a consist.

The other thing I didn't like about it would be the multiplayer wouldn't really supply any information about industries which supply a certain load.

Edit: I feel that in the screenshot, red text is the most visible against most colours for some reason, maybe painting the text red would make it stand out a bit more.

 markus_GE, on 19 November 2013 - 06:56 AM, said:

A good idea, actually liked it a lot in Trainz :sign_rockon: . Until, with Trainz 1008 the Feature was once broken, and I got acustomed to the MSTS way of not having it.

CHeers, Markus

Yeah, I feel if it was developed enough and changed a lot for MSTS's capabilities, it could prove to be rather interesting.

One thing I'd like in OR would be MP would be conflicting car IDs, in which case OR would assign a random ID to the newer vehicle (weird stuff happens to vehicles with the same ID are within the same consist).

[Genma Saotome]

 BenDragon1337, on 19 November 2013 - 10:50 AM, said:

Actually, marking it with car ID (MSTS comes equipped with the feature), load and total weight would be the only thing you'd need for car interaction.

I disagree... but I don't have the time to hash it out right now. I do think a half-way decent Use Case would be a worthwhile endeavor: What does the conductor need to see and when? What does the brakeman need to see and when? The engineer? The activity builder (no reason why non-players should be ignored)? It is my opinion that each role has a need for its own set of cameras along with a thin gui display of appropriate commands. If we can say Camera Set A is assigned to the Conductor we should also be able to say Command List 4 is assigned to the Conductor and Sprite Definitions 7a, 7b, and 13f are also assigned to the conductor (or perhaps the conductors cameras)... repeat exercise for other roles. Naturally one role would have to be Same-as-MSTS and a different role would have to be "Superman" that can do everything.

What's behind this thinking is my opinion that there are not enough key combinations to cover everything that should be shown, nor are most users going to be able to remember them even if there was... so reserve 1-9 for camera selection but create sets of cameras so camera 2 for an Engineer is a tracking camera, looking from ahead of the locomotives, right side, looking towards the rear, but camera 4 is a different tracking camera, looking from behind the locomotives, right side, looking towards the front... and the same camera numbers for the Conductor camera set are identical except they're tied to the Caboose, and for the brakeman perhaps they're non-tracking and positioned close to the cars, representing his view as he walks the train but once again numbers 2 and 4 are on the right side, with two looking to the rear and 4 looking to the front.

With patterns like that the player will know certain camera numbers behave pretty much the same way no matter what role you are in... but you can use different roles to position the cameras in different places.

Get there... and then think about what commands are most commonly used and put them into a very thin gui (so as not to take up too much screen space... and what Sprite text makes sense. What is it now, f7 that shows sprite text? Continue to use that key but by assigning certain sprites to specific roles (or cameras for a role) everybody knows f7 gives you sprites but what you see varies by what role you are in.

[markus_GE]

What about selecting roles by making them, e.g. Shift + (Number key here) commands? Would make all cameras avalable to all rolesets...

Cheers, Markus

[BenDragon1337]

 Genma Saotome, on 19 November 2013 - 11:25 AM, said:

I disagree... but I don't have the time to hash it out right now. I do think a half-way decent Use Case would be a worthwhile endeavor: What does the conductor need to see and when? What does the brakeman need to see and when? The engineer? The activity builder (no reason why non-players should be ignored)? It is my opinion that each role has a need for its own set of cameras along with a thin gui display of appropriate commands. If we can say Camera Set A is assigned to the Conductor we should also be able to say Command List 4 is assigned to the Conductor and Sprite Definitions 7a, 7b, and 13f are also assigned to the conductor (or perhaps the conductors cameras)... repeat exercise for other roles. Naturally one role would have to be Same-as-MSTS and a different role would have to be "Superman" that can do everything.

What's behind this thinking is my opinion that there are not enough key combinations to cover everything that should be shown, nor are most users going to be able to remember them even if there was... so reserve 1-9 for camera selection but create sets of cameras so camera 2 for an Engineer is a tracking camera, looking from ahead of the locomotives, right side, looking towards the rear, but camera 4 is a different tracking camera, looking from behind the locomotives, right side, looking towards the front... and the same camera numbers for the Conductor camera set are identical except they're tied to the Caboose, and for the brakeman perhaps they're non-tracking and positioned close to the cars, representing his view as he walks the train but once again numbers 2 and 4 are on the right side, with two looking to the rear and 4 looking to the front.

With patterns like that the player will know certain camera numbers behave pretty much the same way no matter what role you are in... but you can use different roles to position the cameras in different places.

Get there... and then think about what commands are most commonly used and put them into a very thin gui (so as not to take up too much screen space... and what Sprite text makes sense. What is it now, f7 that shows sprite text? Continue to use that key but by assigning certain sprites to specific roles (or cameras for a role) everybody knows f7 gives you sprites but what you see varies by what role you are in.

I disagree, the labels and the camera views should be left separate, usually what you find in OR (at least, our group on multi player) would be that we'd all pick a train with a consist attached, choose a route and plan it out (via dispatcher's assist) then proceed along the route until the destination.

There just simply isn't enough players normally on a server on OR to assume such a proposition since everyone would have their own train with their own worries to worry about (users just simply merge all of the roles into the train driver's job, leaving them to select the route, what cargo to pick up and set down at each location).

The idea is nice, but I'm afraid you tend to need to know all of the information that you need to know to be able to create a custom schedule that you need to keep to while doing your custom job.

(Something like notepad in OR could be helpful at taking notes during game play to keep track of your custom schedule).

[R H Steele]

This is for the future when work gets around to the Activity Editor. With the current MSTS Act Ed. you have to name consists twice even though they end up as loose consists with no name in the activity file. (if this is not accurate please correct). How about a loose consist selection where no name is required or is an option? Populating routes with loose consists is going to be very popular with Open Rails because it can handle more objects and the activity looks very realistic with them. They should be easy the place and manipulate. Also an option to remove all loose consists (creating and saving a backup act file of course) would be nice, just to run the activity quickly without having to find all the correct rolling stock or sub some stuff in. Just a thought for the future. Cheers rhs (aka gerry) :sign_rockon: {I'm getting used to this clown)

[BenDragon1337]

In reply to my last post (I was pretty tiard when I wrote it), I propose we filter the extra commands to display the extra required info onto the shift + function buttons (shift + F1, Shift + F2, Shift + F3), only problem is when you get to the alt + function buttons, when you get to alt + F4, which is a windows shortcut.