Gammon Forum : MUSHclient : General : Possible problem with timers in MUSHclient?

Entire forum ➜ MUSHclient ➜ General ➜ Possible problem with timers in MUSHclient?

Possible problem with timers in MUSHclient?

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3 4

Posted by

Nick Gammon Australia (23,166 posts) Bio Forum Administrator

Date

Reply #45 on Thu 09 Dec 2010 11:34 PM (UTC)

Amended on Fri 10 Dec 2010 12:23 AM (UTC) by Nick Gammon

Message

Twisol said:

Is there something about layering that you really want to avoid?

It's not in the official release. I did it as a proof of concept. As an exercise, you can improve it. Layer it, change the drawing order, whatever.

Twisol said:

When you update the visible window, merge the layers together.

Well, how exactly? Blending layers using blending modes means choosing a good mode, most of them interact in some way. You probably want an alpha mask. This all adds somewhat to the complexity. The upper layer would need to have a mask created at the same time you draw the content (which is basically twice the work). Then you need to merge with the mask. The extra complexity hardly warrants, for me, the change from a simpler solution of making the few things that are drawn on top (like the room name and area name) into a separate function. Call it once at the start so they appear while the rooms are being drawn, and then again at the end in case the rooms overwrote them.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Larkin (278 posts) Bio

Date

Reply #46 on Wed 15 Dec 2010 06:41 PM (UTC)

Message

Where do we stand on improving the performance of the timers? I'm noticing more and more problems with things that I do that rely on timers, and I'm wondering if it will be improved in the next release of MUSHclient or if I should be looking for alternative solutions to my problems, like manually checking my own expirations on each prompt.

I made changes to my calendar timing, and it ticks along nicely for a while before it becomes pretty much unresponsive and needs to be kickstarted again. It could well be a bug with my own logic, I admit, but the behavior is just odd.

Top

Posted by

Nick Gammon Australia (23,166 posts) Bio Forum Administrator

Date

Reply #47 on Thu 16 Dec 2010 08:51 PM (UTC)

Message

Well it's a design decision. I can make timers higher priority than processing incoming text. At present they are lower, so if you get a lot of text it will tend to push timers out quite a bit.

What would probably work is to check every time data arrives from the MUD, if it is time for the timer to fire (eg. if 1/10 of a second has elapsed since last time) and if so, process timers anyway.

That could slow down processing the text slightly but the timers should fire much closer to their designed times.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Larkin (278 posts) Bio

Date

Reply #48 on Thu 16 Dec 2010 08:57 PM (UTC)

Message

With what I'm seeing lately, I'd gladly take a small hit to processing incoming text to help these poor timers out a bit.

I assume the timers would continue to be processed in the background, too, for when text isn't coming in, and this is just an extra check.

I've always left my temporary timers hanging around and just disabled them, but now I'm thinking it'll be better to create and destroy them, even if I do so frequently. Not sure which is more expensive overall...

Top

Posted by Nick Gammon Australia (23,166 posts) Bio Forum Administrator

Date

Reply #49 on Thu 16 Dec 2010 10:49 PM (UTC)

Amended on Thu 16 Dec 2010 10:51 PM (UTC) by Nick Gammon

Message

It skips disabled timers quickly enough.

My testing so far shows this. First, I put in a "tick" timer (an ordinary timer that fires as fast as possible, namely after 0.1 seconds).


<timers>
  <timer enabled="y" 
   second="0.10" 
   send_to="12"
>
  <send>
local time = utils.timer ()

if last_tick_time then
  print (string.format ("Tick after %0.6f", time - last_tick_time))
end -- if

last_tick_time = time

</send>

  </timer>
</timers>

Old version


Sitting around doing nothing

Tick after 0.100140
Tick after 0.100146
Tick after 0.100151
Tick after 0.100255
Tick after 0.100022
Tick after 0.100142
Tick after 0.100162
Tick after 0.100159
Tick after 0.100101
Tick after 0.100168

Running to weather station

...

East Windy Mountains (386)
East Windy Mountains (385)
East Windy Mountains (384)
East Windy Mountains (383)
East Windy Mountains (382)
Entrance to the Weather Observatory
  You stand in the entrance of the Weather Observatory building. Many pictures 
of weather events line the entrance. Nothing fancy about the entry room. To 
the south there appear to be offices. You can leave the area by heading down 
from here.
[Exits: south down]
Tick after 10.466981

In other words, a lengthy delay for the timer (10.5 seconds).

New version


Sitting around doing nothing


Tick after 0.100138
Tick after 0.100158
Tick after 0.100142
Tick after 0.100134
Tick after 0.100150
Tick after 0.100136
Tick after 0.100140
Tick after 0.100158


Running to weather station

...

Tick after 1.071707
Koloma Forest (604)
Koloma Forest (603)
Dread Fields (602)
Dread Fields (601)
A Grassy Spot (600)
Dread Fields (599)
Danameq Kujalleq (598)
Danameq Kujalleq (597)
Diamond Gorge (596)
Tick after 1.360532
Glaciers of Hypergelidus (595)
Glaciers of Hypergelidus (594)
West Windy Mountains (593)
West Windy Mountains (592)
West Windy Mountains (591)
West Windy Mountains (590)
Rashara Bheigh (589)
West Windy Mountains (588)
The Windy Mountains (587)
The Windy Mountains (586)
Tick after 1.522459
The Windy Mountains (585)
The Windy Mountains (584)
The Windy Mountains (583)
The Windy Mountains (582)
The Windy Mountains (581)
A Shrine to an Unnamed God (580)
East Windy Mountains (579)
East Windy Mountains (578)
Sarakhalah (577)
East Windy Mountains (576)
East Windy Mountains (575)
East Windy Mountains (574)
East Windy Mountains (573)
Tick after 1.869307
East Windy Mountains (572)
East Windy Mountains (571)
Entrance to the Weather Observatory
  You stand in the entrance of the Weather Observatory building. Many pictures 
of weather events line the entrance. Nothing fancy about the entry room. To 
the south there appear to be offices. You can leave the area by heading down 
from here.
[Exits: south down]
An administrator is here shuffling papers.
Tick after 0.764838

The ticks above are at a much better interval than after 10 seconds, but still more than 0.1 second. However a bit more research shows that there were 15 "tick" lines during the run, and there were in fact 15 packets received from the MUD in that time. Now I added an extra test for the timers when a packet was received, so that accounts for why we got 15 ticks (one per packet).

I think the Aardwolf "run to" is a bit of an extreme case. The MUD bangs out large amounts of data in large packets, so you traverse about 60 rooms in only 15 packets.

Under more normal situations (like a battle) the MUD would be processing fight rounds for each player and packaging things up into smaller packets.

It would be possible to test for timers more frequently but then you get the possible case of the client spending more time checking timers than doing anything else.

At least in the example above, since the timers are now processed (potentially) per packet received, then you get a chance for some timer-based event to fire as soon as anything happens on the MUD. And if nothing happens, you still get the normal timeout that you used to get.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

157,956 views.

This is page 4, subject is 4 pages long: 1 2 3 4

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top