that looks like simple rendering related changes, because ultimately when you are not looking in the vicinity of objects, they don't render (if they did your client would take a massive hit to FPS). There really isn't any performance friendly way to prevent that happening. If you notice, when you start getting your view closer to where those trees need to render, it starts adding the shadow detail of the trees.

This is still a problem

for more context, the intention is to be able to create a survivor on the client-side for using in the PlayerPreviewWidget that I can adjust textures or items on, without affecting the actual player itself.

Of course, we as mod makers, have to be careful about how we implement the use of it.

@Geez @Sumrak This was tested in detail by Diesel, but I have verified independently that 39 is the limit that I seem to be limited to also.

@Geez this will probably need some attention before it becomes a problem, as servermod param is becoming quite popular

I believe he was meaning the JsonFileLoader, which DOES have a limitation on the JsonSaveFile function of 64kb. However the FileSerializer does not seem to have this limitation, which is correct (so far in my tests), it just creates a file that cannot be edited by admins/server owners which is less than ideal.

After tinkering a little with the possibilities of CURL, I've come to realize there is a massive issue in that all incoming returned data is limited to approximately 400 characters, as all data is pulled in as a string and 400 characters seems to be the limitation of DayZ's strings (or maybe the curl implementation).

@Geez any chance this might get a little support on the dev side?

yeah after testing a bunch, it's only an issue when writing to a file beyond 64kb in length. Following the code, it seems that the limit may actually be in the way that it takes the data into a single string.

I also noticed that the ItemPreviewWidget behaves the same, you can see in the above screenshot

Having the exact same issue in 1.04 stable

solved. I had a custom spawn location setup based on GUID, that was causing the issue apparently.

I can verify this happening in several locations, floats losing their accuracy.

Yes please!

This would be so much more efficient than having to write one from scratch. The capabilities are there, it would be fantastic to have it available, even if it were done in the same nature as the json serializer.

@Geez @rVn
This is quite important, especially when trying to deal with hackers.

@rVn can you please move this to the modding section. (I am not sure I have done so correctly)

This issue is still present. It happens 100% of the time on a fresh upload of a mod to the workshop in publisher.

When the logs cycle and add to the file count, it will not be good enough

A devmode parameter will not be sufficient to resolve the max file count issue, as the general user does not set launch parameters to join servers.

Salutesh and I were just discussing this.

If the directory creation in $profile is lifted, the file count cap can be avoided. I'm personally finding a lot of issues with creating a config json file on a regular player's system (or even an inexperienced server owner's server), because of the limit to file count and the fact that logs cycle (not a bad thing on the cycling, it just means that unless archived regularly, the cap is hit faster).

I do agree that the script log should be reduced in useage and kept for debugging (hence my mods that are made for extended logging info being moved to dedicated systems as the ADM file gets quite busy too). And absolutely there are some mods that spam the file a lot (despite having requested options from modders to be able to turn them off).

From an optimitation standpoint it's just bloat. Though it's a minimal amount per line, it would reduce the amount of data written to the hdd. As more mods start printing to the file it really adds up quite fast. The cycling combats some of the issues but the script log really can get huge fast

The fps difference changed with the performance update, in all reality. I will submit some more data over the next few days.

If you just play DayZ straight through steam:

• right click DayZ in your library
• select properties
• click the Launch Parameters button
• type "-name=YourName" without the quotes and change YourName to your desired name.

This is quite old, but still applies. Just the specifics of lines and such mentioned are outdated now.

I retract that. Passing true in the 3rd parameter for CreateObject results in an invisible object if that object isn't an AI Entity. That was my error.

I'm still getting the invisible objects on the current experimental.

Also Garden plots are invisible when they have been dug up.

This video shows the AI walking through the walls. It actually also shows me being able to run through a code spawned gate, too.

on a side note, I've noticed this in a few newer mods recently, people being told they need to update their publishedid, because it is 0

This is fantastic news!

Also, when you are building and the hammer wears out, it locks your character unable to move, in a bent over position.

Thank you for your prompt reply Geez. Glad to know it is something bigger than the effects of a couple of file edits. We're really excited for the next big update, the new engine has so much promise.

This issue is actually a bit deeper than Okka has stated. We have been testing it together on our server, ButlerZ - PvE. It has been quite popular, but since the maintenance on the Wednesday before last, every time a player logs into the server, it freezes while they load. Their screen goes white and their FPS runs a bit crazy, coinciding with players being sent in spasms around their location ending in a fast on-the-spot spin.

Welcome to DayZ, that's how hives work. That has been the case on all public shards forever, server hopping to get geared.

I am not sure if it was the automated restart that happened today, or the one I performed just a few minutes ago, but the database seems to have linked back to the correct one now, as the characters are restored.

We have not experienced the issue again on the server since Friday. Thank you for your prompt responses and resolution.

Fragnet Game Panel has finally started working again. I did a restart manually (not a persistence restore), and all of the vehicles that had been gathered re-appeared where they were parked before the database issues happened.

Server just restarted and vehicles have disappeared (assumed respawned completely) again.