HJohnson

Hello, here is my first contribution to the Arma community. This tutorial will help you create animations that can properly configured to play in Arma with Blender. This tutorial is an expansion of the tutorial and files written by user DeanosBeano. This video will explain : how to export the animations properly from blender into a file format (.bvh) than Oxygen can read, how to adjust those animations in oxygen so that they are centered, a brief look at a script to set up the animations and a look at the animation in game. Now in 720p!The file I am providing contains the config file with extra descriptions of the defined classes, an Arma 3 Skeleton.p3d with that is ready for .rtm import along with one with the animation featured already loaded in, the animation .rtm file, and the blend file that I used with an animation already there. '>Files** A couple things you need to know. The first frame must always be 0 and the default "Jesus" pose. The weapon bone must be seperate from the character body rig, otherwise it will improperly animate itself. I haven't done any launcher animations yet, but it is the same for that bone as well. You can use this method to make custom hand anims. This requires you to set the maximum frames to 2. 0 being the T-Pose, 1 being the handanim, and 2 being the handanim. In O2 you must change the keyframe names to -.5000, 0.000 and 1.000 respectively. In order to make the right hand move in this example, you need to use the IKfunctions. I am still documenting those and what they do and will post and update in the future. Any questions or suggestions you can pm me here, or preferably on Google+! **Now with appropriate licensing!

The following code is what is necessary to animate any underslung grenade launcher in Arma 3. This stops the "weapon magazine animates while the GL animation plays" bug and it also allows you to animate the ugl in general (tube moving back and forth, pseudo shell being inserted,etc. Essentially you duplicate the the parts that you need to move in the GL and the Magazine giving them the proper named selections. In the example below, GL_TUBE_DUMMY is visible when the muzzle of the gun is set to 0 and MAGAZINE_DUMMY is set to visible when the muzzle is set to 1. The dummy parts and their named selections do not move and have no animations outside of disappearing when required. Since these are offset, the moving GL parts are not visible when you are using the rifle and the moving rifle reload parts are not visible during GL usage. In this case example, this code is used to animate the FNGL on an Arma 2 scar port: //Reveal the non-moving UGL related reloading parts when muzzle = 0. Hide them when its is = 1. class gl_tube_dummy_hide { type="hide"; source="weaponMuzzle"; selection="gl_tube_dummy"; minValue = 0.0; maxvalue = 0.25; hideValue = 0.01; }; //Reveal the moving UGL related reloading parts when muzzle = 1. Hide them when its is = 0. class gl_tube_hide { type="hide"; source="weaponMuzzle"; selection="gl_tube"; minValue = 0.0; maxvalue = 0.25; hideValue = 0.00; unhideValue = 0.01; }; //Reveal the non-moving magazine reloading parts when muzzle = 1. Hide them when its is = 0. class magazine_dummy_hide { type="hide"; source="weaponMuzzle"; selection="magazine_dummy"; minValue = 0.0; maxvalue = 0.25; hideValue = 0.00; unhideValue = 0.01; }; //Reveal the non-moving magazine reloading parts when muzzle = 0. Hide them when its is = 1. class magazine_hide_2 { type="hide"; source="weaponMuzzle"; selection="magazine"; minValue = 0.0; maxvalue = 0.25; hideValue = 0.01; }; Results in something like this. (I'm using Toadie2k's animations for the magazine reload until I get around to making my own).

So, before I started working on "Yet Another Modded Helmet" I did some research here and found there was an example model of a helmet in the Arma 3 tools. My first intuition was to pack and binarize that helmet (its a baseball cap in the A3tools example) and put it in game, then maniuplate that template for my own helmet aka copy paste my mesh and delete the example mesh. However, this doesn't work. I'll run you through what I have done and maybe you can help me see what I did wrong. A. I took config.cpp, cfgheadgear.hpp and the a3_headgear_example.p3d out of the example folder and put them in their own folder called Spartan B. In the config I changed the things necessary such as there were lines like #include xyz which were for the other examples. I also changed the directories in the cfgheadgear.hpp to fit the new location. Everything was changed to Spartan\m\a3_headgear_Example.p3d for the model location. I open it up in Oxygen, everything is fine. I've copy pasted the model.cfg and the defined name is the exact same as the P3D file name and they are in the same exact folder. I binarize and pack the addon with the Arma 3 Binarizer and go in game and give it to my player. He has no hat. The hat is not in his crotch or at his feet. It is invisible. If I take the hat off, it appears on the ground. At first I thought this was because the model.cfg and the named selections were wrong. But they weren't. I hadn't changed anything from the original file. I proof read the coding again, made sure the named selection for head was there, I hadn't even modified the model.cfg. But the hat doesn't show up. I figured maybe it was too low on the body even though the named selections should negate that. So I made a box the size of a house in the model to see if I could still see it. Not a thing. Yet when I took off the hat, a box the size of a house showed up. I tried replacing one of my custom weapons with the hat's model to see if the model has an error, it doesn't, my scar-H because a giant box with a hat in it. I tried inheriting from an already defined hat class from the game but changing the model, no dice. I don't know what else to try? All of the threads here on the forum do not address an invisible hat. Only ones were the hat was in the crotch, of which I applied those fixes and it didn't work. Anyone have any ideas? TLDR: Binarized the Hat Example from the BI tools It doesn't work Checked the configs and the urls for the model names, they check out Hat is visible when on the ground, not when worn Hat mesh is in the 0.000 and 1.00 lods Model.cfg is unchanged from example files Named selections for "head" is present Autocenter = 0 is present Model works on other things but not a hat Inheriting a class and replacing a model on a vanilla class does not work

From the steamworkshop page: Let me focus on the part that I think many people miss: Never once did I or anyone else claim that Blastcore was anyone else but Opticalsnare's work. Stealing someones work without credit is what the Arma 3 Life people did. I took a mod that needed bug fixing, and bug fixed it. Thats not stealing. He refused the bugfixes. So I uploaded those bugfixes for those who wish to have it. Initially I respected OS over the good work that BC for Arma 2 was by offering to help him. I communicated on these forums that I wished to help him as it was obvious that he couldn't do it himself. After OS's childlike response to someone offering a helping hand (communication) and obvious incompetence when it comes to the maintenance and releasing of mods I lost respect for him. Similar to how I lost respect for the JSRS dev after he threw a tantrum with his personal situation. I wont have people like you warping the story to fit your narrative.

Okay, have fun with your mod then. I'll go back to being the GREAT SATAN evil-doer of the Arma community.

So do you want some help? I'm offering. I took Blastcore RC2, the bug ridden release, and bugfixed it for my private group. I later offered the bug fixed version to Opticalsnare so that he could put it into the official version. It was on github, an opensource website, because that is the easiest way to collaborate on Arma code. If he would have said "no thanks I got it" or something similar, everything would have been fine. I would have kept the bugfix private or in the very least not advertised it here. However, he went on an internet tirade about * Someone would ever dare try to help him improve his work. * Acted as if Blastcore was originally his ( of which is isn't ) and he is the only person who can edit it * That multiple people working together hurts the community instead of helps them That was a drama storm and a half but everything was resolved. If you wanted to use Blastcore with all the bugs and frameloss and support Opticalsnare you could. If you wanted to not have the bugs you could download Hopecore to run along side Blastcore which fixed those bugs among other things in a mod-dependent patch. Everyone went there seperate way. Now, Opticalsnare has released another version plagued with problems which is understandable. Neither RHS, Robert Hammer, Toadie2k, ACE devs, JSRS guy have avoided this. And like before I've offered to help. Not to fork it, not to release my own patch, but to help him directly. And his response was "this is why I want to stop modding,because people like you". "This is why I want to stop modding: I release mods that have bugs and then people offer to help me fix those bugs" ~Opticalsnare 2015

Seems that you have some problems with this release. Would you like some help fixing these errors?

Did you find an animator for those weapons yet? I'm available and have some spare time this summer.

I updated PboProject to the latest available after the recent Arma 3 tools update and it has stalled my modding attempts. First and foremost I cannot pack files without having each and every single extra mod file that is referenced unpacked. This is ridiculous, my P:\ drive isn't that large and I don't need to have additional gigs wasted on external references. Anyone know why we can't uncheck that box now? Also, PBOproject used to be able to detect what is binarized and what wasn't. I help with the content pack with my group and we will routinely compile mods to save space. This means we could have newly made textures an models along with unpacked ones in the same pbo. Pboproject would binarize what needed to be and skip everything else. Now, with pboProject.1.40.4.96 it throws the error every single time I try to binarize a model. Even if it was a simple cube made in oxygen. HK23E.p3d scanning... ****warning: p3d format is unknown file cannot be checked***** HK23E.p3d.dep : ignored or merged cube.p3d scanning... ****warning: p3d format is unknown file cannot be checked***** Even the vanilla builder for Arma 3 in the Arma 3 tools still shoots up an error. What error could I possibly be getting from a self made cube within Oxygen? Edit: I can't even binarize old mods that used to be able to be binarized and hadn't been modified since then. Edit #2: The current project I am working on is a new factions, I decided to make one unique weapon for them. Since it was only one weapon I just put it in with the faction. This was giving me the error above. No matter what model I put in there, it gave that error. Yet when I put the model in a different mod folder, it worked fine.

After a massive amount of editing, I've gotten this mod to work on a server. However I ran in to some problems. Maybe you or other users can give some input. I was able to have Bcombat running efficiently on a dedicated Linux server and people join and play. Only afterwards did things get funny. With how you have built the mod, would each user need to have the mod running as well, or would it be server only?

Okay, I have created a mesh, made it's textures, etc. However, for whatever reason the normalmap created by xNormal is not only not working properly, but it is being randomly applied to the mesh. Here is the normal map applied in blender : http://i.imgur.com/NJDkRGq.png (210 kB) Here is what it looks like in in buldozer: http://i.imgur.com/ujIsqlj.png (185 kB) some random faces are flipped upside down, others are pure white, others have the specularity on the wrong side. I've tried "recalculating normals" and reversing in O2 and I've made sure that blender is exporting the normals properly. I've also exported the file as a 3ds/obj/fbx and they all have the same results. What is causing this? I've tried applying rvmats from other mods to the model and those normal maps work properly (abiet wrong UV) and my normal map looks the same as theirs.

Its almost as if Arma simulates your arms being able to move independently from your head and eyes instead of you being a rotate-a-turret like in Call of Duty, Battlefield and Counter Strike. I'll just do it myself I guess.

1.3 gigs for a single map is bad form *cough* Borhnholm *cough*. I mean, who is going to download this map who doesn't already have AIATP for cherno,taki,fallujah, etc. A.I.A. variant when?

Two things. 1. Sway has nothing to do with the scope being 2d or 3d 2. If you aren't a casual you play with aiming deadzone on so you can manually aim your gun all over the screen without rotating your character anyway 3. Your "reticle" isn't moving. Your gun has inertia. Surprise surprise. Arma isn't like COD where everything is perfect 100% of the time.

Is there something I should be seeing in that image?

Will the ACOG/Elcan be 3D scopes in the future?

Small issue with the 1x scope in one of the distance lods. The "make the 3d scope work" part of the ACOG doesn't have the proper transparent texture applied. As a result people at more than 20ft look like they have a long white styrofoam cup around their optic.

Because that went over so great the first time ;)

Will it be possible to have dynamic hi and low's playing for each weapon in the framework? I'm trying to work on a sound mod that plays these sounds independently so they change depending on the environment or the situation but its just a drag on dedicated servers (21gb error rpts). So yeah, will this be able to support that?

Yep, even tried it with my full mod package that includes cba. CBA or not and it isn't cycling. Edit: Even then, CBA has nothing to do with the cycling of an animated texture in Arma.

http://i.imgur.com/xV8bJ2q.png (949 kB) Vanilla Arma with Blastcore Phoenix results in Smoke Grenades not properly cycling through their animatons.

You don't need to add prefixes. You could have 20 mods that all contain m16.p3d and they will not conflict? Why? Because the full name of the model is addonfoldername/models/m16 , addonfoldername02/model/m16 etc. Usually I follow a folder structure like this. AddonName Models Textures Sounds Scripts Anim The main config.cpp goes inside the main addon folder. P3D's and the model.config go inside the model folder. I find it easier to make one model.cfg that contains all the animations for the mod than to have a billion separate ones. Helps speed things up. Textures contains all image files and the materials. Textures are named after what they do: m16_d , m16_n, m16_s =m16 diffuse map, m16 normal map and m16 specular map. Sounds go in sounds. All event handlers and other scripting goes in scripts. All rtm's go in the anim folder. Pretty simple and neat.

Animations for Arma? I do animations for arma.

Thanks for the RHS patch. However, I have a protip that I discovered while creating custom animations for weapons I don't have access to. With the tool Eliteness you can view the model config of weapons that are binarized, in there you can get the timings of the magazine movement and whatnot. As a result, you can time the animations you are making to what the original developer already created without having the original source files and or debinarizing them. For example, I'm working on an animation pack for some things from BWA3. While I cannot debinarize them nor do I have the source files, I am able to see via eliteness that during the reload animation the magazine is set to move from down from 18.5/100 to 26/100 and then back up from 58.6/100 to 73/100. I don't know what program you are using personally to create your animations but the blender animation suite shows what your current frame's number is in Arma time and I am able to manipulate the dopesheet accordingly. Don't know if you had picked up on that or not. Cheers.

As far as I have read, they didn't steal a mod. As a matter of fact, you can't "steal" a mod for Arma 2/3 because we are unable to sell mods. Also, they aren't commercializing mods. Lets say I had debinarized the Kuma, remodeled it to have a railgun cannon, pbo'ed it and put it back in game, hypothetically. Imagine if I were to say to you, "I'll give you a railgun tank for $10". You give me $10 and I give you a mega link to the pbo. Then I'd be commercializing EULA BIS content and that would be illegal. I would be selling a piece of content that you do not have, that you do not already own, which I cannot legally claim complete ownership of. In the case of Arma 3 Life, you already have the content on your computer as you cannot connect to the server without the mods. While they do not have legal ownership of the mod, they don't need to as you already have and own the mod in your Arma 3 install folder. With Arma 3 Life, you are paying for a service exclusive to their server. You are paying for a script to execute "If ArmaID = ABC then addweapon XYZ". You can play with the content all you want in the editor or single player you already own it. They didn't sell it to you. Paying to access content is not commercializing a mod, its providing a service. If anything you should be upset at their customers who obtain the mods and enable them to sell a service to use them. Then again, I think you are just upset someone found a way to make money off of Arma 3 :^)