fix(ServerDataSyncer): reset quires correctly if op level changed

[zly2006]

rename TWEAK_SERVER_ENTITY_DATA_SYNCER to TWEAK_DISABLE_SERVER_DATA_SYNC.

fix recheckOpStatus so pendingQueries expires correctly if op level updated.

[sakura-ryoko]

I'll test it out myself or make changes before posting as a release

[sakura-ryoko]

I moved it to " TWEAK_SERVER_DATA_SYNC " because I think having it "disable" the feature would be confusing to players, if there are no other "tweak" settings that "disables" a tweak. It still works this way, and I will cleanup the debug messages.

I've also moved the "setWorld" mixin to the proper WorldLoadHandler location.

[sakura-ryoko]

I'm also adding a translatable action bar message for when you are not an operator

[zly2006]

HI @sakura-ryoko what about to move ServerDataSyncer to malilib? so both tweakeroo and minihud (to display the correct bees count in beehives) can use it

[sakura-ryoko]

HI @sakura-ryoko what about to move ServerDataSyncer to malilib? so both tweakeroo and minihud (to display the correct bees count in beehives) can use it

Malilib is meant to be a library / interface for other mods, and not actionable systems... I believe the idea is to eventually create something like this under servux to send them the packets whenever asked for any Entity Data;

Then it would be up to the mods themselves to store / cache the data locally for display later.

[zly2006]

So if I want minihud to sync server data to display bees count correctly, do I need to copy the syncer code to minihud?

[sakura-ryoko]

That can be a start, and would require a similar interface for more than just Inventory data ... it would need to have a raw copy of the NBT / Data Components (ComponentMap object); or the BlockEntity itself; where I'm sure there is possibly a better method for this than sending it as an NBT Compound. I know that there is a different Vanilla packet for this, I believe, isn't there ?

If not, a Servux packet / Data Provider can be created for it... It's something on my TO DO list for this.

You can code dig under the JADE mod for this type of setup, would be the idea for MiniHUD. Also, doing so would present a new change to the existing Network API to include the new IClientPayloadData / IServerPayloadData interfaces as an option upon packet reception for other dependent mods to use the same data channel.

Since it's that much work, is why Masa left it for the "post-rewrite" code.

[sakura-ryoko]

In any case, I just pushed a "share-able" data channel interface update for malilib sakura.4, and working on a similar thing for servux; but would need to build the data provider also.

https://github.com/sakura-ryoko/malilib/releases/tag/1.21-sakura.4

The working code set will be under servux feature branch here:

https://github.com/sakura-ryoko/servux/tree/fabric_1.21-block_entities

And will make a minihud feature branch under the same name once the Data Provider is built.

[sakura-ryoko]

So, a "basic" skeleton for a Block Entities Data provider has been built. It needs a way to scan for block entities located nearby the players that it tracks.

[sakura-ryoko]

And of course Building the related Data Provider under MiniHUD before trying to implement anything. The Data Components usually has a "encode()" function under every BlockEntity class that converts it into a NBT Element / PacketByteBuf for sending over the network; which is sort of the functions that the DebugEntityData packets uses.

The general idea is that Servux can send the Clients this data without having OP, and automatically on a fixed timeout tick schedule based on the Server's view distance ?

[sakura-ryoko]

See Also:
https://github.com/sakura-ryoko/minihud/tree/pre-rewrite/fabric/1.21-block_entities

Maybe it can be copied to an "Entities" channel, as opposed to just being called "block_entities", but I wasn't sure in terms of making a setting to enable / disable them separately.

[sakura-ryoko]

You can of course aid with the coding of this, such as the "Block Entity" implementation to sync the data over the Servux protocol.

Basically, the "REQUEST_DENIED" handling is intended for a permissions issue, or in the case of the data provider being unable to obtain the data for whatever reason, like a failure condition.

[sakura-ryoko]

The overall idea would be to query the BlockEntityData for data if the Block Entity Data isn't available, it will request it from Servux; and Servux will periodically update it on a fixed timer schedule automatically as the player moves around the world.

A Data Query "Refresh" might occur if say, the player "Interacts" with the Block Entity, and needs the most up to date information, and Servux will send it if the data has changes.

[zly2006]

The overall idea would be to query the BlockEntityData for data if the Block Entity Data isn't available, it will request it from Servux; and Servux will periodically update it on a fixed timer schedule automatically as the player moves around the world.

A Data Query "Refresh" might occur if say, the player "Interacts" with the Block Entity, and needs the most up to date information, and Servux will send it if the data has changes.

I dont think servux should send the data to client actively. Because block entities data are usually large, it may cause heavy network traffic. I think there should be two c2s packets, one for query entity/te data, one for subscribing the data, which make the server sync data to the client immediately when the target block/entity changes (mixin to markDirty).