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)

Ok, I now understand that it's safe to enable blending. The Tessellator is reset for every Effect in the EffectRender.effectList, and I added my effect just there. This means that I interfere with no other object's rendering... probably...

Solved it! The GL_BLEND was simply turned off during the call to EntityFX.renderParticle(...); and before I was immediately disabling it after only having added vertices to the tessellator, before draw() was called on it. But now there must be some reason for the color blending to be disabled... I probably shouldn't be using the tessellator for this particle, since it enables blending for all particles that follow, which was disabled by default. But when I render it by direct calls to LWJGL, it works fine only on the first particle spawn, but on every next spawn the actual color (not the alpha) on my particle gets darker until it appears completely black, but with proper alpha. I wonder how to fix that.

Thanks for the reply, Groxkiller! However, I tried that and it didn't work: that alpha value seems to work as a threshold as I have described in the initial post. Also, even if that did work, that would make all the pixels in the particle semi-transparent. I want to use the pixel alpha values directly from the texture PNG file, like it works with blocks. This seems to be a particle-only issue.

The pixels of my custom particle (and probably every other particle in the game) are either opaque or completely transparent. Setting the value of particleAlpha on my custom EffectFX particle only seems to set a threshold, and pixels in the texture file with alpha below that threshold are not drawn, while all other pixels in the file are drawn with 100% alpha. How can I have semi-transparent pixels on a particle?

I think it's done like this: NBTTagCompound tag = itemStack.getTagCompound(); if (tag == null) { tag = new NBTTagCompound(); itemStack.setTagCompound(tag); } tag.setString("playerName", player.getName()); tag.setInt("playerHP", player.getHP()); Methods getName() and getHP() are given just for example, they probably don't exist in player. Also read this tutorial: www.minecraftforge.net/wiki/How_to_use_NBT_Tag_Compound

Not sure why this would happen. Could you post your entire BaseMod class? (surround it with tags)

You should have included some stacktrace to help us tackle your problem. But I'm guessing it's a NullPointerException you're getting, because in your code the NBTTagCompound nbt might be null, as well as String i. (They're null if they're not set on this itemStack.) I think it's ok to save some data like block locations in your custom item in an NBT tag. You can set arrays, and all info should be retained on restart as well.

Unfortunately, item name showing up is not the only problem. If I change currently equipped item on cooldown to some other item and then back again to my item on cooldown, it starts unequip-equip animation again. So ultimately the problem wasn't solved. However, NBT Tag is clearly much better than item stack damage, I just haven't read about its usage until now.

Awesome, that was exactly what I needed! Thanks a lot, opssemnik. There's only one (minor) issue: the item name stays on the display for the whole duration of my cooldown, for pretty much the same reason as described in the first post: because when item's NBT tag changes, Minecraft's GUI overlay thinks it's a different item that the player is holding now. But there's no more item unequip/equip problem!

Thanks for suggestion, opssemnik, I'll look into that