[James Ross]

James Ross, on 11 June 2014 - 03:51 AM, said:

I'm not happy with "normal" looking data triggering experimental code without an experimental option.

(Emphasis added.)

James Ross, on 11 June 2014 - 04:31 AM, said:

I'd still like either one of the values to be clearly ORTS/experimental or this to have an experimental option that's off by default.

(Emphasis added.)

gpz, on 11 June 2014 - 05:19 AM, said:

Even if I add an experimental option, the problem I described still persists. And if I leave everything as is, just add an option, that will not make the data look more unnormal. So that doesn't solve anything, just adds one more step.

Please notice how, in both my posts above, I asked for only one of the following two options:

• Data file values to be clearly OR/experimental.
  
• An experimental option to enable the control.

I did not suggest doing both, like you seem to be thinking right now. If you add an experimental option (off by default), you get to keep the names in the file. If you don't add an experimental option, you should change the names in the file.

[Csantucci]

First of all I thank Peter for having added the possibility of easily introducing this control in .cvf files.

I agree with James on the fact that in the .cvf file the use of this OR feature should be clearly recognizable and if possible should not cause problems when used with MSTS (even if now we have a way out of this by creating an OR-specific .cvf file).
Instead, I'm not happy with the experimental option checkbox, because you can't add a checkbox for every "minor" (no offence to Peter using this adjective, as I highly appreciate this feature) additional option.

So, my proposal is to introduce the option in a similar way as I did with the ORTSFont () additional feature. I see two possible options:
1) either adding within the Digital() block an
ORTSStyle ( ETCS )
line, that lets OR recognize such control as the one we want,
2) or considering this control as a new type, starting the block with following line
ORTSDigital (

Style ( ETCS )
)

Both solutions are MSTS-compatible.

I only add a point on the functionality of the control, that I admit I didn't test yet. As the control can have various dimensions in a 2D cab to take into account the perspective effect, I would ask that the digital speed indication reduces the dimension of the digits when the dimension of the control is reduced, (is it already so?), or, alternatively, that the ORTSFont () command line is recognized to reduce dimension of the digits.

[James Ross]

Csantucci, on 12 June 2014 - 06:25 AM, said:

Instead, I'm not happy with the experimental option checkbox, because you can't add a checkbox for every "minor" (no offence to Peter using this adjective, as I highly appreciate this feature) additional option.

So, my proposal is to introduce the option in a similar way as I did with the ORTSFont () additional feature. I see two possible options:

Experimental options are meant to be temporary. The key point here is that we don't trigger anything unexpected on existing content until we have an actual plan - this control was added completely arbitrarily (something I hope we'll be restricting in future) so we must ensure it has no adverse effects (and I expect everyone to observe this as much as possible).

Now that it is 'safe', we definitely should work out how to go forward with such extensions. Using an ORTSStyle() block is a good way to do that, it seems, though maybe not the only way. But it seems that new values inside Type() and Style() are out, as they crash MSTS, right? Although since we can do OR-specific cabs maybe that's fine. This is the discussion we need to have before we un-experimental a feature. :)

[Csantucci]

New values inside Type() and Style() crash MSTS only if they are within a Control that MSTS recognizes (e.g. Digital ()). If they however are within a Control that MSTS skips ( as e.g. ORTSDigital ()), MSTS skips the whole Control block and therefore you can mess more or less as you like within such Control block, provided that the count of open and closed parentheses matches. :)

[gpz]

Csantucci, on 12 June 2014 - 06:25 AM, said:

As the control can have various dimensions in a 2D cab to take into account the perspective effect, I would ask that the digital speed indication reduces the dimension of the digits when the dimension of the control is reduced, (is it already so?), or, alternatively, that the ORTSFont () command line is recognized to reduce dimension of the digits.

The heights of the numbers are reduced automatically as needed, the control scales quite well to any size.

James Ross, on 12 June 2014 - 06:45 AM, said:

this control was added completely arbitrarily (something I hope we'll be restricting in future)

I shared the code for the control weeks before commitment, indicating my uncertainty about the way to share it. Based on the lack of orders, and because we don't have an official way to share experimental code other than committing it to svn, I did so. I don't see what could be restricted here, except of the movement forwards, which is a must.

[gpz]

When we are extending MSTS file formats, there will always be a need to extend the corresponding MSTSSomething() class or file in MSTS.Formats/ directory with OR specific functions, and they cannot be separated to somewhere in ORTS.Formats/ until there is an own format. It is also a problem for class like MSTSLocomotive. It doesn't make much sense to call it MSTSLocomotive, it could be simply Locomotive, because there are also MSTS and OR specific functions in it, and I feel they will never be separated.

[James Ross]

gpz, on 12 June 2014 - 01:24 PM, said:

I shared the code for the control weeks before commitment, indicating my uncertainty about the way to share it. Based on the lack of orders, and because we don't have an official way to share experimental code other than committing it to svn, I did so. I don't see what could be restricted here, except of the movement forwards, which is a must.

If you do not understand the problems that have already been caused by people committing code without approval from others, then I suggest you think carefully before committing anything. There's a massive difference between a regulated flow of changes and the uncontrolled river we've had at times. That is going to change. We may expand source control to have a more playground-like area, where unconstrained experiments can take place, I don't know yet. I'd just like to remind people that we're trying to get to 1.0 right now and that means bug fixes and controlled changes.

gpz, on 12 June 2014 - 11:54 PM, said:

When we are extending MSTS file formats, there will always be a need to extend the corresponding MSTSSomething() class or file in MSTS.Formats/ directory with OR specific functions, and they cannot be separated to somewhere in ORTS.Formats/ until there is an own format. It is also a problem for class like MSTSLocomotive. It doesn't make much sense to call it MSTSLocomotive, it could be simply Locomotive, because there are also MSTS and OR specific functions in it, and I feel they will never be separated.

The MSTS.Formats code is for things that use MSTS file formats, which we're still unfortunately limited to in most cases, so I think their naming is fine. What would make some sense is removing MSTS from some of the simulator/viewer names, so you have e.g. Locomotive which can be initialised/created with either MSTS.Formats or ORTS.Formats data. This is something I've been working towards in my architectural changes in the viewer code. I don't like to step over in to simulator code too much, but Serana has been making progress recently with restructuring some of that.

[Serana]

If we want to check what is integrated into the main repository, we should switch to Git and Github.
That will make us use branches more often when we're creating experimental code.
Also, we will be able to make pull requests when we feel our new functionality is ready. People will then test the code and integrate the commits if there's no problem.

[James Ross]

Serana, on 13 June 2014 - 12:55 AM, said:

If we want to check what is integrated into the main repository, we should switch to Git and Github.

That's not the only option by a long shot - e.g. we can do similar things on Launchpad with Bazaar.

[gpz]

Bazaar is dying. See: https://www.stationa...rospective.html