Have you verified 'DayZ Tools' through steam? Maybe try deleting the workbench executable and then verify.

That is a community wiki so anyone can edit that as long as they have an account.

Just keep retrying until it works. AFAIK that's what BI also does.

Weapons are unfortunately limited to the player simulation rate of 40hz and not independent to the server frame rate.

In T153090#2247242, @Setman wrote:

Update
It seems like when @DayZ-Expansion-Licensed;@DayZ-Expansion-Bundle; just got updated I am now able to add more mods for some reason. Works great now.

That's it, refing it all the time.

For the " FPS limit while not focused" does changing the "Update in background" option in game menu change anything?

Also, a way to remove (or change) the FPS limit while not focused on the game. Currently, it is set to 19fps.

Well, Expansion-Vehicles and Expansion-Market are going to be getting an increase in the number of scripts soon, sorry about that. There will be an active effort to reduce the number of scripts in the future though once we know what needs to be reduced.

So glad I switched to PS4.

Use "c".Hash() where "c" is any input string of length 1

Works fine for me.

Imagine thinking I have private admin access to the feedback tracker because I can delete my own comment 😂😂😂

Do servers even stay up for that long??

Just tested with @DafixCz's mod list. Again, in Stable, hard freezes on "server core", in the new Experimental patch, it goes past that stage.

Used the following mods directly from the '!Workshop' directory.

Duplicate of https://feedback.bistudio.com/T155225

In T134289#2130363, @Lex wrote:

How was it possible to return the error that was fixed before, it was about a year ago or more?

Doesn't work @komer for anything but gear changing. Even when following the instructions provided from a duplicate feedback tracker link

They probably are intending you to use the new JSONApi from now on.

Doing this will save hassle with backwards compatibility in the future @Hunterz as the devs add more classes slowly

Probably a workaround fix against this issue https://feedback.bistudio.com/T150534

@Arkensor each template is a new class.

The issue has been fixed internally and the fix will appear in one of the future updates!

Nothing you nor Bohemia can fix. This is an issue with sub-par created/packed mods.

https://github.com/Thurston00/DayZSGZScripts/blob/master/sg/creatures/infected/_infected_base/config.cpp#L39

Did you configure the Infected you're spawning to use that behavior? By default they don't use that, it's what the Survivor Games Infected used though.

Video of the issue happening on an experimental server (@Helkhiana twitter)

After further testing, it seems that this issue can be resolved.

Did you wait for the HumanCommandVehicle to end before calling StartCommand_Script inside one of the Command Handler override methods, you can check that by seeing the current command id and checking if that command was finished using the boolean. This method works for me as was intended.

I highly suggest just opening up the 'player_main.aw' animation workspace file and then looking at how the graph works to wrap your head around why it is just not possible to "reset" animations after a command has ended.

It is not a bug with HumanCommandScript. The reason this happens is because HumanCommandVehicle::GetOutVehicle (or equivalent) was not called before the command change. This is done by design to allow the player to enter the command HumanCommandUnconscious while still being attached to the vehicle. If you want to be detached, call HumanCommandVehicle::GetOutVehicle.

That is the intended behavior for how that method works.

Clothing shouldn't be an Engine class so not sure what the problem is there, holds no proto/native methods and inherits from ItemBase which can be modded.

scripts\4_World\Systems\Inventory\AttachmentsOutOfReach.c line 18 and line 20 need to be changed from:

Oh and @Geez, this ticket can be closed. Works as expected for the Expansion Mod in both 107 and 108.

Perform on the client first within the command handler for the player you are linking and then perform on the server. Notice how StartCommand_Vehicle is always called on the client before it is called on the server, this is why. It is only called on the client which is being linked and the server, you do not need to sync to any other vehicle.

Can confirm, except for an issue with getting out of seats and sometimes players teleport to 0,0 (mod issue) it works fine.

That sedan inherits from the script class itembase using a simulation of inventoryitem and at one point I also gave it a mass value of 10. Works fine for me in 107

Both work fine for me.

An idea on how this could be solved is just to create and then expose a script method which is called after car inputs have been resolved in engine. This can then be used to override the inputs if a modder desires to do so.

Some more information to help solve this issue.

This can be closed.

Use HumanCommandScript instead as a workaround. Works really well.

This can most likely be reproduced if the server were to freeze for half a second (server fps drops to 20) and you were to already be travelling at 100km/h going north.

There exists some code in the game that means that if the vehicles forward direction is within some small delta of "0 0 1" (North) and exceeding 60m/s (~230km/h) then the vehicle will seem to no longer have any friction/drag applied on it.

Added a temporary feature into Community Framework, in 4_World use this for now. This should hopefully resolve issues until a proper and crash free solution is implemented.

Call this on the server @Hunterz if you want to spawn a magazine in a weapon

Duplicate of:

Not just images from the profile folder but also audio files

Resolved as of 1.07

Create a new mission and load that one instead. Don't touch the vanilla mission

I found a workaround but it's time consuming and will break compatibility with other mods. We are going to use that hack fix for Expansion and break compatibility with other mods.

That is because server performance went ever worse with 1.05