Zugg Software :: View topic

Newbie Joined: 19 Oct 2008 Posts: 8

Ok, here is another problem I am experiencing. I wouldn't be surprised if it is at least somewhat related to the issue I raised about styles getting confused and causing the edit textbox for triggers (etc) to display the wrong colors. But this one is about the Status window.

I use the Status window to display various screen-scraped stats related to XP, HP, etc etc, as well as what spells are affecting me, and when the next game sunrise and sunset are (it's important in the game); things like that.

1: All text disappearing

The main problem with the Status window is that it seems that I need to bring focus to the main Session window or else all the text on the Status window disappears. For instance, I have several tabbed windows to display various discussion channels, and if I click on any of those to e.g. scroll up to see what was said, the status window goes blank.

Once focus is brought to the Session window, the Status window text will stay visible if I then click in the Status window itself, or even if focus goes to a Help or Package Editor window. But if I bring focus to any of these other tabbed windows, unless I specifically click back to the Session window, all Status window text remains invisible.

This also happens if I click in the Command line to edit something I've typed. I need to click on the main session window which brings focus to it, but still lets me type in the command line, in order for things to work "normally."

I have re-re-re-checked the Style settings both for Global as well as individual windows, and they are all set exactly the same way.

2. Three particular variable values mysteriously disappearing until I started troubleshooting

Also, I just ran into a new and very bizarre issue with a few variable values that suddenly became temporarily invisible even when all the rest of the Status window text appeared correctly. I guess they may either be being displayed in the same color as the background, or just not being displayed at all. I tried to select the text with the mouse (which often makes seemingly invisible text appear in reverse colors) but I still saw nothing.

So these three Status items would only display the fixed text (i.e. the string-literal "label" for a value) but did not display the dereferenced value itself (by this I mean the result of @variable). I checked the variables being referenced and they all did contain the correct values.

To troubleshoot, I took another variable which was displaying correctly on another line in the same window, and pasted it (in the Status item definition) next to the one that was not appearing. Then magically both of them appeared together! Then I removed the pasted one and the previously invisible value stayed visible. The other 2 offending status items all required the same kludge to make them appear again.

Wizard Joined: 22 Mar 2007 Posts: 2320

1) I think each display window has a separate status window associated with it. When you focus on a window, the status window will be the one associated with that display window.

Posted: Wed Nov 12, 2008 8:29 pm

Actually, there is only a single Status window. The contents of the status window are changed based upon what other window has the focus. Each other window can have it's own #STW status window items. When you click on Window A, the status window items for Window A are displayed in the status window. If you click on Window B, then the status items for Window B are displayed in the status window.

Now, in zMUD, there was a concept of "child windows" that couldn't have their own status window items. In CMUD, each window is a primary window that can have their own settings. So the concept of the single Status Window doesn't work as well in CMUD and yes, it is certainly possible to click on a window and have the status window go blank because there are not any status items.

One solution to this is to try and put your status items in a Global Module so that those items are always visible to the status window.

If clicking on a command line doesn't focus the correct session window, then your layout might be messed up. For example, if you accidentally undock the command line and then try to re-dock it to the bottom of the window, it is likely that you will end up with the command line docked with the parent application window (the one with the main menu and toolbar) rather than at the bottom of the specific session window (you usually have to undock the session window, put the command line back into the bottom of the session window, then redock the session window back to the main application window).

Anyway, hopefully that helps with understanding how the status window currently works.

Apprentice Joined: 29 Dec 2000 Posts: 146 Location: USA

Thanks for the information Zugg, that explains a lot to me. This is the issue I've had with Cmud since inception, and why why I'm still using Zmud.

I run 2 characters on the mudd I play. Sometimes things happen on the character thats not on screen. In Zmud, I just pop those events to a home-made status window (just a #window stuff). That stuff window is visable whichever character I am on.

I have not found a good way to do this in Cmud, and has been the source of many crahses and corrupt files.
Zugg, I really think there needs to be a way to either send info to all status windows, or a way to make a global status window. Until that happens, I can't multi-play, which means I will still be using zmud.

Posted: Fri Dec 05, 2008 6:31 pm

Just move your Status Window items into a shared package that is enabled for each character session. Or, if both character windows are stored within the same session, just create a global Module and put the shared status window items into that Module.

The Status Window displays whatever status items are "visible" for the currently selected window, so by making these status items global, all windows will show them. That's the flexibility inherent in the Module and Package system in CMUD that wasn't possible in zMUD.

Apprentice Joined: 29 Dec 2000 Posts: 146 Location: USA

Posted: Fri Dec 05, 2008 8:17 pm

1.34 was a public version and was, as I recall, extremely buggy in this area. It's possible you had that version, and yes, you would've seen some problems like this. But I find it quite hard to believe you were using a version almost 18 months old this entire time.

Apprentice Joined: 29 Dec 2000 Posts: 146 Location: USA

no, I keep swapping back to zmud...

why would I continue to use something that keeps crashing ?

pretty sure whatever version it was, was 2.3X ...

Apprentice Joined: 29 Dec 2000 Posts: 146 Location: USA

ok, played with 2.37 for several hours today...
I've crashed it once already

I tried adding a global module that would post say and tell messages to the #stw ...
it still don't work. they messages do show, but only when you are on the target window.

So I decided to try to make it a package, and assign it to the sessions.
That didn't work either.

Posted: Sat Dec 06, 2008 12:21 am

Show us the code. Your description is too simple to tell us exactly what it is you were doing - without knowing exactly what you've done, we can't tell you how to improve it.

Apprentice Joined: 29 Dec 2000 Posts: 146 Location: USA

it is that simple !
the simplest triggers I have.

%1 tells the group, %2 -> #stw %1 tells the group %2
%1 says, %2 -> #stw %1 says, %2
%1 tells you, %2 -> #stw %1 tells you %2

there's a couple more, but they're really simple.

Posted: Sat Dec 06, 2008 2:58 am

I really don't think the status window is the correct way to go about this sort of thing, because you're going to end up with an immense number of status items cluttering up your settings. Better would be to create a new window (a normal window, not a status window), put it where you want, and then use #win Name {Message} to print stuff to that window.

Apprentice Joined: 29 Dec 2000 Posts: 146 Location: USA

hahahahah --- That's the way I started out with it, by creating a new window.
That's what I do in Zmud.
That REALLY freaks cmud out, It will crash constantly, and that's where the packages start getting assigned to sessions multiple times. and I end up having to delete everything to clear it out.
I use the same name (#win talk) in all the sessions, but wien you open the settings file, there will be 8-10 TALK windows listed.

it's really quite a mess... and why I still have to use zmud.

Posted: Sat Dec 06, 2008 3:35 am

Have you tried it again since you used 1.34? Like I said, 1.34 had some bugs that really screwed up this sort of thing.

Apprentice Joined: 29 Dec 2000 Posts: 146 Location: USA

Changed the triggers, and Played with it a little bit today...

First off, when I open CMUD now, somehow the untitled session opens up in the status window as a tab, and the main window (with the aliases, variables, and triggers buttons in it) is gray, and blank. I have to close the status window to force the untitled session to open in the main window. no clue how this happened, or what caused it, or how to fix it.

I've already got one corrupt session. any time I open it, It will just flash. I have to kill cmud. At least that wasn't happening when I was using the status window.

I think the problem is the window you open seems to attach itself to one of the sessions. the window really needs to be independent of the sessions.
As I open several different characters, the list of "TALK" windows grows. and I start getting 'looping' triggers, because so many talk windows show up in the package editor screen. Deleting the TALK sessions/windows (whatever they are) items from the package editor window fixes this problem, but I have to do it fairly often.

Any thoughts

Posted: Sat Dec 06, 2008 10:14 pm

You can get the setup you're after by putting your single "Talk" window in a separate package and then adding this package to each of the sessions. As long as the "Shared" box is checked for the package, only one window should be opened.

Apprentice Joined: 29 Dec 2000 Posts: 146 Location: USA

I can't seem to get a window go go into a package. I also don't see a "shared" box, only global, local, and external.

Posted: Sat Dec 06, 2008 11:00 pm

You're confused about what's meant by package and window in this case. There's a button on the toolbar labelled "Package Properties" - click it to see the checkbox I'm talking about. If you do File->New Package in the Package Editor, a new tab will appear - stuff in this new tab will be kept in a separate file, named whatever name you gave it. Create your window in this tab.

In the other characters' sessions, do File->Open and find the file you created, and it'll be added to each session.

Apprentice Joined: 29 Dec 2000 Posts: 146 Location: USA

I'm fighting like crazy...

I have the 2 sessions opened, and my 1 comm package is assigned to each (and my talk window is open, but not associated with anything).

For some reason, cmud decides that if that package is assigned to each of the character sessions, the 2 character sessions must be connected too.

so triggers from each session start working on each character session , start looping, and causing lots of fun.

Why is this so dang complicated ?

the idea behind it is great, setup packages for types of actions.. then you can assign those packages to the characters that need them. that way, if a trigger needs to be updated, you don't have to change the same trigger on 10 character files. It's a great thought, but the implementation seems to be screwy. when you have 2 character sessions open, sessions seem to start inheriting packages from the other session. I've said this before, using cmud with 1 character session works great, I've never crashed it, and it's smooth. open that 2nd character session, and it's toast.

I bounce back to cmud every few months, or every time I see a new version has come out, to see if the problems I keep having have been resolved. I keep hitting the forums, to see if I'm doing something wrong, and it sure don't look like it.

Apprentice Joined: 29 Dec 2000 Posts: 146 Location: USA

Unless someone can point out my fundamental flaw in the way I'm using Cmud, and straighten me out, I'm back to zmud til the next version comes out, and I test again til I get frustrated

Posted: Sun Dec 07, 2008 1:53 am

Ok... sounds like we're not understanding you at all, you're not understanding us or you have some lingering corruption. PM and email me your packages and I'll try sort it all out for you.