Rydygier

OK, I have no big experience with GitHub, I find it confusing a bit, as I'm not a programmer, still attempted to create such a repository. Also attempted to make off limits "sound" Hetman sub-folder, as sound files in Hetman are provided by other community members, probably long time out of reach, so it's neither may work, niether I know exact usage limits, they would want for their input, hence sound files should be left as they are. https://github.com/Rydygier/HetmanWarStories/tree/main Not sure, if anyone would like to work on this, but here it is nevertheless.

In general I keep my Arma projects, HWS included, open source to anybody wanting to make any fair use of it, with "share alike" as the restriction and being thruthful about the original authorship as strong recommendation (APL-SA). Hence we have NR6 HAL Evolved for example.

Interesting, can you share more details, how exactly learning works here, what the exact principles are (if not the secret)?

I didn't review HAL code long enough to lose confidence what's what and where, but keeping that in mind: Rest orders can be issued due to several causes including: 1. Group's vehicle: no fuel, armed but no magazines, damage > 0.5, immobilized; 2. group members: total value of wounds and losses too high (threshold depends on commander's personality - recklesness), note, KIAs are counted by comparing the "initial count" (measured once, somewhere at init) with current units count. So any despawns/caching based on despawns are counted as losses too, which affects both group readiness check and the morale; 3. group's ammo reserve considered too low (complex calculation); 4. If HAL decides, the group is overwhelmed by near enemies (complex calculation), rest order may be issued as well as form of "tactical retreat". So, whatever is going on due to Alive or something else, it most likely triggers one of the above. Mods in type of Alive can mess with stuff sensitive for HAL, sadly. Personally I've no further plans for HWS (empty personal "todo"). To be honest - same applies to Arma scripting in general (no any personal projects planned, probably I'm just burned out/out of appealing ideas, or just (re)tired). But always feel free to write any particular wishes/requests or bug reports. Nothing can be promised, there may be nothing done about them easily, but who knows, maybe I'll be willing and able to do something, if easy/quick enough, depends on my RL situation and overall motivation, both are changing often these years. In any case at least I'll be informed, people would like to have something implemented. Oh, I see, HWS has already 10 years... How this even happened?

This also is a way. So you have some marker in RYD_SPR_RespawnPositions and then in some parallel loop you update it's position to make the player respawn somewhere around last position. Maybe like: [] spawn { _pos = getPosATL RYD_JR_Boat; _i = "respawnMark_" + (str _pos); _i = createMarker [_i,_pos]; _i setMarkerColor "colorBlack"; _i setMarkerShape "ICON"; _i setMarkerType "mil_dot"; _i setMarkerSize [0,0]; RYD_SPR_RespawnPositions = [_i]; while {true} do { sleep 30; _i setMarkerPos (player getPos [(75 + (random 75)),random 360]) }; }; But again, IMO there's serious risk, combining this respawn with Pilgrimage would somehow, at least partially, break Pilgrimage regardless of respawn position method.

There's large risk, it woulnd't work because reasons, but if you want to try, I recommend to [] spawn {}; whole thing at the very end of JRInit.sqf and add such a line: _newUnit = (group _killed) createUnit [(typeOf _killed),_respawnPos,[],0,"NONE"]; RYD_JR_Alex = _newUnit; But then also you need to figure a way to define respawn position/decide, where respawn should occur. At the boat? So initially: RYD_SPR_RespawnPositions = [RYD_JR_boat]; And at the hideout if it is set, so this: case (8) : {_center setVariable ["RYD_JR_Parking",_veh]}; into: case (8) : {_center setVariable ["RYD_JR_Parking",_veh];RYD_SPR_RespawnPositions = [_veh];}; And if you pack the hideout - the boat is set again. But there may be optionally multiple hideouts, so it is more complex - perhaps you should rather add new randomly piced spot to RYD_SPR_RespawnPositions each time new hideout is set, and remove this spot when it is packed, and if after that the array is empty - add the boat to it?

No idea, cDLC assets can have some extra functionalities scripted in... FFE for sure doesn't make any arty to move anywhere, but if target is revealed by some FO, this may trigger some attack/engage behavior perhaps?

Oh, that's an old code indeed. Simple thing, it seems. RydFFE_FO should include group names, not unit classes, quoting manual: As for the classes: So it works in a bit odd way, as you see...

Well, as the title suggest (stationary hovering position), it's for helicopters. Plane CAS would be quite different story.

Yup, sure, perfectly OK. Implement it, if you find it useful. 🙂

IIRC there's nothing in Hermes, that could trigger such behavior. In HAS everything is triggered on player's demand. I guess, there's many other possibilities outside HAS. To be sure, what's the cause, normal course of action is to disable part of used mods/scripts whatever and test with the rest etc. until you determine the culprit. To confirm or exclude HAS specifically, try and compare without HAS. And then also with HAS only, no other mods whatsoever - "vanilla repro".

Hello and welcome on BI Forums. 🙂 AFAIK/IIRC NoControl should be the way. Arty groups put there are simply not touched by FFE scripts. That means, those arty groups are operating in pure vanilla manner. If other mod fails to use them - likely the reason is not connected with FFE. Are you certain, the other mod works OK with same arty groups, if you don't use FFE? If not - try. Also be sure, you apply NoControl properly. Should include group names/groups and should be defined at scenario init. Yet another possibility may be some issue with artillery itself, especially if it is some custom arty from mods, in that case, test same scenario with mod arty replaced by vanilla arty. That much I can tell.

This. It simply can happen. There's no balancing mechanism ensuring, your forces are a match to your opponent. Numerically forces should be roughly adequate, but that's it. Think about it in this way: not every war story is about a fair fight and not all has a happy end so don't feel bad about loosing a battle, just immerse into another war story. A part of being a cog in war machine is, sometimes you'll be ground to ashes between bigger cogs.

No problem. 🙂 Of course, this can be applied to any map, simple changing folder's map name should do it, I believe.

Here's a small mission, where you have scripts to find both, holy sites and potential checkpoints positions. Each under mouse action for the convenience. Coords land into RPT and into the clipboard. https://drive.google.com/file/d/1vIqp297YM3U6qpVB6GaTftjyRjsTA4qp/view?usp=sharing In case of holy site search, you can try to find also other types of map objects by editing this line: _aID = player addAction ["<t color='#d0a900'>Find all map objects</t>", RYD_AllChurches,["CHURCH","CHAPEL"]]; With desired types as defined here: https://community.bistudio.com/wiki/nearestTerrainObjects Note, if the list of coords is very long, it may not be copied entirely into the clipboard - not sure... Also note, it searches per map markings type, not actual object class. User can disable this line: private _list = nearestTerrainObjects [_mapC,_categories,(_rds * 1.42)]; and instead enable this one: //_list = _mapC nearObjects ["Church",(_rds * 1.42)]; and use object (parent) class, he want to find.