Posts: 513
Threads: 10
Joined: May 2014
Thanks: 138
Given 89 thank(s) in 75 post(s)
If you want I could update the protocol to 1.14.4. As I read we would drop support for the old protocol versions:
- Merge all packets in protocol file for 1.14.4
- Removed all old protocol files
- Update packets: Ids, update fields
- Comment all packets that changed
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
08-04-2019, 11:34 PM
(This post was last modified: 08-04-2019, 11:35 PM by xoft.)
Not yet, we first need the changes in the underlying representation - go from numeric BLOCKTYPEs to stringular, using the BlockTypeRegistry. If you want to help, I could use help after I get this first part merged, I'll take on the BlockArea rewrite and someone needs to refactor the block handlers, bring some sanity to them.
Unfortunately the protocol will most likely be one of the last things to do.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
I think the registry is now ready, it's waiting for a review. It can be merged into master without disrupting anything, it is initialized but not used anywhere yet.
I'll start working on the next step, the basic BlockArea implementation that provides storage for text-based blocktypes.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
As for the item type registry, that is not immediately needed, so I decided to let it wait until the BlockTypeRegistry settles down, we see how it works and then model the ItemTypeRegistry in a similar fashion. I'm still considering whether to make one template registry, specialized into Block- and Item-type registry, or whether to implement two completely separate Registry objects.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
Basic BlockArea implementation is done (PalettedBlockArea class), it supports getting and setting individual blocks, and pasting other BlockAreas. There's no merging yet, that will need a bit more thought about how to define the merging process. It should be sufficient to support rewriting the world storage, loader and generator to the new BlockArea now, so that's what I'll try next. Not sure if I'll need the BlockEntity and Entity storage added to the PBA class, that could complicate things a bit.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
Another option would be to store the light values in an entirely different class, with a separate get / set API.
Posts: 4,628
Threads: 115
Joined: Dec 2011
Thanks: 693
Given 494 thank(s) in 423 post(s)
Why can't PBA store the lighting as well like the original BlockArea does?
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
09-01-2019, 07:13 AM
(This post was last modified: 09-02-2019, 02:53 PM by xoft.)
I don't think it should. We only need the light values stored when using it to store the chunk data, it doesn't make sense for it to store the light in any other scenario (can't copy & paste light, can't save to file etc.) And I don't want to end up with another set of BlockArea.baSkyLight flags, those didn't work too well.
Posts: 4,628
Threads: 115
Joined: Dec 2011
Thanks: 693
Given 494 thank(s) in 423 post(s)
In that case I like wrapping the arrays into a structure the most.