Board index FlightGear Development New features

Red Griffin ATC - Speaking ATC addon for Flightgear

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Re: Red Griffin ATC - Speaking ATC addon for Flightgear

Postby Bjoern » Sat Jan 18, 2020 3:25 pm

I could have sworn I had replied to the previous post.

RedGriffin wrote in Fri Jan 17, 2020 8:35 pm:What should be done in these cases? To make sure no one is crossing a runway in case an airplane is taking off or landing?


I meant the runways themselves (= multiple runways that are NOT parallel), not traffic flow!
Runway usage as caused by wind speed and direction should be calculated for all available runways of an airport.

There is a property for that: /sim/atc/runway and, as far as I can tell, it defines the "default" operational runway at a specific condition. Sometimes it has a value and sometime it hasn't, even for the same airport at different times/moments.


I've checked it at ESSA and it never showed a value. Need to take a look into the source code to see how it is populated.
Bjoern
 
Posts: 449
Joined: Fri Jan 06, 2012 10:00 pm
Location: TXL or so
Version: Next
OS: ArchLinux, Win 10

Re: Red Griffin ATC - Speaking ATC addon for Flightgear

Postby RedGriffin » Sat Jan 18, 2020 8:37 pm

Bjoern wrote in Sat Jan 18, 2020 3:25 pm:I meant the runways themselves (= multiple runways that are NOT parallel), not traffic flow!
Runway usage as caused by wind speed and direction should be calculated for all available runways of an airport.

Sure! Red Griffin ATC evaluates all and each runway available in order to find the (hopefully) best one.

Bjoern wrote in Sat Jan 18, 2020 3:25 pm:I've checked it at ESSA and it never showed a value. Need to take a look into the source code to see how it is populated.

You are right. Sometimes it has a value and sometimes it is empty. I did not investigate how the value is computed and in what cases it is assigned a value.
Red Griffin - IK0TOJ
Author and developer of Red Griffin ATC - Enjoy my Youtube Channel
RedGriffin
 
Posts: 106
Joined: Tue Dec 25, 2018 7:04 pm
Location: Perugia, Italy
Callsign: IK0TOJ
Version: 2019.1.2
OS: Linux Fedora FC31

Re: Red Griffin ATC - Speaking ATC addon for Flightgear

Postby Hooray » Sun Jan 19, 2020 10:57 am

Bjoern wrote in Fri Jan 17, 2020 3:05 pm:
Hooray wrote in Thu Jan 16, 2020 9:09 pm:Again, feel free to post any Lua code you would like to execute in FlightGear, and we can have an informed discussion about your goals, by either showing you how to write the corresponding snippets in Nasal, by writing a converter to Nasal or even by writing a tiny DSL interpreter to turn Lua-ish code into valid Nasal syntax.

I'll take you up on the "translate Lua to Nasal" offer if necessary.



Feel free to start a new forum topic to see how certain Lua constructs (loops, conditionals, functions, classes) can be translated into Nasal.
If this should turn out to be fruitful, it would not be that much work to provide a script to dynamically interpret a subset of Lua and convert it into Nasal - and who knows, it might even pave the way to support for proper Lua support some day.

Personally, I have seen too many debates like these and rarely (if ever) this was actually about the language/syntax in question, but about the toolkit, platform, framework and tooling, available dependencies or documentation - which would still be a different beast even if we had Lua support right now, because a scripting interpreter running inside FlightGear inevitably has to face some pretty serious restrictions, unless it's designed to work across thread/process boundaries, i.e. outside the FlightGear main loop.
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: 11493
Joined: Tue Mar 25, 2008 8:40 am

Re: Red Griffin ATC - Speaking ATC addon for Flightgear

Postby RedGriffin » Sun Jan 19, 2020 11:15 am

Hooray wrote in Sun Jan 19, 2020 10:57 am:Personally, I have seen too many debates like these and rarely (if ever) this was actually about the language/syntax in question, but about the toolkit, platform, framework and tooling, available dependencies or documentation - which would still be a different beast even if we had Lua support right now, because a scripting interpreter running inside FlightGear inevitably has to face some pretty serious restrictions, unless it's designed to work across thread/process boundaries, i.e. outside the FlightGear main loop.

I do agree with you. I would rather like to have a better documentation about toolkit, library functions, framework and things like these instead of having a new scripting language support in Flightgear. Nasal is not bad and it is also a lightweight solution, it certainly has been a good choice also by considering the period in which it has been implemented in Flightgear and scripting languages around which could fit this need were not so much.
I admit I did not get into Nasal nor I ever used it before I started developing my Red Griffin ATC, but learning Nasal was the very least effort I had because, admittedly, it takes really a little to learn for anyone having a basic background in "modern programming". In the course of my 35 years career in software development and design - during which I used tens of different languages, from many assembly flavors to high abstraction level languages, from developing operating systems and system tools to games - languages count very little in a project, saved performance and construction aspects.
Nasal is not bad and, by considering how Flightgear works and was built, it turns to be a good choice. Moreover, it is very easy to learn and it does not take much effort to convert Lua code into Nasal. As far as I am concerned, the hardest part in developing Red Griffin ATC was not Nasal, indeed the documentation about the many libraries and tools.

Just my 2 cents.
Red Griffin - IK0TOJ
Author and developer of Red Griffin ATC - Enjoy my Youtube Channel
RedGriffin
 
Posts: 106
Joined: Tue Dec 25, 2018 7:04 pm
Location: Perugia, Italy
Callsign: IK0TOJ
Version: 2019.1.2
OS: Linux Fedora FC31

Re: Red Griffin ATC - Speaking ATC addon for Flightgear

Postby Hooray » Sun Jan 19, 2020 7:40 pm

Usually, it's fairly simple to extend the library by adding new extension functions: http://wiki.flightgear.org/Howto:Extend_Nasal

The other option is using an OOP API to expose classes and objects to scripting space (and vice versa): http://wiki.flightgear.org/Nasal/CppBind

I don't think there is much of a need to change anything when it comes to syntax, but even that's possible and pretty straightforward: Adding a new binary operator to Nasal.

Apart from that, there remains the option to add an entirely new subsystem to FlightGear: http://wiki.flightgear.org/Howto:Create_new_subsystems

Speaking in general, creating a wiki page that details how to convert Lua or Python to Nasal would be fairly straightforward.
Also, writing a simple toy interpreter to interpret some Lua-like language subset might actually be a fun little exercise, and could help people wanting to implement a DSL interpreter, e.g. for implementing their own ATC/adventure language without using Nasal directly.

Creating something like a BASIC dialect should take hardly more than 300 lines of Nasal code, and could actually become its own add-on that people can use to create new addons - if that's what people consider useful, e.g. for "adventure/mission addons".

Another option would be a DSL for piloting aircraft, so that this could be used to respond to ATC instructions, i.e. this could be used for all sorts of fancy adventures with AI pilots that actually respond to proper ATC instructions. Something like this could be kept pretty simple, but extensible so that people could add their own heuristics.

Having a tiny little DSL that is suitable to control airplanes/aircraft could be a fun little exercise, and could enormously boost FlightGear's AI world, by adding a ton of realism to 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: 11493
Joined: Tue Mar 25, 2008 8:40 am

Re: Red Griffin ATC - Speaking ATC addon for Flightgear

Postby wkitty42 » Sun Jan 19, 2020 11:22 pm

@hooray: DSL == Digital Signals Library ???
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5991
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Red Griffin ATC - Speaking ATC addon for Flightgear

Postby AndersG » Mon Jan 20, 2020 8:30 am

No, @wkitty42, in this case DSL == Domain Specific Language. (Which, in some sense, Nasal itself is mostly too.)
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: 2454
Joined: Wed Nov 29, 2006 9:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: Red Griffin ATC - Speaking ATC addon for Flightgear

Postby wkitty42 » Mon Jan 20, 2020 4:41 pm

ok, thanks... my other guess was Digital Subscriber Line :lol:
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5991
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Red Griffin ATC - Speaking ATC addon for Flightgear

Postby Bjoern » Tue Jan 21, 2020 12:42 am

Hooray wrote in Sun Jan 19, 2020 10:57 am:Feel free to start a new forum topic to see how certain Lua constructs (loops, conditionals, functions, classes) can be translated into Nasal.
If this should turn out to be fruitful, it would not be that much work to provide a script to dynamically interpret a subset of Lua and convert it into Nasal - and who knows, it might even pave the way to support for proper Lua support some day.

Personally, I have seen too many debates like these and rarely (if ever) this was actually about the language/syntax in question, but about the toolkit, platform, framework and tooling, available dependencies or documentation - which would still be a different beast even if we had Lua support right now, because a scripting interpreter running inside FlightGear inevitably has to face some pretty serious restrictions, unless it's designed to work across thread/process boundaries, i.e. outside the FlightGear main loop.


Adding an interpreter layer to an interpreter layer sounds just kind of inefficient to me. Might be more time efficient to deal with Nasal directly.
Of course there's gonna be questions like "I did this like that in Lua, how can I do it in Nasal?", but my non-computer science mind (I'm just a lowly mechanical engineer) thinks it's best to set up any scripting language interpreter as far down the core as possible to cover all the bases and threading and stuff, but doing that is outside of my skill and motivation. My only foray into C-space was mild improvements to an X-Plane plugin and even without having had to set up a compiler, I still have nightmares from all the pointers, variable types and declarations.
All I know is scripting ("been there, done that" in Batch, Bash, VBScript, Lua, MATLAB, PowerShell, MSFS XML), but I am completely useless without good documentation, examples and web searches. "Mainstream" languages like Lua have the advantages of wide application and therefor good availability of any of these things and that's where my daydream about Lua in FG (which I just can't make happen though) and, honestly enough, low-key fear of Nasal (which is obviously yet another scripting language to learn) originates from. A first look at the Nasal section of the Wiki at least left a somewhat positive impression, so there's that.
Bjoern
 
Posts: 449
Joined: Fri Jan 06, 2012 10:00 pm
Location: TXL or so
Version: Next
OS: ArchLinux, Win 10

Re: Red Griffin ATC - Speaking ATC addon for Flightgear

Postby Hooray » Tue Jan 21, 2020 3:20 pm

Actually, your point on having a low level implementation is absolutely spot-on. However, it's also premature optimization to worry about that for the time being.

Realistically, having an interpreter written in an interpreted language may seem far from perfect. But imagine for a second we python support implemented that way: while performance would certainly be not very impressive, we would at least accumulate experience what it means supporting a certain language/syntax, compared to "only" supporting Nasal.

In other words, the cost of implementing such an interpreter would be very low - and if performance should ever become a concern, the interpreter could be incrementally optimized or replaced over time.

As a matter of fact, it is fairly trivial to expose and access Nasal internals, such as the virtual machine (VM) running Nasal bytecode.

We have previously done that, and even documented the process in the form of tutorials and wiki articles, as well as a dedicated Nasal internals latex/PDF document.

So if someone is really eager to support python,lua, Javascript or Forth - this would be a straightforward approach to test the waters.


Like you clearly said now, you don't seem to want a certain language for technical reasons but primarily for its "mainstream" nature.

In reality, it's the design of flightgear that shapes what scripting looks like, much more so than any particular language, syntax or toolkit.

In general it's not a good idea to run a scripting interpreter inside the main loop at all.

Apart from that, let's face it: python is clearly more mainstream than Lua, yet you don't seem to be overly interested in python support, are you?

Which is to say, people familiar with coding will not be bothered by the choice of programming language - just like people with a driving license will not be bothered much by driving different types of cars
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: 11493
Joined: Tue Mar 25, 2008 8:40 am

Re: Red Griffin ATC - Speaking ATC addon for Flightgear

Postby Bjoern » Tue Jan 21, 2020 10:00 pm

Hooray wrote in Tue Jan 21, 2020 3:20 pm:Apart from that, let's face it: python is clearly more mainstream than Lua, yet you don't seem to be overly interested in python support, are you?


I've never dealt with Python. If it gets to be the new, hot thing for FG and better than Nasal ever was, there'll be not much reason not to learn it. But for all I've read, this is not the case yet so why bother...
Bjoern
 
Posts: 449
Joined: Fri Jan 06, 2012 10:00 pm
Location: TXL or so
Version: Next
OS: ArchLinux, Win 10

Re: Red Griffin ATC - Speaking ATC addon for Flightgear

Postby Hooray » Tue Jan 21, 2020 10:46 pm

Bjoern wrote in Tue Jan 21, 2020 10:00 pm:I've never dealt with Python. If it gets to be the new, hot thing for FG and better than Nasal ever was, there'll be not much reason not to learn it. But for all I've read, this is not the case yet so why bother...


Because Python support actually is a thing in FlightGear, i.e. we have working patches to make it happen - which beats any theoretical talks about supporting Lua, JavaScript etc
While functionality isn't yet up to par with Nasal obviously, the Python VM can already be executed inside FlightGear and it is possible to expose and access internals.
Given your mainstream focus, Python's "mainstream-ness" is hard to beat, even when it comes to Lua ;-)

Like RedGriffin said, language and syntax are hardly relevant in the given context, here's what a while loop looks like in Lua, versus its Nasal counterpart - which look familiar to anybody with a C-background in programming, whereas the Lua version will look more familiar to those who already know PASCAL, Ada or Delphi

Code: Select all
while( true )
do
   print("This loop will run forever.")
end


Code: Select all
while(1) {
   print("This loop will run forever.");
}
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: 11493
Joined: Tue Mar 25, 2008 8:40 am

Re: Red Griffin ATC - Speaking ATC addon for Flightgear

Postby Bjoern » Wed Jan 22, 2020 6:40 pm

Sorry Hooray, I remain unintrigued for now, regardless of Python's "mainstream" appeal.
Bjoern
 
Posts: 449
Joined: Fri Jan 06, 2012 10:00 pm
Location: TXL or so
Version: Next
OS: ArchLinux, Win 10

Re: Red Griffin ATC - Speaking ATC addon for Flightgear

Postby RedGriffin » Fri Jan 31, 2020 5:46 pm

Hello there!
In this period I have been very busy with my job so I could not work on my Red Griffin ATC that much, however I am about to release a new version very soon, hopefully this weekend.
Here it is the new functions and features of the 1.0.0 beta 3:

    • After take off, tower instructs the pilot to fly at runway heading at a specific altitude. It also suggests the pilot to tune to a "departure/approach" radio in case it is available in order to have CTR assistance.
    • Improved Take-off and landing runway determination by properly taking into consideration wind direction
    • Implementation of CTR transition:
      • Request permission to transit a CTR with a dedicated button.
      • ATC refuses to give support in case the aircraft is outside its CTR range or has no transit permission. In such cases ATC invites the pilot to ask for permission or to contact it when in range.
      • ATC warns the aircraft in case it is about to leave the CTR and informs about the neighboring CTR in case there is one in range. In this case ATC also instructs the pilot on new CTR's radio.
      • Pilot's requests to the ATC are now shown on the screen before the ATC responds to the request. Pilot's requests are shown in a popup and text is displayed in a different color than ATC's texts.
    • ATC warns the pilot in case the aircraft is flying too low in relation to terrain's real elevation.
    • ATC warns the pilot in case the aircraft is heading towards elevated terrain such as hills and mountains.

To be implemented and this should take little time:
    • While in a CTR and tuned to the proper radio, ATC will check the aircraft's assigned altitude and inform the pilot in case of significative change and warns the pilot to climb or descend to the assigned altitude. ATC may also require the pilot to change and assign a new altitude.

The beta 3 tests I am doing in my machine are very promising and I am quite happy with the result.

Personal remark: the more I use my Red Griffin ATC the more I believe it gives Flightgear a new "simulation level" and now I am so used to it I am always using it and cannot think about using Flightgear without starting this addon.
In other words - and in my very humble opinion - Red Griffin ATC gives me the idea and feeling I am having a better and more realistic experience than before. Just my opinion, of course, and I understand others may not agree with me.
I must also say that, if it is true Red Griffin ATC is providing (at least to me) this kind of experience, is also particularly thanks to all of you for all the valuable feedback, suggestions and hints you gave me in order to make this addon better and more functional.

Stay tuned, I will be releasing Red Griffin ATC 1.0.0 beta 3 very soon. :)

As usual, feedback, suggestions, hints and tests are very welcome and appreciated.
Red Griffin - IK0TOJ
Author and developer of Red Griffin ATC - Enjoy my Youtube Channel
RedGriffin
 
Posts: 106
Joined: Tue Dec 25, 2018 7:04 pm
Location: Perugia, Italy
Callsign: IK0TOJ
Version: 2019.1.2
OS: Linux Fedora FC31

Re: Red Griffin ATC - Speaking ATC addon for Flightgear

Postby Hooray » Sat Feb 01, 2020 11:11 am

RedGriffin wrote in Fri Jan 31, 2020 5:46 pm:To be implemented and this should take little time:
    • While in a CTR and tuned to the proper radio, ATC will check the aircraft's assigned altitude and inform the pilot in case of significative change and warns the pilot to climb or descend to the assigned altitude. ATC may also require the pilot to change and assign a new altitude.



Note that you can simply accept a "root property" to be monitored - that way, your code is prepared to also handle AI/MP traffic - which is to say that the same code could eventually be used to issue instructions to multiplayer/AI traffic. This is how rleibner's GCA plugin ended up using a property path to look for the correct /orientation, /position nodes:

http://wiki.flightgear.org/Howto:Implem ... GCA_system
Image

This may seem a little weird at first, but once your code is structured like that, you can also use it to monitor other traffic - e.g. the tanker (which is scripted). And once you are able to monitor such traffic, it's not that complicated to also make it respond to instructions issued by your virtual ATC controller.

Obviously, that part of the system would ideally become a separate addon, i.e. a scripted AI pilot that handles AI instructions in order to control an aircraft, and possibly a number of aircraft following flight plans/routing.

While that may take a while to work out, we do have a handful of examples doing this sort of thing, and an ATC addon able to handle property-based traffic, can directly be used in the Multiplayer environment, too
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: 11493
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to New features

Who is online

Users browsing this forum: MSN [Bot] and 1 guest