Rollback Manager going wild #5419

New Issue

AliasAlreadyTaken · 2023-10-25T12:42:13Z

AliasAlreadyTaken commented

2023-10-25 12:42:13 +00:00

41.50% minetestserver [.] RollbackManager::getSuspectNearness(bool, irr::core::vector3d, long, irr::core::vector3d, long)
29.52% minetestserver [.] RollbackManager::getSuspect[abi:cxx11](irr::core::vector3d, float, float)
10.86% minetestserver [.] RollbackAction::getPosition(irr::core::vector3d*) const

41.50% minetestserver [.] RollbackManager::getSuspectNearness(bool, irr::core::vector3d<short>, long, irr::core::vector3d<short>, long) 29.52% minetestserver [.] RollbackManager::getSuspect[abi:cxx11](irr::core::vector3d<short>, float, float) 10.86% minetestserver [.] RollbackAction::getPosition(irr::core::vector3d<short>*) const

AliasAlreadyTaken commented

2023-10-25 13:39:22 +00:00

Reason was an enormous water spill, which needed to be be //drained by worldedit

AliasAlreadyTaken added the

3. source/lag

label 2023-10-25 13:39:28 +00:00

flux commented

2023-11-08 19:36:30 +00:00

huh. didn't know //drain cared about the culprit. i always just use //r water_source air and //r water_flowing air.

huh. didn't know `//drain` cared about the culprit. i always just use `//r water_source air` and `//r water_flowing air`.

AliasAlreadyTaken commented

2023-11-10 23:18:57 +00:00

I used //drain to remedy the evolving situation.

The rollback ran wild because of the spill, which somehow attributed each step to who initially spilled the source. That caused MT fire more entries towards the rolback database than it could handle

I used //drain to remedy the evolving situation. The rollback ran wild because of the spill, which somehow attributed each step to who initially spilled the source. That caused MT fire more entries towards the rolback database than it could handle

Sign in to join this conversation.