Board index FlightGear Development Aircraft Cockpit development

scaling instruments in xml

Discussion about creating 2d and 3d cockpits.

scaling instruments in xml

Postby flyingfisch » Sun May 11, 2014 12:29 am

is it possible to scale an instrument using only xml?
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 2:11 pm
IRC name: ffisch
Version: 3.0
OS: Ubuntu 12.04

Re: scaling instruments in xml

Postby Hooray » Sun May 11, 2014 3:27 am

yes it is, see for example $FG_ROOT/README.xmlpanel
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: scaling instruments in xml

Postby AndersG » Sun May 11, 2014 10:24 am

If it is a 3d instrument (rather than a 2D panel instrument) I think you'll need to insert a scale animation that uses a 0 property and fixed offsets to scale the instrument model.

I have an example from my type UB I submarine that scales a 3d instrument without changing any of the instrument's files. To do that I use the overlay element for model inclusion in 3d XML files.
The element index of the animation is set to a high number so that the animation ends up last among the instrument's animations and since it leaves out the object-name elements the animation applies to the whole instrument.

Code: Select all
 <model>
  <name>CR magnetic compass</name>
  <path>Aircraft/Nordstern/Instruments/MagneticCompass/compass.xml</path>
  <offsets>
   <!-- x/y/z == back/right/up -->
   <x-m>11.08</x-m>
   <y-m>-0.20</y-m>
   <z-m> 0.43</z-m>
  </offsets>
  <overlay>
   <animation n="100">
    <type>scale</type>
    <property>constants/zero</property>
    <x-offset>0.7</x-offset>
    <y-offset>0.7</y-offset>
    <z-offset>0.7</z-offset>
   </animation>
  </overlay>
 </model>
Callsign: SE-AG
Aircraft (uhm...): Submarine Scout, Zeppelin NT, ZF Navy free balloon, Nordstern, Hindenburg, Short Empire flying-boat, ZNP-K, North Sea class, MTB T21 class, U.S.S. Monitor, MFI-9B, Type UB I submarine, Gokstad ship, Renault FT.
AndersG
 
Posts: 2524
Joined: Wed Nov 29, 2006 10:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: scaling instruments in xml

Postby flyingfisch » Sun May 11, 2014 5:02 pm

Thanks AndersG, that worked :)
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 2:11 pm
IRC name: ffisch
Version: 3.0
OS: Ubuntu 12.04

Re: scaling instruments in xml

Postby Stiglr » Tue May 13, 2014 5:20 am

Man, talk about overcomplicated. This language doesn't have a simple scale modifier for an object that doesn't require War and Peace?
Stiglr
 
Posts: 67
Joined: Thu Nov 03, 2011 4:53 pm

Re: scaling instruments in xml

Postby Gijs » Tue May 13, 2014 8:01 am

There is: http://wiki.flightgear.org/Howto:Animate_models#Scale (the second example works nicely if your instrument is in a separate file, or grouped into one object-name)
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9544
Joined: Tue Jul 03, 2007 3:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: scaling instruments in xml

Postby Stiglr » Tue May 13, 2014 4:38 pm

That's quite a bit tidier, if still a bit verbose. It'd make much more sense to simply allow a set of "size" description lines in the section that initially describes an object: it's name, references to it's component files, it's location/rotation/position, then its size.

Odd also that it's listed as an "animation"... when really it's just describing a "state" (provided you don't actually want the size to *change* during flight :D )
Stiglr
 
Posts: 67
Joined: Thu Nov 03, 2011 4:53 pm

Re: scaling instruments in xml

Postby Hooray » Tue May 13, 2014 4:50 pm

Stiglr wrote in Tue May 13, 2014 4:38 pm:That's quite a bit tidier, if still a bit verbose. It'd make much more sense to simply allow a set of "size" description lines in the section that initially describes an object: it's name, references to it's component files, it's location/rotation/position, then its size.


This is true, this is exceptionally wasteful XML, but that's for a reason - because of FlightGear's central nervous system, aka its "property tree".
It doesn't make sense to make such suggestions - except of course your point is proving that you have never looked at our docs and don't understand where all the FlightGear flexibility comes from (hint: 90% of our data are properties, as in run-time inspectable state variables)

Technically you are right as long as XML markup is viewed in isolation, but once it is viewed in combination with the FG environment, this very verbosity is by design. Others have tried to work around some issues, which alienated key contributors (property vectors). So better not discuss this here :D

There's a lovely explanation at: http://wiki.flightgear.org/PropertyList ... tion_files
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: scaling instruments in xml

Postby Bomber » Tue May 13, 2014 9:03 pm

Stiglr wrote in Tue May 13, 2014 4:38 pm:That's quite a bit tidier, if still a bit verbose. It'd make much more sense to simply allow a set of "size" description lines in the section that initially describes an object: it's name, references to it's component files, it's location/rotation/position, then its size.


Look at the code again....

<model>
<name>CR magnetic compass</name>
<path>Aircraft/Nordstern/Instruments/MagneticCompass/compass.xml</path>
<offsets>
<!-- x/y/z == back/right/up -->
<x-m>11.08</x-m>
<y-m>-0.20</y-m>
<z-m> 0.43</z-m>
</offsets>
<overlay>
<animation n="100">
<type>scale</type>
<property>constants/zero</property>
<x-offset>0.7</x-offset>
<y-offset>0.7</y-offset>
<z-offset>0.7</z-offset>
</animation>
</overlay>
</model>

Stiglr wrote in Tue May 13, 2014 4:38 pm:t: it's name,


Code: Select all
  <name>CR magnetic compass</name>


Stiglr wrote in Tue May 13, 2014 4:38 pm: references to it's component files,


Code: Select all
  <path>Aircraft/Nordstern/Instruments/MagneticCompass/compass.xml</path>


Stiglr wrote in Tue May 13, 2014 4:38 pm: it's location


Code: Select all
  <offsets>
   <!-- x/y/z == back/right/up -->
   <x-m>11.08</x-m>
   <y-m>-0.20</y-m>
   <z-m> 0.43</z-m>
  </offsets>


Stiglr wrote in Tue May 13, 2014 4:38 pm: it's rotation


Can be added but isn't used, so it's not shown

Stiglr wrote in Tue May 13, 2014 4:38 pm: then its size.


Code: Select all
  <overlay>
   <animation n="100">
    <type>scale</type>
    <property>constants/zero</property>
    <x-offset>0.7</x-offset>
    <y-offset>0.7</y-offset>
    <z-offset>0.7</z-offset>
   </animation>
  </overlay>


Frankly I thinks it's brilliant.... although it aint collada

Simon
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1933
Joined: Fri Dec 14, 2007 8:06 pm
OS: Windows XP and 10

Re: scaling instruments in xml

Postby Hooray » Tue May 13, 2014 9:09 pm

he was probably referring to using XML "properly", i.e. through XML attributes - which we really only use for certain internal stuff, but which are otherwise unused, we typically have to use quite a few extra nodes (tags) so that things show up in the property tree and can be easily processed.

Anybody familiar with XML or other data formats will agree that the FG PropertyList-XML format is very "wasteful" (even professional developers or XML experts like the property tree designer himself say so!), but the alternative would be having possibly dozens of different file formats for FG files - whereas we currently support PropertyList XML very widely (>=95% of our plain text config files probably). The main problem these days is not the verbosity, but the free-form nature of those files, and the lack of versioning - as well as the fact that they're all having the same basic PropertyList-structure but may very well "support" hugely different features, because each is implemented/processed by a different subsystem.

This has already caused quite some irritation among core developers ...

It's like having a trillion phone books in Japanese in fgdata, and dozens of translators who all interpret those Japanese words very differently ... and people think that they know the format, despite really only knowing the meaning within a certain context.

And it really isn't helping that anybody working with such data is not looking at existing interpretation-mechanisms but comes up with their own parsing/processing code - which is why stuff like conditions (SGCondition) or PID/PropertyRules really only work within certain contexts. That also applies to Nasal scripts that's really only supported in some XML files such as GUI, joystick, scenery (all implemented separately) - whereas it's unsupported in other -potentially useful- places, such as for example generic protocol files :?

All of this is also the reason why there's no editors with proper syntax highlighting for FG's XML files, i.e. those DTDs/schemas would be hard to maintain, because things may be valid and invalid at the same time - without this being obvious at all.

Admittedly, it really is a huge mess, but probably fairly accessible to the layman.

Accessibility really was the main motivation for coming up with XML here - i.e. all those binary MSFS/XP formats were a PITA for other reasons :D

We would be in great shape if this had ever been standardized so that useful constructs would be more widely supported in similar files, and certain problems wouldn't even exist.
But we're a really chaotic bunch of volunteers - and whenever tries to force something onto someone, that someone is likely to abandon the project for a while, or even for good ;-)
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: scaling instruments in xml

Postby Bomber » Wed May 14, 2014 5:55 pm

it's too easy to get into another argument here......

It becomes a problem when potential new developers are faced with a steeper learning curve due to this inconsiderate coding..
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1933
Joined: Fri Dec 14, 2007 8:06 pm
OS: Windows XP and 10

Re: scaling instruments in xml

Postby Hooray » Wed May 14, 2014 6:31 pm

Not disagreeing, in fact you are 100% right - but the thing is that consistency is a b*tch to get "right" :D

There are obvious areas like backward compatibility where consistency would help us a great deal.

But being consistent takes a great deal of work, not just in your own working areas, but especially in other areas that you have never touched.
Being consistent takes a lot of time, dedication, discipline and skill and a ton of networking. And it really isn't fun at all :D

We have an infinite number of examples for this being the case in FlightGear. It's not just our lack of standardized XML processing.
The whole MP/MMO debate is basically about the same thing - competing/conflicting features that never got updated and integrated, so that they end up crippling each other.
And we end up having a dozen way to "skin a cat" semi-properly :D

Being consistent means that "coding" (or even 3D modeling or developing FDMs) is suddenly no longer "just" about your own work, but looking at all the other places and potential use-cases in FlightGear that may benefit from it, including stuff that you never used, and never intend to use yourself.

To see for yourself, just ask yourself if any of your recent work (textures, 3D models, livery packs, FDMs, FDM components, autopilots, scripts, instruments or aircraft) can be easily used outside the context/scope that you designed them for originally ?
For instance, how easily can your aircraft:
  • support being used by the AI traffic system ?
  • support different liveries, liveries over MP ?
  • dual-pilot use across multiplayer ?
  • the weight& balance dialog ?
  • the replay/flight recorder subsystem ?
  • checklists ?
  • autopilot dialog ?
  • the bombable addon ?
    ...

These are all features in existence today that could be supported by aircraft developers - but most contributors only really scratch their own itch understandably :D
And that's really just the non-coding side of things - for programmers, pulling off consistent designs is often even more difficult.

As a coder, you permanently need to re-evaluate your own design and look at other/similar features, and see how those affect each other potentially - and be willing to modernize and re-implement certain stuff.

There's stuff like our networking stack, and the I/O system, along with its generic protocol system - and a httpd/telnet system, and of course the multiplayer system. All of this came into existence at different times - so are hardly integrated, even though they're sharing almost identical requirements, and could be re-implemented on top of 3-5 building blocks probably.

The Canvas/MapStructure work is another example for this: for over a decade, we've had various hard-coded instruments, a hard-coded GUI library, and certain 2D rendering code that could only be used within a fixed context, like 1) cockpit, 2) GUI, 3) scenery. It's only recently -thanks to canvas- that this is being unified and re-implemented, to hopefully get rid of a plethora of legacy features and modernize them through canvas and scripting space wrappers.

Previously, people could not render an instrument/HUD in a dialog, or vice versa - yet, this is a key feature, because supporting recursion means that even features like interactive map editors can share the same back-end code.

Today, just the MapStructure framework is under 1k lines of code, and is making roughly 9k-15k lines of C++ code obsolete in FlightGear (agradar,groundradar,wxradar,map dialog), unifying the whole shebang in the process, which also ensures that more modern OSG/OpenGL can be used, i.e. better performance in the long-term.

This all has taken place in under 24 months actually (MapStructure just being 6 months old now actually) - whereas hard-coded instruments (wxradar, agradar, navdisplay,kln89 etc) are usually 5+ years old, and things like the Map dialog even older - in comparison, these were all "easier" to come up with in the first place, but obviously don't scale as well as a Canvas-based solution. Gijs NavDisplay framework is already better accessible and more feature-rich than the original ND code.

But this kind of work isn't exactly fun, it comprises lots of refactoring and is more about talking and coordinating things than actually coding stuff - because the implementation may very well just be a fraction the size of all the manifestations that are hopefully replaced over time.

To a similar degree, this is also what all the work on HLA is all about: increasing consistency (concurrency, distribution & multiplayer) , but it's taking time, as can be seen :D

So far, Canvas/MapStructure have helped make 2D maps available for all needs in FlightGear, and a canvas/Nasal-based parser that processes our existing GUI dialogs/HUDs or 2D panels code would have the same benefits (GUI: 10k, HUD:3k, 2D panels:4k). Generic canvas/Nasal framework for each of those would probably also be under 4k in total. But it is so much easier being NOT consistent.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: scaling instruments in xml

Postby Bomber » Wed May 14, 2014 7:23 pm

I'm sorry but after over 3 years of being active here I don't have a clue as to what would make an FDM compatible with those things...

I've set myself a goal of doing flight models that have a high fidelity of damage integration on the aerodynamics side... but I've no idea what a weights and balance dialogue here is either and bombable is a complete mystery.
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1933
Joined: Fri Dec 14, 2007 8:06 pm
OS: Windows XP and 10

Re: scaling instruments in xml

Postby Hooray » Wed May 14, 2014 7:30 pm

Never mind, you picked an example that makes sense to question - but you don't just create FDMs, right - there's also lots of other aircraft-related stuff where those questions apply, and are easy to understand ;-)

BTW: a reusable FDM would for example be split into separate components/files and could be included/parameterized for use by different people/aircraft/systems. And yes, it would provide a mechanism to allow FG to modify W&B parameters. So while the question may primarily have theoretical merits, this doesn't mean by any means that "certain developers" are not subject to the same rules here ;-)

It's a part of the system unfortunately, and we're all contributing to this mess - but most people really only realize that once they're affected by work done by others, instead of questioning their own works, and how it may affect others and their projects.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: scaling instruments in xml

Postby Stiglr » Wed May 14, 2014 10:16 pm

Great explanations, Hooray! I'm sure we're *all* guilty as charged.

But, I can certainly hear myself also speaking from Bomber's exasperated POV just as well. And, because the community so embraces the Open System method, it's difficult, if not impossible to rein anything in, because no one is making (or even sees any value in making) any of the hard decisions regarding compatibility, quality standards, compliance, interoperability, etc., etc. The lack of cohesion and vision have a detrimental effect that is profound... but it seems it is tolerated as simply "part and parcel of Open System".

I often say that this open system "design" is a distinctly double edge sword. It has as many pitfalls as it does benefits.
Stiglr
 
Posts: 67
Joined: Thu Nov 03, 2011 4:53 pm

Next

Return to Cockpit development

Who is online

Users browsing this forum: No registered users and 2 guests