Given the recent progress in the reset/re-init department it is foreseeable that we'll sooner or later be able to switch aircraft at runtime, and for most purposes/end-users we're hoping to eventually get rid of having to use external launchers by providing a simple integrated GUI wizard using Canvas/Nasal (initialized much earlier than the rest of the sim) - this is something that Zakalawe & TheTom have been working on as part of the reset/re-init effort:Īnd for the "missions" system itself it would actually be good to support aircraft/location-agnostic missions, so that people can use the same system with different parameters (aircraft, location, daytime, weather etc) - so it would make sense to get rid of this limitation at some point - for example by allowing some tup() routine to be invoked during initialization, rather than requiring tutorials to be statically defined/integrated by editing the -set.xml file This is true, there's a built-in limitation in that "tutorials" need to be loaded via the aircraft-set.xml files currently: įgrun itself is completely unaware of tutorials, while it would be possible to use some -prop: argument to change that easily, I am not even sure if that makes sense: Should missions be defined in the -set.xml of each aircraft? Should they be defined as a scenario? A new entry in the menu? How could we load a mission from fgrun, for example? The only thing I'm not sure is how to load "mission files". Ludomotico wrote in Wed 5:44 pm:I agree most of the code is already there by extending the tutorial system and a bit of nasal. Some kind of "traffic" or "aiobject" would be simple to add and support, and each tag could have its own Nasal section that controls it. I would consider extending the current "models" tag to also support movable AI objects, we have enough code doing this sort of thing (tanker.nas, bombable, fox2.nas) and it would allow us to encode other traffic (vessels, aircraft, ground traffic) as part of the actual XML file. The tutorial system itself already has support for placing 3D models in arbitrary locations, no matter if it's a vessel, climber or a vehicle: īut those are all static currently, so we would need to use this in combination with an AI scenario, which is not overly flexible, and also not that easy to deploy. in terms of building blocks that need to be supported/added by extending tutorial.nas - this may boil down to just having a handful of additional primitives added.īeing able to control daytime and weather as part of the setup seems like a cool idea that should be straightforward to implement, weather would be best supported by simply storing the METAR string to keep things simple. Most of these missions should require very similar features, i.e. To track mission objectives, we could use a procedurally-created canvas dialog that shows some bar charts.Ĭontent-wise, we should focus on aircraft and locations that are fairly well-developed, to ensure that there's not too much maintenance overhead involved due to missing/incomplete features. In the same sense, a twin-engine mission could be flown with different twin-engine GA airplanes that way. max speeds) could be looked up using the data provided via aircraft checklists: R22, bo105 or ec135 - aircraft specific stuff (e.g. having scripted virtual pilots or ATC controller.įor aircraft-specific tutorials, I would hope to use the upcoming "Catalog metadata" to ensure that similar aircraft can be chosen to work through the same tutorial/mission/adventure: īasically, aircraft making use of catalog metadata have sufficient meta information, so that the tutorial system could allow people to fly the same "power line maintenance" mission with different helicopters, i.e. perfectly in line with the original purpose of the "tutorials" system, while also allowing additional functionality to be developed on top, i.e. This would be primarily useful for any "flight instructions"-based scenarios, i.e. where a virtual ATC controller guides pilots down a GCA path using radar vectors and AGL altitudesĪll this stuff is already exposed to Nasal thanks to the work that Zakalawe & TheTom have done as part of "NasalPositioned" and those flightplan() APIs - so we really only need to expose a handful of building blocks so that people can create route/navaid-aware missions. Such things would be useful also for virtual flight instruction - but also for an ATC adventure, i.e. for navigating via VORs, NDBs or DMEsĬurrently, the tutorial system doesn't have any built-in support for "fly to the SFO VOR" - but once we have that, we could even support flying holding patterns ( "fly to sfo maintain 8000, hold left on the 180 radial"). route manager/waypoint awareness, and ability to track course/bearing to certain positions (via geo.nas) - e.g. Hooray wrote:we may need to add some features, especially for piloting/flying, i.e.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |