Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
oxseyn
Wanderer


Joined: 26 Nov 2011
Posts: 71
Location: Colorado Springs

PostPosted: Tue Apr 10, 2012 2:59 pm   

How Should I Go About Multiplaying?
 
Sorry, a month ago or so, I posted about multiplaying got some good advice, tried several methods but ended up just going in circles.
It seems there are several possible methods to multiplay. I'm not sure which is the "most right" so I'm looking for suggestions. Here are the tasks I'd like to accomplish while multiplaying:

Shared map between characters
Some sections of the map are available to some characters but not to others. An example here would be that a character in one guild can enter specific rooms in that guild that other characters cannot. Some room exits work for some characters, but not for others. Some portals are available to some characters, but not others. They should have a way to tell if they can use the portal command or not. If possible, I would like to have a single map that contains all the rooms and a way to indicate to specific characters that certain rooms and exits are unavailable to them.

Reusable, shared packages that can be loaded simultaneously for multiple characters without affecting the values in the others
An example here would be prompt parsing. All my characters have the same prompt layout which provides values like health, health saturation, xp, etc. The same triggers and values can be used across several characters.

Shared variables between characters
I need characters to be able to access the variables specific to other characters. For example - if one character is a monk and one character is a knight - the knight should be able to see if the monk has aggro and defend him. The monk should be able to see the health and mana of the knight and heal them appropriately. They should both be able to see where they are located on the map.

The methods of multiplaying that I understand exist are the following - I'm just hoping someone can clear up what the "best" way is - in that I will be able to accomplish the tasks above and experience the least amount of bugs. :)

Connect to a single session multiple times
This is the first way I was shown. Create a single session that contains _everything_. Connect to it twice. Make the map it contains a shared package.

Connect to character-specific sessions simultaneously
I'm not sure exactly how this would work, but from what I've read on the forums, it seems to be the recommended method ... it looks like you'd have a "master dummy session" which contains the map. Then you'd have individual character sessions ... I assume that don't have a map module in them? Not sure exactly.

Connect to a single session that contains windows specific to each character
This is the way I started attempting to do this a month ago. I created a single session for the mud, then individual windows for each character. Each window (under the advanced tab) was configured with no network connection. Then I would explicitly connect using #connect. I couldn't get #CH or #PW to work in this mode.

So, suggestions, please :)
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4672
Location: Pensacola, FL, USA

PostPosted: Tue Apr 10, 2012 3:56 pm   
 
as far as the variables go, i would suggest a dbvar in a shared package, the same package could hold your prompt data and other scripts that everyone would use.

Char speciffic scripts go in that charections session package

@myChars.charName.variousStats

I would go with the master dummy setup for multiplaying, the master only has the map (and maybe all the shared stuff), while each char can have a #LOC object
_________________
Discord: Shalimarwildcat
Reply with quote
oxseyn
Wanderer


Joined: 26 Nov 2011
Posts: 71
Location: Colorado Springs

PostPosted: Tue Apr 10, 2012 5:22 pm   
 
shalimar wrote:
as far as the variables go, i would suggest a dbvar in a shared package, the same package could hold your prompt data and other scripts that everyone would use.

Char speciffic scripts go in that charections session package

@myChars.charName.variousStats

I would go with the master dummy setup for multiplaying, the master only has the map (and maybe all the shared stuff), while each char can have a #LOC object


So, following your advice, I've done the following.
With the session I've been configuring - I deleted the autolog information, closed the main window (left the map open) and converted the window to a module. This "dummy" session now contains a module which has my map and my prompt parsing triggers and variables.

I then created two separate sessions which each correspond to a character. I opened all three sessions. Connected the two character sessions, docked them both on the left and docked my map on the right.
Here's a picture:


That's all I've done so far.
How do I do the following:
Make the "Nannymud" module (which contains triggers & variables that should be unique to each character) available to the character windows? (window is the right term, right? not package or module).
How do I share the "Nannymud Map" which is part of the "Nannymud" session between both character windows - so that they share the same map (not have individual copies)?
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4672
Location: Pensacola, FL, USA

PostPosted: Tue Apr 10, 2012 6:16 pm   
 
You will be dealing with sessions.

Each character session is housed in a package.
That package will house the window the character data streams to.

Your master session holds the map/layout.

Anything unique to a character should be in that character's session package.

You should be able to make a #LOC object in each character package to show on the one and only map.
_________________
Discord: Shalimarwildcat
Reply with quote
oxseyn
Wanderer


Joined: 26 Nov 2011
Posts: 71
Location: Colorado Springs

PostPosted: Tue Apr 10, 2012 6:17 pm   
 
So, changing the "publish" setting from local only to "global" does make all the scripts contained by the nannymud module available to the character windows, however they share the variables - which doesn't work.
Reply with quote
oxseyn
Wanderer


Joined: 26 Nov 2011
Posts: 71
Location: Colorado Springs

PostPosted: Tue Apr 10, 2012 6:25 pm   
 
If I try to open my master session first cmud crashes. However, if I open the character sessions first, then the master session it seems fine.
Any idea what I'm doing wrong?
Reply with quote
oxseyn
Wanderer


Joined: 26 Nov 2011
Posts: 71
Location: Colorado Springs

PostPosted: Tue Apr 10, 2012 6:34 pm   
 
shalimar wrote:
You will be dealing with sessions.

Each character session is housed in a package.
That package will house the window the character data streams to.

Your master session holds the map/layout.

How is the "layout" saved? How do I ensure it's saved in the master session?

Quote:
Anything unique to a character should be in that character's session package.

I think I can make this work. I can leave the triggers themselves in the master session.
Hopefully it's possible to parse the captured data into dynamically referenced variables? I.E. The trigger can be aware of which window it parsed the data from and reference that window's variable directly?
So, hopefully I can do something like:
Code:
 //%windowname%/stats/hp = %2


You should be able to make a #LOC object in each character package to show on the one and only map.[/quote]
Oki doki :)
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4672
Location: Pensacola, FL, USA

PostPosted: Tue Apr 10, 2012 6:53 pm   
 
%item(%names, 1) = the main window of any given session
_________________
Discord: Shalimarwildcat
Reply with quote
oxseyn
Wanderer


Joined: 26 Nov 2011
Posts: 71
Location: Colorado Springs

PostPosted: Tue Apr 10, 2012 7:25 pm   
 
shalimar wrote:
%item(%names, 1) = the main window of any given session

Tx.

Code:
#SAY %item(%names, 1)

Yeilds the output "2".

Code:
test = 2; #say @test

Yields the output "2'".

Code:
//%item(%names, 1)/test = 5

Yields no errors, but #say @test yields "2" - so the statement didn't work.

And interestingly, the following two examples both yield syntax errors:
Code:
//%item(%names, 1)/test = 5;

Code:
//%item(%names, 1)/test = 5; #say @test


Any idea?
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4672
Location: Pensacola, FL, USA

PostPosted: Tue Apr 10, 2012 7:46 pm   
 
part of me wants to think your master session may be corrupted... that or the main window is literally named '2'
_________________
Discord: Shalimarwildcat
Reply with quote
oxseyn
Wanderer


Joined: 26 Nov 2011
Posts: 71
Location: Colorado Springs

PostPosted: Tue Apr 10, 2012 7:59 pm   
 
I was executing that directly from a character window/session. The reason it yielded 2 was because i set it right above that to 2. I was just showing with that example that even though there was no syntax error from //%item(%names, 1)/test = 5 it didn't set the variable to 5.
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Tue Apr 10, 2012 8:08 pm   
 
The syntax "//%item(%names,1)/test = 5" will not work. Cmud will not parse values on the left hand of that equation. Instead, use the #VAR syntax:
Code:
#VAR //%item(%names, 1)/test 5; #say @test
Reply with quote
oxseyn
Wanderer


Joined: 26 Nov 2011
Posts: 71
Location: Colorado Springs

PostPosted: Tue Apr 10, 2012 8:23 pm   
 
Rahab wrote:
The syntax "//%item(%names,1)/test = 5" will not work. Cmud will not parse values on the left hand of that equation. Instead, use the #VAR syntax:
Code:
#VAR //%item(%names, 1)/test 5; #say @test


Hmm, this gives me a syntax error :(
Reply with quote
oxseyn
Wanderer


Joined: 26 Nov 2011
Posts: 71
Location: Colorado Springs

PostPosted: Tue Apr 10, 2012 8:26 pm   
 
Does the master session have to have a window? It had a window, but I converted it to a module ... so now it's only got a module (which contains some settings) and a map.
Reply with quote
oxseyn
Wanderer


Joined: 26 Nov 2011
Posts: 71
Location: Colorado Springs

PostPosted: Tue Apr 10, 2012 8:31 pm   
 
Here's a bugreport I generated from the crash that occurs when I try to load my "dummy" session first (it loads fine as long as i load the character sessions first).
Quote:
date/time : 2012-04-10, 14:28:38, 719ms
computer name : PURGATORY
user name : **********
registered owner : ***********
operating system : Windows 7 x64 Service Pack 1 build 7601
system language : English
system up time : 1 day 4 hours
program up time : 1 hour 10 minutes
processors : 8x Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
physical memory : 7941/16362 MB (free/total)
free disk space : (C:) 130.32 GB
display mode : 1920x1080, 32 bit
process id : $1f54
allocated memory : 97.59 MB
executable : cMUDPro.exe
exec. date/time : 2011-04-20 13:29
version : 3.34.0.0
compiled with : BCB 2006/07
madExcept version : 3.0k
data dir : C:\Users\*********\Documents\My Games\CMUD\
contact name : ************
contact email : **********
callstack crc : $782bb3f8, $6fabee3a, $6fabee3a
exception number : 1
exception class : EAccessViolation
exception message : Access violation at address 00F54023 in module 'cMUDPro.exe'. Read of address 00000020.

Main ($2304):
00f54023 +003 cMUDPro.exe PrefDat 11536 +1 PrefRec.GetModuleNum
00e2318a +00e cMUDPro.exe PARENT 2532 +2 TParentForm.UpdateDefaultModule
00e23151 +205 cMUDPro.exe PARENT 2526 +44 TParentForm.CreateWindows
00f416f5 +011 cMUDPro.exe PrefDat 3329 +1 PkgData.CreateWindows
00f41e30 +528 cMUDPro.exe PrefDat 3524 +95 PkgData.Load
00e23481 +29d cMUDPro.exe PARENT 2658 +112 TParentForm.NewWindow
00e27b77 +3c3 cMUDPro.exe PARENT 4427 +48 TParentForm.NewMUD
00e23a02 +01a cMUDPro.exe PARENT 2946 +2 MUDWindow
00e23ab1 +085 cMUDPro.exe PARENT 2963 +13 TParentForm.CharAction
00e23b66 +006 cMUDPro.exe PARENT 2993 +0 TParentForm.DoAction
004c06eb +2bb cMUDPro.exe Controls TControl.WndProc
004c46ef +4fb cMUDPro.exe Controls TWinControl.WndProc
004a6c4f +553 cMUDPro.exe Forms TCustomForm.WndProc
00dd302c +020 cMUDPro.exe DXSounds 2128 +9 TCustomDXSound.FormWndProc
00dd151c +00c cMUDPro.exe DXClass 635 +1 TControlSubClass.WndProc
004c3e18 +02c cMUDPro.exe Controls TWinControl.MainWndProc
0047d888 +014 cMUDPro.exe Classes StdWndProc
764e7945 +016 USER32.dll CallWindowProcA
006ff1af +0a7 cMUDPro.exe aqDockingUtils 1728 +7 CallDefWndProc
006ff29d +0dd cMUDPro.exe aqDockingUtils 1776 +41 TaqWindowEventFilter.WndProc
0047d888 +014 cMUDPro.exe Classes StdWndProc
764d7bc5 +00a USER32.dll DispatchMessageA
004aedc4 +0fc cMUDPro.exe Forms TApplication.ProcessMessage
004aedfe +00a cMUDPro.exe Forms TApplication.HandleMessage
004af0f3 +0b3 cMUDPro.exe Forms TApplication.Run
00ffaccc +088 cMUDPro.exe cMUDPro 393 +20 initialization
76733398 +010 kernel32.dll BaseThreadInitThunk

error details:
Trying to load a session that contains only a module and a map. It's meant to be a dummy session that contains the layout, shared scripts and the map file that my characters all share.
Reply with quote
oxseyn
Wanderer


Joined: 26 Nov 2011
Posts: 71
Location: Colorado Springs

PostPosted: Tue Apr 10, 2012 8:45 pm   
 
I just tested this again. I created a brand new session "testing." I connected to it.
I attempted to convert the window to a module, but got an error that the currently active session cannot be converted to a module.
So I disconnected and went into work offline mode. I then converted the main window to a module.
I reconnected and immediately crashed. CMUD now crashes everytime I try to load that session.

So it appears the answer is the master session MUST have a window (I cannot convert it's main window to a module) even if that window is hidden.
Does this sound right?
Reply with quote
oxseyn
Wanderer


Joined: 26 Nov 2011
Posts: 71
Location: Colorado Springs

PostPosted: Tue Apr 10, 2012 9:55 pm   
 
Ok - so I'm trying all kinds of junk.
I'm very confused about how the "layout" is saved when dealing with multiple sessions.

I created a brand new session "Testing." It's got a single window which has no network connection. It's also got a Map.
I dock the map to the right of the my main window. I select "save layout." I then close all windows, reopen the session ... and the map is not there. I have to open it up again. What the heck?

On that same note, I have a similar testing session (no network connection). I open a my character sessions from within it. I arrange my windows then select save layout.
I close all the windows. I open up the main session - and no map. No saved layout. I open up one of the other characters - no saved layout. I open up the other character ... and it tries to adjust the layout but completely mucks it up.

So ... here are my specific questions:
1. When I have just a single session with no network connection and a map docked to the right - why will the session layout not save? (I tested this with a session that has a network connection, the layout is saved just fine, it's specific to sessions with no network connection)
EDIT: This seems like a bug to me, but as work around, I gave it a network connection and just launch it offline.
2. Where is the session layout information saved?
EDIT: I found it located in the associated .xly file.
3. How can I clear a session's saved layout information?
EDIT: I haven't tried yet, but I assume I can clear out the .xly file. Hopefully there is another, better way.
4. Can I specify that a session should have NO layout information?
I found the checkbox that specifies not to use layout information.
5. Does it matter which window is active when I save the session layout? I.E. if a character window is open and I try to save the session layout - is it going to create layout information for that character that I specifically don't want?
6. If I can figure it how to save the layout information correctly - is it safe to assume that when I open up character sessions that they will automatically be added into the main layout where I want them? (I.E. docked to the master sessions main window)
7. Can I have my master session automatically open the other sessions in an offline state, rather than having to manually open the character sessions?
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Wed Apr 11, 2012 1:41 am   
 
Code:

Supersession
|
---Session
|   |
|   ---session properties
|   |
|   ---packages to include
|   |   |
|   |   ---Package1
|   |   |   |
|   |   |   ---Window
|   |   |   |   |
|   |   |   |   ---triggers, aliases, etc
|   |   |   |
|   |   |   ---Another window or module
|   |   |      |
|   |   |      ---more triggers, aliases, etc
|   |   |
|   |   ---PackageN
|   |   |   |
|   |   |   ---Window
|   |   |   |   |
|   |   |   |   ---triggers, aliases, etc
|   |   |   |
|   |   |   ---Another window or module
|   |          |
|   |         ---more triggers, aliases, etc
|   |
|   ---layout file (sessionname.xly)
|
---Session
|   |
|   ---session properties
|   |
|   ---packages to include
|   |   |
|   |   ---Package1
|   |   |   |
|   |   |   ---Window
|   |   |   |   |
|   |   |   |   ---triggers, aliases, etc
|   |   |   |
|   |   |   ---Another window or module
|   |   |      |
|   |   |      ---more triggers, aliases, etc
|   |   |
|   |   ---PackageN
|   |   |   |
|   |   |   ---Window
|   |   |   |   |
|   |   |   |   ---triggers, aliases, etc
|   |   |   |
|   |   |   ---Another window or module
|   |          |
|   |         ---more triggers, aliases, etc
|   |
|   ---layout file (sessionname.xly)
|
---layout file (supersessionname.xly)


Supersessions never, EVER have packages associated with them and therefore cannot have windows/modules of their own. Also, individual session layout files are never used in a supersession (saved or loaded).
_________________
EDIT: I didn't like my old signature
Reply with quote
oxseyn
Wanderer


Joined: 26 Nov 2011
Posts: 71
Location: Colorado Springs

PostPosted: Wed Apr 11, 2012 1:48 am   
 
MattLofton wrote:
Supersessions never, EVER have packages associated with them and therefore cannot have windows/modules of their own. Also, individual session layout files are never used in a supersession (saved or loaded).

Oki doki. So how do I create that supersession? If I create a new session an connect to it offline, I cannot delete the module or remove the package from the session ...
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Wed Apr 11, 2012 2:17 am   
 
Step 1: starting from the Sessions window with all other sessions closed, open up one session
Step 2: open up another session
Step 3: arrange sessions/windows as desired (by default, all the sessions are tabbed to each other; each session is loaded in with windows displayed per their individual layout files, which is the only time the individual layout files are used)
Step 4: click on File|Save Session As... and give it a name

Just like with any other regular session, the supersession can only load its component sessions all online or all offline. You cannot have it so that session1 connects to the mud while session2 stays offline. The supersession icon is going to look identical to the one used for regular sessions, so it's useful to make the name reference something about the multiple sessions it opens.
_________________
EDIT: I didn't like my old signature
Reply with quote
oxseyn
Wanderer


Joined: 26 Nov 2011
Posts: 71
Location: Colorado Springs

PostPosted: Wed Apr 11, 2012 6:06 am   
 
Thanks Matt :) That works beautifully and clears up all my confusion. If this was in the documentation somewhere and I missed it I'm very sorry.
The problem I see now is that for all my session #CH and #PW all use the information of the last session that was opened. I searched for the forums and found an old quote from 2006 by Zugg on the subject, curious if this is still the case ...

http://forums.zuggsoft.com/forums/viewtopic.php?p=102345
Zugg wrote:
The only tricky part is the autologin. Since your username/password are stored with the session icon, using #CH or #PW in your autolog triggers will reference your main characters username/password. So you will need to edit the autolog triggers in the second window to hardcode your second character name/password. That's something that will be improved in the future, but not before the public release.


If it is, is there a way to "hide" the hardcoded password text that's send to the mud like the #PW function rather than having it displayed on the screen?
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Wed Apr 11, 2012 12:59 pm   
 
There is the #SENDRAW command.
Reply with quote
oxseyn
Wanderer


Joined: 26 Nov 2011
Posts: 71
Location: Colorado Springs

PostPosted: Wed Apr 11, 2012 7:10 pm   
 
The tracking is acting funky.
I can see that in each character's package, at the root level there is a LOC object (I created them). They are each populated with a location on the map.
Now, when I start up my master session, everyone logs in just fine. Then from each session i type #TRACK <char's loc object name>
I don't get an error, but nothing happens. It doesn't track. I can still see my characters displayed in their old locations. I move around a bit, does not update.

I then select a room, then go to the map menu bar and click on the "set" option then select each character in turn. It then starts tracking.
Any idea what's going on here?
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net