Problems with Client and Server-Side Proxies

[SirEntropy]

Hi.

 

I was trying to create a mod proxy to manage client and server-side data. However, it is not behaving the way I expect.

 

This is the mod class:

 

@Mod(modid = "mcmods.common", name = "MCMods Common", version = "0.0.1")
@NetworkMod(
	clientSideRequired = true,
	serverSideRequired = false,
	packetHandler = MCModsPacketHandler.class,
	channels = { "SubWorld" }

	)
public class MCModsCommon {

@Instance
public static MCModsCommon instance;

@SidedProxy(
		clientSide = "mcmods.common.registry.CommonRegistryClient",
		serverSide = "mcmods.common.registry.CommonRegistry")
public static CommonRegistry registry;


@Init
public void load(FMLInitializationEvent evt) {
	System.out.println(registry);
	registry.init(this);
}
}

 

This is the server-side proxy class

public class CommonRegistry extends Registry {

public CommonRegistry() {
	System.out.println("Crated Common Registy Server");
}
...
}

 

and the client-side proxy class

public class CommonRegistryClient extends CommonRegistry {
public CommonRegistryClient() {
	System.out.println("Crated Common Registy Client");
}
        ...
}

 

The problem is that, although both classes are instantiated, only the client-side instance gets assigned to the MCModsCommon.registry attribute.

 

...
2012-09-15 21:06:48 [iNFO] [ForgeModLoader] Forge Mod Loader has identified 5 mods to load
2012-09-15 21:06:48 [iNFO] [sTDOUT] Crated Common Registy Server
2012-09-15 21:06:48 [iNFO] [sTDOUT] Crated Common Registy Client
2012-09-15 21:06:48 [iNFO] [sTDOUT] Starting up SoundSystem...
2012-09-15 21:06:49 [iNFO] [sTDOUT] Initializing LWJGL OpenAL
2012-09-15 21:06:49 [iNFO] [sTDOUT]     (The LWJGL binding of OpenAL.  For more information, see http://www.lwjgl.org)
2012-09-15 21:06:49 [iNFO] [sTDOUT] OpenAL initialized.
2012-09-15 21:06:49 [iNFO] [sTDOUT] mcmods.common.registry.CommonRegistryClient@7f32e910
...

As far as I know, there should be two separate instances of MCModsCommon (one for the client thread and one for the server thread), so when the load method is called, it should print both CommonRegistry and CommonRegistryClient. Currently it only prints CommonRegistryClient (see the last line of the last output).

 

Is it right my assumption that MCModsCommon should have two different instances? If so, what am I doing wrong?

[LexManos]

Umm no are you high? How exactly do you expect a variable to hold two values?

The reason you're getting both of the lines in your log is because both functions are being executed ON THE SAME INSTANCE OF THE CLASS.

Thats how inheritance works...

[SirEntropy]

  On 9/16/2012 at 4:28 AM, LexManos said:

Umm no are you high? How exactly do you expect a variable to hold two values?

The reason you're getting both of the lines in your log is because both functions are being executed ON THE SAME INSTANCE OF THE CLASS.

 

I'm well aware of how inheritance works. What you say it's true when you have only one thread running with that instance or two+ threads sharing the same memory. If you run two threads, one for the client and one of the server, as it happens in MC 1.3.2, and you are not sharing memory, you  may have more than one instance, which means that I would have expected that the line "Crated Common Registy Server" should have been printed twice. Perhaps I should reformulate my question: When running MC 1.3.2 in standalone mode (client and embedded server), do both threads (client and server) share the same memory space or do they have different spaces for their variables? If the latter is true the instance of MCModsCommon in the server thread should have the attribute 'registry' of type CommonRegistry, while the instance in the client thread should have the attribute 'registry' of type CommonRegistryClient.

 

Since you say that there is only one instance of the class, the answer might be the former. If so, wouldn't be useful to change MC Forge to create two different instances of the mod class, one for client and one for server, (e.g., using the ThreadLocal class)? That way would make coding for standalone MC be more consistent with coding for MC server and bukkit, since there will be an effective separation between the client and server code.

[LexManos]

Almost never does multiple threads in the same program have a different memory space beyond the thread itself.

 

And yes, MC shares the same instance among all threads, and this isn't gunna change, we are not gunna initialize your mod twice.

The code will be consistent, if you've done it right.

And all of your code should not care what thread it run on, as long as you do not start accessing things you should {like the client world from the server thread} you're fine.

Thats how all of MC is designed, single instances shared amung threads.