Macser

A lot of folks have used Sanc's ww4 units as a base. These are based on a mix of the resistance civ and some elements from the default soldier meshes. Is that what you're using yourself? To date I've probably done a few hundred animations. A lot of them using the strange "base" pose. Hands down by the side. Feet wide apart. Apart from some small errors on my part, initially, export was trouble free. I'm at a point now where I don't bother previewing the results in OFPanim or O2PE. I just go straight to game. Static poses are incredibly fast to get together. Dynamic animations where the character moves require a couple of extra steps. But nothing that would make me go back to OFPanim. No matter how handy it was. I have so much more control over the process. Just the ability to create a library of animations within one blend file is enough. But there's also the flexibility you get from constraints and drivers. And the fine control offered by f-curves. If you'd like a hand with anything relating to that, I'd be happy to help out. Either post here, or send me a pm. :)

Looking good so far. Even for a couple of vehicles it's no small task. :) As to the previous poster, setting up the stowing/deployment of the pods shouldn't be too complex. If I can do it in OFP it can probably be done better in A3. I didn't use any looping scripts. Just 1 linked to a user action, with a condition for the pods arming/disarming/animating and 1 for more accurate launch positions for the missiles and rockets, tied to a fired eventhandler. The user action script simply animates and either removes or replaces just the launchers, not the ammo, as it's triggered. The action itself will only appear under a certain speed and height.

Animating a drone wouldn't be the hard part. Well, not the hardest part. Configs would arguably be harder to get together. But I assume actions could be directed to a small set of animation states. Laborious and probably very boring considering the number of them. I imagine what Bad Benson and McRuppert did with their raptors would be very similar. Of course you could ditch the whole alien deal and go with the military background hinted at in the technical book. That would bring it down to something slightly less ambitious. Not that anyone should be expecting anything outside of a few addons. I'm sure you'll have enough to do getting them ready. :)

Ok. As I mentioned earlier I don't mess around with hand anims much and I don't mod for a3. In the character model if you look at it in Object builder, there's a proxy called "\A3\Characters_F\Proxies\weapon.001". That proxy is also part of the selection "weapon". The weapon bone in the rig controls that. If you delete that bone then there will be no data in the rtm to control the proxy. So it will most likely default to whatever position it has in the model once you bring it in game. Which means it will be to the right and buried in the ground. It definitely won't be in your hands. I don't think hand anims alone will be enough if you intent to use the axe as an actual melee weapon, like in Dayz. Hand anims were created simply to make the hands fit whatever model the player is using at the time. Some rifles just have a standard barrel cover. While others might have a fore-grip. Or an under-slung grenade launcher. The hand anims simply allow the user to place the hands for that model, so they don't grasp it incorrectly. They act like an "offset" to whatever animation is running. But that's all. I just thought I'd reply to make a few things clearer. It would be better to wait for someone with more experience to show you how to proceed. I don't want to lead you astray with incorrect information. :)

As HG suggested. Bringing up the properties panel ( Shortcut key N) on the right of the viewport will show the "Arma Object Properties" section. Armatures have their own properties . Just as object meshes do. With the armature selected, preferrably in pose mode, you make sure it's properties are tagged as you see in the image. Then you will have access to the frames and the exporter.

Those storage crates look really well done. Did you bake some light into the texture at the top? Whether it's intentional or not it looks like the glass is picking some up. And I love that render of Shodan. I'm afraid you'll just have to wait for the singularity. Could be a while though. :D

If they thought it was something that would cover a large user base, then I'm sure BI would go with it. They are after all trying to make some cash. I imagine it's harder to gauge than we think though. If you take this forum for example, I'd bet the amount of people posting is fairly low in relation to the overall number of members. Without people making it known what they actually want BI would have to go with what they know. Which to date has been light military simulation. Despite the near future setting, that's what A3 is, with some variation on the theme. Personally I don't think it would matter too much if they went with the tried and tested or something relatively new. If the tools and engine weren't as limiting in certain areas that would open up modding for a wide range of subjects. Science fiction/fantasy/historical. Things like mass being global rather than class based. Improved particle systems. Basic melee. That wouldn't require sinking the flagship genre they've been using all these years. But would still offer people who want it, a chance to explore other themes via modding. Modding has always been a big factor, directly or indirectly. Directly for people who actively do it and indirectly for those who don't have the time or interest, but can still avail of what comes out of the scene. Right now the only thing blocking people from making what you're suggesting, and doing it justice, is the inability of the engine to accommodate it. I know people have tried and done a decent job to date. But it usually ends up being about hacks, scripting and work-arounds. Even for more traditional subjects. I don't think a company could ever provide a "game" that satisfies everyone's tastes anyway.

Yeah. When you don't know what something does, the only thing you can do is push the values to extremes, until you get a noticeable reaction. I've found some good info that way. I'd never seen those classes until you pointed em out. Even after all this time. :)

Depending on the object baking can be a kick in the nuts regardless of the program. Some models play ball and behave nicely. While others just continue to fight ye. :D

Can you explain what you mean by "deleted the weapon's bone" ? I can't think of any reason to delete bones in this case. Is the P3d for the axe still in the same position it was , in the previous picture you showed? :)

Do you mean you downloaded version 6.1 of the blend file? If so it's not set up to export to BVH anymore. I stopped using that a long time ago as I found it too messy. The last few versions of the rig are only compatible with Alwarren's Arma toolbox. Using the bvh exporter with that last version will give you errors. As the rig no longer contains any links between valid bones. If you need a little help setting it up you can pm me. It's not a complicated process. The good thing is that animations like the one you are doing, can be exported directly without any messing around with dialogs in O2/Object builder. You just export and load the rtm onto the model. Or go directly to game.

Sorry for any confusion. I misunderstood what you were trying to do. I had it in my mind you were doing a pose despite you mentioning hand anims in the first post. :rolleyes: Leave the weapon bone where it is and move the hands to to the weapon mesh. Instead of the weapon to the hands. I imagine that's going to be pretty awkward without any visual reference though. Or bring in a model of the axe and animate the hands gripping the handle. That's the best approach. Just make sure you switch off the "childof" constraint before you do anything though, as the weapon bone is parented to the right hand by default. Any translation or rotation of the right hand will automatically affect the weapon bone too and be included in the exported rtm.

Ok. You seem to have your mind made up that the model position won't cause any issues. That's your call. Maybe you should config the axe as a pistol. Then you shouldn't have to worry about hand anims affecting the results. As a pistol doesn't require an animatable bone. It's proxy follows the right hand.

Ok. I think that's going to cause you some problems unless you bring the model into Blender. If you don't you can't see how the axe looks in the character's hand until you bring it into OB or the game. If you intend to make the axe a primary weapon, then it should have a similar orientation to the default weapon mesh in the A3 example model. Like this: And the axe model itself, aligned to a rifle mesh: You should end up with something like this in object builder:

Before I say anything else. Can I see a picture of the axe model in your Object builder viewport? The problem could be hand anims. But it's best to make sure there's no issues with the model and character animation first.

I don't have enough experience configuring hand anims to advise you on that part. From my point of view there could be an offset on your axe model, which means using the weapon(m16) as a reference, is giving you a false idea of where it is when you animate it. Ideally what you want to see in object builder should be the same as what you see in Blender. I think you need to direct the weapon proxy to your axe mesh using the a3 example character, and then extract it to see where it actually sits in 3d space. In order for it to work it should sit roughly where the weapon is in the example character. Do you understand what I mean? :)

Ok. So how does your axe model look in object builder? Where is it situated on the grid?

I'm not getting any problems myself when exporting and loading an animation onto the A3 example character. What are you using as a reference for the axe in Blender?

Out of curiosity, what does the animation look like in Blender?

Avoiding seams is hard to do, unless you have either flat shading across the seam or you're willing to paint it out directly on the model. If you're sticking with an image editor only, like GIMP or photoshop then make the area near the seam as flat as possible. By that I mean keep the exact same colour values on either side of the seam. If you were willing to try the other method, which is far more interactive, then you can paint out any seams directly and see the results in real-time. Programs like 3d coat and substance painter can do this. Or if you're strapped for cash, as Delta Hawk suggested, try Blender. It's the more effective method of the two. What ever you decide, try to keep your textures free of obvious light sources. They'll only look decent from one viewing angle. Also keep the "texture" (Basic patterns) consistent. The idea is to let the diffuse, also known as a color map, take care of exactly that. The general colour. You can enhance indented areas, or add things like paint chips or dirt. But try to keep it to a minimum. Especially highlights. That's taken care of by a specular map. Use that to define the relative gloss or roughness of the material. It'll be easier to understand what's going on if you don't use the terms "texture" and "material" interchangeably. Think of a material as a "container". Into which you slot your different textures. The color map, normal map, ambient occlusion and specular. Each of these takes care of a different aspect of the material. You can if you like just use a diffuse texture. Although it won't look very interesting, and may not sit well in the game environment.

Yeah. That's not a file path. Correct that first using WilliamsGSG's example.

You can use the decimate modifier on a duplicate of your first res lod, and go from there. Although take it easy on the first couple of lods.The modifier will try to keep the silhouette as best it can, same with the uvs. But as it loses faces the uvs will start to shift. Keep an eye out for anything that looks very off. You'll know what I mean. Problem areas can be separated out into an object allowing the modifier to work with something more manageable. Then you can apply it, and reintegrate the object back into the mesh. Making sure to weld any duplicated verts. The equivalent, in Blender, to merge near in OB/O2 is "remove doubles". Short cut key is W while in edit mode. You can set the distance between verts to be welded once you hit W. It'll pop up on the toolshelf to the left. The default value is good for most things. As it's set for verts that are basically right on top of each other.

I've never had that happen once, in all the time I've played it. It has plenty of flaws. There's no doubt about that. The subsequent titles have plenty of their own though.

If the same textures render correctly in game, I don't know what would cause it. I suppose if you're using it on a newer operating system like Win 10, it could be an incompatibility with that. I don't know of any options that would correct it within O2light though. I've gotten used to working without O2light for quite a while now. Most of the time I'll just use it to correct the normals after export from Blender. I don't bother previewing models in buldozer, unless an issue pops up.

Hey. It is you. Glad to see yer still alive n well. OFP can be a hard habit to kick when you're used to it. :) So the textures are greyscale? That's the first time I've heard of that happening.