Rydygier

An advice, if you wish to experiment more with side swapping in the future, you may consider to: 1. at the very beginning of init.sqf define three global variables, for example in the vanilla version: RYD_JR_AlexSide = west; RYD_JR_HostileSideA = resistance; RYD_JR_HostileSideB = east; 2. Find and replace instances of west -> RYD_JR_AlexSide, resistance -> RYD_JR_HostileSideA, east -> RYD_JR_HostileSideB. But do it by hand, not via mass find&replace, as there will be exceptions, that should stay untouched, like compass direction names (west), marker colors bound to sides, such words inside various texts/strings... If done properly, changing Alex side and hostile sides will be then all about changing those three lines. For example: RYD_JR_AlexSide = resistance; RYD_JR_HostileSideA = west; RYD_JR_HostileSideB = east; Still, unit/object classes native to certain side to be changed separatelly. So anyone willing to try should consider, if it's worthy of effort for him.

Primary function of KIA are those marks, but later I added to it also Alex reputation change related to kills. In the Killedmark.sqf the code starting from: if ((_this select 1) in [player,vehicle player]) then { relates to reputation gained or lost due to kills. Side of killed unit matters. In this array: [civilian,west] there should be civilian side and Alex's own side to make "friendly fire" losses check. So if west side is now enemy and Alex is of resistance side, it should be [civilian,resistance]. BTW I recommend to do a mass search across all the files for words west and resistance to see, where else side swap would make a difference. For example, we have RYD_JR_BigCamp function in JR_fnc.sqf. There are spawned recruitable POWs. In vanilla they are of west side of course, so the change is needed also here: _gp = createGroup west; and may be a good idea also to change accordingly POW classes in JRInit.sqf: RYD_JR_CaptivesClasses = ["B_G_medic_F","B_G_engineer_F"]; as those are natively BLUFOR. and revealMine side: if not (RYD_JR_ACIntense > 0) then { resistance revealMine _mine; }; to west. also the checkpoint function: RYD_JR_CPSetup if (_side == resistance) then { _staticW = ["I_HMG_01_high_F","I_GMG_01_high_F"]; }; and _camo = "CamoNet_OPFOR_open_F"; if (_side == resistance) then { _camo = "CamoNet_INDP_open_F" }; should be turned into west and according classes. RYD_JR_Sherwood function (hidden camps): if (isNull _gp) then { _gp = createGroup resistance; }; resistance -> west. and according classes in the RYD_JR_CampStuff array (JRInit.sqf) RYD_JR_Warmonger (ambient combat function): _sides = [resistance,east]; Here should be both sides hostile to Alex. And here: switch (true) do { case (_rnd > 98) : { switch (_side) do { case (resistance) : {_gps = RYD_JR_AllArmGroupsI;_gpKind = "arm"}; case (east) : {_gps = RYD_JR_AllArmGroupsE;_gpKind = "arm"}; } }; case (_rnd > 90) : { switch (_side) do { case (resistance) : {_gps = RYD_JR_AllMechGroupsI;_gpKind = "mech"}; case (east) : {_gps = RYD_JR_AllMechGroupsE;_gpKind = "mech"}; } }; case (_rnd > 75) : { switch (_side) do { case (resistance) : {_gps = RYD_JR_AllMotGroupsI;_gpKind = "mot"}; case (east) : {_gps = RYD_JR_AllMotGroupsE;_gpKind = "mot"}; } } }; RYD_JR_AllArmGroupsI etc should hold hostile groups of proper side. Same as RYD_JR_AllLocalGroups = etc. but I guess, those are handled already? Problematic may be RYD_JR_AllFIAGroups = , an array supposed to hold possible to spawn in AC allied with Alex partisan groups of FIA faction. But those must be same side, as Alex. There's more across JRInit.sqf: _sides = [east,resistance]; also: switch (side _x) do { case (east) : {RYD_JR_East pushBack _x}; case (resistance) : {RYD_JR_Resistance pushBack _x}; }; and few other in type of _side = resistance;. At the very beginning of vanilla init.sqf wehave also whole setFriend stuff: west setFriend [resistance, 0]; resistance setFriend [west, 0]; east setFriend [resistance, 1]; resistance setFriend [east, 1]; //west setFriend [sideEnemy, 0]; //east setFriend [sideEnemy, 0]; //resistance setFriend [sideEnemy, 0]; civilian setFriend [west,1]; west setFriend [civilian,1]; //west setFriend [sideFriendly, 1]; //east setFriend [sideFriendly, 1]; //resistance setFriend [sideFriendly, 1]; //civilian setFriend [sideFriendly,1]; Recommended to ensure, all is right here. and lower, same file: if (RYD_JR_ACIntense > 0) then { east setFriend [resistance, 0]; resistance setFriend [east, 0]; }; Ambient combat. If both sides hostile to Alex should fight with each other, both must be properly used here, so for example west instead of resistance, if Alex is resistance. Then AddKMark.sqf: if not ((side _x) in [west]) then into: if not ((side _x) in [resistance]) then also in decoy.sqf: if ((_side in [east,resistance]) and {_delRisk > 0}) then { [east,resistance] - this should hold sides hostile to Alex's side. Mainloop.sqf, code for hacked "mad stomper", two times: if ((side _x) in [east,resistance]) then//hostile sides here { RYD_AS_Targets pushBack _x } Finally, about civilians attacking Alex despite good reputation. Thing is, if Alex has high reputation, sometimes should spawn an armed civilian as an ally. So same side, as Alex. In vanilla that's west. Hence spawned are west side armed civilians. SCA_fnc.sqf: if (RYD_SCA_HostileToSpawn > 0) then { _side = resistance; if (RYD_SCA_FriendlyToSpawn > 0) then { _side = west; So if now Alex is of resistance side, those two should be swapped like this: if (RYD_SCA_HostileToSpawn > 0) then { _side = west;//or east... if (RYD_SCA_FriendlyToSpawn > 0) then { _side = resistance;

Great! Let's wait and see then. 🙂 Clear now, thanks!

Hello @Atlas01Actual. 🙂 Thanks for the kind words! I'm happy, HWS still brings some fun to the people. I'm hardly MP scripting specialist, but at least I could try to put some thought into this... So, I guess for MP there must be initially placed as many playayble units on the map, as many slots is wanted to be available. Hetman itself can run on dedi, it's just server-side script. Not sure about possible issues with HC setup though. Well, that would mean, the initial options GUI must be moved to one of the clients. Also probably initial camera flyover is impractical in MP (being for only one of the players to watch or none whatsoever if left on dedi side; it's just a gimmick anyway). Probably in the very same place in the code, where SP player is put in the shoes on a randomly picked unit: 2133: selectPlayer _player; (init.sqf) should be added the code to handle all the player-controlled slots in similar fashion, provided, it will work OK MP. Now, as lobby MP parameter or another option for the initial options GUI there may be a switch, if all the players should get their units at random, or rather should be found a group, that includes enough members and all the players would land there. So, there should be also added a custom respawn behavior, putting fallen player into another unit, right? ...and also a mechanism, that would keep all the players together, if any of them decide to team switch... And to respawn in the vehicle, they died in? That last one sounds bit weird. Not sure, if I understood this one. Well, aside the last thing, I probably misunderstood, I could at least to think and try. If I manage to achieve anything of the above, I let you know, but no promises, no idea, if or when it may happen. For now, I must to sort some issues with my A3, which was misbehaving recenty. Anyways, Happy 2025, guys! 🙂

Tested briefly. A simple way to hop into a dynamic fun, which indicates a good battle generator IMO. Initial settings do the job well in quite simplistic manner, which is perfectly fine. So I become a simple BLUFOR TL in the town center, the HQ tossed our team back a forth a bit with waypoints (could help to have some kind of indicator, the new waypoint pop-up, be it radio chatter sound or just on screen info). Soon the town defenders, we included, became flanked by two Marids from opposite directions with nothing serious against them in terms of vehicles (though my situational awareness was very limited, as should be in sake of immersion, so who knows, what was at our disposal). Anyway, luckilly for us I found a dead comrade - AT specialist, so I took his Titan and backpack, then I was able to destroy both Marids within one minute, because they politely presented themselves to me. So, seeing in my mind's eye the medals for heroism already flying towards me (BTW possibly cool idea for debriefing - to list gained awards/decorations/medals assuming, player's deeds was heroic enough, but that would require a heroism detector algorithm), I paused the game and went to vacuum the apartment. When I returned and unpaused the game I fell dead immediately. Apparently the bullet with my name inscribed on it was already in the air, when I paused the game... Oh, well, post mortem medals then. I could team switch, but decided, such a finale is too perfect to ignore it, so that was the end. Anyway, looks like it may be an interesting alternative for my HWS or any other battle generator, especially, if it does things in its own, distinct way. Having brand new HQ brain behind it makes it even more exciting. Also, it was like a decade ago, but I still rememeber the thrill of creating this sort of stuff, more rewarding than playing the game actually, I hope, it's similar adventure for you, so truly - congrats on the project and good luck!

As for me - sure, you have my permisson. Good luck. 🙂

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?