MapTool 1.3 Final, patch01 (build 84)

[lmarkus001]

I found the individual views caused an EXTREME load. So much so that I had to turn them off (the server became extremely sluggish and it was hard to get macros to run). However they did function correctly.

We ran into one issue that appears to be somewhat reported here, the mouse error:

Spoiler

java.lang.NullPointerException
at net.rptools.maptool.client.tool.PointerTool.mouseMoved(PointerTool.java:577)
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.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)

This occurred for only one of my players, and we were on a square grid. It seemed to be tied to her token being in the Initiative panel and using Initiative: Locked Movement. She was on Win7 32-bit o/s. We had a mix of WinXP, Win7/64, Vista, Vista/64, Win7/32, Mac. Only the one player saw the issue. I was able to spam click CANCEL on her machine until the error stopped, and then removed her token from the initiative panel with my GM machine, at which point she became functional again. Oh yeah, the error was persistent for her even if she closed MapTools and returned. It took the spam CANCELLING and then GM removal from the Init panel to make her functional again.

I did not see a fix to this specifically listed in the ChangeLog so thought to remention it.... I will go post up a bug report formally. This is a fairly big deal. It means that Lock Player Movement is unusable.

[Azhrei]

I did not see a fix to this specifically listed in the ChangeLog so thought to remention it.... I will go post up a bug report formally. This is a fairly big deal. It means that Lock Player Movement is unusable.

You're right -- it's not specifically mentioned. It's related to the movement validation code and to the later comment about movement on a hex grid. I believe I have it squashed, but I need to do some more testing. I have a game tonight, but I plan to run MT on my MacBook with Linux and Windows virtual machines running and try them out against each other.

I need to do that anyway to verify some of the most recent drag/drop changes. The changes are so d/d will work reliably from the desktop and applications such as TokenTool and a web browser. Currently different d/d operations are broken on different platforms, partly due to bugs (JRE on Linux, I'm looking at you!) but partly because the code in MapTool is a bit arcane in this regard.

[plothos]

I was noting in my last game an issue/freq that was mentioned in the past and while not quite a bug seems like it wouldn't involve much of what worries you when it comes to freqs in general, so I thought I'd mention it again:

The portrait stat-sheet in the lower left are often more obtrusive than they need to be, because the stat sheet is frequently larger than the portrait (not always and I have no way of knowing if my own experience is any great guide, but I imagine I'm in at least a sizable minority if not a great majority here), and because the sheet is to the right of the portrait the result is the larger element being placed more centrally on the map. If it could be swapped around to have the portrait on the right (and better yet if there was an option to place it on one side or the other), that would be dandy, and I imagine wouldn't touch on too much disparate code.

[silversonic]

I was noting in my last game an issue/freq that was mentioned in the past and while not quite a bug seems like it wouldn't involve much of what worries you when it comes to freqs in general, so I thought I'd mention it again:

The portrait stat-sheet in the lower left are often more obtrusive than they need to be, because the stat sheet is frequently larger than the portrait (not always and I have no way of knowing if my own experience is any great guide, but I imagine I'm in at least a sizable minority if not a great majority here), and because the sheet is to the right of the portrait the result is the larger element being placed more centrally on the map. If it could be swapped around to have the portrait on the right (and better yet if there was an option to place it on one side or the other), that would be dandy, and I imagine wouldn't touch on too much disparate code.

You know, I've never really thought about that, but now that you mentioned that, I agree completely. Not a game changer, but it would a better place for it.

[Full Bleed]

If it could be swapped around to have the portrait on the right (and better yet if there was an option to place it on one side or the other), that would be dandy, and I imagine wouldn't touch on too much disparate code.

Nice suggestion. If the code wasn't smart enough to determine which was larger, we would need to have a choice though because it's not always the case that the stat sheet is larger.

It would also be very cool if we could have some transparency on the stat-sheet background. I find it gets in the way often. At least 50% if fixed (though a slider or other preset would be even better.) Programatically, would it be easier to just swap in a background graphic texture that had 50% transparency rather than having MT do something like that on the fly?

[Rumble]

If it could be swapped around to have the portrait on the right (and better yet if there was an option to place it on one side or the other), that would be dandy, and I imagine wouldn't touch on too much disparate code.

Nice suggestion. If the code wasn't smart enough to determine which was larger, we would need to have a choice though because it's not always the case that the stat sheet is larger.

It would also be very cool if we could have some transparency on the stat-sheet background. I find it gets in the way often. At least 50% if fixed (though a slider or other preset would be even better.) Programatically, would it be easier to just swap in a background graphic texture that had 50% transparency rather than having MT do something like that on the fly?

IIRC from how the statsheet is generated, swapping the texture is the only way to do it. I've done it just playing around (I think...aku?...was also messing with it).

[PinkRose]

My statsheet looks nothing like yours.
Mine has 8 lines. and is about 4 pixels taller then the picture.
And that's for the players. If a player is looking at a monster, there is only 1 line for damage so forcing the swap, would make mine look odd.

[Azhrei]

This won't happen in 1.3, but we have plans to revamp the statsheet in 1.4.

Don't tell Craig, but I'm actually hoping it can become a JavaFX plugin. If we built two or three of them as plugins, other users who are programming-inclined could build more and could make them game system-specific, if they wished. MapTool could then be given a location where to grab plugins from (sort of like how the repositories work now).

JavaFX takes a different approach from normal Java programming. The programmer describes a "scene" and then the components that should be placed in the scene. It's a declarative style of programming, instead of procedural. It has some advantages for building UI code but gets clunky when there needs to be a lot of conditional logic. So I'm not sure it's really a good idea for this particular situation, but it would still be a great plugin example since they are small and not necessarily "mission critical".

[Craig]

Don't tell Craig

I better not read this then.

JavaFX takes a different approach from normal Java programming. The programmer describes a "scene" and then the components that should be placed in the scene. It's a declarative style of programming, instead of procedural.

You may be thinking of JavaFX script, which Oracle has discontinued. Instead for JavaFX 2.0 they are taking the core and creating a java API for it. Think of it as swing++.

[jfrazierjr]

You may be thinking of JavaFX script, which Oracle has discontinued. Instead for JavaFX 2.0 they are taking the core and creating a java API for it. Think of it as swing++.

Oh.. thank god.... I hated having to think about learning some off the wall language to build UI's.

[Azhrei]

You may be thinking of JavaFX script, which Oracle has discontinued. Instead for JavaFX 2.0 they are taking the core and creating a java API for it. Think of it as swing++.

Oh.. thank god.... I hated having to think about learning some off the wall language to build UI's.

Oh darn. A declarative approach would've been so much easier for users interested in writing plugins.

(No, I hadn't realized I was even referring to JavaFX script. Nor that it had been dropped. That'll teach me to check such things before posting. Or not. )

[Craig]

You may be thinking of JavaFX script, which Oracle has discontinued. Instead for JavaFX 2.0 they are taking the core and creating a java API for it. Think of it as swing++.

Oh.. thank god.... I hated having to think about learning some off the wall language to build UI's.

Because applying awful hacks to a system designed for content markup oh say like HTML is so much better?

[jfrazierjr]

Because applying awful hacks to a system designed for content markup oh say like HTML is so much better?

Heh.. only when the various vendors don't apply the exact same spec in the same way. Hopefully, that will eventually be fixed in say 10-15 years....

[Craig]

Because applying awful hacks to a system designed for content markup oh say like HTML is so much better?

Heh.. only when the various vendors don't apply the exact same spec in the same way. Hopefully, that will eventually be fixed in say 10-15 years....

You missed the point of my statement:)
Using HTML for GUIs has to rank as one of the all time worst hacks in computing, such an awful idea. Its almost like when people want to use excel for EVERYTHING

Edit fixed typo

[Azhrei]

Using HTML for GUIs has to rank as one of the all time works hacks in computing, such an awful idea.

Okay, now I've got to reply in a separate thread.

http://forums.rptools.net/viewtopic.php?f=6&t=18211