scotg

except that there are no BIS poses that fit this tank...

Does anyone have knowledge with creating custom vehicle weapon arrangements? I've tried searching, but I either overlooked relevant results, or there weren't any. Here's what I'm trying to do: I have a tank with two main guns, which are in the same class as a M2A2 Bradley main gun - only larger caliber (45mm). I want it to have modes for "sustained alternating fire - fast," "sustained alternating fire - slow," and "sustained simultaneous fire - slow." It's more important to figure out the "sustained alternating fire" modes because I hope to use what I learn for a smaller, four-barrel (.50 M2 x4), tracked anti-personnel armored vehicle, planned for future development, and I don't want all barrels to fire at once.

Here's what I want to achieve: I want two barrels to take turns firing automatically. Each barrel's animation should be like a quick pop, and then a quick pause before the other barrel "pops." Here's what is happening: The barrel keeps popping far more rapidly than the actual fired round. Rounds are firing in the desired intervals, taking turns, but both muzzle flashes are occurring when each round is fired. Note: I disabled one barrel until I get the animation just right. config pertinents: class cfgWeapons { class CannonCore; class hissGuns: CannonCore { scope = 1; displayName = "HISS Guns"; nameSound = "turret"; cartridgePos = "cartridge_pos"; cartridgeVel = "cartridge_dir"; cursor = "emptyCursor"; cursorAim = "mg"; cursorAimOn = ""; cursorSize = 1; canLock = 2; class gunParticles { class effect1 { positionName = "cartridge_pos"; directionName = "cartridge_dir"; effectName = "MachineGunCartridge1"; }; }; //magazines[] = {"RDS_40Rnd_23mm_AZP85","RDS_2000Rnd_23mm_AZP85"}; magazines[] = {"140Rnd_30mm_MP_shells_Tracer_Yellow","60Rnd_30mm_APFSDS_shells_Tracer_Yellow"}; magazineReloadTime = 1; modes[] = {"manual"}; class manual: CannonCore { displayName = "Alternating Fire"; autoFire = 1; sounds[] = {"StandardSound"}; class StandardSound { //weaponSoundEffect = "DefaultRifle"; begin1[] = {"hiss\sound\vehicles\weapons\hissGun_Fire",5,1,1500}; soundBegin[] = {"begin1",1}; }; reloadTime = 0.3; dispersion = 0.0005; multiplier = 1; soundContinuous = 0; showToPlayer = 1; burst = 1; aiRateOfFire = 0.5; aiRateOfFireDistance = 50; minRange = 1; minRangeProbab = 0.01; midRange = 2; midRangeProbab = 0.01; maxRange = 3; maxRangeProbab = 0.01; }; }; }; class CfgVehicles { class Turrets: Turrets { class MainTurret: MainTurret { class ViewGunner; class Turrets: Turrets { class CommanderOptics: CommanderOptics { body = "obsTurret"; gun = "obsGun"; animationSourceBody = "obsTurret"; animationSourceGun = "obsGun"; memoryPointGunnerOutOptics = "commanderview"; memoryPointGunnerOptics = "commanderview"; minElev = -4; maxElev = 20; initElev = 0; minTurn = -360; maxTurn = 360; initTurn = 0; hideWeaponsGunner = 1; weapons[] = {"SmokeLauncher"}; magazines[] = {"SmokeLauncherMag","SmokeLauncherMag"}; turretInfoType = "RscWeaponRangeFinder"; gunnerAction = mbt2_slot2b_out; gunnerInAction = mbt2_slot2b_in; gunnerGetInAction = GetInHigh; gunnerGetOutAction = GetOutHigh; gunnerDoor = "hatchG"; gunnerOpticsModel = "\A3\weapons_f\reticle\Optics_Commander_02_F"; gunnerOutOpticsModel = ""; // leave "" to disable optics view gunnerOpticsEffect[] = {}; // post processing effets class ViewOptics: ViewOptics { initAngleX=0; minAngleX=-30; maxAngleX=+30; initAngleY=0; minAngleY=-100; maxAngleY=+100; // Field of view values: 1 = 120° initFov=0.155; minFov=0.034; maxFov=0.155; visionMode[] = {"Normal","TI"}; thermalMode[] = {0,1}; }; startEngine = 0; gunnerHasFlares = 1; viewGunnerInExternal = 1; outGunnerMayFire = 0; // Turn off to make player able to look around freely outside optics view. inGunnerMayFire = 0; // Turn off to make player able to look around freely outside optics view. class HitPoints { class HitTurret { armor = 0.3; material = -1; name = "vezVelitele"; visual = "vezVelitele"; passThrough = 0; minimalHit = 0.03; explosionShielding = 0.001; radius = 0.25; }; class HitGun { armor = 0.3; material = -1; name = "zbranVelitele"; visual = "zbranVelitele"; passThrough = 0; minimalHit = 0.03; explosionShielding = 0.001; radius = 0.25; }; }; }; }; //gunBeg = "usti hlavne 1"; //gunEnd = "konec hlavne 1"; memoryPointGun[] = {"usti hlavne 1","usti hlavne 2"}; weapons[] = {"hissGuns"}; magazines[] = {"140Rnd_30mm_MP_shells_Tracer_Yellow","60Rnd_30mm_APFSDS_shells_Tracer_Yellow"}; soundServo[] = {"A3\sounds_f\dummysound",0.031622775,1.0,30}; minElev = -5; maxElev = 57; initElev = 2; gunnerAction = "gunner_apctracked3_out"; gunnerInAction = "gunner_apctracked3_in"; gunnerGetInAction = "GetInHigh"; gunnerGetOutAction = "GetOutHigh"; gunnerDoor = ""; viewGunnerInExternal = 1; castGunnerShadow = 1; forceHideGunner = 0; stabilizedinaxes = 3; gunnerOpticsModel = "\A3\weapons_f\reticle\Optics_Gunner_02_F"; gunnerOutOpticsModel = ""; // FCS turretInfoType = "RscOptics_APC_Tracked_03_gunner"; discreteDistance[] = {100,200,300,400,500,600,700,800,900,1000,1100,1200,1300,1400,1500,1600,1700,1800}; discreteDistanceInitIndex = 5; memoryPointGunnerOptics = "gunnerview"; gunnerHasFlares = 1; maxhorizontalrotspeed = 1.04; maxverticalrotspeed = 1.04; startengine = 0; hideWeaponsGunner = 1; selectionFireAnim = "zasleh2"; class OpticsIn: Optics_Gunner_APC_02 { class Wide: Wide{}; class Medium: Medium{}; class Narrow: Narrow{}; }; turretInfoType = "RscOptics_APC_Tracked_03_gunner"; class HitPoints { class HitTurret { armor = 0.6; material = -1; name = "vez"; visual = "vez"; passThrough = 0; minimalHit = 0.1; explosionShielding = 0.4; radius = 0.25; }; class HitGun { armor = 0.4; material = -1; name = "zbran"; visual = ""; passThrough = 0; minimalHit = 0.1; explosionShielding = 0.8; radius = 0.25; }; }; }; }; class AnimationSources : AnimationSources { /* class muzzle_rot_cannon {source = "ammorandom"; weapon = "hissGuns";}; class muzzle_source { source = "reload"; weapon = "hissGuns"; }; */ class recoil_source { source = "reload"; weapon = "hissGuns"; }; }; }; model.cfg settings: class recoil_L1 { type="translation"; source="recoil_source"; selection="gunrecoil1"; axis="gunrecoil1_axis";//*probably* sourceAddress = loop; minValue = 0.2;//rad 28.64789 maxValue = 0.4;//rad 45.836624 offset0 = 0.2; offset1 = 0.0; animPeriod = 0.0; initPhase = 0; // memory = true;//(default assumed) }; /* class recoil_R { type="translation"; source="recoil_source"; selection="gunrecoil2"; axis="gunrecoil2_axis";//*probably* sourceAddress = mirror; minValue = 0.001//rad 28.64789 maxValue = 0.02;//rad 45.836624 offset0 = 0.2; offset1 = 0.0; animPeriod = 0.0; initPhase = 1; // memory = true;//(default assumed) }; */ Here's what I think I've learned: When sourceAddress is "clamp" I can almost get the desired animations, but it either only plays once or is frozen in one position - a non-animation. "Loop" plays the animation over and over again, but it doesn't cooperate with multiple phases of the animation (at least not in a way that I could figure out). I tried using this and starting the animation with an offset value after a delay to fake the "pop." The result is that the animation looks like it's going way too fast and continuously, but changing the minValue and maxValue did nothing. "Mirror" seems to do the same as loop, except that it reverses the animation once its limit has been reached. It also continues to animate out of sync with the fired rounds. Because of this, I can't tell if it condenses the whole animation into the time range, or if it extends the time range to fit the mirrored portion in. Isn't there a way to set up the animation for a single shot, and then let the game sync it up with the fired round? That's what I thought I was doing, but it's proving to be more convoluted than it should be.

I tried setting up a new fire mode in my tank's cfgWeapons class, based off of cannonCore. I got alternate firing (1, 2, 1, 2, 1, 2, etc.) sort of working. Projectiles were alternating barrels, but the muzzle flash and recoil animations were not working. To be fair, they were only half working before (i.e.: not alternating). I had had the choice to either name both barrels the same or to just have one barrel firing.

You're probably right, but I wasn't sure. Comparing the vanilla content to mod content, I noticed that BIS vehicles refer to BIS ammo, but RHS vehicles refer to RHS ammo, which led me to wonder if custom ammo needs custom 3D meshes. I know 0.00 about ArmA 3 ammo scripting; I just know there seems to be more to it than what is found in the vehicle configs. Skimming through the BIS and RHS configs, I couldn't pinpoint where big ammo is. Side note: I imagine custom missiles would definitely need custom models, since they are bigger than ballistic rounds and sometimes exposed.

I have created a custom model, complete with the LODs, geom, memory points, etc. It even drives pretty well in Eden; I'm just trying to arrange the config of the turret, especially the main guns, so it makes sense for the vehicle's design. I have "usti hlavne 1" renamed to muzzle1 and "usti hlavne 2" renamed to muzzle2 for memory points. For animations I have gunrecoil1_axis, gunrecoil2_axis... but they move together. I'd like to know how to make the firing and animations alternate. The twin-fire vehicles in Arma3 (e.g.: tracked AA vehicles) all fire in simultaneous mode only, or so it first appears. I didn't recognize any scripting that changed this in their config.cpp's. Also, I wanted to know how to create and assign custom ammo. If modeling is required here, then I would indeed need to know what memory points to create, and especially the scripting.

My tank turns left or right forever (in neutral steer) whenever I press "A" or "D" and let go. Sometimes, I can cancel it by driving forward. Any ideas what parameters can eliminate this ridiculousness? I've been trying to adjust some of the tankX wheel params, such as latStiffX, latStiffY, dampingRateInAir, dampingRate, and MOI. Tweaking these might reduce the problem (like slow it down or it'll only turn around twice before stopping on its own), but I have yet to find a solution that doesn't mess up something else entirely. Any ideas?

I had previously tried borrowing tank wheel and engine parameters from the RHS M2A2 Bradley, but my adjustments gradually got so far off that I couldn't get back to its base performance. Several iterations throughout the trials encountered the "tanks turns forever" problem, or something akin to it. Every iteration caused high-speed skid outs and other steering difficulties, no matter what. I decided to look at all the tracked vehicles available to me once again, and settled on basing tall tank's parameters on the BIS Tigris AA. I was able to increase the speed and drop the braking power to where it suits my tank very well. There's no problem steering, unless it is sharp turning at very high speeds (65 kph or more). Being a tall medium tank, it's actually good that there's a speed/turn breaking point. The only issues it has now are visual wheel spin. Because of the variety of wheel sizes, some of the wheels are invisible functioning wheels, and some are just visible rotational pieces that don't actually interact with the ground. Visible wheels are attached to the same podkolo as their corresponding invisible wheels, thus creating the illusion that it's doing the work. Since the visible wheels are not influenced by the ground it's a noticeable over-spin, but it's also somewhat ignore-able for now. After all this, I'm not sure I have a real grasp on tank editing, but at least I found an acceptable set of values for this one! Many, many thanks to wld427 and x3kj!

When doing 3D model research for vehicle CIPs, I noticed in some of the accompanying images that the ridges-style CIPs (looks like Venetian blinds) can be pulled out of their brackets and turned around. This changes the slants from upward- to downward-facing, and would potentially give a different thermal reading. In one very specific case, two M2A2 Bradleys cover the flank of a convoy with their rear CIPs flipped, slants facing up. The obvious part is that the diagonally cut corners of these small CIPs would fit with the bracket if they were "un-flipped." The scene is also full of other armored vehicles heading into combat, including an M1A1 with its CIP slants facing up. Although I found some interesting information about CIPs through my Google searches, there was no description given as to which is the proper way. From visual references, there are as many image results with slants up as there are with slants down. in the RHS vehicle mods, the slants are always down-facing, with an added decal at the top which says "UP ^." It almost seems to imply this is the correct orientation, although it would be in contradiction with the vehicles in that link. Does anybody know for sure if there is a benefit to flipping them or the proper way of inserting them? Perhaps there are combat and non-combat modes? Perhaps it is flipped when in-country, or during an exercise?

@Cpt.Peakz: oh yes, then there's that ^. LOL. And I was wrong about you not needing a model.cfg. I said that while hastily looking in my helmets folder to figure out what I had done a few years ago. But just a suggestion: I would name your cap something more descriptive, like my_hat_officer/my_hat_officer.p3d, or some such - as long as it matches. I'd avoid using the actual word "my," but instead use your initials or your project tag. E.G.: my two Cobra Standard Combat Helmets (Officer and Enlisted) are called cobra_scho and cobra_sche. This might help them not get confused with other mods, in case someone is trying to identify them. It's still good to have a mesh in the geo LOD in case you want it to lay about, I think. I've got one on my helmets, as well.

Messing with the gearbox in tall tank is only having a moderate affect on acceleration, so far, and I haven't accidentally come up with a graph that makes the tank launch with a drag wheelie. It's a good thing, but the flip side is I haven't come up with a solution that helps it climb, either. There are some more details I have noticed while watching the performance more closely, thus I think the skid-outs and poor climbing might be related. Skid-out steering is less drastic (but still present) when not applying the gas. In fact, I can gain some degree of control when coast-steering. Any amount of steering, however, causes more speed and power loss than it should, but it was not obvious to me at first. Again, it seems to be more noticeable when also giving it gas. Lastly, trying to roll over the tank is really difficult. All of this combined makes me think maybe there's too much grip, but I'm not exactly sure what controls that. I've used latStiffX and dampingRateInAir to control unwanted continuous turning (the original problem), but maybe now one or both of those settings are causing the severe oversteer. Doesn't seem logical in writing, though. I haven't messed with the squat tank yet, so I'll get to its rolling over issue at that time.

Been a while since I did any headgear, but I can try to take a look... no guarantees, though. I'd basically be jogging my own memory as I go. EDIT: I think you need a mesh in your geometry LOD, then component-convex-hull the new mesh. I didn't check your config, but looking at your image, I think this problem has been addressed somewhere. You might not need a model.cfg, since it's a static object, also because you're borrowing the "head" animations from the character, which already has a model.cfg. At least that's how I understood it.

Well it's flat on the ground, no matter what orientation the book is. If you rotate it 45 degrees, it will still slide the same. That's the principle I see happening, but I want to try it book-style on my tank anyway in case there are any other benefits to having a quad/book layout. The cubes will have to all be the same weight, though. The benefit of the diamond shape is that the side cubes could be lighter or heavier than the front and back cubes, and that the front and back cubes could even be a little different mass from each other.

Good idea! I will keep tweaking that gearbox slightly. I'll have another look at my mass cubes. From a top-down view, perhaps I'll arrange them in a rectangle instead of a diamond, and then lower them near the tread base.

The replies you guys give are great! Even if someone suggests something that doesn't work or has already been tried, it's so nice to have responses because they motivate me to carry on. When no one replies it can be a little discouraging, and then I start hearing that Genesis song in my head, "No Reply at All." So, a hearty "Thank you!" to you guys imparting your experience on guys like me, and thanks to others who keep motivating us by just contributing to the conversations. There may be a general lack of interest for my mods, but at least you guys don't disparage me from trying to accomplish my goals. @x3kj: I did notice RHS' values seem to be significantly down-scaled compared to the BIS sample tank, if that's what you mean. I pushed the numbers of the gearbox tighter at low gears and wider at high gears, which allows better acceleration. Very helpful! Of the two tanks I'm working on simultaneously, one is tall and the other is squat (the previously mentioned, modified RDF/LT). Taking on two at a time might seem more challenging, but will hopefully give me a better understanding for my future tracked vehicle projects. After some hours of minuscule, tedious value tampering, I managed to get them to not radically fly off most of the time. Although, they both sometimes hesitate when turning, and then suddenly leap a little as if released from a snag. Initial testing in the Virtual Garage shows they can neutral steer, accelerate, turn, and stop with much better control, and adequately within the response time I want for them. They still have some individual issues to overcome: Tall Tank (fictional High Speed Sentry tank) It has 10 wheels and a mass of 20,000 kg. Top speed is 91 kph in Virtual Garage. It will easily spin out and stop when turning at speeds of 20 kph or more, but it's hard to roll over on flat ground. Testing on a terrain map (I tried Stratis and Tanoa) shows that the spin-out effect seems greater going downhill, and it makes cruising down a curvy path very difficult with WASD keys. It is sluggish going uphill, but maybe that's just expected for heavy vehicles. Squat Tank (modified RDF/LT) It has 12 wheels and a mass of 18,500 kg. It is much easier to control on curvy paths. Top speed is about 72 kph. However, instead of spinning out it rolls over while turning near its top speeds or in sharp turns on downhill paths. Ok... that seems fair, as I imagine that could happen IRL, and even some of the RHS tanks do that. It's just a little weird-looking when my squat tank rolls while my tall tank doesn't. Squat tank is also very sluggish going uphill.

Roger that, but the M2A2 is the Bradley. In the RHS line-up I think the mass of the M113, at about 13,000 kg, is the closest to an original RDF/LT, which is 14,800 kg. Although the one I'm doing is fictional, I want it to be believable, and I imagine an up-armored RDF/LT to be approximately in the range of 17,000 to 22,000 kg. I'm not familiar with many other mods to be inspired from, but if you have any suggestions then I'm all ears. Side note: In doing research on real life helis and their payload capacity, few could potentially carry an up-armored RDF/LT. Fortunately, I am also working on a fictional upgrade to the CH53E, which is one of those few that might do it. Although it lists a payload of about 14,000 kg, it also boasts is can carry an M115, its crew, and its ammunition. I estimate that to be about 20,000 kg with 14 men and 14 rounds, based on the M115 specs at wikipedia.org. Therefore, a 20,000 kg tank and three crewmen should be feasible, right?

Thank you for the reply, but I'm not sure how much to adjust since those settings have such different value ranges. Looking at the the Tank Guidelines gives a small hint, but I am having troubles figuring out the rest. I borrowed the tankX settings for RHS's M2A2 and got it to work for my tank, but in doing so I had to increase my tank's mass. It's supposed to be a light tank based on the RDF/LT platform, so it needs to maintain a low mass for sling-ability. That's half the point of me doing this tank. Also, after testing the borrowed "working" settings, I now find that sometimes it pauses while attempting to do neutral steer, and then suddenly jumps out in an uncontrollable flying spin. Incidentally, it also does that with the M2A2, but since I haven't played with the M2A2 much I am only just now finding that out. I wonder if RHS are aware of this. In both vehicles this weirdness happens only about 1 out of 6 times. So basically, messing with the MOI, sprung mass (not so much), and dampingRateInAir have proven to affect its stability. However: fixing the spin makes it stuck; fixing the stuck makes it fly off ballistic. Fixing the flying off makes it spin forever, and I'm back to the original problem. I avoid messing with the sprungMass too much because the math in the Tank Guidelines suggests sprungMass = mass/12 (the number of wheels it has), then tweak a little.

I personally have a tank with 8 links in the texture. I use a value tracksspeed = 1.5, and it doesn't have a visible skip. <THEORY> You can use non-integers, as long as your textures and values meet some criteria: A: The number of links in your texture compensate for the decimal. E.G.: If you have 4 links, you can use multiples of 0.25, provided that... B: Each link is not unique. Continuing the example above, if you have 4 very different looking links, then you are better off sticking to integers. If your texture has 4 links with two distinctly marked/scarred links and a repeat for the other two, then you will be able to get away with using multiples of 0.5. Caveat is if the distinction is there, but not noticeable when they're in motion, then you can probably use 0.25. C: Other examples would be: 3 non-distinct links: x0.33333 6 non-distinct links: x0.16667 6 links with 2 unique links cloned twice (2 by 3 pattern: x0.33333 6 links with 3 links cloned once (3 by 2 pattern): x0.5 ...you get the idea. </THEORY> Each link in my 8-link texture is a little different, but it's so minuscule that it might work with a number like 1.125 (or any multiple of 1/8) for tracksspeed, according to the theory. Even in slow motion, the skip would go practically unnoticed.

I everyone! I was hoping to find some help from the community. I'm having trouble with tracked vehicles, and the first problem is with the land contact. I'm not convinced it has anything to do with the LOD landcontact, since that seems pretty straight forward. There's a pic of the problem in my dA gallery: Well, that was supposed to be just a hyperlink, but it just displays the photo I wanted to show anyway. Tank 1 has different sized wheels. However, it's all just an illusion, because I set up the memory points on all wheels the same size as the 3 covered wheels' center and bounds. Mass is also weird, because it's supposed to be a total of 10kg for the components, and 4 weight boxes evenly distributed for actual mass. That's how the sample tank is done. The 3 wheels and drive wheels move, but the front and back wheels do not, as expected for what I did (btw, is there a better way given that same-size wheels are not an option?). The tracks move, and even an AI soldier can drive it, somewhat. IT stays in that position while moving. EDIT 1: I forgot to mention that all the wheels on this tank, except the front two, are dampened all the way up even though they don't touch the ground. When testing in buldozer, they rise and drop together. Tank 2 is about 10 cm off the ground. I placed my character in prone on the far side to sort of make it more clear. The wheels do not move in Eden (although they do in buldozer). The tracks also don't "move" or damper. The tank is driveable; though it is too slow, turns too tightly, and stutters about every 3 meters as if tapping the brakes. Same size wheels are not a problem with this tank, but none of them move. Weird. EDIT 2: This tank also has a similar mass set up as the sample tank, where 4 mass boxes distribute the weight. It seemed less important to mention that here, but I reconsidered. Ok so... I know I'm gonna need to post more pics or screenshots of the LODs in OB, or maybe paste sections of my config and model documents. For the sake of retaining some secrecy on my project and also not posting unnecessary pics on the servers, I want to limit what I post to only what is needed. So, where shall we start? Any help is much appreciated!!

They're still not moving correctly, but at least both tanks are flat on the ground, now. On Tank 1 it turns out to have been a mislabeled tank wheel: "kolo" was used where it should have been "kol" in a few places. This was necessary to make the larger wheels still roll, giving the impression they're active. On Tank 2 it turned out to be too little mass for the suspension settings in the physX portion of the config.cpp. Wheels and treads weren't moving because I had fat-fingered its name in the model.cfg file, thus it was trying to refer to a different model than what the p3d is named. It's good that the problem is partially solved; it just took going over it a fourth and fifth time before I caught these errors. Now at least maybe the answer lies more in someone's wheelhouse? So, what remains of the initial problem? Well, on both tanks the movement is very slow, and turning while going forward stops forward movement rather than blending with it. On a simple forward direction, Tank 2 jerks as if tapping the brakes about every 2m. Its turning is too strong, and it doesn't stop turning once my finger releases the key. In fact, after I attempt to correct the oversteer by turning the other way, it will resume the original turn direction. Probably not relevant, but suspension/dampening is using the "Basic_Damper_Destruct_Axis" technique prescribed in the sample tank. I had to rotate the two points on X by 180 degrees to get the suspension moving in the correct direction. Although it solves movement for individual springs, it does nothing for the overall performance of the tanks (i.e.: there's still a jerky motion and hypersensitive steering). I'm still looking into it, but have not found anything helpful. EDIT: I forgot to mention that getting re-acquainted with the tanks config guidelines and cars config guidelines, while informative, was ultimately unable to help me figure out the jerkiness. Also forgot to mention that tanks are leaning forward a little, but this time the tracks stay on the ground. The leaning forward effect is even worse when they are driving forward.

I'm making some vehicles from works of military fiction. Many of these vehicles challenge conventional design, but most are based on real-life vehicles or real prototypes. As a vital part of the line-up, I have a tracked vehicle with glass windows for the driver, and differently sized wheels along the track. Although the models I make are my interpretations of semi-fictional vehicles, there are some things that would look too far modified if I homogenized them. After reading all day about the limitations of tank configs I am beginning to look for alternatives to using the them, especially if a reasonable option would yield even slightly better results. Here are some known issues with Arma tanks that I am trying to find a solution for: 1. Drivers and crew are hidden and effectively untouchable unless they turn out. 2. Different wheel sizes don't work very well. 3. Wheels must be in-line. This doesn't limit us from having quad tracks or more, but it does limit the tracks from being staggered (e.g.: Halo's Scorpion tank). So as an alternative, how about using a car rig for specialized tracked vehicles; will it work? Is it possible to make a car turn on the spot, as many tanks can? Can a car achieve a reasonable amount of traction and climb-ability comparable to a tank? Can a car be fitted with the same amount of armor and hit points? Can a car-rigged tank retain its model mass and still move like it should? Can it have tracks (I have heard of half-track mods, but I haven't tested them out)? Can the tracks and wheels on each side be out of line? I know that car drivers and crew are not hidden unless the author specifies it, but will it support turning in/out? For anyone struggling with uncommon vehicles (e.g.: sci-fi or mil-fi tanks, cranes, real world prototypes, etc.), if most of these are possible with cars, then ArmA 3 tank modification might redeem itself in their eyes - possibly. P.S.: I'm not working on a Halo vehicle mod, in case anyone was wondering, but the Scorpion tank is well known and fits the example.

Some of these features have already been stated, but I'm putting in my votes for adding them (not in any order of precedence): Interiors. Add for vanilla tanks/armor, and support for mod tanks' interiors. This includes future thinking in case the world lighting system is ever improved, becoming advanced enough to change interior ambiance (in anything - vehicle, building...) when the doors are closed and block out significant amounts of light (the sun). Support for independent tracks on same side, and track steering. The trend to replace offroad tires for a set of quad tracks is ever increasing, and I'll bet it will be more prevalent in 2035. Although it's more of a snow configuration, it might offer some variety to a future that looks even less distant than its supposed 18 years away from the time of this post. The support could also be used for all those Halo-type mods wishing to include a Scorpion-type tank, but I dare say these are just some examples of how it would be useful, and seemingly simple to do. At this point, not having support for this just seems like a possible lack of foresight from 2001. I didn't see if there was a post for this, but how about support for dual-stick controls behaving just like tank controls - where each stick operates a track independently? If a player has such a controller (e.g.: F310, Xbox, etc.), then that option could be very helpful. Perhaps enabling that option could change how the keyboard moves the tank as well, for those who prefer sticking with KB. While we're taking feedback on tanks, this might be an excellent opportunity to improve some basic ground vehicle stuff as well, to maybe lay down a better foundation for this particular DLC. In other words, the following may not be specific to tanks, but they will add value to tanks. Towing - there are towing mods, but as great as they are, they just feel like a work around. One mod uses tow cables, and another only tows whatever is defined in its mod class or whatever. What I'm talking about however, is tactical relocation of mission critical assets - when using a helicopter is too dangerous or one simply isn't available. It could add value to convoy missions, and make setting up strongholds a little more fluid. Imagine being able to tow a VADS or a HAWK trailer to add much needed defense against air strikes. Imagine being able to deliver valuable supplies, communications trailer, or portable FOB to your troops. Now imagine being the opposition and trying to prevent these movements. Suspension - I know this is a big one, and I apologize if it brings up any heat. I just ask for a little improvement for suspension visualization. Perhaps a simple skeleton for vehicles, using a mix of low-level IK (if that exists) with the current vertex selection assignment method. Offroad vehicles and possible future vehicle designs would be much more believable. The way I see it, if a driver's hand from an outside model can follow the steering wheel or a gun grip and affect the elbow and shoulders, then why can't a bouncing damper affect the rotation of wishbone suspension arms on the same model? The answer is there is not a skeleton in the vehicle when maybe there ought to be. Maybe the suspension parts can be proxy'd on to the main model; it could contain a skeleton, just as the driver is proxy'd and contains a skeleton. That's one way, I suppose. Support for Driver turrets - mentioning this one could possibly put my very life at risk. In this game, where lone-wolfing is discouraged, it is a hallmark of good game play design to disallow a tank driver from operating its main gun, and I say kudos to that! However, to make it so dang hard for mod'ers to include driver turrets in their own creations is frustrating. Plenty of real-life vehicles have utilized this function, but not just in the form of delivering rounds to your enemies. For example, a police car with a driver search light would require some form of driver-turret. Operating a crane could also benefit from this ability. In helicopters, using a special helmet to aim the gun, cameras, and sensors could better mimic how real-life gunships can be used by pilots. It has been stated that this game is primarily an infantry-focused game. The infantry will always be the bread-and-butter, but having believable support for them is paramount. When something works well it doesn't get the notice it deserves, but when it doesn't work quite like it should it risks becoming an eyesore - a distraction. It's not like I'm suggesting support for individual links on tracked vehicles --or perform detailed maintenance on them, like removing and rebuilding the engine. The simple considerations above will greatly help the game and DLC that BIS are providing. They will also make modding quite a bit easier and/or more polished, which in turn will add to the longevity of the game. Now that I've shared my thoughts, it might be helpful to know what BIS are willing to do, so that we can give them more productive feedback. So with great respect I say: BIS, help us to help you. :-) Whatever you do, just think about the future of the game, and I'm sure all will come out fine. ScotG

I have a plane, which is currently in need of a couple of parameter adjustments, but I'm not sure what to do. 1) The size of the plane is very small, as it's based on a BD5J. To fit the pilot in, he must be reclining back significantly, but this puts his default head position more upward. I once ran across a parameter that sets his initial viewing angle, despite his sitting angle, but I cannot seem to locate it now that I need it. If anyone knows, please LMK as well. 2) I have some user-defined animations that started off as a model/OB-specific problem, but now it's down to the scripting. Just like an F/A-18, this plane has wings that fold up. I've got the animation sequence appearing in the action menu in game, but when I try it nothing happens. Here are the pertinent script sections: model.cfg: class Leftwing: Rotation { type = "rotation"; source="wingsFold"; selection="wingL"; axis="wingL_axis"; minValue=0; maxValue=4; angle0=-1.571;// i.e.: 90 deg angle1=0; animPeriod = 0.0; initPhase = 0.0; // memory = true;//(default assumed) }; class Rightwing: Rotation { type = "rotation"; source="wingsFold"; selection="wingR"; axis="wingR_axis"; minValue=0; maxValue=4; angle0=-1.571;// i.e.: -90 deg angle1=0; animPeriod = 0.0; initPhase = 0.0; // memory = true;//(default assumed) }; config.cpp: class AnimationSources: AnimationSources { class wingsFold { source = "user"; animPeriod = 1; initPhase = 0; }; class AddScreen1 { source = "user"; animPeriod = 1e-006; initPhase = 0; }; class HitGlass1 { source = "Hit"; hitpoint = "HitGlass1"; raw = 1; }; class HitGlass2: HitGlass1 { hitpoint = "HitGlass2"; }; }; class UserActions { class Wings_Fold { displayName = "Tuck Wings"; textToolTip = ""; shortcut = ""; priority = 2.0; position = ""; radius = 2; showWindow = 0; onlyForPlayer = 1; condition = "(this animationPhase 'wingsFold' < 0.5) AND (alive this)"; statement = "this animate ['wingsFold', 1]"; }; class Wings_UnFold : Wings_Fold { displayName = "Extend Wings"; condition = "(this animationPhase 'wingsFold' > 0.5) AND (alive this)"; statement = "this animate ['wingsFold', 0];"; }; }; Notice angle0 has a 90 degree value whereas angle1 has 0 degrees (or unchanged). In my mind I was thinking this would spawn the airplane with folded wings, and only once you activate the user command would they extend down into default, unfolded, flyable position. It does spawn as such, but the menu option is "tuck wings" instead of "extend wings." Selecting the option does nothing, and the displayName remains at "tuck wings."

For landing gear animations, is that something that needs to be keyframed in OB, or would one simply set parameters in the model.cfg (e.g.: wheel parameters, turret range)?

Ah. Ok, I'm slowly grasping this. So just to clarify, are you saying as long as I define the source in config.cpp -> AnimationSources, for all pertaining objects, the same as whatever I named it in the model.cfg, then I am not confined to the term "user?" So e.g.: model.cfg: class Leftwing: Rotation { type = "rotation"; source="UK_Apollo_Rocks"; selection="wingL"; axis="wingL_axis"; minValue=0; maxValue=4; angle0=0; angle1=1.571;// i.e.: 90 deg animPeriod = 0.0; initPhase = 0.0; // memory = true;//(default assumed) }; class Rightwing: Rotation { type = "rotation"; source="UK_Apollo_Rocks"; selection="wingR"; axis="wingR_axis"; minValue=0; maxValue=4; angle0=0; angle1=-1.571;// i.e.: 90 deg animPeriod = 0.0; initPhase = 0.0; // memory = true;//(default assumed) }; ...paired with config.cpp: class AnimationSources : AnimationSources { class UK_Apollo_Rocks { source = "user"; animPeriod = 1; initPhase = 0; }; }; class UserActions { class da12thMonkey_RocksToo { displayName = "Tuck Wings"; textToolTip = ""; shortcut = ""; priority = 2.0; position = ""; radius = 2; showWindow = 0; onlyForPlayer = 1; condition = "(this animationPhase 'UK_Apollo_Rocks' < 0.5) AND (alive this)"; statement = "this animate ['UK_Apollo_Rocks', 1]"; }; class Wings_UnFold : da12thMonkey_RocksToo { displayName = "Extend Wings"; condition = "(this animationPhase 'UK_Apollo_Rocks' > 0.5) AND (alive this)"; statement = "this animate ['UK_Apollo_Rocks', 0]"; }; }; That right? Edit: Ermm, I've included the class useractions:useractions within my plane's main class (where all its pertinents are assigned values), but I get an error report that says it's an undefined base class. I guess I assumed it was defined at a lower level, but what should I do now to get it working? Edit 2: Fixed: I missed the "userActions" after the colon, which was apparently not necessary, so I fixed it in my code. I've also edited the code above to more represent how I've structured these sections of the actual code for my plane, but added props to da12thMonkey and UK_Apollo. :-)