Zugg Software :: View topic

Novice Joined: 28 Jan 2010 Posts: 34

I have a Trigger that fires on the death of a MOB that I am fighting.

#SHOW Firing SAC_Save1
$temp_rtXP = @rtXP
sac
#WAITFOR {Saving items.}
#MATH kills (@kills+1)
#MATH xp_run (@rtXP-@xp_start)
#VAR xp_mob @target
#VAR xp_expected %100
#SHOW Completed SAC_Save1

Intermittently, during the execution of the trigger, it will create a new variable xp_mob, or xp_expected, or kills in the root of the active WINDOW. These variables are already predefined under a global MODULE.

PACKAGE looks like this:

Global (publish global, all default packages enabled)
-Aliases (class folder)
-Buttons (class folder)
-Status (class folder)
-Triggers (class folder)
--SAC_Save1 (trigger)
--SAC_Save2 (trigger)
--(etc.)
-Variables (class folder)
--kills (true variable)
--xp_run (true variable)
--xp_expected (true variable)
--(etc.)
MUD (visible window, command line, status bar, uses default connection, and all default packages enabled)
-system (generic class created by cmud)
-kills (bad variable creation)
-xp_run (bad variable creation)

This does NOT happen on every kill, even thought he trigger does FIRE on every kill. It will happen once roughly every 10th-15th kill. When looking back into the package with the editor, there is this rogue variable that has been created under the MUD window.

Has anyone seen this before, or be able to give me a lead to troubleshoot further?

-Celerra

Posted: Tue Oct 19, 2010 10:09 pm

Try adding a command after the #WAITFOR like:

#CLASS //Global/Variables

to ensure that the current class is set properly. If you have other scripts running while the #WAITFOR is waiting, the current class might be getting changed to another window. So this would set the class properly before the variables are created.

Or, you could refer to the variables directly using syntax like:

#VAR //Global/Variables/xp_mob @target

Novice Joined: 28 Jan 2010 Posts: 34

Zugg,

Thanks for the suggestions. There is another trigger that does happen while SAC_Save1 is waiting on the "Saving Items." response (a read of the prompt, separating out HP, Mana, AC, etc.). But, that trigger, and the variables it stores to, are also under the TRIGGERS class, GLOBAL module, and the VARIABLES class, GLOBAL module.

<trigger name="prompt2" priority="1500" id="150">
<pattern><![CDATA[<%1hp %2ma %3mv><%4ac><%5xp><%6gp><%7><%8>]]></pattern>
<value>;#show firing prompt2 script
#VAR rtHP %1
#VAR rtMA %2
#VAR rtMV %3
#VAR rtAC %4
#VAR rtXP %5
#VAR rtGP %6
#VAR Align %7
#VAR rtime %8
;#show done prompt2 script</value>
</trigger>

There are no triggers or variables under the MUD window. All settings have been built under the GLOBAL module.

I have changed the referenced variables, for this trigger only, to be module/class specific. Am testing now.

2 questions:
- should I change ALL variables to be module/class specific?
- should I move all my settings under the MUD window and do away with the extra module (GLOBAL)?

With much appreciation,
Celerra

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

1)explicit module/class pathing will prevent CMud from using its own logic to look for variables. Thus, any wrongly-created variables would come from your own scripts (at least insofar as no new bugs were introduced to change this rule). It's just so fugly to look at, particularly if you have a rather deep class-tree to work with.

2)do you have other windows that look for/use those settings? If so, moving them to the mud window will cause those other windows to not work (triggers, aliases, buttons, and so on) or not get the correct values (ie, variables). Anything inside a window does not exist for the purposes of anything outside that window.

Novice Joined: 28 Jan 2010 Posts: 34

Matt,

I have 2 packages open, 1 for the character logged on, and 1 for the mud in general (thus the GLOBAL module) that contains the active window. Thus, as I understand you to say... Anything built under a WINDOW is isolated completely to that WINDOW and cannot be referenced by any MODULE or WINDOW request outside of where it is defined, and certainly not by another PACKAGE.

If I am correct in repeating your description of case 2, then I am thinking I have built the GLOBAL module correctly, since I want to reference triggers and variables back and forth between the Character Package and the generic Mud Package.

As such, I think I have to fall back to option 1, using explicit pathing for this troublesome trigger. It is odd that this happens for just this one trigger, and very intermittently (when killing the same target over and over again). Cannot reproduce it on demand, but it WILL happen by about the 10th to 12th kill.

After inserting the #CLASS //GLOBAL/Variables statement after the WAITFOR and prior to making my variable storage, there have been no repeat issues. I have not tried the explicit variable names yet, but will try that also (agree that it just looks ugly for scripting).

Thank you very much for your feedback.

Celerra

Novice Joined: 28 Jan 2010 Posts: 34

MATT,

Revisiting this topic, and using the Compatibility report for the first time, I used the explicit variables in the following trigger, but got a Report issue.

Trigger:

<trigger name="SAC_Save1a" priority="500" id="260">
<pattern>Total exp for kill is %100.</pattern>
<value>; SAC (including GAC)
; Group Status = Solo, ingame grouped
;
;#SA Firing SAC_Save1
$temp_rtXP = @rtXP
sac
#WAITFOR {Saving items.}
#MATH //Global/Variables/kills_run (@kills_run+1)
#MATH //Global/Variables/kills_session (@kills_session_stored+@kills_run)
#MATH //Global/Variables/xp_run (@rtXP-@xp_run_start)
#MATH //Global/Variables/xp_session (@xp_session_stored+@xp_run)
#MATH //Global/Variables/xp_actual (@rtXP-$temp_rtXP)
#MATH //Global/Variables/xp_diff (@xp_actual-%100)
#VAR //Global/Variables/xp_expected %100
#VAR //Global/Variables/xp_mob @target
;#SA Completed SAC_Save1
;#SEND</value>
</trigger>

Compatibility Report:

Trigger SAC_Save1a
/ has been changed to ./ for the current class reference [Help] : #VAR //Global/Variables/xp_expected

I'm unsure where I have gone wrong on this reference. Any assistance is greatly appreciated.

Posted: Mon Jul 18, 2011 6:05 pm

Your syntax looks fine. I think this is a false positive from the Compatibility Report which just uses regular expressions so search for possible syntax change issues in your code.