scotg

@Donnie_Plays Yeah, you can fairly imitate GI Joe characters with some vanilla A3 assets. Snake Eyes and Beachhead just need the balaclava and some chest gear, but give SE some goggles. Plop a beret on a dark skin soldier's head, and you've got Stalker. Put some aviator sunglasses on a helicopter pilot with his helmet, and it's how Wild Bill should be dressed for flight. Many other combinations can create some decent stand-ins for other Joes and Cobras as well.

I have a PBO that works in pboProject, but for <reasons> I have to use Addon Builder. I uninstalled A3 Tools, and then reinstalled. Buldozer works, P: drive is set up, and mod even packs with "success" notification. When I start the game there is a puzzle icon for my mod having loaded, but when I look for my vehicle in the Virtual Garage or 3den, it's not there - not even a mention of it. Model and textures are displaying well in Buldozer. I am not sure if I missed a step for installing the tools, or if I needed to uninstall one or all of Mikero's tools first... or something along those lines. I was just hoping to find some common causes of this type of problem.

...Except that they did not. It's too far in the past for me to remember correctly the how's and why's. It was a long, convoluted ordeal just to get back to having compile functionality after trying to rely on mikero's free tools. I didn't understand their limitations, and the documentation that came with them was misleading. My conundrum was that the docs related to RTMs are only available in the subscriber tools, if I understand that correctly. There was nothing in the free tools docs, which mikero said shouldn't exist, explaining how to pack RTMs. I kind of felt like monkey in the middle. The long-to-short is: I could compile with AB before. I wanted to re-structure my mod folders and have P:\ drive and buldozer working smoothly. I tried to accomplish this while converting to MT (free), but then I couldn't pack RTMs into my mod. I then went back to AB, only using MTfree as a helper. All is well. I moved on, and have had better success with AB, using pboProject only as an error checking tool. RTMs are being packed (except for one unusual case which I haven't been able to look in to). This isn't a bad review of Mikero's tools, it's just an indication of what I can do at this time. I am super-busy with the artwork and promoting of my mod, and for lots of other reasons I don't have time to sift through technical docs right now. Perhaps when the artwork load calms down I can justify getting the subscriber version of MT and put out cleaner, fully inclusive PBOs - and have more time to get better acquainted with the tools.

Ah, ok. It's class wheels in the config.cpp. That I do have. Things are still a bit wonky, so if I start to think I'm missing something it'll haunt me.

This is confusing. @DSabre mentions wheel.cfg a few times throughout his first post, but I am not sure what wheel.cfg is. He has also mentioned it in other threads, if I recall correctly, and he has brought it up with me in private messages. Unless someone else knows what he's referring to, we may not be sure what this is until if/when he gets back into working on airplaneX stuff. It is taxing on one's sanity, especially if they feel like they're doing it alone. Getting this even just close to being right is a thing that really separates the big-team mod developers from individual, talented mod'ers.

You're right. That must have been reyhard's shorthand for arma3diag_x64.exe. Diag.exe doesn't exist even in dev branch mode.

Thanks, @Dedmen. So the |#| indicates where the semicolon goes? I did try putting it ahead of the file path, too. It did something. It didn't do anything right, but it did something.

So now I'm trying to figure out how to use the diag_mergeConfigFile command. I did what @reyhard and @TeTeT said, esp. reyhard's advice about keeping a copy of the .exe before switching back to stable. Based on the example here: https://community.bistudio.com/wiki/diag_mergeConfigFile, I replaced it with my plane's path: diag_mergeConfigFile ["P:\gijoe\vhx_plane\cobra_firebat\config.cpp"]. Got an error message saying it was missing a ';' so I tried placing it at the end. Nothing. For unknown reason I tried placing it before the path. I would never have thought of that except for that one moment of randomness, but it did something. Started up scenario, and it didn't let me enter the plane. Weird. I didn't delete plane entry point; all I did was bump the spring strength up to to a ridiculous number, for the sake of testing the config merge. I'm guessing the missing ';' wasn't supposed to be where I put it, after all. For grits and shins, I shut down game and compiled with pboProject, but noisy output just gave me missing sound file warnings (i.e.: for sure no missing ';' in the config). I think you guys are right about this saving me loads of time; I just need to figure it out first.

Forgive me for the double post, but I wanted to distinguish these next thoughts from the previous one. Since that post was a little in-depth, I didn't want this to get glossed over. 1.) Let me impart some wisdom to you guys about case sensitivity. It was a major source of my problems which led to a bunch of unnecessary anguish and repeated trials. Even if you read an official statement somewhere claiming that a parameter is case insensitive, forget that noise and just stick to your principles. Always practice case sensitivity, and hunt down and assimilate rogue letters if you are pasting from someone else's script. For me, it was a 'w' where I needed a 'W' for Wheel_*. The W is sneaky for me, especially in the Courier-esque fonts that Notepad++ uses. 2.) This one is really more of a question, but first a brief outline of my trial and error process: Start up A3, play-test, observe, shut down A3 Make changes to config.cpp, model.cfg, and/or [model].p3d Compile in Addon Builder. If it fails without good explanation, compile in pboProject (free version) for better output. On successful compile in AB (needed for including .rtm files), move on. Repeat process It can be quite time-consuming, especially with all the load times. I feel like there should be a way to make changes in Eden to save time, and then use that data to make the changes permanent in the config (where most of the alterations take place). This would save time from all the load screens, not to mention how it would cut down on all the anguish over waiting, anticipating, and lingering disappointment accumulated between changes and results. I ran across this page: https://community.bistudio.com/wiki/Mission_Editor:_Debug_Console_(Arma_3). It seems to cover more about configuring for servers, but it does say changes can be made on the fly. It just doesn't specify what kind of changes - changes to an .sqf, .cpp, .cfg, or what? It seems to also be a fairly new feature, in the scheme of things. My question is: Has anyone used Eden's Debug Console to do fast edits to their config.cpp settings? Can it be done? Edit: This question, though maybe not presented in the most efficient thread, is super important to anyone who has spent time tweaking airplane suspension. Thus, this is a good place for it.

Kind of on a side note, but I think it's very relevant: None of your visible geometry have to have the same names as your virtual components. I found this useful when aligning the dampers/pistons and their stabilizers, the little elbows that keep the gears from turning out of position. Instead of using a translation animation approach in the model.cfg animations, use a rotation for your damper part - just like you would for those elbows. In the skeleton section make the damper a child of the lower stabilizer elbow. "damper_guide" ,"", //To provide something to inherit in animations. Might be redundant. "gear_1" ,"", // The front gear mast, which lowers for landing. Connected to the root "gear_1_2" ,"gear_1", // The first arm of the elbow, connected to the gear mast "gear_1_3" ,"gear_1_2", // The second gear arm, its axis is the elbow joint. Connected to first arm "gear_1_damper" ,"gear_1_3", //* The piston that goes in to and out of the gear mast. Connected to 2nd gear arm "gear_1_caster" ,"gear_1_damper", //* Don't forget the steering on the front wheel.Connected to the piston. "visWheel_1" ,"gear_1_caster", //* The visible wheel; turns at virtual wheel's rate. Connected last. // Steering can go before or after the three parts of the elbow assembly, but never within. //* These have corresponding virtual components, and for this set up should be named differently. If your elbow parts are the same length, rotate the first elbow and the damper the same radian value, and rotate the middle (where it actually looks like an elbow) the negative of twice that amount. The goal is to nullify the difference. The piston will stay in its sleeve, and the joints will all stay "connected." class damper_guide_move ///again: this class might be redundant... { type="translation"; source="Damper_1_source"; selection="damper_guide"; axis="basic_damper_destruct_axis"; //This is in a lot of vanilla vehicles // sourceAddress = clamp;// (default) ///these are in here, but why? minValue = 0.0; maxValue = 1; offset0 = 1; offset1 = -1; animPeriod = 0.0; initPhase = 0.0; // memory = true;//(default assumed) }; class gear_1_stabil_1_rot: damper_guide_move ///...but we'll inherit from it anyway { type="rotation"; source="Damper_1_source";///if inheriting from damper_guide_move, this might be redundant selection="gear_1_2"; axis="gear_1_2_axis"; minValue = 0.0; ///redundant maxValue = 1; ///redundant angle0 = -0.0; angle1 = 1.0472;//rad 60; //Use also for Damper rotation when both elbow sections are equidistant. animPeriod = 0.0; ///redundant initPhase = 0.0; ///redundant // memory = true;//(default assumed) }; class gear_1_stabil_2_rot: gear_1_stabil_1_rot { selection="gear_1_3"; axis="gear_1_3_axis"; angle0 = 0.0; angle1 = -2.0944;//rad -120.0; //nullifies sum of angle changes for gear_1_2 and gear_1_damper }; class gear_1_damper_rot: gear_1_stabil_1_rot //inherits most of gear_1_2 values { selection="gear_1_damper"; axis="gear_1_damper_axis"; }; It can still be done for landing gear stabilizers of different lengths, but it would require a little more math, knowing the lengths of the arms in the elbow, and thus knowing the initial and terminal angles. I believe the elbow angle should still be the negative of the sum of the other two angles. An example of this setup is in the A-10's Main Gear (rear). Despite the focus, the difference is clear here, too. What I did for my A-10 was I measured the angles in 3DSMax, at both extremes. I don't have actual specs on A-10 suspension stabilizer lengths, so I could fudge with it a little. Just make sure your angles add up to 180 in each position/phase, since it's technically a triangle. EDIT: After going back to look at my model rig, I remembered that the A-10 main suspension wasn't as simple as this. I had to set up an IK Arm Solver in 3DSMax, keyframe the damper going between its motion range extremes, and jot down the angles at both extremes. The problem arises with this one because the 2 axes of the elbow closest to the piston are not parallel to the piston. There probably is a mathematical way to sort it out, but it in this case it was easier for me to have the beginning and ending angles and then plug that data into the model.cfg. If you are having problems with a piece rotating the wrong way, then you can either A) try using the negative of whatever value you used, or keep the value but instead B) scale the axis to -1,1,1 in Object Builder MemLOD (if it's not on the X coordinate then use -1,-1,-1). I think I covered everything about this. The result should be a nice, connected, fluid motion on the suspension parts when dampering, whereas before it was misaligned or broken.

Another technical question here. Most user/custom animations are dependent on a key press or scroll menu selection, and then the full animation is carried out. What I want to know is how (if possible) to make the animation happen only while a key is being pressed. When the player releases the key, the animation pauses. It would also be helpful to disable it from appearing in the scroll menu, since holding a selection in the scroll menu might be impractical. EDIT: I should also mention that when the animation is paused from key release, the animated part (named selection) should remain where it is and be able to go in reverse with another key press. Practical example: Say there's a sliding missile rack on a helicopter, going between left and right in both directions. I want to use Num4 and Num6 for left and right input (I may want to try other keys or controls if these are too cumbersome). I want to have the ability to interrupt the missile rack moving left and go right (and vice versa) on a whim if necessary, and movement should cease if there is no key press at all. I hope that's more clear. If anyone knows how to do this, please show me! Also, is there a list of UserActions>Conditions and Statement keywords? I'm no programmer, but it looks like condition is the "IF" part of an if/then and statement is the "THEN." I know some phrases like this, animatePhase, >, <, and say3D, but there must be a list of more terms. That's probably a huge list, I realize. Anyway, I'm still digging around through the links for bits, pieces, clues. If I can familiarize myself with all this, then I won't have to dig around and beg for help so much! LOL

I'm always speaking from a mod perspective, so... Was the neutral steer rate ever updated? Specifically, is there a setting to determine how fast a vehicle can turn in place, or disable it entirely? I'm thinking this might be the first step to making better half-tracks.

I've been running into some problems with configs lately. I tried to get my Hellwing (aka Firebat) running more smoothly. It seemed like a simple task, but I cannot get over some big hurdles at the moment. Check out this post for the latest on that: Meanwhile, here's some information about another vehicle I'm kind of stuck on (pics at the link): https://www.patreon.com/posts/20933363

After some adjustments and some trial and error, it's still having issues. It's a little better than it was, but there are still a lot of problems to work through. This video explains and demos my issues better: Here's the updated config.cpp: And here's the model.cfg: As always, any help is much appreciated!

There seems to be some confusion over the terms "rim" and "boundary," and the two are inaccurately used interchangeably. I noticed in @firewill's figure 5 that he has the wheel_1_rim set to the part where the metal meets the rubber - the rim of the literal wheel as if without a tire. This is the common understanding of the term "rim," however in the sample plane supplied by BIS they put the wheel_1_rim, wheel_2_rim, and wheel_3_rim on the very edges of the tires. As I am testing it, the inaccurate name position also seems to work better so far.

@Sgt.Makarov, @RicHornet I actually tried looking through that mod by Nodunit and Franze. It's even more intense than the RHS AH64 because you can interact with its dash menus, and you have to go through a series of switches to enable pilot control of the M230. Looking through the code was a nightmare, and the RHS code is equally scary (in a good way - it's advanced stuff way over my head). Most GI Joe-Arma crossover fans aren't going to want to mess with all the real-sim functions. I want the visual immersion, but less complicated to use. It's an elusive sweetspot, and alas I know my hopes are super lofty.

I am a modeler. I can do this, but I need some configs for my own vehicles and gear. I would be willing to trade services if you are a talented config.cpp and *.sqf writer.

I get it, and let me say this is truly astounding what the RHS guys have done! I just want to point out that the documentation on the RHS site does imply that the pilot can control the M230. Further down it also says the Apaches are a work in progress overall, but doesn't specify what doesn't work.

I agree, but what is it really if it doesn't slave the M230? All I see is that it makes a monocle overlay with night vision capabilities. That's cool, yeah, but you can't exactly call it IHADSS just based on that.

I came here looking to see if, in Arma 3, the pilot can control the aiming and firing of the main turret and main gun. In the case of the RHS Apaches it's the M230. I need something like this for this helicopter: As you can see, it's a one-man job with a mg turret up front. I know it's not as realistic as the AH64s, but I've put some research into it to make it plausible. It's at least game-plausible, and it's way more realistic than its toy counterpart ever was. I've been playing the RHS:USF mod trying to figure out how to get the IHADSS system to work, but so far no dice. Any help on getting the pilot turret to work in-game would be nice, and help getting a simplified version of it on the FANG would be AMAZING! (I can dream.)

Hey all. I have a helmet that comes into the wearer's view just barely, so I've put it into the view_pilot LOD. Unfortunately, the ambient soldier animations make this impractical, and half the time he's checking for gum on his boot. The helmet in view_pilot consequently obscures all visibility while the character's head is down. I'm trying not to go into an NCO tirade of how wriggly the soldier and his head are -- no military bearing whatsoever! Instead, I was wondering what the name of the player camera view is, so I can name or attach the view_pilot helmet to that. The camera is a lot less affected by these animations. An answer would also help with future models since I intend to make visors, sunglasses, and other head attachments that will come into view. Of course, the best option would be for BI to have made the ambient animations much, much more subtle, and to attach the player view point at a better place on the head. This would solve so many other problems (like looking down and not seeing where my neck should be, better sight alignment, proper visibility in vehicles, etc).

Perhaps he's building an ATM that spits out cash. I think what @Dedmen is trying to say, maybe not in the best way, is that you need to elaborate in order for us to understand your problem. If you can get past the inherent snarkiness, he has quite helpfully parted out all the ambiguous portions of your post, so you can help us help you. In OP's defense, the terminology can be quite elusive to newbies.

Is there a way to automatically return a tank's turret rotation to its starting position, 0, initial stage of animation, or what ever it's called? Specifically, I want this to happen when the commander-gunner turns out.

@jandrews Thanks! I hope I can release it sooner, too. I really hope to get in contact with some talented script editors who can put some polish on how these things operate - their configs. As an artist it takes me significantly longer to switch over to config mode and try to make things work.

We're about overdue for some pics. Here are some new ones: Warhawk (via Splendid Cam) Diamondback VTOL (Splendid Cam). Can your A-10 do this? Group of Vehicles Vehicles Featured in Videos Skorpion/LM002 Comparison Puma vs. Skorpion