James Ross, on 20 November 2013 - 03:31 AM, said:
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)