[AAA] Part 3 Item callbacks by Wunka · Pull Request #2898 · PixelGuys/Cubyz

Wunka · 2026-04-12T17:32:11Z

This PR will add ItemCallbacks
For now this will only contain onLeftClick

Requires: #2891

What needs to be done before this PR is ready:

add the execution of the callback at all relevant places
move breaking of blocks in a callback
move special wand mechanic into a callback
remove testing callback

Wunka · 2026-04-14T07:57:00Z

@Argmaster I will have to look over the code again to remove some things like the temporary zon creation. But I would like your input for the general structure atleast.

Argmaster · 2026-04-14T19:34:13Z

-	damage: f32,
+	properties: [@typeInfo(ProceduralItemProperty).@"enum".fields.len]f32 = @splat(0),

 	durability: u32,


I think we should consider replacing durability field with timesUsed or something alike, basically reversed durability, so when a tool gets balance changes it doesn't show up funny. Would have to be clamped at zero and tool with zero durability would have to break instantly.

ofc out of scope

Wouldn't that mean that for example if a player has an item wich has like 300 timesUsed and we reduce through an update the maxUsage to something below 300, then the item would just break instantly on joining the world.

We break items only when they are used.
But yes, general intention is to make the item asap.

Argmaster · 2026-04-14T19:59:11Z

+	item: main.items.Item,
+	target: union(enum) {
+		block: struct { block: Block, blockPos: Vec3i },
+		entity: *main.server.Entity,


I think these may not be mutually exclusive.
A scythe, or a large axe may do AOE damage, what then? (Hitting multiple blocks or entities and blocks)
Should we even do that inside the callback or outside of it?
Additionally it may be very useful to get the source player as a parameter and source inventory too.
Although that last thing has no use for now, so that's something to ignore for now.

Honestly I would remove the target completely and instead provide tools to query the possible target from MeshSelection if the callback cares to do so. This means the params need to be extended with everything required for such query.

I removed it. callbacks now get the selectedBlockPos which they (if it is not null) can be used to query the block. This also already helped calls because the selection wand doesn't care about the block only its position

Argmaster · 2026-04-14T20:04:48Z

 	}

-	pub fn breakBlock(inventory: main.items.Inventory.ClientInventory, slot: u32, deltaTime: f64) void {
+	pub fn breakBlock(inventory: main.items.Inventory.ClientInventory, slot: u32, _deltaTime: f64) void {


I think you should eliminate the chain of jumps before this call.
Currently you are jumping game.breakBlock -> Inventory.breakBlock -> renderer.MeshSelection.breakBlock -> <onLeftClick callback> for no reason IMO I think it should just call left click callback directly from game.breakBlock.

but the game.breakBlock has no access to selectedPos I think the call order is ok.

Eh alright, then I guess there is unfortunately a reason. I will have a look at this when I have time to maybe find a better way around this.

Argmaster · 2026-04-14T20:06:07Z

-	pub fn breakBlock(inventory: main.items.Inventory.ClientInventory, slot: u32, deltaTime: f64) void {
+	pub fn breakBlock(inventory: main.items.Inventory.ClientInventory, slot: u32, _deltaTime: f64) void {
+		var deltaTime = _deltaTime;
 		if (selectedBlockPos) |selectedPos| {


I think breaking animation should be handled inside the callback. You may want to extract it as helper function, but it should be called from inside the callback. There might be tools that don't remove breaking animation.

that means callbacks would need a finsish method right? How would they else know that the they can remove the animation

No? I think no.
This is clearing braking animation when you start braking different block.
Since this callback calls into updateBlock sync call, you can do stuff before and after it too, so you can also clear it after brekitn a block.

Argmaster · 2026-04-14T20:08:29Z

 	var selectionFace: chunk.Neighbor = undefined;
 	var lastPos: Vec3d = undefined;
-	var lastDir: Vec3f = undefined;
+	pub var lastDir: Vec3f = undefined;


I don't think it should be made public; ~~this should be a parameter to callback. Preferably inside a struct alongside lastPos as playerOrientation or alike.~~ Callback should receive current player position and direction and should figure out storing that. Then the callback should figure out storing that, no?

is now given over callback

Argmaster · 2026-04-14T20:14:24Z

 	}

-	fn updateBlockAndSendUpdate(source: main.items.Inventory.ClientInventory, slot: u32, pos: Vec3i, oldBlock: blocks.Block, newBlock: blocks.Block) void {
+	pub fn updateBlockAndSendUpdate(source: main.items.Inventory.ClientInventory, slot: u32, pos: Vec3i, oldBlock: blocks.Block, newBlock: blocks.Block) void {


No you don't. This function makes no sense as part of public API of renderer. Renderer does rendering, it doesn't send updates. Move it or call executeCommand.

I have to look how I will exactly handle this.

Argmaster · 2026-04-14T20:15:12Z

-	var currentBlockProgress: f32 = 0;
-	var currentSwingProgress: f32 = 0;
-	var currentSwingTime: f32 = 0;
+	pub var lastSelectedBlockPos: Vec3i = undefined;


This should be managed by callback implementation IMO. MeshSelection may have its own use cases for it (does it?) but even then it shouldn't share it with everyone.

breakBlock seems to use it without reason, in the cases it uses it, it should be the same as selectedPos. I atleast didn't notice any difference in breaking animation.

IntegratedQuantum

I'm not sure where to start here, but I think this is a bit of a step in the wrong direction.

First up, all player actions should be synced with the server to avoid cheating, so the item callback should be executed in the context of a sync command (see also #2381).
This is also important, since otherwise actions can happen out of sync (e.g. the way it's currently implemented the selection wand action and a world edit command may happen out of order since one is happening in the render thread, while the other is deferred to the next server tick as part of the sync system)

Secondly, all the animation state should be shared through an inventory component (@RanPix @tillpp maybe you already have something planned for this?), furthermore the current swinging system is planned to work differently, instead of only progressing when you keep the button pressed, a started swing should end even if you release the button (see also #1137).
In total I'd suggest to for now keep block breaking untouched, but only run it if there is no other successful callback.

Lastly, together with the points above: The callback should not know the deltaTime.

IntegratedQuantum · 2026-04-30T14:20:51Z

 pub const BlockTouchCallback = Callback(struct { entity: *main.server.Entity, source: Block, blockPos: Vec3i, deltaTime: f64 }, @import("block/touch/_list.zig"));

+pub const ItemUsedCallback = Callback(struct {
+	item: main.items.Item,


Should pass the inventory slot, so you can run useDurability and similar commands on it.

IntegratedQuantum · 2026-04-30T14:26:14Z

Also it might be worth considering to also pass the name of the keyboard key, this would make it easier to add other keybinds (at least right click and middle click are on the table for the base game)

Argmaster · 2026-04-30T17:59:24Z

I am not sure if I understand.
I assumed we are aiming for similar interface as touch callback, where we would call into sync system as we need.
With this assumptions I cannot agree that this PR is a step in wrong direction, as only thing it does is moving existing logic into our callback framework, which I find very much aligned with what I imagined.
Yes, the logic of using tools requires a complete overhaul, as mentioned in our discussion #2892 (review) but changing that is waaaay beyond what one PR can do (we already have 300 lines of changes). IMO its starting angle as good as any other.

In the long run, I imagined that those callbacks will be client side key stroke handlers and they will invoke sync system.
In a subsequent PRs we would add block damage tracking and corresponding sync commands. After that we would refactor breakBlock.zig so all that remain in it would be logic that prevents us from sending sync commands every time player spams the left click button. Malicious client can still DDOS us with those, so we will have to check it properly on server side, but we don't want to DDOS ourselves by default. I assumed similar logic will be needed every now and then.

Some more stuff that might want to be outside sync:

UI opening
not-implemented call to server
different sync commands depending on modifiers

IntegratedQuantum · 2026-04-30T19:54:20Z

touch callback also must be synced in the future together will all other player input, and I think at this point we should not introduce more callbacks that don't use the sync system, to make this rewrite harder than it already is.

In the long run, I imagined that those callbacks will be client side key stroke handlers and they will invoke sync system.

If the callback triggers a health increase, then how can the server verify that you actually are allowed to increase your health? Furthermore there is a bit of a synchronization issue, if another player places a cactus in your path, then you should take damage, even if your client didn't see it yet. That is only possible if the server evaluates the callback

I don't really get the DDOS concern, 1 packet per frame is already a given, and a few bytes more wouldn't make a difference there.

UI opening

Should be synced, so that when e.g. another player breaks your workbench, then the client can just roll back and close the UI (instead of the server having to tell the client about it).

tillpp · 2026-04-30T20:15:05Z

all the animation state should be shared through an inventory component

We want to store animation Data in the model component.
(no idea what this entire conversation is about, i've got pinged here)

Wunka added 10 commits April 12, 2026 13:01

move properties to array

55cdb55

remove mass

17571af

use getProperty and getPropertyPtr

8c4431c

didnt need that

47a1d20

fix order

ee84887

add onLeftClickCallback for items

69e32ba

remove prints

3925671

selection wand leftCLick

a987185

moves but still bugs

3e2675c

remove test callback

cba0b16

Wunka marked this pull request as ready for review April 13, 2026 19:33

Wunka changed the title ~~[AAA] Item callbacks~~ [AAA] Part 3 Item callbacks Apr 13, 2026

Argmaster self-requested a review April 14, 2026 08:09

Argmaster reviewed Apr 14, 2026

View reviewed changes

Comment thread src/items.zig

Argmaster reviewed Apr 14, 2026

View reviewed changes

Argmaster mentioned this pull request Apr 18, 2026

Add onBlockUpdate callback to modifiers and items #2892

Open

Wunka added 4 commits April 18, 2026 15:39

setProperty with assert

d54f78e

forgot one

3fa09e5

give finished a more telling name

d279413

edit desc

a582b44

Wunka added this to PRs to review Apr 19, 2026

Wunka moved this to WIP/not ready for review in PRs to review Apr 19, 2026

Merge branch 'AAA-Properties' into AAA-callbacks

26a054f

Wunka added 4 commits April 24, 2026 18:58

Merge remote-tracking branch 'upstream/master' into AAA-callbacks

c65bd27

make callback calls more streamlined

5b37cb3

move away from target

6706606

change lastSlected to selected

4578695

DellieDelta mentioned this pull request Apr 25, 2026

buckets to handle fluids in survival #627

Open

Wunka moved this from WIP/not ready for review to High Priority in PRs to review Apr 27, 2026

IntegratedQuantum requested changes Apr 30, 2026

View reviewed changes

IntegratedQuantum moved this from High Priority to In review in PRs to review Apr 30, 2026

Uh oh!

Conversation

Wunka commented Apr 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Wunka commented Apr 14, 2026

Uh oh!

Argmaster Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Argmaster Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Argmaster Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Argmaster Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Wunka Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Argmaster Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

IntegratedQuantum left a comment

Choose a reason for hiding this comment

Uh oh!

IntegratedQuantum Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

IntegratedQuantum commented Apr 30, 2026

Uh oh!

Argmaster commented Apr 30, 2026

Uh oh!

IntegratedQuantum commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tillpp commented Apr 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Wunka commented Apr 12, 2026 •

edited

Loading

Argmaster Apr 14, 2026 •

edited

Loading

Argmaster Apr 14, 2026 •

edited

Loading

Argmaster Apr 15, 2026 •

edited

Loading

Argmaster Apr 14, 2026 •

edited

Loading

Wunka Apr 24, 2026 •

edited

Loading

Argmaster Apr 14, 2026 •

edited

Loading

IntegratedQuantum Apr 30, 2026 •

edited

Loading

IntegratedQuantum commented Apr 30, 2026 •

edited

Loading