x3kj

Question: Has there been an intended change to make enableDebugConsole not work in singleplayer? I have used a simple mission for quick testing for ages, it always had enableDebugConsole=2 and it always had debug console available in singeplayer. Now the debug console simply doesnt show anymore. Why is that? It is really hampering me, as i can't just load up a mission via startup parameters , i always have to go in the main menu, select eden, select mission, etc.

It's not explicitly communicated, so people coming from other games could simply assume that it's similar to other games - where such a thing simply wouldn't work. It would help if it is communicated in the controls setting menu if an input supports analog input, or if it's binary (0 or 1). There are other examples, like lean left/right for infantry.

There is no complex mechanic in clicking a button to choose an attack mode, automatically lock, click fire. So i don't see the "SO much more satisfying" potential there. There is no different operating skill involved. There is only knowledge of which AT uses which guidance mode and which sensors. The only exception from this is SACLOS and MCLOS (which is not implemented). On the other hand i consider it easy to aquire and apply that knowledge (also, descriptive names for ammo - Scalpel IR, Scalpel Laser, or whatever - will make it obvious which does which.) - provided there is a good ressource, such as a little tutorial or showcase - which i am pretty sure is required with some new Tank DLC features anyway.

True, 90° submun angle is dependant mostly on trigger time tolerance - other angles are less dependant on time tolerance, but more dependant on heigth tolerance between missile and aimpoint (due to missile performance and accuracy in hitting the imaginary aimpoint, and also due to the aimpoint shifting as result of target movement over non-flat terrain), and dependant on object overall heigth and shape. How is the heigth of the aimpoint in relation to target model position determined? Through bounding box heigth, aimpoint memorypoint, or bounding memorypoint ? If the object has a lot of heigth variation (Take a battleship for example - some very high tower, rest relatively flat), and the aiming point sits too high, the chances are good that the submun would reliably overshoot from certain angles.

I would be ok with just shooting from crouch (its not realistic, but ok) - the main problem i have currently is with forced shouldering when going prone with launcher is that you are so arkwardly slow to equip/unequip the launcher. When you crawl behind a small wall and want to go up in crouch and shoot... you first have to go up in crouch, sloooooowly shoulder your rifle and get the launcher, start aiming, shoot, slooooowly shoulder launcher and unshoulder rifle, go prone. Its super arkward New targeting mode looks neat, but it seems more like a gimmick - very shallow and accuracy seems not that great. I would have preferred improvements to manual guidance (the most engaging weapon mechanic in the game imo) to be actually beam riding. Manual guidance has servere accuracy problems against moving targets because the missile tries to steer towards the final aiming point, instead of trying to align itself with the "beam" of the guidance system. This makes it very hard to controll as the final aiming point can switch rapidly in distance (target moves, sometimes you "miss" aiming at the target while the missile is flying, so the aiming point will be several 100-1000 m's in the distance). And because the missile is never in line with your optic axis the corrections it will take might lead it such that it can't hit the target at all. In addition, the missile has no guidance fail - if the missile has passed the current aiming target it tries to fliy a looping to come back around. Having the ability for firing modes on launchers is awesome for modding though... UT Triple Rocketlauncher here i come :D

Not seeing anything like that unfortunately. When i use: diag_list "toggle"; it shows "Shots". But doesn't matter if i toggle it or diag_enable true it - no effect, other than the time going from editor preview back to editor beeing longer than usual and showing a blurred screen briefly (only with Shots enabled). So it appears to have some effect, but not what you show. Revision 144205

Tried the "Shots" diag mode... it doesn't do anything, at least nothing that i can see. The only effect it has that when in Eden, going to preview and then going back to editor takes longer and showes some weird "intermediary" screen in VR Yeah, but with this "announcement" i'm happy nontheless

I mean... it's not totally out of character for US to choose shiny over camoflage *cough* UCP *cough*

Big thanks to iSchluff who offered us a bit of servers space and help in setting up a SVN repository. Mean while work continues - very slowly - machineguns for the infantry (HP model, wip) by me

@oukej I mentioned it in the past a couple times , but could we please get a script command that can read the objects(units) currently visible on the sensor-scope of a specific unit at the moment of calling? Everytime someone wants to do something that involves electronic detection or post processing of sensor info in any way, they have to write their own radar/sensor system from scratch, because the information from old and new sensors are totally inaccessible for scripts. There is so much potential for cool stuff (missions, extra features, nicer/ more immersive displaying, ...) if we could just read the units.

this is... magical

Yes indeed, in theory some improvement is possible by changing configuration. The current configuration does not produce any noticeable effects. The dampersBumpCoef, as the page says, only affects visual animation, not simulation - > the simulation part however is what matters for gameplay. If a car doesn't oscillate/shake and it's just the wheels going up and down, then it wont matter for a player if he drives across a "simulated boulder field" with 30kph or 100kph. At 100kph it would look like it would have destructive effect on the suspension, but it doesn't. They are available since A2 or even earlier if i'm not wrong. But as your reaction proves - the way they are set up in A3 does not lead to any noticeable effect. Also, up until recently maxspeed was totally useless parameter for tracked vehicles for example - they could easily go above it when driving downhill, or if their physx parameters where capable of much more.

It would be most usefull for making AI more capable to decide if to engage enemy or not. hover cars :) Part of the problem is also related to offroad ground not providing any limits to speed or increase of rolling resistance

That's how gatling weapon sounds work, isn't it? I would have a look at those first.

if memory serves right, this mod used to automatically and immediately apply an "afterburner" script when you where on the ground and pushed the throttle lightly. I will agree that it is a bit more difficult to controll precise speed (or decend when using vtol) when only using keyboard.

Even those battle drills would require the AI to understand the situation well. It doesn't know "how to use the terrain" for example. How does it sweep across the objective? If it can't 'read' terrain it has to do a hardcoded sequence of movement - which just can't cover every possible situation - so it will work in some cases, but in complicated situations it will just utterly fail. If you want AI that reacts sensibly to even basic commands, you need to "teach" it (as in code the system for it) the very basics and fundamentals. There's no way around it. It's not impossible but it is a tough nut to crack. Creating intelligently reacting state machines (because AI it is not really...) is a much much more complex topic than what that paper deals with... people with aversion against complex thoughts and questioning ones own decision making process will generally not be people who write AI. Even if you had the AI that could react on everything like a human, how do you even plan to validate it? By outcome? How do you know the outcome was due to the EDM and not other factors? If you want to validate such a basic and general concept as EDM, you will be more successfull trying to find situations where it won't work. And there you are better off with creating a dynamic mission randomizer that puts you as SL in random situations repeatedly that you have to react to. If you want to validate EDM with KI as the ones doing the acting in any shape or form you need to create many more papers on what human 'sensory data' interpretation/decision making from terrain knowledge, enemy knowledge and known unknowledge actually breaks down to at the core level before someone can come along and "simply" put that into algorithms. If you just want better AI - welcome to the club. But whatever it is you want - in modding there is one advice i can give you: If you want something really bad and it doesn't exist, you have to get your hands dirty and make it yourself - unless you like waiting for eternity. Especially for AI stuff. The people who have their fingers in serious AI modding for Arma you can propably count on one hand. Also, AI is serious business, especially now. Intelligently reacting algorithms for games are worth quite a bit, and not just for entertainment... Don't expect somebody to write an intelligent AI for you for your research plans just like that.

https://community.bistudio.com/wiki/BIS_fnc_buildingPositions https://community.bistudio.com/wiki/buildingPos https://community.bistudio.com/wiki/buildingExit if none are found, there is no path lod. more theoretical information: https://community.bistudio.com/wiki/LOD#Paths The "can't enter" issue could also happen because the building is 1cm sunk too far into the ground - it's not possible to tell what the requirements are for finding/accepting an entry position. Vanilla buildings have some fancy "entry flower" - you can check the Arma 3 Sample house to see how that looks like.

cannon based weapons (ammo with simulation=shotshell) can not use multiple tracer origins. Regular guns (ammo with simulation=shotBullet) work for this without problem (check setup of AA tanks) I would suggest to make a 2-person ship, with the turret beeing operated by hidden AI always (maybe drone functionality can be used for this). By script you might be able to force it to target something and open fire with a burst.

In theory. And i think this is why most people like the idea of the warfare game mode. But can it really deliver that in practice? Imo it can only deliver less than half of what the idea promises. Especially for public servers with casual players (meaning those who do not have 3-5hours available to sit through a whole game, and those who do not have sworn in groups and methods for team play). There are no good systems and aids to help and encourage players to organise and collaborate with each other. A task and request system is what could be a good way to solve this issue. And the 'large scale' degrades over time, as people spawn less and less AI, in favor of single powerfull assets. Why does it often boil down to player trying cheese strategies or only using powerfull assets themself instead of using more AI? 1) Because controlling AI can be cumbersome 2) The way bigger aspect imo, is that setting up your AI team is extremely cumbersome. The "barbie soldier " aspect, where sometimes you have to even purchase individual gear for AI soldiers is taking it to the maximum level of uncomfortability. This works in single player missions maybe. But not for mission where you can lose half or more of your AI a lot quicker than you can say "holy s..". Example - You had your "dream team" setup. Vehicles, Planes, Infantry. Somewhere in the middle of the map shit hit the fan and you have some vehicle crew without vehicle remaining, you and some other are dead and back at respawn, some of your infantry are still defending their position. Getting back into action from this, with an organised team is really cumbersome. You have to recruit and outfit new units, possibly set them up into groups (red, green, etc) and you have to bring them all back together, and then get back into action. Considering that this "shit hit the fan" can happen very very quickly, the demotivating factor can be really high. Sometimes you lose half your group before you even have assembled everything and are ready to strike. Simply put: There is way too much micromanagement required to maintain your AI units at a constant amount in a coherent formation. This is why many people will spawn less and less AI, and will rely on high value assets or cheese tactics only (which they usually control themself). So there's 2 things to increase AI usage and therefore also scale of conflict: 1) Keep resupply lines and spawn routes short. Provide options to setup depots, where units can be temporarily stored for reducing time to get back in action. 2) Significantly reduce amount of micro management required to maintain AI units amount -> auto re-recruitment after losses, automatic execution of pre-specified command (meet at position xyz, regroup with player, follow unit xyz) Indeed. And i think this is what the biggest problem is with the current incarnation of Warfare game modes (including becti). There is never a 'frontline' - everything is in flux and instead of warfare it often boils down to roaming bands of warriors who try to claim every village for their tribe while trying to find the enemies tribe leader. This means coordination and team tactics become difficult. It is never really possible to tell where an enemy would have to be expected and where not. Confusion is reigning. With the primary objective to assassinate the HQ (because it is a game ender) this gets even worse, as groups actively try to bypass each other in order to get to the base of each other. The destruction of the HQ therefore should only have secondary effects temporarily and not mean the end of the game. Making the destruction harder will not change the focus. There will always be a way to use cheese tactics and lone wolfing to destroy bases. Especially if commanders take a long time to build their "dream fortress". Maintenaince (that means keeping the base alive and functioning) should be very easy and quick, and dream fortress building (tons of wall sections, tents and huge domes) should be discouraged - it just increases object count and removes focus from the actual game. In addition it makes the target just the more enticing, the more elaborate it is and the more time has been spent on it - the inner troll in everyone will agree. And no base can withstand a quick carpet-bombing run with a CAS plane or Arty/MLRS barrage. There is no other way, due to the complexity. But the important take-away is that CTI should be fun, even if you have only 30min and can only JIP. Which currently it generally isn't, as you have to earn money the hard way first, and have considerable time to get into action with your AI group first. With this beeing the case, people with limited time will find much more enjoyment in other game modes. But i think this can be adressed, if concessions to "commander/ player progression" are made.

I skimmed over the paper. This "EDM" alone is not enough to make a new AI. It is only a structure of "in which order to think". What you need for AI is to answers the question of "how to decide" and in addition, provide all the data required for this decision process. In the paper someone suggested the matrix is just a matrix and not a calculator. Game AI is a pure calculator - everything needs to be coded, it can't rely on human intuition, human perception, human understanding. Validating the EDM for humans by creating AI will not work - because for AI you hardcode any decision making process and every data they can get. Humans decision processes and data gathering "methods" are not hardcoded, may vary between individuals and may depend on human and environmental conditions. How can i determine if a decision aligns with my commanders goals? -> requires that there is a commander AI with goals (not so difficult), and that a SL can interpret if any opportunity for acting/not acting matches this goal (moderately difficult in isolated cases, very difficult in very complex scenarios). How can i determine if i "can take them"? ->Requires in depth knowledge of weaponry and their meaning (easy), Requires modelling of human perception and intuition (extremely difficult). Requires in depth knowledge of terrain and what it means to all aspects of combat (very difficult). Requires modelling of situational awareness (very difficult) If those things can not be modelled sufficiently, the "EDM" can not be applied at all. In addition, any decision making process is hardcoded and hardwired. This means, if something in the coded decision making process is somehow flawed, the EDM modell can not be applied realistically. I have explored these question (how to think, how to decide) with the idea to explore the feasability of a more human-like and succesfull AI command structure. The "in which order to think" part is easy - anyone with good analytical skill will quickly come to a very similar conclusion just by observation. However, the realisation in which order to think is just a drop in the ocean compared to what analytical and code work is required to make a "battle calculator" in form of an AI system. Put simply: If you can model all aspects of human cognition and decision making process accurately, you can validate the "EDM" process by AI. If not, it would still be a massive benefit to Arma to have an elaborate or aproximation - but your goal, to validate the model for real world application, is not possible.

logistical issues... Did you have to evacuate all server hardware into the inside of Edita from the storm ? Hope you all get home safely.

I don't have the answer, but if i would want to do it myself, i would look into ACE code to find how they did it

I did suggest no such thing. To heal you have to leave the vehicle. If you decide to risk doing that right in the line of fire, or if you retreat to safer position first is a decision the player has to take for himself. Also, most crew would abandon their vehicle if it gets penetrated and they get seriously injured... Because if the threat is not eliminated, the next penetrating shot will be only a question of time. A no brainer decision, when healing in arma takes 10 seconds at best. Executing animations while in crew served positions is impossible. Every crew and passenger position would also require custom animations for healing. Ludicrous suggestion. "Only one sitting animation..." No, there are several dozends of different sitting positions. Pointless, scripters can already heal and affect health of people inside vehicles since ages.

The animation of needle in your thigh is an aproximation and generalisation. If you get a penetrating chest wound from a shot or shrapnell going through the armor of a vehicle, what good does sticking a needle in your thigh does? Any damage that makes you consider healinging yourself in arma would be a pretty serious injury IRL. I agree with Beagle. Getting out of the vehicle is more believable. And it also forces people to exit the vehicle, instead of beeing all terminator, just because their vehicle has 50 first aid kits loaded and they immediately heal from any damage. It would be a different story for passenger seats in large 'transport rooms' like in a large cargo truck or transport helicopter.

There are no proximity rounds -> cannon have to directly hit the plane -> much lower hit ratio. In reality, with proximity fuses and AA rounds even near misses would damage the plane. There can be a discrepancy between visual model and the actual hit geometry and hitpoints too, they may lag behind the visual model, reducing hit chances. Special shaped charges (HEAT for anti tank and continuous rod ammo for AA usage) are not implemented. Indirect damage (from high strength explosions) is terribly overpowered. Missiles have larger area of hit, and high hit damage compared to cannon -> damages the entire planes systems in many cases, not just a single one. A Stinger IRL might hit an engine and the engine is toast, but the rest of the plane could be mostly fine. In Arma almost the entire plane gets damaged, but for balance it does not go down from this single hit.