The FMLServerStoppingEvent handler added in 1.11.2-beta1 calls
PlayerData.flushEffects() and PlayerData.save(boolean), and neither method
exists -- so the mod has not compiled since that commit.
Removed along with the four imports the same commit added for it:
FMLServerStoppingEvent, EntityPlayer, PlayerData and ArrayList. Nothing else in
the class used them, so CustomNpcs.java now differs from 8612d444 only by the
version bump.
The problem it was written for is real -- effects live in memory, and logout is
not guaranteed to fire during shutdown -- but the flush needs methods that have
to be written first.
ScriptEntity.hashCode included tempData while equals compares only the entity,
so two wrappers of the same entity hashed differently - and tempData is mutable
and swapped wholesale by copyTempData, so an entry's hash could change while it
sat in a map.
BlockCampfire.onBlockActivated went from returning true to false, which lets the
held item be used or placed on top of the interaction. Restored.
Revision 23 never shipped without the burn flag - it released together with it -
so no saved NPC carries version 23 from a build that lacked pBurnItem. The
migration belongs in the < 23 gate, and bumping ModRev would only force a
redundant pass over every NPC.
Deferring registration to loadComplete is right - TConstruct needs to have
registered first - but naming TabRegistry and the tab classes in CustomNpcs put
client-only GUI types in a class the server loads, which the verifier resolves
at link time regardless of any runtime side check. A proxy hook keeps them in
ClientProxy while still running at the same point.
The free-ID search only consulted the global map, so it could pick an id the
same category still held further down the iteration - and renameTo silently
overwrites on POSIX, so the rename then destroyed that entry's file. It now
skips ids held by the category and any file already on disk.
Quests had the same discard-on-collision behaviour and now get the same
reassignment, including re-registering shared quests under the new id.
The migration sat in the npcVersion < 17 block, but ModRev has been 23 since
2023 and CheckNpcCompatibility returns early when the save already matches it -
so every NPC affected by the regression was skipped. Moved to a < 24 block and
bumped ModRev to 24 so it actually reaches them.
Mouse.getDWheel() clears the accumulated delta, so whichever widget polled it
first in a frame took it and every later reader saw zero. The script text areas
polled it themselves, after the parent screen had already drained it for its
scroll lists, so the wheel did nothing in the player, NPC and event script GUIs.
The screen now reads the wheel once per frame into the mouseScroll field it
already declared for this, and each widget zeroes it when it consumes it.
start() and tick() compared against the raw windUpTicks, but when the windup is
synced to an animation the value that applies comes from getWindUpTicks(). An
ability configured that way skipped its windup entirely and fired on the first
tick. The telegraph duration used the raw field too, so it disagreed with the
phase it was meant to cover.
Same leak as the ability magic editor: @SideOnly strips the annotated method on a
server but not the synthetic lambdas it generates, so ConditionHasEffect,
ConditionQuestCompleted, AbilityTrap and AbilityZone all shipped methods whose
descriptors named a client-only GUI class. Each field is now built in the GUI
class it belongs to.
EntityAITransform claimed the PASSIVE mutex, so any running movement or look
task blocked it from ever starting. The swap only happened in the gaps where
those yielded - which is why it appeared to trigger when an NPC said a line and
for a moment afterwards. The task only polls world time and flips the state, so
it needs no mutex at all.
KAMKEEL