Jump to content
Bohemia Interactive Forums

Rydygier

Member
 View Profile  See their activity

  • Content Count

    4805

  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by Rydygier

  1. Posted

    So far my very scientific approach shown such mix being optimal of all tested as for preventing strawberry jelly syndrome:

      

    													{										
													_x setUnitCombatMode "YELLOW";//seems meaningless - group's combat mode is the one, that actually makes a change, it seems. Just picked one with "keep formation" to avoid potential "pursue" behaviors. 
													_x setCombatBehaviour "STEALTH";//no yelling, possibly bit less pointless aiming at known target through the walls (?). CARELESS loooks wierd in this mix (frequent looking at the target through the walls while weapon lowered looks silly)
													
													_x setUnitPos "UP";//essential, does what supposed
													
													_x disableAI "TARGET";//essential. Prevents sending group members with weird maneuver orders that overwrite doMove. 
													_x disableAI "COVER";//prevents interferences with "find cover" behaviors. Improives fluidness of movement - less weird stops or temporary moving towards "covers"
													_x disableAI "AUTOCOMBAT";//may prevent indivudal units changing set behavior to COMBAT, but seems unnecessary
													}
												foreach _units;
												
												_group setSpeedMode "FULL";//not sure, if makes any differfence, but may prevent interferences with occasional "return to formation" stuff
												_group setCombatMode "YELLOW";//probably anything but BLUE works samey. Just picked one with "keep formation" to avoid potential "pursue" behaviors. 
												_group setCombatBehaviour "STEALTH";//seems pointless, group's behavior turns COMBAT when enemy detected even, if this is set to CARELESS

    Tested scenario was target on the roof of the large building revealed with 4 to the hunting group being outside. Crucial: reveal must occur after above changes are applied. Otherwise there's no salvation. 

    Probably I'll try other scenarios, and if confirmed working aswell, that may be for actual 1.1 update even. 

  2. Posted

    4 hours ago, major-stiffy said:

    So how do I remove debugMode? Assuming you're done.

     

    In this line:

     

    [_x,0,-1,60,true] call RYD_CH_Herne;

     

    The last parameter, "true", is debug mode switch. Turn it off either by:

     

    [_x,0,-1,60,false] call RYD_CH_Herne;

     

    or just:

     

    [_x,0,-1,60] call RYD_CH_Herne;

     

    As this is false by default.

     

    11 hours ago, pierremgi said:

    I gave up a while ago, trying to optimize searching paths in buildings, just because AIs were mad in combat situation (some of them committed suicide, jumping from the tower).

    I'll have a look at AI group in careless but red mode.

     

    I started this endevour knowing, other was here before me. Still, I'm curious, how far I can push it before I stuck hopelessly. Not much time for it, but I guess, I'll experiment with various alchemical mixtures of behaviour, combat mode, maybe even disableAI and other.

  3. Posted

    Yup, looks like in my tests in general. Further improvement would require finding a reliable way to protect the AI from entering strawberry jelly mode if the prey is known in advance (as it happened also here once they finally find out, who is toying with them 🙂 ). 

     

    Currently in use:

     

                                                    _group setCombatMode "RED";
                                                    _group setCombatBehaviour "CARELESS";

    This is not very intuitive though, as group behaviour and group member's behavior aren't the same. Here second line sets careless for the group, but not to the group members. Similar with combat mode, I believe. There's still room for experiments but only by trial and error, since this stuff lacks coprehesive documentation, AFAIK (especially group setting versus group member setting comparison). 

    • Like 2

  4. Posted

    19 hours ago, Rydygier said:

    Perhaps one could somehow calculate intermediate navpoints to shorten the path to calculate...

     

    Of course, it is more complicated, than that. 

     

    In beta 5 I made quite a serious changes in order to fix/workaround/mitigate few problems encountered and it seems better now, but if hunters have full knowledge about you before they get to you from inside, results become very mixed/chaotic. Which sometimes generate quite interesting results, like some units trying to reach you from outside while other from inside. But sometimes it is just like half of a group stops to move somewhere inside while other half do that vanilla maneuver with running far from the building to get a clear shot from afar or sometimes they do who knows what frankly, just running back and forth around the building. The full knowledge about some near enemy turns AI's brain into strawberry jelly and so far I didn't find any reliable way to enforce my iron will upon that jelly. Anyway, enjoy the chaos:

     

    Herne 1.1 beta 5

    • Like 1
    • Haha 2

  5. Posted

    Looks like normal Arma AI behavior in such situation. They know all about you now (4), so they seek a position, from where can shoot at you.

    Seems, they fail to find a path (too long/complex - I saw it earlier, so this is likely) from where they are straight up to the roof where you are (purple arrow is on your position here - expected, when the knowledge is 4). In case of path finding fail they immediately become "unitReady" (movement considered "completed"), hence they take normal orders from their TL. 

     

    As long they do not know all about you, they do not try to reach you directly, but rather start the search from the bottom, where it is possible to calculate the path (shorter/less complex).

     

    In total, the result kind of makes sense. Since they know about you being exposed on the roof and can reach you from outside, they try to do so. 

    As for potential remedy - not sure, if effective one is possible. Since they know all about you, they shouldn't normally search the building in order to find you, but to engage you directly.  Perhaps one could somehow calculate intermediate navpoints to shorten the path to calculate...

    • Like 1

  7. Posted

    1 hour ago, Rydygier said:

    and AI pathfinding problems are... impactful there.

     

    But same building placed in EDEN out of the above context, but in the middle of Almyra salt lake is searched quite nicely. Much better. So it may be not about the building itself, rather whole surrounding context, or something particular about it, that could make path finding capricious. Interesting. Anyway, seems for strictly CQB scenarios, in case of such problems, recommended would be actually to use EDEN placed buildings, in the free, open areas?

     

    BTW used hide object modules to hide everything in the area, around and below, except the troublesome building itself - no change. But I know, hidden map objects sometimes stay an invisible, but physical obstacle (game bug). 

  8. Posted

    Testing with other vanilla building:

     

    Herne-Path-1.png

     

    and AI pathfinding problems are... impactful there. AI still enters the building and tries to move inside, but it seems way less enthusiastic about it, prone to stuck. Tendency to unitReady return true prematurely indicates fails on finding a path. 

     

    One should not assume, even vanilla buildings will work OK for AI. Some will while other not so much. It makes Herne in this regard quite unpredictable effect-wise, which is bad and good thing in the same time. 

    Now let's try, how changing the building in between the search works...

    ...

    Seems, it works OK, only debug arrows from previous building aren't cleared after building change. It's just debug, but perhaps this can be fixed. Also work equally well, when certain building is native part of the map and when it is placed in EDEN. 

    ...

    All right, arrows removal should be fixed in the next version.

  9. Posted

    On 5/7/2023 at 9:41 PM, major-stiffy said:

    No errors, looks good until I change buildings.

     

     

     

    If that scenario is vanilla, I could use it for some tests. Building change wasn't tested so far, also there may be some pathfinding problems. 

     

     


    Yes, the code itself doesn't differentiate aggression in any way. 

  11. Posted

    As a result: Herne 1.1 beta 3.

    Changes:

     

    - applied one fix to the logic (it was flawed);

    - integrated debug arrows and hintSilent as debug mode switched by the new, fourth parameter (false by default). The hint now refreshes only once per hunters orders update, so less frequent, and if multpile hunters groups are active, it will in practice monitor the last one with its prey (previous hunter group hints will be overwritten on screen by the last hint basically);

    - "only known" mode is now 1 by default (hunters follow prey unknown tho them, but will not enter the building if prey is not known), but in the demo mission this parameter is set as 0, same, as it was by default in beta 2. 

     

    As a side note, sadly, building search part rely on the proper building model and config, so it should be properly "searchable" by AI, which requires modelled interior, properly defined house positions and working path finding. The Livonian example above proves, even "official" buildings may be not up to that standard. Not much can be done about that. 

     

    That's all for now. 

    • Like 2

  13. Posted

    All right, apparently what I heard about Livonian buildings is true. I checked this building, it looks spacious, but that's mostly "a fake". Main body is not enterable, there's no interior modelled. The only house positions are located in two small rooms - the only enterable space, and on the external staircase. No positions on the roof BTW. This pic shows all the house positions and shows, how "interior" looks like:

     

    liv-1.png
     

    Still, they don't go up that stairs, I wonder, why...

     

  14. Posted

    I heard some stuff about Livonian buildings, but not sure, if related to this topic. Also curious if there's any difference for AI pathfinding for native terain building versus editor-placed one. Anyway, when I'll have some time, I'll run some tests using this one, may be informative as I see... I assume, they just are staying there around a single house position? And this is same building, not separate, small building?

  16. Posted

    This is not vanilla building, right? At this stage I would recommend to focus on vanilla buildings. Custom ones can cause all sort of AI path finding/house positions etc. issues depending, how are made and configured (errors, bad design, exotic ideas, technical incompletion, ported from older Arma titles, so not up to A3 standards...). So when you run a wip code on such a buildings and encounter problems - you don't know, if the problem is with the script or rather with the building. Once we're confident, Herne works reliably on vanilla assets, we may try it with modded buildings. Then we would know, encontered problems are most likely due to the building problems.

    If however the problems occur in the vanilla assets, we may assume, the script may need adjustements. Although even vanilla ones in theory can cause troubles on their end tbh. 

  18. Posted

    Yes, getPosATL takes the position over the terrain. It is already in use, once hunters have full knowledge about the player, they no longer search the building position after position (house positions also are ATL by the way), they rather all go directly towards the player. 

     

    But watch this footage, that's how Herne works now:

     

     

  19. Posted

    Yes. Also you can:

      

    call compile preprocessFileLineNumbers "Herne.sqf";

	{
	[_x,onlyKnown,distanceLimit,updateInterval] call RYD_CH_Herne;
	}
foreach [HuntingGroup1];

    But if you have only one hunting group, using foreach loop gives you nothing. With multiple groups it can save you some typing basically. 

    PS in the newest version onlyKnwon is still 0 by default, unlike 1.0, where it was 1. That means, in 1.1 beta 2, hunters will enter the building, where player is, even without any knowledge about the player's presence. 

    • Like 2

  22. Posted

    Yes, this part:

      

    [] spawn
	{
	while {alive player} do
		{
		sleep 0.1;
		
		hintSilent format ["Distance: %1m\nKnowledge: %2\nTime: %3s",(leader HuntingGroup1 distance  player) toFixed 0,(HuntingGroup1 knowsAbout player),time toFixed 0];
		};
	};

     

    Is only internal debug. 1.1 is wip, hence you have debug stuff here, also those purple arrows. So, you can delete this part. Or if you want to use this debug, instead of HuntingGroup1 you have to put an existing group, you have in the scenario. Only one. 

     

    Oh, BTW changed for now default setting, so now by default hunters will enter the building even, if player is not revealed to them. Easier to test. 

     

    • Like 2

  23. Posted

    The good news is, the above problem should be solved in the next version. Noted though, AIs directed via doMove into the building sometimes ignore that command, do not move at all and prematurely return unitReady true. Maybe it happens only, if they know about the enemy near, not sure. Anyways, that's pretty normal vanilla AI unreliability, if possible to workaround - we'll see...

     

    EDIT: actually not bound to known enemy presence. Possible cause: not possible to find a path to a certain house position. A sort of workaround, that seems to help, will be applied: seems, the path to a house position in case of stuck exist, but AI can't find it. So, if such stuck detected, instead AI gets doMove to the position in the half way between current position and the building itself. It looks like, when close enough, it may be able to find a path to the same house position, that was "unreachable" from the bigger distance. Therefore reducing the distance between the AI and the building may help. 

    • Like 1

  24. Posted

    Funny find. Because of this check:

     

    ((insideBuilding _prey) > 0)

     

    Hunters will NOT search the building, if player is on the roof. On the roof means outside the building in terms of insideBuilding command (no wonder, it is positive only, if "interior" sounds would applied to the unit by engine). So described yesterday complex check without insideBuilding usage may be the way after all...

  25. Posted

    Possible solution would be to gather all near buildings in quite wide radius around the player. Then for bounding box of each building to take its 2D horizontal plane on the ground (a top down rectangle shape of the building) and use inArea check to find out, if player is in the area of that bounding box plane. Although in some cases, say some L- or U-shaped buildings, player may be in the rectangle area of their bounding box while not truly inside, so https://community.bistudio.com/wiki/insideBuilding should be used too. Or some LOS-based "roof over head" check. 

     

    Maybe I'll use this, but it means, the code will be considerably heavier due to extra calculations. So only, if this prove to be a serious problem after all. Meanwhile Herne meant to be as simple, as possible...

    • Like 1
×