Cre8or

All this time I thought I was doing something wrong... 🙄 I did some testing and found a temporary fix: replace every classname you want to omit with one of an attachment that doesn't fit in that slot. Don't want a suppressor? --> "optic_Aco" Don't want a side attachment? --> "optic_Aco" Don't want an optic? --> "acc_pointer_IR" etc. For magazines, it's a little harder, especially if you only want a secondary magazine (e.g. HE rounds for a UGL), as leaving the classname empty yields this familiar error: Warning Message: No entry 'bin\config.bin/CfgMagazines.'. For now, my workaround is to default the classname to "CA_Magazine", which still adds a magazine to your weapon (the command seems to bypass the weapon/muzzle's "magazines[]" property), but at least it doesn't switch you to the launcher animation when you select it (plus it has no icon, text or even ammo, making for an ideal dummy magazine).

If only there was a way to scale that multiplier via a scripting command... Then we could make AI breach a building at decent speed, rather than having them just walk in like they got home from work. EDIT: I could have sworn the date said 2018, and not 2008... I'll see myself out!

This sounds like a really simple, yet useful (and even realistic) idea. As a player, if I can't hit a tank's weak point due to terrain/object obstruction, I'll pick another spot to fire at, like the tracks. If there are no good alternatives left, I'll just shoot at whatever part of the tank I can hit. I could see this being defined as an array of memory points with weights, determining the priority (and thus the order) that the AI will try to attack each point in. To test if a memory point can be hit, it could do a raytrace to detect obstructions. I'm thinking of something like... aiTargetingMemPoints[] = {"turretBase", 1, "rear", 0.8, "turretCenter", 0.5, "trackL", 0.3, "trackR", 0.3, "massCentre", 0.2, "front", 0.1};

With Mondkalb's recent release of his Operation Blockhead mod, it came to my attention that the game doesn't verify whether the skeleton of a gear item you're trying to equip (uniform, vest, headgear, etc.) matches the skeleton of your unit's default model. In this example, if you try to put a regular NATO uniform onto a Blockhead unit model, the game will freeze and crash. A simple fix for this would be to prevent equipping gear items that don't use the same skeleton as the unit itself. If I remember correctly, uniforms and vests already have a config parameter that references a specific skeleton, so hopefully this shouldn't be a huge task. EDIT: I forgot to mention this, but a "doRagdoll unit" aswell as a "doUnragdoll unit" command would be extremely useful. I realise it is already possible to ragdoll units with "unit setUnconscious true", but the implications of that command (player input disabled, lifestate changing, etc.) make it unsuitable for some scripting situations. If possible, it would be nice to have extra parameters with the "doRagdoll" command, such as a delay until automatic transition to animation, or a boolean to toggle transitioning at all.

Woop! Thanks a ton for releasing this!

I figured the problem out! And I also have a fix! I'm modding on the dev branch, and I'm using -filePatching to preview my changes without having to restart the game. However, this will overwrite the compiled animations from my .pbo with the source files. Therein lies there problem - it seems that the game can't handle handAnim RTMs if they're not compiled. To fix this, either remove the -filePatching parameter, or, if you're like me and want to keep it, just rename/move/delete your source animations so that the game doesn't reload them. Oh, and if you really need to preview different animations in real-time, you need to go through an additional step: make a dummy addon where your new animations go into, along with the A3 samples' model.cfg, and compile that addon whenever you add a new animation (or overwrite an existing one). Then extract the binarized animation file from the newly generated .pbo file and stick it in your main addon folder. Provided the names match up, the game will then reload the animation and it will display fine, because it is now compiled. HOWEVER: once you're done testing your animations, make sure to replace the binarized RTM with the uncompiled version before you pack your addon! Worst case scenario, AddonBuilder (or PboBuilder, depending on what you're using) will try to binarize your files, even if they were already binarized, which will result in errors! --------- Okay, with this out of the way, here's a quick summary of what you need to check if you, like me, are having problems with animations being stretched in-game: in Blender, make sure the weapon bone starts with a lowercase W: weapon if you're not sure which model.cfg to use, simply copy the one from the ArmA 3 Samples (can be found on Steam), found in this location: "...\Steam\steamapps\common\Arma 3 Samples\Addons\Test_Character_01\model.cfg" handAnims do not change based on the weapon model that you use in-game. If you think your (custom) weapon model might be breaking your animation, try and replace it with the ArmA 3 Sample weapon. Granted, the hands may not fit that weapon, but it certainly shouldn't stretch the arms out into oblivion or anything crazy like that. if you're using the -filePatching launch parameter, know that ArmA will replace the animations in your PBO with the source animations (if it can find them), which is most likely the cause of your animation being stretched. I already provided a description on how to fix that issue earlier in this post, so just go read that. and finally, if you still can't get your animations to work, join the ArmA 3 Discord chat and post about it (there's an animation makers channel). The people there are usually friendly and will help you troubleshoot your setup, and generally have some good advice for you. (Kudos to HorribleGoat for helping me out!) --------- If I'm honest, with how simple of a fix this is, I was hoping this would be a common issue. Apparently not that many people animate on the dev branch, since nobody seemed to know about this issue until now. Anyway, I hope this post will help other people before they go and rip their hair out like I did.

Your assumption is correct, the movement of the bone was added to the hands, making it impossible to get an animation with both hands on the gun, both in Blender and ArmA. However, after submitting this post, I was told that Addon Builder is likely to be the cause of the animation problems, due to a binarization problem. To confirm this, I had another modder try my animation and model.cfg out, however they used Mikero's tools to pack the files. The animation worked fine on their end, which seems to be confirmation that Addon Builder has something to do with this. Additionally, I tried using animation files from open-source mods such as NIArms, and they all stretched horribly in-game. Compiled animations on the other hand, like the ones contained in BI's files or even other mods, all work as intended, further implying that the binarization process is the root of these problems. I wasn't able to 100% confirm that Addon Builder is the only issue though, as I simply haven't tested any other PBO builders yet. I will get back to you as soon as I can confirm that it works with other compilers. Thanks for the quick reply though, and especially for the amazing rig that you provided - I can't wait to get down and dirty with animations. With how easy to use it is, I have a feeling I'm actually going to enjoy animating this time, which, considering I absolutely hated it in previous games, definitely says something!

I've been playing around with this rig for a while now, but I can't get custom handanims to work to save my life. I know it was intended for ArmA 2, but I've heard that it's possible to use it in ArmA 3 by renaming the weapon bone (as specified in the first post), so I wanted to try it. To do so, I copied the skeleton model.cfg from the ArmA 3 Samples into my addon and exported a very simple animation that I tossed together in about 2 minutes. I set the timeline in Blender to range from frame 0 to 1, adjusted the pose of the ArmaRig in frame 0, then exported as static pose. So far so good. I then loaded the animation into Object Builder to see what it would look like. Both hands and the weapon were positioned properly, so I decided to try it out in-game. However, once I equipped the weapon in-game, the player's hands would stretch a few meters out into the distance. So I started from scratch, this time with very simple animations - a T-pose with the weapon slightly moved to the left, and a control animation (also a T-pose, with the weapon in its original position). I then took screenshots of both animations in Blender, OB and in-game to figure out what was happening. Here are the results: Control (original T-pose): Modified T-Pose (weapon offset by ~0.5 meters): Let me clarify why I think this is a problem: handanims are determined by the position of the hands in relation to the weapon bone. Nothing else really matters in this context, merely the weapon and the hands are relevant. That's the theory. The problem here is that the weapon was moved closer to the hands - in fact, inbetween them - meaning the player's right hand should be located to the right of the weapon. However, this is not the case, as the hands were both offset in the direction the weapon bone was moved in, and by the same amount. Since I thought this was a personal issue with my setup, I mentioned it in on Discord, where 3 members helped me make sure that I've got the basics covered. But the problem still persists, which makes me think there might be an issue with the rig itself. Ofcourse, this doesn't mean that I'm doing everything 100% correct - I only recently noticed the bone names were mismatching - but I feel like this is outside of my control.

Sorry for the bump, but what's been discussed in this thread is pretty much what I've written over in the suggestions thread. I was wondering if there were any news on this? Just being able to manipulate specific items in an inventory container would already go a long way. Essentially, being able to drop/remove a certain item/magazine/weapon, aswell as being able to add weapons/magazines with specific attachments (ie "spawn a gun with an attached mag that is half full") would prevent us from having to use workarounds like the one Larrow posted (which works, but is tedious and not exactly suited for large-scale use). I understand that this would take time, but I can't help but wonder how the engine currently handles inventory. Surely there is already some kind of array system that keeps track of what's in a container, so I imagine we merely need a way to access and manipulate that system. :)

Hello! This is my first post in these forums; after finding this thread I just couldn't help but sign up! Over the past months I've been experimenting with a custom inventory system, somewhat similar to ArmA 2's inventory. But I couldn't notice the lack of some functions which I believe would help out a lot of people. Here's the situation: Currently, it is not possible to access items/magazines/weapons in a player's uniform/vest/backpack specifically via scripts. Functions like itemCargo only have limited use, as they return the class of every item in a container, but don't allow us to manipulate them. A commonly used workaround is to either run code on ALL items of a certain type in a container (think "recombining magazines"), or on an item designated by the player via clicking on it in the inventory UI. While both methods work fine in a few cases, they're very restrictive as you cannot work with specific items only, let alone run functions on them. My suggestion is to add new scripting functions which will enable us to interact with inventory items in a more straight-forward and in-depth way. Currently, it seems as if the inventory is handled entirely by the engine and cannot be tampered with at all - and I would like to see a way for us to access it. The idea is that every gear container has a list of all items in it, each with a unique ID. Each entry in this list is an array (or similar) which stores information about the item in question. In the case of a weapon, there would be sub-entries such as "muzzle", "bipod", "optic", etc. which in turn would also be arrays. Why? Because this way we can get even more information out of every sub-entry, like checking how much ammo is left in the currently loaded magazine, and how much it can hold at most (when full). Let's take this idea further. If we could not only read pre-defined entries, but also create our very own, things could get really interesting. We could make items that can store custom data. Think of a note/paper item - with this system we could write text onto this piece of paper and it would persist, allowing for complex mission dynamics that were previously impossible! Or, well, really damn difficult to achieve properly. Here are a few functions that I think would be extremely useful: (object Cargo) getGearData [number UID, string Name, any DefaultValue] - return any - Much like the existing setVariable function, this would enable us to access data stored on an item. For example, getGearData [3, "ammo", 0] would return the amount of rounds that are currently in the item #3 (which could be a magazine). Furthermore, we could inquire about the attachments that are on a weapon stored in our backpack: getGearData[17, "optic", ""] could return something along the lines of "optic_Arco". (object Cargo) setGearData [number UID, string Name, any DefaultValue] - return nothing - The counterpart to getGearData, this would enable us to write custom data to inventory objects. (object Cargo) deleteGear (number UID) - return bool - Delete a specific item from a cargo container using the item's UID. Returns true if item with UID was successfully deleted (if it existed), false otherwise. getAllGear (object Cargo) - return array - Returns the entire data array of the cargo container. This includes all items in the container and their UID, aswell as their sub-entries in the form of nested arrays. Basically spits out everything there is in a specific gear container. getAllGearList (object Cargo) - return array - A simplified version of getAllGear that only returns a list of all items with UIDs, but omits their sub-entries. Only useful if it is any faster than getAllGear, otherwise redundant. Now, I'm aware this is a lot to ask, as it would probably require a full recode of the way items are currently handled altogether, but it'd give us so much more freedom in regard to mods. I'd open up an ocean of possibilities which I'm sure will lead to some really interesting game mechanics Lastly, sorry for the wall of text, but this is something I've had in my mind for a long time. I guess I got a little carried away, hehe... :P