Board index FlightGear Development Aircraft Cockpit development

Glider instrumentation

Discussion about creating 2d and 3d cockpits.

Re: Glider instrumentation

Postby zakalawe » Thu Oct 24, 2013 12:12 pm

Two comments:

-if there's not a property which is the elapsed simulated time (and I feel like it exists, but I can't find it), adding one is two minutes work. Easiest if you send an email to the developer list saying what you need / proposed property location, I think.

- timers firing immediately seems like a bug, a small test case would be interesting. It depends which timer system you're talking about, however. (settimer vs timer objects) Please add the report and test-case to the bug tracker and CC me.

(Related to this, anything which depends on the simulation delta-time variables must tolerate those being 0.0, because there are many scenarios which can cause the dt interval from a frame/update to be zero. That's different to a timer firing after a zero interval of course)
zakalawe
 
Posts: 1258
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Glider instrumentation

Postby Gijs » Thu Oct 24, 2013 12:18 pm

zakalawe wrote in Thu Oct 24, 2013 12:12 pm:if there's not a property which is the elapsed simulated time (and I feel like it exists, but I can't find it)

/sim/time/elapsed-sec ;-)
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9376
Joined: Tue Jul 03, 2007 2:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Glider instrumentation

Postby Philosopher » Thu Oct 24, 2013 12:42 pm

In that case, the class doesn't need to keep track of speed-up ;). (it already uses /sim/time/elapsed-sec)
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1588
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: Glider instrumentation

Postby galvedro » Thu Oct 24, 2013 12:53 pm

Aha! Now understand your point regarding listener references. Some thoughts on that:

There are roughly 300K lines of Nasal code in the Aircraft folder alone :shock:

Code: Select all
$ find ./Aircraft -name *.nas -exec cat {} \; | sed -e '/^\s*$/d' | sed -e '/^\s*#/d' | wc -l
289908


If I understood correctly, a (big?) portion of that code is written by people that do not have formal training in programming, and it is difficult enough to write leak free software even for trained people. In this context, any approach to the resource management problem that expects scripting code to follow any standard is doomed to fail. (Sorry if I sound a bit radical :D).

So any alternative must then rely in the core for resource tracking and cleanup. With that in mind, my personal opinion is that it would be better to keep scripts as simple as possible, and that would include leaving such resource cleanups to the framework itself (by design).
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 12:55 pm
Location: Sweden

Re: Glider instrumentation

Postby galvedro » Thu Oct 24, 2013 1:00 pm

Gijs wrote in Thu Oct 24, 2013 12:18 pm:/sim/time/elapsed-sec ;-)

If that is the property, then there is a bug. It honors "pause" but it always grows at "speed-up = 1", regardless of speed-up setting.

edit: fixing the quote
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 12:55 pm
Location: Sweden

Re: Glider instrumentation

Postby Philosopher » Thu Oct 24, 2013 1:04 pm

galvedro wrote in Thu Oct 24, 2013 12:53 pm:There are roughly 300K lines of Nasal code in the Aircraft folder alone :shock:


Apologies for hijacking such a fine topic/discussion, but would it be time to implement import()-like encapsulation and magikery to just pound down the iron fist and ensure that the scripts get taken down properly? :lol: (this would include copying the global namespace, so that the aircraft's warped version of reality can be taken down; overloading setlistener to automatically remove listeners once the aircraft disappears; etc.)
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1588
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: Glider instrumentation

Postby zakalawe » Thu Oct 24, 2013 1:07 pm

galvedro wrote in Thu Oct 24, 2013 12:53 pm:If I understood correctly, a (big?) portion of that code is written by people that do not have formal training in programming, and it is difficult enough to write leak free software even for trained people. In this context, any approach to the resource management problem that expects scripting code to follow any standard is doomed to fail. (Sorry if I sound a bit radical :D).

Not radical, I think most people would agree, I certainly do. And in most cases Nasal is not too bad for this, thankfully.

The revised reinit approach actually tears down and restarts all Nasal and most properties, so the situation becomes simpler - scripts only need to do the correct thing with normal startup, since that is all they will ever see. This assumes I get the new approach working of course, currently it kind-of-works but crashes due to dangling references to old properties. The tearing down Nasal part works fine already.
zakalawe
 
Posts: 1258
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Glider instrumentation

Postby galvedro » Sat Oct 26, 2013 10:37 pm

I have been working for a few days on the problem of loading the library cleanly, and after doing some experiments with io.load_nasal(), I decided to try and write a simplified interface for "embedding" a script into another.

I have uploaded a proposal for an io.include() to my gitorious repo. You will find this experiment on a separate branch called dev-include. Here is the push digest: https://gitorious.org/fg/galvedros-fgdata/commit/dca2852b38f03936771a5b16991509687b0ef7a6/diffs/dba64b3cff668eb3ce5948498da7afd0e4a93bdb

It's a simple tool for a simple purpose: loading (and running) a dependent script into the current namespace, so in essence, it is a simplified io.load_nasal(). This does not replace a proper import functionality, like the require() feature Philosopher is working on, but can be a useful tool for loading library modules into the aircraft´s namespace for example.

It works exactly like C includes do, there the name :D. It adds a marker symbol to the namespace that prevents duplicate loading. It has worked for C for more than 40 years, it should be fine for Nasal as well. But please let me know your thoughts, I was a bit reluctant to take that route right away without a second opinion from you guys.
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 12:55 pm
Location: Sweden

Re: Glider instrumentation

Postby Philosopher » Sun Oct 27, 2013 3:52 pm

Looks good to me! I will look into including something like this with my updates. I would suggest using string.normpath() in your code to have better path handling, especially when people start wanting to use backslashes in those paths :). Also, there's a resolvepath() helper (built into SimGear) which will allow the function to support more loading dirs and makes it in line with all other path usage. (You can of course keep the "calling script directory" in there, but just make sure it exists ^.^ – some "filenames" are actually things like "<compile>" (default) or "/nasal/a4f/file[2]" (aka a property tree path).)
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1588
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: Glider instrumentation

Postby Hooray » Sun Oct 27, 2013 4:06 pm

looks good to me, too - and it seems like we have somebody new here who could help with writing advanced Nasal coding tutorials :lol:
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: 12190
Joined: Tue Mar 25, 2008 8:40 am

Re: Glider instrumentation

Postby galvedro » Mon Oct 28, 2013 12:10 pm

Haha, good! Some wiki work will come, I promise! :D

I will clean the solution up incorporating the suggestions Philosopher made, and I think I am getting close to sending a merge request for a first drop. After that, I will start looking into generalizing/refactoring the framework so it can be reused for more general systems modeling. It would be useful for me to have a concrete example to work on, any suggestion?
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 12:55 pm
Location: Sweden

Re: Glider instrumentation

Postby Hooray » Mon Oct 28, 2013 2:39 pm

After that, I will start looking into generalizing/refactoring the framework so it can be reused for more general systems modeling. It would be useful for me to have a concrete example to work on, any suggestion?


Any well-developed electrical system would seem like a good reference - for example, the c172p is our "standard" aircraft, fairly well-developed, and does have a Nasal-based electrical system:

https://gitorious.org/fg/fgdata/source/ ... raft/c172p

See the Nasal sub folder there, and in particular: https://gitorious.org/fg/fgdata/source/ ... trical.nas
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: 12190
Joined: Tue Mar 25, 2008 8:40 am

Re: Glider instrumentation

Postby galvedro » Thu Oct 31, 2013 7:31 pm

I think the basic framework is ready for a first release. I have rebased to master in a separate branch for easy merging, and posted a merge request: https://gitorious.org/fg/fgdata/merge_requests/227

Let me know if you would like me to make any additional refinement :wink:
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 12:55 pm
Location: Sweden

Re: Glider instrumentation

Postby Bomber » Fri Dec 06, 2013 7:12 pm

Sorry for not replying been busy since Sept with new job, an operation, a building extension and a puppy...

Not known if I'm Arthur or Marther.

Will catch up by new year hopefully.
"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 7:06 pm
OS: Windows XP and 10

Re: Glider instrumentation

Postby shanmoon » Thu Jan 16, 2014 7:11 pm

galvedro wrote in Mon Oct 07, 2013 2:30 pm:Greetings!

I have been doing some work on glider specific instrumentation lately, and I thought it would be nice to drop a quick note here in the forums to let you know, and perhaps to get some feedback also. This is my first development for FlightGear, so I hope I am not reinventing the wheel!


Happy to see your post! I am new to FlightGear, and am considering it for a platform for soaring research, but there are a number of things present in some old soaring software (Condor & Silent Wings) not present in Flight Gear. Looks like you are working in the same space I was considering. Looking forward to see what you accomplish!
DG-300 Pilot
User avatar
shanmoon
 
Posts: 2
Joined: Thu Jan 16, 2014 1:38 am

PreviousNext

Return to Cockpit development

Who is online

Users browsing this forum: No registered users and 2 guests