FlightGear missions and adventures: Difference between revisions

FlightGear missions and adventures (view source)

Revision as of 18:42, 25 April 2014

1,595 bytes added , 25 April 2014

m

→‎Version Attribute: http://forum.flightgear.org/viewtopic.php?f=79&t=22845#p207103

Hooray

Administrators

20,741

edits

@@ Line 59: / Line 59: @@
 * '''Hooray [http://forum.flightgear.org/viewtopic.php?f=79&t=22698#p206113]''': One of the most important changes to prepare more flexible solutions in the future would be introducing a "version" tag/attribute, so that we can provide backward compatibility, while also adding new features, without breaking old tutorials. In fact, the existing tutorial subsystem is fairly flexible, but simply because it's "open-ended" due to the way Nasal scripting is recursively supported, it's so much by design, i.e. there's actually very little in terms of class hierarchies or even OOP in the first place. when it comes to renaming the tag, or supporting additional tags, I really suggest to introduce a mandatory "version" attribute first. Once that is in place, things will be safe to change in the future. [http://forum.flightgear.org/viewtopic.php?f=79&t=22698#p206164]
+=== Separate Modules (Hoops, AI, NPC etc) ===
+I would suggest to keep the amount of custom Nasal code in tutorials very low - any huge amounts of code are a sure "code smell" that the framework isn't yet sufficiently generic and needs to be extended. Things like AI interaction or hoops should preferably be separate Nasal modules (files) that we can either just move into $FG_ROOT/Nasal (or as a submodule), or simply include via io.nas from some other place (load_nasal)
+While the tutorial/mission system will need access to such features, those features should not be a part of "just" tutorials, those should really be modules that can be reused in other places. Hoops is one such example - we need to be able to use the code, but it should not be tied/coupled to just "tutorials". Thus, we simply need to use separate files here and make sure that we can include/load and use such code.
+The tanker.nas code would be another example here, its features would be immensely useful to the tutorial/mission system, because we could easily create AI traffic and control it - but this should not be tied to "tutorials & missions" obviously.
+For starters, and the sake of simplicity, it should suffice to simply maintain such features as separate submodule-files inside $FG_ROOT/Nasal/tutorial, so that things can be more easily refactored later on.
+The only thing to keep in mind here is to ensure that such modules are mostly declarative, i.e. do not actually do anything other than provide helper functions and classes, so that these can be easily moved around without any refactoring needed.
 === Mission Briefings ===