Board index FlightGear Development New features

Ships

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

Ships

Postby chrisb » Thu Aug 14, 2014 3:02 pm

The location and vector information of commercial ships is public information
They could dynamic added to the simulator

Image
Image

Could this be done using a nasal script?
chrisb
 
Posts: 136
Joined: Mon Oct 21, 2013 8:46 pm
Location: YLIL, YMML
Callsign: cnb123
Version: git
OS: Win7 64bit

Re: Ships

Postby Hooray » Thu Aug 14, 2014 3:38 pm

We've actually done this before, the information this is based provided by so called "AIS" systems: https://en.wikipedia.org/wiki/Automatic ... ion_System
What we've done, is extending the MP server (fgms) by adding support for feeding/injecting remote traffic data into the FG MP environment: http://wiki.flightgear.org/FGAIS
Image

In this screen shot, it's TCAS/ACARS data that is used, but it could just as well by some other data.

This all pre-dates the Canvas days - at a time when we had only support for fetching PropertyList-XML data via fgcommands: http://wiki.flightgear.org/Howto:Making ... from_Nasal

Meanwhile, we have support for fetching HTTP data via Nasal: http://wiki.flightgear.org/List_of_Nasa ... 2.99.2B.29
While a MP/fgms-based system would scale better (bandwidth-wise, but also to synchronize multiple fgfs instance concurrently), a pure Nasal version would definitely be possible.
It would be mainly about injecting AI traffic into FlightGear via the methods use by tanker.nas, fox2.nas or the bombable script:
Subject: Possibility to run a fully automatized mission ?

Hooray wrote:
Is it possible to make a complete automatized mission, from engine start to engine shutdown ?


Yes, it is possible "to make" such a mission - but you will literally have to MAKE it by writing a script to outline all required steps for your aircraft.
Curt did that a while back for the f14b, which did a fully automated carrier approach using just Nasal scripting:

http://diydrones.com/profiles/blogs/uas ... simulation
http://www.mail-archive.com/flightgear- ... 33987.html
http://www.flightgear.org/forums/viewto ... =4&t=13615


http://www.flightgear.org/tours/carrier-ops/

Another example is the "tanker.nas" script in $FG_ROOT which implements a simple scripted AI tanker for AAR purposes: http://flightgear.org/forums/search.php ... tanker.nas
http://www.mail-archive.com/search?q=ta ... eforge.net

And then we have the fox2.nas script which implements a fox2 AI missile using Nasal: http://flightgear.org/forums/search.php ... s=fox2.nas

The "bombable" addon is completely implemented in Nasal and created multiple virtual pilots for dogfighting purposes: http://wiki.flightgear.org/Bombable



Even without a lot of Nasal coding, you could use such data to populate a FlightGear instance via http + Nasal:
Subject: Populate AI Traffic with real traffic

Hooray wrote:
HJ1AN wrote in Thu May 15, 2014 10:27 am:That's a shame. It'd be great if there is an option to track just one or two flights though, and follow it around or formation flight


We now have HTTP client bindings available to Nasal, which basically means that you can process JSON/XML feeds directly from FG.
So you can download some live data, parse it and populate Nasal data structures.

so you can still do something like this with less than 50 lines of code - it would just be running locally obviously.

In fact, as a quick hack, you can simply use the MapStructure framework to do this: copy the TFC.lcontroller file and change its searchCmd() to run such a query regularly.
Rename the whole thing to "FEED.lcontroller" and change the name at the top of the lcontroller/symbol files

As long as you're adding a MapStructure-based instrument (e.g. Gijs' ND) to your aircraft (not just as a GUI dialog), that traffic feed will be regularly processed.
If in doubt, use the 747-400 or the 777-200

That alone would just make the traffic show up on your ND or map. But then it's roughly 5 lines of Nasal code to adapt the tanker.nas code to "inject" traffic into our AI system, coming from those MapStructure controllers - i.e. the searchCmd return result would be passed onto the AI system.

It's a hack, but not even an ugly one, and not even difficult - it involves under 50 lines of Nasal code in total, and you'll be able to parse arbitrary traffic feeds, even without fgms.
Technically, it would obviously be better to have one central server, rather than possibly dozens of clients doing that - but this will work,and it's not very much work either.


Obviously, such traffic would never be able to respond to the simulated world: http://wiki.flightgear.org/Status_of_AI_in_FlightGear
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: 11472
Joined: Tue Mar 25, 2008 8:40 am

Re: Ships

Postby chrisb » Thu Aug 14, 2014 5:43 pm

OK, uhhh
chrisb
 
Posts: 136
Joined: Mon Oct 21, 2013 8:46 pm
Location: YLIL, YMML
Callsign: cnb123
Version: git
OS: Win7 64bit

Re: Ships

Postby Hooray » Thu Aug 14, 2014 6:40 pm

Sorry if the response seems overwhelming at first - but at least it should contain the most relevant pointers that would help people to actually implement something like this. The method detailed at the end of the posting would be fairly simple actually, probably not much more than 50-100 lines of Nasal to prototype the whole thing - and the code could be moved to a separate file once things are working as expected. I do remember Stuart once expressing an interest in supporting vessel feeds eventually. So somebody tackling this would definitely not be left alone.
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: 11472
Joined: Tue Mar 25, 2008 8:40 am

Re: Ships

Postby chrisb » Fri Aug 15, 2014 2:14 pm

so you are saying, have a go at trying to implement real world ships into fgfs?
chrisb
 
Posts: 136
Joined: Mon Oct 21, 2013 8:46 pm
Location: YLIL, YMML
Callsign: cnb123
Version: git
OS: Win7 64bit

Re: Ships

Postby Hooray » Fri Aug 15, 2014 3:08 pm

chrisb wrote in Fri Aug 15, 2014 2:14 pm:so you are saying, have a go at trying to implement real world ships into fgfs?


sure, why not: the difficult part is finding the corresponding data/feeds - for everything else (http access, 3d models for vessels, Nasal code for adding & animating/updating AI objects), we already have plenty of code in various stages of completion, i.e. it's mostly a matter of integrating various snippets.
For starters, you could also just create a MapStructure layer to show vessels on a map (gui dialog or instrument) - the HTTP related code could then be fully reused, i.e. to inject AI models for each vessel within xx nm
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: 11472
Joined: Tue Mar 25, 2008 8:40 am

Re: Ships

Postby adrian » Fri Aug 15, 2014 3:13 pm

The oldest attempt that I am aware of belongs to Stuart. Then in 2010 I made a statically generated traffic file, which I had planned to animate using a mixture of C++ and Nasal. Never managed to finish that, but you can still find the code floating around.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: Ships

Postby Hooray » Fri Aug 15, 2014 4:47 pm

These days, very little "external" code should be required - like I said, we can meanwhile fetch data via HTTP and use Nasal to procedurally create/control AI models, including ships - the corresponding Nasal code involves just wrappers around native C++ code, so should be very lightweight.

So it's mostly a matter of keeping a timer running -via maketimer()- and using a function to update all traffic (positions, orientation) and extrapolate in between updates. As can be seen, all the building blocks are in place - and prototyping the whole thing on top of the MapStructure framework should be pretty straightforward, while also visualizing everything at the same time. Afterwards, it's mainly a matter of looking at tanker.nas and extracting some code to reuse it for not just populating/updating the map dialog, but also the AI world.

And yeah, even during the FGAIS days, Stuart mentioned several times that he was hoping to use this to populate the FG world with vessels.
I still think a MP-enabled approach would be favorable, but there's no reason why this couldn't be prototyped using Nasal and its "new" http bindings.

Like was previously said, many MP shortcomings could be addressed quite easily by fgdata contributors by just turning the whole thing into a network-enabled "remote property tree" with scripting support.

I am definitely willing to help with this, including code snippets, tutorials and support via forum/wiki.
And even this should not immediately become a useful feature, it could still be a neat tutorial for our wiki, e.g. added here: http://wiki.flightgear.org/Howto:Workin ... properties

So, if anybody wants to tackle this, I'd just ask for the whole experience to be documented - at least using the forum, but preferably, using the wiki - so that others can learn from it and maybe get involved at some point, or even just pick up the whole thing eventually.

And if that someone can be convinced to use the MapStructure framework for prototyping purposes, support is likely to be even better ;-)
The main task would be creating a new layer with an lcontroller file whose searchCmd() method would be fetching live feed data via HTTP and update a vector of geo.Coord objects.
Like I said previously, this can surely be done in under 50 lines of code - most of which we can probably post in the course of a few days, and which should only require very little adapting.

And we definitely have a number of contributors interested in extending FlightGear to simulate maritime aspects (just search for "ships" or "vessels" to see for yourself!)

Subject: Populate AI Traffic with real traffic
Hooray wrote:That looks very promising!

The current MP system probably isn't able to deal with this amount of "traffic" at the client-side - thus, it might make more sense to develop this as a server-side module, that can be run as part of the fgms process.

See this thread for some fgms-related pointers: http://flightgear.org/forums/viewtopic. ... t=#p136501

PS: I wouldn't name it FG "AIS", because AIS is about vessel tracking (ships), like Stuart mentions - which is another option obviously, because AIS feeds are also available and could be used in FG to populate our scenery with ships (Basically, AIS is analogous to TCAS/ADS-B, i.e. a VHF-based transponder system that sends out GPS-data (and extrapolated data like CoG, RoT etc) over VHF)

Image

Regarding the work that Stuart mentioned, you may want to take a look at these discussions:

EDIT: Thinking about it, the best option would probably be forking fgms and implementing this as part of a custom fgms fork - that way, it could be either configured as a relay by existing servers, or simply used as an additional MP server at the client-side, so that the MP system in FG would only need to support multiple concurrent fgms connections to different servers. That way, we wouldn't be overloading the main fgms network, but just have an additional network of fgms servers that use real traffic feeds
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: 11472
Joined: Tue Mar 25, 2008 8:40 am

Re: Ships

Postby adrian » Fri Aug 15, 2014 5:40 pm

Hey, that's my screenshot :) Never thought it would still be on the web.

Anyway, FGAIS came much later and I was not involved with it, so I wouldn't know.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: Ships

Postby Hooray » Fri Aug 15, 2014 5:45 pm

FGAIS was developed by F-JJTH, and halted due to feedback from core developers - its main idea was feeding traffic back into the FG MP environment, i.e. to populate our FG world with RL traffic (aircraft, vessels etc).

Implementing a simple prototype that uses just Nasal should be fairly straightforward meanwhile, because we can easily fetch data via HTTP and process it to control Durk's AI system by writing new data to the property tree to update/animate vessels.

Some kind of meta information would be helpful, so that the kind of vessel could be used to use different 3D models (size, draught etc)
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: 11472
Joined: Tue Mar 25, 2008 8:40 am

Re: Ships

Postby adrian » Fri Aug 15, 2014 5:52 pm

I see no reason to be running a live AIS feed for every FG client. This would place unnecessary burden on AIS servers, and besides, why bother having real time information anyway? Just like for AI traffic, this can use a static ship definition and animate the models using a little C++ module.
It's not like we need to have real time AIS information for multiplayer, since MP objects can be synced over the wire easily between clients. Just like we did for the clouds back in the day (not for FG of course).
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: Ships

Postby Hooray » Fri Aug 15, 2014 6:07 pm

Yeah, but that's exactly the same discussion we used to have in the FGAIS thread since page #1:

Subject: Populate AI Traffic with real traffic
Hooray wrote:
- My tool is here to generate AI traffic but since he send packet in MP every aircraft are considered like MP traffic not like AI traffic. I prefer to see these aircraft as AI traffic (it means to include it into flightgear source)

Like Stuart said, that's a simple change - but the question is if we WANT to do that (scraping the API at the client-side, i.e. fgfs): Stuart mentioned his concerns regarding "scraping" the JSON API here. The API provider may surely be affected by dozens of fgfs clients scraping his API like that simulatenously, especially given the amount of traffic. On the other hand, scraping the API by just a single process (i.e. fgms) and distributing the data via the MP protocol, would not be as invasive.

So, I'd make sure to keep such considerations in mind - web APIs like JSON are usually metered based on requests per second/minute. The API provider may be fine about us doing that once per second, but probably not dozens of times per second, from multiple contents/countries - which would equal a DDoS attack in a worst case scenario. However, we would obviosuly want to make sure that the API provider is not in any way affected by us using his data feeds like this.

[...] I'd still suggest to keep basic software design rules in mind here - otherwise, we may be spending time developing this feature, only to get the API use privileges restricted (or even revoked) shortly thereafter, because the API provider wasn't aware of our "broken design" and the implications of it onto his business.

Just some food for thought ...
Don't get me wrong, I don't disagree with the feature at all - just the way it's implemented currently, I am simply not sure if it's future-proof.
Personally, I'd hate developing this feature only to get a notice saying that the API use needs to be restricted to 10 simultaneous clients ...


And given how related efforts have stalled in the past, I guess it's time to recognize that "the perfect is the enemy of the good".
A simple Nasal/HTTP + AI-based version would take very little time to prototype and get working.

But even under perfect conditions, I see no reason to duplicate functionality by introducing yet another C++ module - it's really the AI system that should be extended/generalized and leveraged here, and maybe some "scripting glue" to connect things.

As a community, we tend to critically discuss/dissect all kinds of ideas much too early by voicing concerns and pointing out design shortcomings long before those actually materialize, which usually kills off such efforts fairly quickly. It seems, most of us are way too eager to see shortcomings instead of fixing prototypes to let them evolve over 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: 11472
Joined: Tue Mar 25, 2008 8:40 am

Re: Ships

Postby adrian » Fri Aug 15, 2014 6:58 pm

You're wrong, there's no need to write a whole new model, as the existing one written by Vivian can be easily extended.
Otherwise, I still see no need to scrape anything since you would 1. depend on a service to exist, 2. need to send large amounts of traffic over network, traffic which can be used for more useful stuff and 3. there is really no need to have live data.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: Ships

Postby Hooray » Fri Aug 15, 2014 7:47 pm

Like I said previously, I don't even disagree with you regarding the whole scraping/live data issue - we've discussed this at length years ago - but as can be seen, FlightGear contributors -like the two of us- tend to kill off such efforts prematurely due to technical/design issues - even though these projects never reached the corresponding stage where such considerations would matter. Given that neither of the two of us is likely to work on this anytime soon, we shouldn't be giving advice on "proper design" and just let people experiment with several prototypes - and like I said, a simple Nasal+HTTP+AI prototype would take very little time to implement, while a more "proper" solution would be much more challenging to get right, as can be seen in hundreds of postings about exactly this very topic, i.e. injecting traffic into the FlightGear AI/MP environment.

PS: I don't know how I can "be wrong": I never said anything about writing "a whole new model" - I just said, that a prototype can be definitely implemented without it involving any rebuilding of FlightGear or touching of C++ code - which is the primary challenge obviously.

A prototype can be clearly implemented in scripting space - sure, it will have all the issues that you are pointing out, and that a number of contributors pointed out 2-3+ years ago, but -as a community- we should really learn to walk before we try to run - it is far too common for us to discourage newcomers by giving out unsolicited "architectural advice" and a ton of optimization hints, despite the effort not even having reached the "alpha" stage - which often enough meant that we'd kill off interesting efforts because we tend to see more boundaries, issues and challenges than "opportunities". And I am guilty of this myself (c.f. the whole missions/adventures discussion where I was basically the one to kill off Thorsten's ambitions on writing a corresponding system from scratch).

Which is something that can be seen in so many other areas of the project, including core development: no matter if it's osgEarth or even the radio propagation code, and even the Canvas system: even core developers who've been absent for months tend to come up with architectural requirements all of a sudden or "veto" a certain changes, just because there are better/more proper ways to accomplish something - completely ignoring the fact, that their own patches/contributions were more often than not also just compromises.

So, I'd suggest to be careful here - most lurkers (and even coders) tend to become architecture astronauts once they see a certain proposal/design or even patch, without keeping in mind their own work - in the case of Canvas, there were some fairly critical discussions on the devel list early 2012, some folks even suggesting to completely abandon PUI immediately, without keeping in mind that the "proper" solution would obviously take several years to materialize eventually (which we're really only just about to see).

Thus, I am inclined to just let people experiment - Bomber also mentioned various times how he felt that we'd be killing off interesting ideas due to technical reasons, and he kinda got a point there, this isone of the most common issues affecting FlightGear meanwhile, even despite the lack of manpower - just look at all the discussions on the whole "Uber-Shader" approach on the devel list or the plethora of patches providing useful functionality that were never reviewed/committed. And like I said, to a certain extent, we're doing exactly the same thing here around the forums, which is unfortunate.

Yeah, HLA is obviously the most proper solution, but just look at all the fgms/DIS related discussions and efforts HLA has killed off, even though it still is very much "pie in the sky" for various reasons.
So, we're very much seeing "the perfect being the enemy of the good", which is kinda why I am hesitant to discuss proper design/architectural advice at such an early stage - otherwise, we might very well already have most of this functionality in place...
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: 11472
Joined: Tue Mar 25, 2008 8:40 am

Re: Ships

Postby chrisb » Sat Sep 06, 2014 10:26 pm

I still dont understand, its been attempted mostly with fgais I'd just be doubling up on existing work
Wouldn't the smart thing to be to improve this as it already includes planes, the whole point of a flight simulator
chrisb
 
Posts: 136
Joined: Mon Oct 21, 2013 8:46 pm
Location: YLIL, YMML
Callsign: cnb123
Version: git
OS: Win7 64bit

Next

Return to New features

Who is online

Users browsing this forum: No registered users and 3 guests