[gpz]

disc, on 06 December 2015 - 06:18 AM, said:

But still using emergencyrescapacity as starting point, max brake force isn't considered, while the brake cylinder diameter (so as the volume) depends on the max force, because the pressure is fixed.

The brake force is calculated by

float f = MaxBrakeForceN * Math.Min(CylPressurePSI / MaxCylPressurePSI, 1);

no matter how you set up the initial values.

[disc]

gpz, on 06 December 2015 - 06:29 AM, said:

The brake force is calculated by

float f = MaxBrakeForceN * Math.Min(CylPressurePSI / MaxCylPressurePSI, 1);

no matter how you set up the initial values.

Yes, that's how the brake force is calculated from the percentage of pressure. But, that's not what i wrote about using the eng parameters i can make rolling stock that have 1 cm3 cylinder volume, and yet have 30000 kN maxbrakeforceN which is impossible in reality...
And then the players complain about why the game acts unrealistically, with unrealistic eng/wag parameters :)

[gpz]

disc, on 06 December 2015 - 07:22 AM, said:

And then the players complain about why the game acts unrealistically, with unrealistic eng/wag parameters

If I understand well that this is your primary concern, then I can say that just don't care about it. It might be also by intention. You must only ensure that game acts realistically with realistic parameters.

[Genma Saotome]

gpz, on 06 December 2015 - 04:48 AM, said:

Disc, don't try to guess the brake cylinder volume, it is available from the eng parameters, however it is tricky to get that, since it is indirect.

There is the "emergencyrescapacity" MSTS eng parameter. You have to divide it by the "emergencyresvolumemultiplier" to get the aux.cyl volume. If you further divide it by the "triplevalveratio", you get the brake cylinder volume. These MSTS parameters are all parsed for in AirSinglePipe.cs, the corresponding variables containing them are EmergResVolumeM3, EmergAuxVolumeRatio and AuxCylVolumeRatio, respectively.

So you don't need to implement any new default values for these, just use them. The only thing you might need to consider is adjusting the EmergResVolumeM3 default value, since that is set in eng files only rarely, so most of the eng-s are using the default we set.

Peter, what about older equipment that did not carry two reservoirs of air? Many cars built in North America before the 1930's had only one, often physically joined to the brake cylinder (K Brakes were either KC for combined or KD for divided).

A KC brake.



Such equipment was allowed on cars in interchange service (that would be almost all cars) up to 1952 or 53. IIRC cars built after 1937 were required to be built with AB brakes -- they had an emergency reservoir. For a handful of years before that some new cars were built with AB, others still with K.

Silhouette of the double reservoir used with AB Brakes.


Post WWII many such cars were scrapped, either worn out after many years of service or just too small to be worth changing the brake equipment, but were still common up to ~1950.


As a side note, I own copies of quite a few engineering drawings and many are the general arraignment of brake equipment for specific freight cars. It was very common for the draftsman to be required to document the maximum brake power and for many decades that was 70% of the empty car weight. Some were 65, a few others 60, but none over 70%. As I understand it, a higher value could cause the wheels to lock up and slide. Absent other information, this is calculation is a good data point for the value of MaxBrakePower() in .wags using either K or AB brakes.

[gpz]

The existence of emergency reservoir can be set at listing of available brake equipment types. E.g. for default dash9 it looks like this:

BrakeEquipmentType( "Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )

If it is not listed here, it will not be used in simulator. Regardless of this, the reservoir volumes settings are calculated as I wrote above, since Kuju decided to set them up like this, not the other way, starting from brake cylinder. We may change this order once we will have our own eng file format.

(BTW in Europe the cars are not equipped with emergency reservoir at all, as I know.)

[disc]

gpz, on 06 December 2015 - 11:24 AM, said:

The existence of emergency reservoir can be set at listing of available brake equipment types.

So if i understand correctly, Emergency res is always there, and the capacity can be set in eng/wag, but it can be excluded from view and the simulation, if it's not listed in brakeequipment?

[gpz]

Yes, the variable is always parsed, but the reservoir is not effective if not listed as available equipment. But see the code, if you are modifying it, you have to be familiar with it anyways. :)

[disc]

from rev 3361 engine brake should take air from MSR. The next tasks are to make graduated release switched on/off from .eng, add an MU engine brake on/off .eng param, implement a simple blended brake control.

[steamer_ctn]

gpz, on 06 December 2015 - 04:48 AM, said:

There is the "emergencyrescapacity" MSTS eng parameter. You have to divide it by the "emergencyresvolumemultiplier" to get the aux.cyl volume. If you further divide it by the "triplevalveratio", you get the brake cylinder volume. These MSTS parameters are all parsed for in AirSinglePipe.cs, the corresponding variables containing them are EmergResVolumeM3, EmergAuxVolumeRatio and AuxCylVolumeRatio, respectively.

Is it possible to add a new OR parameter for the Auxiliary Reservoir, which would make it cleaner and easier for people configuring WAG files, rather then trying to calculate Emergency Reservoirs, and appropriate multiplication factors?

Having to specify the Emergency Reservoir, especially when it is not used on the vehicle seems to be very misleading to those trying to set up the physics.

This new "ORTSAuxilaryResevoirCapacity" parameter could be used by default whenever it is present in the WAG file, If it is not present in the WAG file, then the current arrangement could be used instead. In this way both OR or default MSTS WG file configurations could be used.

[gpz]

I don't think it is a good move starting duplicating already existing settings in the current data model, the eng file. Eventually the confusion will be unavoidable. Where should we write the clarifying specification? We don't have an official and obvious place for that, actually we don't even have an official eng file specification. It will be just tribal knowledge, thus will be forgotten. It would be better though to think on how our own new engine configuration file will look like.

[hroch]

Hi disk.
Do you think you would be able to program correlation (dependency) between braking force and speed? When the speed rises up the braking force goes down and vice versa. As this thread shows http://www.elvastowe...lly-wheel-disc/

Thanks your answer.

[steamer_ctn]

gpz, on 07 December 2015 - 03:41 AM, said:

I don't think it is a good move starting duplicating already existing settings in the current data model, the eng file.

As no direct parameter exists for AuxilaryReservoirCapacity, I don't feel that it is duplicating the existing parameters.

gpz, on 07 December 2015 - 03:41 AM, said:

Eventually the confusion will be unavoidable.

I suspect that the current method of using the Emergency Reservoir, and a multiplication factor is just as confusing, whereas the use of a directly defined parameter will make it easier to interpret and set the WAG files.

I think that it is important to use directly defined parameters, rather then indirectly calculated parameters.

gpz, on 07 December 2015 - 03:41 AM, said:

Where should we write the clarifying specification? We don't have an official and obvious place for that, actually we don't even have an official eng file specification.

I agree that there appears to be no official specification, but this hasn't stopped (and probably won't stop) new parameters being added as new functions and features are added.

gpz, on 07 December 2015 - 03:41 AM, said:

It will be just tribal knowledge, thus will be forgotten. It would be better though to think on how our own new engine configuration file will look like.

Whilst not perfect, hopefully good comments in the code, and the manual will help preserve some of this knowledge.

[gpz]

steamer_ctn, on 08 December 2015 - 01:39 AM, said:

As no direct parameter exists for AuxilaryReservoirCapacity, I don't feel that it is duplicating the existing parameters.

By programming side, it is absolutely duplicating. The primary rule of data handling is that store at one place only, everywhere else just use references for that.

steamer_ctn, on 08 December 2015 - 01:39 AM, said:

I think that it is important to use directly defined parameters, rather then indirectly calculated parameters.

Yes, it is, but unfortunately Kuju decided to store these data in a different way. We may decide our own way in our own data format.

steamer_ctn, on 08 December 2015 - 01:39 AM, said:

Whilst not perfect, hopefully good comments in the code, and the manual will help preserve some of this knowledge.

And if we don't duplicate parameters, then there is no need for hope at all.

Certainly, I will not "delete", if someone inserts reading such a parameter, but I feel strongly against such duplications, it brings us only backwards, not forwards.

[steamer_ctn]

Thanks for the feedback.

gpz, on 08 December 2015 - 02:00 AM, said:

By programming side, it is absolutely duplicating. The primary rule of data handling is that store at one place only, everywhere else just use references for that.

Maybe I am not using the correct programming language or terminology (as I am largely self taught).

I agree with you (I think - if you are suggesting that data stored and used in the OR program should not be duplicated), as my suggestion was not to store duplicate or similar data elements within OR , but rather to have a different way of setting or initialising the appropriate data element when OR is first run. In other words I see the suggestion more of a user interface alternative, that would set the existing OR data element by using a different input parameter.

OR has already "broken" some of the constraints that Kuju placed on input data types and configuration to achieve better features and functionality. Therefore by default we have already started to create an "OR" input data format, and if a formal data format is required, then perhaps it is something that should be happening now rather then later.

If however, this is still a form of duplication in a programming sense, then I suspect we will need, as you have suggested in your last post, to agree to holding different points of view.

Thanks

[Genma Saotome]

I havn't been following the details here but AFAICT Australian Peter is wanting to move a parameter from an .eng to a .wag (or is it a .wag to an .eng?) because Kuju got it wrong, and Hungarian Peter is saying that's going to cause problems... right?

If yes, I side w/ Hungarian Peter -- you don't just want to jaywalk the data thru the internal objects of RunActivity to get it to the other side of the street... at least w/o understanding that it opens up a much larger issue: Should the internal objects in OR match the KUJU paradigm of the file (today's loader to RunActivity code) or should you completely rethink, design, and code the internal objects to more closely resemble their real world counterparts and then rewrite much of the application?

You could rewrite things in such a way that the RunActivity objects are fully populated by any number of flat files -- the new objects become The Official Objects and what the loader does is populate them from any acceptable source -- a MSTS file, an OR only file ... or even a file from some other game, assuming the loader can become smart enough to handle it. Or, nn alternative is a batch program that converts all old files to a new OR design and the Loader and RunActivity code is substantially changed to conform to that new design. Bottom line is you will have incompatibility between the existing object design and what makes sense in a future environment.

I've done standardization stuff like that, legacy systems data going to data warehouses and operational data stores; it is not a trivial task to figure out. OTOH, jaywalking the data from one place to another within the current objects will, IMO, lead to support-ability issues, especially if it becomes the accepted workaround.

And so I suggest to you to think beyond one or two braking parameters and instead assess if this issue is indeed an occurrence of the question of how does OR handle both MSTS and OR inputs when the list of data contained in the OR version has been shuffled across file boundaries?

I believe the choice is one of these:

• Fork the code so there is a MSTS version and an OR version. Change the OR version to handle this feature.
  
• Kludge up the OR code to handle this feature.
  
• Rewrite the loader and RunActivity objects to allow the loader to populate one object from multiple files.
  
• Write a conversion program to translate all old MSTS files into newly designed files so there is no need for a fork, rewrite the loader and RunActivity as needed.
  
• Forget about this feature, at least for now.

IMO you're best choice is probably #4; That said I respectfully suggest there are many higher priorities -- and more realistic tasks -- to address in the near term. Long term.. dunno if you'll really have any other choice but to pick from #1 or #4.

Hope this helps.