Synide
-
Content Count
984 -
Joined
-
Last visited
-
Medals
-
Medals
-
Posts posted by Synide
-
-
Hi,
Detailing a new skeleton and joints through a model.cfg would be easy for your new animal.
If your developing your model in another 3D application like Maya, 3DSMax, Lightwave, modo etc. and then animating it you need to get those animations over to the Tools Suite.
This is a bit difficult to do but not to bad if you know what your up too.
At this point you may think that's all... but, then you've still got to do the config.cpp which usually aren't to bad, but since you're doing .rtm's you'll need to properly define & setup all the CfgMoves for the animal. Which essentially describes how all the .rtm's interpolate 'tween each other in certain game situations. This isn't a trivial task.
On top of that you've got to do 'geom' .p3d's for the CfgMoves 'states'... Then at that point you might be getting close to having a working animal.
But, you'd also probably want to do 1 or more .fsm's to provide arbitrary behaviour during simulation... Never really got into .fsm's tbh, not pretty things to get running properly imo.
would it be possible to use the existing rtm files for goat, or any other animal, and then define what objects from my model represent a bone.?Maybe, but a bit on the ichy side... Do you know what the skeleton/joint structure that those .rtms for the goat were made with? I suspect not. You'd have to acquire that information through use of community tools. Then, depending on how good you are you may have a few niggle issues with weighting your moose to the expection of the .rtm's. Also, the .rtm's are sized specific so when you moose moved it's leg forward using the goat .rtm it would only move the distance that a goat's leg would move... So, all up I'd say this isn't a feasible idea.
Or use the human skeleton and have it animate in a way similar to an animal?The only reason you'd want to do that is because you weren't confident in creating a new model.cfg skeleton/joints definition file. This would be one of the less difficult things to do for your moose.
Unless you're well versed in all this stuff I'd suggest you've got a great deal of heavy work in front of you.
-Sy
-
who told that ?That would have been me... See Multimaterial. It can take _smdi textures too and the Shader just uses default values.
The majority of default BIS content uses _dtsmdi's in the 'multi' shader .rvmats.
-Sy
-
The red channel should be 100% white. I think texview or buldozer will force that at file conversion time.If you are satisfied with the look you get, then that's what matters. How glossy a surface is not inversely proportional to how reflective it is, though. I'm sure you can name a few materials that are both dull and rough or shiny and glossy. The gloss map helps you differentiate between the surfaces of different materials.
That's quite true... if he was using a '_smdi'. However, he's using a '_dtsmdi'. Multi shader .rvmats use 'dtsmdi' maps in the specular stages. They can take an 'smdi' as well and the Shader uses default values. And, although he doesn't mention it that's what he's using his spec maps for at the moment.
See Multimaterial on the biki for details.
Also, as for the color variation he mentions in his first post. One should keep in mind that the filter he was running that comes as part of the tools installation is used for creating '_sm' textures. Then, when TexView2 saves it out it processes based on TexConvert.cfg and writes out a different result to the one you see after running the filter. Not a big deal, but can cause a little confusion I guess.
-Sy
-
If you so desire you can specify your main '_co' color texture that you would normally put in the 'texture' field of face properties in a 'stage 0' in the 'super' .rvmat.
That's fine.
But, most modellers who use the 'super' .rvmat specify this 'primary' color texture in face properties so that they can 'see' it in the O2 viewport when DirectX shading is enabled.
It's not uncommon though for people to specify the 'primary' in 'stage 0' only and not have anything specified in the 'texture' field of Face Props.
Also, you can have two '_co' color textures if you desire... You can have one specified in the 'texture' field of face properties and another specified in a 'stage 0' of the .rvmat.
IF the 'super' shader happens to find a 'stage 0' specified it just 'blends' the pixels found in that image with whatever pixels happen to be specified for the 'primary' texture in face properties.
It's rare though that people make use of this two color texture capability.
Simple really.
-Sy
-
In theory, this shouldn't happen... because the model you have open in O2 has already been read into O2 and then the file handle is closed. The only thing you should loose is the latest edits you've made to your model since you last pressed ctrl-s.
However, in saying that obviously something's gone wrong somewhere along the track. Send me the broken .p3d you're trying to open and if you've happened to have made a .pbo of the model recently send that too. You'll find my email in my signature.
I'll have a squizzy at it and see what I can do... no promises though... It sounds like in all likelihood it's screwed so you may have to start over.
-Sy
-
Suck-it-an-see task? Arent you the wise guy.The subject was turned over on visitor 4 for arma2, and since I had experience with it trying it, I might aswell tell my story with what I ended up with while doing so.. Not everyone has these tools, so there is very little experience with this task I would assume. :)
I expressed a desire to use and edit a visitor 3 mapfile (wrp) in visitor 4. Getting it from visitor 4 to A2AO is another matter in my story. I didnt get to that. Modkalb had luck by using the other exe with buldozer. I didnt. Thats how funny arma tools can be sometimes. It isnt a path problem, and it isnt a "simple task" to replace any .exe files. These are the first things anyone who has a slight clue on how it all works, tries to do, including me. When that doesnt work, what then? Ignore it?, or post the results/questions on Bi forums when you've run out of ideas? I think forums are made to discuss solutions, talk experience, help out and even ask for help. Funny thing you say its the wrong forums. Where then? Because thats the same thing I would be getting on VBS forums.. Mostly because its for another GAME.. So no matter where I write it, I would get that and some awesome moderator would lock it, twice.
Thanks for taking the assumption that I have made no effort, and have tried nothing myself before even thinking about making a post on this forum.
If I sound slightly annoyed by that, its because I am. :o
Perhaps a bit of a case of 'lost in translation'. I shouldn't use 'slang' in my text as you've appeared to get the completely wrong intention. I don't think I typed anything there that gives the impression I'm assuming you've made no effort. But, I apologize if you've interpreted it that way.
In principal though because you're talking V4 you really should be talking about it over in the VBS2 forums, even if, unfortunately you don't get the responses you're hoping for. It's unlikely your posts would get 'locked' over there whereas it's a higher percentage chance they will here.
I understand you're frustration though as essentially you're wanting to use V4 in a non-standard usage scenario so you're unlikely to get a lot of help over in the VBS2 forums from support staff as it's really outside their scope to do so. This then means you're reliant on VBS2 end users that may have a foot in both camps to pass on information. I hope this response hasn't dampened you're enthusiasm or annoyed you.
-Sy
-
So you mean tools to convert the WRP from V3 to V4'ish, and then buldozer should be able to connect properbly without crash?What tools might that be if you dont mind me asking? ^_^
You expressed a desire to use the output map from your work in V4 over in A2OA and he was commenting that you'd need to use one of Mikero's tools (or know what to change manually) on the .wrp that is pumped out by V4 to change it into a .wrp that binarize.exe in the A2OA tools will recognize and then process properly so it can be used in A2OA.
As a VBS owner, I can sadly tell you that even though Visitor 4 can import and manage visitor 3 maps, and seems to do it fine - buldozer can and will not start up because of p3d files are made different. Cant remember the exact error.Perhaps if you posted the details of the error you were having in the VBS2 forums you might get a solution. I can't imagine V4's buldozer would have difficulty displaying A2OA binarized .p3d's and I know it'd have no problem with mlod's so it may be just a pathing problem.
If it does have problems rendering OA binarized .p3d's then yeah, it's a simple task to replace the VBS2 buldozer.exe with A2OA's game.exe temporarily so you can view the OA content when you're working in V4... mmmm... but then you might have trouble viewing some of the VBS2 tools supplied .p3d's if you use those in your map.
I guess it's just a suck-it-an-see task. Anyhoo, wrong forums for this subject matter anyway.
-Sy
-
I did a doc a long time ago about ladder dimensions but can't lay my hands on it atm... so from memory... i think i used to make the 'rungs' about 225mm - 250mm apart and about 40mm thick and about 400mm wide. There was I remember a sweet spot though in the size... Hopefully, I'll track down that document, but if not trial & error on your part is your best bet.
Also, you wanna have the ladder extend about 800mm I think above the point where the character gets off the ladder so it doesn't look like he's climbing in mid-air.
Don't take those dimensions as accurate though, my memory is not what it used to be. However, there is a good'ish way of you getting it fairly accurate. And, that is slap a character model temporarily into your building model and apply the climbing ladder .rtm to it. Scrubed it through and adjust your ladder topo appropriately.
It's not the quickest method in the book, but making all your models relative to the anims that will eventually run on them is pretty accurate. Don't ask me to remember the name of the climb ladder .rtm... you can track that down I'm sure, or someone else can let you know it.
-
If it uses three, then I might aswell have object specific textures even when they're not visually necessary..?As Max Power said, it'll do at least 3 drawcalls for the 3 different groups of polygons that represents your 3 different models irrespective of whether they carried completely different sets of textures or not. However, if you can share or reduce the number of different textures used by all three models this would be more optimal I'd imagine than say having 3 different (but similar) models and 3 different but similar sets of textures.
What i mean is... if you had say 1 model with 3 different texture 'sets' which may (or may not) end as say 3 drawcalls & you had 3 models with 1 texture 'set' also ending up as say 3 drawcalls, both these scenario's are better than having 3 models with 3 different texture 'sets' if ya get my meaning.
-Sy
-
Did you manage to test it by crashing a helicopter/plane?Yes I did manage to have a wee test. Log a CIT report. It's a bug in the in-built 'destrType' code for the 'DestructWreck' functionality I'd guess and you can't fix or alter that functionality. The settings I described previously are the req'd minimum settings so leave them as is in your model. When the bug report is resolved it should work as prescribed. That's of course if during bug fixing the functional requirements don't change.
If, and only if, you really can't stand it, you could develop a workaround in the form of attaching a killed eventhandler to 'air vehicles' in general and have the ensuing scripts remove and create a static variant of the destroyed model for the various air vehicles.
-Sy
-
but if i fly and crash it the wreck spawns upside down and at an angle still?mmm, maybe that's a bug. I'll test it here too and see if i get the same result.
I also put the 4 points in the wreck model lod with the proxy too? :confused:In your wreck model you really only need several Resolution LoD's, 1-2 ShadowVolume LoD's, a Geo LoD and a LandContact LoD. The Geo LoD should have the typical autocenter=0, prefershadowvolume=1, sbsource=shadowvolume. Make your LandContact last by selecting 3-4 points from your GeoLoD and copy-n-paste them into your LandContact LoD. Then copy those same 3-4 points over to your 'wreck' LoD in your original model. And, finally place a proxy from the original model wreck LoD to the wreck model. Once you have the config class attribute setup too it should just work.
Btw, which version of the game.exe are you using?
-Sy
-
yeah, what thromp said... just put 3-4 un-named points in the wreck lod along with the proxy triangle. situate them along the belly of your chinook as your wreck model probably doesn't have any wheels right?
-
Hi,
Updated first post to version 3.0.1.0.
Cheers, Sy.
-
Cuz I cant figure out how to center my pic in gimp2, and i can in windows paint and windows paint wont open tga.You should be able to do a google search for 'how to center my image in Gimp'. I just did a search and it appeared to come up with some useful info.
I just downloaded Gimp 2.8.2. Opened a .tga converted from .paa by TexView2. Exported as a .tga as another filename and specified...
RLE Compression = OFF
Origin = Bottom Left
... It opens in TexView2 fine.
-Sy
-
convert a paa to tgaDirectly after converting to .tga from .paa can you open this .tga in TexView2?
then open in gimp2 and convert the tga to jpgWhy would you need to convert the .tga to .jpg? Can't Gimp modify .tga?
then make edits to the jpg, and then convert back to tga, now problem arises now that i cannot convertthe jpg to the paa
This is unclear. So, you're trying to open the modified .jpg in TexView2 or the modified .tga?
I'd suspect, without seeing a .tga you've saved out of Gimp that this program is saving a variation of the .tga format that TexView2 doesn't like. It only eats a particular type of .tga.
So, if after converting from .paa to .tga if you can immediately open this .tga in TexView2 and then later once you save a modified .tga from Gimp you can no longer open this .tga then I'd suggest it's a problem with Gimp. At a guess. Could be completely of the mark there.
-Sy.
-
mmm... perhaps also try adding 'mala vrtule blur' & 'velka vrtule blur'...
-Sy
-
try adding 'mala vrtule staticka' (for the tail rotor) & 'velka vrtule staticka' (for the main rotor) to the hiddenSelections in your new config class for this model. then try the 'setObjectTexture'...
-Sy
-
Currently I'm trying to weight a woman witch is smaller than the male model. Do I have to scale it up in order to the animations work properly?Probably. It depends on how much your new character model is different in size, shape and volume. The majority of the animation files (.rtm's) have been created to work with a standard sized character model. If you then apply these .rtm animations to a new model that is too different it's going to look odd.
Here's an extreme example. Imagine you have a current .rtm that moves the standard sized characters left arm across the front of his body and replaces a mag in a weapon being held by his right hand. Now imagine your new character has an enlarged stomach, chest area and you apply the same animation. It'll end up looking like the left arm/hand is now moving through the new characters stomach/chest on it's way over to the right-hand side. Not, very good eh?
The anims are size specific. Generally, people have not made characters dramatically different in size and shape because they'd have to go ahead and create an additional set of animation .rtm's to cover all the moves this new character would be performing. While it is feasible to do this, in practice it's takes time and alot of patience and technical ability. If you have a mocap setup and a refined workflow to move the data into .rtm format then it's not so much of a hardship to have a different sized character. But, most modders don't have this sort of workflow available to them. So, they'd have to create each required .rtm by hand essentially. A rather daunting process.
-Sy.
-
Why don't i see the center of gravity ?Probably because he has his O2 viewport in DirectX mode... never fear... it'll be there, you just can't see it in that screenshot atm.
@Myke... Do you have a proxy in the GeoLoD yet for the 'driver' or is it just hidden in the screenshot. If not, try defining one and rebuilding. Although it won't be hurting your model.cfg in the CfgModel section you have it inheriting from class Default which you have defined just above. You don't really need to do that because your class Default basically defines nothing at all.
Was there anything interesting in the build.log? When you're testing it in-game is there anything in the runtime.log?
-Sy.
PS. Oh, and where is the CoG of the model atm?
-
This is a super shader .rvmat correct?
Try just pointing the AS map from the .rvmat at a 'new' UV map, one without the poly's for the wheels in it and leave the other textures for normalmap, dt, spec, etc., pointing at the current uvmap with the wheel poly's in it.
Give it a go. Should be fine.
-Sy
-
Will this app work with the ARMA game engine too ?No, it will not.
-
Yeah, sorry true... memory isn't the best nowadays... was having a senior moment 'tween vbs2 functionality & oa functionality.
-Sy
-
Myke;2198754']cfgWeapons doesn't support eventhandlers.Since when? It used too' date=' has something changed? I mean some 'eventhandlers' are ofcourse meaningless in certain 'simulation' types but for instance a 'fired' eventhandler in a CfgWeapons.YourWhizzyClass.EventHandlers should work fine.
But sticking a 'fired' eventhandler into a 'building' simulation would obviously be incorrect.
I have used "Class Eventhandlers" and added it to my weapon's class in CfgWeapons - the path and syntax are correct, but for some reason nothing happens.Perhaps if you post your excerpt from your config someone might suggest what the problem is...
-Sy.
-
The short'ish answer is that most of the female models already present you'd need to physically edit the models in one way or another as many have abbreviated Skeleton definitions embedded.
The attempts by various people to muck about with female characters have been based generally around manipulating the standard BIS released male models to 'look' more feminine mainly because there is not a large stock of female sized animation .rtm's available and so you need to use the male sized .rtm's.
The upshot is there are alot of cavets, gotcha's and eula infringements envolved. So, while not impossible it's just not really practical or legitimate to do.
-Sy.
PS. Oh, and to answer your question specifically...
Can I, using the ingame civi female models, replace the custom female soldier models I've found that are built around the male skeleton?No, you could not do that because the proxy's for weapons, launcher's etc. do not exist in those models.
Arma3 Characters Modding Tutorial
in ARMA 3 - BI TOOLS - GENERAL
Posted · Edited by Synide
Yeah, the CfgSkeleton + CfgModel is slightly different, but not overly different. However, there is a disparity 'tween the .p3d's provided selection names and the example .rtm provided.
As I can't see the 3DSMax stuff I'm not sure if the .rtm was produced from that end or through O2. If it was produced from the 3DSMax end then the Skeleton structure used there is slightly different to the example .p3d's.
If the .rtm was produced from O2 then I suspect the example.p3d's weren't used to produced this particular .rtm cause it has the following joints.
Joints[166] = { 0 = "weapon"; 1 = "launcher"; 2 = "RightArm"; 3 = "RightHand"; 4 = "LeftHand"; 5 = "Head"; 6 = "RightLeg"; 7 = "RightLegRoll"; 8 = "RightFoot"; 9 = "RightToeBase"; 10 = "LeftForeArmRoll"; 11 = "RightForeArmRoll"; 12 = "LeftLeg"; 13 = "LeftLegRoll"; 14 = "LeftFoot"; 15 = "LeftToeBase"; 16 = "RightHandIndex1"; 17 = "RightHandIndex2"; 18 = "RightHandIndex3"; 19 = "RightHandMiddle1"; 20 = "RightHandMiddle2"; 21 = "RightHandMiddle3"; 22 = "RightHandPinky1"; 23 = "RightHandPinky2"; 24 = "RightHandPinky3"; 25 = "RightHandRing1"; 26 = "RightHandRing2"; 27 = "RightHandRing3"; 28 = "RightHandThumb1"; 29 = "RightHandThumb2"; 30 = "RightHandThumb3"; 31 = "RightHandRing"; 32 = "LeftHandIndex1"; 33 = "LeftHandIndex2"; 34 = "LeftHandIndex3"; 35 = "LeftHandMiddle1"; 36 = "LeftHandMiddle2"; 37 = "LeftHandMiddle3"; 38 = "LeftHandPinky1"; 39 = "LeftHandPinky2"; 40 = "LeftHandPinky3"; 41 = "LeftHandRing1"; 42 = "LeftHandRing2"; 43 = "LeftHandRing3"; 44 = "LeftHandThumb1"; 45 = "LeftHandThumb2"; 46 = "LeftHandThumb3"; 47 = "LeftHandRing"; 48 = "LeftUpLeg"; 49 = "LeftUpLegRoll"; 50 = "Neck"; 51 = "Neck1"; 52 = "Pelvis"; 53 = "Spine"; 54 = "Spine1"; 55 = "Spine2"; 56 = "Spine3"; 57 = "LeftShoulder"; 58 = "LeftArm"; 59 = "LeftArmRoll"; 60 = "LeftForeArm"; 61 = "RightShoulder"; 62 = "RightUpLeg"; 63 = "RightArmRoll"; 64 = "RightForeArm"; 65 = "RightUpLegRoll"; 66 = "camera"; 67 = "Cheek_LF"; 68 = "Nose_Tip"; 69 = "Lip_UpLB"; 70 = "Jaw_LS"; 71 = "Lip_UpLF"; 72 = "Lip_LC"; 73 = "Lip_LwLB"; 74 = "Lip_LwLF"; 75 = "Jaw_LM"; 76 = "Zig_LB"; 77 = "Lip_LwM"; 78 = "Lip_UpM"; 79 = "Ear_L"; 80 = "Corr"; 81 = "Tongue_M"; 82 = "Tongue_F"; 83 = "Eyebrow_LB"; 84 = "Eyebrow_LF"; 85 = "Eyebrow_LM"; 86 = "Zig_LM"; 87 = "Eye_UpL"; 88 = "Eye_LwL"; 89 = "Cheek_L"; 90 = "Cheek_LB"; 91 = "Zig_LT"; 92 = "Nose_L"; 93 = "Cheek_LM"; 94 = "Nose_R"; 95 = "Forehead_R"; 96 = "Forehead_M"; 97 = "Forehead_L"; 98 = "Cheek_RB"; 99 = "Eye_LwR"; 100 = "Cheek_R"; 101 = "Zig_RT"; 102 = "Zig_RM"; 103 = "Cheek_RF"; 104 = "Cheek_RM"; 105 = "Eyebrow_RM"; 106 = "Eyebrow_RF"; 107 = "Eye_UpR"; 108 = "Eyebrow_RB"; 109 = "Tongue_B"; 110 = "Ear_R"; 111 = "Neck_L"; 112 = "Lip_UpRF"; 113 = "Neck_R"; 114 = "Lip_UpRB"; 115 = "Lip_RC"; 116 = "Lip_LwRB"; 117 = "Lip_LwRF"; 118 = "Neck_B"; 119 = "Zig_RB"; 120 = "Neck_T"; 121 = "Jaw_RF"; 122 = "Jaw_LF"; 123 = "Chin"; 124 = "Jaw_RM"; 125 = "Jaw_RS"; 126 = "Jaw"; 127 = "RightInHandRing"; 128 = "LeftInHandRing"; 129 = "HeadCutScene"; 130 = "Face_BrowFrontRight"; 131 = "Face_CheekUpperRight"; 132 = "Face_CheekUpperLeft"; 133 = "Face_NostrilRight"; 134 = "Face_NostrilLeft"; 135 = "Face_Forehead"; 136 = "Face_EyelidLowerLeft"; 137 = "Face_BrowFrontLeft"; 138 = "Face_BrowSideRight"; 139 = "Face_BrowSideLeft"; 140 = "Face_EyelidLowerRight"; 141 = "Face_Hub"; 142 = "Face_Eyelids"; 143 = "Face_CheekSideRight"; 144 = "Face_CornerLeft"; 145 = "Face_CheekSideLeft"; 146 = "Face_EyelidUpperRight"; 147 = "Face_EyelidUpperLeft"; 148 = "Face_CornerRight"; 149 = "Face_Jawbone"; 150 = "Face_Chin"; 151 = "Face_ChopRight"; 152 = "Face_ChopLeft"; 153 = "Face_LipLowerMiddle"; 154 = "Face_LipLowerRight"; 155 = "Face_LipLowerLeft"; 156 = "Face_Tongue"; 157 = "Face_CheekFrontRight"; 158 = "Face_CheekFrontLeft"; 159 = "Face_LipUpperMiddle"; 160 = "Face_LipUpperRight"; 161 = "Face_LipUpperLeft"; 162 = "Face_BrowMiddle"; 163 = "Face_Jowl"; 164 = "EyeLeft"; 165 = "EyeRight"; };It's probably better if you wait a little for Vespa to provide a properly constructed model.cfg that's being used with all A3 bodies rather than faffing around with a cobbled together one.
-Sy
PS: So, just to clarify the above list is not the Skeleton but just a listing of the joints in the example .rtm provided. As you'll note there's a disjoint 'tween the example .p3d's selection names and the contents of the .rtm. That's why I'd suggest waiting for Vespa to clarify.
You could try something like this though... it may work...
class cfgSkeletons { class Default { isDiscrete = 1; skeletonInherit = ""; skeletonBones[] = {}; }; class OFP2_ManSkeleton : default { SkeletonBones[]= { "pelvis", "", "spine", "pelvis", "spine1", "spine", "spine2", "spine1", "spine3", "spine2", "neck", "spine3", "neck1", "neck", "head", "neck1", "face_hub", "head", "face_jawbone", "face_hub", "face_jowl", "face_jawbone", "face_chopright", "face_jawbone", "face_chopleft", "face_jawbone", "face_liplowermiddle", "face_jawbone", "face_liplowerleft", "face_jawbone", "face_liplowerright", "face_jawbone", "face_chin", "face_jawbone", "face_tongue", "face_jawbone", "face_cornerright", "face_hub", "face_cheeksideright", "face_cornerright", "face_cornerleft", "face_hub", "face_cheeksideleft", "face_cornerleft", "face_cheekfrontright", "face_hub", "face_cheekfrontleft", "face_hub", "face_cheekupperright", "face_hub", "face_cheekupperleft", "face_hub", "face_lipuppermiddle", "face_hub", "face_lipupperright", "face_hub", "face_lipupperleft", "face_hub", "face_nostrilright", "face_hub", "face_nostrilleft", "face_hub", "face_forehead", "face_hub", "face_browfrontright", "face_forehead", "face_browfrontleft", "face_forehead", "face_browmiddle", "face_forehead", "face_browsideright", "face_forehead", "face_browsideleft", "face_forehead", "face_eyelids", "face_hub", "face_eyelidupperright", "face_hub", "face_eyelidupperleft", "face_hub", "face_eyelidlowerright", "face_hub", "face_eyelidlowerleft", "face_hub", "eyeleft", "face_hub", "eyeright", "face_hub", "leftshoulder", "spine3", "leftarm", "leftshoulder", "leftarmroll", "leftarm", "leftforearm", "leftarmroll", "leftforearmroll", "leftforearm", "lefthand", "leftforearmroll", "lefthandring", "lefthand", "lefthandring1", "lefthandring", "lefthandring2", "lefthandring1", "lefthandring3", "lefthandring2", "lefthandpinky1", "lefthandring", "lefthandpinky2", "lefthandpinky1", "lefthandpinky3", "lefthandpinky2", "lefthandmiddle1", "lefthand", "lefthandmiddle2", "lefthandmiddle1", "lefthandmiddle3", "lefthandmiddle2", "lefthandindex1", "lefthand", "lefthandindex2", "lefthandindex1", "lefthandindex3", "lefthandindex2", "lefthandthumb1", "lefthand", "lefthandthumb2", "lefthandthumb1", "lefthandthumb3", "lefthandthumb2", "rightshoulder", "spine3", "rightarm", "rightshoulder", "rightarmroll", "rightarm", "rightforearm", "rightarmroll", "rightforearmroll", "rightforearm", "righthand", "rightforearmroll", "righthandring", "righthand", "righthandring1", "righthandring", "righthandring2", "righthandring1", "righthandring3", "righthandring2", "righthandpinky1", "righthandring", "righthandpinky2", "righthandpinky1", "righthandpinky3", "righthandpinky2", "righthandmiddle1", "righthand", "righthandmiddle2", "righthandmiddle1", "righthandmiddle3", "righthandmiddle2", "righthandindex1", "righthand", "righthandindex2", "righthandindex1", "righthandindex3", "righthandindex2", "righthandthumb1", "righthand", "righthandthumb2", "righthandthumb1", "righthandthumb3", "righthandthumb2", "weapon", "spine1", "launcher", "spine1", "camera", "pelvis", "leftupleg", "pelvis", "leftuplegroll", "leftupleg", "leftleg", "leftuplegroll", "leftlegroll", "leftleg", "leftfoot", "leftlegroll", "lefttoebase", "leftfoot", "rightupleg", "pelvis", "rightuplegroll", "rightupleg", "rightleg", "rightuplegroll", "rightlegroll", "rightleg", "rightfoot", "rightlegroll", "righttoebase", "rightfoot" }; }; };