Zugg Software :: View topic

Posted: Sat Jul 05, 2008 6:55 am

Here's what it looks like in Cmud:

Posted: Mon Jul 07, 2008 7:37 pm

Confirmed. Thanks for the command line code. I swear, this is the last time that I'm going to kludge CMUD to handle MUDs that don't adhere to the proper telnet protocol standard. All of these ATCP packet boundary bugs are being caused by these fixes that allow MUDs to be sloppy with their IAC codes. From now on I'm taking the Firefox approach...force the MUD to adhere to the proper standard if they want CMUD to work with it.

Posted: Fri Jul 18, 2008 2:39 pm

Just was trying out the new version and got something unexpected:

7707h, 8254m, 37263e, 31424w cxdb-|-662h(-8%):0m(0%)|
[NPC]: A pale-skinned, humanoid vampire (prone|blackout)
-|-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)|
|-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)|
|-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)|
|-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)|
|-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)|
|-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)|
|-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)||-405h(-5%):0m(0%)|
You have recovered equilibrium.
ÈChar.Vitals
H:7435/8418 M:8526/8526 E:37265/37265 W:31448/34235 NL:7/100 -

During this output it popped up a window saying it detected a loop and gave an option to disable the triggers responsible. One of them it disabled was the ATCP trigger.

Was there something in the fix that would cause it to loop the ATCP execution?

Posted: Fri Jul 18, 2008 2:45 pm

The triggers that it disabled because of the infinite loop where the prompt and this trigger:

<trigger type="Telnet" param="200" priority="4" case="true" stop="true" regex="true" id="3297">
<pattern>^Char\.Vitals\12(H:(\d+)/(\d+) M:(\d+)/(\d+) E:(\d+)/(\d+) W:(\d+)/(\d+)) NL:\d+/100</pattern>
<value>#if (%1 <> @old_stats) {
#var old_stats %1
#var health %2
#var max_health %3
#var mana %4
#var max_mana %5
#var endurance %6
#var max_endurance %7
#var willpower %8
#var max_willpower %9
#RAISEEVENT Vitals
}</value>
</trigger>

The #raiseevent Vitals in the ATCP trigger enables the i_scan_damage code which is raised when it sees a prompt and is what was causing it to repeat infinitely (my health change) above.

I've never seen this happen on any other version, so I suppose this has something to do with 2.32. I've now run into this several times and reverted back to 2.30 until this is either changed back to how it was before or is fixed.

Posted: Fri Jul 18, 2008 6:08 pm

You'll need to paste the results of the Script Debugger so I can see exactly what the MUD is sending. My guess is that your Vitals event is sending something to the MUD which is causing the MUD to send another ATCP message. Or, maybe you have an expression trigger that is firing when you set one of the variables. But without the debugger output, we have no way to tell what is happening here.

Posted: Sat Jul 19, 2008 2:36 pm

The only place the repeating code is executed is an event call that happens in the prompt. Which means that the prompt is somehow executing multiple times out of control. The ATCP trigger just enables the event that is called in the prompt, it doesn't actually run it.

Given that this only started being an issue in 2.32, could you give me some idea of how you fixed the issue so I can have some idea of what I'm trying to debug?

Posted: Sun Jul 20, 2008 12:04 am

Okay, here's the debug information on the 2.32 fix. I'm pretty sure this error was caused by one of your fixes Zugg. My code works flawlessly on version 2.30 and it gets into a loop consistently in version 2.32.

Debugger Window:
As you can see it is a classic trigger matching on text the trigger outputs itself.

Posted: Mon Jul 21, 2008 5:29 pm

Turn off the Trigger on Trigger option for the prompt_blackout trigger to prevent it from firing again. The bug fix was that CMUD wasn't executing events properly within triggers before, and now it is. So your Prompt event is doing some sort of #SUB command to modify the prompt, which then causes Prompt triggers to fire on the new result again.

Posted: Mon Jul 21, 2008 6:23 pm

Posted: Mon Jul 21, 2008 6:55 pm

Posted: Mon Jul 21, 2008 7:03 pm

Yes, #SAYP will cause Prompt triggers to be executed again (just like #ECHOP or #SHOWP).

Posted: Mon Jul 21, 2008 7:36 pm

Okay, I think I understand now. I suppose there was a reason to make it re-evaluate the triggers each time it was modified, but I can see causing issues for a lot of people who use #SAYP statements in their prompts.

Edit: I'm also surprised my normal prompt isn't seeing this issue as well. It should from everything I understand about this. Well at least the solution is a quick check box for two of my triggers so this should be easy now that I understand what was causing it.

Edit2: I just realized I already had my main trigger stop matching to save compute time, so that's the reason why my main prompt seemed exempt while the blackout prompt was affected. It all makes sense now.

Posted: Tue Jul 22, 2008 2:52 am

Works great in 2.33.

Thanks!

Posted: Tue Jul 22, 2008 3:51 am

Great! Thanks for letting me know that it's finally fixed.