MediaWiki has been updated to version 1.35.1. Please report any problems here.

Changes

Jump to navigation Jump to search
m
Line 526: Line 526:  
     |author=<nowiki>Hooray</nowiki>
 
     |author=<nowiki>Hooray</nowiki>
 
     |date=<nowiki>Mon Feb 04</nowiki>
 
     |date=<nowiki>Mon Feb 04</nowiki>
 +
  }}
 +
}}
 +
 +
== C++ Issues ==
 +
{{FGCquote
 +
  |It would be great if the flexibility of the current system could at least be retained or possibly even extended, for example: your heavy use of the property tree and listeners for instantiating new traffic has made many things possible that you probably never were planning to support, such as AI traffic or AI guided missiles controlled by Nasal scripts.<br/>
 +
<br/>
 +
If this pattern could also be transferred over to the ATC component, then we might eventually have ATC controllers scripted entirely in Nasal space, interacting with AI "pilots" controlled from Nasal. The C++ code would just provide the interface for  Nasal scripts.<br/>
 +
<br/>
 +
Given the small number of C++ developers working on the ATC/AI systems and given the complexity of creating a full working AI/ATC system, it would seem to be a sensible decision to move more and more parts out into scripting space where functionality can be developed, contributed and maintained by users rather than core developers? <br/>
 +
<br/>
 +
The underlying C++ code is already fairly sizable and complex, so it would be great if it could be controlled from scripting space and down-stripped to just provide the required interface itself, that should also make your job much easier.
 +
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=134933&sid=b6751abc5e37df35975f178c70838e28#p134933
 +
    |title=<nowiki>Re: New ATC / AI interactions</nowiki>
 +
    |author=<nowiki>Hooray</nowiki>
 +
    |date=<nowiki>Wed Aug 31</nowiki>
 +
  }}
 +
}}
 +
 +
{{FGCquote
 +
  |Note that I won't oppose other ideas, and if you have nasal code that would require certain components of the AI system to be shutdown, or need specific hooks to interface certain C++ components with nasal bindings, than I would certainly be willing to support that.
 +
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=134970&sid=b6751abc5e37df35975f178c70838e28#p134970
 +
    |title=<nowiki>Re: New ATC / AI interactions</nowiki>
 +
    |author=<nowiki>durk</nowiki>
 +
    |date=<nowiki>Wed Aug 31</nowiki>
 +
  }}
 +
}}
 +
 +
{{FGCquote
 +
  |Regarding "flight plans", I was just reading [http://sourceforge.net/mailarchive/forum.php?thread_name{{=}}m1wrkaf65u.fsf%40usa.net&amp;forum_name{{=}}atlas-devel this] on the atlas mailing list.<br/>
 +
It seems there is some confusion regarding the different types and roles of "flight plans" supported by FG.<br/>
 +
<br/>
 +
In the long run it would be great if the concept of a "flight plan" could become well-defined for all affected systems, so that the same code could be used for both, the AI/ATC systems, as well as the built-in route manager - then we would  have just one single type of "flight plan", which would eventually also improve code reuse and sharing among related systems.<br/>
 +
<br/>
 +
I think zakalawe mentioned plans along those lines some time ago, so it'd be good to keep those things in mind:<br/>
 +
<br/>
 +
For instance, the addition of support for DPs, STARs and IAPs is something that would quite obviously be useful for all 3 components, AI, ATC and the route manager. Same applies to RNAV support, I guess?
 +
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=134933&sid=b6751abc5e37df35975f178c70838e28#p134933
 +
    |title=<nowiki>Re: New ATC / AI interactions</nowiki>
 +
    |author=<nowiki>Hooray</nowiki>
 +
    |date=<nowiki>Wed Aug 31</nowiki>
 +
  }}
 +
}}
 +
 +
{{FGCquote
 +
  |James and I have plans to unify our approaches. One of the reasons why I have put my plans to implement SIDs and STARs, as well as more complicated airway following in flight flightplans on the back burner is to give James some time to finish is work on the route manager. This way we can work towards a common format that is shared between the route manager and the AI system.
 +
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=134970&sid=b6751abc5e37df35975f178c70838e28#p134970
 +
    |title=<nowiki>Re: New ATC / AI interactions</nowiki>
 +
    |author=<nowiki>durk</nowiki>
 +
    |date=<nowiki>Wed Aug 31</nowiki>
 +
  }}
 +
}}
 +
 +
{{FGCquote
 +
  |I guess, it might be a good idea to eventually start collecting a list of things that would need to be changed, i.e. like what Thorsten did for prioritizing core-changes to improve his local weather system using the wiki.
 +
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=140381&sid=4aa5400d0368eaa508a44abd83e43073#p140381
 +
    |title=<nowiki>Re: AI & MP Dogfighting now working! Bombable ships, aircraf</nowiki>
 +
    |author=<nowiki>Hooray</nowiki>
 +
    |date=<nowiki>Sat Oct 15</nowiki>
 +
  }}
 +
}}
 +
 +
{{FGCquote
 +
  |I was looking into the code, and I think this is a "problem" that can be easily solved by disabling some of durk's AI traffic code, basically it is simply "too smart" and making too many assumptions about the type of aircraft/flights it is controlling, at the moment. <br/>
 +
<br/>
 +
Disabling code should be merely a matter of introducing a  bunch of new properties to make such assumptions optional. <br/>
 +
Sort of like a more pure, or a "raw" controlling mode where everything related to "airliner assumptions" is simply disabled.<br/>
 +
<br/>
 +
I think, durk won't mind that at all, because it's not really introducing new code or touching existing code, it would by default keep everything "as is", but only introduce a bunch of control properties to disable some of these defaults.<br/>
 +
<br/>
 +
For your Nasal code, that would basically mean to set those new properties and handle those things in Nasal space instead. Maybe, you could come up with a list of "airliner-characteristics" that you would like to disable/control yourself eventually?
 +
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=140382#p140382
 +
    |title=<nowiki>Re: AI & MP Dogfighting now working! Bombable ships, aircraf</nowiki>
 +
    |author=<nowiki>Hooray</nowiki>
 +
    |date=<nowiki>Sat Oct 15</nowiki>
 +
  }}
 +
}}
 +
 +
{{FGCquote
 +
  | this is helpful.  I've never managed to get the target-hdg or target pitch methods to work.<br/>
 +
<br/>
 +
However, the solution to most of the problems I've outlined above would be to create 1. a new heading/directional mode that disables target roll and target hdg  and 2. a new altitude control mode that disables target altitude and target pitch.<br/>
 +
<br/>
 +
Then, using Nasal, we can just input our roll and vertical speed directly and not have the AI system try to change them.
 +
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=140919#p140919
 +
    |title=<nowiki>Re: AI & MP Dogfighting now working! Bombable ships, aircraf</nowiki>
 +
    |author=<nowiki>flug</nowiki>
 +
    |date=<nowiki>Sat Oct 22</nowiki>
 +
  }}
 +
}}
 +
 +
{{FGCquote
 +
  |The AI System btw. has it's drawbacks regarding non-aircraft Entities. Also it is hard to pass specific Properties to an AI Model. It will always try to bank and pitch, which needs to be corrected per Model. This all can be solved by using animations and Nasal, but creates a lot overhead.
 +
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=206786#p206786
 +
    |title=<nowiki>Re: Tutorials/Missions/Adventures: requests for features</nowiki>
 +
    |author=<nowiki>DFaber</nowiki>
 +
    |date=<nowiki>Wed Apr 23</nowiki>
 +
  }}
 +
}}
 +
 +
{{FGCquote
 +
  |lug mentioned a while ago that he ran into the same issue with regard to his bombable/combat addon
 +
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=207065#p207065
 +
    |title=<nowiki>AI support</nowiki>
 +
    |author=<nowiki>Hooray</nowiki>
 +
    |date=<nowiki>Fri Apr 25</nowiki>
 +
  }}
 +
}}
 +
 +
{{FGCquote
 +
  |If you can provide a list of problematic behavior patterns, I can check the C++ code to see if/how things can be made more configurable there, i.e. with a focus on non-aircraft, but also aircraft that may not fly like airliners
 +
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=207065#p207065
 +
    |title=<nowiki>AI support</nowiki>
 +
    |author=<nowiki>Hooray</nowiki>
 +
    |date=<nowiki>Fri Apr 25</nowiki>
 +
  }}
 +
}}
 +
 +
{{FGCquote
 +
  |OK, here's my wishlist part 1:<br/>
 +
<br/>
 +
<br/>
 +
Disable the banking when turning with Ground Vehicles. There are Ground vehicles in FG, but mainly Trains, which I haven't been able to utilize for Cars. Also Cars need to lookup Ground elevation which AI Aircraft don't do too.<br/>
 +
<br/>
 +
FG determines submodel hits on AI/MP Objects by square Boxes around the Aircrafts Origin. These are too wide to be useful with Ground Vehicles and small Aircraft. Some more Size opions would be useful.<br/>
 +
<br/>
 +
When a new Target Heading is selected AI Aircraft don't turn harder than 30 degrees. It would be good to be able to configure this per Aircraft.<br/>
 +
<br/>
 +
I'd like to specify Model specific Properties like Livery, Type in the AI Scenario file. Right now I need to create and set them within the nasal section.<br/>
 +
<br/>
 +
These are some from the top of my head. More to come ...
 +
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=207095#p207095
 +
    |title=<nowiki>Re: AI support</nowiki>
 +
    |author=<nowiki>DFaber</nowiki>
 +
    |date=<nowiki>Fri Apr 25</nowiki>
 
   }}
 
   }}
 
}}
 
}}

Navigation menu