FL Animations
-
@Freeworlds_Sushi:
Would love to see this tutorial. I could really use it for X-wings/B-wings in FWs.
ive played freeworlds, alot actually
if ya could manage that i would absolutely “try” the mod out ;D
Well then, I better pray that tutorial for this function comes sooner rather than later…lol. -
Sushi, you have been given a link by Mini_Me - I will copy-paste it here.
http://the-starport.net/index.php?option=com_smf&Itemid=26&topic=462.0
This old thread has all the info you need to make the X-Wing and B-Wing S-Foils animated, except for the cruise trigger - I assume that has to be done with FLHook, and we need to get one of our mighty FLHook coders involved
In SHORT - so don’t consider this a tutorial, just some quick guidelines - what you need for animations is:
- Multi-component ships, where the to-be-animated parts (wings) are all separate components
- (So while you are at it, why not make a multi-component sur as well? It does come handy, considering animation, especially on a B-Wing!)
- Having the CMP exported as multi-component, you will need to work with the Cons: Fix, Rev and Pris nodes.
- Fix: your non-animated components come here
- Rev: your animated components come here (in my experience: Rev ==> Revolution, rotation style animation)
- Pris: your animated components come here (in my experience: Pris ==> Translation, moving style animation)
- You can use the XML Project to add/remove nodes in Fix, Rev and Pris (be careful with all that raw data you will manually edit. Use common sense in determining where each part in the node starts and ends. Make sure to change the node size variable respectively. You can use the XML project to modify those parts of the Rev and Pris nodes that UTF Editor will NOT modify for you)
- Make sure you have no doubles! (For example, a component present in both Fix and Rev/Pris) In my experience, an exception to this is the very LAST component of the Fix node.
- Set up the Rev and Pris accordingly - the center, direction and amount of rotation is set up here (or seems to be at least)
- When done, copy an Animation node from a vanilla ship into your very own CMP and modify it accordingly. Refer to Mini_Me’s link to understand how this works.
When the animation is set to be triggered by cargo jettisoning: CTD on pressing F7 ==> You have doubles in your Fix-Rev/Pris nodes.
I hope this helps. Getting the center of rotation done well seems to be VERY tricky and frustrating, or maybe I was just plain stupid and missed out on something. I found that the center of rotation is actually 0,0,0 - the center of the ship (actually, the component), and in oder to move this somewhere else, you have to center your component in MilkShape so that the center of rotation for the component is the very ORIGIN - 0,0,0; and then have the position of the component changed later in the Rev node’s, I think, Offset section.
An X-Wing would need all 4 of its wings as separate components, and a B-Wing its left-right wings as 2 separate components - but if you want to be true to how the B-Wing should work, and make it similar to official games, like X-Wing vs. TIE Fighter, you have to assign the components (somehow) like this:
Root ==> Cockpit
Child of Root: BottomWing ==> The “vertical”, long wing panel which contains the engine area, and the bottom cannon as well, the “horizontal” wings are connected to this
Child of BottomWing: LeftWing
Child of BottomWing: RightWingYou will need to have BottomWing rotate 90 degrees from the bottom to the left side of the cockpit, and have LeftWing and RightWing fold onto BottomWing simultaneously, which is a near 90 degrees rotation. The very problem with this is the changing center of rotation –> everything depends on IF the FL engine supports having multiple parent-child component connections and not just a simple root-allothers style hierarchy.
-
Parent -> Child can be nearly any thing. You can have say… a cockpit as Root & parent, then the body as Child to that, while the body is also a parent to the child wings.
Further, each part can be animated independently. So you could have a funky animated body rotating while some sort of power structure slides up and back along it, each at their own speed.
The Root, however, cannot be animated (it cannot appear in Fix, Rev, or Pris), so keep that in mind. If your design calls for your main structure to be animated, instead use a dummy 4 sided pyramid located out of sight and use that as your Root -if it will be in the open, then use a 0.000000 opacity texture.When importing bases and such, you’ll notice that there are meshes like “door_poly_lod1” and such; those are what make rotating doors a bit easier to work with, as the Door itself is a Child to the door_poly_lod1, and uses it as the center / base of rotation.
You’ll also notice in all weapons, the rotating part (turret, barrel, or both, depending on construction) is listed in Rev.
-
Placing that dummy-root pyramid: I’d say put it into the very center of your ship, if possible… In my experience, NPCs will always fire at the center of the Root - and if the Root is not inside the ship, the NPCs will have some rapid horrible aim.
-
Thanks for the help, guys. I’ll definitely be looking into this more and tell you my results of it.
-
A couple side notes:
- As mentioned by BBalazs, the part will use its 0,0,0 origin as the rotational point. This is why we see doors on many base models all biffed up when importing into Milkshape. Previous importer versions did not take offsets into account when importing, so they all ended up at their natural origin of 0,0,0.
This has two side effects:
-
You can leave parts where they are within Milkshape, and have them rotate or slide from there. To see this, have a look at my Hive Habitat; both side rings are exported exactly as they appear there, so no further offset modification was necessary, it is a spherical model after all. I was working on a funky pyramid base with outer walls as kind of armor. Each wall was child to a telescoping arm, child to a central pivot. The inner walls were solid but for one opening, so if you timed it right you could actually get inside and dock with the base itself. Unfortunately, working with only 4 walls ends up requiring 16 parts due to each component only able to rotate or slide on one axis. So that left 2 meshes for the rest of the base
![😕](https://the-starport.com/forums/assets/plugins/nodebb-plugin-emoji/emoji/android/1f615.png?v=mhmq9j4qrjg ":-\")
not real ideal. Just a little tidbit to keep in mind. -
Or you can do the most common method; move your moving parts to 0,0,0 and then tweak their positions via offset. As noted, DA used polygons as bases of rotation for doors. So parent = door_poly01, child = baydoor_1 etc. This allowed them to place the poly where it needed to be and only need to tweak small amounts from there. Crack open an Outpost to have a closer look at this.
- Just because an item is located within Fix or Pris does not mean it can’t be attached to a Rev component or vice versa. This is another area Parent -> Child relations play an important role. That’s how I managed to attach working dock doors to the central rotating rings on the Habitat, and the side rings rotating on X, while central rotates on Z. It’d be nice in the future if we could exceed 18 (or was it 21?) parts for cmp export. But still, there’s quite a lot we can do within the current limits.
Good luck animating
-
Good point w0dk4. You can create the node name, but that’s it really, or you can copy over a node from another cmp file. In either case, you’ll need to hex edit the contents to add / subtract parts within the node data.
To do that, I usually keep an exported Fix, Rev, and Pris file handy. Open a file with the required node already present, select the node, then click the “Export” button and save it as a .bin so you know what it’s for; example: “RevTemplate.bin”
You really only need one entry in each for a template, since you can select all -> copy and then paste once for each new additional part. After re-saving the modified .bin file with your to-be-modified cmp’s name, switch back to UTF editor and this time click the “Import” button with the corresponding node selected. Re-save the cmp, then use UTF v4 to edit the numeric values, and UTF v3 to edit the strings (parent / child names) via the “Edit XXX data” buttons. You could edit these names while in your hex editor, just be sure you know the character length limits of each name (mentioned earlier in this topic). -
Btw.: Could someone upload the UTF Editor v1.3 somewhere?
Because I couldnt find that version anywhere on the net
Not a big surprise W0dk4 as that version was never officially released, I’ll have a look in my files and upload it in a bit.
EDIT
I’ve uploaded it to the downloads section, but as it hasn’t appeared I guess it needs someone to authorise it first.
-
@Freeworlds_Sushi:
Would love to see this tutorial. I could really use it for X-wings/B-wings in FWs.
ive played freeworlds, alot actually
if ya could manage that i would absolutely “try” the mod out ;D
Well then, I better pray that tutorial for this function comes sooner rather than later…lol.Check our boards Sushi
I’ll release the tutorial later on here at TSP, if it is helpful within our dev team.w00t:
-
Would someone take on making the wings on the Rheinland Valkyrie work? It has the slots under each wing near the fuse-lodge to appear as if they actually move.
I feel that all the parts that appear to move, should actually move as in w0dk4s vid. Bay doors open etc…etc…Why not everything this is supposed to, do so? ;D
Hop to it you guys.
;D -
Would someone take on making the wings on the Rheinland Valkyrie work? It has the slots under each wing near the fuse-lodge to appear as if they actually move.
I feel that all the parts that appear to move, should actually move as in w0dk4s vid. Bay doors open etc…etc…Why not everything this is supposed to, do so? ;D
Hop to it you guys.
;Ddo you mean this: http://www.youtube.com/watch?v=CDJtW-HvbEw ?
