Jump to content
Bohemia Interactive Forums

suma

BI Developer
 View Profile  See their activity

  • Content Count

    3202

  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by suma

  1. Posted · Edited by Suma

    I am contemplating removing the "hard formation" support to clean the formation handling code a bit for further fixes and improvements.

    Before I do remove it, I want to verify there is not someone out there using the hard formations, who would badly miss them.

    This feature is never used by default, unless a script is specifically reqesting for it. To use "hard formation" one has to call one of the following:

    "AwareFormationSoft" enableAIFeature false

    "CombatFormationSoft" enableAIFeature false

    If you do use this commands, please, post a comment what you use it for.

  2. Posted

    So in other words: the driver didn't recieve an explicit command, he isn't responsible for anything, thus he is unitReady all the time. There is no command for him to complete. Right? Really?

    The gunner/commander of said vehicle told him (implicitly) to drive somewhere. Sure, it's no explicit or official command to him, but shouldn't this count as command nevertheless?

    I understand your view has sense and it could be implemented this way. However what I describe is how it works under the hood (the inner workings of the AI). I will attempt to go into more detail: When you are a group commander and there is a tank in your group, you can notice any commands you might attempt to give to the tank driver are translated into commands to the tank commander. This is because the driver is not able to take any commands. In this sense the driver is not a unit, he is not included in the group commanding structure at all. The driver is "directed" by the tank commander. Those directions are not "commands" in the same sense as normal group commands (you can notice they are not confirmed in any way and no completion is ever reported for them). Asking vehicle crew other than commander about their "ready" status is something we did not expect, did not define and it could return anything.

  3. Posted

    Following scenario: a vehicle with a driver and a gunner (any jeep with mg for example) are beeing given a MOVE waypoint. What happens now is that the gunner(!) is _not_ unitReady, while the driver(!) is unitReady. Why?

    It depends on vehicle, but for most vehicles this is OK. The gunner is the commander of the vehicle and the gunner is given the command (he then direct the driver what to do to have the command completed). The driver is not "unit" at all and asking him unitReady has no sense.

  4. Posted · Edited by Suma

    And no, I don't think BIS supports the community to the best of it's ability. Once again, this is my opinion.

    Of course we do not, but this is a kind of tautology. There is hardly any limit to the amount of support we could provide. We could focus all our efforts (all programmers, designers, artists) only to fixing bugs and polishing Arma 2 or Operation Arrowhead. However, we obviously do not do this, as we are convinced this would kill the company quite quickly (and as a result, there would be no support for the community at all quite soon). We provide a level of support which we think is sustainable long term.

    ---------- Post added at 16:45 ---------- Previous post was at 16:36 ----------

    Correct me if I am wrong but probably in WW2 some soldiers had to swim ashore due to their landing craft dropping them off to far from the shore due to the tide/fog of war.

    You may be referring to something different, but in those cases the craft has dropped soldiers to far from the shore by mistake / accident / because of adverse landing conditions, esp. on the Omaha beach, the fate of those soldiers was a lot sadder. Most of them have drowned, because the gear they had for invasion was so heavy that it made swimming completely out of question.

  5. Posted

    As far as I remember, all OFP content was upgraded to Resistance standarts. And we hadn't any problem with vanilla units having different capabilities depending on when they were implemented to the game. So why do we have such problem now? Laziness? Indifference to the community? Something else?

    Something has changed meanwhile. Content creation (or adaption cost) has raised a lot. The unit models are a lot more complex, even unit configs are a lot more complex. Moreover, OFP:R was an expansion (you could not run it without OFP), while OA is a standalone expansion (you do not need A2 to run it).

    And one more thing: as it is still possible there will be some update for A2, we cannot simply upgrade the A2 content, as A2 engine would not work with it, not understanding the new features, we would have to "branch: it first and basically have two distributions of it, one for A2, another for OA. Considering OA does not include A2 content, being standalone expansion, this leads to a distribution matrix close to nightmare.

  6. Posted

    My suggestion is to teach the AI the concept of picking a nearby object (rock, tree, building, wall) and putting it between themselves and a given threat. Make this sort of logic the basis of the Find Cover command, while leaving the extant behavior in place.

    This is exactly how it works now. However, it is a bit harder. First, you cannot only pick an object, you need to select one particular location. Second, the location you select needs to fulfill some criteria:

    - it must provide a cover (or at least concealment) from danger

    - it must be free of obstacles (the soldier must be able to stand there)

    - it must not be occupied (two soldiers cannot use the same corner)

    - it must reachable from current units position

    - (optional, bonus) gives you firing opportunity at the target

    - (optional, bonus) it is far from the route to the waypoint

    Esp. the reachability is what makes it complicated. This means the cover selection needs to be connected to path planning (or use path planning to verify its selection). Path planning is quite costly operation.

  7. Posted

    I am not exactly sure when the issue got worse, but few betas back (could be in older 1.56 version) the helipads could be much closer to the trees. Now you need to be really carefull where to place the landing spots. Overally it looks like before the landing required only small clear zone (like 20m radius) around the helipad. Now its multiplied at least 2-4 times as big.

    Most likely introduced in 73339.

    Now fixed in 77157

  8. Posted

    After playing more this beta. I spotted few flaws - when AI chopper lands it makes first a fast manoveur down closer to ground. While in that state, it may hit into trees very easily.

    `

    While I think I can see the problem, when testing with older version I can see the same behaviour in 73346. Do you have some repro which manifests the bug in 77007 but not in some older version?

  9. Posted

    Gnat;1827997']Similar to metalcraze comments' date=' the AI pilots don't seem to be doing anything differently, except;

    - They tend to do a lot more "dry runs". ie An attack run, but no bomb drop or missile launch.

    - They now at times do a huge grab for air / pitch up, then almost straight away do a steep dive. Seems to happen around actual ammo launch.

    The main problem is all AI pilots nose-down to attack their target, even if the weapon doesn't require nose down.[/quote']

    Please, provide an update repro for this in the http://dev-heaven.net/issues/16219#change-81135 so that I can check it.

    I am sorry, I am unable to provide technical details, the fix is based on many minor fixed and adjustments and the description would be too long. If you will provide an accurate feedback including repro steps how to see what you do not like this time, I will revisit the issue.

  11. Posted

    With HD4870x2 (2 x 1GB RAM), the game still sets local VRAM to 2GB by default for me, too. I get improved performance by switching it to 1GB manually and write-protecting the .cfg file.

    This is most likely placebo. The VRAM entries of the .cfg files are write only. If you make the file read only, you only prevent the game to output the detected values, but you will not force it to use the values you have provided.

  13. Posted

    Hey Suma, you can just test it with my Mission "MountainWarriors".

    There are 2 HMV´s in the US Outpost, short after you started the mission your team will engage the vehicles. You dont have to play long, just 1 minute or so. Im pretty sure this has something to do with the distance to the targets, since it will not happen later on the ambush part, where you are close to some HMV´s. The strange thing was, that even if the gunners where killed and the HMV´s where unassigned, a bit later the target was assigned again sometimes. Thanks for looking into it!

    http://www.armaholic.com/page.php?id=12805

    What I have seen was the HMVs were considered targets as long as they had any crew alive, including driver. Once even the driver was killed, they were unassigned to me.

    That said, your mission features many units and it is hard to be sure I have seen exactly what you have seen. A small and isolated repro would be needed if we are to make any more progress.

  14. Posted

    Myne still detects this with 2 x gtx285 1gb SLI and 8GB of ram. Windows 7 64bit

    localVRAM=1046151168;
nonlocalVRAM=2147483647;

    I am now wondering if maybe I should set it to 

    localVRAM=2147483647;
nonlocalVRAM=8589934592;

    The 1 GB is correct. In the SLI setup you cannot sum the memory, as all resources need to replicated to both GPUs.

    As for 2 GB vs 8 GB, yes, this is incorrect, but this is given by the fact we do all computations in 32b and the value is clamped to 2^31 to prevent overflows. In the end this should not matter much, as non-local VRAM usage is kept low anyway.

  15. Posted

    The HMV was empty, only the gunner, because in both empty HMVs gunners were put manually with moveinGunner. Il have a video with current patch uploaded tomorrow...Still its allready very clear to see in the video

    Please, attach repro mission here or create a ticker on the CIT with a repro.

    I have tried a simple repro using moveinGunner, but no matter what I did, AI has always stopped firing once gunner was dead.

  16. Posted

    But benchmarks show, even with the latest and most powerfull cards, the fps will often drop to 20, or even lower, in some areas of the gameworld, or with too much units fighting. If i look at the benchmarks now, i would believe i need a very expensive GTX580 for my 20 fps minimum ? :eek:

    While I cannot tell for sure, without knowing what kinds of scenes you mean, it is very likely the scenes where you see drops under 20 fps are CPU limited, not GPU.

    The scenes which are likely to be CPU limited are scenes with a lot of moving units (a lot of simulation or decision making code performed on the CPU) or a lot of fighting units (a lot of AI on the CPU).

    If you want to be sure, reduce your 3D rendering resolution temporarily to an extreme (50 %) in the Video options. If the fps in those scenes will not grow, you are most likely CPU limited.

  17. Posted

    Is it possible to get some kind of comment/explanation/insight in what the problem was with the bobbing helicopters?

    The problem was with with acceleration in a combination with terrain avoidance. When heli is flying under its assigned altitude, it limits its dive. The intent of this is to raise a nose once hill appears in front of a heli. The bug with acceleration was the heli tried to accelerate too much in high speeds, which resulted in losing altitude fast, trigerring the terrain avoidance.

    The fix is that now the AI is not even attempting to dive that much when flying fast, therefore the acceleration is smooth, without losing altitude.

  18. Posted

    I can confirm, that it doesn't matter which exThreads i use, i don't have the performance like on 1.54..

    and that makes me angry

    fyi, i have E8500 and it was great on 1.54 ..since texture popping, things are only screwed up...

    I am sorry for this and I will do my best to identify the issue. That said, things like this are often hard to solve. Often a seemingly innocent chance causes unexpected results in rare situations. While 1.55 was definitely a lot worse than 1.54 on many systems, so far I was unable to reproduce this issue with 1.56, which makes solving it a lot harder.

  20. Posted · Edited by Suma
    typo

    ArmA 2 can use up to 31 cores in theory, but experiments have shown that with most scenes the gain above 4 cores is small and above 8 cores unmeasurable.

    The explanation is Amdahl's law - only parts of the application is using all cores. See Real Virtuality Going Multicore blog.

    ---------- Post added at 13:58 ---------- Previous post was at 13:54 ----------

    In build 76122 and newer the default for dualcores will be changed to -exThreads=3 based on user feedback.

    We have also changed the cpu core detection, therefore depending on how many logical cpus are present, default -cpuCount values will be as follows:

    1 1

    ...

    6 6

    7 7

    8 4

    9 4

    10 5

    11 5

    12 6

    13 6

    14 7

    ....

    Some day hopefully we will find a time to provide a proper HT detection, but until then I think the above provides quite reasonable default settings.

  22. Posted

    get a massive dump in my rpt file. Says

    Buffer to small - nowhere to write the data

    game locks but not my system. Have to go to task manager to kill game.

    When I back date the beta, message goes away. I have plenty of disk space.

    This is the size of the internal buffer used for scene management. Can you post here your settings (view distance, object detail) and what world / which location shows the problem for you?

  23. Posted

    and a really weird looking one:

    Received 181, expected bool (number might vary, not sure what it is)

    Unexpected message data (message struct NetworkMessageWaypoint, item visible)

    Before (0x0000003f): 75 65 00 00 00 00 00 74 72 75 65 00 24 4e 4f 4e 45 24 00 00 00 00 24 4e 4f 4e 45 24 00 00 00 00

    Current (0x0000005f): b5

    Thanks for reporting this. There is missing initialization for a newly added variable determining waypoint UI visibility. Will be fixed in 74881 - as a result of the bug, sometimes you may be unable to see the waypoint which you should see.

  24. Posted · Edited by Suma
    Typo

    The main version number for this beta patch was updated to 1.55 (instead of 1.54).

    So you are not able to play on 1.54 servers with this patch anymore.

    This incompatibility is required because of following fix:

    Audibility of the VoN direct channel and conversations are now based on the player camera position, instead of the unit position.

    This fix causes old and new version using completely different mechanism how player position is transferred, therefore old and new clients/servers cannot be mixed together. Hopefully it will not take too much long before we release a stable 1.55 to unite the MP community again.

×