What do the other parameters in setBlock do?

[Turtledove]

I'm updating my mod from 1.16.3 to 1.16.5, and I noticed that the setBlockState method has been replaced with setBlock, but it has two additional integer parameters apart from the standard blockstate and block position arguments. Looking at the implementation of the method didn't help because all the variable names are obfuscated. Anyone have any idea?

[kiou.23]

method signatures did not change, only method names, due to the mappings change
if the method has a different signature, it may not be the method that you are looking for

[Turtledove]

19 minutes ago, kiou.23 said:

method signatures did not change, only method names, due to the mappings change
if the method has a different signature, it may not be the method that you are looking for

...except it clearly did, here's the snippet from 1.16.3, take a look for yourself if you didn't know:

 

and now in 1.16.5:

[Turtledove]

There were several notable changes I noticed refactoring my code from 16.3 to 16.5, not just the above, but also the fact that rotations on the renderer now take quaternions as inputs rather than just a vector representing the rotations.

[Turtledove]

well technically a quaternion IS a vector with just an exra real valued number 

[ChampionAsh5357]

Still hasn't changed. You're referencing two different methods with two difference signatures. The first method you shown calls the second method with the argument 3. As for what it does, it dictates what flags to execute when setting the block (a bit field). The list of flags can be found within Constants$BlockFlags.

[Turtledove]

1 minute ago, ChampionAsh5357 said:

Still hasn't changed. You're referencing two different methods with two difference signatures. The first method you shown calls the second method with the argument 3. As for what it does, it dictates what flags to execute when setting the block (a bit field). The list of flags can be found within Constants$BlockFlags.

...Again, there is literally no function that takes in just two parameters. But anyways thanks for that, I'll look into the flags, never realized it was a thing when blocks are placed.

 

[ChampionAsh5357]

7 minutes ago, Turtledove said:

...Again, there is literally no function that takes in just two parameters. But anyways thanks for that, I'll look into the flags, never realized it was a thing when blocks are placed.

 

Yes there is:

If you expect the method names to be the same across mappings including how they're referenced between methods, you won't find what you are referring to.

Edited April 16, 2021 by ChampionAsh5357

[Turtledove]

5 minutes ago, ChampionAsh5357 said:

Yes there is:

If you expect the method names to be the same across mappings including how they're referenced between methods, you won't find what you are referring to.

I know what it was, I wrote getWorld() as a wrapper method for classes that implement IWorld, but I guess I missed that that method isn't listed as a function in the interface. 0 IQ moment.

[wintermaker]

Ok, so I have a question about these functions in 1.16.5.  I'm trying to do world.setBlock() commands from within an Item use() override.  No matter what function I use (setBlockAndUpdate, setBlock with Constants.BlockFlags.DEFAULT, etc) the blocks appear in the client but disappear when interacted with (apart from collusions).  If I quit and restart, none of the changes were saved.  Blocks replacing other blocks (like grass) go back to the previous block.  This is launching from the Forge MDK runClient configuration.

Are there contexts from which you're not supposed to update the world?  Are you supposed to queue updates for some worker thread/task to handle?  Mark things for update?

ie: world.setBlock(pos.offset(i, y, 5), ModBlocks.MYBLOCK.get().defaultBlockState(), Constants.BlockFlags.DEFAULT);

Most people's questions about setBlock() seem quite straightforward and like it just works for them.

It's almost like a problem passing in immediate variables that get deleted when they go out of scope ... but the few examples I find are using defaultBlockState() and aren't calling new or anything... ?

I can use the ModBlocks.MYBLOCK blocks normally within the game otherwise... as in, place them as in game blocks from creative/survival mode, etc.. they only misbehave from the Item.use() override...

Edited April 20, 2021 by wintermaker

[kiou.23]

16 minutes ago, wintermaker said:

Ok, so I have a question about these functions in 1.16.5.  I'm trying to do world.setBlock() commands from within an Item use() override.  No matter what function I use (setBlockAndUpdate, setBlock with Constants.BlockFlags.DEFAULT, etc) the blocks appear in the client but disappear when interacted with (apart from collusions).  If I quit and restart, none of the changes were saved.  Blocks replacing other blocks (like grass) go back to the previous block.  This is launching from the Forge MDK runClient configuration.

you should make your own threads

 

16 minutes ago, wintermaker said:

Are there contexts from which you're not supposed to update the world?  Are you supposed to queue updates for some worker thread/task to handle?  Mark things for update?

no

 

16 minutes ago, wintermaker said:

It's almost like a problem passing in immediate variables that get deleted when they go out of scope ... but the few examples I find are using defaultBlockState() and aren't calling new or anything... ?

I can use the ModBlocks.MYBLOCK blocks normally within the game otherwise... as in, place them as in game blocks from creative/survival mode, etc.. they only misbehave from the Item.use() override...

we need to see your code. but don't post it here, make a new thread