[fixed] mouse drag behavior for snapped-to-grid tokens

Progress reports and musings from the developers on the current gaming tools.

Moderators: dorpond, trevor, Azhrei

Post Reply
Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

[fixed] mouse drag behavior for snapped-to-grid tokens

Post by Lee »

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.

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: [fixed] mouse drag behavior for snapped-to-grid tokens

Post by aliasmask »

Thanks. That bug was a real peeve.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [fixed] mouse drag behavior for snapped-to-grid tokens

Post by Lee »

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.

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: [fixed] mouse drag behavior for snapped-to-grid tokens

Post by aliasmask »

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.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [fixed] mouse drag behavior for snapped-to-grid tokens

Post by Lee »

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"

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: [fixed] mouse drag behavior for snapped-to-grid tokens

Post by aliasmask »

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.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: [fixed] mouse drag behavior for snapped-to-grid tokens

Post by wolph42 »

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

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: [fixed] mouse drag behavior for snapped-to-grid tokens

Post by aliasmask »

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.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [fixed] mouse drag behavior for snapped-to-grid tokens

Post by Lee »

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.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: [fixed] mouse drag behavior for snapped-to-grid tokens

Post by wolph42 »

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

User avatar
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

Post by JamzTheMan »

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

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: [fixed] mouse drag behavior for snapped-to-grid tokens

Post by aliasmask »

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.
Error running onCampaignLoad on lib:test : java.lang.NullPointerException error executing expression gmNames = getLibProperty("gmNames",thisLib).
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.
||| 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)]}]
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 :oops: .
Attachments
test duplicate lib.cmpgn
(45.71 KiB) Downloaded 184 times

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: [fixed] mouse drag behavior for snapped-to-grid tokens

Post by aliasmask »

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.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [fixed] mouse drag behavior for snapped-to-grid tokens

Post by Lee »

I tried the test campaign and wasn't able to replicate as well. I'll wait on that update then.
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.
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.
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.
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.
Last edited by Lee on Wed Oct 31, 2012 10:47 pm, edited 1 time in total.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [fixed] mouse drag behavior for snapped-to-grid tokens

Post by Lee »

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.

Post Reply

Return to “Developer Notes”