-
Posts
304 -
Joined
-
Last visited
-
Days Won
3
Posts posted by Alpvax
-
-
You've commented out the event listener (ModelBakeEvent) which actually instantiates your custom model (in BlocksMod.java).
-
Check out TheGreyGhost's MBE04: Dynamic_block_models. It does almost exactly what you want (make sure you understand, not just copy-paste).
-
That is the only way. All blockstates are calculated on registration, so there is no way to save that to a single blockstate.
If there are that many, you may need to rethink your approach.
You could maybe store a chunk capability with a map of blockpos -> blockstate, but I'm not sure that would save you much (after all, that is what the world saves). And you'd have a much harder time sorting out the rendering.
-
I'm assuming big-endian. But TBH, I thought the byte order was part of the UTF-8 spec. I've never seen it called UTF-8 BE.
-
You could try looking at how the vanilla /fill command does it. I'm not sure how optimised it is.
-
Should probably be a new topic, as it's a different issue.
I believe it is the same as the undyed version. The dye is saved in the NBT.
-
On 9/20/2020 at 6:16 PM, diesieben07 said:
In your case I would only send "player scrolled X amount", not e.g. "move stack A from A to B".
I'm not fully convinced of that. You should send "player scrolled X slots", that way the actual scroll amount per slot can be configured client-side.
-
It is also possible to use NBT tags to create swords which have custom attributemodifiers and models in order to have more than the usual sword types.
It can be done with any item, but you cannot add new functionality and behind the scenes they are still the vanilla sword item.
See https://minecraft.gamepedia.com/Model#Item_predicates for more info on custom models (uses an NBT tag to select which model override to use).
-
I saw, thank you.
I'll hopefully test it tomorrow, but it looks good.
I've never managed to get my head around this, so thanks for helping.
-
Alpvax/AdvancedAutocrafting 1.16_wireTEs branch
TileEntity: block.tile.WireTileEntity
Block: block.WireBlockV2
The model stuff is in client.data.model.
-
11 hours ago, diesieben07 said:
Call requestModelDataUpdate client-side
11 hours ago, Alpvax said:the end of handleUpdateTag
I already do call it client side.
I have now removed the server side call, but nothing has changed.
-
Even closer now.
I do not want to update neighbours, as the property is changed from Block#neighborChanged, and I do not want to cause an infinite loop.
//Called after updating property BlockState blockState = getBlockState(); //Do not update neighbours getWorld().notifyBlockUpdate(getPos(), blockState, blockState, Constants.BlockFlags.BLOCK_UPDATE | Constants.BlockFlags.RERENDER_MAIN_THREAD); requestModelDataUpdate();
I also call requestModelDataUpdate at the end of handleUpdateTag.
The data is now correct on the client (displayed when right clicked), but the render is always 1 step behind (Only updates once another block is placed).
-
Almost fully working.
Only thing I'm now struggling with is forcing my TileEntity to sync.
I'm calling markDirty and requestModelDataUpdate after changing the property, but the client side data doesn't refresh until I close and reopen the world.
Do I need to send a custom packet, or is there an easier way of forcing a resync?
-
Perfect, thank you.
I'll give that a go and return if I run into any issues.
-
I am in the process of converting my existing blockstate based model to a tileentity due to excessive use of blockstates (4-value EnumProperty for each direction = 4096 + waterlogged = 8192 permutations!)
I have an existing (generated) multipart blockstate json, is there any way to easily convert it to the same model, just using the data from the tileentity instead of the blockstate?
I'm assuming I need to create a custom BakedModel, but I would ideally like to keep the current data-driven approach (one model for each of the 4 enum values).
It's the first time I've started looking into custom models, and I think a TileEntityRenderer is overkill for static models. Please correct me if I'm wrong.
-
Can we add this question to a FAQ/EAQ somewhere obvious?
It is the most requested suggestion I have seen by far.
Although I suppose that people requesting it probably haven't read FAQs.
-
You haven't understood what Draco and I told you.
minecraft:carnivores is a completely unrelated tag to mymod:carnivores. There is no link between them AT ALL. You need to make a single tag (maybe myanimalmodid:carnivores), then for each of your expansion mods, you add to THAT tag. Not to a different tag for each mod.
- 1
-
If you are really desperate to share your resource packs, I believe that using symbolic links should work.
-
6 hours ago, frakier said:
"resources\data\minecraft\tags\items\carnivore.json"
6 hours ago, frakier said:"resources\data\mymod\tags\items\carnivore.json"
These are 2 different tags ("minecraft:carnivore" and "mymod:carnivore" respectively).
You should make 1 tag "mymod:carnivore" and add all the defaults to it (as in all the vanilla items, and your custom items if applicable), then if you want to add items in another mod, you also define the "mymod:carnivore" tag (not the "mysecondmod:carnivore", again that would be a different tag).
As an extension on what draco said, the only time you should put tags in the minecraft domain is if you are overriding/adding to an existing vanilla tag.
-
17 hours ago, BlockyPenguin said:
[ "one": {
That is not valid json. Currently you have an array with keys.
Either it should be an array of objects "[ { ..." or it should be an object with keys of "one, two,...".
I would suggest going for the first option (especially as that is what you support in your code):
17 hours ago, BlockyPenguin said:JsonArray jsonSteps = jsonMethod.getAsJsonArray("steps");
- 1
-
Worked around the issue by double unchecked casting the type:
public abstract class IOType<T> extends ForgeRegistryEntry<IOType<?>> { @SuppressWarnings("unchecked") public static final Class<IOType<?>> CLASS_GENERIC = (Class<IOType<?>>)((Class<?>)IOType.class); } //Can then be used as follows public static final DeferredRegister<IOType<?>> IO_TYPES = DeferredRegister.create(IOType.CLASS_GENERIC, MODID);
By putting the constant in the API class, it can be used by others who are consuming the API.
- 1
-
DeferredRegister has been updated recently to make it work with custom registries, but it still doesn't work with custom generic RegistryObjects (similar to TileEntityType<T>).
When trying to create the DeferredRegister, it errors with:
QuoteRequired type: DeferredRegister<IOType<?>>
Provided: DeferredRegister<IOType>
Incompatible equality constraint: IOType<?> and IOType//Registry public static final DeferredRegister<IOType<?>> IO_TYPES = DeferredRegister.create(IOType.class, MODID); //IOType.java (currently just a stub) public abstract class IOType<T> extends ForgeRegistryEntry<IOType<?>> { }
Is there a workaround for this issue, or can I just not use DeferredRegister? This will be available in an API, so I would ideally be able to support the more popular DeferredRegister approach.
Removing the parametised type (DeferredRegister<IOType> IO_TYPES = ...) then throws the error of IOType not implementing IForgeRegistryEntry<IOType>, so that isn't a fix.
I am wondering if the only workaround is to make the registry in a static initialiser (and overriding it in the NewRegistryEvent), but that seems like a step backwards.
Does anyone have any suggestions?
-
I believe that the last time I looked into doing something similar, I decided to make my HashMaps per-chunk to prevent this issue.
-
What are you actually trying to achieve for the players?
If you want a slime block, register a new SlimeBlock.
Block method differences: updatePostPlacement, onNeighborChange, neighborChanged
in Modder Support
Posted
There are 3 methods which sound like they do something very similar, overridden by various different blocks:
My question is which method should be overridden for what purpose, as many of the call paths are similar. I have spent quite a bit of time trying to trace the call paths and have become lost multiple times.
I was using neighborChanged, but switched to using updatePostPlacement (as that already supplies the direction, and sounds more like what I needed (making connections between blocks)). The effect in-game did not change, so I am wondering when I should be using each of these methods.
There is also the following forge-added method, which doesn't appear to be overridden anywhere, and is only called by the blockstate method of the same name, which is itself not called: