MapTool 1.3 Final, patch04 (build 87)

[loogie]

wow. nice to see things are still alive and well! i've been out of the rp world for far too long, but i'm looking to get back in.. I'm going to have to try to play around with the latest maptool releases that's for sure!

Great work guys

[JML]

Related to the frame issue. One of my players on a MAC kept having his new windows appear in the upper left corner, but the top bar was above the screen. So he couldn't move it or close it. I'm not a Mac person so I couldn't give him advice on this, but having new frames appear centered the first time like dialogs would resolve that in any case.

Anyone have any advice on how to get past this on the mac?

I haven't seen that. I have had frames appear in the upper left but the title bar on the window was always accessible so it could be dragged into place. And all frames should be appearing centered over the MapTool window in b88+ (already in SVN). In addition, dorpond found a problem with the token editor dialog popping up off the top of the screen when the MapTool window was tiny and up at the top -- the function for centering the dialog wasn't taking into account a negative (x,y) coordinate (it does now).

I'm having the issue aliasmask was talking of on my Mac. Glad to know it will be solved, but should you need a test I'd be glad to help.

[username]

Here is a patch for the conic vision problem referenced in http://forums.rptools.net/viewtopic.php ... &start=120 on page 8.

The problem was that "footprint.getBounds()" does not yield a rectangle at (0,0).

[Azhrei]

Hm, interesting. I've committed this as SVN 5843.

[Lee]

I saw the history notes on SVN 5844. Perhaps, if given specific use cases to start from, we could help hunt the error down?

[Azhrei]

Neofax just posted about it in another thread. Most of the cases where this occurs are known, but he had a situation where Win7 brought up that message so he let MT sit and when he went back an hour later and saved, it worked fine. ???

Maybe some kind of interaction with Win7's auto-snapshot feature of the filesystem? Seems pretty unlikely though, as that type of thing it typically designed to be transparent to user file access.

You might need to use Google instead of the forum search, but searching for "create data directory" and/or "{0}" should probably find a half-dozen or so threads... (Sorry, gotta run.)

[Lee]

Oh I see. So basically, it is known where in the MT code this exception springs from and the actual problem is specifically for the scenario neofax reported? Would setting the .maptool directory to read-only, and setting MT's autosave to the shortest interval trigger the error, you think?

[Azhrei]

Oh I see. So basically, it is known where in the MT code this exception springs from

Yep.

... and the actual problem is specifically for the scenario neofax reported?

No, he just had an instance of it that was unexplained (and still is).

Would setting the .maptool directory to read-only, and setting MT's autosave to the shortest interval trigger the error, you think?

Nope. There are times when it happens and there is nothing to explain it!? It's quite clear in the code that the error is the result of path.exists() being false, and then after calling path.mkdirs() it's STILL false?! That shouldn't be possible, at least not without something happening to the underlying filesystem outside of MT's control. Like, changing the permissions as you describe or renaming .maptool/ while the application is still running.

So what should we do about? In most cases, there's nothing we can do about it. It indicates a change to a directory structure that MT is relying on. But since it's not reporting the directory properly (sigh) we can't really know which code is calling this one and triggering the exception. Hopefully we will the next time it happens.

(You can't just set a breakpoint and examine where it's called from because it's a low-level utility function that can be called from A LOT of places, unfortunately.)

[aliasmask]

Ohhh, that is a bug... http://forums.rptools.net/viewtopic.php?f=3&t=19171

Well, at least Wiki: setDrawOrder() gives me the following error:

Undefined function: setDrawOrder

But Wiki: setTokenDrawOrder() works just fine.

[Lee]

Oh I see. So basically, it is known where in the MT code this exception springs from

Yep.

... and the actual problem is specifically for the scenario neofax reported?

No, he just had an instance of it that was unexplained (and still is).

Would setting the .maptool directory to read-only, and setting MT's autosave to the shortest interval trigger the error, you think?

Nope. There are times when it happens and there is nothing to explain it!? It's quite clear in the code that the error is the result of path.exists() being false, and then after calling path.mkdirs() it's STILL false?! That shouldn't be possible, at least not without something happening to the underlying filesystem outside of MT's control. Like, changing the permissions as you describe or renaming .maptool/ while the application is still running.

So what should we do about? In most cases, there's nothing we can do about it. It indicates a change to a directory structure that MT is relying on. But since it's not reporting the directory properly (sigh) we can't really know which code is calling this one and triggering the exception. Hopefully we will the next time it happens.

(You can't just set a breakpoint and examine where it's called from because it's a low-level utility function that can be called from A LOT of places, unfortunately.)

Ah. Thanks. That was enlightening. Perhaps it has something to do with the .maptool directory's location? With it being the repository for multiple applications, maybe that causes rare file system problems. Just speculating here, but if it were to be located within the MT install directory itself? It would then be fully portable, not that I don't see that MT generates the .maptool directory when it's not present

On a different topic, can something be done with regard to macroLink() (and maybe its cousin functions)? I found that setting the output parameter to "all" generates an extraneous line which is blank (with the token/macro context name, of course) when the "h:" roll option is used with the broadcast. It's not a big deal really, I could do with "none" and work around it. I was just wondering why it's a special case that trumps the hidden roll.

[Azhrei]

Ohhh, that is a bug... http://forums.rptools.net/viewtopic.php?f=3&t=19171

Not sure what you're referring to since that thread ends up deciding that there is no bug.

In any case, I copied the current text of the setDrawOrder() wiki page over to setTokenDrawOrder() so the doc is in the right place.

Ah. Thanks. That was enlightening.

We aim to please...

Perhaps it has something to do with the .maptool directory's location? With it being the repository for multiple applications, maybe that causes rare file system problems. Just speculating here, but if it were to be located within the MT install directory itself? It would then be fully portable, not that I don't see that MT generates the .maptool directory when it's not present

"Multiple applications?" It's not, just MapTool. And I suppose if you had different builds of MT all running at the same time that they could clash with each other when creating files under the assetcache directory, but I don't think that's what this error is about.

If it were in the same directory as MT, where would the Java Web Start version be placed? And putting it in the same directory is nonsense since there is no way in Java to determine what the current directory is (as Java is designed to be cross-platform and some platforms may not even have a concept of "current directory"). Silly, to my mind, but there it is regardless.

On a different topic, can something be done with regard to macroLink() (and maybe its cousin functions)? I found that setting the output parameter to "all" generates an extraneous line which is blank (with the token/macro context name, of course) when the "h:" roll option is used with the broadcast. It's not a big deal really, I could do with "none" and work around it. I was just wondering why it's a special case that trumps the hidden roll.

I doubt it. Anything with a not unreasonable workaround is going to need to wait. Unless it's very simple and a patch is contributed (mainly I've got too much other stuff to go chasing after things that aren't high priority).

[aliasmask]

Ohhh, that is a bug... http://forums.rptools.net/viewtopic.php?f=3&t=19171

Not sure what you're referring to since that thread ends up deciding that there is no bug.

I think I mis-read the original problem by the OP in the link. I had no problems with using setTokenDrawOrder, but setDrawOrder doesn't exist as a function eventhough it's in the wiki. I'm not sure how he got an "return an invalid expression." because it clearly tells me it's an invalid function call. That's all. So, other than the function setDrawOrder not really existing anymore, there is no bug.

[Lee]

Ohhh, that is a bug... http://forums.rptools.net/viewtopic.php?f=3&t=19171

Not sure what you're referring to since that thread ends up deciding that there is no bug.

In any case, I copied the current text of the setDrawOrder() wiki page over to setTokenDrawOrder() so the doc is in the right place.

Ah. Thanks. That was enlightening.

We aim to please...

Perhaps it has something to do with the .maptool directory's location? With it being the repository for multiple applications, maybe that causes rare file system problems. Just speculating here, but if it were to be located within the MT install directory itself? It would then be fully portable, not that I don't see that MT generates the .maptool directory when it's not present

"Multiple applications?" It's not, just MapTool. And I suppose if you had different builds of MT all running at the same time that they could clash with each other when creating files under the assetcache directory, but I don't think that's what this error is about.

If it were in the same directory as MT, where would the Java Web Start version be placed? And putting it in the same directory is nonsense since there is no way in Java to determine what the current directory is (as Java is designed to be cross-platform and some platforms may not even have a concept of "current directory"). Silly, to my mind, but there it is regardless.

On a different topic, can something be done with regard to macroLink() (and maybe its cousin functions)? I found that setting the output parameter to "all" generates an extraneous line which is blank (with the token/macro context name, of course) when the "h:" roll option is used with the broadcast. It's not a big deal really, I could do with "none" and work around it. I was just wondering why it's a special case that trumps the hidden roll.

I doubt it. Anything with a not unreasonable workaround is going to need to wait. Unless it's very simple and a patch is contributed (mainly I've got too much other stuff to go chasing after things that aren't high priority).

Oh I was just thinking that it might somehow have clashed with some other non-MT application concurrently using the same Windows User directory, and that an exclusive location for the asset cache would probably isolate it from such conflicts. You're right though that things like that are far-fetched.

My mistake about the suggestion to fully contain MT in one directory. I made the error of only thinking of the MT flavor I use and lost the big picture that MT is a cross-platform VTT solution with a fully capable web version. I also didn't take into consideration that the current architecture for MT is like that for a reason. Sorry hehe. With regard to macroLink, I do understand. It was more about satisfying a curiosity rather than wanting something chased down. Thanks.

[Azhrei]

It was more about satisfying a curiosity rather than wanting something chased down. Thanks.

No problem. If you don't ask the question you'll never get the answer.

[Lee]

I was thinking to modify the getTokens() and getTokenNames() logic, specifically the setStates and unsetStates parameters . Currently, setStates uses logical 'and' it seems, where all states passed must be set to true on the token or it gets removed from the returned list, while unsetStates uses logical 'or'. I think it's beneficial to have one more parameter like setStates, only this time it allows inclusion in the list if any (and not all) of the set states are present. I encountered a coding scenario where I needed to look for tokens that didn't necessarily have all states present, specifically an "enemy" token targeting "ally" and "neutral" state tokens. Understandably, neither "ally" or "neutral" tokens should possess each others' state name so I had to make another state to stand in as a common trait in order the code using setState work. I've tooled around to find a smart and existing way to accomplish what I want and I'm convinced the one I made is the best that can be done.

To give insight as to how my targeting logic works, I:

1. check for the current token's combatant type (e.g. "ally", "enemy",""neutral")
2. based on the type, it sets a corresponding array for states. ally = '["enemy"], enemy = '["ally"," neutral"]', "neutral" = "[]"
3. I then have a switch for effect type, whether it is harmful or beneficial. If it is harmful, I use setStates; and if it is beneficial, I use unsetStates. Since, setStates will return a blank list if the current token is an enemy (unless both ally and neutral tokens have both ally and neutral states), I had to create another state that ally and neutral tokens can share making the state array for enemy = '["sharedState"]' (which I think is inelegant).

If there was another parameter, like say setState (since singular) / setSingleState, it'd be more flexible for situations like these like unsetStates already is. I'd be happy to try and make a patch if I could be pointed to where in the code is the actual source for getTokens and getTokenNames While, I could find it myself, I must confess that I just don't have the time to sift through the MT code XD