oukej
-
Content Count
1063 -
Joined
-
Last visited
-
Medals
-
Medals
-
Everything posted by oukej
-
All those missiles have datalink as well. AI can't utilize autoSeek :/
-
It used to be triggered only by proximity to the target. Now it also triggers on impact (like standard HEAT). We also don't have different submunition behavior based on the firemode to make the PCML representation a bit more accurate, so this was a necessary safety measure.
-
Tanks - Missile flight profiles and weapon improvements
oukej replied to oukej's topic in ARMA 3 - DEVELOPMENT BRANCH
It's possible via https://community.bistudio.com/wiki/Arma_3_Missile_flight_profiles#LoalDistance and it's coming to ARH missiles (except of Zephyr) and to be tested on dev-branch. Might have been a telepathy or something - commited that just yesterday :D Just to manage expectations - what's coming is a "maddog" launch - i.e. a "dumb-fired" missile will find a target on its own and a missile knows no friendlies. Mid-course updates won't be possible. -
Jets - Sensor overhaul (Radars, IRs, Lazors, PGMs)
oukej replied to oukej's topic in ARMA 3 - DEVELOPMENT BRANCH
(Also added note to the feedback tracker) The AI pilot has to first know that the target is an enemy. He doesn't know that from sensors alone (sensors do not reveal allegiance). Missile itself only provides some engagement envelope. As for target acquisition - that's a different story :) In the following test I've added a Wipeout pilot to the player's group. Player, as a leader, then gives the Wipeout a target (T-100, with engines already running). That makes the AI pilot know that he should expect an enemy target at a given position. The pilot however can't see the target yet. So the default weapon - selected by the AI pilot - remains the cannon (AI only switches to a desired weapon once engaging). AI only switches to the Macer around 5 km from the target. This depends on: the weapon's probability (target value coef.) vs. range missile's own missileLockMaxDistance (6 km for Macer) and the AI's skill, e.g. AI with skill 1.0 will launch Macer @ ~5.5km (after it has already acquired the target and waited 3s for the lock). Keep in mind that in this example the AI pilot already has a good knowledge about the target from his leader (group), so the skill only affects the speed of the actual engagement. If the target was a completely new one and there was no info about it from AI's group then the skill would also affect the initial acquisition and recognition that the target is an enemy and should be engaged.- 957 replies
-
- 7
-
-
-
- electronic warfare
- radar
- (and 8 more)
-
We've increased the simulationStep (back to default 0.05) because with very short sim. step time there's a higher chance of duplicated (or several) hit registration during projectile penetration of one component. Sometimes you could've experienced a much higher damage dealt when the projectile ended up going through thick components (front armor).
-
CfgExperience got adjusted together with changes in the revive system. Becoming renegade from FF should be roughly the same or only slightly more forgiving (except of killing higher ranks - now there's no difference between killing a soldier and a leader) More probably the issue could've been caused by a recently introduced bug in cost values. Can you please try it again after next dev. update?
-
bug 17 years old bug in A3 - 'A fallen static objects' geometries bug'
oukej replied to RozekPoland's topic in ARMA 3 - DEVELOPMENT BRANCH
Pls, once it's out, try out everything that pops up on your mind that could be a possible side effect. Also - send BXBX some beers and convince him to stay with the company pls ;)- 70 replies
-
- 35
-
-
-
T is for marking targets in boresight / center-of-screen (freelook) only. If there's a target that's visible to any sensor you should reliably mark the target (square brackets). The target doesn't have to be in missile's range, you don't even have to have any munition equipped or selected. R is a bit trickier - it's used to cycle through all targets acquired by all sensors. But there's a prioritization applied - it will only cycle through targets suitable for the currently selected munition. With every second click returning the "mark" to the target with highest prio (highest threat, closest range). Also R won't mark a friendly target. (We wanted to improve that but so far it seems it may stay this way)
-
The activeSensorAlwaysOn parameter relates to radar (active sensor) guided munitions and can be used to prevent the munition from acquiring a lock when vehicle radar is off or nonexistent. The automatic target acquisition (autoSeekTarget) works only for launchers (shoulder-fired, like Titan AA). Enabling the same functionality for vehicle weapons has sadly not proved tech. feasible (we've looked into that during Jets development). So you will always need to use T or R to acquire a target in a vehicle.
-
This changelog note only related to to the Malden terrain. Same changes were applied to other terrains previously. The roads of various types should now have a consistent positioning of the path line on the road - the line the AI is trying to follow when driving in one direction. The path line offset on the road also depends on the size of the vehicle - the bigger the vehicle the more to the center the line will be. It can't be too close to the side because of the resolution (spacing) of the path nodes on the road which can lead to cut corners.
-
Changes in AIpathOffset in terrain's class RoadTypesLibrary
-
The Titan doesn't have such a big trigger radius and overall the missile isn't rly good at transsonic or faster taregets. (It's primarily against helicopters and slow flying jets.) But then one vid shows an Ababil near miss. Is that reliably reproducible for u pls?
-
In the first post there's some commentary missing, so: class AICarSteeringComponent //or AITankSteeringComponent { // controls working parameters of steering PID controller (Kp, Ki, Kd) steeringPIDWeights[] = { 1.2, 0.1, 0.2 }; // controls working parameters of speed PID controller (Kp, Ki, Kd) speedPIDWeights[] = { 0.7, 0.2, 0.0 }; // remapping of maxSpeed of vehicle, for fast vehicles we want to lower the used speed doRemapSpeed = true; remapSpeedRange[] = { 30.0, 70.0 }; remapSpeedScalar[] = { 1.0, 0.35 }; // prediction ahead is used for both steering and analysing of shape to modify the speed doPredictForward = true; predictForwardRange[] = { 1, 20 }; // steer ahead is a point to steer to, saturated down to given range, in meters steerAheadSaturation[] = { 0.01, 0.4 }; // set method of predicting safe speed // 0 - three angles method // 1 - wheel direction method // 2 - combined method speedPredictionMethod = 2; // three coef's to determine how much given angle should influence slowing down wheelAngleCoef = 0.7; forwardAngleCoef = 0.7; steeringAngleCoef = 1.0; differenceAngleCoef = 1.0; // for how long we allow the vehicle to be not moving, before it replans stuckMaxTime = 3.0; // overtaking is part of collision avoidance allowOvertaking = true; allowCollisionAvoidance = true; // allow using movement vector as direction (experimental) allowDrifting = false; // parameters of predictionMethod = 1 maxWheelAngleDiff = 0.2616; minSpeedToKeep = 0.1; // how strong AI will turn when commanded left/right commandTurnFactor = 1.0; // AITankSteeringComponent only allowTurnAroundInPoint = true; };
-
The "new driving stuff" is just the PIDs. Set useAISteeringComponent to false or delete the component class iirc (inherited all the way from Car_F base class) and you're back to the "old driving". But there are many other things that can influence or be the cause of AI driving issues (see at the bottom). The oscillations around the ideal path have been always around in Arma 3 and were usually "caused" by a strong (good enough) braking power. In the "old driving" we simply solved it by making the brakes deliberately weak(er). In the "new driving" one should be able to tune the AI driving (PID controllers) well together with any vehicle steering, accelerating or braking capabilities. Even with some driving style (casual, racing) in mind. At least in theory. In the old driving the AI posed strict limits to what one could do with the configuration of the vehicle handling. I can't ask you to "fix it for us" but I'd still humbly ask anyone to try setting up the PIDs themselves (info in the first thread post). If you find values that give better results please share them with us and we'll be more than happy to adjust the configs. Otherwise, from top of my head - in Tanks and in the previous patch - there have been several changes which may have had some impact on the AI driving * PhysX lib update * Switch from raycast to sweep queries and wheel colliders * Adjusted surface frictions (generally lowered) * Small changes to AIpathOffsets on roads * Various AI driving fixes * And for Hatchback specifically also a complete overhaul (that's why the blame;)) of it's PhysX configuration. Other overhauled vehicles were the tracked ones, the kart, Hatchback, Zamak and also wheeled APCs to a degree. Using e.g. Hunter for testing would rule out these overhauls as a possible cause.
-
Thanks... that's exactly the evidence that the current AI technology is the wrong way. It's definitely an evidence of a vehicle where the PID hasn't been tuned well enough together with the updated PhysX configuration #blameoukej.
-
useAISteeringComponent
-
What about POV hat? What kind of joystick do you use? What were the other you've tried so far? Already acknowledged. I'm sorry, I didn't get this one. What approach did you mean in particular pls?
-
Tanks - tracked vehicles driving and handling
oukej replied to oukej's topic in ARMA 3 - DEVELOPMENT BRANCH
Used to compute default for peakTorque (if undefined). Otherwise only for deprecated functionalities.Afaict. Default is 50. It was added in the early development because the tank physics (their wheel differential) didn't work well with wheels that are constantly in the air (sprocket, pulley). It dampens the wheels that are in the air and as you hinted towards - it is a bit of a "magic" value. For tanks' clutch strength we use more or less the values you mentioned (30-50, even up to 70). Also we have the switchTime set to 0 on all tracked vehicles. Again - as u mentioned - because you can't steer during the change. We didn't have the chance to alter that. If you have tried the first iteration of an overhauled Kuma last year there was basically no damping (minimal stable damping). It's suspension looked better in many cases. But there was an issues with rough impacts - e.g. when jumping. The tanks bounced away from the ground in a toy-like fashion. It didn't feel like a 60-tonne vehicle. IRL the tank's weight wouldn't be transferred so well into the recoil. The vehicle would also be able to 'smooth the terrain'. On vanilla tanks we tried to compensate these missing effects by adding dampers (even though that came at a loss of this nice suspension sway, especially after firing a gun). It makes the tanks drive better over a rough terrain. -
Yes, it was. With me personally being responsible for that call. I don't care about egos :P It might not have been the best call. The system wasn't perfect and it ain't perfect now either. But let's be honest, your position in this is also a very specific one.
- 5179 replies
-
- 1
-
-
- branch
- development
- (and 1 more)
-
We don't force. But we do know better ;) We value our community probably beyond any other company out there. It's our pillar and our vision. A lot, if not most, of us have come from the community anyway. The 'community' is the best advisor we could ever hope for. But it's the developers who can make the (well-informed! :)) decisions and lead the direction. Btw in many other areas of life the ones with the deepest insights are not always the ones who can make the calls. This is just my own personal opinion.
- 5179 replies
-
- 2
-
-
- branch
- development
- (and 1 more)
-
Don't want to get all apologetic in here ;) The "refactoring" was primarily triggered by AI behavior bugs for which the refactoring was a solution. Some added clarity of the code or the effect progression was something we saw just as an added benefit. But at the same we were very hesitant about changing something the players have already adapted to and found their ways around. In the end we had to make a call. There wasn't an ideal solution. Still, thanks to you that call was - I believe - a well informed one. Even though there were definitely some new issues coming with it.
- 5179 replies
-
- 1
-
-
- branch
- development
- (and 1 more)
-
The AI is using PID controllers. I believe there are many improvements still possible just by setting up the data, the PIDs. At this point most of the vehicles inherit a setup from the car base class. (Btw, Hatchback Sport is quite an unorthodox asset. More of a just for fun car with an over-the-top configuration. Hunter MRAP would be a better benchmark for AI driving issues.) This also means that when looking at the AI path-following we have to consider the particular vehicle. Bugs in this field are well recognizable in the diagnostics - from various oscillations, deliberate under/oversteering, constantly braking and accelerating, generally driving that is not smooth. This is something we can still improve. Given the time.... It is also where we more than welcome any suggestions for an actual setup of individual PID controller values. If AI plans its path over some obstacles, steep slopes or areas where it will obviously get stuck, if it can't reach a destination or if it doesn't even try driving anywhere, it usually indicates a problem in the path-finding. Those are predominantly caused by bad map data. It can be something introduced directly by the map or object designer (areas restricted to the AI because of objects placed under the terrain, bad path LODs in buildings or their connection to the terrain,... ), but it can also be an outcome of binarization and processing problems (incorrectly connected roads, bridges; incorrect order in the cost map...). The vanilla maps can have those issues too. With probably the most painful ones stemming from issues within the binarization. We've tried and we've been half-way to solving that. To be honest, we've probably already run out of time at this point. We still plan to release more diagnostics. To help the community authors better solve these problems on their creations. And again, mainly when it comes to path-following, we've still got options for improvements via PID config tweaks ;)
-
Just to be sure - I meant the aiDispersionCoef. The bigger the AI coefficient the bigger the base imprecision but also the bigger scaling of the effect between skill 0 and 1. And it's something we can do on our side of data (and possibly the only thing we can do now). Also mainly because we've just done some adjustments to the coefs on vehicular weapons during the Tanks DLC development along with changes to the actual weapon dispersion. Like in many other areas the system is a result of two decades of development by various teams, with sometimes different views, with a lot of know-how gained in the process, but also parts of it gradually lost and regained. We stand by what we have but sure we'd sometimes like to have things designed completely differently :)
- 5179 replies
-
- 4
-
-
-
-
- branch
- development
- (and 1 more)
-
AI dispersion can still be adjusted, across the board, for weapon categories or individual weapons. It would also extend the range of the difficulty slider. Vehicle weapons' AI dispersion is deliberately set to relatively low values. It can be increased, few things to keep in mind though: the weapons themselves have quite some dispersion (few months ago I've talked about those changes in general discussion) the effect is the same for the enemy gunners and your own AI gunner if you're a vehicle commander. So we need some kind of compromise where it looks reasonably from both perspectives.
- 5179 replies
-
- 1
-
-
- branch
- development
- (and 1 more)
