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