RPTools.net

Discussion and Support

Skip to content

It is currently Thu May 25, 2017 10:37 pm 






Reply to topic  [ 91 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next

Previous topic | Next topic 

  Print view

Author Message
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12065
Location: Tampa, FL
 Post subject: Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)
PostPosted: Mon Jan 17, 2011 7:20 pm 
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:
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);
    }
}
 


Top
 Profile  
 
User avatar  Offline
Deity
 
Joined: Tue Sep 11, 2007 6:31 pm
Posts: 5401
 Post subject: Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)
PostPosted: Mon Jan 17, 2011 7:46 pm 
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:
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.

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


Top
 Profile  
 
User avatar  Offline
Great Wyrm
 
Joined: Fri Mar 28, 2008 11:30 pm
Posts: 1864
Location: Layfayette Hill, PA
 Post subject: Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)
PostPosted: Mon Jan 17, 2011 7:53 pm 
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.

_________________
D&D3.5 / Pathfinder Framework


Top
 Profile  
 
User avatar  Offline
Deity
 
Joined: Fri May 12, 2006 7:56 pm
Posts: 6300
Location: Las Cruces, NM
 Post subject: Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)
PostPosted: Tue Jan 18, 2011 9:25 am 
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.

_________________
Call me, Hex Boy.

Visit http://www.darkisle.com for photos of castles, cairns, standing stones, and other ancient sites in the British Isles.


Top
 Profile  
 
User avatar  Offline
Deity
 
Joined: Tue Sep 11, 2007 6:31 pm
Posts: 5401
 Post subject: Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)
PostPosted: Tue Jan 18, 2011 9:29 am 
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:
MapTool.serverCommand().updateExposedAreaMeta(zone.getId(), token.getId(), meta);


SHOULD be:

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

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


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12065
Location: Tampa, FL
 Post subject: Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)
PostPosted: Tue Jan 18, 2011 2:31 pm 
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.


Top
 Profile  
 
User avatar  Offline
RPTools Team
 
Joined: Thu Jun 01, 2006 1:05 pm
Posts: 5522
Location: Buffalo, NY
 Post subject: Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)
PostPosted: Tue Jan 18, 2011 3:52 pm 
OK, now that all the technical stuff is hashed out, what is that fixing Azhrei, so I know what to test? :)

_________________
How to use my bundled artwork (MT1.3B60+): http://forums.rptools.net/viewtopic.php?f=8&t=11759
Facebook: http://fb.com/billhartfitness


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12065
Location: Tampa, FL
 Post subject: Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)
PostPosted: Tue Jan 18, 2011 5:41 pm 
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).


Top
 Profile  
 
User avatar  Offline
Kobold
 
Joined: Thu Mar 18, 2010 3:54 pm
Posts: 24
 Post subject: Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)
PostPosted: Thu Jan 20, 2011 2:12 am 
Quote:
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.


File comment: Build 81 current...uh oh...
Build 81.png
Build 81.png [ 121.44 KiB | Viewed 1625 times ]
File comment: Build 66, the way it's supposed to be.
Build 66.png
Build 66.png [ 195.1 KiB | Viewed 1625 times ]
Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12065
Location: Tampa, FL
 Post subject: Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)
PostPosted: Thu Jan 20, 2011 2:35 am 
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.


Top
 Profile  
 
User avatar  Offline
Deity
 
Joined: Tue Nov 10, 2009 6:11 pm
Posts: 7701
Location: Bay Area
 Post subject: Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)
PostPosted: Thu Jan 20, 2011 4:01 am 
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.

_________________
Downloads:


Top
 Profile  
 
User avatar  Offline
Cave Troll
 
Joined: Thu Oct 15, 2009 5:42 pm
Posts: 59
Location: Cleveland, OH
 Post subject: Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)
PostPosted: Thu Jan 20, 2011 7:12 am 
warpoet wrote:
Quote:
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.

_________________
I don't want the world, I just want your half.


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12065
Location: Tampa, FL
 Post subject: Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)
PostPosted: Thu Jan 20, 2011 1:13 pm 
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?


Top
 Profile  
 
User avatar  Offline
Deity
 
Joined: Tue Nov 10, 2009 6:11 pm
Posts: 7701
Location: Bay Area
 Post subject: Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)
PostPosted: Thu Jan 20, 2011 2:36 pm 
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.

_________________
Downloads:


Top
 Profile  
 
User avatar  Offline
Kobold
 
Joined: Thu Mar 18, 2010 3:54 pm
Posts: 24
 Post subject: Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)
PostPosted: Tue Jan 25, 2011 1:15 pm 
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!


Top
 Profile  
 
Display posts from previous:  Sort by  
Reply to topic  [ 91 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:

Who is online

In total there is 1 user online :: 0 registered, 0 hidden and 1 guest (based on users active over the past 5 minutes)
Most users ever online was 243 on Sun Nov 04, 2012 6:14 am

Users browsing this forum: No registered users and 1 guest





Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group

Style based on Andreas08 by Andreas Viklund

Style by Elizabeth Shulman