New animation

hurry!! I WANNA SEE! ;D

let me guess ::) you copied the nodes from the crusader and put them into the defender, easy enough to do, but still leaves you with finding a trigger to use it properly rather than replacing the baydoor animation.

;D Did the same thing back in February with the rheinland battleships baydoor animation, I transfered it to a custom base I was working on, I’d already worked out the coordinates for the “origin” in the “rev” data, it just took a lot of trial & error to get the orientation & Rotation Matrix lined up properly.

@Bejaymac:

…

PS that’s v4 of UTF_Edit, I think it’s still classed as a beta, meaning I doubt if it’s publicly available for general use yet, :-[ sorry for teasing everyone with it

Any idea when that sucker might be available? Looks like it could really be put to good use.

MK

hi, im sure some remember me…

i had planned writing a full tutorial on this, since ive also worked it out a couple of months ago.
unfortunately the “demo object” (a huge custom base) is still being worked on. (paintjob)
first you need utf_edit v1.3, the one i have. (or higher obviously)
it lets you edit the fix/rev components position/rotation etc.
cause in milkshape the pivot will be the origin, so move components there, and edit the offset later.
second, you can use the utf2xml tool to add/remove fix/rev/pris nodes, move multiple hardpoints to other groups, clone component/animation nodes, etc

Animation
± Script
± Sc_example_0 <- name of animation
± Joint map 0 <- a joint for each rev component
± Channel
± Frames <- frames of animation
± Header <- type of animation
± Child name <- name of rev component
± Parent name <- name of parent (ex. root)
± Joint map 1
± Ch…
± Fr…
± He…
± Ch…
± Pa…
± Sc_example_1
± Joint map 0
± Ch…
± Fr…
± He…
± Ch…
± Pa…

so far i know of 2 animation types…

movement (ex. station_large) <- havent experimented with this yet.

header:
0.000000
1.000000
0.000000

frames:
0.000000 <- guessing frame/position
11.813642
23.627285
35.440926

rotation (ex. station_small)

header:
0.000000
-1.000000
0.000000

frames:
0.000000 <- frame
0.000000 <- rad
40.000000 <- frame
3.137226 <- rad
40.166668 <- frame
-3.132870 <- rad
80.000000 <- frame
-0.008720 <- rad

change the frame values to modify the speed of animation,
edit rad to change speed/rotation/direction. (direction can also be changed by editing the components orientation)

and here are 2 screenshots, dont have game recording tool installed atm.
the base is made of more than 80 components, had to do this to get a working sur with the sur splicer.
proves that you can have many component and animation nodes btw.
the radar on top and the ring section with its turrets are revolute, spinning.
the baydoors are working like on vanilla bases, except i let them open to the outside.
dock animation can be set in solararch.ini, the other have to be put in select_equip.ini and attached via loadout.ini

base showing its firepower:

docking granted:

I do remember your name.
Welcome to the Startport RimShot!

I can’t seem to find utf2xml… I remember I’ve seen it somewhere not too long ago, but I forgot… Any help?

Hi RimShot long time no see ;), welcome to the Startport

@ BBalazs, your looking for the XML Project by SIr Lancelot, you’ll find it in the downloads under ‘F’.

Thanks, got it. Silly me, was looking for utf2xml all the way.
I managed to get a fully working baydoor animation, on a completely custom capital ship. Naturally, this needed the CMP to be exported in such a way.
With the animation in the CMP done, there is only one question left - making a sur file that adjusts accordingly - so that if the baydoor is open, fighters can fly inside, and when it is closed, they can’t.

This might fit into another topic, but… oh well. Do any of you know what is needed in the sur so that the baydoor will be accepted? I assume that needs a multi-component sur, where the baydoor is sur component #2 (or index 1) just like in the CMP, but this leaves me with the dilemma of constructing the rest of the sur - there is a ship, with a big hole (hangar) on the inside - thus it is pretty much impossible to make the first sur component convex. I guess the solution would be to have sur component #1 a convex part of Root, component #2 being the bay, component #3 being another convex part of the root, #4 being another convex part of the root - or what I am speaking is simply terrible nonsense. Please correct me - oh and while you are at it, call ms3d groups ‘groups’ and sur groups ‘components’ because I tend to mix them up when reading others’ notes. Thanks loads for all your help!
I might just post a video if everything works out nicely.

WAAAA rimshot long time no see

Here’s what I managed to get to work. Not the best footage, but I think you can see the hangar door opening and closing.

http://www.youtube.com/v/YIxWWLkzoQA

@Worfeh, Bejaymac, cheese on toast: thanks guys, hows the modding?

@BBalazs: ill be back in couple of hours, gtg now…

Evenin Rimshot - nice to see you’re still alive and kicking (or modding)

hi Chips

@BBalazs:

Do any of you know what is needed in the sur so that the baydoor will be accepted?

yes it needs a multi-component sur, the rev component and sur component are linked by name.
best results i got with the sur splicer, i suggest you have a look at it.

example:
ISD.sur
ISD_cons_fix.dat
250
1000000 1000000 1000000
ISD_main.sur Root <- component name
ISD_zomgbayz1.sur zomgbayz1 <- component name
…

@BBalazs:

there is a ship, with a big hole (hangar) on the inside - thus it is pretty much impossible to make the first sur component convex.

the ordering is up to you. also, not all components need a sur, incl. root.

like my base, none of the visible components have a sur, ive linked them all to dummy groups.
i suggest when you export the cmp from ms3d, include one dummy group.
later you can clone the dummy component for how many dummies you need to get a working sur.
that is because all single surs should be made of simple objects (box, circle, cylinder).

for revolute components, ive already mentioned that the 3d origin will be its pivot point.
so that should be their position in ms3d, and when you export the sur for the rev component put it at the same place.
the position offset can be edited later with utf_editor, the sur component will follow it.

if you need multiple surs, thus multiple components for an animated part, then just put all the dummies in the animation node.

hope it helps.

Thanks for all the valuable info Expect feedback by about the end of next week, unfortunately I do not have too much time until then - still, enough to go through your post word-by-word, carefully understanding it to the last bits

Decided to do it earlier than I planned to - was just interested to get it right. My problem is, I can’t get any collission detection, except for the “Root” part of the sur.

I have no clue what is wrong. I built the SUR of simple boxes (I didn’t even extrude them) - that made up 15 boxes. I exported them as separate surs, so that results in 15 surs. I used splicer to add them together into one file. Added 13 dummy groups to the CMP file, exported it as multi component ==> 15 groups (ship, baydoor, dummies).

Imported the ‘fix’ data generated by the splicer, and made sure that all object names check out. I even tried making all those object names lowercase, to see if it is FL’s case sensitive behaviour, but no…

If I remove the dummy groups from the CMP, HardCMP only shows those parts of the SUR that are fixed to the ‘ship’ and ‘baydoor’ parts (more precisely, ‘Root’ and ‘BAYDR-L1_lod1’. If the dummy groups are there, the whole SUR is shown, so the names must check out.)

One last thing I have in mind, is that I used the ‘update cmp’ function of the exporter, to update the dummiless version of the CMP. I did that because I had problems with the Pris node causing a CTD; but if I update the old, working model, there is no CTD and the animation works too - only collission detection fails.

Edit: Not even on an animationless, newly exported CMP. Object names match, of course…

Edit 2: Alright, I think I got it. It seems to have been that File name and Object Names were identical (except for the .3db extension) - so I had them replaced. This was partially the cause for the lack of collission detection - the other cause was splicer’s nature to produce surs that don’t like vanilla solars. I attempted to make the nose of the ship the root, knowing that in case of such a big ship that is the only likely cadidate for solar collission. Unluckily, however, it seems that NPCs will fire at the center of the ship’s Root. This results in completely stubborn hostile NPCs, and their tendency to fill the nose of the ship with projectiles, which just looks crazy. I know that multiple-component surs have been made in the past, I found some excellent tutorials by BJ and CV in the archive. Problem is, they rely a lot on images that do not exist anymore. I suppose that exporting a multi-component SUR straight through the 1.1 exporter isn’t that hard; my question, however, is, what makes the sur link up with the components in the CMP? I presume that’s the ms3d group’s name; does it have to fit the Object Names in the cmp?

(looks like I’ve steered this topic way off animation in the direction of sur files, I’m sorry about that)

Edit 3: Nope. Damn thing only recognizes the root, splicer or not, when it comes to hitting stations…