Laike_Endaril

Or as I'm sure you've guessed, if it's for the server, ServerTickEvent

I just ran into the EXACT same issue as you, Cadiboo. By which I mean that I'm almost 100% sure I know what was causing YOUR issue, for 2 reasons. Posting this for anyone else who comes along. It was your encoding. Need UTF-8 ...WITHOUT...BOM. I was getting unlocalized output... ...so I tried changing my lang file from "UTF-8 BOM" to "UTF-8" (no BOM)... ...and now it works. This also explains the 3 byte difference in file sizes, because BOM adds 3 bytes of data to the file header. Hopefully this saves someone else a bit of time.

Great! Thought that might be the case

For posterity, the code you are looking for is: FMLCommonHandler.instance().getMinecraftServerInstance() Thanks again to VoidWalker!

Sorry, part of that code should have been removed, I was only using the first line to exploit intellJ's Ctrl+B lookup. The actual code there should be: public static boolean isPlayer(Entity entity) { return entity instanceof EntityPlayer; } That is wonderful news. Honestly it's been a while since I did much java, and it used to be horrendously slow, so that makes me feel a bit better. This is extremely helpful, so thank you! I have a lot to say about forge's naming sense though. Anyone using an IDE class lookup will be searching the word "server" and "FMLCommonHandler" is most certainly not going to appear. Was that covered in the forge documentation somewhere? In any case, that's what I was looking for, so thanks again. Right, I meant that the functionality of "MinecraftServer.this" would have been identical accessing a theoretically-once-existed-but-no-longer-does static field within MinecraftServer containing the parent instance. Thanks again!

Edit 3 ====================================================== In general, the answer is: FMLCommonHandler.instance().getMinecraftServerInstance() Credits to VoidWalker for this bit of code End Edit 3 ================================================== If I wanted the integrated server instance on a client, I could use this: Minecraft.getMinecraft().getIntegratedServer() But for a dedicated server, I cannot find any way to obtain the currently running server instance. This train of thought spawned from trying to get the dedicated server and integrated server player lists. Which spawned from trying to determine whether an entity is a player or not WITHOUT using this: public static boolean isPlayer(Entity entity) { Minecraft.getMinecraft().getIntegratedServer() return entity instanceof EntityPlayer; } Honestly, for the mod I'm making right now, instanceof (though slow) is good enough, but for the future, I would really like to know how to get the running server instance. Apparently, there used to be a static accessor: MinecraftServer.getServer() But it no longer seems to exist! There IS a non-static accessor (in MinecraftServer.java): public MinecraftServer getServer() { return this; } But obviously in order to use it, you already need the instance! Isn't this pointless? My best guess is that someone mistakenly changed the static method to a non-static method? Am I missing something here? Sorry for the excitement. Hopefully I'm just missing something obvious. My current forge version is 14.23.5.2768. Edit 1 ====================================================================== With a bit more snooping around in MinecraftServer.java, I found this line (line 976), along with several others similar to it: return MinecraftServer.this.profiler.profilingEnabled ? MinecraftServer.this.profiler.getNameOfLastSection() : "N/A (disabled)"; Notice where it says "MinecraftServer.this...." I'm guessing someone did a find and replace on a static field that used to exist within MinecraftServer which used to reference a field containing the MinecraftServer instance, which would have been set in its constructor? I don't know, but it's really triggering my OCD after looking around for the last few hours. Edit 2 ===================================================================== I also found out that the DedicatedServer constructor is only ever called once, inside the main() method of MinecraftServer, assigned to a method-scoped variable and inaccessible from anywhere else, so how on earth are you supposed to access eg. DedicatedServer::getPlayerList()? I'm really not seeing any way for modders to access the server or playerlist in general?

I just started making a combat tagging mod, so I'm currently dealing with event.getEntity() and getEntityLiving(). I looked at the source code and, at least without other mods being involved somehow, they both return the exact same value (one returns a field named "entity" and the other a field named "entityLiving", and the "entityLiving" field is only set once, in a constructor, and is set to "entity", so they're redundant afaik). Edit 1 ================================================================ I just realized the "entityLiving" field I mentioned is NOT directly being set to the same value as the "entity" field. It is being set by a CONSTRUCTOR ARGUMENT named "entity". That being said, in my case, at least, they still both return the same thing.

Unfortunately I think actually working on your existing code is beyond me; I'd probably have to mess with it for days just to acclimate with that much code, since I'm not used to forge modding yet. Not sure if you're right about the devolution/revolution thing, because if every call to a method recursively calls itself, you're going to crash fast (unless there are some conditions to break the cycle?). Maybe I misunderstood though. But I really do think your issue lies solely in the server not sending the client the new blocks, I just don't have enough experience with minecraft/forge modding to point at a spot in your code. I suppose one thing to keep in mind is that the client doesn't "clear" blocks (set them to air) automagically either, so your server is telling the client that the blocks are air (or possibly null, though I would assume that would cause larger issues if it were the case), but that may just be a little submethod on the backend somewhere when you're eg. replacing a block with another or something. All this is just conjecture and possibly superstition, so take it with a grain of salt. Good luck!

If you're sure the event itself is not firing, maybe your class isn't registered on the event bus? My preferred method is to put this line in the constructor of my class: MinecraftForge.EVENT_BUS.register(YourClassNameHere.class); But there is also a tag that does the same thing. I just can't remember what it is right now. To make absolutely sure you know whether the event is even firing or not (it should fire any time something dies, not just the wither, as you seem to understand already), maybe add a println before your if statement and see if it outputs to console when you kill eg. a pig (if you haven't already tested this)

Well I'd have a better idea if I saw the code, but it sounds to me like the server itself is changing the blocks, but not sending the updated block data to the clients. I know there's a method that does that somewhere (but I've never needed it so don't know where)...maybe it's not getting called correctly. I found this bit of code in one of @Draco18s's examples, which may or may not be helpful to you (and now that I pinged him, he can probably tell you whether it will, if he's not busy): private void sendUpdates() { worldObj.markBlockRangeForRenderUpdate(pos, pos); worldObj.notifyBlockUpdate(pos, getState(), getState(), 3); worldObj.scheduleBlockUpdate(pos,this.getBlockType(),0,0); markDirty(); } And here is a link to the full example https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/entities/TileEntityTanner.java#L94 Edit 1 =================================================== By the way, if it's what I suspect, then having a client log off and on to the server should (temporarily) fix the invisible blocks. I would also think that if the client moves far enough away for the chunks to unload and comes back, that would probably also (temporarily) fix the blocks. If neither of those (temporarily) fix the blocks, then you may be looking at some other issue which I cannot fathom.

I feel like I already tried this, but can't remember for sure, so I'll double check. But before I even try either one again I'll probably throw a println into my BlockFireEdit.fireTick() method and see if it's even being run in my modpack or if the instance of said class itself is being overridden (and not just the settings within it). That would suck... Edit 1 ==================================================== My fireTick() is firing! (Fire joke ha!) ...so that's good. That being the case, it's pretty likely that I was right about the encouragement values being overwritten, though I'll also test to make sure that my tryCatchFire() is acting as expected, just in case (not likely to be an issue there though). Once I have it working with my modpack I'll try out the ReflectionHelper. Edit 2 =============================================================== GREAT NEWS! Hey, I'm excited at least lol... I... ...got it working with my modpack ...used ReflectionHelper calls to reduce a bit of reflection code (still needed 2 different calls for obfuscated and non-obfuscated though) ...accomplished the goal (removing fire spread) in a more elegant way, which preserves original fire-related stats and enables toggling of fire spread using a flag ...I feel like there was something else I improved too but I forgot what, so yeah, that random thing is also probably better than it was before For posterity, I will post the source for the updated version (which works in my massive modpack) in the main post shortly!

Holy crap I didn't realize we had reflection support...nice. I'll try that. I will most certainly use this. Yeah, I'm pretty sure I need that reflection. See Edit 1 in my previous reply for a test I ran. Also, for this part: I remembered I can access the block registry with ForgeRegistries.BLOCKS...you know...like I already did previously...I probably need more sleep but I'd rather code right now lol

I did try that, but I couldn't seem to get the timing right. Maybe I wasn't doing it in the right event? If I'm not mistaken, I would have to re-enter the registry for it *after* it is first set by the Block class (not to be confused with the Blocks class), but before it is accessed by the Blocks class (again, not to be confused with the Block class). I may try at this again, since it would be nice to remove the reflection. Edit 1 ============================================================ I just noticed that you said "Block field" and not "Blocks field". Not sure if you were looking at the right class or not (both exist, and are 2 different classes). In any case, I just ran a test on this. I added this to my main class constructor (the symbols make it easier for me to find the line in the output terminal; I always remove them later): System.out.println("Constructor" + Blocks.FIRE + " @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"); And then I added this in the class itself (not in a method) to force the constructor to fire the first time my class is ever referenced anywhere (I believe): public static NoFireSpread test = new NoFireSpread(); With those 2 new lines of code, the result of the println was still this: [17:18:16] [main/INFO] [STDOUT]: [com.fantasticsource.nofirespread.NoFireSpread:<init>:32]: Block{minecraft:fire} @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ [17:18:16] [main/INFO] [STDOUT]: [com.fantasticsource.nofirespread.NoFireSpread:<init>:32]: Block{minecraft:fire} @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ It prints twice because one is from the "normally created" instance of my class (the one forge is using) and the other is from my "artificially created" instance. So even at the earliest code entry point I personally know of, it's already too late to set the Blocks.FIRE field without reflection (being a static field). Edit 2 ============================================================= On a separate note, I found out that while my mod works on its own (jar mode as well as in intelliJ), it does NOT work in my modpack that I made it for (doh) so I'm currently trying to track down that issue. My best guess atm is that another mod is overwriting the encouragement values *after* I run my code to set them all to 0 (in the RegistryEvent.Register<Block> event). Honestly I'd rather set them all in some event that I know is after all block registry events, but I haven't found a decent one yet (tried WorldEvent.Load but it doesn't seem to have registry access built in...guess I can pass a reference to the registry from elsewhere though, trying that next)

Unfortunately, that gamerule does not have the result I wanted. Setting doFireTick to false does prevent fire spread, but at the same time, it also prevents fires from extinguishing and prevents fires from breaking blocks, neither of which were desirable for my modpack (and I couldn't find a mod that did prevent fire spread on minecraft.curseforge.com, so I made one).

Can you post some code for it? If not, what is the data type for restrictedDrops? Is it a list, an array? (Also if no code posting) If restrictedDrops is any type of data structure (I'm assuming it's a list based on what you said), what type is each element in theory, and in actuality (eg. in many cases you'll have data structures filled with "Object"s which are actually all the same Object subtype)? Edit 1 ============================================= I've just started delving into forge's config annotations myself (I started forge modding a few days ago, so sorry about my ignorance). I doubt they have any built-in support for lists, but if you're already getting an array to pass from your config text file to your config java file, you may find this conversion example helpful: Integer[] ints = new Integer[] {1, 2, 3}; List<Integer> list = Arrays.asList(ints); Just keep in mind that this is a non-expandable list. Also note I had to use "Integer" (the class type) instead of "int" (the primitive type) to get this to work. Not sure if this will help you at all or not.

I just created my first minecraft mod and got it running on SP on both intelliJ and as a regular forge mod jar (tested with MultiMC). It was harder than I expected, due to unforeseen complications and my general lack of minecraft modding knowledge (learned at least a little about the event bus...the hard way). In any case, if any modding gurus out there want to point out bits of my code that rub them the wrong way, I can try to fix them (eg. to be more compatible/stable with forge and/or other mods, etc). Also, I have not tested on an integrated server and remote client, but I see no reason why there would be a difference between that and normal SP on MultiMC for this particular mod, as it stands right now. My main class: And my BlockFireEdit class (replaces the normal BlockFire class) For posterity, here are the source files for THE VERSION THAT WORKS WITH MY MASSIVE MODPACK: Main file: BlockFireEdit, which extends the original BlockFire: And just to make it a complete example in case another newb modder like myself sees this... ...my mcmod.info file: ...and my build.gradle file: I think this thread is pretty well done and overwith, so here's a link to the mod on curseforge: https://minecraft.curseforge.com/projects/no-fire-spread I will also be making a more advanced version with a bunch of fire-tweaking config options soon and releasing it under the title "Controlled Burn"