[Genma Saotome]

 James Ross, on 20 November 2013 - 03:31 AM, said:

I would really like it if, when you do have time, you could try and pin down some of the specifics here in a new thread. What is the full list of roles you envisage? Which cameras would be specific to a role?

The reason I ask is that, whenever I think about how we could do it, I don't see the roles that you mention. There's certainly a few different "modes" of play I've seen - passenger, freight, shunting come to mind - but not conductor, brakeman, etc., so I'd like to know where exactly you're coming from.

Ok. This is 98% for the programming team.

I'm going to assume that there is an app that sits on top of this data with Add, CopyFrom, Edit, and Delete functions. This should allow for those rows distributed by the OR Team to be non-editable but remain available be copied and edited by the player (like a template) when he is creating his own; also some data is internal to the program. If this assumption is not correct then everything can be handled with an ordinary text editor and what's shown below can be simplified to some degree.

I am also assuming this specification is applied at the route level. I've made provision for the OR team to provide and manage non-editable "template" data which should be understood as global to the installation. Each route definition should begin with the OR standard and should either route designer or player want something different it can be done on a case by case basis w/o harm tot he defaults.

NOTES to programmers:

• I'm assuming the programers have the final say on the physical object definition so what follows is a Logical proposal; In some cases I've normalized the data, in others I have not, depending on how important I thought it was to point out the issue. The exception is subtype data in Cameras... I kept it simple/physical rather than get bogged down by specifying to which subtype the data belonged.
  
• In many cases fields ending in the string "Id" are being used as a foreign key. I've added "FK" to signify those.
  
• Topic of Keyboards and Keys is included as an attempt to simplify presentation of the ideas around assigning keystrokes to commands so I get to use standardized foreign keys when I am discussion assigning individual commands to roles. It's probably not needed by you guys but I needed to think it thru. It is not intended to suggest replacing anything extant in the code if what's there will work just as well.

Notes to Players:

• I expect much of this complexity will be hidden from players but to describe it fully to the programmers I needed to do this at their level of detail, not yours.
  
• In many cases things you would think of as one list are shown here as two: The first part identifies the list and who created it; The second part is the full list of items. For example, to describe a camera set I use CameraSet for descriptive purposes, including who created the set, and then a second block of data CameraSetList that is the actual list of cameras in the set. Programmers need to see it as two things... what gets presented to you would likely be the combination of the two.

Role
To be understood by players as an ordinary list of names, such as "Fireman", to which they can assign sets of cameras and sets of commands. Roles need not be limited to describing a specific individual... defining a role for "MSTS" to match the original MSTS cameras is expected; other abstract roles like "Train Passengers" should be allowed too.

• RoleId << serialized unique identifier, most likely an integer sequence, 1 to n >>
  
• RoleName << editable string used for display purposes, such as "Conductor", "Remote Fireman" >>
  
• RoleType << any sensible categorization, such as "Crew Roles"; might not be needed >>
  
• RoleDelegation << binary to determine if role can be delegated in multiplayer; useful only if used to control authorized commands >>
  
• RoleAuthor << a string to record who created the role; "OpenRails" will be used for all role definitions distributed with the software and those rows are not editable by players >>
  
• RoleEditing << a binary indicating whether the data on this line is editable by the player >>

For example:

• Engineer/Driver, train crew
  
• Fireman, train crew
  
• FrontEndBrakeman, train crew
  
• RearBrakeman, train crew
  
• Conductor, train crew
  
• Towerman, command & control crew
  
• YardClerk, yard crew
  
• Hostler, yard crew
  
• Dispatcher, command & control crew
  
• TrainPassenger, member of the public
  
• Railfan, member of the public
  
• MSTS Compatiblity, abstract.
  
• ModelRailroader, abstract (e.g., all high, looking down angles sikilar to what one sees while operating a model railroad)
  
• Helicopter, abstract (e.g., very high )
  
• Remote<<whatever>> remote Multi-player (i.e., when multiple persons are playing roles on the same train and the cameras and/or command sets are different than what the player might give himself)

Camera
To be understood by players as similar / identical to the purpose of the MSTS Camfig file. Specific details and organization for OR may be different as needed.

• CameraId << serialized unique identifier, most likely an integer sequence, 1 to n >>
  
• CameraType << any sensible categorization, such as tracking, that may include date specific to the subtype >>
  
• CameraFOV << per standard FOV definition, most often a constant but inclusion here allows for special situations to be defined >>
  
• CameraZClip << per standard ZClip definition, most often a constant but inclusion here allows for special situations to be defined >>
  
• CameraAuthor << a string to record who created the camera; "OpenRails" will be used for all camera definitions distributed with the software and while those rows are not editable by players they may be copied as a template when the player is creating his own>>
  
• CameraEditing << a binary indicating whether the data on this line is editable by the player >>

---- Begin Subtype data ----

• CameraOffsetInitialXYZ << standard XYZ data to define initial distance from attachment Point >>
  
• CameraOffsetAttachmentTargetType << indicates what the camera is attached to (e.g., ground, player train, ai train, etc.) >>
  
• CameraOffsetInitialTrainId <<indicates which train the camera offset applies to (e.g., Player, AI #nnn, etc.)
  
• CameraOffsetAttachmentInitialTargetId << indicates the initial specific object in the train to attach to >>
  
• CameraOffsetLastTrainId <<indicates the last train the camera offset applied to (e.g., Player, AI #nnn, etc.)
  
• CameraOffsetLastAttachment << indicates what object in the train the camera was last attached to; Program use only >>
  
• CameraOffsetLastXYZ << standard XYZ data to define most recent distance from attached object >>
  
• CameraOffsetReturnType << indicates which CameraOffsetXYZ to use when returning to this camera >>
  
• CameraOffsetInitialPitch << 0 to +90 or 0 to -90 where 0 = Horizontal, positive menas up, negative means down; Applicable only when CameraOffsetAttachmentTarget = Ground.
  
• CameraOffsetInitialRotation << 0 to +90 or 0 to -90 where 0 = Center, positive means right, negative means left; Applicable only when CameraOffsetAttachmentTarget = Ground.
  
• CameraOffsetMinDistance << real number, in meters, limiting how close to the target object the camera may move >>
  
• CameraOffsetMinDistance << real number, in meters, limiting how far from the target object the camera may move >>
  
• CameraOffsetRiseType << indicates if the camera rise/fall is on a straight line or arc >>
  
• CameraOffsetMinRise << real number, in meters, values 0 to n, limiting the extent the camera may be lowered on a straight line from its original position. >>
  
• CameraOffsetMaxRise << real number, in meters, values 0 to -n, limiting the extent the camera may be raised on a straight line from its original position. >>
  
• CameraOffsetMinRoll << real number, in degrees, values 0 to n, limiting the extent the camera may be rolled up on an arc from its original position. >>
  
• CameraOffsetMaxRoll << real number, in degrees, values 0 to -n, limiting the extent the camera may be rolled down on an arc from its original position. >>
  
• CameraMaxPitchUp << integer, in degrees, values 0 to +360. Used to limit the extent of upwards pitch of the camera on its own axis from its original position.>>
  
• CameraMaxPitchDown << integer, in degrees, values 0 to -360. Used to limit the extent of downwards pitch of the camera on its own axis from its original position. >>
  
• CameraMaxRotateRight << integer, in degrees, values 0 to +360. Used to limit the extent of rotation to the right of the camera on its own axis from its original position. >>
  
• CameraMaxRotateLeft << integer, in degrees, values 0 to -360. Used to limit the extent of rotation to the left of the camera on its own axis from its original position. >>
  
• Possibly more....

CameraSet Object -- two lists.

CameraSet
To be understood by the player as a collection of cameras to be used for a specific purpose. Some of these will be defined by Open Rails, others by the player.

• CameraSetId << serialized unique identifier, most likely an integer sequence, 1 to n >>
  
• CameraSetName << A string used to name the camera set for display purposes; May not be needed >>
  
• CameraSetAuthor << a string to record who created the camera set; "OpenRails" will be used for all camera definitions distributed with the software and while those rows are not editable by players they may be copied as a template when the player is creating his own>>
  
• CameraSetEditing << a binary indicating whether the data in this set is editable by the player >>

CameraSetList
To be understood as the list of cameras that belong to the camera set.

• CameraSetId (FK) << serialized unique identifier, most likely an integer sequence, 1 to n; Managed by the program. >>
  
• CameraID (FK) << the unique identifier of a camera assigned to this set >>
  
• CameraSetListKey << the keystroke assigned to this camera in this set (e.g., 1-8 ).

CameraSetRoleAssignment
To be understood as a list of CameraSets made available to a role. Most often an assignment of 1 set of cameras per role is enough but this approach will allow multiple sets to be assigned.

• RoleId (FK) << serialized unique identifier, most likely an integer sequence, 1 to n; Tells us which role this list is for >>
  
• CameraSetId (FK) << serialized unique identifier, most likely an integer sequence, 1 to n; Tells us which Camera Sets are assigned here >>
  
• CameraSetRoleAssignmentAuthor << a string to record who created the CameraSetRoleAssignment; "OpenRails" will be used for all camera definitions distributed with the software and while those rows are not editable by players they may be copied as a template when the player is creating his own>>
  
• CameraSetRoleEditing << a binary indicating whether the data in this set is editable by the player >>

KeyStroke
For program use only. To be understood as a list of default keystrokes used by OR within the program as-if everyone was using the same keyboard.

• KeyStrokeORString << Unique Identifier. The string used as a mnemonic in the OR program to signify the identity of a keystroke >>
  
• KeyStrokeCode << the value issued by the actual keyboard in use when a keycap is pressed >>

NationalKeyBoard
For program use only. Maps n number of national keyboards to the mnemonic used within the OR program. The idea here is this list will provide the actual keystroke code sent by the keyboard in use as identified by the mnemonic used by the program. >>

• KeyStrokeORString ( FK ) << The string used as a mnemonic in the OR program to signify the identity of a keystroke >>
  
• NationalKeyStrokeString << Unique. The string used as a mnemonic in the OR program to signify the identity of a keystroke >>
  
• NationalKeyStrokeCode << the value issued by the actual keyboard in use when a keycap is pressed >>

Command
For program use only. To be understood as the list of commands issued by the player that are used by Open Rails.

• CommandId << serialized unique identifier, most likely an integer sequence, 1 to n >>
  
• CommandName << a string used to describe the command (e.g., increase throttle). >>

CommandKeys
For program use only. To be understood as an ordered list of keystrokes that in combination invoke a command.

• CommandId ( FK ) << serialized unique identifier, most likely an integer sequence, 1 to n >>
  
• CommandKeySequence << Integer, 1 to n. The order of the keystrokes.
  
• KeyStrokeORString ( FK ) << the standard keystroke used by the OR program >>

RoleCommand Object -- two lists.

RoleCommand
To be understood by player as a list of commands that are always available to a specific role.

• RoleCommandId << serialized unique identifier, most likely an integer sequence, 1 to n; >>
  
• RoleCommandAuthor << a string to record who created the RoleCommand list; "OpenRails" will be used for all camera definitions distributed with the software and while those rows are not editable by players they may be copied as a template when the player is creating his own>>
  
• RoleCommandEditing << a binary indicating whether the data in this set is editable by the player >>

RoleCommandList
This should be understood as the actual list of commands assigned tot he role.

• RoleCommandId
  
• RoleId (FK) << serialized unique identifier, most likely an integer sequence, 1 to n; Tells us which role this list is for >>
  
• CommandId ( FK )<< serialized unique identifier, most likely an integer sequence, 1 to n; Tells us which commands are available to this role. >>
  
• RoleCommandUse << Defines whether the command is always available or only in limited circumstances >>
  
• RoleCommandGui << Defines whether the command can appear in a GUI or is limited to keyboard use >>

RoleCommandCameraSet
This might be "a specification too far" as they say but it meant to create discussion as to whether certain gui commands are shown only in certain camera sets.

• RoleCommandId ( FK )
  
• CameraSetId (FK)

[Genma Saotome]

Quote

This is from a PM several months ago

In all of the attached images, below, I deliberately used letters instead of numbers to identify each camera. I did so because I felt any decision on which numbers to assign to which cameras deserved careful thought to consistent patterns and I didn't want to get into that.

Pretty much the same purpose as the existing camera 1. What is different is the head out views can be assigned to a camera number instead of misc. keystrokes & keystroke combinations:



Probable variant:



Here are two examples of how the cab cameras might vary based on roles -- Engineer vs. Fireman (I used right and left sides rather than Engineer and Fireman on the belief that who sits on which side is not the same world-wide):





We have two tracking cameras, numbers 2 and 3. By introducing camera sets we provide up to 10 views and altitudes per camera set. This would allow for an almost unlimited number of tracking positions and angles:



Here is a generic replacement set our current camera number 5:



With the consideration of roles we create two different sets... perhaps assigned to different persons in multiplayer:









One concept I'm particularly keen on is the walking brakeman and his camera set:












I overlooked a few ideas when composing the basenote:

• CameraMovementSpeed() and CameraMovementSpeedMultiplier()as a column to define the standard rate of movement and very fast movement on either a Camera by Camera basis or cameraSet basis.

And have not fully fleshed out the walking brakeman data requirements.

[Buttercup]

Engine cab cameras: add rear through the window views in "Cab Cameras - no role" etc.

[Genma Saotome]

 Buttercup, on 23 November 2013 - 05:06 AM, said:

Engine cab cameras: add rear through the window views in "Cab Cameras - no role" etc.

Yeah, there are some details that need correcting. Your comments are correct for some locomotives, my example for others.

Here is an example of two camera sets, CAB01 for early EMD Road units (e.g., F-7) and CAB02 for many North American Switchers:



The example corresponds to the first two images in post #2 and represents camera sets for everyone in the locomotive crew. That makes it fairly likely to match what most players will want.

As you can see, CAB01 gives 6 different cameras to the player, using keys 2-7. There's no need for other keystrokes or combinations of key strokes to move between inside and outside: Just hit the camera number. For the second example there are 8 Cameras. As you can see some camera definitions are found in both CACAB01 and CAB02 sets.

[Genma Saotome]

Second example, this time creating sets of cameras that would be specific to a locomotive engineer and a fireman:



If you compare these to images 3 and 4 in post #2 you'll see the arraignment.

=======================

Not yet shown is assigning camera sets to roles (I'll get to that a little later in the day).

[Buttercup]

You might only need one outside cab camera on each side if it can be rotated front to back.

[Genma Saotome]

 Buttercup, on 23 November 2013 - 04:54 PM, said:

You might only need one outside cab camera on each side if it can be rotated front to back.

True. OTOH we could also define cameras pointing in both directions so you can start looking one way or the other... and then rotate as you want. One outside camera... or two. It works either way.

==================

Next example... how we could assign player commands to certain roles:


So here we've already got two roles defined -- Engineer and Fireman. What follows is a partial list of game commands (I've only listed a few to keep it short). Last, two sets of commands assigned to roles... in this case the first set, RC051, will be assigned to the Engineer Role. The second set, RC077, will be assigned to the Fireman Role.

As you can see by this a bunch of commands are assigned to the Engineer role and only two assigned to the Fireman (turn wipers on and off). That could make sense for a Fireman in a Diesel Locomotive but certainly not for one in a steam locomotive. That simple fact argues for changing the original name given to role 2 -- Locomotive Fireman, to Diesel Locomotive Fireman and then continuing on, creating another Role: Steam Locomotive Fireman. That role might use the same cameras as does the Diesel Locomotive Fireman role but his command list would be radically different.

That's not meant to be the definitive list for these two roles, juts an example of how we might do this kind of assignment.

[captain_bazza]

How on earth will we find enough key-combos for all those cam-views? :ph34r: :cool3: I really like the brake~man~cam idea. :D

Cheers Bazza

[Genma Saotome]

 captain_bazza, on 23 November 2013 - 06:53 PM, said:

How on earth will we find enough key-combos for all those cam-views? :ph34r: :book2: I really like the brake~man~cam idea. :lol2:

Cheers Bazza

You cannot without grouping them into some sort of set -- collection if you will -- first. Once you do that then you can re-use the keystrokes.

Take the tracking cameras -- picture 5 in post #2. Three sets; All have ten cameras, which I've marked as A thru J. What makes the sets different is the altitude at which the camera is created. Railfan Set is ground level; Model Railroader is medium high, maybe 30m - 40m above the train, and Helicopter is very high, maybe 100+m above the train. That's gives 30 different camera definitions, obviously far too many for unique keys. But once you put those cameras into the three sets you can reuse the keys: Press the key for camera 3 and in the Railfan Set you get a tracking camera that starts down low behind the rear of the train, looking forward (see Camera C in that picture I mentioned). Change to the Helicopter set and press the same key as you did before and you have the same general position but now you are 100m higher. Same key, different location and it works because we've got different sets.

Clear?

[Buttercup]

You could have a couple of "empty" camera sets that could be used by the end user to build customized sets.