MapTool 1.2 Development Release Build 7
Moderators: dorpond, trevor, Azhrei, Craig
- trevor
- Codeum Arcanum (RPTools Founder)
- Posts: 11311
- Joined: Mon Jan 09, 2006 4:16 pm
- Location: Austin, Tx
- Contact:
MapTool 1.2 Development Release Build 7
This build specifically fixes several issues that were introduced in build 6. Please let me know if you are still having issues with the fog. It also picked up some features that were contributed since build 6:
Build 7 (1/30/2007)
* MRU list (contributed by galneweinhaw)
* CTRL-X to cut tokens, and associated Edit menu item (contributed by galneweinhaw)
* Bug fix: token sequential naming (contributed by galneweinhaw)
* Token sequential numbering naming tweaks (contributed by galneweinhaw)
* Add CTRL and SHIFT modifiers as F key modifiers for macros (contributed by galneweinhaw)
* Fix F10 key issue (contributed by galneweinhaw)
* Preference panel UI layout updates (contributed by galneweinhaw)
* Bug fix: tokens disappearing in player view
* Bug fix: update server state when updating token vision
* Bug fix: token vision shape not updating when rotating token
* Prefix all rolls with "*" to prevent cheating
* Macro button label updates
* Vision objects are now nameable
* In the vision menu list, left click to toggle enabled state, right click to edit
NOTE: This does not address the texture shapes lining up, that will be addressed in build 8
Build 7 (1/30/2007)
* MRU list (contributed by galneweinhaw)
* CTRL-X to cut tokens, and associated Edit menu item (contributed by galneweinhaw)
* Bug fix: token sequential naming (contributed by galneweinhaw)
* Token sequential numbering naming tweaks (contributed by galneweinhaw)
* Add CTRL and SHIFT modifiers as F key modifiers for macros (contributed by galneweinhaw)
* Fix F10 key issue (contributed by galneweinhaw)
* Preference panel UI layout updates (contributed by galneweinhaw)
* Bug fix: tokens disappearing in player view
* Bug fix: update server state when updating token vision
* Bug fix: token vision shape not updating when rotating token
* Prefix all rolls with "*" to prevent cheating
* Macro button label updates
* Vision objects are now nameable
* In the vision menu list, left click to toggle enabled state, right click to edit
NOTE: This does not address the texture shapes lining up, that will be addressed in build 8
Last edited by trevor on Tue Jan 30, 2007 11:43 am, edited 4 times in total.
Dreaming of a 1.3 release
- thelevitator
- Dragon
- Posts: 963
- Joined: Wed May 17, 2006 2:10 pm
- Location: "The Biggest Little City In The World!"
- Contact:
How do you set the expose so that it only shows the immediately visible area? The visible area lights up, but the fog doesn't seem to recover the area that the token has moved out of. I'm still trying to keep up with all the advancements, so let me know if that's currently not available.
"Neither hexes nor squares can confine me!"
James Anthony
"It's all in your head....."
http://www.spelz.net
James Anthony
"It's all in your head....."
http://www.spelz.net
Definately better with the token disappearing issue that we reported in 1.2B6.
There is still a slight issue with it though - more of a measuring issue than anything else.
In this example, you see no token because it is out of vision. this is expected behavior:
But when I move up my token up one square, the other token becomes visible, even though it isn't in the vision. This is probably due to the blocky light vs. the rounded:
There is still a slight issue with it though - more of a measuring issue than anything else.
In this example, you see no token because it is out of vision. this is expected behavior:
But when I move up my token up one square, the other token becomes visible, even though it isn't in the vision. This is probably due to the blocky light vs. the rounded:
- trevor
- Codeum Arcanum (RPTools Founder)
- Posts: 11311
- Joined: Mon Jan 09, 2006 4:16 pm
- Location: Austin, Tx
- Contact:
Actually, it's probably because of a single pixel overlap. The block cell is probably one pixel offset, which makes it overlap the cell with the token by juuuuust enough to make the cell visible. You only need a single pixel overlapping the rectangle that surrounds the token in order for it to be considered visible. We need to figure out how we want to handle precision edge cases like this
Dreaming of a 1.3 release
I noticed a similar effect in the test I used. I'm using the non-blocky vision and if the slightest edge of a square is in the visible area, any token in it is visible. This seems a little odd.
I'd like it if players could only see the bits of tokens that lie in the visible region (the lighter area in Dorpond's example). So players generally only see bits of tokens (for non-blocky light) or whole tokens in squares they can see (for blocky light) when a token is on the edge of their vision.
I'm sure that other people will have a different preference.
If players could only see bits of tokens then it would be possible to really freak them out too (I see a tail! What of? Don't know, but it's big...) - which is never a bad thing.
Otherwise, it's looking great. No problems so far and a map that is unusable before (4 tokens with 60ft vision) now ticks over nicely at ~8% CPU or ~15-20% when a token is moved. Whatever optimisation has gone in has made a big improvement.
I'd like it if players could only see the bits of tokens that lie in the visible region (the lighter area in Dorpond's example). So players generally only see bits of tokens (for non-blocky light) or whole tokens in squares they can see (for blocky light) when a token is on the edge of their vision.
I'm sure that other people will have a different preference.
If players could only see bits of tokens then it would be possible to really freak them out too (I see a tail! What of? Don't know, but it's big...) - which is never a bad thing.
Otherwise, it's looking great. No problems so far and a map that is unusable before (4 tokens with 60ft vision) now ticks over nicely at ~8% CPU or ~15-20% when a token is moved. Whatever optimisation has gone in has made a big improvement.
- trevor
- Codeum Arcanum (RPTools Founder)
- Posts: 11311
- Joined: Mon Jan 09, 2006 4:16 pm
- Location: Austin, Tx
- Contact:
Interesting. I specifically checked this right before building. Could you give me your specific repro steps, perhaps I missed a case.Phergus wrote:The outline marker for conic vision isn't rotating with the token until after a movement has been performed.
Also there is some debug output printing the name of the Vision.
Dreaming of a 1.3 release
One thing I did notice that seem to be more of an aggravation more than anything.
When we change the facing of the token (with cone vision for example), it deselects the token so to reveal, we have to click on the token again and then reveal.
Seems like an extra step. Since we are already on that token, we should still be on that token ever after changing the facing - Know what I mean Trevor?
[edit]
I am talking when changing the facing in the token menu]
When we change the facing of the token (with cone vision for example), it deselects the token so to reveal, we have to click on the token again and then reveal.
Seems like an extra step. Since we are already on that token, we should still be on that token ever after changing the facing - Know what I mean Trevor?
[edit]
I am talking when changing the facing in the token menu]