[[1.14.4] Fluid system: can't use custom texture and texture loading bugs]

5 hours ago, Ommina said:

You can use TextureStitchEvent.pre to add your textures, instead of creating a block or item.  This may or may not also affect issue two.  (I've not seen any texture problems, so far)

 

That said, gigaherz has made further changes to the Fluid API that will remove the need for the manual texture stitching entirely.  Keep an eye on Forge PR #6110 for details there.

Thank you, do you happen to know how I add player interaction to the fluid? (eg: swimming, damage etc.)

[[1.14.4] Fluid system: can't use custom texture and texture loading bugs]

I found two issues with the new fluid system:

 

1) I can't assign any texture to it which does not belong to a registered block or item: that means I have to register a block/item that uses my _flow texture and another one that uses my _still texture in order to apply custom textures to the fluid

 

2) Sometimes, if I quit the game right in front of a custom fluid and then reload the game and world, it will show the missing texture for an instant

[[1.14.4] NoSuchMethodError when calling ModLoadingContext.get().getActiveNamespace() in obfuscated minecraft]

I can call getActiveNamespace() when running Minecraft from the IDE, but when testing the mod on a Minecraft release it crashes with the above error

 

BTW I only get this if I call it directly from my code

 

UPDATE: my bad, Forge was not updated to the latest version in the client

[[1.14] WeakHashMap with entities' UUID: keys sometimes not clearing]

I'm trying to create a system to register custom Entity data on-the-fly for already existing Entities (including vanilla Entities); for every data object i keep a normal HashMap that maps Class<Entity> -> DataParameter, and i keep a global WeakHashMap that maps UUID -> WeakReference<EntityDataManager> (as I noticed the Entity instance may change for one entity).

 

However I noticed sometimes (not always) the map does not clear out, even if I change world and run System.gc(), while sometimes it does

[[1.14.3][Kotlin] Is repacking and shadowing the Kotlin runtime a bad idea?]

7 minutes ago, rdvdev2 said:

I think this is a better approach because forge doesn't have the kotlin runtime or standard library. Without a language provider like kottle every mod would have to shadow these libraries, so it's a better practice to have one mod to carry this libraries to avoid redundancy. This also allows the kotlin libs to update independently 

Yeah, but what I'm saying is this mod doesn't have to be minecraft-version dependant (but it currently is) so using it would mean I depend on it to be updated for updating my mod, while I don't have to worry about that if I shadow the Kotlin runtime

[[1.14.3][Kotlin] Is repacking and shadowing the Kotlin runtime a bad idea?]

On 8/17/2019 at 10:52 PM, rdvdev2 said:

I found this Forgelin rewrite for 1.13.2+: https://www.curseforge.com/minecraft/mc-mods/kottle

It will hopefully do the trick 

Thank you, but I just don't see why a minecraft-version-dependant framework is needed when Kotlin actually does work out of the box, the only extra step needed is adding the @JvmStatic annotation alongside @SubscribeEvent in static event handler's methods

[Default blockstates, block/item models and model patterns]

15 minutes ago, DaemonUmbra said:

If you're in 1.13+, you shouldn't be doing this manually anyway. Look into the Data Generator system.

Any documentation / example source code?

[Default blockstates, block/item models and model patterns]

10 minutes ago, LexManos said:

Just make your json files.

Having to make 3 json files for each block is only part of the problem: having 30+ files in a directory that all do the same thing gets kinda messy and unmanageable;

 

but whatever, I'll keep adding json files until this strikes you as an OK idea I guess

[Default blockstates, block/item models and model patterns]

I don't know whether this has been asked before or whether this is possible or not, but it would be a nice feature for forge blocks without a blockstate to fallback to a signle-state blockstate with block/REGISTRY_NAME.json as default model, and blocks with no blockstate AND model to default to 'block/cube_all' as model and block/REGISTRY_NAME.png as texture

 

Same goes for items, with BlockItems defaulting to their correspective block's model, and normal items defaulting to 'item/generated' model with item/REGISTRY_NAME.png as texture

 

 

Also a more complicated addition would be having reusable models (EG: that provide textures as '${name}_top', '${name}_sides' and '${name}_bottom')

[[1.12 to 1.14] Make custom mobs spawn only at night (custom biome)]

21 minutes ago, Choonster said:

 

It was made public again in this PR (1.14.4-28.0.37). Update Forge.

Thank you, that worked

[[1.12 to 1.14] Make custom mobs spawn only at night (custom biome)]

19 minutes ago, Choonster said:

It looks like spawning conditions are handled by EntitySpawnPlacementRegistry in 1.14.

 

You need to call EntitySpawnPlacementRegistry.register with your EntityType and a predicate that determines the conditions under which it can spawn. Zombies and other hostile mobs use MonsterEntity::func_223325_c for the predicate, this checks the difficulty and the light level.

Thank you, but the register function is private inside EntitySpawnPlacementRegistry, isn't there any forge registry to handle this, or do I have to use reflection?

[[1.12 to 1.14] Make custom mobs spawn only at night (custom biome)]

Hello, I'm having trouble getting a custom mob spawn at night in my custom biome.

 

Adding a spawn for a vanilla Zombie will automatically make it spawn only at night,

addSpawn(EntityClassification.MONSTER, Biome.SpawnListEntry(EntityType.ZOMBIE, 100, 5, 8))

 

but doing the same with my custom entity, which extends the ZombieEntity class and has EntityClassification.MONSTER classification will still make it spawn during the day

[[1.14] Custom ocean biome with custom block (instead of sand)]

I was trying to create a customized ocean biome but i wanted my block to show up instead of sand; I just copypasted the normal OceanBiome class but used this config

 

SurfaceBuilderConfig(MyMod.Blocks.MYGRASS.defaultState, MyMod.Blocks.MYDIRT.defaultState, MyMod.Blocks.MYSAND.defaultState)

 

apparently the underWaterMaterial parameter (third one) is completely ignored and the biome still uses vanilla sand as default

[[1.12 to 1.14.4] Separate logic for different block states]

4 minutes ago, Draco18s said:

https://github.com/MinecraftForge/MinecraftForge/issues/5615

Oh well, atleast I did not mess this one up, thanks Draco

[[1.12 to 1.14.4] Separate logic for different block states]

5 hours ago, diesieben07 said:

Wat?

 

Forge's blockstate format should help you here.

I've got another small issue, I don't know if that's just me messing it up again or an unimplemented/changed feature, but on 1.14.4 I'm not able to override textures inside a blockstate file, it just uses the model-associated texture (if present) or not-found texture otherwise

Here's an example of my blockstate

 

{
  "forge_marker": 1,
  "variants": {
    "examplestate": {
      "true": {
        "textures": {
          "side": "greenapple_glacia:blocks/test_bedrock",
          "end": "greenapple_glacia:blocks/test_bedrock"
        },
        "model": "greenapple_glacia:block/glacia_column_mono"
      },
      "false": {
        "textures": {
          "side": "greenapple_glacia:blocks/test_stone",
          "end": "greenapple_glacia:blocks/test_stone"
        },
        "model": "greenapple_glacia:block/glacia_column_top"
      }
    }
  }
}

 

But I have many tried different ways with the same result

[[1.12 to 1.14.4] Separate logic for different block states]

3 minutes ago, diesieben07 said:

Nothing about this is XML.

ERR json ?, I need to sleep

[[1.12 to 1.14.4] Separate logic for different block states]

16 minutes ago, diesieben07 said:

Wat?

 

Forge's blockstate format should help you here.

I'm dumb, I was trying to do something like this:

{
  "forge_marker": 1,
  "variants": {
    "facing" : {
      "north" : {"y": 0},
      "south" : {"y": 180},
      "west" : {"y": 270},
      "east" : {"y": 90}
    },
    "overworld" : {
      "true" : {"model": "greenapple_glacia:block/glacial_berry_overworld"},
      "false" : {"model": "greenapple_glacia:block/glacial_berry"}
    }
  }
}

 

But with normal syntax ("facing=north" : {...} ...)

This makes this XML JSON blockstates sytem not suck as much

 

Also thanks for answering again

[[1.12 to 1.14.4] Separate logic for different block states]

Hello, I used to make mods for minecraft 1.7.10 and I'm getting back into it.

 

I haven't failed to notice the new XML JSON system (wannabe MVC compliant) sucks... a lot.

Haven't quite figured it out yet though, so my question is, can I separate what each blockstate for a single block does (ex: `facing` changes the rotation and `overworld` changes the base model) without having to write all combinations of states?

 

Example where i write all states combinations:

 

{
  "forge_marker": 1,
  "defaults" : {
    "model": "greenapple_glacia:block/glacial_berry"
  },
  "variants": {
    "facing=north,overworld=false" : {"y": 0},
    "facing=south,overworld=false": {"y": 180 },
    "facing=west,overworld=false":  {"y": 270 },
    "facing=east,overworld=false":  {"y": 90 },

    "facing=north,overworld=true" : {"model": "greenapple_glacia:block/glacial_berry_overworld", "y": 0},
    "facing=south,overworld=true": {"model": "greenapple_glacia:block/glacial_berry_overworld", "y": 180 },
    "facing=west,overworld=true":  {"model": "greenapple_glacia:block/glacial_berry_overworld", "y": 270 },
    "facing=east,overworld=true":  {"model": "greenapple_glacia:block/glacial_berry_overworld", "y": 90 }
  }
}

 

^ that is as much as i was able to trim it

I mean, if I used 4 states with 4 possible values each, I would have to write 4^4 = 256 stetes (?!)

[Include the Kotlin runtime in Forge]

24 minutes ago, diesieben07 said:

Won't happen. It was done in the past with Scala and just caused problems galore ("please update Scala!" - "No, please don't, my mod won't work on the newest version!"). Additionally the scala libraries are one of the biggest bandwith hogs on the Forge download server.

 

Minecraft targets Java, so that's what Forge targets.

Just don't use kotlin-reflect then (It is marked as Stable Incremental Release (SIR)), the other components i mentioned are marked as Fully Stable (FS), which, according to the Kotlin documentation website, guarantees future incremental releases to be backwards compatible.

 

Also, Kotlin doesn't seem that bloaty to me

[Include the Kotlin runtime in Forge]

I know, unusual request, but Kotlin is now, more than ever, the go-to JVM language for many programmers, and this would allow modders to use the provided libraries without each of them having to include it in their mods.

By runtime I mean kotlin-stdlib, kotlin-reflect, kotlin-coroutines, kotlin-stdlib-common, kotlin-stdlib-jdk7 and kotlin-stdlib-jdk8 (possibly updated to the latest version)

 

BTW: I am able to make mods in Kotlin without using Forgelin (using just the kotlin libraries), I just use the @JvmStatic annotation on the functions inside my RegistryEvents object and it works like a charm; EG:

 

@Mod.EventBusSubscriber(bus = Mod.EventBusSubscriber.Bus.MOD)
object RegistryEvents {
    @JvmStatic @SubscribeEvent
    fun onBlocksRegistry(event: RegistryEvent.Register<Block>) {
        //Do some stuff here
    }

    @JvmStatic @SubscribeEvent
    fun onItemsRegistry(event: RegistryEvent.Register<Item>) {
        //Do some stuff here
    }
}

 

[[1.14.3][Kotlin] Is repacking and shadowing the Kotlin runtime a bad idea?]

Hello everyone, I wanted to try making a mod using Kotlin, but Forgelin is completely trash: I couldn't get it to work on the latest Minecraft version.

 

Instead I opted to include the full Kotlin runtime in my Jar using johnregelman's shadow Gradle plugin (relocating it to com.my.package.embedded.kotlin so it doesn't conflict with any other mod doing the same thing)

 

I tried including it using the ContainedDeps manifest attribute (and yes, I put the Jars in META-INF/libraries), but it did not work, so this was my only option