MapTool 1.3 Final, patch01 (build 84)

New build announcements plus site news and changes.

Moderators: dorpond, trevor, Azhrei, Craig

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: MapTool 1.3 Final, patch01 (build 84)

Post by aliasmask »

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.

User avatar
plothos
Great Wyrm
Posts: 1890
Joined: Sat Jun 21, 2008 1:07 am

Re: MapTool 1.3 Final, patch01 (build 84)

Post by plothos »

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.
Error Msg
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)
Drop-In Utilities:
My Spell Manager for D&D3.5 and PFRPG
My Inventory Manager for D&D and PFRPG, but more generally useable than that.
My Message Manager -- My Top-Down D&D Token Images
and my Custom Initiative & Status/Spell-Effect Tracker (work in progress, but functional).

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: MapTool 1.3 Final, patch01 (build 84)

Post by jfrazierjr »

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.
Error Msg
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.
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
plothos
Great Wyrm
Posts: 1890
Joined: Sat Jun 21, 2008 1:07 am

Re: MapTool 1.3 Final, patch01 (build 84)

Post by plothos »

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.
Drop-In Utilities:
My Spell Manager for D&D3.5 and PFRPG
My Inventory Manager for D&D and PFRPG, but more generally useable than that.
My Message Manager -- My Top-Down D&D Token Images
and my Custom Initiative & Status/Spell-Effect Tracker (work in progress, but functional).

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: MapTool 1.3 Final, patch01 (build 84)

Post by jfrazierjr »

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 save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: MapTool 1.3 Final, patch01 (build 84)

Post by aliasmask »

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.

User avatar
plothos
Great Wyrm
Posts: 1890
Joined: Sat Jun 21, 2008 1:07 am

Re: MapTool 1.3 Final, patch01 (build 84)

Post by plothos »

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?
Drop-In Utilities:
My Spell Manager for D&D3.5 and PFRPG
My Inventory Manager for D&D and PFRPG, but more generally useable than that.
My Message Manager -- My Top-Down D&D Token Images
and my Custom Initiative & Status/Spell-Effect Tracker (work in progress, but functional).

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Final, patch01 (build 84)

Post by Azhrei »

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: Select all

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

User avatar
francogp
Cave Troll
Posts: 66
Joined: Thu Feb 02, 2006 1:06 pm
Location: Mordor

Re: MapTool 1.3 Final, patch01 (build 84)

Post by francogp »

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: Select all

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)

michaelheggen
Kobold
Posts: 4
Joined: Wed Mar 30, 2011 3:23 pm
Location: Oregon

Re: MapTool 1.3 Final, patch01 (build 84)

Post by michaelheggen »

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

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: MapTool 1.3 Final, patch01 (build 84)

Post by jfrazierjr »

@Plothos:

Code: Select all

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).

random developery type stuff
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.
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: MapTool 1.3 Final, patch01 (build 84)

Post by aliasmask »

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: Select all

[dialog(d1000000,"title="+title):{<!-- content -->}]
This will always create a new window independent of the title.

michaelheggen
Kobold
Posts: 4
Joined: Wed Mar 30, 2011 3:23 pm
Location: Oregon

Re: MapTool 1.3 Final, patch01 (build 84)

Post by michaelheggen »

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
Last edited by michaelheggen on Thu Mar 31, 2011 4:59 pm, edited 1 time in total.

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Final, patch01 (build 84)

Post by Azhrei »

francogp wrote:Heres a bug...
Already reported previously in this thread, and already fixed in SVN. :)

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: MapTool 1.3 Final, patch01 (build 84)

Post by Craig »

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.

Post Reply

Return to “Announcements”