Switch cover animation

[Guest fbnweoghnwd]

I'm trying to make an animation - for FSX, using XML - that will toggle a switch cover open and closed. There would be a switch underneath it for, say, the generator, which you could then toggle. The generator switch is a piece of cake, but how can I animate the switch cover? It doesn't have to do a thing, other than toggle open & closed.Here's what I tried - which didn't work:I created the keyframe animation for the switch cover in 3D Max. Then, in Modeldef.xml, I made a copy of the default battery switch animation to use as a starting point. I copied both the "part info" section, and the little section up top where the GUID is specified. I then changed the GUID to a unique one, and renamed the animation. At this point, the code was an exact copy of the battery switch animation, except for the new name I gave it...looking like this: switch_cover_generator50ELECTRICAL MASTER BATTERYbool50400HandHELPID_GAUGE_BATTERY_SWITCHTOOLTIPTEXT_BATTERY_SWITCHTOGGLE_MASTER_BATTERYI then re-started Max, and expected the new animation to show up in the Attach Point tool and Animation Manager - but it wasn't on the list. It's supposed to be, isn't it - or am I missing a trick?The next part of the plan - which of course I never got to - was to try to disable the actual toggling of the battery - leaving only the animating switch and no functionality. I was going to see if I could simply eliminate the EventID - but that sounds so simple that I bet it won't work.So, will this method ever get me an animated - but non-functioning - switch, or is there a better way?

[n4gix 4,947]

First, let's get your cover animated and operational, then we can refine it somewhat if needed.Anything you add to the section at the top of modeldef.xml will indeed show up in the picklist of the Animation and/or Attachpoint tools, provided you edited the actual working copy of modeldef.xml file to begin with! ;)Use ONLY the modeldef.xml file located in the default SDK path to avoid any confusion. It should be in the ..SDKEnvironment KitModeling SDKbin folder.Secondly, I would strongly advise adding all new GUID information to the BOTTOM of the stock entries. This will keep your "custom stuff" separated visually from the stock entries.Next, all custom animation code ideally will be placed at the TOP of the "stock code" for the same reason. It just makes debugging faster when you've got your stuff in one spot... ;)For some perverse reason, all "new stuff" added this way will display as follows in the picklists: 1) Animation Mangager: top of the list 2) Attachpoint Tool: bottom of the listFinally, I would suggest creating/using a custom L:var,bool to animate your cover instead of a "stock" event. So, here is my suggested code: switch_cover100 (L:SwitchCover,bool) 100 * 40HandOpen/Close Cover (L:SwitchCover,bool) ! (>L:SwitchCover,bool) Notice in the above that since we are using a "custom L:var" the type= entry is "Standard" rather than "Sim". Also, since there's no need for "legacy support," the typeParam2 entry can simply be empty "".In the section, we use a tag pair so we can insert whatever we want to display as a "tooltip" when the mouse is moved over the cover.In Max, you must now use the Animation Manager tool to assign the XML code blob to the part. Use the Attachpoint tool to assign the XML code blob's information to the part.Now it should export and animate properly! ;)

[Guest fbnweoghnwd]

Thanks a lot, Bill. I tried using your code verbatim. The switch is now animating, but there's still a few kinks: It displays the tooltip and hand cursor, but it doesn't wait for mouseover - the switch animation plays as soon as you load the aircraft. It loops continuously - going from closed to open, then starting over and over. Any thoughts?

[ozbeowulf 0]

I'm using the following code for an FS9 B307 landing gear switch. To raise the gear, the guard is moved aside with a mouse click on the top left portion of the gauge, then the switch is operated with a mouse click on the right side of the gauge. Finally, a click on the lower left mouse area flips the guard back to the right, covering the switch. When lowering the gear, the mouse click sequence is reversed. Sounds confusing, but actually it's intuitive in practice. Note: There are three guard bitmaps because in one position the guard simply keeps the switch from being moved up but in another position it rests on the switch handle in the up position. (The third position is open.) (A:Gear handle position,percent) 50 > (L:GearSwitch,enum) (L:GearSwitch, enum) ++ 2 min (>L:GearSwitch, enum) (L:GearSwitch, enum) -- 0 max (>L:GearSwitch, enum)Landing Gear Good luck,Glenn

[Guest fbnweoghnwd]

Thanks, Glenn. But I think I'm on the right track with that code that Bill posted, so I want to keep going down that road. I want to keep this as a 3D switch in the VC. In fact, other than the main panel, I don't plan on having any 2D panels.

[n4gix 4,947]

>Thanks a lot, Bill. I tried using your code verbatim. The>switch is now animating, but there's still a few kinks: It>displays the tooltip and hand cursor, but it doesn't wait for>mouseover - the switch animation plays as soon as you load the>aircraft. It loops continuously - going from closed to open,>then starting over and over. Any thoughts?Let me think on this some more... it's late here and I'm tired. I've been working on a DO328J model since 8:00 am and it's now 10:05 pm here in Indiana... ;)I've run into this "looping issue" before in FSX, but I forgot what I did to fix it. In the morning, I'll whip up a cover, add the code and test it out for ya.It won't be wasted effort, since I'm going to need it myself for the DO328J's overhead... ;)

[Guest fbnweoghnwd]

Sounds great, Bill. That makes two of us who are burned out right now and need to get some shuteye.Now, another thought...which hopefully won't keep either of us awake: Now that we know how to (accidentally) create a looping animation, might that point the way toward a way of creating windsheild wiper animation? That's next on my list, and I wasn't going to touch it with a ten foot pole til I got the switch cover and some other issues cleared up...but it got me thinking.

[n4gix 4,947]

>Sounds great, Bill. That makes two of us who are burned out>right now and need to get some shuteye.>>Now, another thought...which hopefully won't keep either of us>awake: Now that we know how to (accidentally) create a looping>animation, might that point the way toward a way of creating>windsheild wiper animation? That's next on my list, and I>wasn't going to touch it with a ten foot pole til I got the>switch cover and some other issues cleared up...but it got me>thinking.I've already developed the XML for windshield wipers for FS9 (posted in the "Working XML Parts..." forum at http://freeflightdesign.com and it will simply need to be "translated" to FSX's XML schema.

[n4gix 4,947]

Here is the working and TESTED XML "blob" for the animated switch cover. I had to change the L:var type from "bool" to "number..." :)Note also that the you must be certain to use &gt: instead of the right arrow > symbol in the command.I also shortened the keyframes to 50 (although that's not strictly necessary) and set the value to 200 to make it move more snappily. If you want to make it even faster, increase the value to 400 or so...: switch_cover50 (L:SwitchCover,number) 50 * 200HandOpen/Close Cover(L:SwitchCover,number) ! (>L:SwitchCover,number)Obviously, the next step will be to create your "switch lever" and animate it as need to "switch" whatever it is you want to "switch!" :)

[Guest fbnweoghnwd]

Hmm....the switch is still cycling. Here's what I just tried...it's exactly the same as what you just posted, but with > instead of the forward arrow: switch_cover50 (L:SwitchCover,number) 50 * 200HandOpen/Close Cover(L:SwitchCover,number) !(>L:SwitchCover,number)

[n4gix 4,947]

Well, since I've tested the code in FSX, I know it works...However, I did note that I had to shut down the sim and restart it before the code changes were recognized. I don't know why that might be, but there you are anyway... ;)The only other thing that might be "wrong" is something that went pear-shaped in the Max/GMax model...

[Guest fbnweoghnwd]

Got it working!It turns out that the Attach Point tool & Animation Mgr were using one version of Modeldef.xml, and the compiler was using another. I know you suspected early on that something like that might be happening, but I looked into it and it led me to believe that they were all looking in the same place. In reality, I was adding your revised code to one version, the compiler was working with the older version, and them switches just kept flappin' in the breeze. So now I've got everything pointing to the same place and the switch covers are working great.Thanks a lot for all the help on this one. I think you came up with a really useful piece of code here - which can be used any time something needs to animate on mouse-over.

[n4gix 4,947]

>>Got it working!>>It turns out that the Attach Point tool & Animation Mgr were>using one version of Modeldef.xml, and the compiler was using>another. I know you suspected early on that something like>that might be happening, but I looked into it and it led me to>believe that they were all looking in the same place. In>reality, I was adding your revised code to one version, the>compiler was working with the older version, and them switches>just kept flappin' in the breeze. So now I've got everything>pointing to the same place and the switch covers are working>great.>>Thanks a lot for all the help on this one. I think you came up>with a really useful piece of code here - which can be used>any time something needs to animate on mouse-over.I'm glad you got the path issue sorted out. I have one and only one modeldef.xml file, which is located precisely where the SDK installed it:C:FSX_SDKSDKEnvironment KitModeling SDKbinGMax is "hardwired" to use the Registry path information, so modeldef.xml must remain in that location. I simply Add(ed) that path to Max8 so it will seek and find the same modeldef.xml file. ;)Speaking of "useful XML code," there's a very nice repository of throughly tested code "blobs" here in the "WORKING XML Code Library (Parts and Gauges)" forum:http://www.aerodynamika.com/cgi-bin/yabb/YaBB.cgiSince I build the same models for FSX and FS9, I generally develop the XML code "blobs" for FSX first, then reverse-translate them to their FS9 equivalents...

[Guest fbnweoghnwd]

I have one and>only one modeldef.xml file, which is located precisely>where the SDK installed it:>>C:FSX_SDKSDKEnvironment KitModeling SDKbin>>GMax is "hardwired" to use the Registry path information, so>modeldef.xml must remain in that location. I simply>Add(ed) that path to Max8 so it will seek and find the same>modeldef.xml file. ;)I had a copy in the path you mentioned, and one in a folder that I created called C:FSX_SDK. After that big mix-up, I deleted the one in the default path, and I'm now using the one in C:FSX_SDK exclusively. I agree it makes more sense to use the default path (in fact, I have to keep telling Attach Tool where the file is now).So why did I create the other copy, and why am I using this path instead of the default? There's a process - I think I saw it on FSDeveloper.com - by which you can enter all the command line gibberish into a desktop shortcut, then compile your X files by simply dragging them onto the shortcut. That's the way I've been doing my compiling. But when I first tried this, a few months ago, I found that I couldn't make it work off of the default path. As soon as the command line encountered a path with a space in it, it would abort and tell you there's no such program. Using a path without spaces fixed that.

[n4gix 4,947]

>So why did I create the other copy, and why am I using this>path instead of the default? There's a process - I think I saw>it on FSDeveloper.com - by which you can enter all the command>line gibberish into a desktop shortcut, then compile your X>files by simply dragging them onto the shortcut. That's the>way I've been doing my compiling. But when I first tried this,>a few months ago, I found that I couldn't make it work off of>the default path. As soon as the command line encountered a>path with a space in it, it would abort and tell you there's>no such program. Using a path without spaces fixed that.Yes, I'm aware of that thread - suggestion at FSDeveloper.com......mainly 'cause I wrote it! ;) I also created the FSWiki entry.Actually, I "solved" the issue to my own satisfaction by removing the SDK and reinstalling it to a path with no spaces in it:C:FSX_SDKSDKEnvironment_KitModeling_SDKbinIt's not only shorter and more sane path, but this allows me to have my cake and eat it too! ;)BTW, a nice refinement to the Desktop Shortcut trick is to move it to your ..SendTo folder. That way, you simply right-click on your file and choose "SendToBuild Aircraft" or "SendToBuild Scenery"Your .mdl file will be created in the same folder where the MaxGMax .x file(s) are located.