MinecraftForge/FML — pull request #230 by fnuecke (2013-05-08 05:14:56+00:00)
Title: Alternative setter logic for @SidedProxy in Scala classes/mods.

I'm not sure how `@SidedProxy` was supposed to be used in Scala classes, because it's very hard to find examples or existing code. And I couldn't quite reconstruct it from inspecting the sources. (In fact, I'm not sure how it *could* work, seeing as all fields are private in Scala, so `getField("INSTANCE")` kind of has to fail? Sorry, rambling...)

So I added an alternative way of setting the proxies, which will fall back to the current code if it fails, so it should be fully backwards-compatible. This is how I have it running right now:

package example

imports...

@Mod(modid = "ScalaMod", name = "ScalaMod", version = "0.0.0", modLanguage = "scala")
@NetworkMod(clientSideRequired = true, serverSideRequired = true)
class ScalaMod {
@SidedProxy(clientSide = "example.client.ClientProxy", serverSide = "example.CommonProxy")
var proxy: CommonProxy = null;
}

object ScalaMod extends ScalaMod {
@PreInit
def preInit(e: FMLPreInitializationEvent) { }

@Init
def init(e: FMLInitializationEvent) = proxy.logTestMessage()

@PostInit
def postInit(e: FMLPostInitializationEvent) { }
}

I'm logging two different messages in the `CommonProxy` and the `ClientProxy` and it sure enough logs them differently for client and server, so I'm confident this works. I'd be very happy about feedback or hints on alternative approaches, though.

One final note for anyone stumbling across this in search of information on how to mod in Scala: the construct of having the class and singleton separate is necessary, because `@SidedProxy` would otherwise be copied into the inner class, compiled as `ScalaMod$`. Which in turn means it'd be ignored by the lowlevel mod loader logic.