@Geez please help. server steel crashes. need help. pls

Ah I didnt think to try out for AI, thank you very much

The problem are the non team-players that wants to get the ultra-ghillie-sniper-grenade-rocket-launcher-kit straight from the beginning... just to get killed five seconds later. This behaviour drains resources like there is no tomorrow and causes massive resource problems. People should earn their stuff and that's what the conflict mode is for. If you know how to rank up fast you will get what you want.

It was ignored for player used weapons, not for AI.

Hello Krozj.
This has been tested internally but we were unable to reproduce the issue.

Thank you, so far we are unable to reproduce this issue

Without the Steam ID/link to Steam profile we cannot provide any further service unfortunately.

2.20 also adds config entry for map controls
useRealViewport = 1 to enable it by default, then you don't need to use script command

Fixed in https://feedback.bistudio.com/T189016
due to backwards compatibility you need to run a command, or add a config entry to enable it.

Fixed in https://feedback.bistudio.com/T189016
due to backwards compatibility you need to run a command, or add a config entry to enable it.

Fixed in https://feedback.bistudio.com/T189016
due to backwards compatibility you need to run a command, or add a config entry to enable it.

This is how lifetime works, this loot didn't come with the event so it will not be removed as a part of it.

Can you guys please fix this as it breaks single player PvE.

Okey.
Due to backwards compatibility, we need to mess around a bit.

Per @dedmen request here is a PBO where once this issue works the suppressor (on MX rifle) should reduce the recoil o 25% of its original value when not prone, or if prone to 5%. Other fields like the hit coef dont appear to work, so if it gets fixed then with this suppressor they should do 10x more damage (Picked an extreme value to test with). I imagine typicalSpeed value also doesnt work, unsure how to test on my end.

Give items iD numbers and tracking numbers 🥴

respond and clarify the situation(pls), coz this is huge

Did he leave cash in your underwear?

Yeah should have been easy, so why has not been fixed in a month of telling them

In addition, I would like to say that in fact any edit to class SurvivorMale_Base: SurvivorBase and class SurvivorFemale_Base: SurvivorBase that affects the model path on the customizer will result in this effect.

So why do I need that update if I'm still unable to publish updates to any of my mods?

Can be closed, as it can be fixed by enabling AutoHierarchy on the RplComponent (since 1.3.0.76).

It is easier to see if you also change the position of the background like this

with localNamespace do  
{  
 private _display = findDisplay 46 createDisplay "RscDisplayEmpty";  
 private _ctrlGroup = _display ctrlCreate ["RscControlsGroup", -1];  
 private _ctrlText = _display ctrlCreate ["RscText", -1, _ctrlGroup];  
 _ctrltext ctrlSetPosition [0.2, 0.2, 1, 1];  
 _ctrlText ctrlSetBackgroundColor [1, 0, 0, 0.5];  
 _ctrlText ctrlCommit 0;  
 private _ctrlMap = _display ctrlCreate ["RscMapControl", -1, _ctrlGroup];  
 _ctrlMap ctrlMapSetPosition [0, 0, 0.5, 0.5]; // effect is immediate  
 _ctrlMap ctrlMapAnimAdd [0, ctrlMapScale _ctrlMap, player];  
 ctrlMapAnimCommit _ctrlMap;  
 _ctrlGroup ctrlSetPosition [0.2, 0.2, 1, 1];  
 _ctrlGroup ctrlCommit 0.3; // non instant transition  
 _ctrlMap ctrlMapSetPosition []; // instant sync to new _ctrlGroup position  
};

You can see that when you click above the red area, the map control is moved. But clicking outside the map area, it is not.
Also the map ignores the ctrlSetPosition, it should be positioned at 0.2/0.2 from the top left. But it is rendered at 0/0

I hope this is a temporary issue with .52 or .55 updates, as I haven't noticed this before in 1.3.

Workaround:
You can create a new group and add new AIs to it

I believe there is none unless we use EachFrame/Draw3D and call it a day. Smooth transition wouldn't be a concern to consider IMO, from what I can see firing an EH upon cameraView has changed is good enough to detect Visual/Pilot LOD change etc.
However and just thouht of, "BeforeCameraViewChanged" might be an addition to suppress the viewmode update etc I guess. Not really sure how it would have a usecase, so just sayin'.

Here's another video that shows the lack of blood effect in animals, generally a problem with all AIs

This is true that it might feel disconnected, when the input is faster than it's needed to be, since there is no way to force a speed limit on a mouse.

it's an easy fix.
I assume they process loot mapgrouppos when they redo the navmesh before pushing the files to QA then Live. Unless the mapgroupproto is broken.. I haven't personally looked at the shared files.

In T188318#2754101, @dedmen wrote:

Won't fix. I have no idea where to look.

Confirmed this behavior as well on stable branch, it appears to be fixed on the latest experimental build.