I tried the Timer class in the past to replace callLater but it is a lot lot more ressource consumming.

In T156746#2385202, @Hunterz wrote:

Timer and CallLater have pros and cons. Switching to Timer is just workaround. Personally preferring fix already very good described issue.

Timer and CallLater have pros and cons. Switching to Timer is just workaround. Personally preferring fix already very good described issue.

I'm hearing that John, Deer Isle is unmotivated to do this, so that might not be an option

Hi, friends! I see that this bug has gathered quite a bit of attention lately, due to it affecting Deer Isle vault doors and the suit printer on Namalsk.

Hello everyone.
The problem has been resolved internally and the fix will appear in one of the future updates.
Regards,
Geez

In T151279#2143641, @tjensen wrote:

Is the GetTime() value stored internally as a 32-bit float? That could explain the issue, since 32-bit floats have only 24 bits of mantissa and therefore integer values above 16777216 can lose precision when converted to 32-bit floats.

Seeing more and more frustrated players on Deer Isle (vault door) and Namalsk (printer) servers, we've put up warning messages for them to only attempt missions in the 3 hours after a restart (as 4 hour server restarts are too many I feel). Engine bug

Hello again.
The problem has been resolved internally - It is going to be possible to set health on items in client via script. This change will appear in one of the future updates.
Regards,
Geez

That still would be a very useful feature! Not only for S.T.A.L.K.E.R. but many other stuff we, as a community, could create for DayZ.

This issue seems to now be affecting the Namalsk 3D Printer, and the DeerIsle KMUC door.

I've been using a work around with POST request and setting custom headers, but this only works for POST request, as by default SetHeader only sets Content-Type headers, using this work around with GET requests fails, because GET request by standard does not have a request body, which is why SetHeader is ignored.

Feel free to close the topic, if needed I can provide more details.

@Geez I've found it. There is a continuous poll looping of course on the available playeractions. One of the in a mod had a null pointer after something updated in 1.19 and it just starts lopping as soon as a player logs on to the server. This creates a huge logfile that we saw and at some point the clientside just has a crash, maybe when maximum memory is reached orso.

Hello mattty-ice-.
Unfortunately there is not much we can do with this file as it is empty. But not all is lost.
You yhould try to recreate your project file again (terrain properties and so on) and then attach your object layers, template librariers and the height map. You may even be able to recover the up to date heightmap from one of the v4d files. What is most important for your case is that you back up everything before trying to recover the project (we assume you have a source folder with more files than just this one).
Regards,
Geez

Hello everyone.
This has been fixed for the 1.19 hotfix nr. 3.
Regards,
Geez

Can definitely reproduce and confirm freeze/desync/teleport issue when player changes stance while attached to vehicle (using LinkToLocalSpaceOf). I noticed that jumping/falling onto a vehicle while already crouched/prone does not cause the issue, it's only caused by changing stance.

Hello LBmaster.
This issue has been fixed internally and the fix will appear in one of the future updates.
Regards,
Geez

To be clear -- the above entry was after I manually changed the "CanBeAutoupdated": value to true. It was false.

before player teleported client freezes for few seconds

there are only new bug with linking to object... when player change stance, is teleported (desync) randomly to map