|
From: Wayne B. <kil...@co...> - 2023-06-13 16:12:42
|
<div dir='auto'>The point being, YASim aircraft roll on this cover, JSBSim don't. I didn't spend enough time following the source to the line in question to understand why it might be calculated that way. But both Ysim and Jsim are dealing with ice or not in those code blocks. I don't necessarily think simply removing removing the division is the answer either. I did that and tested (very briefly),. At least the couple of land cover values I tested that used to be 50, we're only 1. One was a Broadleaf and one was a MixedForest. If it was coming straight from the material settings they would have been higher values.<div dir="auto"> I was assuming someone knew this code well enough to maybe understand a possible mistake just with this little bit of information, possibly not. Also I submit, the values for land cover friction should be directly tied to material settings, not some amped up value. What other reason would you design this code this way, include a material value for friction only to completely obliterate it later in the code. In this instance, I get you could be trying to adjust for local weather conditions. Where you have a base value for ideal conditions and adjust accordingly, if raining, divide by x. </div><div dir="auto">Mainly, I'm stuck on one fdm can land on this cover, one can't and in reality bush aircraft can, even if unadvisable, potentially land on most of this "ground" where there isn't heavy cover. Just because we don't have grass, brush, tree, etc, collision coded yet in the sim isn't a valid reason to excluded millions of acres of ground from access.</div><div dir="auto">I also bring this up because 3.0 is in the process of being designed and I am preemptively hoping to engrain a need to get the ground cover for it as robust as possible by bringing attention to the possibilities.</div><div dir="auto"><br></div><div dir="auto">This is just one more area I think FG can continue to distinguish itself from other sims. </div><div dir="auto"><br></div><div dir="auto">Wayne</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Jun 13, 2023 10:12 AM, James Turner <ja...@fl...> wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br /><div><br /><blockquote><div>On 13 Jun 2023, at 08:20, Wayne Bragg <killaccount@cox.net> wrote:</div><br /><div><div style="margin:0in;font-size:11pt;font-family:'calibri' , sans-serif;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">I finally had a chance to look at this a little closer. This unreasonably high rolling friction factor is only being calculated under the JSBSim FDM. Under YASim it is not dividing the material value by .02 and you end up with a reasonable value. Also why would you use static values directly from the material settings but not the rolling values?</div><br /></div></blockquote></div><br /><div>Erik replied (in this thread, but quite some messages ago) that the scaling by factor of 50 was intentional. Therefore I’m really unsure how to proceed: we can of course remove or change the value, but it affects all materials, so aren’t you simply moving the problem around?</div><div><br /></div><div>Also, the scaling is done in groundreactions.cxx which is NOT JSBsim specific code, although maybe only JSBsim uses the particular API which does the scaling? (Just guessing how Yasim and JSBsim could be different in this regard)</div><div><br /></div><div>Kind regards,</div><div>James</div><div><br /></div></div></blockquote></div><br></div> |