x3kj

New LOD as in a mesh for Shadowvolume View Gunner/View Cargo, or new LOD types (which i guess would require objectbuilder update)? I tried Shadowvolume View Gunner but it didnt work properly when i tried (some time back).

[Marshall] the dirt on the drivers optic reflects in sunlight/ is extremely visible in darker surroundings (tanoa) and way too much. Awesome! How did you make it so that direct sunlight doesnt affect the interior ? Where there any changes or repairs to the gunner/commander shadow LODs ? When i tried them they didnt work properly, but it could have just been my fault. Are there any special rvmat or LOD tricks? It looks a bit like a different env map is used for starters. Human eyes have way higher FOV than your screen could capture. And monitors way too low resolution to allow scanning the distance. This is why infantry in arma have magic eyes with zoom in and out function. Its a game on a monitor, not RL. Its the best representation of view periscopes that is possible under the circumstances, in addition to retaining the old letterbox. Old letterbox is a cheat detached from ingame reality. There is no hull blocking the view and aspectratio doesnt match the real optics. And just because the marshall driver has a shit periscope design that does not allow to look to the side does not eliminate all the other benefits that 3d optics for other vehicles and non-driver positions provide. How about you try the marid? Last pictures shows that the hull is not represented in the driver view (you can see through the optic back into the interior). Claiming that you will see less of the road in front of you is simply untrue if you adjust camera position. Drivers job is to drive and when vehicle is standing to scan the front of the vehicle for threats. But please, if it bothers you so much, just keep using magic letterbox and forced optics on gunner/commander.

About the head animation (shaking) i agree about, it is and has been pretty terrible for a long time. Many vehicle positions suffer from this. Passengers, Pilots, now Tankers as well. It just feels jerky and hyperactive instead of organic. Its like the constant face swipe animation before they patched it -> way overdone. The only reason i dont go insane from this is because i mostly work and play with my own vehicles, with custom animations that dont have the jittering. The thing i dont agree about at all is the view slits beeing useless. Once you bind the keys for camera/head movement (translatory) they are super usefull and way better than letterbox 2D view. Proof desired? Letterbox: 3D View with cam moved forward (closer to the glass) to maximize screenspace: Note the tree on the left. You can also move the cam up+down for viewing the sky/ground. And the cream of the crop is ... zooming in:

Ok i had a looksee now - couple of things: [Gorgon] Secondary dials (ampere, temp, rpm) on gorgon are pretty much unreadable unless zooming directly into them. There is quite a bit of space in their "rings", the markings could be made larger. To also make them more readable, reduce the amount of "minor markers" / the accuracy of those dials - It generally doesnt matter if it's 84 or 86°C oil temperature, as long as it's not anywhere near the critical temperature. [Gorgon] Gunnerposition for the gunner himself seems to be fairly useless - there are no view ports and no display for the guns camera. Only thing he can do is check if he still has a commander or driver. It seems to be only usefull for the commander to glance over to him. [Gorgon] Passenger interior (while where at it) has z-fighting issue on door hinge (to the turret) and fire extinguisher holder. Excaserbated by the frantic and nauseating head movements of the first passengers animation... (Either he is on drugs, had too much coffeine or needs to pee badly) [Marid] Driver Position - pretty good Layout. When you translate the camera a bit forward it would be perfect, but the handle bar above the screen panel blocks the view on the upper part of the speed indicator. [Gorgon & Marshall] Amperementer in a vehicle that has both minus and plus scale seems nonsense to me. Both engine alternator and battery have predefined polarity. Maybe for electrically powered vehicles that recuperate energy and show how much the motor/generator is consuming/generating. Transitioning between turned out state and turned in state leads to flicker, because as soon as turn button is pressed the gunners view mode snaps to the interior view, but the animation and fadeout lags behind. Especially noticeable on Gorgon driver turned out switching back to interior view. Either introduce time delay for switching of LOD (preferably synched to animation/fadeout), or remove the delay in turning in (undesirable imo, and propably ugly for turn in animation). Actually it's hard to tell if there is any fadeout at all, its definitely not as pronounced as for turnin out. [Marshall] has external LOD issue - Possibly empty res LOD? The model dissapears completely at some distance. When turning around near it, it is first invisible and then fades in noticeably. [Marshall] seems to lack the rear of the turret exterior in gunner/com view. The air inlet/outlet to the rear on the turret exterior (or whatever it is) is not seen in the view periscope and you can see through the view periscope into the interior again when translating the head upwards and looking down. [Marshall] has asphalt screeching tire sound when breaking on dirt [All interior positions] I suggest looking over the head movement limits again. When moving your head position maximally in just one or all 3 axis (translation, not rotation) and then rotate the camera i noted that you can see some things you should not be supposed to see. Some unclosed faces or cut panels out of the view ports and sometimes the reverse side of the interior model or sometimes even look through the model entirely (e.g. Marshall Gunner and Commander position looking over left and right shoulder). Also, for drivers, when translating the camera maximum forward and breaking from high speed, the camera can go through the glass from the movement of the "deceleration effect" (noticed on Marid). No i mean exactly what i said. In the view periscope itself. Directly. Or directly below, above or next to the front facing piece. And for exactly the same reason that planes have it since ages, cars already have it (upper class) and likely in 50years when RL military finally caught up tanks as well, if we havent all been replaced by robots by then. The Game's vehicle HUD is shit when you actually need a quick read on speed. I even placed it right in the middle on the top so the distance is smaller for the eyes to jump but its still not well readable at a glance. I needed it alot during tank and airplane config tests. I got so frustrated i built my own indicator models so i can work properly. Also, it's not just the poor position, contrast and size. It's also basic ergonomic facts: A dial indicator is much more readable than a digital number at a glance when you need to only discern much/less , fast/slow. And it's infinitely better when trying to gauge loss/gain of speed. Marshall definitely could need a secondary display like i mentioned, Gorgon would also really benefit from that. Marid has well positioned interface, it doesnt need it. And i'm predicting most existing MBT in A3 will need something like i mentioned due to main console beeing located to the side. Lit up panels do not produce any light to the surrounding. They just glow themself (self illumination quite literally). And this doesnt stop the interior from beeing illuminated by actual light sources (vehicle headlights, street lights, etc). Dynamic light sources (i.e. everything that is not the sun or moon) do not produce shadows in A3 and do not get occluded. This is the issue. They shine through every object. So if you add light in the interior and do not restrict the light sphere to completely end within the vehicle hull, it will shine through the vehicle hull. Lights from other vehicles will have visible reflection inside the interior just as well. It's possible to bake lighting into the texture (via self illuminated textures). It just looks the part, but isnt actual light beeing computed. It could also be a small lightsource but with really sharp falloff. Eitherway, the shadow occlusion/casting of dynamic lights is not solved to my knowledge. I would be the first to celebrate about any positive change/addition to this, cause i have tank interiors myself that need fixing.

It's not in direct line of sight when the front is too sloped and vehicle heigth too low (as usually the case for MBT drivers)->no space. Not because it is very "good" place to put it. Mechanical indicators require additional depth to house all the components. Nowadays it would be very little issue to provide a secondary small display bar above, below or beside the view periscopes that shows digital values of speed/rpm and some other important icons for example (basically repeating the primary instruments). Modern displays are extremely flat, and with all the info beeing usually available digitally , it would be no problem adding smaller displays as secondary "quickinfo" and connect it via cable with the main unit. Making the multifunction displays more ergonomical (for example rotating them 35° more towards the player ) would also help. If this is the future, why no HUD for one periscope in the array? Car makers are experimenting with it for a long time already (not sure if and what cars have one - not my price class). IRL secondary speed info would not be so important, because when you drive the vehicles tactically you have no need to watch your speed not go above a speed limit. You will feel it yourself if you go too fast (alternatively your comrades in the turret might complain...), because you sense it through vibrations/bumps/sound. As PC player you lack those senses and the feel of speed is very bad if you dont have the indicators showing you all the time. This is why virtual drivers need "training wheels" (like the ridiculous stabilizer setting in physx that makes it almost impossible to flip the vehicle) to reduce them flipping their vehicles over in turns at speeds that no sane person IRL would attempt. This is where the additional speedometer would really help. Also IRL every person can move his head easily without second thought or dedicated equipment. As Gamer you require headtracking equipment and software to easily "look to the left". Another reason to place at least a secondary display where everyone can see it (in default view). Engine limitation. Unless they rework the lighting system to allow shadow casting from extra light sources (like it is now in dayz) this will be as good as it gets. Having shadows cast from dynamic lights would be amazing (also for making building interiors in darkness much much better) but i dont think it is going to happen.

Look at vanilla weapon sound configs to learn how this is set up. Use all in one config download for vanilla so you dont have to chase individual config files (google for this in this forum), or just read config classes with the ingame config viewer. I think megagoth also has some good info in his addon discussion topic.

with the new independant camera bone option, view direction and turret direction are no longer necessarily synched.

Sad news, but i completely understand it. Going for very high accuracy and level of detail/quality requires an immensely disproportional amount of time and efford. Not something you can stem with a small volunteer team for a long time without making personal sacrifices in RL (which makes you question your doing every day).

technically you can read the animation source or animation state of the commanders turret right now to get the direction (which's name you can read from config). But its not particularly convenient, this is true.

Almost missed this gem... Awesome stuff! This will offer many new opportunities and solve a couple of issues i currently have

looking fabulous

If we could get details on what was unfavorable on dirt humps LOD that would be a help for us modders, to know what should be avoided on our terrain models. This would only make sense immediately after a vehicle got the damage while operational, and only if the radiator was actually damaged. It makes no sense and is very gamey if this is permanent, or guaranteed no matter where engine was hit. There are many other reasons for engines becoming disfunctional that do not procude any externally visible effects or noise. Seeing red engine status immediately after entering already is a simplification.

Not to mention first aid packs "damaging" other parts of the body in the past, when only one part was damaged. Haven't played properly in a while, but iirc when your leg was damaged and you healed yourself, every bodypart suddenly had 0.25 damage...

Intended as safeguard, but do they cover every possibility? After all, the force on the wheel translates through the suspension. And like i said - if physx operates in the way i remember (tire always posed on top of the closest raycast hit), and you limit vehicle suspension forces (or acceleration - same result), then what happens if the new wheel pose would overstep maxcompression limit of the suspension? That would be one boundary condition to much. Since there is imprecision and fluctuation in the calculations, a physx car tire beeing positioned extremely close to a curb for example (with distance between wheel and curb approaching zero) - sidescraping basically, there could be a chance that the raycast may instead hit the top of the curb, rather than the road. I haven't payed any attention, but do wheels properly cause lateral forces to prevent a tire close to a curb getting closer? And if so under what conditions is the force created? Maybe there needs to be a larger safety boundary. So when you drive and very slowly get closer to the curb, the lateral force from the collision needs to happen earlier, so that the raycast will always have a bit of buffer distance to not "glitch" on to the curb and cause sudden force spikes. I'm just stabbing in the dark here, its been too long since i looked at physx (also i looked mostly at the clutch thing...).

"explosive contact" behaviour is a key problem in physics modelling. In a force based system you need to create forces so that penetrating objects reject each other until they are no longer penetrating each other (or only ever so slightly). The "rejection force" is usally calculated by some spring factor * the distance of the penetration ± damping forces. Means, there will always be a tiny amount of "sinking into the ground" because at 0 penetration force is 0. This method works ok if objects come to rest or collide normally. Works bad if objects suddenly penetrate by a large amount (e.g. wheel suddenly 10cm in the "ground" due to ray cast falling onto another collision object, or two objects moving at very fast speeds and colliding, with collision speeds too fast for simulation step to resolve it properly) -> Huge forces, and unphysical behaviour. One possible solution could be to limit the maximum suspension force per tire generated by physics contacts via a vehicle based config parameter. So whenever contact forces are extreme, they get capped to a certain configurable limit -> this means the vehicle (or object) will slowly rise out of the ground whenever there are high penetration values, instead of beeing catapulted. How fast the vehicle will raise out of the penetrating object depends on the force cap. Initial starting point for experimentation (per tire) could for example be: 4x vehicle weight/ tire amount. IIrc physx does not calculate penetration distance, but instead always forces the tire to sit on the surface and then calculated the suspension force from the tire distance offset (in suspension direction) between the current and the last simulation step. Unless i'm missing something (brain in sleep mode already), a limiter on suspension force per tire should still work in this situation however. The only issue would be if suspension travel exceeds maximum permissiable limit. With the wheel beeing forced into the "nonpenetrating position" it means it will never clip into the ground. So if the force is also limited, the wheel would have to clip through the body - as there is no other way. And i dont think physx would like this either (possibly a crash as result or something ). that said, in these sidescraping situations... IRL the track or the landscape piece would give way... It's not just the game that doesnt like this kind of driving ;) This is not fault of Arma directly... RHS and CUP decided to add the tank barrel into the physx collision models of their tanks. Since turret turning is not part of the force considerations (yet?), they turn no matter what. IRL the turret would stop turning when it hits something and turret drive potentially break. Not in Arma. Which leads to many potential "explosive contact" situations where vehicles get stuck or are launched. When they swing the turret around very fast and hit something with the barrel, it's like some hammer of god hit something with near infinite force.. Except that their tank is not anchored like static objects , and since actio=reactio they fly when a static object or the ground itself (definitely infinite resistance force) is struck. Vanilla doesnt have tank barrels in the physx lod (they had at some point in alpha or beta).

no, extracting and modifying current Arma 3 content is not permitted (and not possible with the tools). So what you would want to do is unfortunately not possible currently.

At slow speeds physx is inaccurate and friction varies, even for identical sides. https://feedback.bistudio.com/T77522 Try finetuning MOI and dampingrateinair first and see what happens. That the tank accelerates on its own in previous trials is a good indicator that there is no issue with stuck wheels etc. When using RL values, remember that there are many losses on a vehicle, so even if the tank has 1500HP on paper, a big fraction can be taken up by engine cooling and all sorts of auxiliary pumps and things. That said, i can't recommend obsessing over "real values", because there are a few unphysical things (especially how MOI and dampingrateinair behave) that just void all the accuracy put into other parts.

Which is why Arma traditionally never really focused on supersonic Jets (and in the past, jets ingame would always have a speed handycap compared to RL). They changed it with the DLC somewhat because of popular demand and because the situation with Saul gave the opportunity.

weapon and scope zero in vanilla only compensate for distance, not for scope/sight heigth offset

1) there is only one functional mode for the gearbox in A3 currently and that is automatic mode "auto" (i guess full-auto does simply the same). 2) dampingrateinair and MOI are the main parameters that dictate how fast/slow your vehicles accelerates, decelerates without engine power and it's topspeeds. Tweaking them carefully, one at a time is necessary. That you stop as soon as you release throttle indicates that you have fairly high movement resistant currently. If the vehicle accelerates on it's own then that is a result of dampingrateinAir beeing too low for the chosen MOI value. It's unphysical behaviour (energy conservation law thrown out the window) due to BIS's tank physx integration as far as i can tell, but thats what we have to deal with. 3) in the dialog you see that at current top speed you have an rpm of ~1860 at the engine. If you check your engine settings, you see that at this point the engine is losing torque, would it turn faster. Your vehicle not accelerating further means that the MOI/dampingrateinair setting at this speed is in balance with the torque generated by the engine. JFYI - you also lose torque and rpm due to the physx clutch - if you check the rpm value behind Gear 2, it says 1589 rpm as Gearbox input - so you are losing 270 rpm due to the clutch at this mode of operation. For playing with dampingrate and MOI it is efficient to use diag.exe's config merge function. You can patch the config while the game is running that way. You only need to restart the mission (or respawn the vehicle) to get the change, instead of restarting the game.

wouldnt it be more performant to add a killed eventhandler to soon-to-be-dead unit(s), that writes the position to some variable (or directly creates a marker object/position for the group ...). After all, who knows if OP wants just a specific mission unit or every unit in a certain gamemode to be tracked.

First of all, the mass of physX LOD has no effect at all. To find out what causes this issue you should use arma3diag.exe (only available when using devbranch). When using diag.exe, activate EPEVehicle dialog for debugging help https://community.bistudio.com/wiki/Arma_3_Diagnostics_Exe Based on experience there could be two core reasons: a) the gearbox is simply not switching properly and is stuck in first gear b) some weird hiccup with the wheels/physx bodies, where parts are counted as draggin on the ground and therefore creating a lot of resistance forces Best way for us to help you would be if you could make a video of your tank (attempt to) drive, with EPEVehicle dialog enabled.

For example? The only case where zero range is not like in the weapon config is when there is a scope mounted with different zero values (which is in turn defined in the scope's config class). So this seems to be just a lack of understanding as far as i can judge. When dealing with 3rd party ballistics code, and the creators do not validate it properly, then i guess beeing carefull about config values not having effects one would expect is true. But for vanilla this is generally not the case (some oddities exist however). Even so, you only have to validate the config parameter once. You don't have to test 5 different weapons to make sure it works as you expect. You only need 1 test and based on that can deduct what the other weapons do based on their config parameter differences. in Eden Editor, there is a configViewer /cfgViewer button where you can browse all ingame config classes (also in ESC menue, when debug console is activated). Alternatively you can download an all-in-one config text file (a single textfile with all config entries of the game compiled into one) - makes searching for a specific class easier because you can use standard text-editors search functions (notepad++ etc). https://forums.bistudio.com/forums/topic/191737-updated-all-in-one-config-dumps/ To learn about the config parameters you can look into the Biki (e.g. https://community.bistudio.com/wiki/CfgWeapons_Config_Reference ) - that said, not all parameters are written down in the biki, because BIS themself did not update it in the past. Newer things they write down, but older stuff not so much. The Arma 3 Samples (on Steam tools) have configs with commentary what stuff does as well.

there is no such thing as top attack in vanilla (nor would it have any different effect on target vs. direct attack) If you use mods, ask the mod creators.

Second walk cycle looks a lot better than before. The only thin i see with the current one is that the forward movement is extremely fast - almost too fast to see. MWO mechs with fast speeds have a bit of jumping in their walk, so that the legs dont have to move so fast. Not sure if that would be in-character with your mech.