Zugg Software :: View topic - Multiplaying: Separate instances of modules for different sessions

Newbie Joined: 23 Mar 2010 Posts: 3

I've spent the last few hours trawling the forum for an answer, but couldn't find a good solution, so I'm starting a new thread.

BACKGROUND
I'm trying to play a multi-player setup on a MUD. The exact composition of characters can change, so a fixed layout is not required. What I have created is a common module to put all the aliases/triggers that will be used by all the characters. Each character also has its own package that stores its individual settings. I have created separate sessions to login each character, which will load the character-specific package as well as the common module.

To login in multiple characters, I will connect to the sessions as required.

PROBLEM
When the sessions are loaded and connected, they all reference to the same common module instead of loading a separate instance of the module.

Let me illustrate with an example. Let's say there is a class in the common module which has triggers for auto-pick in the room. I log in two characters, and in the first character, I enable the auto-pick class (which is in the common module). However, this will also cause the second character to have auto-pick enabled as well.

What I want to achieve is for the common module to be loaded twice, so that enabling/disabling classes from one character session will not affect the other character session.

WORKAROUND
The only way I can think of to work around this is to start a separate instance of CMUD for each character. However, this will not allow inter-character scripting. Is there another way of setting this up to work properly?

Thanks.

Wizard Joined: 22 Mar 2007 Posts: 2320

Fear not! There is actually an easy solution for this!

Open one of the sessions in offline mode. Click Settings to open the package editor. Click the tab for the shared module to select it. Click Edit|Package Properties. Near the bottom of the window should be a checkbox labeled "Shared". Uncheck this box. After this, each session should have it's own copy of the package in memory. I think this works on the package level, not the session level, so you probably only need to do this in one session. But check it in the other session in case I'm wrong.

Newbie Joined: 23 Mar 2010 Posts: 3

I've tried this, and but changes only seem to affect the latest instance of the shared module.

Eg: Common module contains class called test.

1. Open 1st session in offline mode.
2. Open package editor: 2 tabs, 1 for common, 1 for 1st char.
3. T+/T- test will enable the class in common.
4. Close package editor.
5. Open 2nd session in offline mode.
6. Open package editor: 4 tabs, common (for 1st char), 1st char, common (for 2nd char), 2nd char
7. T+/T- in 1st char window toggles the class in the 2nd common tab. T+/T- in 2nd char window also toggles the class in the 2nd common tab.

Posted: Tue Mar 23, 2010 4:42 pm

Sounds like a bug with #T+/#T- and the Shared flag. It is supposed to allow two separate instances of the module in memory. I'll add it to the bug list.

However, keep in mind that even though the Shared flag is supposed to allow two instances of the same module, the module still only has a *single* pkg database file. For example, if there is a variable in the module called "testvar" and you set it's value from both sessions, the in-memory value might be different, but the value that gets saved to the disk file will be undefined.

So when designing a module like this, it will be important to ensure that session-specific variables are created within the specific session window and not withing the module itself.

Newbie Joined: 23 Mar 2010 Posts: 3

Yup the character specific variables are saved in the individual session windows. Need some clarification on the publish setting for the shared module: should it be local or global?

Posted: Wed Mar 24, 2010 4:28 pm

That setting determines the "scope" of the scripts within the module. In other words, "who can see these scripts". If you set it to Local, then only other modules in the *same package* can access the scripts. Since you want to use these scripts from your main session window, you should set it to Global.