 |
| ecourt |
Posted: Sun Jan 09, 2011 7:17 pm
yearly test, Cmud still don't work for multiplaying. |
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
 Posted: Mon Mar 14, 2011 4:42 pm
|
1) The Map module that is created in your session _can_ be moved into a separate package.
2) You _have_ been told before that the best way to have multiple sessions is to do what I said and DraxDrax detailed. You were told when you brought this topic up a year ago.
As for sometimes only wanting to play one character and not the other, you can use one of the individual sessions. Use the dual session if you want to play both together. |
|
|
|
|
ecourt
Apprentice
Joined: 29 Dec 2000
Posts: 146
Location: USA
|
Posted: Mon Mar 14, 2011 4:43 pm
|
I am going to try this shortly, but let me tell you what I've seen in the past when I do this.
Suddenly the triggers and aliases stop working in session apples. When I go look, it shows packages I wanted to work on apples are disabled. When I enable these for apples, suddenly they start working for Oranges too. It's been a good 6 months since I've tried this, so I'll try it again. |
|
|
|
|
ecourt
Apprentice
Joined: 29 Dec 2000
Posts: 146
Location: USA
|
Posted: Mon Mar 14, 2011 5:00 pm
|
| Rahab wrote: |
1) The Map module that is created in your session _can_ be moved into a separate package.
2) You _have_ been told before that the best way to have multiple sessions is to do what I said and DraxDrax detailed. You were told when you brought this topic up a year ago.
As for sometimes only wanting to play one character and not the other, you can use one of the individual sessions. Use the dual session if you want to play both together. |
#1 - it can be moved into a SESSION, it CAN NOT be moved into a package.
#2
And I'm trying to point out THIS DON'T WORK but be and my 40 mud buddies are all stoopid.
That's fine, that's 40 less licenses to be sold.
we're all smart enough to use zmud, so that's what we'll keep doing. Sure some of the new features would be nice, but having a clien that works, is more important than having new wingdings....
I've even asked the other guys that play, why doin't you post over here, if enough people tell them it don't work, maybe it will get fixed....
They say, too much trouble, and when we do, people just tell us we don't know what we're doing.
so whatever... maybe I'll come back in 6 months to see if anything working has been released, maybe I'll just give up.
but I promise there's a much larger group than you know that cant use cmud. hide your head, and say if you click enough buttons, you can eventually make something that worked out of the box for zmud, work for cmud, but I haven't managed to get there yet....
I only have 22 years of IT background, more certifications, and programming languages than I can count, I'm sure it's just me. |
|
|
|
|
DraxDrax
Apprentice
Joined: 22 Mar 2009
Posts: 149
|
Posted: Mon Mar 14, 2011 5:14 pm
|
Seems possible to me... |
|
|
|
|
ecourt
Apprentice
Joined: 29 Dec 2000
Posts: 146
Location: USA
|
|
|
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Mon Mar 14, 2011 7:20 pm
|
Ecourt,
No one has said you or your friends are stupid. No one has said that you don't know what you are doing. If you wish to take offense when no one has given offense, that is your right, but it is also a good way to make people decide that helping you is not worth the aggravation. When you say that you have never been told something before when clearly you have, that too is not helpful.
The reason we have been repeating the procedure is because that procedure is supposed to work, and it works for the rest of us. If you want help, the best thing you can do is follow the procedure step by step, and tell us what precisely what happens. Saying "THIS DON'T WORK" does not help us figure it out. If you want to go away for six months, that too is your right. But it won't get this fixed. Zugg can't fix a problem that he can't reproduce, and so far no one here has been able to reproduce it. With your IT experience, I'm sure you can understand that. The only way to get it fixed is to help us narrow down where the problem is. |
|
|
|
|
ecourt
Apprentice
Joined: 29 Dec 2000
Posts: 146
Location: USA
|
Posted: Mon Mar 14, 2011 8:05 pm
|
search back through on my name...
I've posted logs, sent logs, tried stuff... and to be honest, I've spent more time on it than it's worth to me.
Cmud don't have anything in it I cant live without, and when I get frustrated, I just swap back to zmud.
There seems to be no interest in fixing the problem, only coming up with some strange way around it, that makes mudding so complicated, I don't want to do it. Sorry, I'm just calling it like I see it.
Any attitude you sense from me is either from frustration or what I feel I am already being fed. I'm not trying to be a pain.
The process you listed may work for some, but it does not work for the way I play. I swap around characters a lot. I may get one character on, and the supporting character may swap 3 times in 30 minutes. that works fine in Zmud, but will crash cmud every tiime (that's how I made the crash you see above).. just left the first character on, and swapped the 2nd character twice. |
|
|
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Mon Mar 14, 2011 8:37 pm
|
I'm sorry that you feel using a third, dual, session does not work for the way you play. If you choose not to make a dual session as described in that procedure, then you would have to follow DraxDrax's procedure each and every time you try to use two sessions at once on Cmud. That is not a bug--it is the way packages are designed. Packages need to know which windows and modules they apply to, and the way that is done is by adjusting those checkboxes as described in the procedure. Saving the dual session as in that procedure allows you to save those settings, otherwise you will have to set them every time. Using a dual session does not necessarily mean that you have to have both sessions logged in at the same time. You could instead open the session in offline mode, and then log in to one session, or the other, or both, and log out of either whenever you wanted.
If you still feel the dual session does not work for you, then you can just open Cmud multiple times, once for each session you want. If neither of these works for you, then I guess you will have to stick with Zmud. This is the way packages work in Cmud.
Now, if you follow that procedure and find that it doesn't work, then perhaps we can help figure out why. It's not clear to me whether the crash you describe in your last post is from following DraxDrax procedure or by following your usual procedure. If it is from DraxDrax procedure, please describe exactly what led up to the crash. |
|
|
|
|
DraxDrax
Apprentice
Joined: 22 Mar 2009
Posts: 149
|
Posted: Mon Mar 14, 2011 10:19 pm
|
| Rahab wrote: |
| If you choose not to make a dual session as described in that procedure, then you would have to follow DraxDrax's procedure each and every time you try to use two sessions at once on Cmud. |
It appears to me that you don't actually have to do it each and every time that you try to use two sessions together concurrently, just the first time that any two sessions are loaded together. After doing so once, Cmud appears to remember which packages are meant to be disabled and which are meant to be enabled. It's just the first time they're loaded together that packages a module hasn't 'seen' before become enabled automatically.
So, if you created 35 different sessions for all 35 different characters, then loaded them all at the same time, you could go through each module, manually disabling the packages you didn't want that module to use and, after doing that once, you could load any combination of those 35 sessions and Cmud should keep everything straight. That would take a while, and be a terrible nuisance, but it should work and you'd only have to do it once.
There really should be an option somewhere that would let us toggle whether or not packages that get loaded with a session or newly created become automatically enabled or disabled for other modules and windows that are loaded concurrently. Right now, it seems they always become enabled. If it could be toggled so that they were automatically disabled, I believe Cmud would behave more like zMUD did for ecourt and his life would be made that much easier.
Curiously, if I have seven packages active and click on New -> Window from within one of the active session's packages or modules, the window I create will come in to being with all seven packages enabled. If I create a window with the #WINDOW or #CAPTURE commands, the new window has only it's parent module enabled. That seems a little anomalous to me.
I also hope I'm getting all the nomenclature right... |
|
|
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Tue Mar 15, 2011 12:40 pm
|
That's correct, DraxDrax, it will remember the which packages are to be disabled or enabled to each other--IF you save that combined session, which is what I was saying. Ecourt says he doesn't want to do that, because sometimes he plays one char, sometimes another, and he wants to load or unload the sessions on the fly.
|
|
|
|
|
ecourt
Apprentice
Joined: 29 Dec 2000
Posts: 146
Location: USA
|
Posted: Tue Mar 15, 2011 1:47 pm
|
OK, that all makes sense...
So from what you guys are telling me, the only way I can run Cmud to do what I want is to run 2 separate instance of cmud, but the downsides are
no passing commands between chars,
no way to have 1 chat window, to catch all tells |
|
|
|
|
DraxDrax
Apprentice
Joined: 22 Mar 2009
Posts: 149
|
Posted: Wed Mar 16, 2011 7:52 am
|
| Rahab wrote: |
| That's correct, DraxDrax, it will remember the which packages are to be disabled or enabled to each other--IF you save that combined session, which is what I was saying. Ecourt says he doesn't want to do that, because sometimes he plays one char, sometimes another, and he wants to load or unload the sessions on the fly. |
You have misunderstood me, Rahab. A separate 'combined session' does not need to be created. Your suggestion was that ecourt create three sessions. For the sake of argument, let's call them session Apples, session Oranges and session Both. To play the apples and oranges characters together, you would have him load the 'Both' session; a 'combined session', as you've called it.
I am saying that he can do it with just a single session per character. Just Apples and Oranges, no 'Both' session. It's possible to load sessions Apples and Oranges in to Cmud at the same time. If those two sessions are ever loaded concurrently, Cmud will remember which packages are enabled and which are disabled for each window or module and the same packages will be disabled and enabled automatically the next time those same two sessions are ever loaded concurrently. If ecourt tried making 'combined sessions' for every possible combination of two characters that he might want to play when he has 35 different characters, he'd need 595 different 'combined sessions', and easily swapping between them wouldn't be possible. I'm saying he can accomplish the same thing, and swap characters around 'on the fly' with just 35 sessions for 35 different characters, each with unique settings.
| ecourt wrote: |
OK, that all makes sense...
So from what you guys are telling me, the only way I can run Cmud to do what I want is to run 2 separate instance of cmud, but the downsides are
no passing commands between chars,
no way to have 1 chat window, to catch all tells |
That's not what we're saying. At least, that's not what I'm saying. You can have multiple characters open within the same instance of Cmud, share commands between them, and have a single chat window for them to share. There are ways to try doing this which will crash Cmud, and it sounds like you've been getting some practice finding those ways, ecourt. But there are also ways to do it which, so far as I can tell, are perfectly stable and should allow you to accomplish everything you want to do.
To try to isolate the problems you're having, let's take this a step at a time, nice and slow. This is what you've described doing:
| ecourt wrote: |
I load session 1, which is character1, which has 2 packages, and 1 package that applies to all my characters.
load session 2, which is character2, which has 2 packages, and the same shared package as above. |
Do that exact same thing, but after you've loaded both sessions, follow the steps outlined in my first post to manually disable packages as appropriate to each window and module. Once you've done that, click 'save' within the package editor. Here's an example of me saving the settings for my 'Oranges' window. Notice that the packages 'Apples' and 'ApplesOne' are disabled for that window under the Advanced tab, while Oranges, OrangesOne and SharedPackage are enabled.
After you've set that up, press Ctrl+S to save everything, or click on File -> Save from within the package editor to accomplish the same thing. Now exit the package editor and close both sessions by clicking on File-> Close all from Cmud's main file menu. Then open both sessions again, one at a time just as you described doing where I've quoted you. Once they're both open, open the package editor (Ctrl+G) and check to see that the appropriate packages you just disabled for each window by following the steps described in my first post, are still disabled appropriately. Don't play on the mud yet, or use any aliases or triggers, just confirm that the packages are switched on or off as appropriate. When I test this, it works for me. Does it work for you?
If that works, this is the next thing I'd like you to try:
1) With both sessions open in Cmud, open the package editor (Ctrl+G).
2) Select the shared package that both of your sessions use.
3) Click on the main module of that package.
4) Click on 'New' -> 'Window' and name it something like 'SharedChat'.
Here's what that should look like:
When you create that window, all packages will be enabled for it. Use the method described in my first post to disable EVERY package for the shared chat window, except for the shared package in which it resides; that package will be greyed out and can't be disabled. Also disable the network connection for your shared chat window and its command line. Here's a picture of me about half way done disabling all the packages:
Here's a picture after all the necessary changes have been made:
Once you've done that, press Ctrl+S from within the package editor to save the changes, or click on File -> Save, then close the package editor. You should now have three windows open, one window for each of the two active sessions and one window that's in the shared package for both sessions. It should look something like this:
Now type #SHOW This line comes from the '%window' window. in to your first session's window and press enter. This simulates output from the mud.
Then type #CAP <name of shared chat window> and press enter. This simulates a capture trigger operating in that window.
Repeat these steps for the other sessions window. Are the lines being captured correctly? It should look like this:
The 'SharedChat' window MUST be placed within a shared package accessible by both sessions for it to function properly. In my example, I've called it SharedPackage. Any triggers you create which are meant to automatically capture mud output and send it to the SharedChat window CANNOT reside in the same package AS the 'SharedChat' window itself. If you tried placing those sorts of triggers within the same package as the SharedChat window, you'd create an infinite loop. |
|
|
|
|
ecourt
Apprentice
Joined: 29 Dec 2000
Posts: 146
Location: USA
|
Posted: Wed Mar 16, 2011 12:53 pm
|
I followed your dirs...
(FYI, this is a brand new machine, so im building new packages, and new stuff. not importing anything from zmud)
Session 1 loaded, one shared package assigned, one char specific package.
Session 2 loaded, same shared package assigned, one char specific package.
close session 2,
load session 3, which is configed just like the other 2.
close session 3, to load session 4,....
and crask (never started to load session 4... crash on close of session 3)
 |
|
|
|
|
Tech
GURU
Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA
|
Posted: Thu Mar 17, 2011 4:45 am
|
Hey Ecourt, I just ran through the scenario you described and didn't get a crash. I did this in CMUDPro 3.33a. I'm guessing it's because my shared and char specific packages were only had a few random things in them. One possibility is the content of the packages may not be playing well when loaded. Can you please post th code the Shared Package, as well as the Char Specific packages. Also when you post the image for the error, can you post the one the 'call stack' tab. That you usually provide some clues as to where to focus the search for the bug.
I can imagine your frustration because you have been dealing with this off and on for quite some time. Especially when, I imagine, you are looking forward to using the new CMUD features. I sure with a bit more perseverance we'll uncover the root cause, and help make CMUD a better product for it. For what it's worth, thanks for sticking with this I'm sure we'll get ti fixed soon. |
|
_________________
Asati di tempari! |
 |
|
|
ecourt
Apprentice
Joined: 29 Dec 2000
Posts: 146
Location: USA
|
Posted: Thu Mar 17, 2011 12:10 pm
|
This is a brand new install, and these are all new packages.
each package had either 1 alias, or nothing in it.
the one alias I created was simply df - drink fountain
To keep things simple, I had not yet created a shared chat window.
This copy of win7 is about a week old.
I'll try it again, and see if I can get the stack-dump |
|
|
|
|
ecourt
Apprentice
Joined: 29 Dec 2000
Posts: 146
Location: USA
|
Posted: Thu Mar 17, 2011 1:12 pm
|
ok, I noticed I may have been doing something not exactly as the instructions said...
Each time I loaded a new character, I was checking the new session, to make sure it had the right packages. I was not checking the packages that were loading on session1. each time, I have to uncheck all the packages that were loading on that session too.
When I load the chat window, I'll have to check the packages that load on that session as well.... SHEW, I just got 4 chars setup right now, and it's already a ton of work.
I did get a dump this time... but I had to do a few more character swaps than last time...
I was going to copy and paste this as text, as it would be easier to go through, but it wouldn't copy as text.. so here ya go. |
|
|
|
|
Tech
GURU
Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA
|
Posted: Thu Mar 17, 2011 3:44 pm
|
Ok... this interesting. The error suggests the problem occurred while trying to update a button. Specifically it seems to run into some kind of error when setting up the new Mud Window. Do any of your packages have buttons in them? Just so I'm absolutely clear (because I may have missed it) what are the exact steps are you using to 'close the session'. In my test I did it by going to File -> Close Window for session window I wanted to close.
FYI you can use %packages to programmatically control which packages are loaded. When I need to control this I usually do it in an onLoad Event.
Finally are your tests being run online or offline? I must admit I was not unchecking the packages on session1 either. |
|
_________________
Asati di tempari! |
|
|
|
ecourt
Apprentice
Joined: 29 Dec 2000
Posts: 146
Location: USA
|
Posted: Thu Mar 17, 2011 3:51 pm
|
I was on-line...
I do have a couple buttons in my zmud cofig, but I have not imported anything.
when closing the window, I didn't manually close antyhing. I logged off the mudd, then the session closed.. I would guess the window that was trying to open was the window that says 'reconnect, new session, whatever, whatever' |
|
|
|
|
Scarn
Apprentice
Joined: 24 Jul 2005
Posts: 137
|
Posted: Thu Oct 11, 2012 12:36 pm
|
I haven't read all the replires, but if you issue is not wanting aliases to clash just make classes.
And with one alias (or even a trigger) when you log on a certain class character it will disable/enable the relevant classes.
Trigger:
You log on into Tolkien the Wizard.
todo
#T- WarriorClass;#T- ArcherClass;#T+ WizardClass |
|
|
|
|
ecourt
Apprentice
Joined: 29 Dec 2000
Posts: 146
Location: USA
|
Posted: Thu Oct 11, 2012 12:50 pm
|
this post is over a year old.. but still same song and dance...
You have multiple sessions running for multiple characters, so classes with triggers on them don't work.
I gave up a long time ago.. Zmud handles it perfectly, all I can say is cmud was designed badly, and I still run zmud.
It's not going to get fixed, and I'm not losing any sleep over it. |
|
|
|
|
meddlesome
Wanderer
Joined: 24 Aug 2012
Posts: 70
|
Posted: Fri Oct 12, 2012 3:45 am
|
When cMUD does what he described to me, it's usually an open dialog box that has slipped behind the Session Window. When that happens there's not much that can be done but to close completely down and try again. I doubt that's the case though.
He may have a conflict with Anti-virus too. Need to close down as much as possible before running cMUD. The Black is cMUDs way of saying it's running out of resources. Something running is gobbling up resources. |
|
_________________
Intel Core 2 Quad Q9450 @2.66GHz
MDAC 2.8 SP1 ON WINDOWS XP SP3
Msjet40.dll ver 4.0.9511.0 + Security Bulletin MS08-028
CMUD v237
Order number: **7829 |
|
|
|
Daern
Sorcerer
Joined: 15 Apr 2011
Posts: 809
|
Posted: Fri Oct 12, 2012 5:24 am
|
You can usually just hit the enter key to close a dialog that pops up behind another window, it might have adverse effects though.
|
|
|
|
|
|
|
|
|
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
|
|
