Refactor natural block dropping - #3532
Conversation
abaca9c to
b88cdfb
Compare
…opNaturally` function
b88cdfb to
3c49964
Compare
| @as(f32, @floatFromInt(pos[0])) + model.min[0] + main.random.nextFloat(&main.seed)*(model.max[0] - model.min[0]), | ||
| @as(f32, @floatFromInt(pos[1])) + model.min[1] + main.random.nextFloat(&main.seed)*(model.max[1] - model.min[1]), | ||
| @as(f32, @floatFromInt(pos[2])) + model.min[2] + main.random.nextFloat(&main.seed)*(model.max[2] - model.min[2]), | ||
| }; |
There was a problem hiding this comment.
Could we maybe include this as another case into the Location?
I think it would be nicer to only have a single drop function, with everything else being configured through its parameters.
There was a problem hiding this comment.
Ohh I hadn't made that connection, I'll try it out
|
Before I continue, I need your feedback on a direction I want to take this in. See the last commit Now that we have allowed/forbidden tool tags on drops, we can get rid of the Instead of passing a list of block drops directly to the decay callback, we can instead rely completely on the drops defined on the block itself. That would mean you'd always treat decay as if you're breaking the block by hand. Currently, any block that can decay already works like that It makes sense to me, but I'm wondering if you still see any value in allowing the caller to define custom drops in the callback |
IntegratedQuantum
left a comment
IntegratedQuantum
left a comment
There was a problem hiding this comment.
It makes sense to me, but I'm wondering if you still see any value in allowing the caller to define custom drops in the callback
As far as I remember this was mainly a decision because we didn't have any other tools to restrict block drops.
In the future, if we ever ed this capability again, I think it would make more sense to add a mechanism that makes use of the existing tags instead.
Now that we have allowed/forbidden tool tags on drops, we can get rid of the dropNaturally function too on the BlockDrop by letting decay also use Context
Yes, please, but do note that it should still give each stack a new random poisition.
| } | ||
| const model = params.block.mode().model(params.block).model(); | ||
| const location = BlockDrop.Location{ | ||
| .normalDir = main.vec.normalize(main.random.nextFloatVectorSigned(3, &main.seed)), |
There was a problem hiding this comment.
Ideally all item stacks should have a randomized direction, not one direction for all of them.
3 participants
Progress towards #2385
Related to #3533
Is about
decayand thecheck_support_blockcallbacks