Jump to content


  • Content count

  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

1125 Excellent

About x3kj

  • Rank
    Warrant Officer

Profile Information

  • Gender
    Not Telling
  1. 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
  2. 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...
  3. [CTI,TvT,CooP] Dissension

    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).
  4. arma3 is so sick

    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.
  5. 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?
  6. @kllrt please dont forget to update A3 sample models with the head changes
  7. Documentaries Chernobyl 1986

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

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

    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.
  10. AI Driving - Feedback topic

    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).
  11. HUZZAH! I had already written it off as forever broken ... today is a great day
  12. 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.
  13. 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:
  14. 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]; }; }; };
  15. Hey guys, does anybody know of a way to rotate a tank on the spot by AI commands? (not by using any setdir or similar command) I'm trying to get self propelled with limited traverse angle to work, so i need the driver to adjust orientation when gun traverse limit is reached