[Genma Saotome]

Peter, thank you for taking the time to write up such a good explanation of what's going on. I do appreciate it.

Here's my concern: Does the OR team "own" FCalc2? Have the source code? Can make changes and release new editions?

If the answer is Yes, then my only concern is that FCalc2 should be distributed with the OR downloads as OR supported software. If the answer to any is No then I would strongly urge you ask end users to put into the .wag files the elemental parametric data necessary for the Davis Formula to work and put into t he OR code whatever is necessary to use that data correctly.

Consider how DEMEX and/or MOSAIC and/or whatever that track generator software was called and/or lack of support for the Sketchup exporter have ALL caused problems for end users by either being difficult to obtain, install, or understand because the persons who authored them are no longer active in enhancing and/or supported their software. In each case there is no viable go-forward alternative... eventually somebody -- perhaps the OR team -- is going to have to step up and do something about it.

You don't know what's going to happen w/ FCalc2 and absent full ownership you should not inject it into the game process. I know one could say, "Yeah, what about DirectX? It's 3rd party software", to which I reply Microsoft isn't going anywhere and there are loads of alternatives available. How many teams are there out there in the world doing alternatives to FCalc2?

Last, I know for examining the data that the FCALC2 values suggested for the MSTS friction line are only an approximation of what the Davis formula would produce. IOW, they're wrong and not from any failure on Joe's part but because the MSTS Friction formula isn't the same as the Davis formula... so Joe had to fudge things to make the FCalc results kinda close enough. Are the A, B, and C values shown a conversion of these fudged values OR the correct product of the Davis Formula? IOW, do you know if they are actually accurate as compared to what's suggested for the Friction line?

[Genma Saotome]

copperpen, on 02 February 2014 - 05:22 AM, said:

I can see a problem ahead with activities if one person makes an activity using one set of resistance and the end user is using a different set.

Mervyn, IMO the OR team is rapidly closing in on that set of circumstances that would best be resolved by establishing it's own file types. Perhaps it is the achievement of OR 1.0 that means from here on out features that require new data and/or incompatible constructs will trigger the creation of the go-forward OR file type. Or something else. Whatever it will be in the meanwhile the team is going to continue to bump into the obstacle of what they want to do can't be done in a MSTS file w/o breaking MSTS compatibility. Such as the problem you cited, above.

[Matej Pacha]

Well,
First of all I would like to thank Peter for the enthusiasm and the work on OR physics. We had some plans with OR, but it was interrupted by a need for MSTS compatibility. The physics is still a work in progress and it is still not so far from the starting line. Usage of Davis' coefficients directly is definitely a step forward. Maybe, in the future, we will be able to estimate these numbers from the car description (since these are directly dependent on the car shape, rail-to-wheel contact and bearings).

copperpen, on 02 February 2014 - 05:22 AM, said:

I can see a problem ahead with activities if one person makes an activity using one set of resistance and the end user is using a different set.

I must say that this is the life - you can run two same missions, two same train sets, but you'll never get the same behavior. It can be caused by various factors (maintenace, failures, ambient temperature, etc.) And what if you have not the same trainset? Anyway, the friction formula parameters are important for the content creators, not for the players. And if you've changed something, you are the creator and you should distribute your content with your activity. I think this is not a big deal.

The problem of the Davis formula is always the units: there are lots of Davis-like formulas, lots of unit systems over the years, etc. Someone want to use kilonewtons directly, or newtons. Some coefficients are relative to the train mass or the gravity force - newtons per kilonewton, or per ton or newtons per kilopond... And what if the coefficients have been set up for a speed in miles per hour, or in kilometers per hour, or meters per second? ... Just thoughts :lol2:

Matej

[copperpen]

Dave

I have been busy testing these ORTSDavis lines using the Fcalc A+B+C figures as a start. My aim was to match the friction figures produced by OR to a published curve for BR Mk1 stock. To achieve that I had to reduce the A figure by about 100. The thing about the Davis friction is that the formula is empirical, and data is inserted to match a curve. Using OR to calculate this from given data requires more than just frontal area weight and number of axles. Until someone comes up with a formula that matches data to required performance then the output from Fcalc is the only thing we have. Perhaps someone should develop something like Fcalc specifically for OR.

Personally, I like having the facility to tune parameters rather that have a set of code decide for me, and then produce an unsatisfactory result.

[Genma Saotome]

FWIW I just tracked down FCalc2 on my PC. I havn't used it in years -- I use Excel instead. Out of curiosity I tried to run FCalc2. It won't run... some message about incompatibility w/ my OS. I dunno why... I only know it won't run. While the answer to that failure may be rather simple it does serve as an example to the concerns I expressed in post #11, above: If it won't run, for whatever reason, it cannot generate values to plug into .wag files.

[edwardk]

Dave,

The Dos version of FCalc will not run on Windows 7, but since the source code is available, I updated it so that it will run. Individual commands which became obsolete were replaced with custom procedures and changes to numeric values to show that they actually are floating point. I do not think this should be a big deal so I will upload the entire package with the updated source code and executable. I did test to check to make sure that the calculations are still correct and everything looks good. I always liked this version over the windows version.

Note: The updated code and executable are shown with "_updated".

Edward K.

Attached File(s)

•  fcalc_updated.zip (1019.34K)
  Number of downloads: 582

[rdamurphy]

Before DEMEX was released, I was very close to doing the same thing. As a matter of fact, I sent some source code to JohnCS, not because he needed help but just because I had it done and to hopefully save him some time.

I don't know if I have any of the code anymore, and it was written in VB. However, as I recall, it's really just a matter of translating height locations in the DEM data into a format that MSTS used, and adjusting for the fact that the earth is flat in MSTS.

The further you get from the NW origin of the data, the further off locations become. Which is why Marker files are always off.

There's really no reason we couldn't just use DEM data directly in the game.

Robert

[Genma Saotome]

copperpen, on 02 February 2014 - 01:32 PM, said:

Dave

I have been busy testing these ORTSDavis lines using the Fcalc A+B+C figures as a start. My aim was to match the friction figures produced by OR to a published curve for BR Mk1 stock. To achieve that I had to reduce the A figure by about 100. The thing about the Davis friction is that the formula is empirical, and data is inserted to match a curve. Using OR to calculate this from given data requires more than just frontal area weight and number of axles. Until someone comes up with a formula that matches data to required performance then the output from Fcalc is the only thing we have. Perhaps someone should develop something like Fcalc specifically for OR.

Personally, I like having the facility to tune parameters rather that have a set of code decide for me, and then produce an unsatisfactory result.

Mervyn, I've had a long think about our conversation... realized in some areas we are in agreement, tho perhaps not fully aware of that. I'm perfectly comfortable with the fact the Davis Formula is empirical -- I happen to use Excel for calculating resistance as I can chart the result in Excel and compare it to what I want to obtain; it seems you do something similar only w/ FCalc2. So let's agree that fiddling with the numbers in search of a desired outcome is a perfectly fine thing to do.

So why am I objecting to the proposal? <Begin Long Think> Before the OR was formed I was advocating for an Open Source, non-commerical train simulator. I wanted non-commercial to escape the trap that commerical software has: when the sales dry up the product dies. I wanted Open Source to escape the trap of when software author moves on the product dies. Fortunately for all of us Wayne Campbell had similar thoughts and had he skills to do something about it. The point: It's important to me to escape the trap of software authors moving on. There have been LOTS of people on the OR team, >90-95% of which are long gone. Open Source lets the coder go but saves the source code. <End Long Think>

One objection of mine is that AFAIK Fcalc2 is not an Open Source product. If it were I'd still have some reservations about your proposal -- as a (retired) Data Architect I will always advise you NEED to have the elemental data -- but I would be willing to overlook that IF I knew the source code for such an important set of functions was in-hand and would survive w/o its author.

OTOH, if FCalc2 is not Open Source and if there is no prospect for it becoming Open Source than the community long term prospects is, IMO, exposed to substantially more risk for a key portion of its functionality. If it were to disappear, much in the same way the situation with other 3rd party utilities have presented problems its omission will cause real problems. So my recommendation in this situation is to have end users record the locomotive/car based elemental data necessary for the Davis formula and within the OR code somebody needs to write the code for the various instances of the Davis Formula... a bunch of case statements. That way the key functions for accurately calculating resistance are Open Source because OR is Open Source. If somebody wanted to lift out that code, tie it to code that allows a user to point at a .wag file and then see the result charted then numbers fiddlers like you and me can fiddle away to our hearts content.

So what's really important (IMO) is to ensure that in the final result the community knows it can let the coder go but has saved the source code.

This post has been edited by Genma Saotome: 02 February 2014 - 09:16 PM
Reason for edit:: Rephrased last paragraph for better clarity.

[Lindsayts]

rdamurphy, on 02 February 2014 - 04:15 PM, said:

Before DEMEX was released, I was very close to doing the same thing. As a matter of fact, I sent some source code to JohnCS, not because he needed help but just because I had it done and to hopefully save him some time.

I don't know if I have any of the code anymore, and it was written in VB. However, as I recall, it's really just a matter of translating height locations in the DEM data into a format that MSTS used, and adjusting for the fact that the earth is flat in MSTS.

The further you get from the NW origin of the data, the further off locations become. Which is why Marker files are always off.

There's really no reason we couldn't just use DEM data directly in the game.

Robert

There are two reasons for the position errors brought about by the current world model that MSTS/OR uses.

First is the projection used is the not the best to display a world accurately on a flat plane. The second reason is that the calculations treat the earth as a sphere, from my work this produces an error around 1.5 percent in distance around the latitude 35 degrees south (the error will vary with both lat and long). To produce accurate positions the earths true shape must be aproximated, as is done in creating map projections such as Transverse Mercator.

I have done a great deal of work on this topic, if more info is required just ask.

Lindsay

[Lindsayts]

Hmmmmmmmmmmmm,

My previous post over simplifies the subject quite a bit, there are various option one can use to generate a more accurate world model.

Lindsay