Again, sorry for the huge commit. Just taking on performance issues as I
see them. Changes in this:
- Deadlocks in region code finally fixed
- Chunk packet preparation optimized (saves ~10-20ms per packet, since
we're sending these like 30 at a time that's pretty important) by
storing chunks pre-encoded in memory (basically just using a single
big array for IDs, metadata, and light)
- Move chunk generation and compression to the thread pool
- Move client chunk updates to the scheduler
- Improve profiler coverage
- Add knob to disable scheduling chunk events on chunk load
- Make it possible to disable specific scheduled events in config.yml
Sorry for the vague commit message. There were a lot of changes. Here's
a list of most of them:
- Lighting updates are timeboxed each frame
- The next environment frame is queued sooner if the current one took
longer (as soon as immediately)
- Issues with the physics engines and mobs using it were (mostly) fixed,
mobs no longer freak out and get stuck on physics objects
- Mob AI/pathfinding is done more intelligently
- The player can no longer spawn in an ocean or a desert biome
- Some deadlocks in Region were fixed (more remain to be fixed)
The current performance bottlenecks are lighting (still) and propegating
initial chunk loads to blocks that need to schedule things (such as
grass blocks). I think the main culprit in the latter case is grass
blocks and water blocks. The former can be improved by adding a block
cache to World, but that'll take some custom work. This step is just
gonna be slow no matter what, we might have to split it across several
frames but it's never going to be great.
There still seems to be a deadlock somewhere in all of this mess, in the
world code. I'll find it later.
This allows us to cancel events when the subject is no longer around.
For example, if a chunk is unloaded due to inactivity, the events within
it are cancelled (growth of wheat, propegation of fluids, etc). When a
client disconnects, events associated with it are cancelled.
To use this for your own scheduled events, pick a subject. If your
subject does not implement IEventSubject, implement it. Then, you can
pass the subject into ScheduleEvent and that's it. When the subject
dies, your events will die with it. So long as the subject remains
alive, your events still fire.
`null` is a valid subject for events that should happen regardless of
any subject expiring.
Closes#1
