That would be useful and in addition to that, a line where the parser said: "nope, that's not what I expected in line ..." would be perfect

@inkihh He said it will be in the stable update, but I personally dislike how it's handled by the Devs, that we cannot properly test our mods for compatibility to prepare for the update. @Geez Something to consider for future updates

Please address the issue again. I've had the issue with out own Server and I know a few others, who are stuck with the same issue.
@Geez is there anything that changed since it was changed to Assigned again ?

Can be merged with https://feedback.bistudio.com/T151046

While doing some more tests, I've noticed, that also with a json String length < 60.000 I would get server crashes. It seems to have to do something with the string.Substring() method.

	static bool WriteToFile(string file, T data) {
		JsonSerializer js = new JsonSerializer();
		string jsonOut;
		bool ok = js.WriteToString(data, true, jsonOut);
		Print("Length: " + jsonOut.Length());
		Print("Json: " + jsonOut);
		if (!ok)
			return false;
		Print("Opening File for writing Json");
		FileHandle handle = OpenFile(file, FileMode.WRITE);
		Print("Opened File Handle.");
		if (handle == 0)
			return false;
		Print("Starting to write File...");
		for (int i = 0; i < jsonOut.Length();) {
			int end = Math.Min(i + 60000, jsonOut.Length());
			int length = end - i;
			Print("Writing Chars: " + i + " to " + end + " -> " + length);
			string sub = jsonOut.Substring(i, length);
			Print("Sub finished");
			Print("Sub: " + sub.Length());
			FPrint(handle, sub);
			Print("FPrint Worked");
			i += 60000;
		}
		CloseFile(handle);
		Print("Closed json File");
		return true;
	}

and this was the output sometimes (sometimes it crashed later in the program)

SCRIPT       : Opening File for writing Json
SCRIPT       : Opened File Handle.
SCRIPT       : Starting to write File...
SCRIPT       : Writing Chars: 0 to 58892 -> 58892

Okay this is getting even more "interesting"
I've noticed, that Doing this:

modded class MissionServer {
	
	void MissionServer() {
		TIntArray testArray = new TIntArray();
		for (int i = 0; i < 100000; i++) {
			testArray.Insert(i);
		}
		Print("Saving Json ...");
		JsonSaver<TIntArray>.WriteToFile("$profile:/testArray.json", testArray);
	}
}

would cause the server to freeze at some random position in the code (for me while loading Trader Objects) removing the Code will make it run fine again. If I don't put 100.000 items in the list, but 1.000.000, the server will crash completly instead of just freezing. DK, what's wrong there, but this definitely needs some attention. I've also checked if this occours while saving the json file, but that's not the case. The file is saved correctly and all my Prints were executed. When setting it to 10.000, the Server will start, but then eventualy crash. It's random every time.

Since nobody seems to care about it, I made my own Json Saver / Reader class. Feel free to use it in your Projects. I've successfully saved the TestArray from above which was a 1064kb file. This is how you use it to save files:

@Geez any chance this will be fixed ?

Great Idea, but It would be nice to have some kind of whitelist the mod needs to be put on to be able to access this function. E.g. the Workshop ID needs to be inserted into the server config as an array of Strings. I can already see some modders having the great idea to add random people ore them selfes or anything else

Thanks.
So I can spawn items / events in, but I don't get a reference to an object that was spawned ? Would be nice to get my spawned Item to manipulate it further

Can we also use that for Weapons to spawn with attachments ? Or is this only a thing for Events ? Would be great if we would have the configured attachments from cfgspawnabletypes.xml for weapons working with that too

Thats correct. I thought I wrote JsonFileLoader somewhere, but apparently not ^^. But that was the thing I meant

Thanks. Would have been a very strange limit just cutting off the Json output. Any ETA when it will be resolved ? And just one thing to note: the FileSerializer does not seem to have a limit too, if you are still looking into that. It was just a coincidene, that the size of my testfile was around 32768 bytes.

And does the FileSerializer has the same limitations ? Otherwise I would run into the same issues soon. Looks like the file the FileSerializer creates has an even lower limit set to 32768 (2^15)

Nice idea, but there will be a big problem that could cause some great mess. If you have an enum and set the first Value to 1, the second will be equal to 2 and so on. Now Imagine you have multiple mods adding items at the end of the enum and you have different load orders on the Client and Server. Some RPCs would go to the wrong direction and the whole thing blows up

Maybe try
ref array<ref Person> personarray = new array<ref Person>

I had some hard hours trying to figure out the Issue causing this Problem. It's happening when you want to use the PlainId (maybe other values too) of the Player and not save the PlainId in a variable first ! I fixed I by always using string steamid = player.GetIdentity().GetPlainId(); and then compare those values ! I did not test if this is enough, but what should be enough is this code:

I've tested a bit with all the Mods installed and it seems to be the Trader Mod causing this issue. I'll message the creator of the Mod and tell it to him. Did not think this mod could cause these issues. If you want to test it too, install the Trader Mod on the Server and Client ;)

If you need my logs: BasebuildingCrashReport.zip
And as allways: rVn has the login Data

Since the last update 1.03.151658 we did not encounter the Problem again. If we have more information on that, I will tell you

Currently you hate to use direction *= "-1 -1 -1".ToVector(); That worked for me.

You can render Them above Map widgets. You have to put them on the same parent widget and set the Priority the the other widget higher than the Map Widget. At least that is how I got it fixed