scotg

A lot of these issues, while valid, are mere config adjustment issues pertaining to the ArmA 3 tanks. As a mod-er, I'm more concerned with solutions that might help imported and custom made tanks as well. Not all tanks are the same, and when creating fictional tracked vehicles the parameters are limited to the very basic, narrowly conformed layout of the game tanks. There are work-arounds for issues such as variety of wheel sizes on a single tank, but what about visible drivers? If I wanted to make a bulldozer or crane with tracks, the driver wouldn't be seen. In fact, I DO have an armored, tracked vehicle with a glass canopy for the driver, but I have to "turn out" just to see him at the helm from outside. Semi-related to tanks are half-tracks, and the best mods with these don't handle at all like half-tracks should IRL. Since half-tracks are supposed to be as easy to drive as a regular truck, more or less, having tracks enabled in carx makes the most sense. I dare say it would be nice to see even Quad-Track vehicles working, such as snow/mud-enabled pickups where all four wheels are each replaced with track assemblies. I'll have to agree with the destructible environment issues, although I do realize that's a huge task. My main gripe on tanks vs. obstacles is doing things like plowing through trees, fences, tents, and telephone poles - only to get stopped dead in my tracks by a chicken coup. Sections in stone walls and roadside guardrails should be getting mangled by smaller vehicles and utterly destroyed by tanks. Speaking of bulldozers, a big heavy vehicle shouldn't have to depend on its momentum to knock down trees. E. G.: if I drive a 35,000# tank into a tree at 1mph, it should still be able to push that sucker down, rather than having to build up speed first. I'm glad to see that some issues are getting addressed and corrected, but I also fear that mods have been forcibly homogenized in the process, which could potentially stifle creativity and variety in vehicle addons.

I am indeed working on a bigger GI Joe mod than just a few vehicles, but this is just the beginning, strangely enough. I started doing GI Joe mods in 2004 with Unreal Tournament 2004, and switched to Battlefield 2, then Crysis/Crysis 2. I took some time away from game mods while serving in the real US Army as a 25U, and now I'm focused on converting and updating the assets for ArmA 3 (I was unaware of ArmA games until right before A3 Alpha was released). The GI Joe- and Cobra-inspired assets I created have evolved into more developed projects as the games have become more sophisticated, and for each game I have had to modify the assets to conform to different formats. I have some written documentation and unwritten plans that are part of a much larger scope, but I will need to get a lot more talented, interested people on board. So far, I've gotten really positive reaction, but the numbers are low. I am thinking about starting a Patreon or Kickstarter to back the funding for this. At the moment, I am a stay-at-home dad of two girls, developing game assets between diaper changes, formula/milk/juice refills, meal prep, cleaning, play time, and nap time. I never actually get to play ArmA 3 unless I am testing something I've made, and I haven't even been on a public server since A3 Beta was the most up-to-date version. But I'm not throwing a pity party for myself; I just want to present my work to test public reaction, then possibly look into recruiting if that goes well. :-) If you're interested in seeing the previous assets I created - what they have evolved from, I have set up some subsections in my deviantArt gallery. GI Joe for UT2004 - These were basically toy-to-game models, without much thought given to any real-world design or proportion. GI Joe for Crysis - These were starting to become more realized for the confines of reality - an important step towards today's versions.

Thank you much! I have two versions of my own M2 that might go there. My goal is to make the vehicles as they are more commonly seen first, but keeping in mind different weapon configurations and such for future variety. After a few releases I will go back and start working on the variations. You're right about the FAV. I believe I mentioned something about it in the video, but not in so many words. In a nutshell, I started off with how the NAVY DPV is newer than the AWE Striker and couldn't have been the influence, and I continued with how the earlier ARMY FAV is the more likely source of inspiration. Thanks! It's good to know I'm not the only one, and I hope to make it more appealing to more folks with my re-imagined and true-to-life designs.

Thanks! I believe these might interest you: - GI Joe 3D - ArmA III Mod Assets

All the KB/M people seem to like, and all the stick users seem to not like it. I use gamepad/thumbsticks, and even though I've learned to fly a lot better, it's way less fun and doesn't seem practical in a hot zone.

I'll give this a try. So basically, the source "time" will make it rotate consistently, as per a clock? ... But then when the engine starts source "rpm" should swap out the static fan for the consistently rotating one, right? Is there some reason I can't just use source rpm to make the fan rotate in a loop when the engine is on? I can't; I tried. I just want to know if there's a why or if I just plain did it wrong.

Good news! After finally getting to the bottom of the problem, and with thanks to UK_Apollo and RedPhoenix for their tips and support, the AWE Striker buggy is driving and performing even better than before. I've been recording it in motion hopping around the hills of Stratis, Altis, and Tanoa, and will hopefully have a video of it on YouTube soon. I've also sorted out the problem with the Crew poses, mostly. EDIT: Here's the video!

One of my cars is faceplanting over hills and even the smallest of bumps. The effect is so bad it ends up on its back, like it's trying to tumble forward in-air. Being a buggy, part of its testing involves jumping from berms and off of cliffs to kind of gauge its balance, which is how I discovered this. It also hugs smaller bumps in the front while the rear wheels are really bouncy, even though all wheels inherit the front-left's suspension values. The buggy was working fine until I did a series of minor tweaks for suspension adjustment. Since discovering the problem, I have worked backwards trying to restore it to its working state, only to keep seeing this problem. It's as if there's a tank-sized mass sitting on its front bumper. I have already looked into the model's geom LOD. Unless I need another look, the mass distribution and CoG is on point. So here's what I'm wondering: Are there any config settings that will affect this so dramatically, despite the geometry positioning? Here's a list of some things that seem to have no affect on the nose-heavy action: - terrainCoef class Wheels: - mass - MOI - dampingRate - sprungMass - springStrength - springDamperRate - latStiffX - latStiffY Pertinent Config Section (anything missing?): It should be noted that this is a 650 kg RWD, Rear engine buggy. If there should be any imbalance, it should be back-heavy. Strangely, whenever I shift the Geom LOD weights toward the rear in OB and recompile, the result is the rear suspension is compressed all the way, and it still nose dives off of cliffs -- another reason I think there might be some config setting that defeats the weight distribution. PLEASE HELP?!?!?!

Yup. It turned out I had saved a PBO to an old location, but it was accessed sooner in the hierarchy. Since then, the updated PBOs I've been trying to get working were being bypassed (and to think of all the missed results!), except for the model information. See, but that's the part that was throwing me off. This all sucks, because I had set aside some time to do more art work on my models. Researching and fixing this ate up most of that time, and aside from its two improved crew poses I made, I'm practically right where I stood before this mess. What really stings is how simple the problem was to fix once I discovered it. At least I can move forward now, and I got some good advice from you guys! Thanks for all the help UK_Apollo and RedPhoenix!!

Update Some of my config file updates are not being recognised by ARMA3, including the buggy. I copied all the buggy's files and components and created a "new" vehicle folder by simply changing every instance of "striker" to "shocker" inside and out. The new buggy was not visible in the virtual garage, but I could load it in the editor and test it in a mission. Although not even close to perfect, there was a noticeable improvement from the original buggy. These are the exact same build, except with different names. Next I tried to adjust the new buggy, but ran into the same problem as the old one - the update is not taking hold. I opened the PBO in eliteness and found it was indeed compiled anew. I then made a simple displayName change to another car, the LM002 to The BULL, and it was not recognised in game. I did tbe same to my Sky Hawk VTOL, renaming it Seahawk, and it took! So either the game doesn't like car mods, doesn't like MY car mods, or most likely all my cars have inherited some bad joujou. Or maybe it loves NFL :-D. At least I can identify the problem.

I think I might be on to something now... possibly. The game is not looking at the new config, or something. First, I tried renaming the vehicle in the displayName value. In the garage, it kept coming up as the old name. Next, I tried just deleting the PBO completely, but the name STILL appeared in the virtual garage. However, selecting the vehicle immediately puts me in "try it" mode, without a buggy, and without actually hitting the try it button. Whenever I have made a change to the model itself, there has been a notable difference in game. That, combined with the name still in the game when the PBO is gone, leads me to believe the compile process is probably working. BTW, when I was done with the garage, I pressed escape, then ctrl+F4 to quit. Usually it just quits, but this time it gave me the warning message about "ArmA 3 unexpectedly stopped." Something wrong with my game?

ok. presumably of the vehicle in motion? Setting up a scenario now. EDIT: Here's the video: https://www.youtube.com/watch?v=btLa687XxRI

LOL. True, but that's not the issue. I re-component convex hull whenever I reassign weights - habit. I just forgot to re-CCH for the picture.

I've tried all sorts of weight distribution combinations. This is the current set up with each wheel as 20kg. The little decimeter cube in the back helps me move the weight around and try different distribution. I have tried using four cubes containing most of the weight (using the same principle of moving them around for balance shifting), while the main geometry weighed 5 kg total (as per the BIS examples). Side View Geom LOD

Just for eliminating all possibilities, I've re-centered the CoM to the F/B; it was already L/R centered. I've yet to check it out in Dev Branch mode. Are there any forewarnings for that, like will I be able to revert back?

Is there any impact CoM position in relation to the world axis/origin (0,0,0)? I.E.: Should the CoM be there?

@HorribleGoat: Maybe you can help me. I created a pose, saved, and exited - but no export to RTM. It took me three hours to make it, and when I reopened it I realized I had forgotten to start a new keyframe, so the T-pose was gone. Now, I'm racking my brain trying to figure out how to integrate the new pose with a T-pose, or vice versa. The hard solution is to start from scratch and do it all over in a new frame this time, but is there a way to copy/import?

This might seem a little crazy, but is there a way to get driver poses from vanilla RTMs and edit them to fit into other vehicles? There are a lot of good choices to start from, but none of them are ever a perfect fit for my vehicles. Starting from scratch is one option, using the sample files, but then there are the hands. Yeah... it's mostly all about the hands. Moving arms and legs around is tedious enough, but moving individual fingers seems exhausting, especially when the driver has to grip something like a wheel or control stick. Alternatively, does anyone have any p3d pose models featuring hand gripping, that they are willing to share?

Anyone know what to do if you jack up the default pose when creating a new one? I spent a few hours getting a pose just right, only to finally realize that it was the initial T-pose frame. Any way to re-import the initial pose without losing the new one?

This post comes from the perspective of a modder, particularly with vehicles: I agree with Drift_91, above, about having VTOL flight model options. I'm not convinced a straight-up helicopter type system would be best, but a choice to have the previous VTOL flight system would at least be "not a step backwards." With the new flight model and a VTOL I can takeoff, fly, land, taxi, and even do vertical landings, but I wouldn't say it's just fine - not by a long shot. It used to be fun flying VTOLs, but now it's just a chore. It takes a long time to throttle down, speed brake, position the aircraft, and finally set down. By then I'm lucky if I'm anywhere near the LZ, and I usually have to descend from at least 250 meters even after approaching at 50. Helicopters are a cakewalk compared to this. You can come in quickly and low with a constant stream of micro-adjustments, and then set down exactly where you want. I want the same degree of control and speed for my VTOLs without having to turn them into rotor-less choppers. While I kind of like this new system for standard flight, the old way was far better for VTOLs. Oh, and I use an F710 game pad (for all vehicles), in case that matters. This is where I go into a semi-rant, so take it with a grain of salt: Personally, I think revamping the flight system is like putting the wagon before the horse. There are a lot of infantry movement issues that seem more priority, and I'm not even talking AI. One annoying thing is having to run up, stop, and slowly step over even the smallest of obstacles. There needs to be some official implementation of fast-paced obstacle clearance, like some of the mods have. I'm not saying every soldier needs to have parkour skills, but If a real life drill sergeant witnessed soldiers approach an obstacle that way he'd eat them for lunch and poop out their grandkids later. And the characters move around so friggin' much! There's no military bearing, the way they squirm all the time. Do you need to wipe your brow every 7 seconds, or check the bottom of your shoe every 10 seconds? Infantry is just one area that has been overlooked, and even ground vehicles should get more attention before aircraft. We need better looking suspension, for vehicles that have exposed struts and springs and large moving parts (a vehicle IK and vertex weight setup would greatly help). There needs to be towing - not just piggie-back towing, but real towing with trailers and hitches. We need an option to see tank drivers, for certain real life and custom tanks. We need an option to use a dual-stick game pad like real tank controls (who knows if they will do this for the tank dlc). How about let's get some tracks on cars, for better half-tracks and quad-track trucks with steerable tracks. We need the option to give drivers and pilots the ability to operate a turret via helmet (such as the AH64), at least in custom vehicles. I'm starting to get into some wishful thinking, but it's all (every bit of it) a better use of time than revamping the flight model. Even a radio sim would be better. Train up on frequency hopping and ComSec! Can't get a signal, eh? Then you'd better deploy your OE-254 and make sure you put a perimeter around it so the privates don't screw it all up (and get the crap shocked out of them). I jest, but it's a good point I make. The thing that bothers me isn't that ArmA 3 vehicles have all these limitations; it's that these limitations are also imposed on potential custom vehicles, whether real or fictional. It's getting so that every mod has to stay within an increasingly tighter set of parameters, and as such, vehicle mods are becoming far too homogeneous. I wonder how the Star Wars mod guys are coping with the new flight model. Are their A/B/X/Y-wing fighters still able to take off and land quickly?

I found the solution for the passenger pose; it was a line of the config, in class ManActions, that was accidentally still commented. I can't remember why I commented it, though. Now that I've been able to move it along, I am not too happy with the poses. They are suffering from deformation because of me adjusting them in OB. Is there a way to make bone sections rotate around their pivot points and obey the hierarchy, when editing? Currently, they are only rotating on the selection center, which means I have to reconnect the joints. Apparently, I missed in several places. Note the passenger's right arm, trigger finger, and left forearm, as well as the driver's wrists. Wonky bone structure

Can someone point me in the right direction, or perhaps offer some guidelines? I'm not entirely sure what questions I need to ask, even... I have several vehicle mods and a couple of soldier gear mods, each one self-contained, but I want to merge them under one blanket mod. It was always my intention to eventually do this for the sake of consolidation, but now other reasons have made the need a higher priority. I have some universal textures and models, such as commo equipment and pioneer tools, that can be attached to each main model (usually a vehicle), but I want to have them all in one place. I'll probably have many of them as add-on proxies, if possible. So far, all of my model, config, and material paths have been relative to each individual mod. I know I'll have to change all that, but I want to get it done so that future projects will be consistent. Also, I figure the organization of other assets like custom classes, faction icons, fonts, and environmental textures can also benefit from doing this.

That's what I thunk, but I had to be sure. LOL So the problem persists...

These are vanilla paths. Does this work with custom paths that point to custom poses? Could it be a problem with the config? I'm thinking that since the pose is extracted correctly in OB, then the RTM is not the problem.

I followed Abs' video tutorial, and just renamed it cargo. I get it that it might not take if you don't end it with cargo, but in the video he just replaces the whole directory path with cargo. I did that for the driver proxy (renamed it driver), which worked. So... I just still don't understand why the driver proxy is working but the cargo proxy isn't.