Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

anothertime

Members
  • Content Count

    24
  • Joined

  • Last visited

Community Reputation

0 Neutral

About anothertime

  • Rank
    Tree Puncher

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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
  3. Sorry to bump, but this is really slowing down development. Is this a problem with ForgeGradle or could be IDEA ?
  4. 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
  5. Changes to the body of an existing method
  6. 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!
  7. Very important. I use one project for each MC major version and I develop / debug the mods alongside each other
  8. 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
  9. 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
  10. 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
  11. 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/ModelB
  12. 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?
  13. 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? Tha
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.