Macser

Just to be on the safe side, make sure you're in pose mode when you're exporting. You can't load an rtm from the file menu, if that's what you're doing. You load them onto a model from the animation window. If that's not a visible panel in your object builder, you can activate it from the window menu. When you right click in the animation window you will get the option to "load matrices". When you click on it you can navigate to any saved rtm and the frames will be loaded onto your model.

Use Alwarren's arma toolbox addon and export directly to an rtm. Object builder will open that format natively. I don't personally bother with BVH any more. I know some folks who still do. But to be honest there's no compelling reason to do so. That's one of the reasons I didn't supply a BVH compatible rig.

You might not get too many folks still posting here. Just like with cold war assault. Although that doesn't mean there's no-one still playing or modding for it. You just might have to dig around to find them.

Those textures are still in those PBOs if that's what you mean.

The only manual I can see is on the first page. For extra features. Maybe if you were more specific about what you want to do, it might help. It's probably going to be difficult to get someone who's willing to do a full run-down on the entire mod. When you say "change the models of vehicles properly", what do you mean? There should be plenty of info on getting an addon in-game right here on the boards. I'm sure you can dig up what you need. And if you get stuck, there's still a few people around, like myself who can offer advice.

Basically this happens when the units are not in cargo on mission start. If they are in cargo at mission start, the animation for the cargo slots plays correctly. The units in question are part of the player's group (me). And I'm in the command position. Anyone seen this type of behaviour before? It doesn't happen with default vehicles.

Possibly. But it's something limited to this particular adddon. I have never seen this before with any other custom or default vehicle. I managed to get a position on the lefthand selection though. And there is a small difference: The vehicle may have moved slightly. So if that's taken into consideration the readings would probably be the same. It may be a rendering issue of some description. Not sure where that leaves me though. Up the creek without a proverbial paddle presumably.

I don't think the model is necessarily the problem. Configuration and animation are the deciding factors. It's a fairly involved, time consuming process. Even with a well made rig. Still. If a suitable model was found or created, I'd be willing to at least rig it. The only potential downside is that it would be done with Blender. Not a downside for me obviously. But I know there's quite a few people who simply don't like it.

About the selectionposition command. Would it need to be run from a script? With hintformat to output to the screen? Scripting is not my strongsuit. I thought I might be able to stuff it into a trigger and run from there. Just to verify, as I hadn't tried it in a while, as long as the vehicle is also part of the group, the cargo slots have no issues. Also it still happens whether or not the units are part of the player's group. The deciding factor is the vehicle being in the group. Why that should have any bearing on whether a unit's body is drawn or not seems ....odd. I won't go so far as to say there's no errors with the model or the proxies. But they do at least work in the above circumstance.

@HG I have removed and re-added the proxies. This issue is affecting all of the cargo positions. Not just that one. I just happened to have one unit in my group at the time. @Mondkalb I'll certainly have a go at that. It's been a while since I tinkered with it. I am using a custom rtm, but I'm fairly sure it happens regardless of whether it's custom or default. I find it odd the head should stay where it is though. Or that it should only happen when I or the units in my group enter a vehicle that's not under my command. Thanks for the responses guys.

No. There's actually a default unit sitting in that slot. For what ever reason the body isn't being rendered. And I still don't know why. I don't recall ever seeing anything like this before.

Hey HG. It's only an issue when the units are outside the vehicle on mission start, and ordered into cargo. Seems to happen regardless of whether there's crew or not. It got a bit frustrating. So I had to bail out . It'd be nice to see it working though. For all I know it's something very simple. But it eludes me.

I think that's the one thing that catches everyone in the initial stages. It's caught me on more than one occasion. It'd be nice if the foundation put in a small warning message, even on the top bar, about applying changes made in object mode.

I didn't know him on a personal level. But it's obvious Bushlurker was a positive presence, and influence. That's something worthy of remembrance whether you knew him or not. May he rest, or wander, in peace.

Right. I'll see about sorting that out as soon as I can.

I can't make comments based on anything other than what I know to be true. I'm not an experienced coder, and scripting is definitely not one of my strong suits.But, having said that, the scripting commands for either version are set in stone. If a build of an engine does not have provision for a command it will cause an error when a script is run, using it. There is no provision for GetPosAsl in 1.96. The engine only recognises GetPos. 1.99 on the other hand will accept both. Short of changing the script and replacing the GetposAsl command with GetPos, the only option is using 1.99. Those are the only methods I can see, which would cure the error. As far as I know, the returned position is more accurate for GetPosAsl. Even though Getpos worked/works, it occasionally needs some "assitance" where sea level is taken into consideration.

Not all that surprising considering the original post is 14 years old. If there's a particular addon or mod you're interested in, and it's no longer available from the original source then make a request here. It's no guarantee of success, but it's better than posting in inactive threads.

The part about the naming convention I mentioned on the first page. But the rest will be invaluable. So thanks for posting back. In fact I'd say that warrants a separate "solved" thread in the A3 modeling section, so it doesn't get buried in here. You could suggest it to a moderator and see if they agree. If there was concern about it getting spammed it could be locked after creation, unless it really needs to be updated with new information.

Yeah. That definitely has cropped up, from what I've read. But I thought they'd rectified that in later updates to the tools. In any case, I'm glad to hear you're getting into the area of animations. It's often overlooked, even though there's been some fantastic contributions from various people. Any kind of ik based rig really does make the process less tedious. For OFP and even A2 to some extent, the main process was FK or mesh based deformations out of O2. Functional, but not exactly inviting.

I doubt there's too many who would agree , but I think it's actually an interesting visual side effect too. It makes it look like some kind of technical anomaly or aberration in the optics caused by shockwaves. Sure, it'd be great to have some kind of control over it. But considering it's not something constant, I don't find it totally off-putting.

Ok. First off, let me say I'm no expert when it comes to animations. Or even rigging for that matter. Although I've gained a lot of experience since I first started. My intial reason for creating the rig was so I could get into experimenting with animations for the newer titles. But I ended up getting side-tracked by other things, and didn't get any practice in. So I decided to put it out there and hoped that someone else might get some value out of it. Which apparently, they have. Hand anims have always seemed to be a pain for a lot of people. Maybe you've already covered what's mentioned in this post. But I'll link to it anyway. I really need to have a go at it myself. I assume the rig is not a dud, as it's been used successfully to generate hand anims, static and full body sequences. If it failed on one aspect, it's quite likely the others would fail too. Most of the problems I've seen usually stemmed from the official tools or config issues. Try moving the hand bones into the desired location without altering the position or rotation of the weapon bone. The only things of concern should be the hands as far as I'm aware. From looking at the images, there's a correlation between the in game shots and the viewport shots. Especially if you take into consideration that the weapon position is offset in the aiming stance by roughly the same amount as the hands have shifted. The same looks to be true when you moved the weapon bone. It's translation appears to have been added to the position of the weapon bone in the aim stance. Now, I'm open to correction on any of that, but to the best of my knowledge, hand anims act like an "offset" rather than a replacement. So the current position of the weapon bone has to be a factor.

The one on the right made it into the real world via 3d printing, didn't it? I've found that's probably the single best way to deal with seams. Or areas that cut across them. Trying to do a camo pattern that's mindful of seams is extremely laborious using an image editor. It's always a tedious back and forth process. I get by with the limited texture tools in Blender. I know at least one other person using 3d coat. It looks like a great application.

Kenoxite or Krzy will confirm or deny. But I think it's because of your version. getposASL was only introduced in 1.99. 1.96 uses the getpos or setpos commands, so it won't recognise it.

I think if there was genuine interest it would've been picked up by now. Maybe they got tired of it. Perhaps there wasn't enough people working on it. Any number of reasons. The likeliest way to see something we really want is to try to make it happen ourselves. Waiting on someone else to get it done rarely works out. Not what most folks want to hear. But it's the truth. :)

Obviously there's nothing stopping you building models that would be suitable for use in a game engine. Those could be sold, as they're your property. That's between you and who ever buys a copy. What they do after that, could be up to them. As Pufu mentioned, once they pass through the tools they are subject to any EULA BI set out. It might be a bit tricky doing anything specifically targetted to Arma without involving official assets. But I think it should be possible to get close enough that a modder could take it the rest of the way. Otherwise you're probably getting into murky legal waters. I don't know what the specifics are in cases like these. Would payment for creating an asset be seen as payment for work done, as in time and skill? But the end product can be shared according to the author's chosen license. Or would it be seen as payment for a "product" restricted by BI's EULA?