x3kj

1) Corner piece (Bastion) for the wall sections, with open area for placement of vehicles, bunkers or other stuff 2) Small Pillbox, designed for 2-3 people fighting, or one heavy weapons team (different modifications will allow placing of tripod/bipod mounted heavy weapons), Class XV protection - safe against most ordinary Cannons @500m (not against siege weapons)

comments annotated in brown Core reason why tank battles are a clusterfuck is that AI attack routine is the same like for a rifleman. Which is ridiculously inappropriate. Riflemen close in on their target, until they killed it. Sometimes they run back, move to the side (to flank) and run towards the target again. Vanilla tanks do exactly the same. So if they saw a target that hides (i.e. a player) and therefore cant kill it immediately, they drive at it (while shooting) until they are in face hugging distance. Then they cant shoot anymore, because they cant elevate properly. This needs to stop. Tanks must always keep their distance to enemies unless terrain commands it (urban areas). How to break this madness? Idk - maybe something can be learned from vcom and other AI scripts. Also tanks never drive backwards.. with simple commands you can force them to drive in reverse, but you have to do path planning and path-checking via script yourself. Some other commands break simplecommands - esp. for AI tanks under player command (without player in it)

Where the controller-sources that where added over time for config sound effects (rpm, thrust, etc) also implemented for config particle effects? If not, could they be added? I tried intensity for exhausts but its just very glitchy and its behaviour is weird for tanks - it cuts out (stops emitting) when you steer with mouse, and when you release mouse it emits a huge wave of particles (causing even more lag than usual), sometimes they appear in strange locations. RPM and Thrust would be so much better controlls...

Sherp offroad adventure - cool scenes

https://community.bistudio.com/wiki/LOD 4-6 resolution lods (for larger objects) 2 shadow lod several collision lods

Is that your geometry LOD you shown there in the resolution LOD? If yes, you should optimize it. If geometry LOD looks beautifull it is a bad LOD - it must be as simple as possible. The railing is way too detailed, also the "mushrooms". Put that in the fireGeo if you really must (but reduce railing to 3 or 4 edgesat most around the circumference ). In geo LOD such detail does not belong, there is no point having a "round rail" in there. It gives no benefit for collision with humans or vehicles, but it costs more performance. The mushrooms should be simple cubes (if at all) for example. For PhysX LOD you should propably even delete all the vertical pieces of the rails (it gets rid of a huge amount of componentXX's that need to be checked for collision), because they have minimal effect.

you can always write yourself a max script to generate a model.cfg ... if you learn max script first...

Days without connection to the outside world can also be beneficial sometimes... i got pretty far with figuring out the first and smallest wall system type (which would used for small outposts/ bases). Still WIP obviously (esp. the vehicle firing element) and incomplete (e.g. there are no cornerpieces yet). The wall has regular parapet like 'ordinary' walls, but also integrated trench for protection during bombardments. 95% are already textured with the pillbox texture shown previously - pretty good mileage out of one texture i say. For 40k setting the merger with the trench made the most sense to me. Without it the troops would be super exposed to shells that fly over the wall and explode in the back. Plus when something manages to flank fire the wall soldiers have a chance of survival

Why would it make sense? It simply doesn't. You can only use bipods in the right situation, when the terrain permits. You cant use it all the time, especially not when firing high into the air. So why should Arma always give bipod bonus when in prone? Auto deployment is impractical. Bipods have movement limits and different rotation points than regular movement. Extend the limits where you get weapon resting bonus is a better compromise here. I agree with @da12thMonkey Downward firing is what is the problem of the bipod ingame. In prone, but also in the other stances. In many cases players are at a disadvantage when they are standing on a plateau that is higher than the enemy is at, since they cant use bipods. This is completely the opposite to real life. IRL enemy can't use bipods in prone or low stances on lower ground against enemies higher up. They always need an object to rest bipod on to be able to aim up. IRL, in prone and semi crouch to crouch there is always a way to fire over the edge of a mountain or plateau using bipods. (provided it is straight and not sloped downwards). You can kneel and deploy your weapon bipod on the ground to fire downwards at big negative angle IRL. In arma you are limited to prone deployment. Making firing upwards easier with bipod seems illogical. It should be the opposite direction that is "relaxed" in its limitations. Advantages and disadvantages from terrain slopes and height difference needs to be considered in real battle and that should be mirrored as good as possible in Arma. Otherwise we might as well revise the game concepts... from King of the Hill to King of the Valley...

Maybe it's a bit expensive to check, but maybe another solution for spawning AI of towns (i use town for simplification here, but it could be any capture location) could be dynamic based on proximity of enemy units (those that trigger spawning), so that they don't spawn behind the intruders and also not directly next to them. A spawning-safezone sector (like the piece of a pie, going from the capture enter) around intruders basically, . Another possible alternative: Deploy a couple of military buildings in and around the town/location. Each of those buildings units can spawn inside and then walk out. That means it will not be entirely unexpected where they appear from and they won't just pop in in plain sight. On the outskirts there could be tents or some other smaller building. The closer you get to the center of capture, the larger the military building could be. And the more units could be expected to exit from there. This also provides the opportunity to stagger the spawning, so that new units can spawn mid town-battle for the AI town defenders to replenish their numbers - ideally in a location that is least contested of course. If the buildings cant be looked inside of, nobody will notice someone spawning in it, unless they are in the building themself. That said, it needs to be possible to disable a building from spawning entirely (e.g. capture, or maybe also destruction from inside via explosion charges or something like that). Otherwise attackers still have to worry about units spawning from the place they already cleared, once they get further away on their mission to clear the town. Maybe another idea is to reduce number of AI per town slightly, but send instead one or two groups of reinforcement from another location via transport (just one or two - not more). Number and type of reinforcement could depend on size of town that sends it. this is a good idea. 2 Man patrols - not for the purpose of killing the enemy. They just need to discover an enemy and alert the stationed defenders attacking team. The attacking team is a larger team, which responds to things the patrol spotted (or got killed by). This is also pretty realistic i think. Static overwatches + a few patrols to control and close the gap in static overwatch (and be less predictable than static overwatches) + mobile combat teams at the ready to respond. The combat team can then spawn in in case of need (again, maybe inside a baracks building or something like that).

We have no time for stupid rant posts in the development forum. State your problem or question objectively in the right place (Arma Editing) , civilized, without ranting, and people will help if they can.

To repeat my question again - Whats the purpose of those selections for tankX? Is it still important? First time it was introduced way back when, i think it was to help with climbing ability - which now technically is not necessary (propably?) because there is fake acceleration helper force. What can we expect from these selections in terms of function and behaviour and what do we need to keep in mind when modelling the components? Are there specific things to avoid there?

@kllrt please dont forget to update A3 sample models with the head changes

Channel that has several recordings inside sarcophagus https://www.youtube.com/channel/UC0bOfQEN80hIbdEECDwLyJw/videos

better is the wrong word. It's the only option available - with the limitations i mentioned.

I have the impression that this is unfit for any detail, using a pure photogrammetry setup. Yes you can get the scale and basic shape and all well, but the actual detail (those that matter) will not transfer across properly using low grade setups. So you will end up having to build an entirely new model on top of it, LP and HP by hand and remodel all the detail, because thats actually easier and has better results than trying to repair/transform the scan data into something you can use. It's mostly used for props in the industry - which makes sense. Nobody will want to waste their time modelling a dozends of objects to assemble a virtaul heap of garbage for example - so they scan it in, bake it down into LP/texture - great. "Hero assets" (weapons, vehicles, characters) generally not scanned - at least not with low-end capturing equipment and software. Definitely has it's uses, and worth trying for yourself, but dont expect too much from it. The actual high grade stuff uses laser scanners to get the surface detail properly, and combines that with photos to overlay them for the texture. There are compact hand aparatii that can do this (seen at a tech convention 2 years ago) but i dont remember what their price was back then.

I agree with pierremgi, blaming assets is not fair (because with current DLC model, which imo is the most consumer friendly in the industry, assets are the only reason to buy a DLC - which also support development) Thats one of the most core issues with this hole thing imo. Nobody other than devs can do something about the problem, because it's all inaccessible and there is no way to override driving behaviours efficiently with custom logic. The script commands (like doMove etc) are insufficient for dealing with this. I'm expecting/hoping for improvements in future games in regards for AI driving. But i'm also hoping of improvements in accessability of that logic from the outside. Eventhandlers for stuff related to driving routines for example - detected obstacle, or detected crash, change of move order, etc . And also for 2 distinct ways of exerting controll over AI externally in scripts - "by command" (like it is now with commands "fire at thing X", "move to pos Y") and "direct" (which forcibly interrupts the logic chain in order to be able to do a specific thing exactly and precisely by simulating player inputs. Like pressing the key to move forward for an exact amount of time. ). Right now we have no direct control over AI driving actions (increase throttle, stop, steer left/right etc). It can be done somewhat on command level - which breaks in certain circumstances. E.g. you can order tanks via https://community.bistudio.com/wiki/sendSimpleCommand but such commands are only accepted in special conditions - namely when AI subordinate follows the owning player. Not when it is told to stop or is told to move somewhere by the player. I have been running into this problem when trying to get AI to turn into a specific direction in my attempt at a custom artillery script (https://www.youtube.com/watch?v=uKGzWkKDwdY).

HUZZAH! I had already written it off as forever broken ... today is a great day

use EPEVehicle modus in arma3_diag.exe https://community.bistudio.com/wiki/Arma_3_Diagnostics_Exe to see at what gear it is stuck and what the rpm is.

To adress the limitations of the vanilla artillery system we have to come up with our own solution (that also works for AI) This is a sneak peak/ demonstration of the functionality at current state:

Thanks, i didnt know this was possible. Pretty usefull, but unfortunately it is not accurate enough for what i'm trying to do. When i stop it rotating, it keeps going for another 70° or so (depends on physx setup). After testing i made a hybrid workaround using setDriveOnPath to a position behind the vehicle, so it starts rotating and then using doStop at the desired direction (and before it starts moving forward). This gives me reliable results of around + - 4° for the vehicles. But i'm having trouble to get it to work for AI units under player command: If i spawn the unit in eden by themself they will react to doStop commands no problem. If i spawn the unit in eden under player AI control, it reacts to doStop no problem, but only until i give the first Move Order. Then it just ignores doStop, or works very unreliably (after regroup command was ordered the first doStop works occasionally, but the second that stops it from actually going to the position in setDrivePath) handle = [] spawn { private ["_p_tar","_vehicle","_com","_speedm","_dir_rel","_drvr","_p_veh","_debug_chat","_debug"]; _p_tar = getPosASL player; //position target - where to orientate to hint format ["Pos player %1", _p_tar]; _debug_chat = true; _debug = true; _vehicle = tank; //mission object //stop vehicle from moving with group _com = effectiveCommander _vehicle; //global doStop _com; //global. Does not prevent unit from starting to move again when enemy is sighted _drvr = driver _vehicle; if (isPlayer _drvr) then { hint format ["Driver, orient %1", _dir_rel]; } else { sleep 3; //wait for it to stop _dir_tar = (_vehicle getDir _p_tar);//direction to target _dir_rel = (_dir_tar - getDir _vehicle); // _dir_rel = ((_vehicle getDir _p_tar) - getDir _vehicle); if ( abs(_dir_rel) > 4) then { if (_debug) then { diag_log [">>> ARTY FCS start traverse: rel dir to target is ",_dir_rel]; }; private _tol = 4; //stop when direction in this tolerance if ( abs(_dir_rel) > 15) then { _tol = 15 }; // increased turning distance means increased turning speed -> increase tolerance to stop earlier // calculate position behind vehicle private _clockwise=false; if (_dir_rel > 0) then { if (_dir_rel < 180) then {_clockwise=true;}; } else { if (_dir_rel <-180) then {_clockwise=true;}; }; if (abs(_dir_rel) > 120) then { if (_clockwise) then { _vehicle sendSimpleCommand "RIGHT"; } else { _vehicle sendSimpleCommand "LEFT"; }; waitUntil { _dir_rel = (_dir_tar - getDir _vehicle); if (_dir_rel > 180) then { _dir_rel = abs(360 - _dir_rel); }; if (_dir_rel < -180) then { _dir_rel = abs(_dir_rel+360); }; if (abs(_dir_rel) <= 100) exitWith {true;}; false; }; _vehicle sendSimpleCommand "STOPTURNING"; sleep 1; }; _clockwise=false; if (_dir_rel > 0) then { if (_dir_rel < 180) then {_clockwise=true;}; } else { if (_dir_rel <-180) then {_clockwise=true;}; }; private _d = 0; if (_clockwise) then { _d = (getDir _vehicle) + 150 ; hint format ["BehindVehicle Dir _d + 150 %1", _d]; } else { _d = (getDir _vehicle) - 150 ; hint format ["BehindVehicle Dir _d - 150 %1", _d]; }; _p_behind = _vehicle getPos [20,_d]; _p_veh = getPosASL _vehicle; _vehicle setDriveOnPath [_p_veh,_p_behind]; waitUntil { _dir_rel = ((_vehicle getDir _p_tar) - getDir _vehicle); if (_dir_rel > 180) then { _dir_rel = abs(360 - _dir_rel); }; if (_dir_rel < -180) then { _dir_rel = abs(_dir_rel+360); }; if (abs(_dir_rel) <= _tol) exitWith {true;}; //changing _tol tolerance makes vehicle stop earlier false; }; doStop _com; //global. Does not prevent unit from starting to move again when enemy is sighted sleep 1.5; _dir_rel = ((_vehicle getDir _p_tar) - getDir _vehicle); hint format ["relative direction final %1", _dir_rel]; }; }; };

How is this an AI driving problem? BIS is not responsible for mission design from community authors. There are certainly issues with driving AI, but not everything is fault of AI driving, or even BIS's fault. Entire Altis is covered with these super annoying small stone walls and those steel road boundary things that can wreck almost all vehicles or at least get them stuck, or flip them. Not just AI, also players are regularly victims of them.This is a map/model design issue. They are indestructible and present almost everywhere. Also, there is barely any slowdown when driving off road. Remember A2, where you where your max speed was cut in half or more in many cases when you left the road. In A3 everything is practically autobahn - except it's littered with obstacles that can wreck anyone foolish enough to drive at max speed (such as those tiny stone walls). Supply truck driving in CTI didnt reliably work in A2 either, which is why people started allowing it to be disabled (benny warfare) back then already.

So is this just a general 2nd screen, that you put a self-built cover over for looks ? Or is that purpose built hardware you buy somewhere? Looks interesting. If you are looking for customizable options, maybe a toggle for metric/imperial units (e.g. soviet is all metric) would be worthwhile. Also soviet artificial horizon style unit - it's pretty good and (imo) more handy than typical western "brown-blue-ball". Climb indicator on arma planes will usually just bounce all over the place. Making it non-linear (in discrete steps) helps. Oil, Vacuum and Ammeter Indicator are only window dressing. Yes, flavor. There are more relevant indicators that could be integrated though. G force indicator; Flaps, Gear, Light status; Damage status; Lock on warning. Just saying.

What was the reason for PCML submun not triggering correctly?

Long time no update, but things are still going - just not a lot of significant stuff to show. The Heavy Stubber from above was finished and optimized, as well as the Stubgun. MartinezFG11 also worked on another Heavy Stubber which should be ready soon-ish. Some vehicles also got their LOD pass that was still missing (Basilisk and Hydra). Texturing the passenger interior of the Chimera was started but is not quite there yet. Concepting for structures (buildings and fortifications) continued. I think i am finally happy with the Medium pillbox concept, now it goes into details and modelling all the different modules from which a wide variety of different layouts can be constructed in a time efficient manner. Seen in the pictures are the first base modules (blank wall, 2 different firing portholes - both for single and dual storey building). The textures will need some tinkering still. What's next are entry points, firing positions for a variety of medium and heavy weapons, corners at different angles and so on, as well as the interior. A lot of my time was also spent on figuring out and starting a base system for new texturing materials that can be shared across multiple people of the team, so things will look similar even if different people made them. Still quite a long way to go with that however ... i hope i'm not getting sick of this kind of french spaghetti any time soon The team of volunteers has grown as well, 2 map makers (Nightovizard and Mog'Dug) and 2 additional modellers (Ghengis Steve and Testarossa) have voiced their interest in helping so far. May the future be bright grim dark and productive We are still looking for any people interested in helping. Especially those who could support us with config work and/or scripting, animators (esp. hand and reload animations for hand weapons) and sound effect creators would be most helpful right now.