Closed aaronhowser1 closed 1 year ago
Couple of questions a. Do you have the server log for the time of the incident? b. Is Prefab the only mod you're running?
If this is a larger modpack, it could be a result of other mods interferring or just a matter of the player trying to place the prefab while the server is lagging, sending over multiple requests to the server to deploy, which would process at the same time due to the lag spike
I do not have the log unfortunately, and yes this is a rather large modpack.
It likely is just sending multiple simultaneous requests, but shouldn't that be detected? Like, only allow a player to place a single prefab each tick or something
Most modpacks have optimization mods that can mess with the way Prefab requests are processed. The larger the modpack, the greater the chance it added a conflicting mod. Some modpacks, like FTB's, even change some of the functions of the mods themselves when adding it to the pack.
But again, lagspikes can make them process at the exact same time. Kind of like when you break a lot of blocks, nothing happens for a few seconds, and then you rubber bands and all of the blocks break and drop at the same time.
Some modpacks, like FTB's, even change some of the functions of the mods themselves when adding it to the pack.
I'm the pack dev lol, this isn't intended. An alpha tester found this when the server lagged.
Is it not possible to check if the player's already placed a Prefab down on the same tick as they're trying to place another? I feel like that would by far be the simplest way to prevent this, rather than just always trusting that the packet or however it's handled is good?
Sorry about that. I didn't realize you were one of the pack devs for the FTB University series.
As for that check, I'm not sure. I've only recently taken over the mod development so I'll take a look and get back to you on that.
Are you hosting the server yourself or using an online service? If you're hosting it yourself, you should have historical logs in the server's logs folder, unless you've been deleting them. Same goes for if you're using a hosting service and have access to the server files. They'll be called "[date]-[number].log.gz". You unpack with 7zip or similar program to get the log file in question.
The logs would go a long way to help figure out exactly what happened here.
Hello I am the tester who reported this. I reproduced this in a new world. Attached is my log and a screenshot of the results/
Hello I am the tester who reported this. I reproduced this in a new world. Attached is my log and a screenshot of the results/
That log file is incredibly helpful thank you. So here's the thing. This is one of those situations where yes, it kind of is a bug, but it's not exactly one that's fixable without causing more issues.
The process Prefab goes through to deploy a structure is essentially: Use item > Confirm deployment spot > process runs to place all of the blocks/make calculations to ensure it can be deployed > structure is finished > item is deleted bc it was used
The reason you're able to place multiple prefabs is because of that last step: the item is not deleted until the game confirms the structure was successfully deployed. So during the lag spike, the thread doesn't return that success flag, even if you kick off the deployment more than once.
Now, in theory, we could move that item deletion further up the process, but that could cause problems where the player runs into an issue deploying the prefab and are now left with no item to try again. Where it is right now is more of a lesser of two evils outcome. We would rather a player be able to place multiple prefabs during a lag spike than to be forced to remake a potentially-expensive item because they ran into a server error.
Tangentially related, but we found the cause of the lag that was allowing this to be so easily reproducible. It wasn't prefabs fault: CompactMods/CompactCrafting/issues/71
Minecraft Version
1.19.2
Forge Version
43.2.8
Mod Version
prefab-1.9.2.5
Details
Experienced by a player on my server, no log unfortunately