mudlet-makers team mailing list archive

[Colin L Crowley <sanaki@xxxxxxxxxxxxxx>]

Public bug reported:

Currently this is occurring and has only been confirmed on Mudlet
3.0.0-delta on Windows 7 home premium.

There appear to be a few individual conditions causing gauges to freeze
and refuse to update when they shouldn't be, all revolving around
setting the gauge's current value to 0, regardless of what the max value
is. This has also occurred at times with low values where the value
itself would render less than 1px width full in the gauge. The only
method I've been able to reproduce and confirm myself thus far on a
blank profile is as follows:

* Disable command echoing in the main window.
* Create a gauge -- createGauge("test", 100, 30, 500, 500, nil, "blue")
* Update the gauge's position to 0, or any value lower than maxvalue/width -- setGauge("test", 33, 10000)

At this point, the gauge will be frozen. Further updates to the gauge's value or maxvalue will be ignored until one the following is fulfilled:
* New text appears in the main console from any source (text being added to miniconsoles will not undo it)
* An update to the text on the gauge (including just a blank space, but not an empty string if no text is present already, in setGauge's text argument)
* A window resize event fires (including from the command line expanding to fit new lines)
* The window loses focus
* The gauge is moved
* The gauge is hidden and revealed

This bug seems to extend significantly further, though thus far I've
been unable to produce exact criteria for reproduction of the other
issues. Originally when it was happening to me, getting new lines in my
main console had no effect on restarting the gauge movement. After many
hundreds of gauge recreations (same name/size/position with a different
color in createGauge's arguments, though the recreations may be
irrelevant) and Mudlet running for around four days solid, I started
having issues where the (permanent) timers being used to update the
gauge positions were themselves not starting until the resize event was
fired in some manner, and the gauges were failing to recreate with the
non-full color. In terms of my script, I can include a workaround
easily, but the cause seems... disturbing. Restarting mudlet has
returned me to a state where only the above method has reliably produced
the issue. I'll post more if I manage to isolate a method for
reproducing the other problems.

** Affects: mudlet
     Importance: Undecided
         Status: New

** Description changed:

  Currently this is occurring and has only been confirmed on Mudlet
  3.0.0-delta on Windows 7 home premium.
  
  There appear to be a few individual conditions causing gauges to freeze
  and refuse to update when they shouldn't be, all revolving around
  setting the gauge's current value to 0, regardless of what the max value
  is. This has also occurred at times with low values where the value
  itself would render less than 1px width full in the gauge. The only
  method I've been able to reproduce and confirm myself thus far on a
  blank profile is as follows:
  
  * Disable command echoing in the main window.
  * Create a gauge -- createGauge("test", 100, 30, 500, 500, nil, "blue")
  * Update the gauge's position to 0, or any value lower than maxvalue/width -- setGauge("test", 33, 10000)
  
  At this point, the gauge will be frozen. Further updates to the gauge's value or maxvalue will be ignored until one the following is fulfilled:
  * New text appears in the main console from any source (text being added to miniconsoles will not undo it)
  * An update to the text on the gauge (including just a blank space, but not an empty string if no text is present already, in setGauge's text argument)
  * A window resize event fires (including from the command line expanding to fit new lines)
  * The window loses focus
  * The gauge is moved
  * The gauge is hidden and revealed
  
  This bug seems to extend significantly further, though thus far I've
  been unable to produce exact criteria for reproduction of the other
  issues. Originally when it was happening to me, getting new lines in my
  main console had no effect on restarting the gauge movement. After many
  hundreds of gauge recreations (same name/size/position with a different
  color in createGauge's arguments, though the recreations may be
  irrelevant) and Mudlet running for around four days solid, I started
- having issues where the timers being used to display the gauges were
- themselves not starting until the resize event was fired in some manner,
- and the gauges were failing to recreate with the non-full color. In
- terms of my script, I can include a workaround easily, but the cause
- seems... disturbing. Restarting mudlet has returned me to a state where
- only the above method has reliably produced the issue. I'll post more if
- I manage to isolate a method for reproducing the other problems.
+ having issues where the (permanent) timers being used to update the
+ gauge positions were themselves not starting until the resize event was
+ fired in some manner, and the gauges were failing to recreate with the
+ non-full color. In terms of my script, I can include a workaround
+ easily, but the cause seems... disturbing. Restarting mudlet has
+ returned me to a state where only the above method has reliably produced
+ the issue. I'll post more if I manage to isolate a method for
+ reproducing the other problems.

-- 
You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.
https://bugs.launchpad.net/bugs/1458719

Title:
  textless gauges freeze when set as empty

Status in Mudlet the MUD client:
  New

Bug description:
  Currently this is occurring and has only been confirmed on Mudlet
  3.0.0-delta on Windows 7 home premium.

  There appear to be a few individual conditions causing gauges to
  freeze and refuse to update when they shouldn't be, all revolving
  around setting the gauge's current value to 0, regardless of what the
  max value is. This has also occurred at times with low values where
  the value itself would render less than 1px width full in the gauge.
  The only method I've been able to reproduce and confirm myself thus
  far on a blank profile is as follows:

  * Disable command echoing in the main window.
  * Create a gauge -- createGauge("test", 100, 30, 500, 500, nil, "blue")
  * Update the gauge's position to 0, or any value lower than maxvalue/width -- setGauge("test", 33, 10000)

  At this point, the gauge will be frozen. Further updates to the gauge's value or maxvalue will be ignored until one the following is fulfilled:
  * New text appears in the main console from any source (text being added to miniconsoles will not undo it)
  * An update to the text on the gauge (including just a blank space, but not an empty string if no text is present already, in setGauge's text argument)
  * A window resize event fires (including from the command line expanding to fit new lines)
  * The window loses focus
  * The gauge is moved
  * The gauge is hidden and revealed

  This bug seems to extend significantly further, though thus far I've
  been unable to produce exact criteria for reproduction of the other
  issues. Originally when it was happening to me, getting new lines in
  my main console had no effect on restarting the gauge movement. After
  many hundreds of gauge recreations (same name/size/position with a
  different color in createGauge's arguments, though the recreations may
  be irrelevant) and Mudlet running for around four days solid, I
  started having issues where the (permanent) timers being used to
  update the gauge positions were themselves not starting until the
  resize event was fired in some manner, and the gauges were failing to
  recreate with the non-full color. In terms of my script, I can include
  a workaround easily, but the cause seems... disturbing. Restarting
  mudlet has returned me to a state where only the above method has
  reliably produced the issue. I'll post more if I manage to isolate a
  method for reproducing the other problems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1458719/+subscriptions