RPTools.net

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.

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.

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.

Error running onCampaignLoad on lib:test : java.lang.NullPointerException error executing expression gmNames = getLibProperty("gmNames",thisLib).

[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)]}]

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.

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.