Board index FlightGear Development Aircraft Cockpit development

scaling instruments in xml

Discussion about creating 2d and 3d cockpits.

Re: scaling instruments in xml

Postby Hooray » Wed May 14, 2014 9:47 pm

The thing about consistency is that it needs to be future-proof, too - i.e. in case someone leaves the project for a while, or even completely abandons a project.

And that's when becoming a "visionary" is almost as important as being a "designer" of some new project or feature.
Which also means that solutions must not be "lock-in" solutions, but need to be sufficiently well-understood and documented to either allow others to review/maintain them over time, or let them completely revamp/replace them if needed.

We always tend to see the problems in solutions that others come up with, but refer to our own contributions as "hacks", "workarounds", or more eloquently, "prototypes", even though they typically have the same issues and effects on projects and features developed by others

Yet, those very "prototypes" often end up being around for several years until someone comes up with something better or some major improvement.
At the end of the day, we're all just that: lazy human beings - and volunteers at that, too - i.e. we are really only motivated by stuff that's not a chore, but it must be fun.

So you end up with a huge herd of cats that don't want to be organized at all ...

Then again, there are a few people doing the unpopular "grunt" work here, i.e. constantly refactoring things, and permanently looking at the bigger picture to generalize stuff over time.
However, their work is usually not at all "visible" or even compelling to non-developers, often not even to developers.

We're really here to scratch our own itch and not contribute to some "global cause" that we may never benefit from at all.

Asking for better and more consistency is however exactly doing that: asking people to drop the "interesting & fun" stuff in favor of improving things for the long-term, without them necessarily benefiting from such work (or without it being obvious to them). Understandably, that's kinda frustrating - not just for the people asked to do the work, but also for those asking for it :D

I think we went through the same thing in all those T4T debates...

Imagine for a second you had spent 18 months working on a new project/aircraft/feature, and everybody is proud of your product, but suddenly someone comes around and says something along the lines of this is all great, but it's not future-proof, what you should really be doing is neuter the whole thing, split it up into a dozen modules, generalize each component to make it accessible to other users, and please don't complain about regressions - there certainly will be many, and we won't have much time to help you, but it's basically the right thing to do, and it needs to be done ASAP

This is pretty much what's happening to many developers who come up with useful, but non-generic, stuff - especially in a healthy software development environment, where people are constantly reviewing their own code. We've had many such discussions here in the past, i.e. when the random buildings system got first introduced, Thorsten and I were the ones discussing potential scripting hooks to make it less random and expose it to scripting space, so that placement heuristics could be based on other data (i.e. OSM). Back then, that was not a popular thing to ask for, the response was "this only has theoretical merits..." - 3+ years later, this is what people are looking into now :D

So being consistent really is a painful thing unfortunately, because it means more work, less time for interesting stuff, much more networking - and the outcome may still be uncertain, and it may cause frustration among contributors, too.

For instance, when one aircraft developer came up with the new NavDisplay code, we had been talking with Zakalawe about doing kinda that as part of the map dialog - and I was pretty frustrated seeing code that was more complete than mine, but on the other hand much less generic (not as re-usable), i.e. it being aircraft-specific, single instance, single style, too slow etc

And raising my concerns, the 747 developer was the one saying "not a high priority for me" and next: "but, ok be my guest" (which is very common around here!).

So that's how the whole shebang got split up into ~20 different modules, introducing a plethora of regressions/bugs (that he gratefully ignored!), slowing down his progress and overall development by at least 6 months in the process, and introducing a degree of complexity, so that the original developer no longer felt responsible for the modified code, or even refused to work with it afterwards :D

As you can imagine, this sort of thing really is a painful process for all parties involved. Actually, it's a miracle that Gijs & Hyde are still talking to us :lol:

Next, it was Philosopher reviewing my stuff and "politely disagreeing" with my way of doing things, rewriting much of it to make it much more generic :D And in the process, we then even learned that the extra500 developers had been working on a much more complete system for almost 6 months, long before our system was even designed/prototyped, but it too, suffered from being specific to a single aircraft and use-case.

So, all the while we'd been trying to be more consistent, and then that - and looking at the extra500 commit history, we're apparently having a hard time inviting them to be more consistent by adopting our framework now.

And that's what kinda everybody is going through here - Thorsten also mentioned various times that it would be so much easier to just code his own stuff than having to maintain compatibility with other/similar or even conflicting features (e.g. basic weather/rembrandt).

It really is hard to understand why we should accept such issues without being also paid for all the frustration resulting from all this

Honestly, consider this a freakin' petri-dish in which software evolution simply takes place and you'll have a much better time
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: scaling instruments in xml

Postby flyingfisch » Wed May 14, 2014 11:25 pm

Just one little thing that would be nice is if FlightGear had an official indent... And even if it didn't, people can still manually fix indents they copy/paste into their programs.
Beechcraft A35 Bonanza
Wiki Page
GitHub Repo
Improving the 737-300
Forum Thread
All my projects
User avatar
flyingfisch
 
Posts: 306
Joined: Mon Oct 07, 2013 1:11 pm
IRC name: ffisch
Version: 3.0
OS: Ubuntu 12.04

Re: scaling instruments in xml

Postby Hooray » Wed May 14, 2014 11:33 pm

what do you mean ? coding conventions ? formatting guidelines ?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: scaling instruments in xml

Postby flyingfisch » Wed May 14, 2014 11:41 pm

Yes, coding conventions, just to make code readable. I use 4 space indents, not necessarily saying everyone has to, but it would be nice to try to be consistent within a file or project. For instance, the pa24's FDM:

Code: Select all
<airplane mass="1742.9">

<!-- Approach configuration -->
<approach speed="55" aoa="14" fuel="0.6">  <!-- 55 -->
  <control-setting axis="/controls/engines/engine[0]/throttle" value="0.4"/>  <!--0.2-->
  <control-setting axis="/controls/engines/engine[0]/mixture" value="1.0"/>
  <control-setting axis="/controls/engines/engine[0]/propeller-pitch" value="1.0"/>
  <control-setting axis="/controls/flight/flaps" value="1.0"/>
  <solve-weight idx="0" weight="170"/>
  <solve-weight idx="1" weight="170"/>
  <solve-weight idx="2" weight="100"/>
  <solve-weight idx="3" weight="100"/>
  <solve-weight idx="4" weight="115"/>
</approach>

<!-- Cruise configuration -->
<cruise speed="156" alt="9000" fuel="1.0">
  <control-setting axis="/controls/engines/engine[0]/throttle" value="1.0"/>
  <control-setting axis="/controls/engines/engine[0]/mixture" value="0.6"/>
  <control-setting axis="/controls/engines/engine[0]/propeller-pitch" value="0.8"/>
  <control-setting axis="/controls/flight/flaps" value="0.0"/>
  <solve-weight idx="0" weight="170"/>
  <solve-weight idx="1" weight="170"/>
  <solve-weight idx="2" weight="100"/>
  <solve-weight idx="3" weight="100"/>
  <solve-weight idx="4" weight="115"/>
</cruise>

<cockpit x="-2.03" y="0.26" z="0.58"/>

<!-- Cowl & Windshield-->
<fuselage ax="0" ay="0" az="-0.145" bx="-2.1" by="0" bz="0"
          width="1.16" taper="0.4" midpoint="1"/>

<!-- Cabin -->
<fuselage ax="-2.1" ay="0" az="-0.59" bx="-4.06" by="0" bz="0"
          width="1.16" taper="0.97" midpoint="0"/>

<!-- Tail cone -->
<fuselage ax="-4.06" ay="0" az="0" bx="-7.25" by="0" bz="0.29"
          width="1.125" taper="0.258" midpoint="0"/>

<wing x="-2.97" y="0.58" z="-0.58" taper="0.538" incidence="1.05" twist="-2"
      length="5.01" chord="1.89" sweep="0" dihedral="5" camber="0.1" idrag="1.05">
  <stall aoa="16" width="1.0" peak="1.5"/>
  <flap0 start="0" end="0.58" lift="1.4" drag="1.5"/>
  <flap1 start="0.58" end="0.98" lift="1.2" drag="1.1"/>
  <control-input axis="/controls/flight/flaps" control="FLAP0"/>
  <control-speed control="FLAP0" transition-time="5"/>
  <control-input axis="/controls/flight/aileron_in" control="FLAP1" split="true"/>
  <control-input axis="/controls/flight/aileron-trim" control="FLAP1" split="true"/>
  <control-output control="FLAP0" prop="/surface-positions/flap-pos-norm"/>
  <control-output control="FLAP1" side="left"
        prop="/surface-positions/left-aileron-pos-norm"/>
  <control-output control="FLAP1" side="right"
        prop="/surface-positions/right-aileron-pos-norm"/>
</wing>

<hstab x="-7.18" y="0.15" z="0.22" taper="0.57" effectiveness="2.0" incidence="0"
       length="1.92" chord="1.02" sweep="3.23">
  <stall aoa="16" width="4" peak="1.5"/>
  <flap0 start="0" end="1" lift="2.0" drag="1.1" effectiveness="2"/>
  <control-input axis="/controls/flight/elevator_in" control="FLAP0"/>
  <control-input axis="/controls/flight/elevator-trim" control="FLAP0"/>
  <control-output control="FLAP0" prop="/surface-positions/elevator-pos-norm"/>
</hstab>

<vstab x="-6.68" y="0" z=".36" taper=".556"
       length="1.6" chord="1.3" sweep="26.6"> <!-- effectiveness="2"-->
  <stall aoa="14" width="3" peak="1.5"/>
  <flap0 start="0" end="1" lift="1.5" drag="1.2"/>
  <control-input axis="/controls/flight/rudder" control="FLAP0" invert="true"/>
  <control-input axis="/controls/flight/rudder-trim" control="FLAP0" invert="true"/>
  <control-output control="FLAP0" prop="/surface-positions/rudder-pos-norm"
        min="1" max="-1"/>
</vstab>

  <!--  Lycoming O-540-A  -->
  <propeller radius="1"
   cruise-speed="131" cruise-rpm="2400"
   cruise-alt="15000" cruise-power="113"
   takeoff-power="250" takeoff-rpm="2575"
   x="0.0" y="0.0" z="0.0" mass="600" moment="6"
   min-rpm="800" max-rpm="2575"
        fine-stop="1.0" coarse-stop="4.0" >
    <piston-engine eng-rpm="2575" alt="0" eng-power="250"
     displacement="541.5" compression="8.5"/>
    <actionpt x="0.0" y="0.0" z="0.0" />
    <control-input control="THROTTLE" axis="/controls/engines/engine[0]/throttle" />
    <control-input control="STARTER" axis="/controls/engines/engine[0]/starter" />
    <control-input control="MAGNETOS" axis="/controls/engines/engine[0]/magnetos" />
    <control-input control="MIXTURE" axis="/controls/engines/engine[0]/mixture" />
    <control-input control="ADVANCE" axis="/controls/engines/engine[0]/propeller-pitch"/>
  </propeller>
 

<gear x="-1.1090" y="0" z="-1.2318" compression=".15" sfric="0.9" dfric="0.8"
  spring=".6" retract-time="5"> <!-- nose -->
  <control-input axis="/controls/flight/rudder" control="STEER"
                 src0="-1.0" src1="1.0"
                 dst0="-0.1" dst1="0.1"/>
  <control-input axis="/controls/gear/gear-down" control="EXTEND"/>
  <control-speed control="EXTEND" transition-time="5"/>
  <control-output control="EXTEND" prop="/gear/gear[2]/position-norm"/>
</gear>


<gear x="-3.076" y="1.51" z="-1.165" compression=".2" sfric="0.9" dfric="0.8"
  spring=".6" retract-time="5"> <!--  -1.17 left main -->
  <control-input axis="/controls/gear/brake-left" control="BRAKE" split="true"/>
  <control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/>
  <control-input axis="/controls/gear/gear-down" control="EXTEND"/>
  <control-speed control="EXTEND" transition-time="4.2"/>
  <control-output control="EXTEND" prop="/gear/gear[0]/position-norm"/>
</gear>

<gear x="-3.076" y="-1.51" z="-1.165" compression=".2" sfric="0.9" dfric="0.8"
  spring=".6" retract-time="5"> <!--  -1.17 right main -->
  <control-input axis="/controls/gear/brake-right" control="BRAKE" split="true"/>
  <control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/>
  <control-input axis="/controls/gear/gear-down" control="EXTEND"/>
  <control-speed control="EXTEND" transition-time="4"/>
  <control-output control="EXTEND" prop="/gear/gear[1]/position-norm"/>
</gear>

<!-- Fuel  -->
 
  <tank x="-2.31" y="-1.16" z="-0.479" capacity="168" />
  <tank x="-2.44" y="-2.32" z="-0.377" capacity="90" />
  <tank x="-2.44" y="2.32" z="-0.377" capacity="90" />
  <tank x="-2.31" y="1.16" z="-0.479" capacity="168" />

<ballast x="-7.0" y="0" z=".22" mass="-250"/> <!-- Move CG forward -->

<!-- Pilot, copilot, left passenger, right passenger, baggage -->
<weight x="-2.17" y=".33" z="0" mass-prop="/sim/weight[0]/weight-lb"/>
<weight x="-2.17" y="-.33" z="0" mass-prop="/sim/weight[1]/weight-lb"/>
<weight x="-3.04" y=".33" z="0" mass-prop="/sim/weight[2]/weight-lb"/>
<weight x="-3.04" y="-.33" z="0" mass-prop="/sim/weight[3]/weight-lb"/>
<weight x="-3.64" y="0" z="0" mass-prop="/sim/weight[4]/weight-lb"/>

</airplane>


For one thing, the weights and ballasts should be indented like the rest of <airplane>'s children. Not putting anyone down, it's just that I noticed that a lot of FG code is hard to read.

EDIT:

Actually, looking at that again I see that none of <airplane>'s children are indented except the <tank> tags. Seems like either it should all be indented, or none.
Beechcraft A35 Bonanza
Wiki Page
GitHub Repo
Improving the 737-300
Forum Thread
All my projects
User avatar
flyingfisch
 
Posts: 306
Joined: Mon Oct 07, 2013 1:11 pm
IRC name: ffisch
Version: 3.0
OS: Ubuntu 12.04

Re: scaling instruments in xml

Postby Philosopher » Wed May 14, 2014 11:45 pm

BTW: forum doesn't keep indentation well ;) (particularly with tabs).
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: scaling instruments in xml

Postby flyingfisch » Wed May 14, 2014 11:52 pm

Philosopher: the indents in the file itself are exactly the same. Those are not tabs. ;)
Beechcraft A35 Bonanza
Wiki Page
GitHub Repo
Improving the 737-300
Forum Thread
All my projects
User avatar
flyingfisch
 
Posts: 306
Joined: Mon Oct 07, 2013 1:11 pm
IRC name: ffisch
Version: 3.0
OS: Ubuntu 12.04

Re: scaling instruments in xml

Postby Hooray » Wed May 14, 2014 11:55 pm

I tend to use a handful of different editors, depending on the computer I am at - and as Philosopher can confirm, formatting isn't exactly my strongest skill, I usually just see the mess when I view things later on :D
But there've been many attempts at establishing coding/formatting/styling guidelines, but it's kinda pointless unless contributors come up with those rules and actually comply with them.
Understandably, nobody likes having to go through the hassle for reformatting/re-styling stuff. And such requirements cannot be realistically imposed by just a single person. Those need to be agreed upon by people who actually make those commits. We don't exactly have a lot of manpower here - so alien ati ng pe op le due to bad formatting isn't gonna he lp Us

PS: There were roughly half a dozen of "issue trackers" suggested and implemented until ONE (the google one) got adopted - not because someone external suggested doing so, but because people agreed to actually use it
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: scaling instruments in xml

Postby flyingfisch » Thu May 15, 2014 12:08 am

Ah ok, gotcha. XML files can be automagically indented/reformatted, you know. ;)
Beechcraft A35 Bonanza
Wiki Page
GitHub Repo
Improving the 737-300
Forum Thread
All my projects
User avatar
flyingfisch
 
Posts: 306
Joined: Mon Oct 07, 2013 1:11 pm
IRC name: ffisch
Version: 3.0
OS: Ubuntu 12.04

Re: scaling instruments in xml

Postby Stiglr » Sat May 17, 2014 3:41 pm

Hey, flyingfisch,

What is that solve-weight code for? just curious...
Stiglr
 
Posts: 67
Joined: Thu Nov 03, 2011 3:53 pm

Re: scaling instruments in xml

Postby flyingfisch » Sun May 18, 2014 2:56 am

THe Pa-24 YASim file.
Beechcraft A35 Bonanza
Wiki Page
GitHub Repo
Improving the 737-300
Forum Thread
All my projects
User avatar
flyingfisch
 
Posts: 306
Joined: Mon Oct 07, 2013 1:11 pm
IRC name: ffisch
Version: 3.0
OS: Ubuntu 12.04

Previous

Return to Cockpit development

Who is online

Users browsing this forum: No registered users and 1 guest