Zugg Software :: View topic

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

I've had some big problems that was caused by referencing variables from the status bar. We pinpointed the problem in this thread: 32676 (no idea how to link).

It seems however that this thread died - at least no one bothered to react to my last requests - so now I have created a new topic with a more suitable subject in hope I get a little more response.

It seems there is a problem when you reference variables from the statusbar and you have more threads reading and manipulating those. In my other settings like triggers and aliases I enclose access to those variables in sections but what will I do to have the same mechanism when accessing the same variables from the status bar? I've tried using functions to encapsulate but that doesn't seem convincing - at least the values on the bar is not changed immediately as the value of the variable does...

Anyone knows the problem and perhaps a solution?

Posted: Tue Feb 17, 2009 6:57 pm

I went ahead and created a link for you.

First remember that the status bar was intended for simpler text and variable displays (and as a carry over from zMUD) was not really designed to work in a multi-threaded environment.

If you have multi-threaded accesses to these variables you may need to consider how your using them (or if the status bar is the best place for them). Another thing I think may work better for you and give your system more modularity and flexibility is to not update the variable directly but to use an #EVENT and have that be the only thing updates the variable.

For example, assume the you are monitoring you HP variable, you can have an event called onHPUpdate you could wrap it #SECTION and be done. Alternatively you can pass parameters to the event, so if you variable were to depend on multiple pieces of data you could do all your processing for the variable in one place.

Also not sure if you said so before or not, if you really need fast access to the variable you may consider marking it as default so CMUD never tries to persist it.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Perhaps it was not made for a multi-threaded environment in the beginning but that doesn't make it less useful now. I certainly hope I can continue using it though as it's very useful for showing things like current weapon, tool, current armor, etc. Right now most of these things are disabled as I prefer this to getting a lot of exceptions causing CMUD to crash and it's a pain not having this information.

I'll try the #EVENT suggestion and see if that works for me, thanks.

I never heard of default variables before. Could you explain?

Posted: Sat Feb 21, 2009 8:12 pm

They are regular variables that you mark as default. They key differences are, at the start of the session CMUD sets it to whatever the default value is. More importantly, is that CMUD doesn't try to save this to the .pkg (i.e. it's storage database). This makes accessing them faster and removes the overhead of variable storage. It may help.

I wasn't suggesting that the status bar wasn't useful (although I'm partial to gauges, buttons and the status window myself) but rather when you have and old technology (i.e. the status bar code which is relatively unchanged for compatibility) dancing with new technology (CMUD multi-threaded goodness); they'll move across the floor but sometimes toes get stepped on.

Don't fret though.. Zugg's a perfectionist and one day he'll probably fix the bug or redesign the whole thing for double the goodness.