Cinderous

Using 1.16.1 /forge setdimension always leaves behind a nether portal when going to nether or custom dimensions. Is there a way to teleport without the portal logic? Ive tried making an item that uses teleport from ServerPlayerEntity but it operates in the same way. I used to use my own teleporter class which changedimension allowed me to choose if it left a portal behind but this isnt in 1.16.

Thank you ChampionAsh535

I do use deferred registries now, im not a you people though. I simply provided a working solution and stated it was NOT the best way to do so. I apologize for not editing my post out sooner when an example was provided.

Okay, so I registered a treefeature based on the already existing treefeature. I do this so I can specify the block its capable of being placed on. Im using TreeFeature class, but copied to my own class so I can modify the settings. I can get my tree to spawn in my biome just fine, the only problem is every tree that gets placed changes the base block it was formed on back to dirt. I dont want some random dirt blocks in my biome, because I use a different block.Here is the only referrence in TreeFeature to dirt, which ive changed to allow my tree to place on my special dirt. private static boolean func_236418_g_(IWorldGenerationBaseReader p_236418_0_, BlockPos p_236418_1_) { return p_236418_0_.hasBlockState(p_236418_1_, (p_236409_0_) -> { Block block = p_236409_0_.getBlock(); return isDirt(block) || block == Blocks.FARMLAND || block == CinderbaneRegistry.CINDIRT.get() || block == CinderbaneRegistry.CINDIRT_GRASS_BLOCK.get(); }); } Although, because mappings arent this far done yet I cannot find the function that is replacing the base block with dirt. As seen here : Has anybody had any success with changing this?

edited to encourage deferred registry usage

This is the main class where I set that public static final ResourceLocation HYPERLANE_DIM_TYPE = new ResourceLocation(MOD_ID, "hyperlane"); And the deferred registry part in my registry handler public static final RegistryObject<ModDimension> HYPERLANE_DIM = MOD_DIMENSIONS.register("hyperlane_dim", () -> new HyperlaneModDimension()); Ive tried using either of these, hyperlane or hyperlane_dim in the condition. Same thing. No matter what dimension, it activates.

So, Ive been stuck on this for a few days and cannot figure out why this is happening. I have a tiered dimension system where you get to one dimension from the other. The advancements are in order. Whenever I change to any dimension, all my advancements that have a dimension change condition are completed. Ive rewritten it dozens of times, checked over other advancements for syntax issues, and I honestly cant figure it out. Ive even tried adding a biome requirement on top of it, but they still fire off. Here a screenshot of it happening : https://i.imgur.com/Bve4DWD.gifv Im lost with why this is happening. Here is an example of one of my advancements regarding the dimension Hyperlane. Each of the the 3 advancements specifically have a condition for the name of the dimension. It makes no sense why other dimensions are triggering them. { "parent": "hyperl:hyperlane_gel_residue", "display": { "icon": { "item": "hyperl:hyperlane_staff" }, "title": { "translate": "advancements.hyperl.hyperlane_staff.title" }, "description": { "translate": "advancements.hyperl.hyperlane_staff.description" }, "frame": "challenge", "show_toast": true, "announce_to_chat": true, "hidden": false }, "criteria": { "entered_hyperlane": { "trigger": "minecraft:changed_dimension", "conditions": { "to": "hyperl:hyperlane" } } }, "requirements": [ [ "entered_hyperlane" ] ] } To see the same looking files, here is my github for the advancements https://github.com/cinderous/Hyperlane/tree/master/src/main/resources/data/hyperl/advancements

The invetory change and blockchange notify can be optimized if you help. But asking around the lag is most likely from the initlization/configuration process of getting information from the item and applying it to specific features of the tile entity. I don't need it to be quick, i just dont want it to bog down for a few seconds while it configures everything whenever a item changes. I guess i need to setup a custom tick handler and do each step after so many ticks, right? That should make it smoother...i Think

MineMaarten, this worked perfect. My problem now is it seems like the server is having issues or my client is having issues. I don't drop in FPS, but i get these weird "frame skips" like im lagging. I think its because my block is saying tis changed too frequently and its causing a lot of useless checks or something. How can i make it do notifyBlockChange only when the invetory is changed? onInvetoryChanged() seems to do other stuff not related to my problem. Will i just have to add the notifyblock to all the methods that move an itemstack into or out of a slot or is there a simple solution I can put into updateEntity to do this with less code everywhere?

Dear folks, I have block that is a tile entity, this tile entity utilizes BuildCraft api to configure sides of the block to become compatible as a power receptor. The pipe works fine when its connected to the pipe and that side is configured "ON", and it works fine if I configure it "OFF", but the problem is the actual Pipe that connects to that side doesn't render that is is no longer connected. If I close my server and reopen it, the pipe correctly renders because it knows that side is no longer valid to be connected to. While the server is running, if you want the pipe to show correctly based on the tile entity's state you must destroy the pipe and replace it. The pipe has a method to detect when neighbor blocks change and will connect/disconnect accordingly. The problem is its not the block changing, its the tile entity. Without changing the pipe which will detect the changed block, how can I force my tile entity to tell the server that the block has changed. Does this make sense? If the server knew the block changed, not the tile entity, this would work fine.

I understand JCubicPart more and can place my notch sized block in the world and can refine it more later. Right now the block renders no texture so I am working to resolve that. So I'm making progress.

Alright so I've been working on a mod for awhile now. I have been without Internet and going from vending machine to vending machine to power up my laptop so I haven't been able to do much research. I am obsessed with ForgeMultipart's capabilities. I've tinkered with my mod and currently working on breaking it apart into the proxies for what I'm assuming is more efficient rendering and resource management of these blocks. I seem to have the very basics down on using JItemMultiPart to create items from parts, but it is half assed. Most mods out their that use Multipart seem to use JCuboidPart and are utilizing blender models to actually fill the block space. I am familiar with blender models and may try this approach, but I'd rather get a much more basic multipart. My goal is to make a notch like from the microblock classes. This will be a notch that will be a tileentity so it will be utilizing the tilemultipart if I'm correct. The reason for this is because I want to utilize a different texture based on how many of this notches are connecting and from where. I don't need help with the logic of that right now as it is a big project for my final result. My question is there has got to be some simple way to create the basic notch from block that utilizes the grid placement. I see some of those functions, however I seem to have more trouble getting an actual notch block than trying to make an ItemPart. I've searched github for code that extends JCuboidPart and really only seem to find chicken's wireless redstone mod as well as project red, both mods utilize multipart well, but they use it to display the multipart as a model and such and its way to complex for my learning experience. Also, I have a question to help optimize the mod later on. I'd rather design the multiparts in notch blocks but may utilize a model in place of one of the notices to create more of a pointed notch, unless this is a capability of JCuboidPart that can create the dimensions from code. The basic end result is a bunch of notches working together with a wedge or pointy tip. I'm not a greedy guy and plan to put my mod up on github so others can learn from whatever I've done. Thanks.