Do less shit per onUpdate(), its good for your tps
Split explosion into a bunch of phases that run every onUpdate, code is
ass but stopped the server from crashing
Will need to do the same to EntityFalloutRain too but that's tomorrows
problem
Also tomorrows problem: make this less ass
Also vim fixed a lot of whitespace things and I dont feel like dealing
with that right now
Looks like the devs were in the middle of rewriting this class
Thermonukes would cause a crash because setScale tries to set a
dataManager thing that was never registered
Once that bug was fixed the crash stopped happening but the explosion
didnt do much so I readded a lot of commented out code
Works for now, will have to see what the devs were planning to do with
this so I can impliment it right or just steal what they did
They were missing from the source I got so I stole them from the
production jar file, no clue if this is where they go but it worked well
enough for testing.
This fixes a bug where leaving the chunk shortly after an explosion will
cause the explosion to either not happen, or do very little.
Currently this functionality only applies to nuclear explosions.
When the EntityNuclearExplosion does its first tick we grab a ticket
from ForgeChunkManager and use it to load the chunk that will contain
the EntityFalloutRain. The ticket is then passed to the
EntityFalloutRain which will unload the chunk when it finishes its work.
Doing it this way will almost certianly add race conditions but it works
as a proof of concept. Ideally I imagine we would wnat to have some
class that will keep track of loaded explosions and make sure that they
are unloaded properly even if the entity somehow despawns.
I also did not impliment anything in the chunk loading callback. As far
as I understand, we would need to store the loaded chunks there so if
the server dies in the middle of an explosion, it will be reloaded when
the server comes back up.
This commit fixes a bug where ICBM explosions would not trigger Trinity
explosions on servers.
Event handlers were only being registered on the client side which means
that integration would only work in singleplayer. Also most of the ICBM
code was commented out so I assume this was mid rewrite or it was
causing build errors.
Event handlers have been split into 3 classes:
ClientEvents - Events that are only clientside, currently used
for the TextureSwitchEvent handler
CommonEvents - Events that occur on both the server and client,
currently handles player tick events
ICBMEvents - Events related to ICBM integration, handles adding the
warning tooltip and the Explosion.Start hook
Explosion code has been updated to use the new Explosion api, most
fields being used were made private.
The ICBMEvents handler is only registered if ICBM is acually enabled,
removing the need to check in the event itself