Elvas Tower: Camera Sets - Elvas Tower

Jump to content

Posting Rules

All new threads will be started by members of the Open Rails team, Staff, and/or Admins. Existing threads started in other forums may get moved here when it makes sense to do so.

Once a thread is started any member may post replies to it.
  • 3 Pages +
  • 1
  • 2
  • 3
  • You cannot start a new topic
  • You cannot reply to this topic

Camera Sets

#1 User is offline   Genma Saotome 

  • Owner and Admin
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Owner
  • Posts: 12,709
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 30 May 2014 - 11:28 AM

Problem Statements:
* 8 possible camera definitions are too few to cover the full range of possible positions and camera types that players may want to use. The limit appears to be determined of number keys on a keyboard.
* Lack of a camfig file prevents players from configuring cameras to their own preferences.
* The KUJU design of a global Camfig does not take into account the different needs individual routes may require.

Objectives:
* Determine whether a GUI is necessary for managing files specified herein or that an ordinary editor is sufficient. Design, Code, Test, Release GUI as needed.
* Provide both a global and route specific user editable camfig file. The route file is optional and the global file is required.
* Provide both a global and route specific user editable CameraSet file that groups a list of 1 to 10 cameras from the camfig file into an operable set used by the OR software. The route file is optional and the global file is required. The camera set file can specify any combination of global or route-specific cameras. Each camera in each set shall be tied to a unique integer value between 0 and 9.
* Enhance the OR software to check for and if found to use the route-specific files; If none, use the global files.
* Enhance the OR software to switch between camera sets updating the in-use definitions from the camfig file with each in-game change. Players will continue to use integer numbers to change from one camera to another.
* Enhance the OR software to display a thin GUI that, on a mouse click, signals to the software which camera set has been selected and thereby affecting a change in current camera definitions.
* Provide a number of OR-Suggested entries to the camfig file with a subset matching existing OR camera definitions.
* Provide a number of OR-Suggested camera sets, one of which matches the current OR cameras. A convention of odd/even integers should be followed to signify positional orientation
*Assess and recommend whether the above convention should be based on left/right or front/rear camera positioning relative to the train (e.g., all odd numbers position the cameras to the left side, even numbers to the right).
* If an OR provided GUI is not used to manage the CameraSet file, enhance the OR software to verify at run time that all data in the selected-for-use CameraSet file are valid.
* If an OR provided GUI is not used to manage the Camfig file, enhance the OR software to verify at run time that all data found in the selected-for-use Camfig file(s) are valid.
* Adjust existing Camera software as needed to reflect the use of a camera number to replace head out key commands.

Specific features:
* Camfig file shall allow for defining tracking cameras (e.g., what cameras 2 and 3 do today).
* Camfig file shall allow for fixed outside-position cameras (e.g., what cameras 4 does today).
* Camfig file shall allow for fixed inside-position cameras (e.g., what cameras 1 does today, to include head-outs).
* Camfig file shall allow for specification of a target-to-attach-to in the train (e.g., first, last, first + n, last-n )
* Camfig file shall allow for specification of initial XYZ position, horizontal, and vertical rotation relative to its target.
* Camfig file shall allow for specification of its rate of both slow and fast movement per second for user movable cameras for sweep, rotate on its own axis, vertical, and towards/away camera movements.
* Camfig file shall allow for specification of a ramp-up and ramp-down parameters for rotational speed that control the length of time, in seconds for the ramping of speed. Actual movement speed while ramping shall be a straight line incremental summation of ((Current speed/second)/ ramping length of time) + what was used in the previous second, with a start speed = (Current speed/second)/ ramping length of time) and a final speed of Slow (or Fast depending on what the user is keying) movement speed. A value of 0 seconds means do not ramp speeds.
* Camfig file shall allow for specification of a ramp-up and ramp-down parameters for sweep speed that control the length of time, in seconds for the ramping of speed. Actual movement speed while ramping shall be a straight line incremental summation of ((Current speed/second)/ ramping length of time) + what was used in the previous second, with a start speed = (Current speed/second)/ ramping length of time) and a final speed of Slow (or Fast depending on what the user is keying) movement speed. A value of 0 seconds means do not ramp speeds.
* Camfig file shall allow for specification of a ramp-up and ramp-down parameters for vertical speed that control the length of time, in seconds for the ramping of speed. Actual movement speed while ramping shall be a straight line incremental summation of ((Current speed/second)/ ramping length of time) + what was used in the previous second, with a start speed = (Current speed/second)/ ramping length of time) and a final speed of Slow (or Fast depending on what the user is keying) movement speed. A value of 0 seconds means do not ramp speeds.
* Camfig file shall allow for specification of a ramp-up and ramp-down parameters for towards/away from target speed that control the length of time, in seconds for the ramping of speed. Actual movement speed while ramping shall be a straight line incremental summation of ((Current speed/second)/ ramping length of time) + what was used in the previous second, with a start speed = (Current speed/second)/ ramping length of time) and a final speed of Slow (or Fast depending on what the user is keying) movement speed. A value of 0 seconds means do not ramp speeds.
* Camfig file shall allow for specification of its maximum extent of vertical movement, towards/away from target movement, rotational movement, and sweep movement (using the target as a center point of the arc of movement).

* Camera Set file shall provide for defining which camera is active on first use of the set and which camera will be used on subsequent uses with a choice of ( First used | Last used ).

TBD (i.e., feasibility, desireablity, timing):
* Is there a need for key strokes to invoke a change on the active camera set?
* Is it feasible (and desirable) to allow a unique FOV with each camera set (or each camera)?
* Is it feasible (and desirable) to allow a unique MaxViewDistance with each camera set.
* Does the Camfig file need to allow a specification of a target-to-aim-at in the train that is different than the attach-to-target? Might be applicable to head out cameras for passengers and/or cameras for crewmen assigned to watch the train. Such a feature would allow for automatic camera rotation to follow the target thru curves.

#2 User is offline   James Ross 

  • Open Rails Developer
  • Group: Elite Member
  • Posts: 4,980
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 30 May 2014 - 01:02 PM

View PostGenma Saotome, on 30 May 2014 - 11:28 AM, said:

* Provide both a global and route specific user editable camfig file. The route file is optional and the global file is required.
* Provide both a global and route specific user editable CameraSet file that groups a list of 1 to 10 cameras from the camfig file into an operable set used by the OR software. The route file is optional and the global file is required. The camera set file can specify any combination of global or route-specific cameras. Each camera in each set shall be tied to a unique integer value between 0 and 9.


What is the objective with route-specific camera configurations/sets? Are you suggesting that routes come with such things (to what end?) or simply that the user is free to create such things?

View PostGenma Saotome, on 30 May 2014 - 11:28 AM, said:

* Is there a need for key strokes to invoke a change on the active camera set?


I believe so; I don't want anything to require a mouse (camera zoom and managing the consist's brakes/couplings are such things currently, which I'd like to change) if at all possible. I believe we could use something like:

  • 1 to 0 change camera
  • Shift-1 to Shift-0 toggle cab view (and other things?) - we could actually drop this
  • Control-1 to Control-0 change camera set


If camera sets are sorted (either alphabetically or manually by the user), the selection with Control could simply be the global camera sets followed by any route specific camera sets (if they exist). That would give the consistency between routes.

I've also labelled it 1 to 0 because I think we should sequence the keys 1, 2, ..., 8, 9, 0 for camera/sets 1 through 10.

View PostGenma Saotome, on 30 May 2014 - 11:28 AM, said:

* Is it feasible (and desirable) to allow a unique FOV with each camera set (or each camera)?


Totally feasible and I suspect highly desired per-camera. The camera zoom function is just an FOV adjustment so this would simply set the default FOV for each camera but then we'd remember the current FOV for each camera during a session (like now).

View PostGenma Saotome, on 30 May 2014 - 11:28 AM, said:

* Is it feasible (and desirable) to allow a unique MaxViewDistance with each camera set.


Although I can see the desire for this - maybe an interior camera would want less viewing distance than a helicopter-like camera - there are technical and logical issues.

Technically, we only load data periodically and when doing so load based on the viewing distance. If this were to change arbitrarily by camera, we would have to e.g. load more terrain when switching to a camera with higher viewing distance.

Logically, we have the issue that viewing distance is a major performance control and as such we really could not get away with specifying it absolutely in a camera configuration. If we did, the actual viewing distance would have to be min(global setting, camera setting) and we might have to put in an option like we already have for scenery, e.g. "Extend camera viewing distance to global viewing distance". Therefore, I think the only way we could do this would be a percentage/ratio of the user's configured viewing distance but you'll still have problems with people deciding their outside camera should be 50% and under utilising the system. Of course, if only the user of OR can set this, it might provide some use but it would still have to be a percentage/ratio AFAICS.

View PostGenma Saotome, on 30 May 2014 - 11:28 AM, said:

* Does the Camfig file need to allow a specification of a target-to-aim-at in the train that is different than the attach-to-target? Might be applicable to head out cameras for passengers and/or cameras for crewmen assigned to watch the train. Such a feature would allow for automatic camera rotation to follow the target thru curves.


If I understand correctly, this would be a camera attached to one car but looking at a different car, e.g. on the rear of the train looking towards the front. This would be a new type of camera so we might want to separate that from the base idea - put the current set of cameras in to camera configurations/sets and separately consider adding new camera types. There are others I'd suggest if we did this. :victory:

#3 User is offline   conductorchris 

  • Superintendant
  • Group: First Class
  • Posts: 1,740
  • Joined: 24-March 10
  • Gender:Male
  • Simulator:Open Rails - MSTS
  • Country:

Posted 30 May 2014 - 01:46 PM

The nice thing about having different profiles is it could allow a simple set for beginners and folks like me who haven't taken a deep dive in this area -- and others for those who have.
Christopher

#4 User is offline   Genma Saotome 

  • Owner and Admin
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Owner
  • Posts: 12,709
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 30 May 2014 - 02:13 PM

Quote

What is the objective with route-specific camera configurations/sets? Are you suggesting that routes come with such things (to what end?) or simply that the user is free to create such things?

I think the vast majority of routes would not bother but there are some where route camfigs sensibly come into play and that is where the ROW is normally quite narrow due to combinations of terrain, trees, and/or buildings. In those routes you really want to be using shorter distances to the target lest you find your camera being blocked by trees and falling inside of buildings.

A route builder might always want to issue a custom camfig file that he thinks works better w/ his route... perhaps the vertical height is limited so as to not expose the fact there isn't much scenery beyond what's been set down along the ROW.

And last, to provide for the fellow who has his own opinions about what works best on specific routes.

Now as an alternative solution perhaps the answer is to just encourage players to just add as many camera variations as they want to the global file... or perhaps multiple, uniquely named global camfigs. Perhaps the issue of administration needs to be looked at... what happens when folks start publishing their own camera specifications, their own CameraSet specifications? Does that influence the physical solution?

But now that I consider, this discussion is perhaps too much about the physical solution. Perhaps at this point in time the discussion should be limited to understanding what degrees of flexibility need to be provided and why (on that topic my preference is for more, not less), not how. As an example, should the global files be fixed for all time by the OR team with any and all route specific files created with the same definition, but done by end users? Perhaps. Should contributed files be appended to the existing one or left standalone, to be selected at some point in time? Not sure. But to be clear, my goal is two part: (1) to provide individual choice: Global vs. route specific; This camera spec vs. that one; My set of preferred cameras vs. yours, and so on and (2) to allow for the exception (route specific) when wanted that is taken in preference to the standard (global). I think most people will choose the simple solution: a global setup. But IMO OR should allow the individual to choose for themselves.

I'm inclined to say the above thinking applies to camera sets as well.

Given the format of the data files and function within the code should be identical wouldn't the only real burden on development to do both global and route-specific be to first look for a route file and to switch to the global one if the first glance is empty? Inside the code camera processes will be data driven... whatever is read in from the selected CameraSet and Camfig files.

Quote

I've also labelled it 1 to 0 because I think we should sequence the keys 1, 2, ..., 8, 9, 0 for camera/sets 1 through 10.


I'm pretty sure I have no opinion one way or the other... just that everyone is used to an integer value to change cameras and we do have 10 keys to use -- more if the code is changed to look for two key mnemonics (something I think will be necessary elsewhere and probably not needed for cameras).

Quote

(WRT FOV) Totally feasible and I suspect highly desired per-camera.

Cool. I don't think there would be a need to remember anything so long as the proper data is obtained w/ each change. What does need to be examined is whether the FOV value belongs in the camfig data or on the camera line in the CameraSet file. Off the top of my head I cannot think of a compelling argument right now for one place vs. the other.

I realize now that I did not specify how to deal with the "Last-Used" choice when returning to a camera set with specific regard to what to do if the "last used" camera had been moved? I am inclined to say an extra parameter is called for: ReturnPosition ( "Last Position" | "Camfig Position" ) where the later is what the camfig file has and the former is data that was set aside for this purpose.


Quote

If I understand correctly, this would be a camera attached to one car but looking at a different car, e.g. on the rear of the train looking towards the front. This would be a new type of camera so we might want to separate that from the base idea - put the current set of cameras in to camera configurations/sets and separately consider adding new camera types. There are others I'd suggest if we did this. :victory:


Yes, that is correct. And I agree other camera types might be useful too -- the walking brakeman for instance: no sweep, attach, detach reattach to cars, etc. etc. It could be added at a later time if the incremental development cost is a burdensome.

#5 User is offline   James Ross 

  • Open Rails Developer
  • Group: Elite Member
  • Posts: 4,980
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 30 May 2014 - 02:38 PM

View PostGenma Saotome, on 30 May 2014 - 02:13 PM, said:

Given the format of the data files and function within the code should be identical wouldn't the only real burden on development to do both global and route-specific be to first look for a route file and to switch to the global one if the first glance is empty? Inside the code camera processes will be data driven... whatever is read in from the selected CameraSet and Camfig files.


Well, I'd personally prefer to merge the list of camera set so you get access to the global camera sets and the route camera sets but that isn't hard either.

FWIW, I generally work somewhat to the minus 100 points concept so, if we can't find good reasons for implementing the extra stuff for route-specific camera sets, we shouldn't do it. (I think we have some okay but not great reasons right now.) We might also want design with it in mind, but not implement it initially.

#6 User is offline   Genma Saotome 

  • Owner and Admin
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Owner
  • Posts: 12,709
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 30 May 2014 - 05:08 PM

View PostJames Ross, on 30 May 2014 - 02:38 PM, said:

Well, I'd personally prefer to merge the list of camera set so you get access to the global camera sets and the route camera sets but that isn't hard either.


Might be a good idea. I'm all for providing a fully featured, flexible solution. The way I wrote up the proposal really is just a starting point for further design.



Quote

FWIW, I generally work somewhat to the minus 100 points concept so, if we can't find good reasons for implementing the extra stuff for route-specific camera sets, we shouldn't do it. (I think we have some okay but not great reasons right now.) We might also want design with it in mind, but not implement it initially.


Well in this case I think the answer is this: The OR team does not have the knowledge of the personal choices that might be made by all end users and so to close off the ability to customize the camera system on a route by route basis is, IMO, an insufficiently flexible solution to meeting their needs. That said, if there is an alternative physical design that allows them to do route by route when they want to but does it in fewer files than I outlined, well, I've no problem with that. But I'm inclined to say that somewhere, somehow, some of the data should be reserved for use by 1 to n routes where n is fewer than the number of routes installed. Whether that is in files located with the route or field values set in a global file doesn't matter to me.

Something else that needs to be kicked around is the proper location of the initial camera position. I wrote that data up as attributes of the camfig file but that need not be the case. One could argue it belongs on the camera lines of all camera sets... or perhaps in another file that sits between the Camfig and CameraSet files.

The other topic to look into is managing the receipt of n distributions of these files.

The best answers to the above, I think, will be determined by a better understanding of the administrative aspects of managing the lifecycle of these files: For distribution (update), if end users are asked to append new definitions to the existing files what exactly do they distribute -- just the additions or the whole file? How will the unique identifier on any row remain unique when lots of people are distributing data? Or should they instead be asked to set up and distribute alternative files -- "Joe's_Gold_Camfig" -- and let the end user specify which camfig and cameraset files he wants to use? Maybe at run time, maybe one selection as the default and the other at run time, or 1 to n in individual routes and one as default for all the others. I'm inclined to think many uniquely named files presented for user selection might be the easiest solution for each player to administer.

#7 User is offline   James Ross 

  • Open Rails Developer
  • Group: Elite Member
  • Posts: 4,980
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 01 June 2014 - 03:10 AM

View PostGenma Saotome, on 30 May 2014 - 05:08 PM, said:

Well in this case I think the answer is this: The OR team does not have the knowledge of the personal choices that might be made by all end users and so to close off the ability to customize the camera system on a route by route basis is, IMO, an insufficiently flexible solution to meeting their needs.


The purpose of the minus 100 points system is that, if you can't clearly show it as being needed and worth implementing, you don't implement it. So saying we have no idea if users might want to do it or not is a fairly clear argument for not doing it, at this point.

I am also in favour of building a big feature like this in steps, so we can simply work up to per-route configuration after we've done the rest - but importantly, I think, after people have had some time to play with it.

View PostGenma Saotome, on 30 May 2014 - 05:08 PM, said:

The other topic to look into is managing the receipt of n distributions of these files.


We also need to consider the camera set(s) distributed by OR vs. the user. We must be able to update the former and we need to not wipe out the user's when doing so. Hence, I'm thinking we have two locations - one as part of the OR code which is updated, and one which the user is free to add whatever they like. Potentially, then, that could just be extended to three locations for routes (OR, user, route) if we allow per-route sets. I'm not sure, though, if we would want per-route sets in the route directory or just associated with it... it seems like both (for route author-made sets vs. user-made sets).

#8 User is offline   Genma Saotome 

  • Owner and Admin
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Owner
  • Posts: 12,709
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 01 June 2014 - 09:08 AM

View PostJames Ross, on 01 June 2014 - 03:10 AM, said:

The purpose of the minus 100 points system is that, if you can't clearly show it as being needed and worth implementing, you don't implement it. So saying we have no idea if users might want to do it or not is a fairly clear argument for not doing it, at this point.


I think the expansion to sets is an obviously good idea. Consider ordinary tracking: Right now you get two camera positions (cameras 2 and 3) and that is it. But if you look at the list of reasonable additions to tracking you come up with 5 at the front and 5 at the rear (a pair looking along the train from the right and left sides that is ahead of/ behind the traveller, one above the track, and a pair located slightly inside the traveller looking towards the it's margins... 5 for the front, 5 for the rear). Why would you think nobody would use that?

As for sets... one set of tracking cameras position low, about 2m above the track, another positioned higher, maybe 5-15m up, a third positioned even higher, 20-50m. Players could switch between cameras (or camera sets) to change their point of viewing instead of sweeping -- in movie terms a cut instead of moving the boom.

Second argument in favor of sets is this: sometime down the road the software will have accumulated a very large number of keystroke driven commands where whatever that list is has become too long to remember which keys go with what commands (n.b., you can't be pulling help up all of the time). And so a partial solution to that is some sort of player command GUI. Grouping commands by train-crew-role allows subsetting the list -- you don't need to display the commands for a steam locomotive fireman all of the time. I believe relating camera sets to these train crew roles to be a very logical and straight forward way to manage all of this: One camera set for the Engineer, with a command gui for what an engineer normally does and a second camera list for the fireman with a command gui for what he does. When you are managing the throttle and things ar eunder control, but you want to check steam production you select the firemans camera set and bingo, the command gui changes from what an Engineer would use to what a fireman would use. You could still key things in w/o that change, but if you wanted a gui instead you change roles. When your're done, change the role back to engineer... or something else.

But that's not in this spec... it'll have to be it's own idea & spec.



View PostJames Ross, on 01 June 2014 - 03:10 AM, said:

I am also in favour of building a big feature like this in steps, so we can simply work up to per-route configuration after we've done the rest - but importantly, I think, after people have had some time to play with it.


Understood. I suppose one logical break in the sequence would be to change the existing cameras to be data driven from 1 set and then later on add the ability to do multiple sets (i.e., change from one set to another). That said, I am strongly of the opinion the real value is changing from one set to another.


View PostJames Ross, on 01 June 2014 - 03:10 AM, said:

We also need to consider the camera set(s) distributed by OR vs. the user. We must be able to update the former and we need to not wipe out the user's when doing so. Hence, I'm thinking we have two locations - one as part of the OR code which is updated, and one which the user is free to add whatever they like. Potentially, then, that could just be extended to three locations for routes (OR, user, route) if we allow per-route sets. I'm not sure, though, if we would want per-route sets in the route directory or just associated with it... it seems like both (for route author-made sets vs. user-made sets).


Perhaps we need to ask ourselves whether any OR provided Camfig & CameraSet data needs to be a constant over an extended period of time rather than a recommendation / basis for rolling your own? I'm not sure one way or the other. KUJU certainly didn't object when folks hacked their camfig values. Is there a technical reason? Might a value validation step on startup serve just as well to ensure the user hasn't screwed up the data -- something that probably should be there anyway 'cuz somebody, somewhere, will eventually screw up their data.

#9 User is offline   Genma Saotome 

  • Owner and Admin
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Owner
  • Posts: 12,709
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 01 June 2014 - 09:26 AM

WRT ways to identify one CameraSet from another... as I mentioned above I think roles is one way to consider but that solution aside there is an open issue of how to distinguish them.

My own ideas on the matter follow traditional understanding provided by KUJU: Tracking refers to being attached to the train and moving along with it; having multiple tracking sets means coming up with an adjective to distinguish one from another. One possibility is starting height above the rail... perhaps Tracking-Low, Tracking-Mid, Tracking-High; A variant to that might be to replace Lo, Mid, High with the altitude value in m: Tracking-2m, Tracking-7m, Tracking-20m and so on.

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.

In the cab of course. At first only 1 would serve but down the road, if there is a command GUI then 2: Engineer and Fireman.

Caboose: Probably the same as Cab.

Passenger... not sure. Sets per car perhaps?



I suppose people might want to adjust the proximity to the target on tracking CameraSets... Near, Avg/Std, Far for example. Going with the idea of distance as meters works here too but then one wonders if it would be better to put the whole XYZ string in: Tracking+10/-20/+2 for instance. Rather clumsy I think, something that suggests people should not go wild and try to set up a CameraSet for every possible position but perhaps to pick three or four most-likely-to-be-used sets and stick with those.

The reason this needs to be addressed is this: by what means does a person switch from one set to another? I'd use a thin GUI: a single row line of buttons to click on where each button has a meaningful string written on it. But then there are those who prefer keystrokes.

At this point in time I don't think I'm partial to one naming convention over another (other than (1) roles are a natural fit, (2) that the software will probably use a serial number as a UI instead of a string and that's fine, and (3) provision for different languages is included)... just that it is something that should be resolved.

#10 User is offline   James Ross 

  • Open Rails Developer
  • Group: Elite Member
  • Posts: 4,980
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 01 June 2014 - 09:50 AM

View PostGenma Saotome, on 01 June 2014 - 09:08 AM, said:

I think the expansion to sets is an obviously good idea.


I wasn't talking about sets in general, just the ability to have per-route sets.

View PostGenma Saotome, on 01 June 2014 - 09:08 AM, said:

Understood. I suppose one logical break in the sequence would be to change the existing cameras to be data driven from 1 set and then later on add the ability to do multiple sets (i.e., change from one set to another). That said, I am strongly of the opinion the real value is changing from one set to another.


Sure, and 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.

It's also worth noting that we should balance feature cost vs. user return. If per-route camera sets are going to be used by a tiny fraction of users but are anything but really easy to add, it would be better not to. (I do think they would be quite easy to add but it's not yet clear how many people would use them or how much they'd gain from it.)

View PostGenma Saotome, on 01 June 2014 - 09:08 AM, said:

Perhaps we need to ask ourselves whether any OR provided Camfig & CameraSet data needs to be a constant over an extended period of time rather than a recommendation / basis for rolling your own? I'm not sure one way or the other. KUJU certainly didn't object when folks hacked their camfig values. Is there a technical reason? Might a value validation step on startup serve just as well to ensure the user hasn't screwed up the data -- something that probably should be there anyway 'cuz somebody, somewhere, will eventually screw up their data.


We should certainly validate the data reasonably when we load it.

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.

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.

  • 3 Pages +
  • 1
  • 2
  • 3
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users