Zugg Software :: View topic - [1.33] *Now Reproducible* Variables becoming inaccessible

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

I can't reliably reproduce this yet but it seemed serious enough to post anyway. Sometimes when playing then certain variables seem to become inaccessible to CMUD. Deleting and remaking the variable sorts out the problem but just editing and resaving it doesn't. You can see what the value is when you're in the settings editor, but you can't display it in a #say, button, or use it in an #if etc.
Note the 'You can hold -32 terls' bit in the button on the right - that should actually be (@mterls-@cterls)/3, but since mterls can't be found it's displaying wrong

See pic. All the variables exist only once, they're all inside the same class and they all have values. I'm pretty sure I've not done anything stupid :)

Adept Joined: 18 Dec 2005 Posts: 246

Sorry, but my post isn't about the variable problem you indicate :) I just see your status window on the right and I'm wondering how you set that up in general, is it through the normal status windo, if so, how did you get it borderless? how did you change the background? Sorry, to keep this thread on track could you either email me at gumbudah_AT_charter.net or start a new thread? please please please.

Jed

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

They're just buttons on the right panel. I did away with the status window in zMUD as buttons seemed to be more usable, and just stuck with them since. The spacing is just a long caption with newlines using %cr.

Posted: Tue May 15, 2007 9:19 pm

He's not using borderless status windows. Rather he seems to be user large buttons with captions with a lot of information.

Correct me if I'm wrong Guinn, but I think you posted about long captions a while back.

As for the problem your having Guinn, I've not seen anything like that. I guess the first thing I'd ask is are you sure you don't have @thirst defined anywhere else? Trying doing a #VAR with no parameters to see all the variables and what CMUD thinks their values are.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Yep, definitely only defined in one place. The problem goes away when I restart CMUD, them might come back a day later. I've got a fairly settled .pkg file now so haven't made any changes to things like the hunger, thirst, health variables etc.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

It happened again for no reason but noticed it was the same couple of variables that went, so I opened the pkg file in SQLite and looked at the difference between working and non working variables in the settings table.
cterls and hunger work, mterls and thirst don't.

cterls: kind=3, subkind=0, opt=1, options="<opt><DefVal>0</DefVal></opt>"
mterls: kind=3, subkind=0, opt=0, options="<opt><DefVal>200</DefVal><ArgList></ArgList></opt>"

hunger: kind=3, subkind=2, opt=1, options="<opt><DefVal>not hungry</DefVal></opt>"
thirst: kind=3, subkind=3, opt=1, options="<opt><DefVal>not thirsty</DefVal><ArgList></ArgList></opt>"

Apart from that the only differences were the id.

Posted: Fri May 18, 2007 4:58 pm

Probably isn't a problem in the SQL database, since you said that restarting CMUD fixes it (which causes CMUD to reload the database from scratch). It sounds more like something in the memory cache is getting messed up. It's going to be really hard to debug this, but when it happens again, start by using the #VAR command to list all of the currently accessible variables, and the #CLASS command to display your classes. These commands only display the contents of the memory cache, so they might show something wierd.

The package editor only edits the database itself, so again, if it's a problem with the cache, it might not show up in the package editor. But the #VAR command loops through the internal cache and displays every variable that is accessible, so that would be the first thing to try.

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

Could it be something related to the two non working variables having <ArgList></ArgList> in them? The two that do work don't have them

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Sorry for the slow reply. Last time it happened I typed #VAR and the variables in question didn't show up in the list. This was while I could see them in the package editor.
I've not mudded in the last week or so (exams... fun) but I'll see if I can spot a way to reproduce it. I've since manually altered the variables to make the broken ones the same as the working ones btw (from inside SQLite, not inside CMUD).

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Got it! Remember 'mterls' is one of the dodgy variables, default is 200.

I open CMUD, load my session.
#SAY @mterls
returns 200

I then click the Session dropdown and open the same session again. When that's loaded, #SAY @mterls in both sessions - both return 200

Then close the second session (right-click the tab, select close)

Then in the first session, #SAY @mterls
returns nothing

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

I can send you the pkg file of course, since I can now reproduce the problem

Posted: Wed Jun 13, 2007 4:23 pm

OK, thanks for reproducing this for me. I didn't realize you were loading multiple copies of the same session and then closing one of them. When you load more than one copy of the same session, you now have two sessions that are trying to write to the same database file. But each session is also going to have it's own internal cache. So things might get confusing in that case,

But it sounds like the bug is that closing a session is somehow effecting the internal cache of the other session somehow. So I've added this to the bug list.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

It didn't register that it was the multiple sessions doing it until yesterday when I logged on quickly with a couple of characters to catch up on messages, and noticed things had gone weird just as I was about to leave. It'd always just seemed random before, heh.