anothertime

I think I can confirm that this is a gradle/forgegradle problem. I configured IDEA to NOT use gradle to build/run my project and now the hot swap work correctly

I did more tests. It works with a single mod (I compiled and debugged the forge 106 mdk) but it doesn't works with a multi-mod project structure: I always get the hot swap error. I followed McJty example to build my multi-mod project: https://github.com/McJtyMods/MultiWorkspace

Sorry to bump, but this is really slowing down development. Is this a problem with ForgeGradle or could be IDEA ?

I usually rebuild the module with build\build module but I've also tried run\reload changes after looking for a solution on the web but the result is the same

Changes to the body of an existing method

Hi i'm using IDEA but when I modify my mod code and then rebuild it, while debugging, I keep getting "hot swap falied" errors and I'm forced to restart MC to test the new code. I generated the run configs with get the genIntellijRuns task and I've never had this problem in 1.12 I'm using the last version of IDEA and forge 1.14.4-28.1.102 How could i fix this problem? thank you!

Very important. I use one project for each MC major version and I develop / debug the mods alongside each other

No. I have this as a dependency to allow modB to complie (Idea see the dependency in gradle and set it's project correctly): implementation project(':moda') But the runconfig don't see the dependency and so modA is not added to the mods list when Idea/forgegradle launch modb (and I get an error from FML becase ModB required ModA to be present and ModA is missing) I've to edit the Idea runconfigs XMLs to manually add modA to the mods to loads and I'm trying to find a way to add it in the build.gradle file to avoid that manual work every time I upgrade to a new forge version and recreate the run configs

No, they are 2 separate mods

Hi! I've a single, multiproject setup in IDEA, with, say, ModA and ModB in it, and ModB depend on the code of ModA. It's working fine so far, they only problem is run configurations How do I include ModA in the run config of ModB? I've tried to add a new "mod" unders the mods list of the run config of ModB, like so: runs { server { workingDirectory runDir // Recommended logging data for a userdev environment property 'forge.logging.markers', 'SCAN,REGISTRIES,REGISTRYDUMP' // Recommended logging level for the console property 'forge.logging.console.level', 'debug' mods { moda { source project(':moda').sourceSets.main } modb { source sourceSets.main } } } client { //same stuff basically } } but that project(':moda').sourceSets.main, for some reasons, seems to resolve to the source set of the root project, not the one of the subproject "moda" How do I do that? thank you!

I have a similar problem with my blockstates. So far the only thing I found is this : https://github.com/MinecraftForge/MinecraftForge/issues/5615 But there is no fix at the moment

I've got a similar problem too All my (forge) blockstates that worked with no problems in 1.12.2 stopped working in 1.13.2. I use Minecraft "cube" model for my blocks and I get this errors in the log: [Client thread/WARN] [minecraft/ModelBakery]: Unable to resolve texture reference: #down in minecraft:block/cube [Client thread/WARN] [minecraft/ModelBakery]: Unable to resolve texture reference: #up in minecraft:block/cube [Client thread/WARN] [minecraft/ModelBakery]: Unable to resolve texture reference: #north in minecraft:block/cube [Client thread/WARN] [minecraft/ModelBakery]: Unable to resolve texture reference: #south in minecraft:block/cube [Client thread/WARN] [minecraft/ModelBakery]: Unable to resolve texture reference: #west in minecraft:block/cube [Client thread/WARN] [minecraft/ModelBakery]: Unable to resolve texture reference: #east in minecraft:block/cube It is like the defaults textures in the blockstate are ignored. I tried to set the textures in every variants but they are ignored too

got it, thank you!

I'm sorry, I know that my property name is a bit misleading. Those are not 5 different blocks, it's basically a chest that show how full it is by changing it's texture. The TE compute the value for the TYPE property (0/black = empty, 4/red = full, and values in between) and my old getActualState() return the corresponding value for the blockstate json property. Could this be done using extended state and my current blockstate json or should I call world.setBlockState() every time the amount of stuff in the chest change between one TYPE and the other?

Yeah I noticed that. I was looking into extended states but from what I understand I can only work with unlisted properties in extended states, that is, properties that are not in the block json blockstate file. Unless I'm wrong :) In my blockstate I have a TYPE property with values between 0 (default/black texture) and 4 (red texture), the color to use is stored in the block TE. In 1.12.2 my getMetaFromState() always returned 0 (so TYPE=0), leaving getActualState() to set TYPE to the color stored by the TE Can I do this with extended states? Thank you!