MapTool 1.3 Final, patch01 (build 84)

I think that is by design. You can reset the frame title by adding temporary=1. The first time, it will put the old title, but then clear it from the cache. The second time it will use the title specified in the property string. You do have to close the dialog to have it show the new title as well, otherwise the dialog frame is not redrawn.

Azhrei wrote:

Thanks for the report.

What does the CPU usage look like during these times? Is it pegged at 95% or more?

Since you said that the game sessions start out fine, it could be that the macros...

Here's the memory error he's getting.

java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknown Source)
at net.rptools.maptool.client.AutoSaveManager.actionPerformed(AutoSaveManager.java:118)
at javax.swing.Timer.fireActionPerformed(Unknown Source)
at javax.swing.Timer$DoPostEvent.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at net.rptools.maptool.client.swing.MapToolEventQueue.dispatchEvent(MapToolEventQueue.java:25)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

plothos wrote:

Azhrei wrote:

Thanks for the report.

What does the CPU usage look like during these times? Is it pegged at 95% or more?

Since you said that the game sessions start out fine, it could be that the macros...

Here's the memory error he's getting.

java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknown Source)
at net.rptools.maptool.client.AutoSaveManager.actionPerformed(AutoSaveManager.java:118)
at javax.swing.Timer.fireActionPerformed(Unknown Source)
at javax.swing.Timer$DoPostEvent.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at net.rptools.maptool.client.swing.MapToolEventQueue.dispatchEvent(MapToolEventQueue.java:25)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

Well.. he is running out of memory, plain and simple. A high stack size is one possible reason for this combined with a low amount of allocated memory when starting MT. If neither of those help, then it will likely boil down to Veggie having to rebuild is macro's to be more stack friendly.

Well, what's funny about that is he's allocated 1024 and MT is using only like 200. Javaw is using like 800+, however. Veg recommends stack size 10, but that has always struck me as way too high.

Also, just to clarify, these errors are cropping up when he isn't having the lag error mentioned earlier, but it does seem macro related.

plothos wrote:

Well, what's funny about that is he's allocated 1024 and MT is using only like 200. Javaw is using like 800+, however. Veg recommends stack size 10, but that has always struck me as way too high.

Also, just to clarify, these errors are cropping up when he isn't having the lag error mentioned earlier, but it does seem macro related.

Yea.... 10 really is way to high for a stack size. subdividing the macros up more will help that, but either Veggie has to do that or someone will have to take over. I used his older version, but since he pushed his stack size up to 10 suggested, I have looked around for alternatives( settled on Rumble's Slim but have/will make additional tweaks to it).

It is "possible" that something in one or more macros is calling putToken(the java method that transfers tokens from one machine to the server and then back out to clients) before the macro is finished. I THOUGHT we had all of those cleaned up, but it is always possible something was missed.

You say he is the GM? If so, and he has poor throughput on the upstream side, then his poor network is probably choking with sending all of those updates out the the clients when a token is changed(and the more clients, the worse it will be). Have someone(who has a good upstream speed) else host the server for a night and play with the same settings and see if it makes it any better. Best case scenario is that his network card or router are messed up(well, best case in terms of quick fixes if he has the money to replace that is) and the issue is not due to an ISP issue as they are generally pretty blah to work with in these types of cases. A second machine on his network might help rule out the network card(might also want to have him check the network FAQ as it's possible a few config changes to his network card settings "might" help. Likewise, removing his router and doing a direct connect might rule that out. Using something like DSLreports will give you a general baseline for upload and download speeds to see if changes make a difference or not.

I once cleared up a macro that caused a stack error by splitting up the nested function calls. I think I had 3 string like functions that seemed to create huge stacks. I think it was a lower/replace and something else like encode nested in to each other. I think the bigger the string, the bigger the stack. But I've always run with a stack of 2 while some of the clients with the same macros needed a stack of 3 using lindsays framework.

Some more data:
Lag popped up again (after the errors, but not at all close, the errors were around for a long while first).

I before had run the older Veg with stack 2 at no problems, but have been running with 10. We shut all MT on all PCs/GM down and restarted with 1024/64/6 and lag remained upon restart.

I was looking at things on my side and found that for some reason gmail on firefox on my machine was choking at 50% CPU for no reason I could see (I had a IM open in gmail, but meh). This might be just coincidence, but gmail and indeed everything on my machine (a client) was running way slow. I shut down everything but MT and Skype and it seemed like performance picked up on my end. We didn't get to play long after, but it seemed like the lag issue might have been improved after that.

Is there any way at all gmail and/or firefox could be interacting with skype or MT in unfortunate ways to create this lag/slowdown?

plothos wrote:

Is there any way at all gmail and/or firefox could be interacting with skype or MT in unfortunate ways to create this lag/slowdown?

Well, I wouldn't say they were "interacting with", but GMail does a lot of background stuff depending on the options you have enabled. For example, with lots of contacts and their "chat" feature turned on, it's constantly checking to see if someone wants to chat with you. I have GoogleVoice and GoogleTalk and ever since I enabled the latter I seem to have lag issues if that tab is open.

They could try switching back to the "Basic HTML" layout (from the "standard" layout) and see if that helps. IIRC that disables the extras.

Incidentally my players had some massive lag on Tuesday night. Neofax pasted his performance numbers into the chat so I have investigation to do. Those numbers were ridiculously high in parts of the token renderer. Here are the numbers for anyone interested (cleaned up a little). As you can see, the tokenlist-1 fields are the most time-intensive, followed by fog and labels.

Code:

Timer zonerenderer: 7938
   calcs: 80 
   tokenlist-1.1: 7859
   tokenlist-1a: 7859
   tokenlist-1.1: 7858
   tokenlist-1e: 7856
   labels: 7855

Timer zonerenderer: 22818
   calcs: 89
   tokenlist-1.1: 22729
   tokenlist-1a: 22728 
   tokenlist-1.1: 22728
   auras: 36
   auras-4: 36
   tokenlist-1e: 22686
   labels: 7822
   fog: 14864

Timer zonerenderer: 23041
   calcs: 92
   tokenlist-1.1: 22949
   tokenlist-1a: 22949
   tokenlist-1.1: 22949
   auras: 23
   auras-4: 22
   tokenlist-1e: 22921
   labels: 7846
   fog: 15074

Heres a bug...

* create a map with CBV.
* put some light and give vision to tokens (PC)
* set "show as player"
* move a token to a dark zone (so the "player" cant see his token)
* try to "move" token via "right click->move" in the map explorer

Code:

java.lang.NullPointerException
   at net.rptools.maptool.client.tool.PointerTool.mouseMoved(PointerTool.java:576)
   at java.awt.AWTEventMulticaster.mouseMoved(Unknown Source)
   at java.awt.Component.processMouseMotionEvent(Unknown Source)
   at javax.swing.JComponent.processMouseMotionEvent(Unknown Source)
   at java.awt.Component.processEvent(Unknown Source)
   at java.awt.Container.processEvent(Unknown Source)
   at java.awt.Component.dispatchEventImpl(Unknown Source)
   at java.awt.Container.dispatchEventImpl(Unknown Source)
   at java.awt.Component.dispatchEvent(Unknown Source)
   at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
   at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
   at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
   at java.awt.Container.dispatchEventImpl(Unknown Source)
   at java.awt.Window.dispatchEventImpl(Unknown Source)
   at java.awt.Component.dispatchEvent(Unknown Source)
   at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
   at java.awt.EventQueue.access$000(Unknown Source)
   at java.awt.EventQueue$1.run(Unknown Source)
   at java.awt.EventQueue$1.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
   at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
   at java.awt.EventQueue$2.run(Unknown Source)
   at java.awt.EventQueue$2.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
   at java.awt.EventQueue.dispatchEvent(Unknown Source)
   at net.rptools.maptool.client.swing.MapToolEventQueue.dispatchEvent(MapToolEventQueue.java:25)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.run(Unknown Source)

aliasmask wrote:

I think that is by design. You can reset the frame title by adding temporary=1. The first time, it will put the old title, but then clear it from the cache. The second time it will use the title specified in the property string. You do have to close the dialog to have it show the new title as well, otherwise the dialog frame is not redrawn.

Hmm.... You've provided a workaround, but I fail to see how this is a useful feature. I'm willing to be enlightened, though!

-Mike

@Plothos:

Code:

java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)

This means windows would not provide any additional memory for whatever reason (native means OS). Basically, the OS is telling java it can't have any more memory and typically, this is due either to to low java VM memory allocation or stack to high in combination with the previous(or a windows bug/java bug).

One thing (which may be totally unrelated) that I just found out via another list i belong to is that Windows (and I am sure other OS's have their own numbers for this in their GUI components) has a limit on the number of ... ummm widgets(placeholder for things like buttons, fonts, textures, windows, etc) allowed which are internally called GDI's by the windows code. This came up because a guy was building an application with lots of windows(variable number) each with lot's a controls on it and it was running out of memory. There was a "bug" in the library code he was using (Win32::GUI for anyone interested) where a background color object was being created for each control(rather than once and passed as reference) and this was bumping into the GDI limit. While I doubt this was the cause of the issue as it would take a large number of controls to do this, I just wanted to throw that out there.

michaelheggen wrote:

aliasmask wrote:

I think that is by design. You can reset the frame title by adding temporary=1. The first time, it will put the old title, but then clear it from the cache. The second time it will use the title specified in the property string. You do have to close the dialog to have it show the new title as well, otherwise the dialog frame is not redrawn.

Hmm.... You've provided a workaround, but I fail to see how this is a useful feature. I'm willing to be enlightened, though!

-Mike

I don't know what your need is to alternate applying title methods, but if you're going to be using the same dialog variable name with different titles, I recommend always putting temporary=1. You can do that, or use some other criteria to set the dialog variable than just teleport for the different dialog creation methods. Here's something I have done:

Code:

[dialog(d1000000,"title="+title):{}]

This will always create a new window independent of the title.

Sorry, I understand how to avoid the problem. That's not my point.

And I don't have a need to alternate titling methods, either. I was just tinkering to see how the dialog roll option worked and stumbled across this by accident.

My point is coming from a software design standpoint. When you say that this is "by design", that implies that there is a purpose. If there's no purpose behind it, then it is either a bug or a design flaw. And purpose-wise, I don't see how the functionality of being unable to change the dialog title is useful.

Not trying to be difficult; just trying to be clear. And in the scheme of things, this is a pretty minor problem for MT (unless it points to some larger problem with the dialog roll option, such as a set of variables not being properly reinitialized or something like that).

Thanks for the info.

-Mike

francogp wrote:

Heres a bug...

Already reported previously in this thread, and already fixed in SVN.

michaelheggen wrote:

My point is coming from a software design standpoint. When you say that this is "by design", that implies that there is a purpose. If there's no purpose behind it, then it is either a bug or a design flaw. And purpose-wise, I don't see how the functionality of being unable to change the dialog title is useful.

Initialization parameters are only read at initialization so that users are not surprised by their windows resizing on them all the time (after all if the user resizes the frame the macro shouldn't change that). The purpose behind the title not changing is because all these parmeters are initialization parameters and as a developer I would be somewhat surprised if some initialization parameters functioned for more than initialization and others didn't. Consistency is a valid reason for making a design decision -- one that is all too often overlooked.

RPTools.net

MapTool 1.3 Final, patch01 (build 84)

Who is online

Top

Top

Top

Top