Board index FlightGear Development Scenery

The animated jetway project

Questions and discussion about enhancing and populating the FlightGear world.

Re: Movable jetways- some progress!

Postby skyop » Mon Jul 05, 2010 6:26 pm

HHS wrote:But all aircrafts have parkingbrakes! So when parkingbrake is applied the jetways should be triggered.


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. :P
Aircraft: [ CRJ700-family | DC-10-30 ] Scenery: [ KBFL ]
skyop
 
Posts: 3047
Joined: Mon Jun 14, 2010 12:40 am
Location: Austin, Texas, USA
IRC name: skyop
Version: next
OS: Fedora 23/Windows 10

Re: Movable jetways- some progress!

Postby Oscar » Mon Jul 05, 2010 6:41 pm

This would be awesome! What Gijs said, putting 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)

Anyway, this project is awesome and I think it should have been in FlightGear already, so thanks for starting this!
User avatar
Oscar
 
Posts: 425
Joined: Sat Sep 05, 2009 1:12 pm
Location: The Netherlands
OS: Mac OS X

Re: Movable jetways- some progress!

Postby skyop » Mon Jul 05, 2010 6:44 pm

Oscar wrote: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.


It can be even easier. Fire up Blender, load the *.ac file, place an empty, move it to the door, get the coordinates and BAM! :D

Oscar wrote: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)


Yes, I believe they detach the jetway before pushback.
Aircraft: [ CRJ700-family | DC-10-30 ] Scenery: [ KBFL ]
skyop
 
Posts: 3047
Joined: Mon Jun 14, 2010 12:40 am
Location: Austin, Texas, USA
IRC name: skyop
Version: next
OS: Fedora 23/Windows 10

Re: Movable jetways- some progress!

Postby skyop » Mon Jul 05, 2010 6:47 pm

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.
Aircraft: [ CRJ700-family | DC-10-30 ] Scenery: [ KBFL ]
skyop
 
Posts: 3047
Joined: Mon Jun 14, 2010 12:40 am
Location: Austin, Texas, USA
IRC name: skyop
Version: next
OS: Fedora 23/Windows 10

Re: Movable jetways- some progress!

Postby Oscar » Mon Jul 05, 2010 7:08 pm

skyop wrote:It can be even easier. Fire up Blender, load the *.ac file, place an empty, move it to the door, get the coordinates and BAM! :D

Lol you made me download blender :P
skyop wrote: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.

That sounds great!

Suggestion: maybe someone can make an AI-staircase doing the same thing? Then that thing is just standing at airports where there's no jetway, and then it drives it's way to your aircraft's door (staircase that fits small aircraft, like 737 and A320). It might be tricky to let it drive realistically, but the coordination-seeking part should work the same, right?
User avatar
Oscar
 
Posts: 425
Joined: Sat Sep 05, 2009 1:12 pm
Location: The Netherlands
OS: Mac OS X

Re: Movable jetways- some progress!

Postby scotth1 » Tue Jul 06, 2010 10:06 am

In real life the jetway/aerobridge is independant of the aircraft and it is controlled by a operator within the jetway/aerobridge.

If we were to model this in an object oriented programming manner we would put the logic for moving the object into the jetway object and not into the aircraft object, the amount of travel (in time or distance) would be configured for each aircraft type in the jetway/aerobridge object also.

So with this in mind, it makes sense to me that clicking on the jetway/aerobridge object would cause it to start moving, as it knows its current position relative to a known starting position, so it can determine if it needs to move forward or backward. If the aircraft is also assume to be on the centreline then it can move within a reasonably close distance to the aircraft, the last extension of distance of the hood part could occur until it touches the aircraft (from memory there is the possibility to detect when one .ac object touches another, but I can't remember the details).

This then removes the need for every aircraft to be updated with some information of where the "doors" are relative to some point of the aircraft, and then determining where the aircraft is in relation to the jetway/aerobridge, and if these aerobridges are located at every airport the scan of all jetway/aerobridge objects and aircraft objects to see if they are close enough to move is going to increase and therefore slow down the frame rate.

Just another way at looking at it perhaps.


S.
scotth1
 
Posts: 231
Joined: Thu Jan 01, 2009 3:27 am
Location: Australia
Callsign: VH-SHA
Version: Git next
OS: Linux 3.4.11

Re: Movable jetways- some progress!

Postby Gijs » Tue Jul 06, 2010 10:14 am

I noticed that it is easier to place the door-positions within the jetway object. The jetway will check what aircraft the pilot is flying and it will then pick the correct door position. The jetway calculates movements by itself, based on the door-position, relative to the nosewheel (which the pilot should place on the marker at the end of the centerline). This does mean that when a pilot parks his aircraft at the wrong spot, the jetway will act as if it parked correctly...

One way to solve this (and actually most problems) would be to add controls to the jetway, so users/pilots can manually operate the jetway, just as they can drive the pushback on some of our aircraft. I think we can even add a viewposition (next to helicopter view, chase view etc.), which will become available if the aircraft is within "range" of the jetway. What about that?

scotth1 wrote:from memory there is the possibility to detect when one .ac object touches another, but I can't remember the details

James also brought this up. It sounds very interesting, as it will make it impossible to "damage" the aircraft or the jetway and allow us to detect if the aircraft is in "range" (eg. 100 meter) of the jetway. Anyway, I'll need an example of this for sure :)
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9364
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Movable jetways- some progress!

Postby zakalawe » Tue Jul 06, 2010 10:36 am

Putting the positions in the jetway is a bad idea, I'd say - and assuming the pilot parks correctly is definitely a bad idea - such information will rapidly become stale or not be kept in sync. In real life, there jetway is guided (there's a human brain involved, but I bet it could be automated) based on where the door is, not by markings on the ground or similar.

Adding a marker object for the door centre is 'easy' in either the .ac or the -set file (in some properties - especially since there's normally only one or two doors that can be possibly be used with jetways - although having an air-stair or catering lorry use the same information is highly desirable).

I'll look out some Nasal examples of intersecting the model geometry, but Vivian and Thorsten are the experts in this, I think, plus anyone who's done the Nasal based combat systems - the jet way is a bit like a very slow guided missile that locks onto a very specific part of the aircraft :)

(Making the hood fit the aircraft curvature should also be trivial, once we figure out the Nasal intersection logic)
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Movable jetways- some progress!

Postby simbabeat » Tue Jul 06, 2010 2:56 pm

We could make it so that we could control the jetway maybe?..

Cheers
User avatar
simbabeat
 
Posts: 3435
Joined: Sat Sep 12, 2009 12:19 am

Re: Movable jetways- some progress!

Postby skyop » Tue Jul 06, 2010 8:09 pm

simbabeat wrote:We could make it so that we could control the jetway maybe?..


My position is to keep the jetway automatic. Save the manual jetways for a rainy day...

Gijs wrote:One way to solve this (and actually most problems) would be to add controls to the jetway, so users/pilots can manually operate the jetway, just as they can drive the pushback on some of our aircraft. I think we can even add a viewposition (next to helicopter view, chase view etc.), which will become available if the aircraft is within "range" of the jetway. What about that?


I think we should keep the current approach and assume the pilot has parked correctly, which is almost NEVER the case, but I think it's the best method for now.

What I'd like to see is progress on the multiple jetways issue. I still haven't figured out how to solve that problem... :(
Aircraft: [ CRJ700-family | DC-10-30 ] Scenery: [ KBFL ]
skyop
 
Posts: 3047
Joined: Mon Jun 14, 2010 12:40 am
Location: Austin, Texas, USA
IRC name: skyop
Version: next
OS: Fedora 23/Windows 10

Re: Movable jetways- some progress!

Postby Gijs » Tue Jul 06, 2010 9:32 pm

My evening has been a little too bussy (yes, we won!!!), so I'll send you the current progress tomorrow if you don't mind (actually also if you do mind) ;)
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9364
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Movable jetways- some progress!

Postby Hooray » Tue Jul 06, 2010 9:32 pm

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. :P

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...
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Movable jetways- some progress!

Postby skyop » Tue Jul 06, 2010 9:42 pm

Gijs wrote:My evening has been a little too bussy (yes, we won!!!), so I'll send you the current progress tomorrow if you don't mind (actually also if you do mind) ;)


No, not at all, looking forward to it! :)

Update: I've almost found the holy grail (nasal solution to independent jetway animations)! There is just one missing link. I have two options:

1. I need to specify a global(ish) variable that will ONLY be available to that SPECIFIC model. So if I placed two jetways, both of them would need to have different values for the hypothetical variable (does that even make sense!?). :lol:

2. I need a way to reference the model in which the nasal script is defined. Something like the "this" keyword often found in other scripting languages. That way, I could do something like this:
Code: Select all
scenery.currentMovingJetway = this;

Where "this" refers to the jetway in which the script is defined.

:shock: :| :arrow: :cry:
Aircraft: [ CRJ700-family | DC-10-30 ] Scenery: [ KBFL ]
skyop
 
Posts: 3047
Joined: Mon Jun 14, 2010 12:40 am
Location: Austin, Texas, USA
IRC name: skyop
Version: next
OS: Fedora 23/Windows 10

Re: Movable jetways- some progress!

Postby Oscar » Tue Jul 06, 2010 10:17 pm

Can't you mention the coordinates in the data files of the jetways? If you click any of them, the one most close to the aircraft will wake up and connect. This way you can also make limitations to the relative coordinates so it just won't work if the pilot parked incorrectly. It might be quite some work to put in all the location data in those jetways, but if you just do it from start, it might become useful in the end.
User avatar
Oscar
 
Posts: 425
Joined: Sat Sep 05, 2009 1:12 pm
Location: The Netherlands
OS: Mac OS X

Re: Movable jetways- some progress!

Postby skyop » Wed Jul 07, 2010 12:25 am

Oscar wrote:Can't you mention the coordinates in the data files of the jetways? If you click any of them, the one most close to the aircraft will wake up and connect. This way you can also make limitations to the relative coordinates so it just won't work if the pilot parked incorrectly. It might be quite some work to put in all the location data in those jetways, but if you just do it from start, it might become useful in the end.


Sort of what I was going at. :? I don't understand your post though, could you please rephrase it?

To all who are debating: here's what my "visionary" system is:

Player clicks a jetway. If the aircraft is close enough, the simulator pops up a message: "Jetway extending." Otherwise the simulator says "You are too far from the jetway." The jetway then extends and rotates itself to fit the door of the aircraft, the position of which is defined in one of its xml files. (Yes, this is exactly like FSX.) Clicking the jetway again retracts it.

Here's what I aim to achieve ATM:

Player clicks a jetway. (Done.) The simulator pops up a message: "Jetway extending." (Done.) Jetway extends/rotates itself to predefined positions depending on the aircraft the player is in. (In progress.) Clicking the jetway again retracts it. (Done.) Multiple jetways can be placed based on one model and are operated independently. (Nearly impossible, apparently.)

Obviously, there are many drawbacks to the system specified above, but it's what I aim to do. :P If anyone wants to take it further and create the "visionary" system above, be my guest, but wait until my work is done. ;)
Aircraft: [ CRJ700-family | DC-10-30 ] Scenery: [ KBFL ]
skyop
 
Posts: 3047
Joined: Mon Jun 14, 2010 12:40 am
Location: Austin, Texas, USA
IRC name: skyop
Version: next
OS: Fedora 23/Windows 10

PreviousNext

Return to Scenery

Who is online

Users browsing this forum: No registered users and 10 guests