Macser

I misunderstood what you were getting at. I thought you wanted to put the document up yourself. I thought I had it buried somewhere in my collection of old CDs/DVDs. No luck finding it so far. Out of all the folks here, zulu1 might be the best chance of locating a copy. Given that he has a massive backlogue of OFP content. :)

Right. Sounds good. Shifting the weight slightly from side to side might help sell the illusion of mass when it's powering up. If it's possible. Nothing drastic. That and a little dip right after each foot contact. That's where the graph editor comes in very handy. :)

Wasn't that a feature of SLX? Where the player would automatically dive for cover when rounds passed nearby, without input from the user themselves. Is it possible that scripting was incorporated into the mod?

Hello Thobson. I certainly wouldn't grumble. I've brought it out of the cupboard and dusted it off for a replay more than a few times. Definitely one of the greats. :)

Looking great so far HG. :) How much lateral movement does the setup actually allow? Do quick movements cause the "tank" section to disconnect in game?

Are you really expecting a reply after 4 years? And a reply relating to A3? :)

Not if they're working solely in A2 unfortunately. :)

These types of addons could be accommodated by less restrictions in the man class. That and some kind of globalised physics. Where a unit/vehicle interacts with the environment based on it's weight rather than it's class. Again, like melee, that's not something that would detract from the milsim experience. It may even have dividends for more "realistic" projects. :)

Quick tip on using subsurface divisions: When using a sub surf modifier, let it do some of the heavy lifting. The base mesh doesn't have to be ultra detailed to get good results. So start with something reasonable and let the algorithm smooth it out for you. For example, in Blender, I'll go with 10,12 or 16 edges for a cylinder instead of the default 32. For certain objects a cuboid is often enough for smaller parts as it will automatically become spheroid once it's created. Just remember the count per face is being multiplied by 4 each time you ratchet up the level. So it can sky rocket fairly quickly. Which in theory sounds like it makes for a great result. But often the difference can be minimal at higher levels. Really fiddly stuff like thin panel lines could easily be inserted into a normal map at a later stage.

You'll need to close CfgWeapons. And Enum. enum { destructengine = 2, destructdefault = 6, destructwreck = 7, destructtree = 3, destructtent = 4, stabilizedinaxisx = 1, stabilizedinaxesxyz = 4, stabilizedinaxisy = 2, stabilizedinaxesboth = 3, destructno = 0, stabilizedinaxesnone = 0, destructman = 5, ordinalenum = 2, destructbuilding = 1 }; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< class CfgPatches { class GEND_VEST { units[] = {"GENDVEST"}; weapons[] = {""}; requiredVersion = 0.100000; version = "1.0"; fileName = "GEND_VEST.pbo"; author = "Tuner"; requiredAddons[] = {"A3\Characters_F","A3\Weapons_F"}; }; }; class CfgWeapons { /*extern*/ class Vest_Base_F; /*extern*/ class Item_Base_F; /*extern*/ class ItemCore; /*extern*/ class InventoryItem_Base_F; class VestItem: InventoryItem_Base_F { author = "$STR_A3_Bohemia_Interactive"; _generalMacro = "VestItem"; type = 701; uniformType = "Default"; hiddenSelections = {}; class HitpointsProtectionInfo { class Body { hitpointName = "HitBody"; armor = 0; passThrough = 1; }; }; overlaySelectionsInfo = {"Ghillie_hide"}; showHolsteredPistol = 0; }; class Vest_Camo_Base: ItemCore { author = "$STR_A3_Bohemia_Interactive"; _generalMacro = "Vest_Camo_Base"; scope = 0; weaponPoolAvailable = 1; allowedSlots = {901}; picture = "\A3\characters_f\Data\UI\icon_V_BandollierB_CA.paa"; model = "\A3\Weapons_F\Ammo\mag_univ.p3d"; hiddenSelections = {"camo"}; descriptionShort = "$STR_A3_SP_NOARMOR"; class ItemInfo: VestItem { uniformModel = "\A3\Characters_F\BLUFOR\equip_b_bandolier"; hiddenSelections = {"camo"}; containerClass = "Supply0"; mass = 0; }; }; class V_TacVest_GEND: Vest_Camo_Base { author = "Tuner"; _generalMacro = "V_TacVest_POLICE"; scope = 2; displayName = "$STR_A3_V_TacVest_GENDARMERIE0"; picture = "\A3\Characters_F\Data\UI\icon_V_TacVest_police_CA.paa"; hiddenSelectionsTextures = {"\A3\GEND_VEST\Common\Data\tacticalvest_gend_co.paa"}; model = "A3\Characters_F\Common\equip_tacticalvest"; descriptionShort = "$STR_A3_SP_AL_II"; class ItemInfo: ItemInfo { uniformModel = "A3\Characters_F\Common\equip_tacticalvest"; containerClass = "Supply100"; mass = 50; class HitpointsProtectionInfo { class Chest { hitpointName = "HitChest"; armor = 12; passThrough = 0.400000; }; class Diaphragm { hitpointName = "HitDiaphragm"; armor = 12; passThrough = 0.400000; }; class Abdomen { hitpointName = "HitAbdomen"; armor = 12; passThrough = 0.400000; }; class Body { hitpointName = "HitBody"; passThrough = 0.400000; }; }; }; }; }; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

When I see or hear the term AAA being used, I assume it refers more to the production values than how much moola it rakes in. Although that's more of a personal opinion. The Arma series has steadily improved in the area of production and quality, even with the flaws. The main thing it has, which lets it carve out it's own niche is the ability to mod in a particular way. In a particular type of environment. From that point of view you could call it AAA. I've spoken to quite a few people about why they opted to get into the Arma series. People who are only just trying it out for the first time. The main draw for them wasn't the milsim theme. It was the modding aspect. And the improved looks. Although they loved the idea of being able to fly, drive and wander around an open area on foot right out of the box. I think more features to open the modding up to a broader range of tastes wouldn't adversely affect the hardcore milsim fans. Like with most companies, interest in what they create waxes and wanes. They've been around quite a while with a steady flow of loyal fans. But I'm not sure that a niche market is what they want forever. It's not simply about growing. Diversifying may allow them to keep the train rolling. :)

Check my reply on this thread. There's no point in repeating myself. https://forums.bistudio.com/topic/78900-ww1-mod-expansion-pack-release/page-5#entry3068382

There's only one hook for reloading in OFP/CWA, as far as I'm aware. You could animate a reload on the move. But that animation would play every time you preform a reload. So it's one or the other. Stop is used because it's more acceptable in any given situation. The whole body is taken into consideration for an RTM. You can't play an animation just on the torso and have another running on the rest of the skeleton. A2 does it this way. Similarly to hand anims for weapons. Which allow the engine to override the bones current position in the base RTM. If someone scripted this for OFP/CWA I haven't heard of it. Is it possible you're confusing this with the bolt-action reload WWIIEC did?

There's no hit detection specific to a melee weapon as far as I know. Any attempts at making them so far have been achieved via script. It'd certainly be a nice addition, and open up more modding possibilities.

The exporter doesn't differentiate between model types. It simply sees the objects tagged as having Arma properties. There's nothing needed on that side to tell either Object builder or the engine what it's dealing with. The P3d and the configs take care of that. If you're just doing a uniform, all you need are the weights from the character transferred to your mesh. After that you duplicate the mesh onto another layer, and reduce it manually, or use the decimate modifier, to get your resolution LODS. The weighting and UV co-ordinates will be retained. If the samples are representative of clothing, then the main concern is the resolution, Shadowvolume and geometry lods. Use the data transfer modifier to grab the vertex weighting from the character and have them applied to your uniform.

Maybe he means the slight transparency near the top of the sight. I thought that was intentional though. A rough simulation of the way near objects get blurred and partially transparent when the eyes aren't focused on them. Besides giving a bit more situational awareness.

If it has the relevant vertex groups you should be ok. The exporter will take the those as selections when converting to P3d. If that for some reason doesn't work, you can use the data transfer modifier. This will allow you to transfer the weights directly from the character sample P3D directly to your uniform. From there, if needed you can tweak the weights. If you use a pre-rigged (Functioning armature) character you can pose it to check the deformation of the uniform is happening correctly.

The company should be advertising to get the game sold. No arguments there. In fact they should probably be pushing it a bit more. Especially the modding aspect. But an ad should be an ad. And an article in a "magazine" that frequently reviews Pc games should remain impartial. How else can their opinions be considered unbiased? The only thing that changes the slant of the piece is the author, a representative of the magazine, getting directly involved in the sell. "be sure to download the game on Steam today." Which isn't really necessary. If PC gamer want to talk up the game, great. But it might mean a bit more if it's of their own volition. BI can pay for ads. PC gamer can do a glowing review. No need to mix them.

As much as I take the media in general with a pinch of salt, the video looks like what it says it is. A peek at something new. They paid to get some exposure in the same way any business would pay for advertising space within the magazine. One line does bother me slightly though. "be sure to download the game on Steam today". Without an honest review? And given the paid nature of it, would it be biased?

I don't know about OB, but in O2PE you have to save the animation as an RTM. When you save the P3d that's all you're saving. The RTM can then be loaded up and played on your mesh. Getting it in game will need a suitable config. I don't know the equivalent class in A3. In A2 it's CfgMovesMaleSdr. You'd have to then redirect the relevant state to your animation. I can't be much more specific. Someone who's already explored that might shed more light on it. In the original OFP there was a very handy class called StatesExt which was made to do exactly this kind of thing. So the user wouldn't need to rewrite an entire CfgMoves section. Unless I'm missing something, this appears to have been removed. Shinkicker mentioned his character moving on the spot. That's because the engine uses the step values to determine the distance travelled. If the animation did move it would add the step value, moving the character twice the distance they should, in game. It will also cause the animation to visibly "loop" back on itself.

I think the biggest obstacle people complain about is the layout of Blender. At least initially. I know that was the case for me in the early days. Especially after experience with other applications. Pre 2.49. I even gave up on it altogether. But I came back eventually as 2.49 was reaching the turning point to 2.5x. I decided to leave preconceptions behind and just accept the fact it was simply different. Not bad. Once I did that, things moved a lot faster, and became more enjoyable. It's by no means perfect. Many flaws still exist. As they do in any other software. But it's still a very powerful application nonetheless. Now with Alwarren's excellent toolbox addon it's become more relevant to the Arma series. I think you've covered a lot of the things I would've mentioned myself. So I won't add much to it. The good news is that the basic principles in modeling are universal. So most educational material can be applied to whatever you use. Topology, especially when using sub-surface division, is very important. It's something I'm always learning about myself. Working with quads, for example, is not essential. But it does have advantages. The simplest one being neatness. It's easier to work with visually. And makes for faster selection. Making the edge loops flow around certain areas will not only reduce shading artifacts, but allow you to isolate areas for added detail, without affecting the rest of the mesh. Whenever possible only use as many loops as you need to get the desired result. Don't be tempted to start bunching up support loops to get a sharper edge. Most of the time it'll end with pinching and ripples in the mesh. It's not always intuitive, so it does need practice and some study. As horrible as it might sound. What ever program you choose, it's very important to learn how to use it. Take time to study it. If you don't know how to use an application you'll quickly get frustrated. Not every tutorial assumes you are a novice. And don't get bogged down in tutorials either. I know of people who spend hours watching tutorial after tutorial, but never seem to get around to actually applying it. Take a break from them occasionally and experiment. Make mistakes. It's a pity the groups went bye-bye after the board change. While there's plenty of material elsewhere on the web, it'd be nice to have a more local source for information like this. Anyway. Although I'm not modding for A3 myself, it's nice to see a thread like this. :)

Thanks Foxhound. I've updated the first post to include your link. :)

I haven't explored that type of animation to be honest. I know it's possible to reload while in motion since A2. But I'm not sure whether it's tied to the reload action specifically. You could certainly create the animation within Blender. It's how to apply it in game that might give you some difficulty. Static poses wouldn't be a bad place to start, if you're just getting into it. :)

Another small tweak to the file. I moved the forearm bones onto the first bone layer. This should help correct potential collapse when rotating the hand forward( palm to the back, as opposed to the front). Links have been updated on the first page.

I think the recent posts aren't totally unrelated to HG's work. He may well appreciate some help with the workload if he decides to go with custom animations. But that's his call of course. He might also like to take it on himself, as a challenge. :) The last link you posted on the previous page is what myself, HG and others are using to export rtm animations and meshes out of Blender. I'm not sure how many people have played around with FBX. Maybe that format could be used to get animations out of Object builder/O2 for import into another application? Maybe Zeealex or someone else with Max experience could shed light on that. As it's an autodesk format.