New animation
-
hi Chips
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
âŚ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.
-
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âŚ
-
Hmm those warnings happen sometimes to me as well, on occassion, but they did exist even earlier than I started fiddling with animation, and even then, the server worked just fine (and the game as well).
Check for faulty âFixâ and âPrisâ (or âRevâ) entries. They can make the game crash - the âFixâ node once crashed me on launching, it was a typo in there.
Another mistake that caused CTDs was: Faulty filenames in the cmpnd node, did not pair up with the 3dbs.
Iâd place my bet on the Fix node, because you naturally exported the thing as multi-component.
-
Through trial and error, Iâve determined that the problem is definatitly not in the fix node, but in the rev node (I deleted only the rev node and the crash went away, although if I tried to eject cargo the game crashed as the animation node had nothing to refer to). The parent and the child are both named correctly. Of course, I donât have much choice; Iâm not sure if itâs an error in v4 of UTFEdit, but I canât rename anything in the rev node; I can edit the names in the fix node fine, just not the rev. Damn you BJ, sending me a product that doesnât work So, if it isnât nicknames, what else in the rev node can cause a crash?
And as a side note, what exactly does the pris node do?
MK
-
@mknote:
did you copy+paste the header+frames data in utf editor?
if so, try using the export+import buttons instead.
also, mismatching parent references in rev node / animation node lead to a ctd on game exit.
its been a while tho, hope my memory is correct⌠-
**Well, from my work over the past week, the Pris node is for your baydoors. The Fix is for fixed hardpoints, the Pris is usually used for the baydoors and the Rev is for your Revolute hardpoints.
The layout of the Fix node is different than the other two, the Rev and Pris follow the same format.
There is other bugs in that version, I do not use it to do any editing with because it have a string problem.**
-
Look at the Liberty Dreadnaught, that is where it is used for baydoors. Rev and Pris are the exact same format so it would stand to reason both can be used.
-
I used Pris for the baydoors on the sleepership, a copy from the Rheinland Battleship. Iâve also witnessed the problem that it almost seems that the node is âwrite-protectedâ (even though it actually isnât, of course) - but you simply canât modify it.
I once fooled it into working by making a copy of the Rh battleship cmp, and continuously replacing it with the data of my own CMP. That is why the baydoor of my sleepership is called baydr-l1_lod1 (that is the object name, the file name is baydoor_lod1.3db).
-
Curiouser and curiouserâŚ
Well, I changed Rev to Pris on a hunch, no change whatsoever. But I noticed something odd in-game. On the base, before the launch-and-crash, I noticed that my ship components had all⌠dissappeared. Only the Root and the two baydoors were visible, an understandable mistake given that that compomises 80% of the ship. In addition, the baydoors were above where they should be, and slightly offset to the left and right. When I open HardCMP, well, the baydoors are in that position and also where theyâre supposed to be! Thatâs right, two sets of the same mesh in different locations. Wiskey Tango Foxtrot? I changed the origin on the Rev (I changed it back from Pris for no reason) and nothing happened; in-game, the baydoors were still in the same spot, and HardCMP showed exactly the same thing. Iâm confused.
MK
edit
Please excuse the blood, but itâs because my head is bloody because I banged it so hard against the keyboard for being stupid. The reason changing the origin didnât do anything is because I forgot to save The baydoors are now in the right position, though their angle is off, but the crash remains.
edit2
Huh. I set the angles to zero and it now appears in the right position in HardCMP⌠and doesnât appear at all in-game. Also, when I clicked on the equipment dealer, the camera went up, but right when the equipment window was supposed to come up, CRASH!
-
@&$# Now I remember why I stopped doing animations, with UTF v4 you can edit the Fix node to your hearts content, but neither the Rev or Pris will save, I had to butcher the Rev using âfloatâ and gave myself a right good headache, Iâll dig out v3 later and see if itâs the same.
The Fix, Rev & Pris nodes are basically joint locations with Parent & Child assignments.
Fix = This is how the Components (Child) are attached to the Root (Parent), the offset is the location of the âjointâ.
Rev = As âFixâ but is used for animation, generally used for models with multiple joints.
Pris = As above, but is generally only used on models with one joint.
MK check the Fix & Rev/Pris nodes, are your baydoors listed in both, generally non animation components are only listed in the Fix, and animated components should only be in the Rev/Pris, this might explain why you have two sets showing.
-
As it dont save, cant you do it in hex and manually go in that way? (search and replace etc :))
-
QâplaH! BJ was right, the problem was that my baydoors were refered to in both the Rev and Fix nodes; since I canât delete subnodes, I had to find a ship with a Fix node with two subnodes fewer than what I had. Once I renamed everything, it worked peachy. Now, the animation itself is screwed up, but thatâs a matter of origins, axises, and whatnot. Help there would be appreciated, but Iâm just about to begin so I donât know what to ask for.
MK
-
QâplaH! BJ was right, the problem was that my baydoors were refered to in both the Rev and Fix nodes
ah, same thought there but Bejaymac was faster.
since I canât delete subnodes, I had to find a ship with a Fix node with two subnodes fewer than what I had.
run your cmp through utf2xml and look at the generated xml.
have fun editing, then do the other way xml2utf.Now, the animation itself is screwed up, but thatâs a matter of origins, axises, and whatnot.
as mentioned on page 3, the pivot point of rotation is the 3d origin in milkshape.
lets assume you have a box shape, align the bottom left with the origin, then the box will turn around its bottom left.
the position of the box relative to the rest of the model is defined by âoriginâ, when you click edit rev data in utf editor.
ârotation matrixâ is like the orientation of hardpoints, shouldnt worry about this if the orientation is ok on export.
âaxis rotateâ is the other important thing, should be easy enough to figure out. the axis the animation is applied, values of the frames node. -
since I canât delete subnodes, I had to find a ship with a Fix node with two subnodes fewer than what I had.
You can delete them MK, but you need to do it using âinterpret dataâ, using âfloatâ you will find something like this.
75879931235666218000000000000000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 78682151728776971000000000000000000.000000 4740101122411936900000000000000.000000 15270985670545095000000000000.000000 70366722061431311000000.000000 17666323175581866000000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 75879931235666218000000000000000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 78682151728776971000000000000000000.000000 4740101122411936900000000000000.000000 16273113490958152000000000.000000 0.000000 73153541666658487000000000000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 75879931235666218000000000000000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 78682151728776971000000000000000000.000000 4740101122411936900000000000000.000000 16273113490958152000000000.000000 0.000000 73153546389024969000000000000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 75879931235666218000000000000000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 78682151728776971000000000000000000.000000 281688317150816630000.000000 15270983309361854000000000000.000000 70366722061431311000000.000000 17666323175581866000000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 75879931235666218000000000000000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 78682151728776971000000000000000000.000000 281688317150816630000.000000 16273111185115143000000000.000000 0.000000 73153541666658487000000000000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 75879931235666218000000000000000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 78682151728776971000000000000000000.000000 281688317150816630000.000000 16273111185115143000000000.000000 0.000000 73153546389024969000000000000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 75879931235666218000000000000000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 78682151728776971000000000000000000.000000 17025421289908726000000000.000000 73153820286280976000000000000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 ```This is the Fix node from my copy of the Fury, minus the baydoors. From the first "75879931235666218000000000000000.000000" (Root) to the next one is the data for the first component, it's a simple case of counting down till you find the data for your baydoors (as listed under the Cmpnd node), not sure if it's a v4 problem but you will have to alter the Child names in the Fix after you've deleted some of the data, as the part of the remaining names are missing. You can also do the same with the Rev, but you'll need v3 to fix the Parent & Child names.