Another year, another rabbit told to stop before reaching the road. Confirmed to have survived 2018 as well.

Most notably, from a 3rd person perspective if your cursor is on the flat portion of the stand the addAction applied to the stand will not display. However, if you place your cursor between the legs of the stand, the addAction will display.

*Crickets*

Can confirm that the stop sign has survived 2017 - https://cdn.discordapp.com/attachments/137724981500051456/390175103759155210/20171212171606_1.jpg

@Neology Haha, feel free. I largely just stopped answering our community and began directing them to this ticket.

Here's an existing way to do it.

*crickets*

@dedmen I'm specifically looking for a client command that returns the calculated GUID and not the Steam PlayerID.

At a glance, it looks like "レーザー指定子" may be a better fit?

Specific uses would be for something such as a function to add experience (fn_addXP). If malicious players utilizing some BE bypass method were executing this to script-inject themselves experience.

Something worth noting, if you're using a 32bit OS, I'm assuming you're also using a 32bit version of Arma 3. No 32bit executable can actually use 16GB of RAM.

@Wilco Asylum is keeping an eye on this. Seems based on our internal experiments that a hard restart alleviates the issue, but if left unchecked the server will continue to kick every time it fills back up (every 15 mins or so) until it naturally hard restarts.

Reports from our players that this is still happening post 1.70 (Vanilla with Life Mission)

Asylum had reconfigured everything in preparation for a move to Headless Client and had subsequently stopped using it prior to the increase in mass BE kicks. (i.e, we've had the issue without using headless client)

See Related ticket:
https://feedback.bistudio.com/T124835

To save @razazel some time:

I'm pretty sure in the history of warfare, air superiority has, and will continue to be, a vastly superior option to ground-based forces.

If BI ever decided to explore a method for "multiple admins having access to debug", a compromise for security could be done via some method similar to the following:

Gaming-Asylum started having the issue in May/June (more heavily in June).

Here's a post from one server experiencing the issue that has a touch of detail.

My reaction when I realized what I did......

Also worth noting that (vehicle player isEqualTo "Steerable_Parachute_F") returns false when in a steerable parachute.

Works perfectly fine for me.

Ahh. Well then, my mistake.

Fixed: The BIS_fnc_initRespawn handle disconnect event was returning true and causing units previously controlled by a disconnected player to be transfered to server and become AI (https://feedback.bistudio.com/T123785)

Have you verified that:

1. The building you want is for sure the object being returned by nearestBuilding
2. That doors 3-5 are the same doors that they were pre-1.68

Servers owners have to update their own servers. Alternatively, you can roll back to the previous version on Steam by using code "Arma3Legacy166" in the Betas tab.

Tossing a bump into this. Mostly because snakes bypass _this setVariable[format["bis_disabled_Door_%1",_thisDoor],1,true];

I'm pretty sure non-binarized files have to have all instances of double quotes encased in double quotes.

Any word on this one? I haven't tested in RC/Dev in the last few weeks, but I assume it's not yet been resolved.

There may be effects on other vehicles; but I've not noticed any significant changes (i.e, other vehicles don't just stop).

Occurrence is in Vanilla (no mods).