Rydygier

Herne 1.1 beta 2 Improved building search behavior (more fluid (1 sec. cycle intervals insted of 10 sec.), quicker, units doesn't try to return to the formation while waiting for another stage - "glued" to the current house position). Changes not tested at all outside this particular case, still wip.

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.

One day I decided to test my... "teaching skills" (not sure, if I have any though, beware...) and created a scripting tutorial for absolute beginners. There are some good sources in English, but seems hard to find something like that in Polish, hence Polish and English editions. Here it is: Polish: https://skryptysqf.blogspot.com English: https://sqfscripts.blogspot.com It's short, 4 chapters, still I tried to cover important basics of scripting craft (my way of practicing it at least). The main goal is to lower as much, as possible the entry treshold for those, who want to begin the adventure with Arma scripting, but have no clue, how to. Therefore this tutorial tries to provide also informations usually omitted, assumed as known/obvious. From my experience - nothing is obvious at the start, such assumptions, as I recall, was pobably the biggest obstacle for me. It is written from non-programmer perspective, without any programming experience assumed in the audience (I hope). Chapter 1 (PL/EN) explains preliminary topics like the role of the scripts in general, the sources of them, the basic way to use them in the game. Chapter 2 (PL/EN) focuses on the learning metodology, knowledge sources, basic terms and concepts required during the work. Chapter 3 (PL/EN) describes in detail a complete process of writing working SQF script example, from the bare concept description through the algorithm synopsis, collecting required commands, line-by-line walkthrough, syntax pitfalls... to the trial run footage. Chapter 4 (PL/EN) is all about the art of debugging (how I do it).

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.

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...

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...

The radius, I talk about is to search for the nearest building (the one, player is inside). There's a command (brand new in fact) to determine, if unit is inside a building or not, but it doesn't return a building. So although you could learn the bounding box, you obviously must to know the building already in order to do so. And once the building is known, you don't need any radius, as there's a command provided earlier, that would return ALL house positions in that building. So the problematic (sometimes) part is to find a building, in which the player hides. We have also: https://community.bistudio.com/wiki/nearestBuilding But it shares the same problem. Though I would say, wrongly chosen building should be rare enough to ignore/tolerate.

The ladder? The ladder, I saw there, leads to the roof. And you said, you was not on the roof. Is there any other ladder? I ask, because I need to test same situation in order to analyze and then maybe to fix. Still, if I'll have time and free mind, I intent to try work bit more on this, as there's still room for improvements. Seems this exact building may be a good reference, as it may be properly challenging. The issues to overcome: - currently the group moves cyclically from random house position to another house position. There's no consistency in building search. It's enough in small building, but if there's lots of positions and space to move, it may take ages for them to check everything with no warranty, it will even happen; - also, because of size of the building, AIs may be sometimes redirected to other position before they manage to reach previous one; - there's still the problem of vanilla AI, which I try to "tame" by certain behavior and combat mode, but AIs may still be sometimes not obedient anyway. Not sure, if/when I would try to improve this though.

Search radius is already 2D, height difference doesn't matter when the code searches for the houses nearest to the player. That's what the "true" here means: private _blds = nearestObjects [_prey, ["house"],30,true]; And when the house is found, all defined in that house positions should be included regardless of elevation: (_bld buildingPos -1)

Yes, no problem, except this: you do only once, no matter, how many hunters you plan to use later on. Keep this line in the initServer.sqf, execute it before you appoint any hunters (best just as it is in the demo, at the mission init). Then, whenever you want to appoint some hunting group, also mid-game, you can do it also without foreach loops: [zomgrp2] call RYD_CH_Herne; [smash2] call RYD_CH_Herne; [someOtherGroupName] call RYD_CH_Herne; Can be inside onAct trigger field.

Although never used vcom and do not know, what exactly it does an by what technical means, expected should be interferences with any AI mod, that tries to move AIs from place to place or manipulate its stance, behavior or combat mode. Simply imagine, what happens, when two different scripts tries to achieve two different things by manipulating in the same time the same unit... 🙂 Unless two AI mods are designed to work together or at least known to tolerate each other, universally good idea is to avoid mixing them. IMO best if hunter groups would be excluded from any other AI mod control, but of course feel free to experiment, who knows...

Was the building one of those? If so, the probable cause is this line: private _blds = nearestObjects [_prey, ["house"],10,true]; So the script looks for any house object in 2D radius of 10m around the player. But those searches are in relation to the ground level center of the building, not to any point of it. Hence, if building is large enough, there may be positions inside it, that are farther, than 10m from that center. So I went into that building and found positions at the edges, that are >11m away from the house center (distance in 2D). Result: no building to be searched found. So if you want, try such a change: private _blds = nearestObjects [_prey, ["house"],30,true]; If that's the cause, it should help (in my tests with me closer to the center, AIs entered the building and found me eventually). So, why the radius is so small? Well, If you're in some large building close to the external wall, and just behind this wall is other building, very small, that small building may be closer to you, than the one, you're in. That's not good. But since 10m proven to be too little for some buildings, we probably need to accept some risk of that sort. 30 meters hopefully should cover (almost?) all cases - tested on Altis airport terminal building. I wouldn't go wider even, if there are larger buildings. 30m is already risky.

Well, they should. If they don't do that in some case, there are various possible causes. If you provide vanilla repro - a mission, that doesn't require any mods or other scripts, where the problem occurs, there's a chance to determine, what's the exact cause and, if possible, to fix it.

1) No issues known to me - not tested but also not expected. It should work fine as long kept server side, along with affected AIs. 2) No. That would require quite different logic, more complex and hard to make reliably, I imagine. Covert following is out of scope here, probably also too specific for standalone script project.

The ones, Icewindo made to be used with my Rincewinder, Combat Effective Magick System? Also there was some melee script involved. Well, old days (I didn't run A2 since A3 appeared...) and some cool memories of working on those. 🙂 BTW Rincewinder was ported to A3, can be found on Steam Workshop. No true dragons though, only choppers pretending them... Still, here let's focus on Herne.

Probably (don't remeber for sure) loot boxes also are cached/decached. So that would be my guess. Maybe try on stable to compare? Mods can't change script commands syntax/break them (which seems the problem here). Dev branch is always risky to use for such reasons exactly.

Was it on A3 2.12 stable, or dev branch? On BIKI I see, they are adding some functionalities to addItemCargo command for 2.14, so perhaps it is broken temporarily in dev branch? Error says, array is encountyered, while string is expected. But this command definitelly takes an array. But also - this line exactly is not from loot spawn, it is from vehicle decaching code. And it looks like this: case (2) : {_vh addItemCargo [_stuff,_am]} So there's _stuff in my version, not stuff. Why there's no underscore in that log, I wonder?

If there are many players, each hunting group goes after the closest one (to the hunting group's leader). Depending on settings, ignored may be (or not) players unknown to given hunting group. Another optional limitation is certain distance limit, but it is disabled by default. Yet another option to exclude some player from being hunted is marking him like this on the server: somePlayerUnitName setVariable ["RYD_CH_Protected",true]; or anywhere: somePlayerUnitName setVariable ["RYD_CH_Protected",true,true];

Hi. 🙂 If so, you may like also this: https://steamcommunity.com/sharedfiles/filedetails/?id=310586623 It is, what you described. Two AI-controlled sides fighting each other, player is but a small cog in the machine. BTW AI is controlled by same script used also here, in Ragnarok, namely Hetman. It is not RTS though, so it lacks base building, economy, producing units... It's just a plain battle over randomized territory. There exist numerous ports to other maps/mods, not sure, if there's any WW2 though.

I wonder, if anyone knows this:

Hi. Happy to hear, you like the mission. It is based on Modkalb's WOO scenario, so he is the primary recipient of kudos. 🙂 WOO was adopted to WW2, modified here and there and equipped with complete AI opponent logic. About scrolling, direct code editing is required: In MBG_WOO_F_InterfaceControl.sqf found line 320 looking like this: _step = (sqrt (MBG_WOO_Main_cam distance MBG_WOO_Main_cam_Center_POS))/3; I believe, that's the place. Not sure, because it was years since I worked on this code. Change 3 with some lower, yet positive value and test until it's OK for you. Also, note, there's scrolling limitation in flexible way preventing player from moving the camera too far from any own asset (fog of war of sort). As for factory list, no super easy way other than editing proper arrays. IIRC, again, it will be in MBG_WOO_F_unitConfig.sqf: MBG_WOO_WEST_TANKFACTORY_Sales = ["MBG_WOO_WEST_1_AAV","MBG_WOO_WEST_1_LAV25","MBG_WOO_WEST_1_LAV25B","MBG_WOO_WEST_1_M1A1","MBG_WOO_WEST_1_M1A2"]; Entries here have misleading names inherited from initial WOO scenario, but you can add new ones (I hope...) or edit existing ones, each is defined in the same file like this for example: MBG_WOO_WEST_1_AAV = [[160,600,130,"StuG III","b_armor","GUI\Buttons\StugIII.paa",0.5,3],["LIB_GER_tank_crew","LIB_GER_tank_crew","LIB_GER_tank_crew"],"LIB_StuG_III_G"]; At the moment not really sure about numeric values, I would need to dive deeper to check them, probably first ones are cost of production etc. while 0.5,3 may be consumption? Just experiment with them and compare results. Other entries are for the map icon, interface button, the crew, and lastly the vehicle classname itself. So, as we see here, "AAV" is a StuG III G in fact.

Sorry, I saw those answers only now. So I see your pic, but, as shown, I was unable to replicate this issue with the very same mission, you gave me (run via EDEN on Arma 3 2.10 stable, no any mods), so it is nothing with the mission itself, if the exactly same mission works on my PC and does not work on yours. HWS doesn't save anything, that would be necessary to run it. If I can't replicate the problem, I'm unable to determine the cause and apply a fix.

I downloaded this scenario. I ran Arma 3 pure vanilla, obviously 2.10 stable branch. At first it was impossible even to load it in EDEN, there was loading error message, no RPT log about it. Then I removed spaces from the mission folder name and at second try it loaded properly. So I did preview and all seems normal: Later, after loading screen, there's one script error, but apparently nothing directly preventing from playing. I would say - a share of such errors would be expected, when you mix NR6 with HWS like this... Namely: 16:44:30 Error in expression <Dvs = []; for "_i" from 1 to _amnt do { _rDiv = []; for "_j" from 0 to _recAm d> 16:44:30 Error position: < _rDiv = []; for "_j" from 0 to _recAm d> 16:44:30 Error Missing } it is not the error, you saw. After that I was properly "incarnated" into some soldier and gameplay started as usual. Didn't test longer. As for that error, it seems harmless, it comes from HQOrdersEast.sqf, never finished alternative combat doctrine, which isn't used by default, but it is compiled, apparently the error pops up at compiling. The cause seems to be in line 74: _attackAv = _attackAv - ["Del]; should be: _attackAv = _attackAv - ["Del"]; But there may be more errors later in this file, still doesn't really matter, as this code is unused. What can I say, once I repaired mission folder by removing spaces, all the rest is working fine at least till the gameplay start.

All right, that's your culprit: 19:19:57 Error in expression <rlFill),[_newIx,_name,toLower _fac]]; } foreach _factions; _newIx = lbAdd [_ctr> 19:19:57 Error position: <foreach _factions; _newIx = lbAdd [_ctr> 19:19:57 Error foreach: Type Bool, expected Array,HashMap 19:19:57 File steam\__cur_sp.altis\init.sqf..., line 833 _factions somehow is not an array. This var is defined this way: _factions = switch (_ix) do { case (RYD_ix_SideA_B) : {RYD_WS_B_Factions}; case (RYD_ix_SideB_B) : {RYD_WS_B_Factions}; case (RYD_ix_SideA_I) : {RYD_WS_I_Factions}; case (RYD_ix_SideB_I) : {RYD_WS_I_Factions}; case (RYD_ix_SideA_O) : {RYD_WS_O_Factions}; case (RYD_ix_SideB_O) : {RYD_WS_O_Factions}; }; Probably something is wrong with one of these faction lists: RYD_WS_B_Factions etc. If you don't see, what exactly, just give me your HWS scenario as open folder, so I could test it quickly in EDEN.

I'm not familiar with ACE arsenal, but you have this: //RYD_HAS_SupplyDrop_Prepared = [];//holds optional prepared boxes as supply to be dropped, that will be used before default, spawned boxes So you can pre-place some supply boxes, configure in EDEN whatever you need, put their names into RYD_HAS_SupplyDrop_Prepared array and those should be used by helis. Example: RYD_HAS_SupplyDrop_Prepared = [Box1,Box2,Box3];