MamiyaOtaru

how are you going to move classes around in the middle of a Minecraft version? This is not a treadmill I want to be on

Cheers. Just finished porting to forge (a minimap) and updating to 1.14 and discovered this (that you can't). Well, code at least runs (sans updates) and will be ready to go if that ever becomes possible. In a non-forge environment I can get this info by mixing in to WorldRenderer.func_215319_a() and be made aware of any chunk that is scheduled to be processed so I can at my leisure read terrain data from that chunk. Alternatively one could just periodically read terrain data for every chunk in range. This'd cause a lot more overhead, and would miss changes that happened before a sweep. Anyway, it would be nice to have a way of knowing which chunks have changed.

if NetEase needs Forge, they can easily spare some change to financially help the people who make it. Otherwise they are just leeching. Similarly if there are thousands of players on Minecraft China who can't wait for Forge, they can check out Patreon. Otherwise they can just wait.

As you know, for any given block, only states returned by getStateFromMeta(int) are stored to disk. Additional states returned by getValidStates() are not. Your best bet would be to see what properties in the set of states returned by iterating through metadata 0-15 never change (and do change in getValidsStates()). All 16 states returned for the dirt block from getStateFromMeta for instance will be snowy=false, as that is not stored. This will not be true in 1.13, where blocks will not be limited to 16 (storable) states. Presumably every possible state will be stored. I'm not getting the pushback here. His mod deals with stored world data files, and the integers are still heavily used in the anvil files. This will change of course, but is totally applicable for a program that runs without even having Minecraft (with its nice int to blockstate mapping) running. If you're going to deal with savefiles, there's going to be some numbers involved. Of course things will get more complex in 1.13! Which will of course include the numbers to blockstate mappings in the savefiles, but those are not yet in 1.12 and below, so again I really don't get the pushback against using the numbers. You simply have to when dealing with (generating, editing) savefiles without Minecraft running.

bigteddy98's uuidlib worked pretty well. I used it for a one time, out of game conversion from UUID to name, dunno how fast it would be it seems to have mostly disappeared, but went like this given uuid as a string, after uuid = uuid.replaceAll("-", ""); // no dashes it went through String name = null; try { URL url = new URL("https://sessionserver.mojang.com/session/minecraft/profile/" + uuid); URLConnection connection = url.openConnection(); Scanner jsonScanner = new Scanner(connection.getInputStream(), "UTF-8"); String json = jsonScanner.next(); JSONParser parser = new JSONParser(); Object obj = parser.parse(json); name = (String) ((JSONObject) obj).get("name"); jsonScanner.close(); } catch (Exception ex) { ex.printStackTrace(); } there's probably some reason this is horrible code or unworkable or something, but it did what I wanted to for converting a bunch of UUIDs to usernames

I get that same error (inconsistently) without changing any gamerules. IMHO the gamerule is a red herring

same issue here. No dev.json to mess with though (new install)

this is the same request I had here http://www.minecraftforge.net/forum/index.php/topic,2009.msg15922.html#msg15922 If I ever feel like getting to know the internals of an API so I can submit a pull request for a sensible addition I'll go for it. I'm just a modder though. Anyway, glad to see that someone else has the same request But currently there is no way to do it without some sever kludges, as detailed in my post.

Is it possitbe using forge to draw to the HUD after the other HUD elements (like the dimming at the edge) have drawn, but before GuiScreens (like menus, inventory screen etc) are drawn? To explain, here is what I ran into trying to do this with ModLoader. I know this isn't a modloader forum, but it illustrates my issue, which is hopefully one that won't be there with Forge. I've been maintaining Zan's Minimap since Lahwran let it go http://www.planetminecraft.com/mod/zans-minimap/ I recently had someone ask if my mod worked with Advanced HUD. As is, it does not. Rather than using modloader, I have been calling the minimap code (rendering, calculating, handling menus etc) at the end of GuiIngame's renderGameOverlay. This draws it over the top of things like the fading at the edge of the screen, and before EntiryRenderer calls this.mc.currentScreen.drawScreen on whatever (if any) GuiScreen is called. So the map is not faded at the edge, but gets drawn behind menus, chest containers or whatever. Obviously the minimap won't work with AdvancedHUD as is, since advancedHUD replaces GuiIngame with AGuiIngame, so mine is never called. So I made mine modloader compatible. Each onTickInGame, call the maps rendering, menu handling etc. The problem with this is Modloader's EntityRendererProxy does this: super.updateCameraAndRender(var1); ModLoader.onTick(var1, this.game); calling HUD drawing AND menus before any registered mods get their ontick. (updateCameraAndRender calls this.mc.ingameGUI.renderGameOverlay(par1, this.mc.currentScreen != null, var11, var13); this.mc.currentScreen.drawScreen(var11, var13, par1); in order) So hud draws, menu draws, THEN the map (on top of whatever if any GuiScreen is currently up). This is not what I want. So instead, in my onTickInGame, I set minecraft.ingameGUI = fakeGui;, fakeGui being a class that extends GuiIngame. Its renderGameOverlay calls super.renderGameOverlay, then my map's code. So HUD is drawn, then my map, then GuiScreen. This is mad kludgy, especially when working with another mod that does something similar (like AdvancedHud) It works, and I'm not asking for help getting it to work. What I want to know is if Forge does it better; if Forge provides an official way to draw something after the HUD and before the menu. As far as I can tell it does not. Specifically, this section in minecraft.java FMLCommonHandler.instance().onRenderTickStart(this.timer.renderPartialTicks); this.mcProfiler.endStartSection("gameRenderer"); this.entityRenderer.updateCameraAndRender(this.timer.renderPartialTicks); this.mcProfiler.endSection(); FMLCommonHandler.instance().onRenderTickEnd(this.timer.renderPartialTicks); shows forge doing stuff, then updateCameraAndRender (which calls ingameGUI then MenuScreen) then maybe some more forge stuff. I see no way to insert something between HUD and menu rendering. IMHO (and assuming I'm not wrong) this is a bit of an oversight for mod APIs. There's no way to add a HUD element that acts like the other ones. The add on either draws over menus, or disappears whenever a GuiScreen comes up (which the built in ones do not). I'd like to leave the map up (dimmed, and behind the menu) so users can see the effect of changes they make to the config in real time. I assume I can do something similar to what I did with modloader, hijacking ingameGUI, but I'd love to be wrong!