Zugg Software :: View topic

Apprentice Joined: 03 Jul 2006 Posts: 110

I am still having problems with my script. The first issue is that, yes, #ADDITEM is DEFINITELY adding duplicate variables. The second problem is that I have a comparison which for some reason WILL NOT correctly check to see if the element is present, and while I'm sure there is some simple format issue here, I can't find it.
The first two #IF statements work correctly, in that the first correctly evaluates %ismember() and only announces a new area if that title is not present in the @Areas variable, and neither now create duplicate entries into their respective stringlist variables.

The THIRD #IF statement, on the other hand, refuses to acknowledge that the stringlist already has not one, not two, or even three, but umpteen dozen copies of the environment entry in it, and stubbornly keeps adding new ones, even though the #ADDITEM in theory will not do this. I have modified the statement with some #SAY commands to show what it sees as the values of both the value being entered and the stringlist before and after the #IF statement and #ADDITEM, which shows it adding multiple entries. I even uninstalled and reinstalled the program in case something became corrupted, though the package files with the triggers are the original.

I start out with all values blank - no previously captured variables), and run 3 look commands in the same room to execute the trigger. I have deleted the results of the look for space, but below I have the output of the trigger itself, and a single copy of the Room.info message which comes in each time.

Posted: Thu Mar 09, 2023 7:29 pm

Might simply be a corruption issue.

Export your settings to XML from the package editor.
Close the session/CMUD
Move/rename/delete the .pkg file
A blank .pkg file will be created when you reopen the session.
Import from XML in the package editor.

Apprentice Joined: 03 Jul 2006 Posts: 110

Issue persists across an export/import cycle. It also seems to be contagious, because I installed CMUD on another computer and typed in a new script which does the same thing. Interestingly, it also fails on checking that same entry from room.info.details, seeing every single "outdoors" as a unique value that is added again (perhaps there is something "malformed" about that variable coming from the MUD, though I can't see it in the debugger?). Of interest, when I simply type it into the command line, #ADDITEM does NOT add a duplicate (on either computer), so it appears only to appear when I write it in a script. It doesn't appear that I am typing it wrong, because it behaves differently between command line and script when I cut/paste the command between the two.

To be honest, I'm having flashbacks to my Fortran programming class in College - having some type of formatting error on a line would show up as a compiler error on another totally unrelated line, which might be before or after that line in the actual program.

Also, I know that it is a bit late to make a complaint about the way the commands are formatted, but WHY are the order of parameters reversed between %additem and #additem (and it seems inconsistent between various functions)? Did someone realize that I would eventually come along and decide ahead of time to just torture me? I think I'm going to have to type out a cheat sheet of all the functions and commands (though I'm currently using a total of approximately 3) so I don't have to pull up the support page every time.

Thanks for the help.

Mike

Apprentice Joined: 03 Jul 2006 Posts: 110

Just had a thought as to what MIGHT be an issue. The room.info.details packet does indeed come back as "non-standard," at least compared to the rest of the gmcp message. The data packet (I believe) represents that the variable is an array or stringlist. Note the following section of the gmcp packet including the "details" entry plus the next entry "background":

Posted: Sat Mar 11, 2023 1:45 pm

try:

#FORALL $var {then the #IF #ADDITEM off of %i}