Laike_Endaril

If I understand correctly, yes, that was the goal. At the time I was to preoccupied to consider the fact that this is a forge forum and not a sponge forum In any case, hopefully the "like" on my post above with a sponge forum thread link means it's solved, but if not, then yeah, this would probably be better off on the sponge forums

@The_Wabbit This thread is about a completely different environment, not forge 1.13. You should probably open a new thread asking for the new equivalent to setMaxStackSize, since it doesn't quite fit in this topic (note: I don't know the new naming, as I haven't done anything on 1.13 yet).

Take a quick look at this when you get a chance; it seems to provide a way to get the raw NBT in sponge. Just don't quote me on it, since I don't have any sponge experience: https://forums.spongepowered.org/t/how-to-get-and-change-nbt-of-an-item-simple-pls/14269/6

Unfortunately, I only have experience with the "normal" forge mod dev environment. Does your current environment not have *any* kind of mappings in use? Because if that's the case, I'd start by burning it in holy fire. Doing normal mod work using fully obfuscated names would be absurd (unless you had some very special reason for doing so). Just to be clear, SRG mappings look something like "field_110275_br", while the corresponding MCP mapping is "horseJumping". I'm not even sure what the unmapped version of that particular field would be.

If you're trying to add someone else's block, I suggest not doing so. It can lead to more confusion than making your own. I'd find a simple block tutorial first. Make sure it extends Block directly and not BlockBase. If anyone sees this and can suggest a good block tutorial, that would be great. I mostly do game mechanic mods.

That looks fine to me at a glance. Run the game from your dev environment and see if the redstone flux mod shows up. Have you already gotten a basic block working as well? Edit: When I say "that looks fine", I mean that if the gradle repositories and dependencies are working correctly (not mistyped, etc), you should not need anything else related to RF, afaik. If you wanted to use the jar file as a dependency *instead*, you could do that, but I wouldn't do both at the same time

You can't afaik. I would repost this in the modder support forum, then leave a reply here, on this thread, saying you've reposted it there (with a link to the new one). That should take care of redirecting any potential replies. Then, if a forum moderator sees this, they can just lock it instead of moving it for you. Edit: Also, here is the correct forum, just to be sure: http://www.minecraftforge.net/forum/forum/70-modder-support/ Edit2: This has been reposted on the correct forum:

I would do these things first, if you haven't already... 1. Make a mod that does nothing and confirm it works (shows up in the mod list in-game) 2. Make a basic block that does nothing 3. Make the block look how you want 4. Add the "Redstone Flux" mod as a dependency, and make sure it shows up correctly in the mod list in-game Ie. get all the basics out of the way first before trying to add any cross-mod functionality. Once you have all these things done (one at a time!) then your foundations are in place to start tinkering with RF blocks (unless I missed something)

While I haven't looked into the actual code for it, I believe MC entities are only tied to a single chunk (ie. the chunk containing their origin point), which would cause these kinds of issues (based on several related forum/chat posts I've seen). Also, based on how the collision detection and several other systems work... Going along with the "I've seen posts of" line of thought, I've seen several posts suggesting to do as DavidM said, and split your entity into smaller parts, basically improving the "granularity" of what's culled due to chunk culling. Edit: I believe for entities which are holding still, you could just split the entity into one part per chunk, if you get my drift. For large moving entities, I'm guessing it would be better to have a pre-defined set of parts instead of trying to constantly recalculate entity sections based on chunk boundaries in relation to the entity

I am doing this in my Dynamic Stealth mod, but it's quite hacky iirc...it's been a little while since I looked at that code. I'll post a link and you can play with it. https://github.com/Laike-Endaril/Dynamic-Stealth/blob/1.12.2/src/main/java/com/fantasticsource/dynamicstealth/client/RenderAlterer.java

Figured it out by scraping through the tooltip render code. In GuiConfigEntries.java: comment = I18n.format(configElement.getLanguageKey() + ".tooltip").replace("\\n", "\n"); So if you have a lang key defined for a config setting / category, then the proper lang key for the tooltip / comment for it is the same, but with .tooltip appended, eg. dynamicstealth.config.serverSettings=Server Settings dynamicstealth.config.serverSettings.tooltip=Server Settings Tooltip This might be a good thing to note in the related forge documentation page, as it currently makes no mention of this functionality or the syntax for it.

We can use @Config.LangKey to specify lang keys for config setting / category names, but does the annotated config system have support for localization of config comments? If so, what's the syntax of the reference and the lang key? If not, how would you go about accomplishing this?

registerBlock(121, "end_stone", (new Block(Material.ROCK, MapColor.SAND)).setHardness(3.0F).setResistance(15.0F).setSoundType(SoundType.STONE).setUnlocalizedName("whiteStone").setCreativeTab(CreativeTabs.BUILDING_BLOCKS)); Try 15 instead of 45

@Fusseel Not sure if you already tried it or not, but I just got around to doing more testing and it seems the trigger I based my DSoundEvent on doesn't catch all sound events. I need to do more R&D. To be more specific, I noticed it not catching block breaking sounds from myself while in single player mode. I haven't gotten to do much testing yet. In any case, the current version of DSoundEvent is not a catch-all, unfortunately

Registering stuff in the registry events specifically designed for registering blocks, items, etc. is usually best practice unless you have a good reason to do otherwise (you'll know if you run into that kind of situation). Using the registry events generally puts things in the right execution order "automagically", as well as letting other modders predict when certain things will happen in a general sense even if they've never seen your source or don't even know your mod will be running alongside theirs (eg. if they're altering something fairly global). As for when you create the stuff...you'll get varied answers. I usually try to create whatever I'm going to register directly in the registration call if doing so is feasible. Edit: Righto, I should've posted what Ugdhar did, but I'm half asleep and didn't think of it

EnumHelper.addToolMaterial() and EnumHelper.addArmorMaterial() might be good to look at. You're just doing tool/armor materials right? If you need a block material as well, it uses a different approach. All 3 are different things.

https://minecraft.curseforge.com/projects/fantastic-lib/files/2686512 The world events mentioned in the changelog there include a few for sounds. The event you'd want from the library is DSoundEvent Feel free to ping me if you decide to use it and find an issue / need more information

I've actually been looking into the same thing for a server-side system, but unfortunately the existing systems don't track the entity that made the sound (except for one circumstance which only ever allows for instances of EntityPlayer to be tracked). In Entity.java: public void playSound(SoundEvent soundIn, float volume, float pitch) { if (!this.isSilent()) { this.world.playSound((EntityPlayer)null, this.posX, this.posY, this.posZ, soundIn, this.getSoundCategory(), volume, pitch); } } Edit: I've just finished implementing a workaround in my library; custom event which actually includes the entity the sound came from. When I finish the current version of the library I'll post a link in case you decide to use it.

It should be a quick and easy project for someone who already has a mod environment set up. I'll start work on it today. Edit: Scratch that, someone already made it: https://minecraft.curseforge.com/projects/scavenge?gameCategorySlug=mc-mods&projectID=282988 It looks like that mod should be able to do what you want. It has a bunch of addon mods too, though I didn't look through them.

I'm pretty sure you're right. I guess one way of circumventing this might be to schedule a server task from the event. The timing for a task that happens "soon" should be fine if you're just altering sign text or something. FMLCommonHandler.instance().getMinecraftServerInstance().addScheduledTask(() -> { //Do stuff }); You should only call this from the logical server. Not sure if there's a better way to access it or not.

I haven't touched loot tables yet in any of my mods, but I just found this inside the LootTable class: public static class Serializer implements JsonDeserializer<LootTable>, JsonSerializer<LootTable> { public LootTable deserialize(JsonElement p_deserialize_1_, Type p_deserialize_2_, JsonDeserializationContext p_deserialize_3_) throws JsonParseException { JsonObject jsonobject = JsonUtils.getJsonObject(p_deserialize_1_, "loot table"); LootPool[] alootpool = (LootPool[])JsonUtils.deserializeClass(jsonobject, "pools", new LootPool[0], p_deserialize_3_, LootPool[].class); return new LootTable(alootpool); } public JsonElement serialize(LootTable p_serialize_1_, Type p_serialize_2_, JsonSerializationContext p_serialize_3_) { JsonObject jsonobject = new JsonObject(); jsonobject.add("pools", p_serialize_3_.serialize(p_serialize_1_.pools)); return jsonobject; } } Just don't ask me how to use it If you find existing usages of the deserialize method, you might be able to figure out how to use it correctly.

It's very doable with a "full" (but fairly simple) mod. If there is an existing mod out there which can already do this using a config or scripts, I don't know about it. The way to do it is to subscribe to PlayerInteractEvent.RightClickBlock, then filter for your wanted block type(s) and have it create and drop the items in-world (or give them directly to the player). Can also destroy the block from there if you want. Btw, was this a mod request, or just a request for info so *you* can make the mod?

Your BlockItem for the permit writer is being created from a new instance of your Block instead of the one in the registry. You already have a public static field in ModBlocks with the ObjectHolder annotation, which basically means once the registry name on that annotation is registered (ie. when you register the block part of the writer), you can thereafter reference that field to create the proper BlockItem. In your case, this amounts to a very minor edit of one file: package casuallobster.permitmod; import net.minecraft.block.Block; import net.minecraft.item.Item; import net.minecraft.item.ItemBlock; import net.minecraftforge.event.RegistryEvent; import net.minecraftforge.fml.common.Mod; import net.minecraftforge.fml.common.event.*; import net.minecraftforge.fml.common.eventhandler.SubscribeEvent; import static casuallobster.permitmod.ModBlocks.blockPermitWriter; @Mod.EventBusSubscriber public class CommonProxy { public void preInit(FMLPreInitializationEvent event) { } public void init(FMLInitializationEvent event) { } public void postInit(FMLPostInitializationEvent event) { } @SubscribeEvent public static void registerBlocks(RegistryEvent.Register<Block> event) { event.getRegistry().register(new BlockPermitWriter()); } @SubscribeEvent public static void registerItems(RegistryEvent.Register<Item> event) { event.getRegistry().register(new ItemPermit()); event.getRegistry().register(new ItemBlock(blockPermitWriter).setRegistryName(blockPermitWriter.getRegistryName())); } } Changed areas are one line of code cleanly removed from registerItems() and one new import. Also removed one unused import, just because. As far as best practices go, I don't know them for sure in this respect. All I can say is that it loads the textures.

And here is a minimal patch with replacement files that will load the texture. These changes were applied to the "initial commit" version of your online repo (in case your current project does not match said commit). Batteries and correctness sold separately! But you may find it useful for reference. It would probably still be a good idea to go through your entire project over again as David said. Middle_Earth.1.12.2-0.0.1.0-patch.zip

If you're trying to do something that changes at a constant rate over time, you can do it using timestamps. What exactly is the goal?