[fixed] mouse drag behavior for snapped-to-grid tokens
Moderators: dorpond, trevor, Azhrei
[fixed] mouse drag behavior for snapped-to-grid tokens
Mentioned by aliasMask, Bonewhite, and Phergus here, the behavior was caused by a small change to the formula for setting the positioning of the mouse pointer. My guess was that when the code was being improved for b87, this was changed by mistake as it looked very similar to other point translations found within the class.
The fix is included as part of a larger patch I'm still working on.
The fix is included as part of a larger patch I'm still working on.
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Re: [fixed] mouse drag behavior for snapped-to-grid tokens
Thanks. That bug was a real peeve.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: [fixed] mouse drag behavior for snapped-to-grid tokens
No problem. It was a peeve of mine as well. I wanted to ask though, since you were around here more at the time, if there was any discussion as to why it was changed in b87 (if it was deliberately changed that is) and if fixing it would break anything.
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Re: [fixed] mouse drag behavior for snapped-to-grid tokens
I'm pretty sure it wasn't deliberate. The same is true with the one time fix of being able to use setProperty on a lib token without worry of duplication. That somehow got reversed among the builds and was never really meant to be possible.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: [fixed] mouse drag behavior for snapped-to-grid tokens
That's good to hear. With regard to setProperty, from what I understand, setProperty still affects library tokens? If it is and the desired behavior is to bar the function from writing to a lib:token, I can put in a lockout and throw a message to the effect of "to save a property to a library token, use setLibProperty instead"
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Re: [fixed] mouse drag behavior for snapped-to-grid tokens
Well, I would like to write to a lib token during onCampaignLoad for various settings. We just don't want the duplicate lib token to happen if say the client is loading to a map without the lib token on it. What happens is if it is updated during onCampaignLoad and the client is on another map, then it'll create a duplicate lib token on the current map. Right now, I have a way of avoiding duplicates so it's fine for now. The issue isn't with using setProperty vs setLibProperty.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: [fixed] mouse drag behavior for snapped-to-grid tokens
aliasmask wrote:I'm pretty sure it wasn't deliberate. The same is true with the one time fix of being able to use setProperty on a lib token without worry of duplication. That somehow got reversed among the builds and was never really meant to be possible.
I've got the feeling I'm missing something here. The dup issue is as you describe. But what does that have to do with setproperty and setLibproperty? AFAIK I've never used setProperty to edit a lib:token. Or do you mean that if you use setPropery("Lib:..") that you will never create a dub? Which sounds obvious cause you HAVE to be on the same map to be able to do that, on the other hand I expect that setLibProperty won'g render an issue as well if you are on the same map.aliasmask wrote:Well, I would like to write to a lib token during onCampaignLoad for various settings. We just don't want the duplicate lib token to happen if say the client is loading to a map without the lib token on it. What happens is if it is updated during onCampaignLoad and the client is on another map, then it'll create a duplicate lib token on the current map. Right now, I have a way of avoiding duplicates so it's fine for now. The issue isn't with using setProperty vs setLibProperty.
GETTING STARTED WITH MAPTOOLS - TUTORIALS, DOCS, VIDEOS, TOOLS, ETC
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
Re: [fixed] mouse drag behavior for snapped-to-grid tokens
Without doing some weird stuff to delay the process of writing to the lib token, even with setLibProperty it's possible that the token will be duplicated on current map if load map isn't the same map as library map. It's a timing issue. I believe Trevor said not to do that because it's not supported, but we don't listen.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: [fixed] mouse drag behavior for snapped-to-grid tokens
I still think I'll lock out lib tokens from being affected by setProperty/getProperty. If a framework out there breaks, it shouldn't be hard to refactor; not with your RPEdit and N++ around.
As for the race condition, let me try out if setting the function to be invoked later if anything is happening on the queue, helps. If you could provide a test campaign to debug with, it'll be most helpful.
As for the race condition, let me try out if setting the function to be invoked later if anything is happening on the queue, helps. If you could provide a test campaign to debug with, it'll be most helpful.
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Re: [fixed] mouse drag behavior for snapped-to-grid tokens
Well, IRC the only write to lib OCL we do is to get the gm names. But I believe that eye or tiorthan are checking to see whether a function can be created for that or maybe it can be added to getInfo. When that happens there no longer need to be any writes to lib OCL.aliasmask wrote:Without doing some weird stuff to delay the process of writing to the lib token, even with setLibProperty it's possible that the token will be duplicated on current map if load map isn't the same map as library map. It's a timing issue. I believe Trevor said not to do that because it's not supported, but we don't listen.
GETTING STARTED WITH MAPTOOLS - TUTORIALS, DOCS, VIDEOS, TOOLS, ETC
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
Re: [fixed] mouse drag behavior for snapped-to-grid tokens
I agree with the approach, it may not be a simple refactor. If only the framework creator had to do it for their own framework, I agree no problem. But I for one (and probably many others) tweak frameworks and do not usually update unless we have to due to the headache involved. So there may be a lot mid-level users out there left with broken frameworks?Lee wrote:I still think I'll lock out lib tokens from being affected by setProperty/getProperty. If a framework out there breaks, it shouldn't be hard to refactor; not with your RPEdit and N++ around.
As for the race condition, let me try out if setting the function to be invoked later if anything is happening on the queue, helps. If you could provide a test campaign to debug with, it'll be most helpful.
Granted I have no idea how common set/get prop is used for lib functions and it may or may not be a huge deal. All I know is it would be a pain for me to have to do it myself.
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
Re: [fixed] mouse drag behavior for snapped-to-grid tokens
I'm making a test file to demonstrate the library token duplication and ran in to a different error, but it is still related to the timing I believe.
edit: Also, things like findToken don't work either and give the same error, btw. I'm thinking there is some load order where at this point the token is not accessible. But this is only when the server is loading. So, I'm guessing the file load process is different when loading while running a server.
Okay, this is weird. I get nothing but a blank screen if I have a new campaign with nothing on it and I start a server. Anyone else having this problem?
edit: Okay, figured out why that is. If the map is not player visible, then I get the black screen, eventhough I'm the GM. I'm unable to make it visible after starting server as well. I'll see if this was the problem with the above loading error.
edit: Apparently that was why I was getting the error. Back to creating my test file to demonstrate duplicate lib token creation. I'm such a retard. The last game I hosted, I hosted as a player .
This error occurs only when I'm starting a server. When loading the campaign, there is no error. I put a large map on the second map to invoke some load delay for test. I removed it for the upload since it doesn't seem to matter for this error.Error running onCampaignLoad on lib:test : java.lang.NullPointerException error executing expression gmNames = getLibProperty("gmNames",thisLib).
||| onCampaignLoad |||
Code: Select all
[H: thisLib = getMacroLocation()]
[H: gmNames = getLibProperty("gmNames",thisLib)]
[H: allPlayers = lower(getAllPlayerNames("json"))]
[H: playerName = lower(getPlayerName())]
[H, if(isGM()), code: {
[H, if(json.isEmpty(gmNames)), code: {
[H: setLibProperty("gmNames",json.append("",playerName),thisLib)]
};{
[H: gmNames = json.intersection(gmNames,allPlayers)]
[H: setLibProperty("gmNames",json.union(gmNames,json.append("",playerName)),thisLib)]
}]
};{
[H, if(json.contains(gmNames,playerName)): setLibProperty("gmNames",json.difference(gmNames,json.append("",playerName)),thisLib)]
}]
[dialog("GM Names"): {[R: getLibProperty("gmNames",thisLib)]}]
Okay, this is weird. I get nothing but a blank screen if I have a new campaign with nothing on it and I start a server. Anyone else having this problem?
edit: Okay, figured out why that is. If the map is not player visible, then I get the black screen, eventhough I'm the GM. I'm unable to make it visible after starting server as well. I'll see if this was the problem with the above loading error.
edit: Apparently that was why I was getting the error. Back to creating my test file to demonstrate duplicate lib token creation. I'm such a retard. The last game I hosted, I hosted as a player .
- Attachments
-
- test duplicate lib.cmpgn
- (45.71 KiB) Downloaded 199 times
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: [fixed] mouse drag behavior for snapped-to-grid tokens
Okay, I can't seem to duplicate the problem. It may be because I have a better/faster machine, or because of a newer java version?!? I don't really know. But I'll test it out on my players next game and see if the lib token duplicates.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: [fixed] mouse drag behavior for snapped-to-grid tokens
I tried the test campaign and wasn't able to replicate as well. I'll wait on that update then.
I'd be willing to do community support to fix any such framework breakages. If not, it'd be a good opportunity to showcase and send people to those editing tools everyone should be using from day 1.JamzTheMan wrote: I agree with the approach, it may not be a simple refactor. If only the framework creator had to do it for their own framework, I agree no problem. But I for one (and probably many others) tweak frameworks and do not usually update unless we have to due to the headache involved. So there may be a lot mid-level users out there left with broken frameworks?
Granted I have no idea how common set/get prop is used for lib functions and it may or may not be a huge deal. All I know is it would be a pain for me to have to do it myself.
Thanks for the info. The function for that has already been made. It's just part of a larger piece of work so I haven't released it yet.wolph42 wrote:Well, IRC the only write to lib OCL we do is to get the gm names. But I believe that eye or tiorthan are checking to see whether a function can be created for that or maybe it can be added to getInfo. When that happens there no longer need to be any writes to lib OCL.
Last edited by Lee on Wed Oct 31, 2012 10:47 pm, edited 1 time in total.
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Re: [fixed] mouse drag behavior for snapped-to-grid tokens
patch supplied in Testing
FYI, I applied the change to setProperty to bar it from affecting library tokens, though I'm opting to not submit it for the official build as it's not game changing or anything like that; plus I made changes to the translation properties that I'd need to submit as well, and that file includes a lot of amendments not found or supported in the official source.
FYI, I applied the change to setProperty to bar it from affecting library tokens, though I'm opting to not submit it for the official build as it's not game changing or anything like that; plus I made changes to the translation properties that I'd need to submit as well, and that file includes a lot of amendments not found or supported in the official source.
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in