Page 6 of 7

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Posted: Mon Jan 17, 2011 7:20 pm
by Azhrei
jfrazierjr wrote:Azhrei, it looks like when you refactored(I think you did...I don't remember making this change... of course... the past few weeks I have had mush brain) AppActions.PASTE_TOKENS that the check for duplicate exposedAreaGUID makes a new GUID, but does not add that new GUID to the zone. Perhaps that is the issue??? I don't see how a restart of the server would help that though. Even still, any update to the FOW should add the new GUID to the zone.... :?
I don't remember doing anything in that area, and the comments don't look like my kind of writing... :|

I've added some code to ensure the ExposedAreaMetaData object is in the zone and that the exposed area history is updated (I just copied this code from elsewhere). It includes the call to the ServerHandler, which is probably an important part of it. Here's what I have now. I'll play with it a bit.

Code: Select all

for (Token tok : allTokens) {
    if (tok.getExposedAreaGUID().equals(token.getExposedAreaGUID())) {
        GUID guid = new GUID();
        token.setExposedAreaGUID(guid);
        ExposedAreaMetaData meta = zone.getExposedAreaMetaData(guid);
        // 'meta' references the object already stored in the zone's HashMap (that was created if necessary).
        meta.addToExposedAreaHistory(new Area(meta.getExposedAreaHistory()));
        MapTool.serverCommand().updateExposedAreaMeta(zone.getId(), token.getId(), meta);
    }
} 

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Posted: Mon Jan 17, 2011 7:46 pm
by jfrazierjr
Azhrei wrote:
jfrazierjr wrote:Azhrei, it looks like when you refactored(I think you did...I don't remember making this change... of course... the past few weeks I have had mush brain) AppActions.PASTE_TOKENS that the check for duplicate exposedAreaGUID makes a new GUID, but does not add that new GUID to the zone. Perhaps that is the issue??? I don't see how a restart of the server would help that though. Even still, any update to the FOW should add the new GUID to the zone.... :?
I don't remember doing anything in that area, and the comments don't look like my kind of writing... :|

I've added some code to ensure the ExposedAreaMetaData object is in the zone and that the exposed area history is updated (I just copied this code from elsewhere). It includes the call to the ServerHandler, which is probably an important part of it. Here's what I have now. I'll play with it a bit.

Code: Select all

for (Token tok : allTokens) {
    if (tok.getExposedAreaGUID().equals(token.getExposedAreaGUID())) {
        GUID guid = new GUID();
        token.setExposedAreaGUID(guid);
        ExposedAreaMetaData meta = zone.getExposedAreaMetaData(guid);
        // 'meta' references the object already stored in the zone's HashMap (that was created if necessary).
        meta.addToExposedAreaHistory(new Area(meta.getExposedAreaHistory()));
        MapTool.serverCommand().updateExposedAreaMeta(zone.getId(), token.getId(), meta);
    }
} 
As I said.... I have had mush brain for the past few weeks. However, that last line is broken. It needs to set the token.getExposedAreaGUID into the zone, not the token id. Currently, the tokenId changes on a copy/paste and is almost always guaranteed to be different on a token per map(with the exception of moveToMap functions which copy without creating a new token). However, the exposedareaGUID will "stick" with the token no matter how many maps it is moved to/from as long as the target paste map does not already have the token with that GUID on that map.

Of course, since the issue is not easily repeatable, that may not be the only problem.

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Posted: Mon Jan 17, 2011 7:53 pm
by lmarkus001
jfrazierjr wrote: Well... there are several possibilities here. I assume you checked them, but would like to verify. Most important is token vision. No vision of course means no reveal. Second is ownership. Since individual FOW is based on Individual Views, if the player does not own the token in question, then they won't see from that token's point of view. My best guess here is that the issue had to do with ownership. Another question (this may have nothing to do with it, but it has been an issue in the past with macros), were the players names the same as the token names they controlled?
Token Vision: Yes these are all very long played tokens and they all have vision (and my campaign properties let even those with Normal vision expose a tiny circle at their location if they have no light source). There were active light sources on several of the tokens.

Ownership: Yes they all own their tokens. There were some multiple owners tokens, one worked fine, the other did not (the ownerships on them were like George and george so they were not cross player owned, although I do some of that, I just was not doing it on Friday).

Player vs Token Name: All player and token names were different.

One of the players closed MapTools and reloaded to see if that would help and it did not.

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Posted: Tue Jan 18, 2011 9:25 am
by Phergus
jfrazierjr wrote:Phergus, perhaps you could take a look into the code. The way it works is that on a paste, it checks to see if the exposedAreaGUID is set on the token AND is not duplicated on the map already. If already on the map, a new exposedAreaGUID is created for that token. Then, any exposed area's area added to the zone in a map<GUID,ExposedAreaMeta> and this is checked for adding/removing any exposed area regardless of how.
I'm traveling for work till Friday but will take a look when I get back.
jfrazierjr wrote:Azhrei, it looks like when you refactored(I think you did...I don't remember making this change... of course... the past few weeks I have had mush brain) AppActions.PASTE_TOKENS that the check for duplicate exposedAreaGUID makes a new GUID, but does not add that new GUID to the zone. Perhaps that is the issue??? I don't see how a restart of the server would help that though.
Wasn't a server restart in my case. Just had the player disconnect and then reconnect. When they reconnected the token was already on the map thought I don't know why that would matter.

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Posted: Tue Jan 18, 2011 9:29 am
by jfrazierjr
Phergus wrote:
jfrazierjr wrote:Azhrei, it looks like when you refactored(I think you did...I don't remember making this change... of course... the past few weeks I have had mush brain) AppActions.PASTE_TOKENS that the check for duplicate exposedAreaGUID makes a new GUID, but does not add that new GUID to the zone. Perhaps that is the issue??? I don't see how a restart of the server would help that though.
Wasn't a server restart in my case. Just had the player disconnect and then reconnect. When they reconnected the token was already on the map thought I don't know why that would matter.
Yes! In which case they would get the updated zone since the call:

Code: Select all

MapTool.serverCommand().updateExposedAreaMeta(zone.getId(), token.getId(), meta);
SHOULD be:

Code: Select all

MapTool.serverCommand().updateExposedAreaMeta(zone.getId(), token.getExposedAreaGUID(), meta);

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Posted: Tue Jan 18, 2011 2:31 pm
by Azhrei
jfrazierjr wrote:However, that last line is broken. It needs to set the token.getExposedAreaGUID into the zone, not the token id.
Okay, thanks. That's why I posted it -- I couldn't tell from the method signature whether it was supposed to be the exposedGUID or the tokenID. I'll make that change and check it in to SVN.

Edit: Revision 5588.

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Posted: Tue Jan 18, 2011 3:52 pm
by dorpond
OK, now that all the technical stuff is hashed out, what is that fixing Azhrei, so I know what to test? :)

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Posted: Tue Jan 18, 2011 5:41 pm
by Azhrei
Well, I suppose you can go through the ChangeLog on the wiki. I just went through the commit history at SourceForge and updated the ChangeLog. It's gotten pretty large!

Probably the most complicated section is the part about fog-of-war not being cleared properly for tokens. We discussed that in detail on the devteam mailing list. Basically, some fog is cleared when it apparently shouldn't be (?) and then there's no way to put it back as GM.

I still have on my list: movement distances (1/12@18:40), offset when pasting tokens (1/16@12:27), and resize/rotate (1/16@12:27).

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Posted: Thu Jan 20, 2011 2:12 am
by warpoet
Please define what you mean by "properties pane"? Do you mean the Campaign Properties dialog on the Property tab? Or the token editor dialog and its Properties tab? Or some place else?

It sounds like this is a bug that should be fixed prior to 1.3 Final.
My apologies for being late in replying; I know it's probably too late before the final, but I might as well describe this issue as best as I can. If you are running a for-mac build of maptools after roughly version 66 or so, and you double click a token to open up the edit token dialogue, then select the properties tab, and then resize or maximize the window, the properties "panel"/window-within-a-window will not resize or maximize with the window that contains it. It will stay its default size--that is, the size it is before you try to resize the edit tokens window/dialogue/whatever the accurate term might be. With build 66 or so and back, the property panel resizes as it should.

The attached screenshots will hopefully make all this excess verbiage unnecessary.

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Posted: Thu Jan 20, 2011 2:35 am
by Azhrei
Okay, thanks.

(I really didn't need to have my entire screen taken up with those shots though! LOL!)

This should be pretty easy to fix.

Edit: Okay, this is fixed but I may need to break it again later. The fix is Java6-only and I'd like to keep MT as Java5-compatible as possible for 1.3 Final. If I can find an easy way to implement the fix in Java5, I'll do so. If not, I may need to revert this fix back out.

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Posted: Thu Jan 20, 2011 4:01 am
by aliasmask
Can we do something about the frame focus problem when using a form submit? If I click a macroLink, a hidden frame becomes visible if drawn to. If I submit a form it does not.*

*Only if frame is attached to form frame.

If too complicated to track down or fix, a possible fix would be to have a function that focuses a frame, ie frameFocus(). That way the programmer can force a frame's focus. I'm sure you already have an internal function for that.

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Posted: Thu Jan 20, 2011 7:12 am
by silversonic
warpoet wrote:
Please define what you mean by "properties pane"? Do you mean the Campaign Properties dialog on the Property tab? Or the token editor dialog and its Properties tab? Or some place else?

It sounds like this is a bug that should be fixed prior to 1.3 Final.
My apologies for being late in replying; I know it's probably too late before the final, but I might as well describe this issue as best as I can. If you are running a for-mac build of maptools after roughly version 66 or so, and you double click a token to open up the edit token dialogue, then select the properties tab, and then resize or maximize the window, the properties "panel"/window-within-a-window will not resize or maximize with the window that contains it. It will stay its default size--that is, the size it is before you try to resize the edit tokens window/dialogue/whatever the accurate term might be. With build 66 or so and back, the property panel resizes as it should.

The attached screenshots will hopefully make all this excess verbiage unnecessary.
Ahh, I see what you're talking about now with the screen shots.

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Posted: Thu Jan 20, 2011 1:13 pm
by Azhrei
aliasmask wrote:Can we do something about the frame focus problem when using a form submit? If I click a macroLink, a hidden frame becomes visible if drawn to. If I submit a form it does not.*

*Only if frame is attached to form frame.
I went back and read your dialog with Craig. Let me recap to see if I have this right.

Say I have three frames. Frame "A" is floating and visible on the screen (it contains the SUBMIT or Wiki: macroLink()). Frames "B" and "C" are stacked on top of each other, so only B's content is visible and C just shows the tab.

You're saying that everything works the way you want in that scenario (whether you use SUBMIT or macroLink), but if you drag frame A and dock/stack it with B and C, a SUBMIT that draws to frame C does not make C visible, but a macroLink that draws to the frame does?

You want both of them to make frame C visible unless the frame is set to autohide?

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Posted: Thu Jan 20, 2011 2:36 pm
by aliasmask
Azhrei wrote:
aliasmask wrote:Can we do something about the frame focus problem when using a form submit? If I click a macroLink, a hidden frame becomes visible if drawn to. If I submit a form it does not.*

*Only if frame is attached to form frame.
I went back and read your dialog with Craig. Let me recap to see if I have this right.

Say I have three frames. Frame "A" is floating and visible on the screen (it contains the SUBMIT or Wiki: macroLink()). Frames "B" and "C" are stacked on top of each other, so only B's content is visible and C just shows the tab.

You're saying that everything works the way you want in that scenario (whether you use SUBMIT or macroLink), but if you drag frame A and dock/stack it with B and C, a SUBMIT that draws to frame C does not make C visible, but a macroLink that draws to the frame does?

You want both of them to make frame C visible unless the frame is set to autohide?
Right.

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Posted: Tue Jan 25, 2011 1:15 pm
by warpoet
Azhrei wrote:Okay, thanks.

(I really didn't need to have my entire screen taken up with those shots though! LOL!)

This should be pretty easy to fix.

Edit: Okay, this is fixed but I may need to break it again later. The fix is Java6-only and I'd like to keep MT as Java5-compatible as possible for 1.3 Final. If I can find an easy way to implement the fix in Java5, I'll do so. If not, I may need to revert this fix back out.
Awesome. And my apologies for filling the screen--I didn't realize those screenshots would be so huge on the forum. I'll know not to do that in the future!