Alex Sim

Maybe, but that's exactly what the Javassist library is designed for: to assist me raping the JVM Jokes aside, this would allow me to retain the old logic for a method on top of mine, and also possibly be compatible with any other hypothetical mod that would use the same approach (as if). I'm honestly not sure whether that's possible with coremods, but as far as I know two mods replacing the same class will conflict with each other If that's not the case I'll look into coremods

Doesn't redefineClasses also retransform classes? public class Hello { public int helloWorld() { LogManager.getLogger().log(Level.INFO, "Hello World") } } init { //Based on my tests val hello = Hello() hello.helloWorld() //Prints "Hello World" Hello::class.addMethodAfter(Hello::helloWorld) { LogManager.getLogger().log(Level.INFO, "Goodbye World") } hello.helloWorld() //Prints "Hello World", then "Goodbye World" } I cannot add new methods or fields, but what I CAN do is change an existing method's bytecode, which is exactly what I'm doing (if you look at my source I found a little workaround to call my local variable (functional interface) by creating a new static class at runtime)

ClassPool.getDefault().apply {appendClassPath(LoaderClassPath(Thread.currentThread().contextClassLoader))} This seems to work on non-dev-environment Minecraft, it used to throw javassist.NotFoundException without it; But you probably already know why this won't work and crush my hopes and dreams ?

Should or could? Sorry if I sound insistent but I don't see what's the issue. Aside from practical ones (whether I could, and I seem to be one dll away from being able to), why should I not? My boredom knows no "should"

BTW correct me if I'm wrong but the only issue here seems to be the attach library, if there was a way to use it in JRE (I'm open to suggestions) the rest would probably work

I use Johnrengelman's shadowJar plugin to embed the libraries I use in my mod (and rename the base package), including the Kotlin runtime You're right about the instrumentation stuff though, it apparently doesn't work outside the dev environment ?

My quarantine fueled boredom led my to try this anyway (would be useful for other purposes in my mod) So I made an utility class that uses Kotlin (1.4) extension functions, here is the Kotlin class on pastebin The methods to use are `addMethodAfter`, `addMethodBefore`, `replaceMethod` and `replaceMethodOrFallback` It's pretty small and should be easy enough to convert it to Java Here is an usage example (I call it from my mod's constructor): /** * Replaces animateTick so that it does nothing (fire particles not spawned) if in the Glacia dimension * Otherwise fallback to default method **/ WallTorchBlock::class.replaceMethodOrFallback(WallTorchBlock::animateTick) {(_, world) -> if ((world as World).dimension?.type != Glacia.DIMENSION.type) RedefineUtils.fallback() }

Thanks, that's very helpful, I basically have to do something like this, definitely way easier than whatever tf I was trying to do

I was just experimenting for now but my (probably unreachable) goal is to light every pixel differently (maybe using the alpha level) like so:

Is it possible to learn this power?

Ok thanks for the info, how would I go about it tho? After a little bit of digging i found out WorldRenderer calls renderBlockLayer for each block RenderType inside the updateCameraAndRender method, is it possible to render my blocks without changing vanilla code?

Hello, I'm trying to create a custom RenderType for my block, using a custom lightmap LightmapStateCustom object RenderTypes { private val SHADE_ENABLED = RenderState.ShadeModelState(true) private val LIGHTMAP_ENABLED = LightmapStateCustom() private val BLOCK_SHEET_MIPPED = RenderState.TextureState(AtlasTexture.LOCATION_BLOCKS_TEXTURE, false, true) val SOLID2: RenderType = RenderType.makeType("solid2", DefaultVertexFormats.BLOCK, 7, 2097152, true, false, RenderType.State.getBuilder().shadeModel(SHADE_ENABLED).lightmap(LIGHTMAP_ENABLED).texture(BLOCK_SHEET_MIPPED).build(true)) } For now the only methods LightmapStateCustom overrides are `equals(other)` and `hashCode()` (`RenderType.makeType` would otherwise return an existing RenderType) so the RenderType is logically identical to SOLID, but the block does not render (as you can see on the screenshot below)

Thank you, I did that, however I still have a small issue: the recipe result's stack size is not updated if I insert the items one-by-one, only if I insert the whole stack alltogether, any idea how to fix this? Also I need to consume all of the ingredients' stack instead of one per ingredient BTW I have overridden ShapedRecipe and only changed the method getCraftingResult as below override fun getCraftingResult(inv: CraftingInventory): ItemStack { var count = 64 for (i in 0 until inv.sizeInventory) { val stack = inv.getStackInSlot(i) if (!stack.isEmpty) count = min(count, if(stack.isStackable) stack.count else 64) } return super.getCraftingResult(inv).apply {this.count = count} }

Let's suppose I want to make a recipe with two items, a stackable one (eg: stick) and a non-stackable one (eg: plasma bucket) 1x plasma_bucket + 1x stick makes a plasma torch; 1x plasma_bucket + 64x stick makes 64 plasma torches Is this behaviour possible with forge?

As I wrote above, I'm doing this for torches AND fire. I can just use the entity placement event for torches but not for fire (explosions, flint and steel, lava...)