 |
ardwick
Novice
Joined: 31 May 2007
Posts: 32
|
 Posted: Thu Dec 06, 2007 4:29 pm
[2.14] Alarms not firing.......sometimes.
|
To start combat I use an alias.
Within that alias I have a few commands:
- Turn off a class with triggers used to start a fight
- turn on my combat alarm
- an alias to calculate fight start time
- set a variable to let me know I'm in a fight
- add keys to a db record to track kills
- and finally, start the fight
The alarm in question tracks hit points to determine if I should heal myself,
determines the status of the mob I'm fighting to figure out which attack
I should use and is set to evaluate these things every 4 seconds.
I set up an ID for the alarm and in the combat start alias I turned the
ID on. At the end of the fight, I turn it of using T+ or T-.
This works most of the time. The entire combat alias fires, but sometimes
the Alarm never got turned back on. Sometimes this would happen
3, 4 times in a row.
I originally named it Combat Alarm and fired it off by using T+ {Combat Alarm}.
So I changed the name to Combat_Alarm and then fired it off using T+ Combat_Alarm.
Still same results. It would mostly fire, but every couple fights, it didn't turn on.
So, I stuck the combat alarm into it's own class and changed my aliases and triggers
to turn the class on/off. This caused the alarm to fire more but still I get that odd
fight where it doesn't turn on. Also, in this set up it seems like the alarm is still
counting in the background, it's just not executing the scripts within the alarm.
Before I'd start the fight and my first attack would come 4 seconds after the fight
started. Now, when the alarm is located in the class, I'll start a fight and sometimes it is immediately
firing off an attack command.
If this is not a bug, but just something that I have to work around, is there a command to check the
state of a trigger to see whether it is disabled or enabled? I was thinking I could either check the
state of the trigger or have a different trigger try to turn the alarm on (but this may reset the
count? which wouldn't be good either)
that |
|
|
|
|
ardwick
Novice
Joined: 31 May 2007
Posts: 32
|
Posted: Thu Dec 06, 2007 4:40 pm
|
Hmm, will try using #sus/#resume and see if that resolves this issue.
Still not sure why sometimes CMUD skips the turning on of the alarm when told to.
Never misses turning it off, just turning it on. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Dec 06, 2007 4:42 pm
|
Is the alarm in the same window as the alias, or is the alarm in a separate module/package?
Perhaps you can show the script for the alarm. If the alarm script is using any sort of #WAIT commands, then the alarm is going to create a parallel background thread, and alarms are currently set up so that you cannot run the same alarm while the previous copy is still running.
The %trigger function will return whether a trigger (or class) is enabled or disabled. |
|
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
Posted: Thu Dec 06, 2007 5:10 pm
|
I can explain at least one part as not a bug.
| Quote: |
Before I'd start the fight and my first attack would come 4 seconds after the fight
started. Now, when the alarm is located in the class, I'll start a fight and sometimes it is immediately
firing off an attack command. |
This has always been the behavior even in zMud. When the class is turned on the settings within become enabled; in the case of alarms this means they start counting down. When the class is turned off the settings within become disabled; in the case of alarms this means they stop counting down. No where in that is the alarm reset to its original time.
If you use a class to control an alarm include #CALL %alarm(id,time) where you turn the class on. I don't think I would want this behavior to change, even though it doesn't match with turning the alarm off and on directly.
Where it doesn't fire while enabled could be a bug, and we definitely need more details to trace that. |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
 |
|
|
ardwick
Novice
Joined: 31 May 2007
Posts: 32
|
Posted: Thu Dec 06, 2007 6:49 pm
|
| Vijilante wrote: |
I can explain at least one part as not a bug.
| Quote: |
Before I'd start the fight and my first attack would come 4 seconds after the fight
started. Now, when the alarm is located in the class, I'll start a fight and sometimes it is immediately
firing off an attack command. |
This has always been the behavior even in zMud. When the class is turned on the settings within become enabled; in the case of alarms this means they start counting down. When the class is turned off the settings within become disabled; in the case of alarms this means they stop counting down. No where in that is the alarm reset to its original time.
If you use a class to control an alarm include #CALL %alarm(id,time) where you turn the class on. I don't think I would want this behavior to change, even though it doesn't match with turning the alarm off and on directly.
Where it doesn't fire while enabled could be a bug, and we definitely need more details to trace that. |
That's what I was thinking. Which is no big deal. It's not like my attacks flood the combat more than the mud's waitstates.
Anyway, I tried testing the resume/suspend functions and that may work, although when I first go into the session in offline mode (and most likely when connected) the alarm is in active mode. I could code something to turn it off during login. I can play around with this more tonight when I can actually connect to a mud.
In the meantime, I uncoded my changes to put them back to something very similar to what I was running before. I'm not sure how much info you need, but I'll go through the original setup and explain the way it is now. Then I'll post the xml of what is currently set up.
Originally, I had the F4 key set up with two #IF statements. I evaluated two different variables (in_combat [YES/NO} and start_combat [warcry/kill]). If in_combat = NO and start_combat=warcry I changed in_combat variable to YES and executed my warcry alias. Then there was another #IF statement for in_combat = NO and start_combat = kill which would execute my kill alias.
These aliases included:
~kill/warcry @current_target initiate combat with either kill or warcry mud command
Combat_timer set start time of fight
#t+ combat_alarm turns on alarm to evaluate fight
#t- {Combat Start Triggers} turns off start triggers when in groups or if mud initiates combat
#if (@log_kills=ON) {#addkey kills_db_rec {kills_name=@current_target|kills_zone=@current_area}} {} sets db rec of kill
I thought maybe something was hanging up and not causing the combat alarm to turn on, so I moved it to the top of the script and
sometimes it still would not turn on. Not often, but often enough. All the other actions were executing properly within the script.
So, I thought maybe the name of the alias and the ~kill might be conflicting so I changed my start combat alias to:
#t+ combat_alarm
Combat_timer
#t- {Combat Start Triggers}
#if (@log_kills=ON) {#addkey kills_db_rec {kills_name=@current_target|kills_zone=@current_area}} {}
%concat(@start_combat" "@current_target)
#variable in_combat {YES}
And I changed the F4 key to just evaluate the in_combat variable. If NO execute single alias or don't. Nice and simple.
The bold line forms the command I send to the mud to start the actual fight.
These changes caused the alarm to fire off more (at least by appearance) but it would still not get turned on sometimes.
So, with all that said, here's the xml of the current way I have it set up. The only real difference is that I used to
have the ID on the alarm as Combat Alarm, not combat_alarm and I would enclose the name with {} on the #T+/- command.
I thought that may have caused an issue as well.
I really don't know if this was happening in 1.34. It may have been happening and I just really didn't notice it. I only
wrote these scripts two-three weeks ago. Before that I was manually executing commands during combat.
XML for the start_combat alias
<alias name="start_combat" id="4663">
<value>#t+ combat_alarm
Combat_timer
#t- {Combat Start Triggers}
#if (@log_kills=ON) {#addkey kills_db_rec {kills_name=@current_target|kills_zone=@current_area}} {}
%concat(@start_combat" "@current_target)
#variable in_combat {YES}</value>
</alias>
XML for the combat_alarm
<trigger name="combat_alarm" type="Alarm" priority="37800" trigontrig="false" newline="false" id="3780">
<pattern>4</pattern>
<value><![CDATA[#variable in_combat {YES}
$hp = %eval(@max_hp-@current_hp)
#if ($hp>900) {get cureall @potion_container;quaff cureall;#math fishermans_curealls @fishermans_curealls-1;#abort 1} {}
#if (@max_mana=@current_mana && @touch_on=ON) {touch} {
#if (@victim_status=crippled && @disem_on=YES) {disem} {@punch_or_kick}}]]></value>
</trigger>
Again, I've never noticed an occurrence when the combat_alarm hasn't turned off at the end of the fight. I see the line
You receive X experience and it has always shut off. It's just when I start that sometimes it doesn't turn on.
PS: Oh, and it's within the same window/package. I'm not going there yet  |
|
|
|
|
ardwick
Novice
Joined: 31 May 2007
Posts: 32
|
Posted: Fri Dec 07, 2007 2:57 pm
|
Loaded up 2.15 yesterday and played pretty much all evening last night. This issue did not
happen once last night. It fired every time I started combat as it is currently coded.
Of course, in previous versions it would happen only once in a while, where when I played
with 2.14 it just seemed to happen alot that evening.
If I notice it again, I'll post about it, but yeah, I didn't see this happen at all last night. |
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
