bugs in latest patched version

[wolph42]

We'll I'll try again later.

[wolph42]

a post by AM just reminded me of the following bug which I haven't reported here yet.

11.

Code: Select all

[json.difference('["test1","test1","test2","test2"]','["test1"]')]
[json.difference('[1,1,1,2,2,2,2,2,3,3,3,3]','[1]')]

results in

["test2"]
[2,3]

It *should* return:

["test1","test2","test2"]
[1,1,2,2,2,2,2,3,3,3,3]

In short, it apparently does a json.unique before substraction. This should not happen. You could argue that substracting test1 will remove all occasions of test1, but
1. that still does not explain the dissapearance of 'test2'
2. I strongly disagree with this approach as there is a seperate function (json.unique) to deal with that.

EDIT
same issue with json.intersection

Code: Select all

[json.intersection('[1,1,1,2,2,2,2,2,3,3,3,3]','[1,1,4,4]')]

results in

[1]

but should result in

[1,1]

for good measure I tested equals, remove and reverse as well, but they work as intended.

[dorpond]

In case I haven't said this recently, I really appreciate all the efforts with testing and patching. It is warming to see the passion that you all have with making MT an even-more awesome product!

Thank you to all of you!

[jfrazierjr]

a post by AM just reminded me of the following bug which I haven't reported here yet.

11.

Code: Select all

[json.difference('["test1","test1","test2","test2"]','["test1"]')]
[json.difference('[1,1,1,2,2,2,2,2,3,3,3,3]','[1]')]

results in

["test2"]
[2,3]

It *should* return:

["test1","test2","test2"]
[1,1,2,2,2,2,2,3,3,3,3]

In short, it apparently does a json.unique before substraction. This should not happen. You could argue that substracting test1 will remove all occasions of test1, but
1. that still does not explain the dissapearance of 'test2'
2. I strongly disagree with this approach as there is a seperate function (json.unique) to deal with that.

EDIT
same issue with json.intersection

Code: Select all

[json.intersection('[1,1,1,2,2,2,2,2,3,3,3,3]','[1,1,4,4]')]

results in

[1]

but should result in

[1,1]

for good measure I tested equals, remove and reverse as well, but they work as intended.

I don't agree...there are MANY instances, especially for intersection, where you needTo know Just the distinct values..how many copies is of no consequence. unfortunately, it really just depends on if you are trying to create a new jaisaun or if you are trying to perform filtering functionality which is what it appears to be made for

[wolph42]

I don't really get your remark, cause I fully agree with you but that that the functions certainly aren't useless, just that they don't work 'as suggested' or 'as described in the wiki'.

Point is: json.union(json.intersection()) is really easy, the other way round though (so using the function without the union) is a real pain.

edit:
by the way. As is pointed out here json.removeAll and json.difference currently act the same. json.removeAll should remove ALL instances of e.g. [1] in [1,1,1,2,2,2] while json.difference should only remove the given instances. That way both functions have a proper meaning.
so json.removeAll([1,1,1,2,2], [1]) should return [2,2] and
so json.difference([1,1,1,2,2], [1]) should return [1,1,2,2].
You can always choose to use json.unique as well. but you cannot retrieve values that have been thrown away beforehand as both functions currently do.

[wolph42]

and another one:

12. when a lib:token is either not visible to players or owned by someone, the rest of the players have no access to that lib. This is how it should work. What happens (at least when the token is not visible) is that the onCampaignLoad IS run by all connecting players, but then the macro bugs out as soon as a variable on that lib is accessed by the OCL. IMO the OCL should NOT run at all in this case.

[Azhrei]

I thought it wise to post the bugs I've encountered lately here separately.

This is a great list! Thank you for maintaining it.

These are bugs that I encounter while using jamztheman latest NERPS version. In this case: 'h'.

So should I expect that these bugs can be reproduced in the b90beta? I'm going through them to try each right now and so far I can't reproduce #4.

4. getTokenX and getTokenY are broken in b90. getTokenX(1) on a large token on position x=650, token is snapped to grid (although that does not matter) it returns: 651 !!!

I opened MapTool and used the default (empty) campaign. I dropped a token at grid coordinate 13,0 (which is at pixel 650,0 when using a 50px grid, the default). Both getTokenX(0) and getTokenX(1) produce the correct values (13 and 650, respectively).

5.getStrProp and varsFromStrProp broken as reported here: http://forums.rptools.net/viewtopic.php?f=3&t=24482

I posted in that thread that I don't this this is safe to change from a backward compatibility standpoint.

As I work on the others I'll come back and edit this post to include the additional items and I'll try to post in the individual threads you linked to as well (for posterity's sake).

[wolph42]

I haven't kept track in the early ones which ones are fixed or not, also it's based on the beta release and I've understood from lee that some fixes to the bugs here are applied to the repos. But you'll find that out when testing.

4. I'll check again
5. Pls read my reply as I STRONGLY disagree. Also backwards compatibility only applies for one of the two issues found with them. (The other being the ID issue)

edit: 4: I cannot replicate it either anymore. Strange cause I remember this to be an issue while constructing new code and I encountered an anomaly and after quite some time finally figured out that the X-coord returned was incorrect. I can't remember what i did to create that result save what is described here.

edit: issue 6. Lee could not confirm this issue and I had to agree that in a clean campaign i cannot replicate it either. However I tried it again in my framework with lib:DH impersonated and it *did* occur. Not as strongly as I encountered it earlier, but there was quite some delay (30 seconds to delete 30 tokens).

--->it appears to be the lib:token. so a guess here: if a token, containing a lot of data is impersonated AND the impersonation panel is open THEN the delay happens.
I noticed that if I impersonated a 'normal' token, that the deletion is instantaneous.

3 (so not 1) posts down there is a test campaign attached with instructions.

[wolph42]

I think I've identified issue 10. Load the campaign below and press
F2 and F3.

The latter won't work until you selected the lib token. After that it will work always.

[wolph42]

added 14 to op.

[wolph42]

I cannot replicate #6 and #8. There must be more going on in these. With regard to #8, are there associated frames for these tokens? Anything special about their character sheets?

Could you update #9 to say that there is an "not yet applied" fix, like what you did for #6?

concerning #6 (deleting tokens takes a LOT of time). Attached is a test campaign, build in b90. Instructions are on the map (1. impersonate token and make sure panel is active. 2. delete block of tokens)

[Lee]

I'm just passing through, and I don't really have a lot of time for other stuff right now, but I took a quick look and it seems to be an optimization problem, and not a bug per se.

There's code for putting tokens on the map en masse, but no similar code for removing them. What compounds the speed problem is that a refresh of all the token panels is called whenever a token is removed, which is why you happened on this when deleting a lot of tokens when the impersonation panel is open. I'm wondering if the same holds through if the selection panel is open instead? They're basically descended from the same base class, so the problem, logically, can happen here as well.

I'll look into it when I clear up other stuff on my TODO list. That's about all I can promise right now.

[JamzTheMan]

#7 Fixed, patch submitted: http://forums.rptools.net/viewtopic.php?f=60&t=24773

[wolph42]

#7 Fixed, patch submitted: http://forums.rptools.net/viewtopic.php?f=60&t=24773

OP updated

[wolph42]

added issue 15:

15.
a. [frame:] the 'temporary=1' option is NOT working. This *does* work for [dialog:] though.
b. Additionally there is the complaint that the position of the frames are not stored during save (or reset on restart) which requires user to reposition the frames everytime they start MT (which is rather annoying). Now I *do* remember that previously there was an issue with frames being outside of the screen (due to saving in high res screen and loading later in low-res), which IRC is be the reason for this 'reset'. Maybe there's a more elegant way to solve this?