 |
Anaristos
Sorcerer
Joined: 17 Jul 2007
Posts: 821
Location: California
|
 Posted: Fri Jul 17, 2009 11:25 pm
[308B] Inbound data interference
|
I've noticed severe interference trying to type either on the command line or in the settings Editor when a large block of data is being sent by the mud (as a response from a spellup script, for instance). There is a noticeable lag in the typing. Also, there are instances where the Editor "loses" the current setting and displays the setting just updated by MUD output (e.g. captured from a trigger). While the Editor problem existed before (and was fixed way back in 2.34), the halt of typing on the command line is new.
|
|
_________________
Sic itur ad astra. |
 |
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Sat Jul 18, 2009 12:27 am
|
This means that you have a script running in the background that is taking a long time. You can use the Script Debugger to see what trigger or script is taking all of the time. Windows gives "typing" a lower priority than threads that are running scripts, and so a really slow script that triggers on too much text could definitely cause this problem. Without a *lot* more information to reproduce this, there is nothing else I can do to help with it.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Sat Jul 18, 2009 12:30 am
|
Also, I'm going to quote this again from the "How to report bugs" topic:
| Quote: |
I think it is about time to bring a link to this article back.
How to Report Bugs Effectively
To summarise:
* Be Specific - say exactly what you did, in the order you did it. The menu option "Load" is different to Alt-L.
* Be Verbose - having information you don't need is better than not having information you do need.
* Avoid Pronouns - don't say "it" or "the window", it can be ambiguous.
* Read What You Wrote - and be sure that someone else could understand it. |
You can't just say "It doesn't work". You need to provide specific instructions on reproducing problems. Otherwise they just get filed in my "untested/cannot reproduce" folder, and those reports get mostly ignored.
With a problem like you reported above, you should be trying the same thing with your triggers disabled to see if it's a trigger/script problem. Probably 90% of the problems people report are due to bad scripts (often converted from zMUD). Part of the JOB of beta testing is trying to narrow down the cause and coming up with a way to reproduce a problem that everyone else here can also test. Without your scripts, there is no way for any of us to test this. |
|
|
|
|
Anaristos
Sorcerer
Joined: 17 Jul 2007
Posts: 821
Location: California
|
Posted: Sat Jul 18, 2009 9:29 pm
|
I did point out that a script was running. What I was trying to say was that the lag is new. The script is not new. I re-installed 307B and tried it and the problem is not there, that is why I posted. There was nothing to explain with respect to what I was doing, because I was doing the same thing I've been doing since I created the script back in 2.34. In prior releases (prod and beta) there was no problem waiting for the MUD to finish sending bulk data (data generated in response to a looping script) before the typing could continue. I am sure there was lag then too, but it was not noticeable. It is now. The a delay is measured in seconds. The delay also occurs when the Settings Editor window is open and variables are updated due to MUD interaction. What I noticed about the Editor window is that, just as it was done in 2.34, the Editor "moves around" when data is updated and sometimes causes the setting that I am working on to disappear from view and the (last) updated setting appear instead.
|
|
_________________
Sic itur ad astra. |
|
|
|
|
|
|
