Hunternif

Which option is it in server.properties?

I'm trying to debug multiplayer, so I run a server instance from Intellij, and a client instance in debug mode. When I hit a breakpoint on the client, the server then proceeds to disconnect me because of timeout. How can I prevent this disconnect?

I see. Somehow I did experience a different behavior when debugging 1.7.10, but I can see now that it was not intended. If I mean to have keep one instance of WorldSavedData for all dimensions at once, do you think it would be a good idea to have a cache for it on the client, and store the data instance once it is first loaded? Thank you for you help!

I think I'm starting to understand it a little better. I store all data for one map for all dimensions at once in one WorldSavedData instance. So I expect the same instance to be loaded from within any dimension. I think I prefer to have it like this in one file, as opposed to saving a new file per each dimension for each map. UPDATE: Naturally, I don't expect the client to actually save any data locally on its own. When the player first logs in, the server sends the data over in a packet. The packet would contain map data for all dimensions at once, and the client would show the corresponding portion depending on where the player currently is. Now I tried a little cheat, to re-send all this data again when the player changes dimensions, and voila, it is now loaded correctly. Although all the actual data for this dimension has already been sent to the client with the first packet, and loads correctly without additional "reminders" of this sort in 1.7.10.

I probably decided to use world.loadItemData because this data pertains to a particular item, like it does with Minecraft maps. Should I still prefer world.perWorldStorage if I'm using it for data tied to an item? UPDATE: I switched to perWorldStorage, and the same issue is still present.

The code is probably a bit too long and convoluted to post as is, let me try to explain one more time what is happening on an abstract level. My item is basically a map that updates constantly based on your surroundings. The data is saved to a WorldSavedData instance with the current world. As long as I stay in one dimension (e.g. overworld) all the data is saved correctly, and is correctly loaded when I log out and back in. On each tick in Item.onUpdate() and GuiScreen.updateScreen() I call world.loadItemData() to update its content and load it for rendering. If world.loadItemData() returns null, I assume I have never visited this dimension before, and create a new WorldSavedData instance and save it by calling world.setItemData(). However, in 1.8 something strange happens when I change dimensions. As soon as I load in a new world, even if I have previously visited it before and have saved some data (which is evident by the presence of the corresponding <data_key>.dat file in the world data folder), world.loadItemData() returns null. I don't know if it would eventually "remember" the old WorldSavedData it had, because I immediately replace it with a new instance, as explained in the previous paragraph. This only happens on the client side, and it doesn't happen with identical code in 1.7.10. If I log out and back in, the old WorldSaveData of the current dimension is loaded correctly again. If I change dimensions, the data gets lost on the client until the end of this session.

I call world.loadItemData(clazz, dataID) in an item's onUpdate() to load and render some data attached to the item. In 1.7.10 it used to work fine, but in 1.8 it would suddenly return null for the same dataID after I walk into a Nether portal. Does anyone know what changed in the logic of WorldSavedData and world.loadItemData()? I've yet to look deeper into this issue, I'm just asking in case anyone has already figured out how WorldSavedData works.

So I ran cleanCache again and it worked, then after some time and setupDecompWorkspace it started failing again. I ran cleanCache once again, and setupDecompWorkspace too, because I need it for development, and after that it has worked several times so far. EDIT: later today, it broke again

Once again, it worked 1 time, then on subsequent launches of "gradlew build" it failed on task ":reobf" with the same exception. Before that I had been working as usual: added some texture assets, modified some code, nothing that should have changed the way the project is built. I did restart my computer once, so I suppose, that could possibly be the reason why it did work once again.

I tried this: gradlew cleanCache gradlew setupDevWorkspace gradlew eclipse And the build worked. But after I added gradlew setupDecompWorkspace the error appeared again.

It worked after I changed "runDir" in build.gradle from "run/assets" or "eclipse/assets" (which I had from an older version of Forgem when that variable was called "assetDir") to just "run" or "eclipse". I still have no idea what that folder has to do with building, because it remained empty. An explanation will be appreciated. EDIT: Never mind, it worked once, now it doesn't work again. Please help.

I am using Forge v10.13.2.1230 for Minecraft v1.7.10."gradlew build" works for the example mod that ships with Forge src, but fails for my mod. I've tried running it with JAVA_HOME set to JDK v1.6 and JDK v1.7 with identical results. Following is gradle log: **************************** Powered By MCP: http://mcp.ocean-labs.de/ Searge, ProfMobius, Fesh0r, R4wk, ZeuX, IngisKahn, bspkrs MCP Data version : unknown **************************** :compileApiJava UP-TO-DATE :processApiResources UP-TO-DATE :apiClasses UP-TO-DATE :sourceMainJava UP-TO-DATE :compileJava UP-TO-DATE :processResources UP-TO-DATE :classes UP-TO-DATE :jar UP-TO-DATE :compileTestJava UP-TO-DATE :processTestResources UP-TO-DATE :testClasses UP-TO-DATE :test UP-TO-DATE :extractMcpData UP-TO-DATE :getVersionJson :extractUserDev UP-TO-DATE :genSrgs SKIPPED :reobf FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':reobf'. > java.lang.IllegalArgumentException (no error message) * Try: Run with --info or --debug option to get more log output. * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':reobf'. at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46) at org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:35) at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:64) at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58) at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:42) at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53) at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43) at org.gradle.api.internal.AbstractTask.executeWithoutThrowingTaskFailure(AbstractTask.java:289) at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.executeTask(AbstractTaskPlanExecutor.java:79) at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:63) at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:51) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$1.run(DefaultTaskPlanExecutor.java:33) at org.gradle.internal.Factories$1.create(Factories.java:22) at org.gradle.cache.internal.DefaultCacheAccess.longRunningOperation(DefaultCacheAccess.java:198) at org.gradle.cache.internal.DefaultCacheAccess.longRunningOperation(DefaultCacheAccess.java:266) at org.gradle.cache.internal.DefaultPersistentDirectoryStore.longRunningOperation(DefaultPersistentDirectoryStore.java:135) at org.gradle.api.internal.changedetection.state.DefaultTaskArtifactStateCacheAccess.longRunningOperation(DefaultTaskArtifactStateCacheAccess.java:95) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:31) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:86) at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:29) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:61) at org.gradle.execution.DefaultBuildExecuter.access$200(DefaultBuildExecuter.java:23) at org.gradle.execution.DefaultBuildExecuter$2.proceed(DefaultBuildExecuter.java:67) at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:61) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:54) at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:166) at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:113) at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:81) at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:64) at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:33) at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:24) at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:35) at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26) at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:50) at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:171) at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:201) at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:174) at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:170) at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:139) at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33) at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22) at org.gradle.launcher.Main.doAction(Main.java:46) at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45) at org.gradle.launcher.Main.main(Main.java:37) at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:50) at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:32) at org.gradle.launcher.GradleMain.main(GradleMain.java:23) at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:30) at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:127) at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:58) Caused by: java.lang.IllegalArgumentException at org.objectweb.asm.MethodVisitor.<init>(MethodVisitor.java:86) at org.objectweb.asm.MethodVisitor.<init>(MethodVisitor.java:71) at net.minecraftforge.gradle.extrastuff.ReobfExceptor$JarInfo$1.<init>(ReobfExceptor.java:374) at net.minecraftforge.gradle.extrastuff.ReobfExceptor$JarInfo.visitMethod(ReobfExceptor.java:373) at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:852) at org.objectweb.asm.ClassReader.accept(ClassReader.java:669) at org.objectweb.asm.ClassReader.accept(ClassReader.java:506) at net.minecraftforge.gradle.extrastuff.ReobfExceptor.readJar(ReobfExceptor.java:154) at net.minecraftforge.gradle.extrastuff.ReobfExceptor.doFirstThings(ReobfExceptor.java:80) at net.minecraftforge.gradle.tasks.user.reobf.ReobfTask.getExceptor(ReobfTask.java:319) at net.minecraftforge.gradle.tasks.user.reobf.ReobfTask.doTask(ReobfTask.java:277) at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:63) at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.doExecute(AnnotationProcessingTaskFactory.java:219) at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:212) at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:201) at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:533) at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:516) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61) ... 52 more BUILD FAILED Total time: 8.791 secs The stack trace seems to point to the following line in org.objectweb.asm.MethodVisitor (although the line number doesn't match the log - does gradle use a different ASM jar from the one that's in the mod's build path?) if (api != Opcodes.ASM4 && api != Opcodes.ASM5) { throw new IllegalArgumentException(); }

This coremod addresses a rather peculiar issue with the default Minecraft font, namely it has too much space (kerning) between letters when rendering bold Unicode characters. This may be interesting to modders making book-like GUIs with a lot of small text, like we are doing in Quest. With longer text lines it looks really ugly. Original With Better Kerning Installation 1. Install Forge 2. Download the Better Kerning core mod: http://adf.ly/c1kNP 3. Copy the jar file into your .minecraft/mods folder , or mcp/jars/mods when developing Source code https://github.com/Hunternif/BetterKerning

Thanks for the code, it was really useful! I'd like to point out some things however: 1) This may not be an issue if you don't use this method too frequently, but you should only use the Vec3.fakePool for vectors that must be stored permanently. Use world.getWorldVec3Pool() to get short-lived vectors instead. 2) closestHit must be instantiated with maxDistance, not infinity. Otherwise you will always hit the entity when you are actually aiming at the block in front of it.

Replying for the sake of google. You can add dependencies "before" and "after", as well as specify required vesions: "required-after:mod1@[1.0,)" - This means you require a mod with id "mod1" of version 1.0 and higher to be loaded before your mod. See javadoc for cpw.mods.fml.common.versioning.VersionRange.createFromVersionSpec(String spec)