Zugg Software :: View topic - How to prevent duplicate variable creation?

Beginner Joined: 07 May 2017 Posts: 10

I have a simple that's just supposed to block until cmud reads a prompt from the mud. It's defined as a simple alias/trigger pair, like so:

Posted: Mon Jul 25, 2022 7:51 pm

My guess is that the class/folder you house the variable in is getting disabled somewhere.

This forces the next definition to resolve at the root because there is no active variable with the name.

The easy fix would be to keep the variable at root and delete the other copy. Or at the minimum, make sure it's in a class/folder that never gets disabled.

Beginner Joined: 07 May 2017 Posts: 10

I don't think that's it. The class it's in is called Data, and it contains a bunch of core functionality for my scripts like hit point tracking, room contents parsing, and so on. If it were disabled a dozen different things would immediately break, not just this. Also, the string "#T-" only appears in one spot in the whole package, with a constant argument.

Also, I just tested it and when you given #var an explicit class argument, it will set the variable in the specified class, creating a new variable if necessary, even if that class is disabled, so long as it can't resolve any other variables with that name.

Is it possible that cmud's internal stack can become corrupted under some rare circumstances? And if so, do we know what triggers it, so that I can stop doing it? I've had other problems that seem to suggest that: my long-running scripts occasionally fail with implausible errors like "argument still on stack" and "operator requires two operands".

Posted: Mon Jul 25, 2022 11:47 pm

It is possible, though I am unaware of the circumstances for such off the top of my head.

I know editing multiple rooms on the map simultaneously can mess up the creation of the next room, but that's not really applicable here.

Apprentice Joined: 09 Apr 2008 Posts: 168

out of curiousity, how long do you leave cmud running at any given time? Do you save and close the program periodically? I have noticed that dupe vars and mis-firing scripts will occur with variably increased frequency the longer it's left running.

To the point that I'll get an exception error pop-up and may suffer a roll back if I made any substantial changes and neglected to save/restart (at least once a day)

Posted: Tue Jul 26, 2022 5:20 am

Typically I have it up for running till I finally give in to the windows update requests.
A week or three at a time.
It was a bit more frequent when creating and coding new scripts (several times a day even), but once you get things working, it is very stable.

Beginner Joined: 07 May 2017 Posts: 10

I do feel like things get worse when cmud has been up for a long time, or when Windows has; I try not to let cmud run for more than 2 or 3 hours at a time. But this isn't always good enough, sometimes it misbehaves immediately on startup.

I thought I had a workaround: just use #unvar to unset the variable before I set it, and change the reading code to tolerate reading "" values from time to time. But this doesn't work: cmud becomes unstable after just a few minutes of variable setting and unsetting, and AFAICT it isn't possible to unset a var if and only if it's defined at the root; `#unvar @var` will unset what variables it can find, and adding an explicit class argument of "" doesn't change that.

Posted: Tue Jul 26, 2022 10:14 am

That also depends on your system.
Have you looked into using a dbVar?
With that, you could house all of your utility variables in one master variable...at root.

Wanderer Joined: 05 Sep 2008 Posts: 51

Conradin would you be willing to share the variable update/creation script you have made? I am personally in the process of trying to learn how to build that and it might also be helpful to trace back the potential cause.

thank you much

Beginner Joined: 07 May 2017 Posts: 10

@shalimar Thanks for your replies. I'm not sure what you mean; what depends on my system? I'm on windows 10, cmud 3.34. As for dbvars, I do use them in several places, for example to keep track of buffs and inventory item counts, but I find that they sometimes get corrupted when I write to them (adding blank entries that map "" to "", or deleting keys). For things like buff tracking I can work around that, because I can always regenerate the buff data from scratch by querying the MUD, but for storing internal variables it seems pretty dangerous.

@miegorengmen Here's the XML for the variable-setting function I wrote; is that what you meant?

Posted: Wed Jul 27, 2022 6:35 pm

More that the amount of RAM your system has can drastically affect the performance of laggy scripts.

Do you have a permanent prompt trigger?
Seems like you could do away with that unfortunate-looking #WHILE waiting for a prompt to finish the cleanup by having a dedicated trigger to do it for you.

#TR {^>} {#IF (@awaiting_prompt) {awaiting_prompt=0}} {} {prompt}

Beginner Joined: 07 May 2017 Posts: 10

I have a trigger like that, see the first post, but I still need a blocking loop in the alias. The usecase is, the MUD doesn't allow a lot of command stacking: if I send four commands in a row, `a;b;c;d`, the last two commands will be ignored. So my strategy is to wait for the MUD to send back a prompt, like so:

Posted: Thu Jul 28, 2022 11:37 am

I think it would only be using more in those high-stress situations.
Or maybe it uses more CPU processing instead.

As for the command stacking issue, you could always set a command queue for those commands that get set to the MUD.

commandList=a|b|c|d

Then have the prompt trigger do this:

#IF (@commandList) {#EXEC %pop(commandList)}

Beginner Joined: 07 May 2017 Posts: 10

I have experimented with that kind of design in the past, but couldn't make it reliable: list variables seem to have a chance to become corrupt every time you write to them, much like DB variables do, and guarding them with a #SECTION does not help.

It's also pretty tricky to compose this kind of asynchronous design with other kinds of blocking. For example, `check-inv` is an alias that queries the MUD for my inventory and then blocks with #waitfor until it gets a line indicating that we've seen my whole inventory, while some triggers populate @inventory with items and counts. Combined with `go2` (which executes a speedwalk to a named room) and `sell-loot` (which looks at my @inventory variable to find things to sell), I can write a script to sell all my excess loot like this:

Posted: Fri Jul 29, 2022 3:52 am

This outlier situation probably has more to do with whatever caused the corruption in the first place.
Variable definitions are usually very reliable.

#SECTION and threading, in general, is one of the most elaborate and advanced concepts in CMUD, and most users have no real need for anything that complex.
The main thread is capable of handling most scripts you throw at it.
The only time I bother with it is for a laggy function like %mapquerry

P.S. %push adds things to the front of the list, which would make command order be LIFO instead of FIFO, %additem would append to the end of the list.

Beginner Joined: 07 May 2017 Posts: 10

So you think there's something different about my cmud install, compared to a normal one? That would be really good news, because I could fix it, and then I wouldn't need a workaround for the behavior in the OP, I could just rely on #VAR to behave as documented. Do you have ideas of what the cause might be, or what sorts of things I should search for? I already know a few basic things, like not calling user functions without #CALL, and not using signals and events. EDIT: and not enabling/disabling classes in scripts.

Posted: Fri Jul 29, 2022 10:52 pm

Who told you that those things were bad?

There is nothing wrong with #EVENTs.
#SIGNAL is another threading command.

Enabling and disabling is also fine, so long as you aren't turning off variables you will continue defining.
As is using functions outside of a #CALL. #CALL is more a means of isolation.

None of the settings are bad, though some are more prone to unexpected results than others.

Unfortunately, the exact cause of corruption is rarely known for certain.
Though it usually stems from typos or bad syntax.
Without looking over every script you have, there is no way to know the root of your issue.
The script debugger window can help to see what is firing at any given moment.

Sometimes the only answer is to recreate from scratch.
I have had to do that a number of times, and each time my code comes out cleaner than before.

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA

Beginner Joined: 07 May 2017 Posts: 10

Beginner Joined: 07 May 2017 Posts: 10

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA

Posted: Mon Aug 01, 2022 6:55 am

Beginner Joined: 07 May 2017 Posts: 10

Posted: Tue Aug 02, 2022 12:39 pm

I tend to break stuff down and segment it to protect from corruption.
Compartmentalization.
It effectively serves as a backup of known good code as well

Any corruption that matters will only be in my main session file.

Besides, not everyone will want every bit of functionality I decide to use.
Nor do i necessarily want to share every line of code I use.

I would be rather surprised if this all comes down to a trigger pattern.
From what you said the issue seems to stem from one of the aliases you tried to convert into an event. As that was when things became unplayable.