teacup

I binarized my Su-22 addon without a P drive, and penetration materials seem to be working fine: when i shoot the plane surface, i get sparks and not dirt effects, I get metallic sounds, one thing haven't checked is if they let different caliber rounds through or not (like HMG, 30 mm canon rounds, SABOT). I experienced things similar to what you're describing on the An-2 port I'm attempting. I think it has to do with specific materials, the "armour_plate_XXmm" ones. One difference that I found between unbinarized and binarized models, is that the latter have references to the BISURF files in them. So it seems binarization does "bake" some of the RVMAT into the model.

Nevermind, I'm talking out of my ass, just checked.

That config is a mess. All the interpolate../connect.. errors were because base classes Default, StandBase, DefaultDie and ManActions were referenced from the wrong place, so instead of inheriting from them, they were basicly overwritten with nothing. The relevant bits should look like this: class CfgMovesBasic { class Default; class StandBase; class DefaultDie; class ManActions; }; class CfgMovesMaleSdr: CfgMovesBasic {}; class CfgMovesDSSZmb : CfgMovesMaleSdr { class Actions { ..and not like this: class CfgMovesMaleSdr; class CfgMovesDSSZmb : CfgMovesMaleSdr { class Default; class StandBase; class DefaultDie; class ManActions; class Actions { There's also a host of No entry.. [state class].useIdles errors that can be fixed by adding useIdles=0; or 1 to some of the states. You also need to set up the zombies faction correctly. Easy-peasy, look at how factions are set up in A3. Next batch of interesting errors, there's only a couple of them: bin\config.bin/CfgMovesDSSZmb/States/DSS_ZMB_HasTarget_Still.interpolateTo: Bad move EHJ_INF_HasTarget_Still_Die_1 bin\config.bin/CfgMovesDSSZmb/States/DSS_ZMB_HasTarget_Still_TurnLeft.interpolateTo: Bad move EHJ_INF_HasTarget_Still_Die_1 bin\config.bin/CfgMovesDSSZmb/States/DSS_ZMB_HasTarget_Still_TurnRight.interpolateTo: Bad move EHJ_INF_HasTarget_Still_Die_1 bin\config.bin/CfgMovesDSSZmb/States/DSS_ZMB_HasTarget_Still_AttackStart.ConnectTo: Bad move DSS_ZMB_HasTarget_Still_AttackEnd bin\config.bin/CfgMovesDSSZmb/States/DSS_ZMB_HasTarget_WalkFast_AttackStart.ConnectTo: Bad move DSS_ZMB_HasTarget_WalkFast_AttackEnd These interpolate../connect.. array elements point to some non-existent states. There is no class EHJ_INF_HasTarget_Still_Die_1, however, there is a class DSS_ZMB_HasTarget_Still_Die_1. Are they supposed to be the same, you just forgot to rename, re-index them? Or are there parts of the original config missing from yours? Last substantial error is: Warning Message: No entry 'bin\config.bin/CfgMovesDSSZmb/Actions.ZMB_INF_Dead_Actions'. Warning Message: No entry '.turnSpeed'. Warning Message: '/' is not a value Warning Message: No entry '.stance'. Warning Message: '/' is not a value Warning Message: No entry '.upDegree'. Warning Message: '/' is not a value Warning Message: No entry '.limitFast'. Warning Message: '/' is not a value Warning Message: No entry '.useFastMove'. Warning Message: '/' is not a value Warning Message: No entry '.adjustf'. Warning Message: '/' is not a value Warning Message: No entry '.adjustb'. Warning Message: '/' is not a value Warning Message: No entry '.adjustl'. Warning Message: '/' is not a value Warning Message: No entry '.adjustr'. Warning Message: '/' is not a value Warning Message: No entry '.adjustlf'. Warning Message: '/' is not a value Warning Message: No entry '.adjustlb'. Warning Message: '/' is not a value ... As with the previous batch, is this a sloppy edit, or there really is supposed to be a ZMB_INF_Dead_Actions (there is a DSS_ZMB_Dead_Actions). You should open the RPT, take every error and warning and fix them as they come. Here's the config I did, where i fixed the first 2 errors (base class inheritance and useidles). The rest is up to you. You owe me a beer.

I can't find a fault in your config, but place yourself a character in editor, paste this into it's init field this playAction "GestureAgonyCargo"; then hit Preview. As you can see, it is possible to have seamlessly looping gestures. Copy the way it's set up in the animation config, and you should be set.

Setting looped=1 should work, just make sure to add the animation state itself into it's own connectTo[]= array, otherwise it cannot be followed by itself, loop that is. Look at the way looping animations are configured.

Man IS an animal, so philosophically, i have no beef with you resorting to CfgMovesAnimal_Base_F :) If it suits your needs, and you can live with the reduction in functionality, great. But in principle, you should try to inherit all of the human movement tree. It shouldn't be that complicated, you don't even have to touch the Actions section for what you want to achieve (if I understood your intentions), nor should it involve mass quoting of the original game config.cpp normally. Shouldn't that be the other way around? Usually, your custom actions are derived/inherited from the default game actions and not the other way around. Don't be a masochist.. :)Extending or modifying an existing class with a new one, is not that complicated. Basic OOP. Debugging any config errors like undefined base classes or unintentional overwriting of base classes is not that complicated. Make sure to check the RPT as well, because ArmA will only give you one popup message for each kind of error, and will write the rest of the errors to the RPT. And as always, upload or post your config if you need help, it's next to impossible to assist you in the blind.

Take a look at the ArmA2 sample models, they include static weapons like the D-30, ZU-23, etc.. and follow suit. Get your A2SM_Data_APL.zip from here.

Maya 2008 MotionBuilder 2012 ObjectBuilder ObjectBuilder Direct3D Maybe MAX is somehow privileged, ObjectBuilder's internal data structures are closer to 3DS, and need no further processing. But I just verified an FBX export from Maya (2008) -> FBX (Inspected it in MotionBuilder 2012) -> O2. And i can confirm that it is indeed ObjectBuilder that dances with my polygons. Though even OB shows different stuff when using OpenGL (i guess) versus Direct3D.

Maybe the animation is a bit shorter than 0.8 seconds (your sleep delay), so when it finishes, the character reverts back to the base animation for a split second. Maybe it isn't even possible to play those animations in a perfectly seamless loop, using scripting commands like play/switch/Move/Action/Gesture. It might be a wild goose chase, but in your place I might try and set up an event handler for AnimChanged, AnimDone and AnimStateChanged, see if either picks up on the reload animation finishing, and use that event to time the next call for the reload action/animation. Or try making an addon out of it, if it's practical for you or suits your needs. That way you might have better control over it, than what scripting commands afford you at this time.

Most reload animations are configured as Gestures, meaning they are layered over a base animation like standing still or running, and only involve the weapon, arms and head. That setup makes it possible to reload while running for example, it does not interrupt the underlying animation. Is the animation you're trying to trigger set up as gesture, and if so, have you tried playGesture. Apparently it doesn't work, but who knows, maybe they implemented/fixed it..

Crashes can be hard to figure out. Check your RPT, the last couple of lines could provide a clue as to why it goes belly up. This is how i caught a malformed RVMAT (bad procedural texture inside) crashing my game recently. Otherwise you will just have to try and eliminate the different factors at play, one by one, to try an trace what's causing the crash.

http://forums.bistudio.com/showthread.php?114463-moveObject-exe

That path points to an ArmA2 collision model, one made specifically for a death animation ("dth"). ArmA3 obviously can't find the file, and even if it did, it would likely be the wrong collision shape for your idle animation. ArmA3 collision paths look like this (rooted in A3\anims_f rather than ca\anims): Older tutorials and ArmA1/2 configs are good for learning the principles, but for integrating your addon into the current ArmA3 structure, you must unpack anims_f.pbo and look at the configs inside.Characters stuck in animation? If I would have to guess, maybe it's misconfigured ConnectTo[]= and InterpolateTo[]= properties. But we're not psychic, you will have to post your config if you want assistance.

You might be right. My exporter has only 2 options though (none related to mesh processing), it's that basic. And I doubt it would have the gall to optimize my geometry willy-nilly, being it's written for software used for film rather than games. Sounds more like something an in-house game tool would do ;) I've noticed in the past, that when importing models into O2, specially higher polycount ones, it used to take it's sweet time, even displaying some progress bar thingie. I just assumed it was hard at work optimizing the mesh.

You're a lucky man.. :) Happens to me evey time, though my path is Maya -> FBX -> ObjectBuilder.

Did you do it in all the LODS? To make sure there's no reference to the old proxy paths, open the P3D in a hex- or even text-editor and search for "proxy:". You will find all proxies and ensure you didn't miss some.

Tinkering with the model.cfg won't do the trick here, you have to go into the model, and swap proxy paths. Either you point the proxies to their ArmA3 equivalents, or copy over the ArmA2 proxies into your addon and refer to them.

When importing any geometry, from any format into ObjectBuilder it will optimize the model: remove what it thinks are redundant edges, triangulate, quadrangulate to it's heart's content. No way around this, and it's specially annoying when it sometimes removes edges that are UV borders, and texturing blows up on a couple of faces. But in your case it's very simple: since it is a model that will be animated (i.e. deformed, distorted), you will have to again triangulate all faces once you're in ObjectBuilder. Look at the samples, anything that is not a rigid shell, anything that will deform in the game, gets triangulated. Since planarity of a quad cannot be guaranteed, it gets split into 2 tris.

I'd suggest trying something like this (code below not tested): class CfgMovesMaleSdr; class [color="#B22222"][b]MY_MOVES[/b][/color]: CfgMovesMaleSdr { skeletonName="OFP2_ManSkeleton"; gestures="CfgGesturesMale"; class States { class AmovPercMstpSnonWnonDnon { variantsPlayer[]={}; file = "\my_unit_file\data\anims\myIdle.rtm"; }; }; }; class CfgVehicles { class C_man_polo_1_F; class myguy1: C_man_polo_1_F { side = 3; scope = 2; author = "Bones"; vehicleClass = "myUnit"; uniformClass = "my_texture"; displayName = "My Unit In Game"; [color="#B22222"][b]moves="MY_MOVES";[/b][/color] }; }; Notice how I emptied the variantsPlayer array. This way, if you have only one idle animation, you can have that one loop for ever, instead of having the animation state-machine keep randomly alternating between 6 different idle animations.

Welcome to the grey hair club.. :) Crashing without giving clues about why it happens is tough to debug. If I were you I would try to isolate the problem first. Is it the config.cpp, is it the model, is it RVMATs or perhaps the model.cfg that crashes the game? Don't assume that sample models are perfect and will binarize and pack without problems, that the resulting addon cannot crash the game. Do the HAFM helis use helicopterX? If so, modify them step by step, until you figure out what causes the crash. If they use only "helicopter" as simulation, try to create the simplest config.cpp with helicopterx and pack the PBO with just the model and config.cpp, delete everything else, and don't binarize. Sure it's going to be just a white statue of a helicopter, but if it doesn't crash the game, you have a starting point.

You can safely delete CfgSkel(e!)tons and CfgModels. The skeleton to be used by human characters in the game already exists and needs no modification. cfgModels is used for something else entirely, not for RTM character animations (motion captured or keyframed). It's used for simple procedural animations, like rotations around one axis, translation, hiding objects, etc.. Focus on CfgMovesMaleSdr. If you want to overwrite the default civilian/unarmed idle, don't create a new animation (class myIdle), just replace the file path of AidlPercMstpSnonWnonDnon_AI to point to your RTM instead. But pay attention, there is not just one single idle animation for unarmed civilians, there are several, and they are played randomly. Also, "AidlPercMstpSnonWnonDnon_AI" refers only to the AI and not player characters. If you unpack anims_f.pbo, and look at the config, if you search for "class CivilStandActions" you will se that the default animation for that is "AmovPercMstpSnonWnonDnon". And now if you look further, moving from Actions to States, and look up "class AmovPercMstpSnonWnonDnon", you will see that it has 6 other animations that are played randomly/alternatively: class AmovPercMstpSnonWnonDnon: StandBase { variantsPlayer[]= { "AidlPercMstpSnonWnonDnon_G01", 0.16, "AidlPercMstpSnonWnonDnon_G02", 0.16, "AidlPercMstpSnonWnonDnon_G03", 0.16, "AidlPercMstpSnonWnonDnon_G04", 0.16, "AidlPercMstpSnonWnonDnon_G05", 0.16, "AidlPercMstpSnonWnonDnon_G06", 0.16 }; ... If you don't want to alter the game content, but would rather add your things to them, create your own moves class and inherit from CfgMovesMaleSdr, then do the modifications inside that. And point your cfgVehicles human, to use your newly created moves class. The introduction here might clarify a few things about animation config: https://community.bistudio.com/wiki/CfgMoves_Config_Reference ArmA2 mods can be just as educational as ArmA3 ones, regarding config, and animation config. All config.bin files can be converted to human readable config.cpp.

Wow, LOL. Sometimes AddonBuilder makes me want to cry. I was trying to binarize and pack the ArmA2 Antonov An-2, to port it to ArmA3. And ran into a problem, or several: - Error in config D:\SteamLIB\SteamApps\common\Arma 3 Tools\Binarize\bin\config.cpp popup. - Binarization and packing continues past the above error, but the final PBO is not where it's supposed to be (this was easy, just had to copy from temp folder, known bug). - When testing in game, all transparency is gone, lots of black instead. Luckily, I had another addon handy that I knew was good, it binarized and packed a month ago without a hitch. Tried to pack that, and surprise, it worked. Something must be wrong with my An-2, right? Config, model config, model, materials, textures, folder structure - something. Started swapping things out, isolating the problem. Took me a day, but found it eventually - it was AddonBuilder: if the addon folder sits in the root of my D:\ drive (D:\TCP_A2_An2) then I get all the above problems. If I move the folder from the root (to say, D:\stuff\TCP_A2_An2) it binarizes and packs without a problem. Can someone confirm? http://publicfiles.armedassault.info/teacup/AddonBuilder_NoAlpha.jpg (203 kB)

The rest of the settings are stored in registry, chances are they don't get wiped upon uninstall. Open regedit and check HKEY_CURRENT_USER\Software\Bohemia Interactive\Object Builder. Lots of stuff in there.

I get black instead of transparency as well. I think it's binarization that's killing transparency. Packing/binarizing from GUI myself. Edit: it may not be the tool though. I managed to binarize & pack my Su-22 without errors, and transparency was fine. When i try to binarize the ArmA2 An-2 which i'm trying to port over, i get an error in Binarize\bin\config.cpp. Binarization finishes, but transparency is lost. So chances are the model.cfg is somehow responsible for the error and loss of alpha. Or even the P3D.

The 3 places where you tried to put your model name are correct. If you tried "class YOURMODEL: Car" instead of "class DAR_ImpalaPIM: Car", you did it right. Ideally, you should write your own model.cfg from scratch - no two cars/models are the same, even if they share many sections, animations or the skeleton. If it crashes the game, take a look at the RPT, you can sometimes find clues as to what's wrong. If that doesn't help, I would try adding the model.cfg you borrowed in chunks, so you can isolate the part that's causing the crash. I would probably start by removing the last 2 classes: DAR_ImpalaPID and DAR_ImpalaPIS, and cut down class Car and DAR_ImpalaPIM (or whatever you replace it with) to a minimum. Then gradually add animations back to them.