Ahh, yes, we just switched to mumble.. Good to know.. Next game session, I'll have everyone turn off the overlay...Daeger wrote:Are you using Mumble, by chance? The overlay can make it do odd things.
MapTool 1.3 Bugfix Build 69
Moderators: dorpond, trevor, Azhrei, Craig
Re: MapTool 1.3 Bugfix Build 69
Re: MapTool 1.3 Bugfix Build 69
Also Rumble, see Natha's post above (http://forums.rptools.net/viewtopic.php ... 81#p157212). I only mention it because you didn't refer to it.Rumble wrote:They shouldn't see the statsheet at all. Interesting. I'll check it out.DeviantNull wrote:My players were able to view the MT statsheet info for properties that were set "owner visible only" when selecting unowned tokens.Rumble wrote:Please post any additional bugs you may find, of course! Unowned token selection is a sticky wicket.
Follow-up: I can't reproduce this problem - did you mean that they can see the owner-visible-only properties of the unowned token? I've tried this with a server and connected client and when I do the mouseover I don't see anything from the unowned token.
@lmarkus: I agree -- older tokens should still load. There was a token format change prior to b59 regarding token properties becoming case-insensitive that caused breakage, but loading one of his tokens into b59 and then saving it again fixes it?! All of the code from loading/saving tokens from b59 is still in there, so I need to investigate this more. Also, RPTroll (I think it was him) had issues with dragging a Lib: token to the map. His problem only occurred when dragging from the desktop and the work-around is "don't do that." Save the token somewhere that it is accessible from the Image Explorer and drag it from there. (Yes, it's the drag/drop code that I must have screwed up. It's on my todo look to look at it.)
- Full Bleed
- Demigod
- Posts: 4736
- Joined: Sun Feb 25, 2007 11:53 am
- Location: FL
Re: MapTool 1.3 Bugfix Build 69
In this case, it's throwing the error when coming from the image explorer.Azhrei wrote:Also, RPTroll (I think it was him) had issues with dragging a Lib: token to the map. His problem only occurred when dragging from the desktop and the work-around is "don't do that." Save the token somewhere that it is accessible from the Image Explorer and drag it from there. (Yes, it's the drag/drop code that I must have screwed up. It's on my todo look to look at it.)
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."
Re: MapTool 1.3 Bugfix Build 69
They can also add javaw.exe to the overlay's blacklist.Seeker wrote:Ahh, yes, we just switched to mumble.. Good to know.. Next game session, I'll have everyone turn off the overlay...Daeger wrote:Are you using Mumble, by chance? The overlay can make it do odd things.
I should also point out that it messes up Character Builder too (far worse in fact), and that too can be added to the black list.
- Full Bleed
- Demigod
- Posts: 4736
- Joined: Sun Feb 25, 2007 11:53 am
- Location: FL
Re: MapTool 1.3 Bugfix Build 69
So I changed a property value on a token to something that wasn't default. Then I ran a test on the token:
and... nothing. I thought it would reset the property to null (and therefore set it to the campaign property default.)
I also had a question about function case sensitivity. Some seem to be case sensitive (like resetProperty throws an error if the "P" isn't capitalized), and others aren't (like getstrprop). I know that UDF functions are case sensitive... but for some reason I didn't think other functions were, though I appear to be running into problems with others if I don't capitiliaze the right things. For example, try:
That adds everything to init. Capitalize the I in "initiative" and only adds PC's.
Code: Select all
[resetProperty(propertyname)]
I also had a question about function case sensitivity. Some seem to be case sensitive (like resetProperty throws an error if the "P" isn't capitalized), and others aren't (like getstrprop). I know that UDF functions are case sensitive... but for some reason I didn't think other functions were, though I appear to be running into problems with others if I don't capitiliaze the right things. For example, try:
Code: Select all
[h: addAllPCsToinitiative(0)]
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."
Re: MapTool 1.3 Bugfix Build 69
Full Bleed wrote:So I changed a property value on a token to something that wasn't default. Then I ran a test on the token:
and... nothing. I thought it would reset the property to null (and therefore set it to the campaign property default.)Code: Select all
[resetProperty(propertyname)]
I also had a question about function case sensitivity. Some seem to be case sensitive (like resetProperty throws an error if the "P" isn't capitalized), and others aren't (like getstrprop). I know that UDF functions are case sensitive... but for some reason I didn't think other functions were, though I appear to be running into problems with others if I don't capitiliaze the right things. For example, try:
That adds everything to init. Capitalize the I in "initiative" and only adds PC's.Code: Select all
[h: addAllPCsToinitiative(0)]
Functions should all be case sensitive, only variables are case insensitive. Any that accept case insensitive versions are anomalies, any that do anything different based on case are bad bugs
- Full Bleed
- Demigod
- Posts: 4736
- Joined: Sun Feb 25, 2007 11:53 am
- Location: FL
Re: MapTool 1.3 Bugfix Build 69
Ok. Thanks for the info. I'm in the process of going through my framework and fixing the cases on everything. Any idea what I'm doing wrong with resetProperty?Craig wrote:Functions should all be case sensitive, only variables are case insensitive. Any that accept case insensitive versions are anomalies, any that do anything different based on case are bad bugs
PS: Just off the top of my head, listAppend and listContains also work with all lower case.
PSS: Should "strformat", "strfind", "countsuccess" be "strFormat", "strFind", and "countSuccess" respectively?
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."
Re: MapTool 1.3 Bugfix Build 69
Gotcha. As mentioned, I could not reproduce the behavior DeviantNull observed (DN, if you're reading, can you send / post the campaign this is happening in?)Azhrei wrote: Also Rumble, see Natha's post above (http://forums.rptools.net/viewtopic.php ... 81#p157212). I only mention it because you didn't refer to it.
With regard to Natha's issue, IIRC I've seen that kind of thing since b63 (in face, in the game I'm a player in - which until this past week used b63 - I frequently ran into that issue when clicking on other tokens but my own). I'm not trying to be defensive or anything, but I'm not sure that's a side-effect of unowned token selection. I will do some experiments.
Edit: hm, I appear to be incorrect. I know I saw similar behavior in b63 but the circumstances are different. It turns out that it would go blank when selecting any unowned token that has sight (NPC or PC; it's just that NPCs usually don't have sight). I'll see what I can do!
Okay...I'm not sure what the best approach is here. I found where this is triggered and edited it so that if the unowned token is a PC, you'll get that PC's individual view (rather than having everything disappear, which it's doing now). However, if you have an NPC with sight, and you select it, everything still disappears. What behavior should this have?
With individual views, I assume that if a fellow unowned PC token is beyond a wall from you, and you try to see what he sees his view, you should not see anything. In other words, this is working as expected - you can't see what unowned tokens see - but you couldn't previously find that out since you couldn't previously select an unowned token.
- silversonic
- Cave Troll
- Posts: 59
- Joined: Thu Oct 15, 2009 6:42 pm
- Location: Cleveland, OH
Re: MapTool 1.3 Bugfix Build 69
Hey Azhrei, was that error log I posted helpful?Azhrei wrote: @lmarkus: I agree -- older tokens should still load. There was a token format change prior to b59 regarding token properties becoming case-insensitive that caused breakage, but loading one of his tokens into b59 and then saving it again fixes it?! All of the code from loading/saving tokens from b59 is still in there, so I need to investigate this more. Also, RPTroll (I think it was him) had issues with dragging a Lib: token to the map. His problem only occurred when dragging from the desktop and the work-around is "don't do that." Save the token somewhere that it is accessible from the Image Explorer and drag it from there. (Yes, it's the drag/drop code that I must have screwed up. It's on my todo look to look at it.)
-Devin
Re: MapTool 1.3 Bugfix Build 69
I'm sorry i did'nt make the dmg file. I had some problem in my life so i had not time to do this. next time i will make it as soon as i can. Azhrei made this anyway, so thank you Azhr.
La nuova Era - Sito italiano dedicato a MapTool e D&D 4th edition.
Gringoire's FrameWork Il primo e unico FrameWork completamente italiano, sviluppato da un italiano.
Gringoire's FrameWork Il primo e unico FrameWork completamente italiano, sviluppato da un italiano.
Re: MapTool 1.3 Bugfix Build 69
Well that's a bad sign. I didn't think the desktop drag/drop used the same code as the Image Explorer d/d. If it does then it's much more important to get it fixed. My plan will be to roll back to the b68 implementation until I get some "quality time" with the code. I have narrowed the problem down to a particular area of the code, so I'm getting closer.FullBleed wrote:In this case, it's throwing the error when coming from the image explorer.
Sorry, I've been busy and haven't looked at yours yet. I still have three campaigns and two tokens that exhibit issues also. I'm going to try to work on those Friday night and Saturday so that I can get a build out Saturday night. But I'm getting on a plane Sunday and that may cause changes in priorities this weekend.silversonic wrote:Hey Azhrei, was that error log I posted helpful?
Actually it was provided by another forum user (don't remember who; the name started with "m" though ).Gringoire wrote:I'm sorry i did'nt make the dmg file. I had some problem in my life so i had not time to do this. next time i will make it as soon as i can. Azhrei made this anyway, so thank you Azhr.
Re: MapTool 1.3 Bugfix Build 69
Thanks for looking into it and explaining.Rumble wrote: With individual views, I assume that if a fellow unowned PC token is beyond a wall from you, and you try to see what he sees his view, you should not see anything. In other words, this is working as expected - you can't see what unowned tokens see - but you couldn't previously find that out since you couldn't previously select an unowned token.
IMHO, with "individual views" turned on, a player should never see what a unowned token can see, PC or NPC, sight or no sight.
- Full Bleed
- Demigod
- Posts: 4736
- Joined: Sun Feb 25, 2007 11:53 am
- Location: FL
Re: MapTool 1.3 Bugfix Build 69
I just took a look at unowned token selection and had a couple questions:
1) Are you only supposed to be able to select another token with the shift-key held down while you have yourself selected? It's disconcerting when the screen goes blank when you click on another token. It kind of pulls you out of the game. Can this be stopped from happening if you have a token impersonated so that it assumes you want to see things from the impersonated token's view (*if* you're a player)? I was hoping that once you had your own token impersonated all a player would have to do is click on an unowned token and run a macro against it. Being forced to use the keyboard to select a target a little clunky, imo.
2) Are you using green for other selections? I think you are, but for us color-blind people it's very difficult to distinguish (especially because you're using the same luminosity.) I would much prefer blue or yellow (or be given a choice.)
I'm guessing it's not a b69 problem, but can someone explain how resetProperty is supposed to work? As mentioned above, I can't get it to work like I thought it would.
1) Are you only supposed to be able to select another token with the shift-key held down while you have yourself selected? It's disconcerting when the screen goes blank when you click on another token. It kind of pulls you out of the game. Can this be stopped from happening if you have a token impersonated so that it assumes you want to see things from the impersonated token's view (*if* you're a player)? I was hoping that once you had your own token impersonated all a player would have to do is click on an unowned token and run a macro against it. Being forced to use the keyboard to select a target a little clunky, imo.
2) Are you using green for other selections? I think you are, but for us color-blind people it's very difficult to distinguish (especially because you're using the same luminosity.) I would much prefer blue or yellow (or be given a choice.)
I'm guessing it's not a b69 problem, but can someone explain how resetProperty is supposed to work? As mentioned above, I can't get it to work like I thought it would.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."
- Full Bleed
- Demigod
- Posts: 4736
- Joined: Sun Feb 25, 2007 11:53 am
- Location: FL
Re: MapTool 1.3 Bugfix Build 69
I think you and Rumble are misunderstanding one another. This is not how things are working for me. It only seems to work like that when Vision is "Off". Clicking on a non-owned PC or non-owned NPC should produce the same results (a soft-fog screen without *any* tokens or objects.)Natha wrote:On a map with active vision (day), we had several player tokens (each one with sight activated) and a bunch of NPC tokens (witthout vision).
The players could not interact with the NPC except click/select the tokens. Which is good.
When a player clicks anywhere on the map but not on a token : they can see everything (background + all the visible tokens).
When a player clicks on a NPC token, his view doesn't change : he still can see everything.
But when a player clicks/selects another player token, which he doesn't own, he can see anything : all the tokens disappears, and the background is "soft FOGed".
It seems kinda strange to me that clicking on a non owned PC hide everything but not on non owned NPC ?
Though, as mentioned above, I wish MT would assume that players who have their token's impersonated always want to see from them, regardless of what's selected now that they can select other tokens and lose view of the map.
I actually thought selecting NPC's and un-owned PC's would work like it does when vision is off (so players wouldn't have to use shift to maintain a selection on their own tokens so that they can see properly.) What's happening, apparently, is that when you select a token while individual views is on, they are selected, but you just can't see anything any more!
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."
Re: MapTool 1.3 Bugfix Build 69
That's what I tried to described.Full Bleed wrote: What's happening, apparently, is that when you select a token while individual views is on, they are selected, but you just can't see anything any more!
Except that it occured only when a player selected a unowned PC token (with sight), NOT when selecting a NPC (without sight).
And that's this difference in behaviour that seems strange to me.
IMHO, with individual views on, a player should see the same thing when selecting a unowned token (PC or NPC) : nothing.