Gammon Forum : MUSHclient : Miniwindows : Miniwindow goes black

Register forum user name Search FAQ

Gammon Forum

Entire forum

MUSHclient

Miniwindows

Miniwindow goes black

Miniwindow goes black

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

Pages: 1 2 3 4 5

Posted by

Fiendish USA (2,514 posts)

bio Global Moderator

Date

Reply #30 on Mon 29 Aug 2011 03:22 AM (UTC)

Message

Fiendish said:

Hmm. I've got another user here who can get it to happen pretty reliably just by starting MUSHclient with no other intervention. I asked him to switch to 4.75 and it still happens.

Quote:
...debug summary...

It looks now like whether this happens for this user is entirely dependent on plugin load order. Moving bast_spellup to the very end of the load list made the problem stop. Putting it back made the problem happen again. We're now trying to narrow it down a bit more.

https://github.com/fiendish/aardwolfclientpackage

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #31 on Mon 29 Aug 2011 04:05 AM (UTC)

Message

Checking the code for drawing the output window, it seems to me that the window is being drawn, in a sense. The output area is initially cleared to the background colour/image, and then the miniwindows and text drawn.

Now the miniwindows are basicallly "blitted" from the bitmap which is stored as the miniwindow contents. That is, from whatever it was when you last drew stuff.

So if, for some reason, it wasn't drawing certain windows you would see nothing, not a black box. That is, you would see whatever was underneath.

The fact that it has blitted in a black box tends to suggest that the miniwindow contents are wrong, for some reason. A reason along the lines of, someone did a WindowCreate, and then relied upon the window filling up with data, and it didn't.

That's why I was asking about the assert, perhaps if the drawing code hits some condition, it just stops drawing.

Now as far as I can tell, this problem isn't happening to "simple" windows (like status bars) where the window is cleared and then redrawn in easy-to-follow logic.

You could confirm this a bit by clearing the window to some sort of colour, or pattern (like a grid) initially, and then overwriting. Now if we see this colour/grid but not what is supposed to be on top of it, that supports the idea of some logic problem in the plugin.

I also wonder if in one of the libraries, some button or something is getting much larger than it should be? Maybe something that is quite small becomes negative, and that negative value is taken as "from the RH side" and then wipes out everything under it?

What you could do to narrow this down is to remove all instances of black when drawing with some other unique colours (at least for testing). So if the window becomes purple (say) and you only draw that shade of purple in one place, then you have your culprit (this includes the initial colour you clear the window to).

- Nick Gammon

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

Posted by Fiendish USA (2,514 posts) bio Global Moderator

Date

Reply #32 on Tue 30 Aug 2011 02:44 AM (UTC)

Amended on Tue 30 Aug 2011 02:45 AM (UTC) by Fiendish

Message

Nick Gammon said:
The fact that it has blitted in a black box tends to suggest that the miniwindow contents are wrong, for some reason. A reason along the lines of, someone did a WindowCreate, and then relied upon the window filling up with data, and it didn't.

Given the evidence I've seen, I'm leaning more toward the miniwindow contents are wrong because they're getting put in the wrong place in memory or getting pulled from the wrong place. Here's why:

Going back to my user who can consistently reproduce the problem, I had him add the following function, activated by an alias, to the miniwin_tabbar.xml plugin.


function testFunction()
   local win = "eee96e233d11e6910f1d9e8e-tabwin"
   print(WindowRectOp (win, 2, 0, 0, 0, 0, ColourNameToRGB("green")))
   Repaint()
end

That *should* immediately make the tabbar window green. But for him it stays black. Though the print does display "0" as expected.

I had him then throw in


WindowShow(win, false)

at the end, and sure enough the black section goes away, which means that MUSHclient is drawing...SOMETHING...just not what it's supposed to be. And then when the mud sent some information and a plugin updated state, it came back. Still black.

https://github.com/fiendish/aardwolfclientpackage

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #33 on Tue 30 Aug 2011 07:01 AM (UTC)

Message

This suggests to me a bit that the internal bitmap has gone wrong. Since miniwindow operations draw to the bitmap, and then the bitmap is copied to the main window if (for some reason) it was corrupted then attempts to modify it might fail.

I'll look into it tomorrow.

- Nick Gammon

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

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #34 on Wed 31 Aug 2011 07:11 AM (UTC)

Message

Before I look into this in a great deal of detail, what I can't get my head around is why the plugin order affects it.

Say there is a bug in miniwindows, and after 1000 WindowCreate calls it no longer works properly. OK, but why does the plugin order affect that? Whatever order things are done in, the same things will be done, right?

If someone can make a minimal example that reproduces this, that would help track it down.

- Nick Gammon

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

Posted by

Fiendish USA (2,514 posts)

bio Global Moderator

Date

Reply #35 on Wed 31 Aug 2011 07:37 AM (UTC)

Amended on Wed 31 Aug 2011 07:54 AM (UTC) by Fiendish

Message

Quote:
Before I look into this in a great deal of detail, what I can't get my head around is why the plugin order affects it.

I don't think order causes it to happen. I think a certain plugin order may just cause it to happen sooner. Remember that for this particular user the problem manifests right away, whereas most other players require some random combination of events during gameplay before the problem occurs. I had the same user enable tracing before any plugins loaded and the problem didn't happen, which would indicate a race condition and that the output from trace changes the timing enough that the problem goes away.

Quote:
If someone can make a minimal example that reproduces this, that would help track it down.

I can't even get it to happen at all on my machine. I doubt we'll be able to produce any sort of example. :\

https://github.com/fiendish/aardwolfclientpackage

Posted by

Rooklion (9 posts)

Date

Reply #36 on Wed 31 Aug 2011 11:30 PM (UTC)

Message

I'm not sure if a larger test set is needed, but I just installed Linux as a 2nd OS and have MUSHClient running under Wine. I have so far not had a single problem with miniwindows turning black. It might be important to note that I was otherwise running Windows 7 64-bit as my other OS.

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #37 on Thu 01 Sep 2011 01:49 AM (UTC)

Message

Rooklion said:

Update: it seems resources might be to blame. I hadn't restarted my machine in quite a long time and it seemed like I was able to get the blackout in a very short period of time. I've just restarted and have been through a few CPs so far and no blackout.

It is starting to sound like some sort of Windows 7 problem. Perhaps when a process ends it doesn't free all the resources it uses?

- Nick Gammon

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

Posted by

Fiendish USA (2,514 posts)

bio Global Moderator

Date

Reply #38 on Thu 01 Sep 2011 01:59 AM (UTC)

Message

Nick Gammon said:
It is starting to sound like some sort of Windows 7 problem.

Can't be. The summary I posted says XP.

https://github.com/fiendish/aardwolfclientpackage

Posted by Bast (78 posts) bio

Date

Reply #39 on Fri 09 Sep 2011 07:20 PM (UTC)

Amended on Fri 09 Sep 2011 08:07 PM (UTC) by Bast

Message

Ok,something like this has now happened on my MUSHclient install with the miniwin_events window. I don't get a fully black window, I got a half drawn window. The hotspots in the window still worked whether or not that part of the window was drawn correctly. It happened within 30 minutes of me starting the client, I requested a campaign, killed a mob, and then the window got drawn incorrectly. If I reloaded the plugin, the problem happened immediately when I did "cp check". If I unload the plugin, change the id, then load the plugin again, the window was drawn correctly, but after a couple of cp mob kills, it did the same thing. If I repeated the process and converted back to the original id, the problem was still there.

Bad Image: http://i.imgur.com/9uIvi.png
Good Image: http://i.imgur.com/X5CwM.png

Here is what top showed:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5263 endavis 20 0 2686m 97m 14m S 11 2.5 3:19.39 MUSHclient.exe

I also had over a gig of RAM free.
Wine: 1.3.27.20110909-1.1
Opensuse 11.4

Here is my plugins command, which shows how much memory my plugins are using according to collectgarbage('count')


PluginFunctions v6.1 Plugins List
-----------------------------------------------
Name                          Vers  Cmd/Short Debug   Enabled   Mem Usage (KB)
-----------------------------------------------------------------------
Aardwolf_BigMap_Graphical     3.00                    true                
Aardwolf_Chat_Capture_Miniwindow2.00                    true                
Aardwolf_Chat_Echo            1.00                    true                
Aardwolf_GMCP_Mapper          2.00                    true                
Aardwolf_Group_Monitor        2.00                    true                
Aardwolf_Health_Bars          2.00                    true                
Aardwolf_Helper_Aliases       1.00                    true                
Aardwolf_Main_Layout          1.00                    true                
Aardwolf_New_Connection       1.00                    true                
Aardwolf_Package_Update_Checker1.00                    true                
Aardwolf_Planes_Mobs          1461  pl        false   true      597       
Aardwolf_Regen                1461  regen     false   true      882       
Aardwolf_Tick_Timer           1.00                    true                
Aardwolf_WeaponSwitch         1.10                    true                
Consider_info                 2.00                    true                
Copy_Colour_Output            1.10                    true                
GMCP_handler                  1.00                    true                
Miniwindow_Z_Order_Monitor    2.00                    true                
MobLookup                     1461  lm        false   true      679       
PluginFunctions               1461  plugins   false   true      827       
PotionQuafferv2               1.30                    true                
Repaint_Buffer                1.00                    true                
StatDB                        1461  statdb    false   true      1203      
StatMonitor                   1461  statmn    false   true      795       
Summary                       1.00                    true                
bast_hunt                     1461  bh        false   true      995       
bast_spellup                  1461  bsp       false   true      2313      
fix                           1461  fix       false   true      563       
miniwin_double                1461  mdbl      false   true      583       
miniwin_events                1461  mev       false   true      1145      
miniwin_help                  1461  mnhelp    false   true      1319      
miniwin_map                   1461  mmap      false   true      1665      
miniwin_moonbot               1461  mb        false   true      905       
miniwin_noexp                 1461  mnoexp    false   true      591       
miniwin_settings              1461  mnset     false   true      1346      
miniwin_spellup               1461  mspell    false   true      5841      
miniwin_stats                 1461  mstat     false   true      1397      
miniwin_tabwin                1461  mtab      false   true      1026      
miniwin_vote                  1461  mvote     false   true      663       
smoothTick                    1.00                    true                
xBastmush_Update_Checker      1461  bup       false   true      1283      
xBroadcast_Area               1461  barea     false   true      1322      
xBroadcast_CP                 1461  bcp       false   true      770       
xBroadcast_Double             1461  bdbl      false   true      552       
xBroadcast_GQ                 1461  bgq       false   true      1224      
xBroadcast_Inventory          1461  binv      false   true      745       
xBroadcast_Kills              1461  bkill     false   true      1172      
xBroadcast_Level              1461  blev      true    true      1034      
xBroadcast_Noexp              1461  bnoexp    false   true      1056      
xBroadcast_Quest              1461  bqu       false   true      549       
xBroadcast_Runto              1461  brunto    false   true      805       
xBroadcast_SpellSkills        1461  bsst      false   true      1231      
xBroadcast_Whois              1461  bwhois    false   true      563

Link to Debug Summary: http://pastebin.com/YfqJVVZG

Bast

Bast

Scripts: http://github.com/endavis

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #40 on Fri 09 Sep 2011 10:04 PM (UTC)

Message

Bear in mind that miniwindows are not directly locked to plugins, except the convention of using the plugin ID in their name. Thus unloading the plugin could still leave the window around.

As a work-around, try putting into the OnPluginClose function a call to delete the miniwindow(s) you use.

Then when the problem occurs, reload the plugin. This should force the miniwindow to be deleted, effectively simulating using a different plugin ID.

- Nick Gammon

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

Posted by Fiendish USA (2,514 posts) bio Global Moderator

Date

Reply #41 on Sat 01 Apr 2017 07:47 PM (UTC)

Amended on Sat 01 Apr 2017 07:48 PM (UTC) by Fiendish

Message

Resurrecting this because with 5.06-pre + Wine I and another linux user get it happening all the time in the aardwolf mapper plugin.

Until I can make a reliable test plugin, here is a set of screenshots: http://imgur.com/a/g6XUv
In all of those images, the miniwindow background color is bright yellow. You can see it in the last image where I've disabled the texture.

Things to note:
Sometimes the whole miniwindow is black.
Sometimes some amount of the top left corner is drawn.
Sometimes some amount of the top somewhere else is drawn.
Hotspots still work.
Resizing still works, but the black areas stay black.
Dragging still works, but the black areas stay black.
WindowCreate still works, but the black areas stay black.
Changing Z order works, but the black areas stay black.
WindowWrite produces an exact replica of what is displayed, black parts and all.

WindowSetPixel('b6eae87ccedd84f510b74714_mapper', 50, 50, 65535)
WindowShow('b6eae87ccedd84f510b74714_mapper', false)
WindowShow('b6eae87ccedd84f510b74714_mapper', true)
Repaint()
Redraw()
print(WindowGetPixel('b6eae87ccedd84f510b74714_mapper', 50, 50))

prints 0

https://github.com/fiendish/aardwolfclientpackage

Posted by

Teclab85 (16 posts)

Date

Reply #42 on Sat 01 Apr 2017 08:03 PM (UTC)

Amended on Sat 01 Apr 2017 08:39 PM (UTC) by Teclab85

Message

Hey all,

So I am the other user that has been affected by this. I am hoping we can figure it out! It is oftly annoying to lose a whole window at a time.

I wish I had more information to contribute to this but I don't I was working with fiendish all morning so we could figure the info out that he has.

Best Regards,

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #43 on Sun 02 Apr 2017 03:05 AM (UTC)

Message

My immediate reaction is that this is some sort of clipping issue. Why it is happening is unclear.

Template:bug

Please provide a summary of your world configuration:

Either use the scripting Immediate window (Ctrl+I) to execute: Debug ("summary")
or
Install the Summary plugin (see "Summary" feature) and type "summary"

Then copy the resulting information from the output window, and paste into a Forum message.

You need version 4.55 onwards of MUSHclient to do this.

I'm wondering if you have a large monitor and that somehow affects it.

Try a different (eg. earlier) version of Wine.

- Nick Gammon

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

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #44 on Sun 02 Apr 2017 05:51 AM (UTC)

Message

@Teclab85 - are you also using the pre-release version? If so, can you try the latest release version?

http://www.gammon.com.au/forum/?id=13918

The pre-release version is compiled with a totally different version of the compiler.

- Nick Gammon

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

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.

147,397 views.

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

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

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )