[James Ross]

Genma Saotome, on 01 June 2014 - 09:26 AM, said:

I've forgotten what Kuju called Camera 4. Whatever it was called I can see 10 positions per set and like tracking, 3 sets based on altitude.

The quick-reference card lists the cameras as:

• Front Cab view
  
• External view 1 (front)
  
• External view 2 (rear)
  
• Trackside view
  
• Passenger view
  
• Coupler view
  
• Yard view

[Genma Saotome]

James Ross, on 01 June 2014 - 09:50 AM, said:

...I am of the opinion that per-route camera sets have very limited value, so would suggest we do global camera sets first, let people have a play, and then we can add per-route camera sets if it seems generally useful.

I know I would use them on two routes: Goose Island and the Alameda Belt Line. Both are urban switching layouts with street running and both would be better viewed with initial camera positions closer to their target having limited vertical climb available. I suspect the WP 3rd sub might benefit from a custom set too... the canyon walls being right up against the ROW you'd probably want to customize the tracking cameras the tracking CameraSets to create left and right side versions rather than leave them as both sides and on a change follow the default setting into the side of the mountain.

James Ross, on 01 June 2014 - 09:50 AM, said:

The problem is updates. Unlike with MSTS, you don't install OR and never expect any updates to the game engine. Quite the opposite, in fact. That's a problem when people go editing things that are not specifically intended to be edited. I do not think Kuju intended many of the files that people edited in MSTS to be edited by anyone except them. There are very complex issues trying to deal with files edited by two parties. For that reason, I consider anything inside the Open Rails directory except OpenRails.ini (when in use) to be completely off-limits for most people. You can edit lots of other bits but the updater has no chance of keeping them from version-to-version, so your changes will always be wiped out.

Understood now but not in mind when I first wrote up the idea. Given that player-created Camfig and CameraSet files are likely to be passed around (rather than to expect each person fiddles on their own and that's all) the issue boils down to this: Should the recipient of one of those files delete his current file and replace it with the one he downloaded, ensuring the file name is correct... open his current file and append the rows he downloaded (which will present a problem for retaining valid UI's)... or give the downloaded file(s) a unique name and point to them when he wants to? Whichever seems best at first, what to do when he finds some subset of a distributed file that he'd like to merge into his already well thought out, well worked over set in use? It seems there will be no escaping a desire to append and with that all sorts of potential problems keeping the UI's of each line correct and matching between Camfig and CameraSet lines. Anyway, at this moment in time I am not sure which might be a better solution. Do you have an opinion?

James Ross, on 01 June 2014 - 09:50 AM, said:

What we could do, is this:

• If there are user-defined camera sets, use them.
  
• Otherwise, use the OR "stock" camera sets.

Then anyone can take a copy of the stock ones and edit them - but they mustn't edit them in place in OR.

I think that would be a reasonable solution.

[James Ross]

Genma Saotome, on 01 June 2014 - 08:44 PM, said:

Understood now but not in mind when I first wrote up the idea. Given that player-created Camfig and CameraSet files are likely to be passed around (rather than to expect each person fiddles on their own and that's all) the issue boils down to this: Should the recipient of one of those files delete his current file and replace it with the one he downloaded, ensuring the file name is correct... open his current file and append the rows he downloaded (which will present a problem for retaining valid UI's)... or give the downloaded file(s) a unique name and point to them when he wants to? Whichever seems best at first, what to do when he finds some subset of a distributed file that he'd like to merge into his already well thought out, well worked over set in use? It seems there will be no escaping a desire to append and with that all sorts of potential problems keeping the UI's of each line correct and matching between Camfig and CameraSet lines. Anyway, at this moment in time I am not sure which might be a better solution. Do you have an opinion?

I can see a variety of ways we could manage this... one option would be:

• Available camera sets = sorted list of camera set files.
  
• Available cameras = list of individual camera files.
  
• Each camera set file contains references to each camera's file name.

This would allow distributing a "set of cameras" (i.e. camera set and needed camera configurations) as just a collection of files (1 for the set, N for the cameras). If people named them reasonably, e.g. put their nick/initials at the start, it'll be something anyone can just "drop in".

Most other arrangements I can think of involve either the cameras or camera sets being combined into single files, which means manual copy-pasting and editing and potential syntax screw-ups, so I would lean towards the above many-file approach. I don't have that strong an opinion on it, though, as we could make an import/export function in OR that handles all the syntax editing stuff.

[Genma Saotome]

As I think more about this the issue of managing the Unique Identifier (UI) in the Camfig file (and it's "foreign key" value over in the CameraSet file) becomes more and more a concern. If the UI is an integer value then it's no big deal to tell people working on their own files to just look to the end of your own file and use the next available integer for whatever you add. but when distribution comes into play. Will that be enough for dealing with distributed rows? The recipient will have to manually change the UI of the new Camfig rows "per the rules" and then must also update all references to those cameras as he appends the rows from the distributed CameraSet file. Not difficult but errors could easily be introduced.

So that makes me think that in the ideal there would be an application that would append the distributed rows to both an "official" Camfig and CameraSet file, thereby ensuring the UI of each added camera row is assigned by the app, not the user (e.g., a serial number). The app would also update the camera's foreign key value in the imported CameraSet file as well as the UI of the new CameraSet(s). This will ensure all keys are always unique on each persons installation w/o regard to key values in use in other installations. Having done the append / key update for the user he then would select which camera sets he wanted to use (perhaps by marking specific sets, perhaps by marking and exporting the rows of selected sets). Ideally he could also edit the camera assignments to selected CameraSets... perhaps even edit values of the Cameras themselves. IOW the APP ensures all of the camera related data is correct, providing for imports and exports. Based on his selection decision the correct Camfig data would always be used. That would give these two reference files to RunActivity to get the data... or if it makes more sense to export the selected CameraSet rows (for route by route or globally) then RunActivity looks for that file instead. Either way the file names are standardized and rows are going to hold correct values and keys. But the ideal seems like it could be a lot of work. Thoughts on that?

Change the solution by asking each person to add their initials (3 of them) plus 2 or 3 randomly selected keystrokes (an attempt to ensure uniqueness beyond initials) would give a reasonable chance at the distributed filenames being unique but what that produces is many files to choose from and does nothing to provide for those situations where some subset of a distributed file is wanted as an addition or replacement to one's own preferred files.

And so with consideration of the above thoughts I am now inclined to suggest appending distributed rows to official files. Whether it is better to assume people can be counted on to manually do the append and UI updates or to build and distribute a simple APP that automates that step remains an open question. The later does mean more work now but I think over time it would eliminate all sorts of headaches for both end user and OR programming team.

[markus_GE]

The App youre tlaking about, dave, would not be a real problem. At least for adding to a file from another one and updating things (serial numbers) I already have the basic program structure for a similar task ready (DPU). Adapting it a little to fir the new task, I would perfectly be able to create a drag-and-drop-controlled "adder" to the global file.

GUI would have to come later, as I´m not familiar with the Windows API GUI functions, forget other such libraries. However, I have a project on the backburner to create my own GUI library for FreeBASIC that will also be portable and could be ready by the end of the year.

Now, however, two important question remains: Would the ORTS team accept a "third party" (I would make it open source and freeware for ORTS anyway) app written in something else than C (in this case, FreeBASIC - easy to port to VB)?

If the above is no, forget about Q2: Which format will these files be in? Plain text? Easy to work with. CSV or anything else? Um... could be a headache, since EXTENSIVE reworking of the above-mentioned code would be required.


Removing entries from the global file / exporting them to an exchange file could even more easily be done, though it WILL require a GUI as to be user-friendly enough (passing a file as a command line can be done by dragging.and-dropping in the windows explorer. But if there´s no file to pass, the command line would have to be typed).

However, I generally develop such programs as (a) bulk-processing utilities which means that (:sign_thanks: they are command line programs that © need an external GUI frontend with which the user interacts and which is the only thing to interact with the actual program. That way, also other programs not developed by me can interact with the actual program without any unnecessary GUI cluttering things up. RE what this means for this specific program: The actual program can be available quickly, only the GUI part has to wait.

Tell me what you thing, pls.

Cheers, Markus

[James Ross]

If we need a GUI or at least import/export functionality, we'd included it as part of Open Rails, written in .NET, probably integrated entirely into the menu.

[markus_GE]

I´ll accept that as no ;)

:birthday: for the feedback anyway.

Cheers, Markus

[Genma Saotome]

Continuing to expand the definitions, here are my initial thoughts for some of the data requirements for what goes into the CAMFIG file. Please understand that the different sections shown appear as different objects but that is only for the purpose of making clear as a specification how the data is used. So long as the usage requirements are met, I do not care one way or the other about how the programmer decides to physically code the object(s).

ALL CAMERAS SHALL HAVE THIS DATA

• CameraUI( Int ) <--- Something that uniquely identifies each camera, such as a serial number (e.g., 0, 1, 2, 3...).
  
• CameraName( String )
  
• CameraFOV( Real )
  
• Camera NearZClip ( real ) <--- How close, in meters, is the view range of the camera.
  
• Camera FarZClip ( real ) <--- How far, in meters, is the view range of the camera.
  
• CameraBaseInOutCode ( String ) <--- Inside the train or Outside of it
  
• CameraMovement ( String ) <--- Circular, Straight line, or None.

After that basic data is collected, it seems that everything from here on out depends largely on whether the camera is being used by "a person" inside of the train or outside of it. The value of CameraBaseInOutCode() will therefore determine what gets collected in the block of data.

ALL OUTSIDE CAMERAS SHALL HAVE THIS DATA

• CameraTerrainBounce( Binary ) <--- may be implemented in later phases
  
• CameraManMadeObjectBounce( Binary ) <--- may be implemented in later phases
  
• CameraNaturalObjectBounce( Binary ) <--- may be implemented in later phases
  
• CameraOutsideSubtypeCode( Int )<--- How the outside camera will be used where 1 = Player Tracking, 2 = Software Tracking, 3 = Fixed Location (e.g., Tower), 4 = RR Employee, 5 = The Public

As you can see, most of the above relates to rules about camera collisions. I expect those features will most likely be addressed well after the initial phases of Camera Sets and so at this time no further specification for those features will be provided. That said, the last parameter in the list is important from the start as it determines the data necessary to define the type and extent of camera movement.





FOR OUTSIDE CAMERAS THE REST OF THE NECESSARY DATA VARIES BY HOW THE CAMERA IS USED
When CameraOutsideSubtypeCode(2)... (To replicate what MSTS Camera 4) does this data is necessary:

• DefaultAttachedTo( Int, 0-999 ) <--- the default unit number in the consist used to attach the camera, w/ consist designated first unit = 0 and last unit = 999.
  
• DefaultExteriorOffsetXY( Real, 1-9999 ) <--- the default number meters away from the center of the attached unit the camera will be placed on the XY plane as measured along the track the unit is located upon.
  
• DefaultExteriorOffset( Real, -180 to 0 to +180 ) <--- the default degrees offset the camera will have from perfect alignment to the direction of the attached unit, in degrees, where 0 means aimed from straight ahead of the first unit in the consist facing the rear of the consist (as defined in the .con file) and 180 means aimed from straight behind the last unit in the consist facing the front of the consist (as defined in the .con file) and-90.01 TO 360.0 TO +90.01 means aimed towards the front of the consist (as defined in the .con file),where negative values always mean on the left side of the train as viewed from the end of the consist (as defined in the .con file) and positive values always mean on the right side of the train as viewed from the end of the consist (as defined in the .con file).
  
• DefaultOffsetZ( Real, 1-9999 ) <--- the default Z dimension offset, in meters, relative to the center of the attached unit.
  
• DefaultYaw( Real, 0-180 ) <--- the default direction the camera looks, in degrees, where 0 means directly at the center of the attached unit; negative means towards the camera's left, positive means towards the camera's right.
  
• DefaultCameraPitch ( Real, -90 To 0 To +90 ) <--- the default orientation of the camera lens, in degrees, relative to the center point of the attached unit.
  
• MaxRise( Real, 0-9999 ) <--- the allowed change of position on the Z Axis the camera may move upwards from DefaultExteriorOffsetZ, in meters.
  
• MaxFall( Real, 0-9999 ) <--- the allowed change of position on the Z Axis the camera may move downwards from DefaultExteriorOffsetZ, in meters.

n.b., My expectation is there will initially be 8-10 such cameras defined, all positioned at ground level and all assigned to a single Tracking Set. I would not be surprised to see users add more such cameras that are positioned above ground level and to assign those cameras to sets at various altitudes well above ground level.

QUESTION: I used Degrees as an offset... should that be meters to the left or Right instead? In the later case the OR software would need to determine the correct radius value so the distance from the tracked unit remains the same when swing motion is done.

Goof. DefaultExteriorOffset( X Y ) has the data, where Y will specify the number of meters to the left or right of the track.




When CameraOutsideSubtypeCode(1)... (To replicate the behavior of MSTS camera types 2 and 3) this data is necessary:

All of the data available to MSTS camera type 4 (shown above), plus

• MaxTurnLeft( Real, 0-360 ) <--- the allowed change of position on the XZ plane the camera may move to the left from DefaultYawDegrees(), in degrees.
  
• MaxTurnRight( Real, 0-360 ) <--- the allowed change of position on the XZ plane the camera may move to the right from DefaultYawDegrees(), in degrees.
  
• MaxRunIn( Percent, 0-100 ) <--- The allowed movement, in meters, the camera may move towards the attached unit, relative to its initial position. Probably should not exceed the value of DefaultExteriorOffsetXY().
  
• MaxRunOut( Percent, 0-999 ) <--- The allowed movement, in meters, the camera may move towards the attached unit, relative to its initial position.

Data for CameraOutsideSubtypeCode(3) -- fixed location, such as a tower, to be determined later.


Data for CameraOutsideSubtypeCode(4) -- RR employee on the ground, such as a brakeman, to be determined later.


Data for CameraOutsideSubtypeCode(5) -- member of the public, on the ground, such as a passenger approaching a car, to be determined later.









ALL INSIDE CAMERAS SHALL HAVE THIS DATA

• CameraInsideSubtypeCode( Int ) <--- 1 = RR Employee, 2 = The Public
  
• DefaultRollingStock ( Int ) <--- 1 = Locomotive Cab, 2 = Passenger Car, 3 = Freight Car, 4 = Caboose
  
• DefaultInteriorOffsetX( Real ) <--- the X axis offset, in meters, from the position defined in the .wag or .eng
  
• DefaultInteriorOffsetY( Real ) <--- the Y axis offset, in meters, from the position defined in the .wag or .eng
  
• DefaultInteriorOffsetZ( Real ) <--- the Z axis offset, in meters, from the position defined in the .wag or .eng
  
• DefaultInteriorOrientation ( Real ) <--- the aim of the camera lens, in degrees, where 0 = the direction of the unit containing the camera; Negative is to the left, positive to the right.
  
• DefaultInteriorYaw( Real, 0-180 )

All of the above relates to the initial position of the camera within a car or locomotive. I expect most / all of the data will still come from .wags and .engs. Providing for that data in the CAMFIG file enables the means to assign interior based camera to specific camera sets.


That's all for the moment.

This post has been edited by Genma Saotome: 24 July 2014 - 10:23 PM
Reason for edit:: Correction.

[James Ross]

Genma Saotome, on 18 July 2014 - 10:41 AM, said:

Continuing to expand the definitions, here are my initial thoughts for some of the data requirements for what goes into the CAMFIG file. Please understand that the different sections shown appear as different objects but that is only for the purpose of making clear as a specification how the data is used. So long as the usage requirements are met, I do not care one way or the other about how the programmer decides to physically code the object(s).

Thanks Dave; I'm busy catching up on stuff but have added this to my queue of things to look at.

[Eldorado.Railroad]

I hope there a facility for both port and starboard head outside cab views. I often have to position this view pretty far away from the cab window because one side of the model has a mirror to look past while the other does not. In MSTS this was moot, because the coordinates were only for the engineer.