Tile Entity Logic

[samdotjpg]

Okay I'll update this with more information about the PR and its features/changes when it's nearing completion. Right now I'm just documenting my progress and what's left to do.

• Chests
• • Singleplayer functionality
• • Fix UI from console
• • Save compatibility check <- 0.4.0? where should we take this from? unneeded for now if goal is 0.3.3
• • Multiplayer support <- Once ContainerListener is fixed, this should work instantly. This isn't a TileEntity specific issue, but we need to be able to:
  • • Open / close chest
  • • See container items
  • • Move items in container
• Furnaces
• • Singleplayer functionality
• • Save compatibility check
• • Multiplayer support <- Same deal as chests
• Note Blocks
• • Singleplayer functionality
• • Multiplayer support <- This will naturally work when TileEvent is fixed and players don't place a block/item when interacting with containers/crafting tables/etc.

misc:

• entities stored as maps instead of vectors
  • tile entities will need to be migrated to this once we have an unordered map so we can hash them based on their coordinates
• riding entity logic
• changed "looking at" entities to fetch an entity by ID, which closes Server crashes when a player leaves while a mob is looking at them #342
  • can someone please make (or choose an existing) o(1) hashmap? we have so many inefficient map/vector functions
• charcoal
• facing:: helpers
• touchscreen controller support
• sheep are no longer gross on gles
• sand/gravel drop items now, closes Gravel and sand drop nothing if destroyed from below (i.e. torch) #447
• snow tiles drop snowballs, closes Shoveling snow should give snowballs #449

Right now even interacting with tile entities in multiplayer causes your buddy's client watch you place whatever is in your hand.

[samdotjpg]

it's getting to the point where we need an unordered hash map and we need to go through just about every map and see if it needs to be replaced so we can squash the o log n lookups.

[samdotjpg]

How do you want to broadcast the current state of the container? The ContainerSetContentPacket and ContainerSetSlotPacket just need to be hooked up to wherever they are in PE. Otherwise, the functions do work and transmit the data properly and I fixed the ServerPlayer container transmission bug.

@BrentDaMage is it possible I could get you to do container hookups where the PE equivs are? This PR isn't necessary for it, it's just the hookups to transmit data. Using this for the furnaces visual clues would help tho

[BrentDaMage]

I'll do this, there's some stuff in furnace that sends packets that I (for obvious reasons) never decompiled. I'm sure chests are the same.

[samdotjpg]

You are my hero

[samdotjpg]

surface

[samdotjpg]

I've gotten chests and furnaces mostly working in multiplayer. There's some weird occasional desync issues I'm working out.
Also I guess it's not a "feature" that when the host breaks part of a chest when you're looking in it, the client's game crashes.

[Un1q32]

?

[Wilyicaro]

tell me why

[Vimd0]

they quit damn

[Un1q32]

If she did actually quit I wish she would have warned us before deleting the branch there was a lot of misc bugfixes i coulda separated out.

[Un1q32]

Wait actually you can still see the diff yippe, I'll try and get the bugfixes in myself if she doesn't say anything for a day or so.

[Vimd0]

Wait actually you can still see the diff yippe, I'll try and get the bugfixes in myself if she doesn't say anything for a day or so.

Thank god it archives