On using /stop:

Heya, thanks for your ticket! I'll pass this on to Internal!

After looking through the source code, it looks like this issue is related to the server not correctly recording which mega stone's the player has obtained.

See:



The getNames call that results in a NullPointerException occurs within a for-loop block that iterates over the species of unlocked megas.

Such an exception implies that the data from this.megasObtained.keySet() is generated improperly (and likely contains null values or values that generate null values).

You may want to try and reproduce this issue by defeating the same Mega boss twice.

Having the same issue on a server with multiple people - it seems to start happening around when a player kills a mega boss and obtains a mega stone, the next time they log in the async saving fails (and continues to fail every time the async interval occurs). Based on the error it may be involving the saving of the MegasObtained section of the player's .pk file - the last time it is written before the server is unable to write to the file anymore, it adds "[email protected]" (alternating d4 for a different value based on which mega it is) at around hex 0x000035A5, and the error involves the getNames method in PlayerPartySorage.java. I can send two pk files - one is a player who has not killed a mega yet (freshly generated to test the error), and another immediately after the same player killed a mega (marked as player_mega) - for comparison, if that helps at all (the second one has that string and can no longer be written by the async routine).

I literally just made the same observation. Good stuff, I think we found the root cause here.

To add to this, the server seems to be writing that data to the file perfectly fine when async is disabled, and if async is on it is able to write the data until the player disconnects and reconnects, at which point it pulls the data from the file but stops being able to write back to it - possibly, the async routine has an issue flushing that specific data to disk (pulling it from memory until the player logs off) and then the next time it has to read the data it gets somewhat mangled data that it is no longer able to re-write to disk? (or vice versa, having trouble reading from disk on player log-in and getting mangled data that can't be re-written)

The player .pk files have the MegasObtained information written correctly (confirmed using a functioning file generated with async disabled, player_mega_working.pk) and are being updated up until the player logs off, at which point the next time they log in it is no longer able to be updated and the error appears in the log.

All three pk files are attached here: https://drive.google.com/drive/folders/1JLg-huxOF8ip2LPtHQPTwmBup2hB8Czo?usp=sharing

Slight update: with async disabled, the server no longer fails to write to the player data file, but instead it just completely crashes when trying to write the data. I've uploaded a player data file and relevant crash log below - what happened is a player caught a mega, logged in and out multiple times with no issue, the server was then restarted, and upon the player logging in again the server hard crashed about a minute later with a similar error (exception in server tick loop, which the logs identify as a java.lang.NullPointerException at PlayerPartyStorage.getNames)

I think what's happening is when the MegasObtained data is read from disk, it comes back somewhat mangled and any attempts to re-write this new data to disk just break the writeToNBT function - or the error is happening upon writing to disk, I'm not sure if what I'm seeing in the .pk files is even close to correct since I don't know the format.

Relevant files are attached here: https://drive.google.com/drive/folders/1lA4QttBMjzUEEUDG6qfTpDzw4OSl-jYz?usp=sharing

logfile.txt is the section of the server log pertaining to the crash (all subsequent crashes display the same errors), and crashing.pk is the player file for the player that is causing the crashes

Thanks guys, I've passed this whole convo onto the internal ticket as well.