I just checked again, becaus I saw other mods using somthing like
class CfgAddons { class PreloadBanks {}; class PreloadAddons { class dayz { list[] = { "Other_Mod_Name" }; }; }; };
I just checked again, becaus I saw other mods using somthing like
class CfgAddons { class PreloadBanks {}; class PreloadAddons { class dayz { list[] = { "Other_Mod_Name" }; }; }; };
It not only happens when I get the string in there with the CopyFromClipboard, but also when doing something like string str = "..." and put all the data with escaped quotes in there
Okay, that's what I expected, so we have to either spawn items only client side or try to hide it for other players.
Thanks for the answer anyways.
Nice. Seems to be fixed with the last 1.24.157353 update
Changing this will 100% break more mods than it will fix. Either introduce a >>> for it or don't change it
Why is this a bug ? This is normal behavior for negative numbers. What you mean is >>>, which does not care about the sign of the number
I just checked if my 1.24 Experimental Server and it does not start with the PBO loaded and I still get the same error. Has the fix not been merged into the first Experimental Build? I also haven't seen it in the 1.24 changelog in the forums.
Also one big issue this would solve would be adding mods, which overwrite the onstoreload and onstorewrite methods to save their own variables, cause the whole persistence to break. Being able to rewind the buffer when it failed to read the data, would make it possible to prevent wuch issues from happening. At least when installing the mod
I just saw a fix for "Can't find matching overload for function Error" was scheduled for the 1.24 update and I wanted to emphasize, that this has also been a major problem for me in the past, that sometimes the loadorder of mods is not the way you need to have it and supporting a load of different mods will get very tedious without some proper softdependencies. Currently it's just luck if it works or I have to make a seperate PBO for the plugin, which is not really doable especially for only a few lines of code for every plugin.
Yeah, That's what I expected. I found a workaround by adding proxy physics and removing them by script when the item is attached / detached. That seemed to be impossible first too, but now it works for some reason. I guess you can close it
@Geez please have a look at this
The mdmp is from a 1.22.156718 Server, but it also happens on the latest version and has been a problem in older versions too
Or when going even further, you could implement a whole FileApi to subscribe to file changes with a callback to the reload any changed configs so for example
class FileApi {
for me personally it would be enough to just be able to manipulate the players network bubble position through the PlayerIdentity class with something like proto native void SetNetworkBubblePosition(vector position); to overwrite the position to a certain location as like the player would stand there to see items and players around (must be called by the server obviously). and a proto native bool ResetNetworkBubblePosition(), which returns true if the position was overwritten or false if the position was not overwrittien (Also maybe add a method to get the current location and get if it's currently overwritting without having to disable it, but they don't seem to be that needed). Also the PlayerBase of the player remains at it's old position and should still be synced with the server to prevent any issues arrising when deleting the PlayerBase of the player, because he is out of the range of the network bubble. It would also be cool if the VON location would be changed to the same location to allow interacting with other players like the admin is at this position
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
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