Rydygier

On that, if anyone's interested... Tried was models 4o and 03-mini, I believe. Result was... poor. In rough shape it was resembling a neat, simple code, doing heli transport. But there was key problems in the aspect of the syntax (non-existent command used), logic structure (local variables used out of its scope) and design (oversimplification, it was possible to call heli while it was already busy, temporary mouse actions not cleaned up, special situations not handled, code oblivious to Arma's AI limitations and quirks). It was semi-working sketch at best. Probably GPT could do better with languages providing wider training data base.

The priority here was code simplicity, hence there are certain limitations, otherwise we would simply gradually re-create Hermes, that also started from something very simple. For example this script uses different way for reliable keeping the heli at/on the ground for touch down/landing (there's a bug in vanilla heli landings, when heli after the land takes off again and stays hovering). It is done via not available, while Hermes was created, alternative flyInHeight syntax enforcing chosen altitude in real time: _heli flyInHeight [0.5, true] As a result, heli immediately and pretty aggressively adjusts the altitude, even very low, and keeps it, which is cool, but apparently in the process heli doesn't pay attention to trees etc. Hence it is on the player to pick the LZ safely. findEmptyPosition is used, but it may not suffice in certain situations. Player/mission maker being responsible on having smokes/flares on the caller is another thing, that stays so in sake of simplicity. Unlimited calls is not the thing here also, but one could simply set very high limit to get practically same result. Alternatively, one could disable/remove this line: AI_SHT_extractionsUsed = AI_SHT_extractionsUsed + 1; And optionally to adjust info text here to fit better and avoid confusion: _text = if (AI_SHT_extractionsUsed < AI_SHT_extractionLimit) then { (format ["Helicopter has returned to base and is available for another extraction. %1 calls left",(AI_SHT_extractionLimit - AI_SHT_extractionsUsed)]) } else { "Helicopter has returned to base. No calls left" }; hint _text; For example reduce the above to something like: hint "Helicopter has returned to base and is ready for another call";

Gunther asked me to paste here the info about the new mission update on Steam Workshop - he is lately unable even to log in due to persisting technical problems of these forums. Update: Feb 24 @ 3:01am v1.4 ==== - Changed the intro. - Added two new player starting positions. - Adjusted some objects in buildings. - Removed some lamps that were preventing some lights to be seen. - Added another boat patrol. - Adjusted boat patrol markers. - Adjusted waypoint settings of foot patrols. - Added view distance parameter & script. - Updated skill script. - Updated description.ext code for the parameters. - Updated uniforms and gear of most units. - Added few triggers for tripwire flares. - Fixed task id issue for 2 tasks with same id. - Fixed code order of one of the tasks. - Added a new lookout camp with task. - Added 2 new tasks. - Added 2 beach patrols in two seperate locations. - Added three new locations with fog ambiance. - Added Helicopter transport for extraction. - Added exfiltrate task after all tasks were completed. - Added respawn ticket function. - Updated the briefing and replaced diary modules with a script.

Maybe try this way: 1. Find this line (25th in the original file): "_this in _originalTarget", 2. Turn it into: "((_this in _originalTarget) and {(primaryWeapon _originalTarget) isEqualTo 'CaseSensitiveSpecialRifleClass'})", It's action's visibility condition. So the action is visible, where 'CaseSensitiveSpecialRifleClass' is your special rifle class. So the switch action will be visible only, if certain weapon is held. But we need also to handle situation, when the Spectator mode is already switched on, and after that player changes weaponry. Thus: 3. Find this line (35th in original file): if not (isNil "RYD_PRC_Projectile") exitWith {}; 4. And add new line just below, so both would look like this: if not (isNil "RYD_PRC_Projectile") exitWith {}; if not ((_this select 1) isEqualTo "CaseSensitiveSpecialRifleClass") exitWith {}; After that there should be no spectator view if the weapon fired class is not the special one. In fact, points 3 and 4 suffice, if you don't mind Spectator mode switch action visible regardless, if player has that special rifle or not.

Well, that's the way. But if so, this must be done in the place of the code, where output is already determined (after the player confirms his GUI choices with a button). RYD_TakeValues seems the right place - it shows, how it is done for all the other dropdowns (paired with RYD_JR_Dialog). Also you don't need to nil a variable in order to define it with other value. Just define it with other value. I guess, you need to replace editor-placed Alex with spawned unit of desired side defining it as RYD_JR_Alex and selected as a new player unit... Unless would work simply to join Alex a newly created group of proper side, but to me it sounds messy. Anyways, good luck! 🙂

All right, please, test the code included in this version in your own scenario and see, if it helps. AI Medic Auto Heal 1.02 If the above fixes the problem, then @Gunter Severloh - we should update the thread with this version. The change: was: _wounded = _units select {((((getAllHitPointsDamage _x) select 2) findIf {_x > 0.1}) >= 0)}; is: _wounded = _units select { _damageArray = getAllHitPointsDamage _x; if ((count _damageArray) < 3) then { false } else { (((_damageArray select 2) findIf {_x > 0.1}) >= 0) }; }; If it doesn't help - then after all venilla repro would be required.

OK, zero divisor errors bound with "select" (Error position: <select 2) findIf {_x > 0.1}) >= 0)};) in my experience usually indicate, that the code tries to point via select a non-existent element of the array, so in this case - like the array is shorter, than 3 elements, while the code tries to take third element. But the array is produced by this command: https://community.bistudio.com/wiki/getAllHitPointsDamage And per description, it should always have 3 elements. So either it is not about that after all, either there's some abnormal output of this command regarding one of player's group units. Without proper vanilla (no mods/custom addons used/required whatsoever) repro mission, that I could personally test with extra logs, I can't say more nor propose any fix, as there's no clear indication, what could cause this error in the provided logs. So please, give a simple repro, that reproduces this error. EDIT: So this could explain the issue, array can be empty if for any reason units group player return null or no shape entity. I'll propose "blind fix" in that direction to be tested, if it helps, then that was likely it.

Nothing obvious coming to my mind by looking at this line. BTW in original script line 345 is: _val = (damage _x)/(_medicD max 1);, but init.sqf could be altered in this case. I can try to add some UAV and see, what happens, but IMO it rather shouldn't have any impact, as this script works on player's group. Best would be as simple, as possible, vanilla repro mission with clear steps to reproduce that error. EDIT: I added some west and east UAV teams and standalone UAV units to mu demo mission, there was no any errors. So repro is needed.

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! 🙂

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.