Harzach

You are missing CBA_A3, though you should have been warned that it is a dependency when you subscribed to Massi's mod.

That's the thing, the client is the GFN server, I'm pretty sure that there's no .rpt on his PC because Arma isn't installed there.

I don't use GFN, so I don't know how that part of it works. And I guess you don't have a .rpt file to check since it would be on the GFN server. At this point it's not clear to me with whom the "blame" lies - Arma, Steam, GFN, the game servers you are trying to join...

In other words, not on the Workshop. But we don't know what servers you are trying to join, so it is impossible to say. *edit* - my mistake, I can see the DayZ server you are trying to join in the screenshot you linked above. According to their Battlemetrics page, all required addons are from Steam Workshop, so that's not the issue. Assuming you are indeed subscribed to all of those mods, understand that every time you join the server (or at least, every instance you run in Geforce Now), all of those mods must be downloaded to the GFN server. This might explain why you are hanging on the load screen - your mods are downloading (and that server requires over 20GB of mods).

From what I understand, Geforce Now only supports mods from the Steam Workshop. Not sure if this applies to your situation, but the game modes you mention often use privately hosted mod collections.

Should that not be a backslash?

Woke up wanting to play around with this a bit: HARZ_disable_gps = [] spawn { waitUntil {!isNull (uiNamespace getVariable ["RscCustomInfoMiniMap", displayNull])}; disableSerialization; private _display = uiNamespace getVariable ["RscCustomInfoMiniMap", displayNull]; private _miniMapControlGroup = _display displayCtrl 13301; private _miniMap = _miniMapControlGroup controlsGroupCtrl 101; HARZ_warn = _miniMap ctrlAddEventHandler ["Draw", { (_this select 0) drawIcon [ "\A3\ui_f\data\map\Markers\Military\warning_ca.paa", [1,0,0,1], getPos player, 50, 50, 0 ] }]; HARZ_cover = _miniMap ctrlAddEventHandler ["Draw", { (_this select 0) drawRectangle [ getPos player, 1000, 1000, 0, [0,0,0,1], "#(rgb,8,8,3)color(0,0,0,1)" ] }]; }; h To re-enable GPS: if ((!isNil "HARZ_disable_gps")) then { private _display = uiNamespace getVariable ["RscCustomInfoMiniMap", displayNull]; private _miniMapControlGroup = _display displayCtrl 13301; private _miniMap = _miniMapControlGroup controlsGroupCtrl 101; _miniMap ctrlRemoveEventHandler ["Draw", HARZ_cover]; _miniMap ctrlRemoveEventHandler ["Draw", HARZ_warn]; }; It seems to work, but I did minimal testing in SP, and all code is just copy/paste/replace/mash-up of code by users in the topic linked above, as well as others, so who knows what I'm getting wrong. Any and all corrections/clean-ups are welcomed!

Discussion and solution to drawing on the GPS panel here: Now, how to use this information to achieve what you are asking... Maybe draw an opaque black rectangle over the visible area (or the whole control) then some icon on top of that, like an exclamation mark? I don't know if it's possible to cover the control with an image this way, which would be ideal, because it could say whatever you want ("Unable to connect", etc.) Working with controls are well outside my wheelhouse, though.

Here's a simple-ish way to do it: Place an APERS tripwire mine and give it a variable name (I'll use "trip1"), DISABLE SIMULATION Place a trigger - Rectangular 1 x 1.5 (this creates a 2 x 3 trigger area) Anyone (or whatever you prefer) non-repeatable OnAct: null = "SmokeShellRed" createVehicle (trip1 getRelPos [1.5,270]); deleteVehicle trip1; The APERS tripwire is 3 meters wide, so the trigger fits right inside. The trigger is 2 meters "long" to make sure that it activates if someone runs through it (triggers evaluate every .5 seconds, and even though now you can change this value, having many triggers that evaluate at a high frequency may impact performance, depending on certain factors.) If you can definitely predict the direction of travel of the "tripper," you might want to offset the trigger so that the majority of it is behind the wire (first picture), other wise just center it (second picture).

I mean, I don't know how a negative value could slip in there as neither the command nor the function are capable of returning one, but if you're fine with the extra code, go for it! My test included driving around inside a ring of 36 riflemen, while filling an array with every unique _relDir value. Thousands of values, no negatives.

Great! I don't actually play much anymore, but I enjoy solving problems. I always thought a Boomerang system would be a nice option to have alongside the CREW Duke and whatnot. Have fun!

OK, I started with your code then gradually applied my "fixes" until the issue disappeared. Sticking with declaring the EH's params and using those variables was the fix. I think it is best practice to declare an EH's full set of params, even if you aren't going to use them all.

Well, I just tried this and it seems to work just fine (calling from vehicle init): //[this] execVM "ok_boomer.sqf"; _vclBoomerang = _this select 0; _vclBoomerang addEventHandler ["FiredNear", { _this spawn { params ["_unit", "_firer", "_distance", "_weapon", "_muzzle", "_mode" , "_ammo", "_gunner"]; if (_distance < 100) then { { _relDir = _unit getRelDir _firer; if (_relDir > (_x select 0) && _relDir < (_x select 1)) then { sleep 0.5; systemChat format["Shooter is at %1 from the Vehicle",(_x select 2)]; systemChat str _relDir; }; } forEach [ [0, 15, "12 oclock"], [15, 45, "1 oclock"], [45, 75, "2 oclock"], [75, 105, "3 oclock"], [105, 135, "4 oclock"], [135, 165, "5 oclock"], [165, 195, "6 oclock"], [195, 225, "7 oclock"], [225, 255, "8 oclock"], [255, 285, "9 oclock"], [285, 315, "10 oclock"], [315, 345, "11 oclock"], [345, 360, "12 oclock"] ]; }; }; }]; I removed the checks for negative values as they will never evaluate true (both getRelDir and the BIS function return only positive values between 0 and 360). I added a spawn so the sleep could run. Running your code as-is, I saw the pure values, but backtracking from my "fixes" I was unable to get them. Not sure where the problem is, I'll keep looking. One thing to remember with the FiredNearEH is that it will also trigger when the unit the EH is attached to fires - it will detect the .50 in your HMMWV turret.

I can't say it will fix the issue, but the Biki states unambiguously:

So figure it out. There are multiple ways to do it. @johnnyboy provided one above. The floor grid of the VR terrain is marked out in 2 meter squares, so there's an easy way to at least get workable measurements.