Adding on to what @lava76 mentioned.

* Order of Events firing:
* When player respawns                            : ClientPrepareEventTypeID ► ClientNewEventTypeID ► ClientNewReadyEventTypeID
* When player joins (no saved character)          : ClientPrepareEventTypeID ► ClientNewEventTypeID ► ClientNewReadyEventTypeID
* When player joins                               : ClientPrepareEventTypeID ► ClientReadyEventTypeID
* When player logs out                            : ClientDisconnectedEventTypeID
* When player cancels logout                      : LogoutCancelEventTypeID

A method to be able to query basic file structure variables like, name, last modified, date created, size.
Within one method resulting in a callback instance create that holds onto such parameters:

The issue seems to lie internally with how GetGame().CreateStaticObjectUsingP3D functions. There seems to be a difference in how the position coordinates are processed in comparison to normal GetGame().CreateObjectEx() functioniality. After looking into the ObjectSpawnerHandler script level class, there is nothing done to the input of position coordinates and or the orientation data that would result unexpected behavior with placement.

Aim better next time

Ticket can be closed, for future reference for others: the class HumanItemAccessor methods for each entity is tied to Human instance. Access it via Human::GetItemAccessor(); and the methods within HumanItemAccessor will be relative to the entity. The features mentioned above in the original ticket are working as intended

With use of unoptimized mods, on a lower tier hardware (HDD, low read/write speeds) the game tends to take much longer when loading in.
The connection process on each server takes different amount of time based on factors like; mission size (adding custom buildings via CreateObjectEx), count of entities nearby to load in during initial connect.

Math.Randomize(-1);
int index = Math.RandomInt(0, 100) % 2;

Or reference external methods over HTTP

Just tested on the latest patch, working perfectly! Thanks :)

Update: this is possible to reproduce with the stable DayZ client exe 1.12.153.891

Hello Geez,

Could we please get some information what did you guys fix internally? (it does not need to be technical line by line, just some heads up on something we can relate within EnforceScript) Might clue us in on looking for an easy way to reproduce. Because right now i am stuck with adding a single "if statement" or declaring something "new" of a custom typename causing crash during 4_World module compile
I have a 100% reproduceable method right now, but it must include a large list of mods; and the issue is presented based on combination of scripts that have no correlation from one mod to another (on surface level aka Enforce Script modules)

New patch 1.10 has added the ability to read from the globlas.xml, you could make use of that.

I have not attempted that, my alternative solution was simply to stick with vector.Distance() however, i might give it a try with increasing the objects' Transformation.

no :)

Results in:

This has to be a user error. Works fine for me. vars markers with [NonSerialized()] behave as they should.

pls fix

pls fix :)