Well, I wanted to let this sink in for several days (and didn't want this to go too far down the thread line), before I posted again. We obviously got some good ideas on how to make the "TUG" possibly happen. The next step... can we put some of these theories to the test? 1. - Arno, gorchi, and ShakaCan we try a test by creating a simple design, say a rectangle and see if we can get it to follow an aircraft? Either each person try it on their own or as a team. Again I can help coordinate... let me know your strengths in design for this or areas you could use help.2. - ZipCan you create a generic switch ( final look yet to be determined), that would pop up the rectangle in it's proper location? Have you tried any switches that result from an action... (i.e - such as a parking brake released)?Ever created a switch that also plays a sound file?Just got back from taking shots at Palm Springs (KPSP)... whew 112 degrees!!! It was so hot I could hardly touch my camera. I will also be emailing all those who left an email address. Hope to talk with ya all over the the weekend...

Marcus,no problems on the gauge side but a few questions:As always, documentation is elusive. I had a cursory look at SCASM, (need to read more), and in particular I'd like to find out if it's possible to read/use/set custom vars (= named variables for example) on the scenery side. I see that the dynamic object can be set at a specific point (lat/long) and be given heading/alt in the compiled file. It can also read other variables, but I have no idea what these are at this point. It also appears that it is not a good idea to use AI type dynamic scenery since it talks to the built-in ATC and you end up with a bus asking for IFR clearance, not desirable.It would be helpful if somebody with experience on the dynamic scenery side could explain the how those variables are used in the scenery, and from that I'll look at placing the right values in those from the gauge side. In particular:1) position of the tug relative to the plane.2) state (attached, detached)3) time (for textures such as lights on the tug)These can be easily set in the gauge, but transfering the info to the dynamic object is what we're talking about here.Makes sense?

>1) position of the tug relative to the plane.I think Goran can better answer this, as I have not tried to tweak dynamic scenery like that (I use animations more). But I think it is not possible to set it relative to the plane. You set it relative to a RefPoint (some coordinates), so the gauge should do the calculations needed to get that position.>2) state (attached, detached)I think these can best be stored in a user variable, then it is possible to write them from outside. For GMax animations I use local variables to store the state, but then it can not be changed by the gauge, so we should use one of the 5 user variables that are available for this I think.>3) time (for textures such as lights on the tug)I think this is not needed from outside. The model of the tug itself can contain such checks and then textures and light will appear automatically. No interaction of the gauge is needed with that I would say.