AlexVestin

It does have some benifits. If you want to move a bit slower, and be able to see more on the screen, combat-pace is viable. It's what it's for if you're after that little bit slower pacing moving into an area. Hip-firing is also a bit faster in the heat of the moment if combat-pace is toggled on. It's all optional, wich is good.

I'll just try to keep it short and start of with why I think combat-pace is flawed and can be improved. For those who do not know what I am talking about; combat-pace is the mode that can be toggled that makes you character run with his rifle raised and aimed down range. Now, there are some things about it that make it seem broken/buggy. Best examples I have is: Walking with no weapon, toggling combat-pace to ON will lock you in walking mode, no matter if you try to toggle run/walk in any way. There's no way of letting the player know if combat-pace is ON/OFF visually on the character, except for running with a rifle. The system is intentionally or not, set up to give the player a second mode of moving, wich lacks several animations to be complete. No visual clues if it's ON/OFF. Icons are not the right way to go since even more extra hud clutter is often not what players want. Here's a picture showing exactly what I am talking about. First row, GREEN, ArmA3 default animations with combat-pace toggled OFF. Second row, YELLOW, ArmA3 default animations with combat-pace toggled ON. Click this link for larger image: https://image.ibb.co/nnAHyb/animation_sets_and_fixes_DEFAULT.jpg Here's a picture showing suggested fixes, changes and animation stances that would complete the combat-pace mode. First row, ORANGE, suggested fixes/changes for animations with combat-pace toggled OFF. Second row, RED, suggested fixes/changes for animations with combat-pace toggled ON. Click this link for larger image: https://image.ibb.co/ePeGrw/animation_sets_and_fixes_FIXED.jpg Open the two pictures and compare them next to eachother, and the changes will be more obvious. Basically, what has to be done in these pictures is to have the animation on the first row have a different animation for the row below in combat-pace. Thereby making combat-pace visually enabled for all standing poses. There are of course similar fixes that can be made to animations for pistols and launchers, also standing and crouching, for this to be a complete functioning combat-pace mode. I chose to just show this for the rifle animations since those are most used. The animation for walking with a rifle lowered already has different versions of animations tested. The one I added for walking with a rifle lowered and combat-pace enabled is already available in the A3 files. Would BI themselfs consider this worth fixing for the time it'd take? It's for the main movement system for ALL characters after all, and would just improve and add depth to the overall movement for everyone. This would need some careful testing, and probably make the idle animation for standing with a rifle raised use the equivalent animation for combat-pace ON whenever you try to shoot or aim down sights. If implemented right, watching players aim down sights are also going to be more visually displayed on their character. I'd really like to hear some thoughts on this, or just some general discussion, since I feel this have been a problem for a few years now and it does not seem to get any changes to remove the clunkyness. I have not stayed around the forum, so I am not aware of any already given answers. TLDR; Combat-pace is missing visual clues and animations to be a complete mode of moving.

MB is quite easy to learn and easy to use once you get the hang of it. Picture of my recent tests with MB. http://cloud-4.steamusercontent.com/ugc/536267850680003938/7A37C13F5B792082ACDA09237697DB7F6DABCFA3/ Everything is WIP. Terrain still needs to be lowered in the pool.

Thanks! I will try that and some more today and see if I get anywhere. Will probably only do these parts: case "HitFuel": { _maxDamage = 0.9}; case "HitEngine": { _maxDamage = 1}; Did something like this earlier and the helicopter would explode endlessly after taking damage: this addEventHandler ["HandleDamage", {false}]; I did find that script actually, but no matter how well made it is, it's still a very faked crash. There has to be a better alternative with no teleporting etc. Should be doable, as long as there's a working way to set a max cap for the damage able to be made, no matter what kind of round it is that hits the helicopter or the speed it crashes with.

I have looked around but could not find anything after searching for an entire day. I've tried the related scripts I've found, and I've tried testing stuff with eventHandlers. There are some cheap ways helicopter crashes have been faked by scripting, but none I've found have been desirable (or rather realistic). Here's the desired outcome. 1. Helicopter takes damage like normal. 2. Helicopter goes down. 3. Helicopter does not explode on impact. 4. Crew takes damage like normal. I want to test something that sounds like it'd work rather simple, but I do not know exactly how to execute it. It'd kinda work in the order listed below. 1. Helicopter takes damage like normal. If damage goes above 0.9, set it to 0.9 2. Helicopter goes down. Once the damage has gone above 0.9, destroy the engine, main rotor and tail rotor to force it down. (A helicopter with only damage set to 0.9 is still flyable.) 3. Helicopter does not explode on impact. The helicopter would before impact with anything set "this allowDamage false". (Disabling further damage prevents the explosion, but also the rotors from being destroyed when touching objects/ground etc. (Step 2 above must be done before disabling damage.) 4. Crew takes damage like normal Will work just like it does normally. If the helicopter has crew inside of it, they'll still take normal damage on crashing into things. To simplify it even some more: If helicopter damage above 0.9, set it to 0.9, destroy engine, rotor and disallow further damage. I've been trying some stuff and something seems off. Added this to the init of a helicopter: this addEventHandler ["Dammaged", {if ((_this select 2) > 0.1) then {hint "bananas";};}]; I thought this would execute if the helicopter has damage above 0.1 I fired a few round at the helicopter, and surely, the hint with "bananas" showed after doing so. It took 6-7 MX rifle rounds and nothing in the interior of the helicopter showed any kind of damage to the modules. Still as expected. Now. I changed the number. this addEventHandler ["Dammaged", {if ((_this select 2) > 0.9) then {hint "bananas";};}]; I thought this would execute if the helicopter is at 0.9 damage, wich is a lot and should have the helicopter barely flying. The only difference now is that it took about 14-15 rounds for the hint to come up, but the helicopter still showed no sign of damage at all. Then I tried going even higher and doing this: this addEventHandler ["Dammaged", {if ((_this select 2) > 1.0) then {hint "bananas";};}]; Now it all of a sudden took 4-5 magazines fired at the helicopter, with no real damage done, and no hint even came up. I only added +0.1 to the value and the changes were drastic now. /I have no idea what I am doing.

Is this eye specifically related to anything, or is it nothing special? http://www.arma3.com/images/teaser.gif It's a lightning bolt visible in the center of the eye. The circle around it is the "Select" marker. Could be something placeable in the editor.

It sounds awesome that you got it working :) There seems to always be atleast something that does not work in one way or another. Let's hope those things haven't just not revealed themselfs yet. (I admit I confused myself with this last sentence being from a non-english speaking country and all, but you get my point)

Too early in the morning :)

When it comes to landing or taking off? :D

I think groups are a must for whenever there's an update :) Same with the OCP units since I've seen quite many poeple liking the more 2013-2014 looking units. And I am still working to have some more accurate UCP gear that was used by the US Army from around 2009-2010. Pretty much all of the gear comes from Operation Arrowhead infantry created by Johannes and Binkowski, but it's getting heavily tweaked to work with the new unifrom system in A3. Also some minor proportion tweaks to get it just a lil bit more accurate.

We're not talking about a huge increase in size anyhow. Making it be 1.1 in size could be too much. Same for the UH-60s. The C130-J is mainly wierdly proporioned in the interior areas.

To keep it simple, the right railcover will be hidden if a laser is attached. So there won't be any clipping between railcovers and attachments. I've also been experimenting with mounting attachments on the top rail. Flashlights can be mounted on the top rail because of that, but I thinks it's okay anyways, since not all of the M4A1's will make use of the top rail.

These pictures (and links) are great. Thank you! :)

I have the CLU unit as the actual weapon. And that model of the CLU has the tube attached, but it's hidden in-game if no magazine (tube) is loaded onto the CLU. It's intended to work exactly like a rifle model that always have a magazine attached, but hidden in-game if no magazine is loaded into the rifle. My magazine is a model of a "CLU + Tube + Missile" that the weapon switches to when the CLU is loaded with a magazine. It results in me having just a CLU in-game, and loading it will look like it adds a tube with a missile in it. The problem is as follows. After I fire the missile it's supposed to go back to the model of a CLU that had the tube attached (but hidden if no magazine is loaded onto the CLU). But it does not. My CLU never has time to understand that it's loaded with an empty magazine because the game delets my launcher magazine completely from the inventory, leaving me with just a CLU (that hides its attached tube) in my hands once more. Tricky to to explain the process, but I did my best :D ---------- Post added at 21:56 ---------- Previous post was at 21:37 ---------- Some progress! I think it was the "type" of magazine I changed something with. Also made the magazine tube contain 2 missiles (lol), and it did not get deleted from my invetory after firing. I'll update the first post with my configs when I'm through testing these values. ---------- Post added today?? ---------- Previous post was at earlier today??????? ---------- My discoveries are leaning towards launcher magazines containing only 1 missile will be deleted after completion. A magazine containing 2 missiles behaves like any other rifle magazine etc. and will stay empty in the inventory. It is a problem.

Nah, it could very much be. If so, it's related to what slot the ammo uses in the inventory. Launcher ammo slots not being able to have an actual magazine or something like that.