Zugg Software :: View topic

Wizard Joined: 17 Jun 2006 Posts: 1201

Well apparently the problem was a bad install! Embarassed

Version 2.10 test with #send.

Offline with all classes enabled.

68 ms

Offline with all classes disabled.

35 ms

Offline with all classes enabled and disabled and triggers disabled via clicking the little gun.

20 ms for both

-------------------------

Online with all classes disabled.

36 ms

Online with all classes disabled and with triggers disabled via gun.

23 ms

Online with all classes enabled and triggers disabled via gun.

22 ms

Online with all classes enabled and without triggers disabled via gun.

70 ms

Online with all classes enabled and with triggers disabled via gun and without using #send

16 ms

Online with all classes enabled and triggers enabled via gun and without using #send

70 ms

However, I still cannot enter anything on the command line while receiving a bunch of lines from the MUD. For instance when I run the test alias the MUD sends back:

You see no ash in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
Pericles strides out to the south.
3580h, 3938m, 15570e, 16800w exkdb-
You see no bayberry in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no bellwort in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no bloodroot in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no cohosh in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no ginseng in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no goldenseal in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no hawthorn in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no kelp in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no kola in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no lobelia in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no echinacea in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no moss in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no pear in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no sileris in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no skullcap in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no elm in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no valerian in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-
You see no myrrh in your inventory.
3580h, 3938m, 15570e, 16800w exkdb-

While that is happening I cannot do anything. I can't even type on the command line until it finishes.

I did #thread and it showed:

Threads:
# ID Window Name Status Script
-------------------------------------------------------------------------------------------------
1 [u] Achaea running #thread

The first time I couldn't do thread until the lines stopped coming. Then I cut and pasted #thread real fast while receiving the text and got the following:

3580h, 3938m, 16800e, 16800w cexkdb-Threads:
# ID Window Name Status Script
-------------------------------------------------------------------------------------------------
29 [u] Achaea running #thread

A few seconds later after the running the alias I continue to get the same when I enter #Thread

Threads:
# ID Window Name Status Script
-------------------------------------------------------------------------------------------------
29 [u] Achaea running #thread

It stayed at #ID 29 after that.

Sooo yeah looks like the first problem was a bad install. The lines coming at a slow pace seems to be my OnPrompt event firing other aliases on each prompt. I guess I will have to redo everything just to fit 2.10 because it works fine in 1.34, but in 2.10 I can't even enter an alias/command in the command line while text is coming real fast.

However, even though I feel like an idiot and should have reinstalled first, there is still a big difference in speed. It's twice as slow in 2.10 as it is in 1.34, even with using #send.

Posted: Sun Nov 04, 2007 9:36 am

At the risk of sounding petulant: I told you so ;P

Also, you can probably improve your prompt-lag by moving those aliases that OnPrompt is calling into their own OnPrompt event. That is, move the actual code of the alias into the OnPrompt event. You can use the priority numbers to control the order in which they execute, if that's important. But then you can avoid the overhead of checking tons of aliases which then probably do #if (@parrying) and #if (@autosip) and stuff by disabling and enabling the event when you'd normally change the variable in question.

Wizard Joined: 17 Jun 2006 Posts: 1201

Apprentice Joined: 26 Apr 2007 Posts: 113

Wizard Joined: 17 Jun 2006 Posts: 1201

Yeah even after disabling my OnPrompt event it does the same thing. At least I am not the only one having this problem.

Also if you send a bunch of commands in rapid succession it will append one of the received lines to the end of a prompt at random times.

Apprentice Joined: 26 Apr 2007 Posts: 113

I just tested with #SAY and #SHOW while still connected to Aetolia and had no issues whatsoever, it seems to be when the text is coming directly from the MUD that this problem occurs.

#REPEAT 80 {#SHOW H:3135 M:3117 E:15400 W:17351 B:100% ~[csdb eb~]}

Showed no significant slowdown. (CPU usage jumped from 30%-ish to 80% at its peak.)

NOTE: The #SHOW is exactly the same as the text I'd expect to receive from the MUD if I just did #80 " " which shows the same slowdown as reported.

Apprentice Joined: 26 Apr 2007 Posts: 113

Posted: Mon Nov 05, 2007 6:24 pm

As mentioned in some other threads, CMUD 2.10 "blocks" while it is executing scripts. This means that all windows messages, such as keyboard and mouse input, are blocked while executing a script. This is done to prevent you from entering a command on the command line and pressing Enter to run it in the middle of other script that is running (which could then cause the script that is running to fail, or cause commands sent to the MUD in the wrong order).

zMUD did not block during script execution. This led to a number of problems where sometimes commands could be sent in the wrong order, and caused problems with commands like #WAIT. The same was true in CMUD versions 1.x.

Windows *should* still maintain your keystrokes in the typeahead buffer. So when a script is finished, anything that you have typed should appear in the command line just as normal.

What this means is that you need to pay more attention to your scripts to make sure they are fast, or use a command like #WAIT to put your script processing into the background.

One thing that can significantly improve the speed of your onPrompt triggers is to make sure you mark all of the variables that are set by the prompt (such as @hp, @mana, etc) as "Use Default" in the package editor. This prevents changes to these variables from being saved to the database each time they are changed (because "Use default" tells CMUD to reset the values to the default when the package is loaded, so any saved value would be lost anyway).

Or, as I mentioned, you can put #WAIT at the beginning of your script, or at whatever point you want to move the script into the background. Using #WAIT without any arguments is like pressing Shift-ESC on the command line...it continues executing your script in the background, which unblocks the command line and the rest of CMUD.

Just keep in mind that if you run scripts in the background, you don't know which one will finish first, so it might get complicated trying to synchronize your scripts. Also, if multiple scripts running in the background try to access the same resources (like variables), then you can get additional problems.

Finally, you can also use the #SENDRAW command to send your commands to the MUD without the echo of the command to the screen. This is a very fast way to send commands to the MUD since you don't need to wait for the screen update.

Wizard Joined: 14 Aug 2004 Posts: 1269

So #SEND has to synchronize with the main thread and #SENDRAW doesn't?

Wizard Joined: 17 Jun 2006 Posts: 1201

Wanderer Joined: 09 Jun 2006 Posts: 62 Location: Florida

I have a package containing roughly 40 classes, some large and some small, but many hundreds, if not thousands of settings. I haven't noticed any problem in my ability to fight on the IRE mud I play and am still experiencing a significant improvement over 1.34 and ZMud versions. The answer to 'how exactly you are supposed to do offense' is one you can only answer yourself, but I can tell you I've had 0 problems thus far maintaining my own.

Wizard Joined: 14 Aug 2004 Posts: 1269

Posted: Tue Nov 06, 2007 2:50 am

Wizard Joined: 17 Jun 2006 Posts: 1201

Actually I don't use any #wait commands at all. The only thing I use is #alarm to re-eat or reapply salves and so on if it doesn't happen the first time due to being afflicted with stupidity or something. Once I get the line I ate the herb it clears that alarm. It is also only waiting to eat one herb at a time or apply one salve at a time. The aliases that run each time I get afflict are nothing more than an #if statement checking if I can actually eat or apply and then a #switch statement which runs through all the afflictions and chooses the right herb or salve alias to execute. The actual herb or salve alias contains the alarm. So in combat the herb heal alias, salve heal alias, and so on are executing constantly. They are all set up exactly the same with an #if statement and a #switch statement. I have exactly 8 of these curing aliases. One each for herbs, salves, elixirs, focus, prone, writhing, sleep, and tree. For each herb, salve, and elixir I have a separate alias that sends to eat or apply and then sets of the alarm to do it again if I don't.

This still does not explain why I can't even for instance enter attack target on the command line while a bunch of lines are being received. The only thing that is happening there would be the OnPrompt updating my health and mana, turning off a bunch of triggers or classes that might be open, and my curing aliases mentioned above firing.

If anyone has a better idea I am all ears. I thought what I was doing was simple and easy, but apparently it isn't.

Apprentice Joined: 26 Apr 2007 Posts: 113

I use #ALARMs alot as far as system defense goes, if only to ensure that when I try curing, it will go through.

I'm all for stricter script acceptance and so on, however, I have not seen suggestions for alternatives to these methods, either by looking through the help files, or by watching the forum closely. This will often put people off. (Why bother using a client that -can- be faster, but less friendly to what I *know*?)

This may mean that you'll want to look at how the help files are written, last I checked, all of the files only offered examples of syntax. Perhaps have each file offering alternative methods for doing something similar?

If the help documentation is improved, I can see it being friendlier to old Zmud users, etc, which would be your main base market at this point in time.

I'll try making my scripts faster and so on, the main problem is, I wouldn't know where to start, since I started rewriting from scratch in 1.34 in the hopes that I'd avoid compatibility issues in the future, such as this. Does this mean I need to start over again in 2.x because the little foresight I had didn't expect such a drastic change in what is acceptable?

The baseline is, I like the potential of Cmud and I'd like to make it work for me. I'm sure the same applies for most other "new" users coming from using Zmud.

Wizard Joined: 17 Jun 2006 Posts: 1201

Right exactly that is the same reason I use alarms to make sure it goes through. That's it! I don't have a bunch of complicated crap going on. Fang has my package so maybe he can tell me what I am doing wrong, because I sure don't see it.

Apprentice Joined: 26 Apr 2007 Posts: 113

Posted: Tue Nov 06, 2007 4:24 am

It's not that, Asilient, it's that because your thread is now executing in parallel with other threads, the two threads compete for resources. If one thread changes a variable at the wrong time, it can cause problems. For example, thread1 could change the value of @something from 1 to 0 between when thread2 checks @something, and when it executes its commands. #if (@something) {whatever} - whatever will get executed, but at the time that it does, something=0, which might cause problems. Those are the issues that Zugg is talking about.

Zugg: Is it true that previous versions also prevented the sending of commands until there was a break in script execution, but without the invisible typeahead problem? IRE users have a penchant for running many scripts on their prompts, mostly because it's regular and fast. Having to wait for script execution to finish before you can send commands considerably slows CMUD's response to input from the command line in these cases, which obviously isn't good.

Apprentice Joined: 26 Apr 2007 Posts: 113

Well, that's what I'm saying, Fang. To avoid that problem I'd need to create different variables for the various scripts I'd need to check a single variable in? Saying that, I can see the same problem arising regardless.

All in all, I'm not entirely certain -how- to avoid that problem, for what limited knowledge I have.

As I said, I'll try playing around with my scripts and see if I can change the resultant slowdown. As you said, waiting for script execution to finish before letting previous input go ahead can be problematic. I might have wanted to attack a few seconds ago, but now I've been hit so hard I need to go defensive. By the time scripts finish running, my attack goes through and my chance to go defensive is lost, and I'm most likely dead because of it. :P

Wizard Joined: 17 Jun 2006 Posts: 1201

Exactly Asilient. There is no way you can do combat like that because by the time anything goes through you are probably dead. IRE combat is fast and furious and I don't know who Arlie is, maybe they are a real life programmer, but I am not. I still don't think that is an honest statement though saying that they see no slowdown. Obviously they must not be involved in combat much. Have an occultist and an apostate attack you at the same time and tell me your statement is still going to stand. There is no way I would ever be able to enter anything on the command line until the fight was over and I was dead because I would just have to cure the whole time and would never be able to do offense or even some defenses skills because I couldn't type the command in the command line and send it.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

What Zugg is saying by that is that the value of a variable could be in use by 1 trigger and then changed by a second. The instances where this will be a problem are with loops, especially those that take a long time. That is what the critical sections are for, it is either #SECTION or #CRITICAL I haven't quite completely memorized all the new commands yet. In any case it should be somewhat rare for problems to happen with variables.

On to more fun, OldGuy2 do you create and destroy the alarms each time or is it just #T± that you use?

Apprentice Joined: 26 Apr 2007 Posts: 113

Well, I wouldn't say it's a matter of being a programmer outside of playing MUDs, I'm perfectly willing to admit that it's a problem with my scripts. The main point I am making is that it isn't so friendly to those who are upgrading from Zmud. Getting used to Cmud 1.x was easy for me, I could write my scripts virtually the same, with a few changes to syntax, and the use of a new function here or there.

However, 2.x sets the bar to a completely higher level (something I'm all for.) however, there isn't much help in the transition. I found the changes for Zmud users really helpful, it told me what I *might* have done before, and how I am supposed to do it now. The only additional help that I am likely to receive is that from other Cmud users, which I'm fortunate enough to know one or two of from Aetolia. The main flaw in this is that if you're completely new to Cmud and don't want to feel like an idiot clogging up the general discussion, there is very little help. For instance, I know a lot of players on Aetolia swore by #ALARM for herb eating, etc, if using multiple #ALARMs is going to be harmful, it would not hurt to offer some alternative methods to these just to help that transition along.

Apprentice Joined: 26 Apr 2007 Posts: 113

Wizard Joined: 17 Jun 2006 Posts: 1201

Yes that is what I do is use #untrigger. In fact very similar to what you have there.

Here is what it looks like.

This is the value for the trigger:

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Ok, figuring fighting a raja serpent using double stab equates to 1 trigger created and destroyed each second of combat. If we then figure you spend 20 minutes out of each hour in combat, that gives a rough average number of 1200 triggers created and destroyed each hour.

How long do you spend online per sitting? Do you leave CMud open and waiting for you when you go offline? Can you tell where I am headed with this line of questioning?