Really interesting discussion.
I agree, the most straightforward solution would be to simply specify the entry/exit locations for aircraft directly in the aircraft-set.xml file, using relative object coordinates and offsets.
Preferably, this sort of meta information would however be just included, so that it can be easily reused by other aircraft (think different airlines, liveries, configurations etc).
And yes, glazmax is right: size(vec); is the right function to retrieve the size of a vector.
But you do have to rely on the pilots parking at the correct spot, as the jetways do not (yet) see where and how the aircraft is positioned relative to the jetway...
What would be needed to add this? Has anybody actually tried doing this? Where exactly was the problem?
As far as I know, Nasal can already be used in scenery XML files - so wouldn't it be possible to use generic properties for the coordinates and offset, and then fill in these dynamically using a script that is aircraft specific? Am I misunderstanding something here?
My current approach involves editing of each aircraft's -set.xml. That way, aircraft authors will have full freedom.
I really think it would be better to use a generic set of include files that can be reused by identical/similar aircraft.
I'd still prefer the "click the jetway" method. With the parking-brake method you have all sorts of variables to calculate, such as what jetway the aircraft is closest to (if any), etc. For now it's just simpler for me to use clicking instead.
That's a fairly simple question of providing a good user interface, one could even have a separate dialog ...
The underlying code remains the same.
utting some coordinates in the aircraft-set.xml would be best. Even if the aircraft already is finished or the developer is unfindable, we can all experiment with the xyz until we found the right place for the jetway to be. Clicking is just fine, and it's the easiest way to create it indeed. You can just depend when to (dis)connect to the jetway whenever you want. Don't they first get away that jetway before releasing parking brakes in real life? (that seems logical to me)
Using separate XML files that are simply included would have the advantage, that it would be fairly easy to include such a file with global defaults for ALL aircraft, e.g. via preferences.xml. That would have the advantage that you would not need to modify xxx aircraft-set.xml files to add support for this, but instead just have a handful of generic files with coordinates for different type of aircraft, so that users would merely have to override them if they seem to be way off ... but defaults would apply for those aircraft that do not yet have custom coordinates specified, possibly with a corresponding note shown in the console window saying "Note: using generic jetway coordinates and offset, because no custom data was found, you may want to override this by editing jetway.xml in your aircraft's folder"
About where the door coordinates should be defined, I think it should be in each aircraft's -set xml file. Also, a suggestion for Gijs: perhaps you could also store the angle at which the jetway hood should be extended? Ideally it should be like 1 or 2 for 747s and 5 for smaller aircraft.
I agree, but the aircraft-set.xml files are often already fairly bloated, it makes aircraft much more self-explanatory by using separate files for various features (e.g. fdm, sound, panel, gui, help etc).
That way, users would not have to mess with huge bloated XML files, but could instead concentrate on just editing one tiny bit of XML, i.e. consider the following which is much easier to deal with than your usual aircraft-set.xml file.
- Code: Select all
<?xml version="1.0"?>
<PropertyList>
<jetway-offsets>
<x></x>
<y></y>
<z></z>
<angle></angle>
</jetway-offsets>
</PropertyList>
In real life the jetway/aerobridge is independant of the aircraft and it is controlled by a operator within the jetway/aerobridge.
The closest possible thing in FG would be having a dedicated "jetway vehicle" (i.e. like the ATC "aircraft") to allow people to control the jetway. Of course that would probably become pretty boring rather soon. So the other option would be to tie it to said ATC aircraft, so that ATC may optionally operate the jetway and pushback, by clicking a button. But that would only make sense for aircraft with actual ATC. For airports without human ATC, one would still want to keep this fully automated.
To keep this sort of realistic, one could run a local Nasal script that implements support for jetways and pushback, the Nasal script would then be bound to a handful of properties using listeners. This would make it possible to issue a pre-canned radio transmission (via the GUI) that could be parsed by the locally running Nasal script, which would in turn operate the jetway and/or pushback vehicle.
With some workarounds, exposure via MP might be possible using generic properties, I am not sure however how efficient that would be in the end...