bugs in latest patched version

Notes on testing the latest builds of MapTool

Moderators: dorpond, trevor, Azhrei

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

bugs in latest patched version

Post by wolph42 »

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

These are bugs that I encountered while using b90-beta, released by Azhrei.
fixed / fixed-but-not-yet-patched / unable to replicate
1. (FIXED) getVBL is broken, jamz is fully informed.

2. (FIXED) moving tokens is 'broken'. In about 25% of the time when 'dropping' the token (releasing left mouse button after moving a token) the token 'jumps' several squares to a different place. larger tokens tend to jump farther then smaller tokens.

3. (FIXED) The following line works in b89 and NOT in pre-b90:

Code: Select all

[jsonOrder      = json.sort('[{"id":"A","order":1},{"id":"B","order":5},{"id":"C","order":2}]',"a","order")] 
4. (UNABLE TO REPLICATE ISSUE) 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 !!!

5. (FIXED, patch not yet applied) getStrProp and varsFromStrProp broken as reported here: http://forums.rptools.net/viewtopic.php?f=3&t=24482

7. (FIXED, patch not yet applied) It appears that VBL is not applied if the ending coordinate is 0. http://forums.rptools.net/viewtopic.php?f=3&t=24547

9. (FIXED, patch not yet applied) Cone light source lits up also 2 grid cells around the token: http://forums.rptools.net/viewtopic.php ... 86#p248986


PRIORITY 16. (FIXED, patch not yet applied) getStrProp and varsFromStrProp broken as reported here: http://forums.rptools.net/viewtopic.php?f=3&t=24482
json.sort no longer works on arrays. b90 issue. http://forums.rptools.net/viewtopic.php ... c4#p250959
test code:

Code: Select all

[h:vals = '[ {name:"Hero", HP:10},{name:"Wolf", HP:5},{name:"Mage", HP:20},{name:"Troll", HP:15},{name:"Eagle", HP:5} ]']
[json.sort(vals, "a", "name")] 
temporary solution (workaround) for 16
6. (UPDATED ISSUE) When deleting token while a token is impersonated and the panel is open: the deletion process takes A LOT of time.
UPDATE: if a token, containing a lot of data is impersonated AND the impersonation panel is open THEN the delay happens when many tokens are deleted: http://forums.rptools.net/viewtopic.php ... 06#p249706
NEW (test campaign): http://forums.rptools.net/viewtopic.php ... 35#p249935


8.Changing the grid (ctrl+shift+A) is broken: http://forums.rptools.net/viewtopic.php ... 40#p248740
UPDATE: apparently this does not happen on every PC. I have two PCs, on one I cannot make this happen. On the other this happens consistently. The only difference so far (win7, java7b17: no issue) and (win 8, java 7b45: issue). Whether its java or the OS or the hardware... no idea.

10.(ISSUE UPDATED and confirmed) Issues with short cut keys: http://forums.rptools.net/viewtopic.php ... 06#p249206. UPDATE: http://forums.rptools.net/viewtopic.php ... 07#p249707

11.

Code: Select all

[json.difference('["test1","test1","test2","test2"]','["test1"]')]
results in
["test2"]
In short, it ALSO does a json.unique. This should not happen.
Same issue with json.intersection: http://forums.rptools.net/viewtopic.php ... 33#p249533

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.

13. memory leak. http://forums.rptools.net/viewtopic.php ... 84#p249419

14. Players can see token name and travel distance of NPCs through FoW, when gm moves the token (and thus revealing their location). http://forums.rptools.net/viewtopic.php?f=21&t=24758

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? http://forums.rptools.net/viewtopic.php ... 46#p250846
c. I noticed that the last position of Dialogs are NEVER stored (not sure thats an issue, but I though I'd mention it here) so also not during one session.

17. Light cone bug: http://forums.rptools.net/viewtopic.php ... 84#p244084 (had completely forgotten about it until my last game)

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: bugs in latest patched version

Post by Azhrei »

Yeah, the token movement stuff won't be in the next build.

It would be nice to find a fix for the getVBL() problem, although I'm not going to wait for it to do b90.

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

Re: bugs in latest patched version

Post by wolph42 »

The getvbl issue seems to be Pc or java dependent, so I think it's another issue entirely. Need to run some more tests. Overall I don't think you'll need to wait for the fix as the problem lies somewhere else.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: bugs in latest patched version

Post by JamzTheMan »

The only real issue that's kept me from submitting getVBL() function as a patch is the amount of data it "can" return.

Az, how do we classify "stack overflow" errors? In other words, if you submit a 20,000 x 20x000 area, you could be fine if the VBL is a single square ~10 points of data. But you could also submit a 200x200 area that is stupid crazy vbl with 10,000 points of data and would most likey throw an error as the returned data will be to large.

Would you consider this an issue? Not sure if we could throw any sanity checks in as it would be stack size dependent. So far it works just fine for token sized chunks of data. But if you try to get the vbl for a whole map, it's usually way to much data.

Otherwise, the Dungeon Builder project has been a good test on whether it's functionally complete and so far seems to be a nice utility. Maybe I'll submit the patch and you can take a look and offer comments?
-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
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: bugs in latest patched version

Post by wolph42 »

just confirmed that the getVBL is NOT bugged, I think it has to do with an older java version or maybe a local setting. In the netherlands you write 5,000.50 (five thousand and 50 cents) like 5.000,50
I think that somehow half of the vlb coord is deducted and then cast in the dutch version (resulting e.g. in 678,5) and later interpreted like english which will treat 687,5 like a string and not a number, rendering an error. I've tried it on other pcs and its not an issue, just on the sole one...

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: bugs in latest patched version

Post by Azhrei »

wolph42 wrote:just confirmed that the getVBL is NOT bugged,
Okay, thanks.
I think it has to do with an older java version or maybe a local setting. In the netherlands you write 5,000.50 (five thousand and 50 cents) like 5.000,50
Ah. There are some string-to-number parsing functions in net.rptools.maptool.util.StringUtils that handle localization correctly. For a floating point number it would be parseDecimal(). I'll look at the code and see if there's an issue like that before I do b90.

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: bugs in latest patched version

Post by Azhrei »

Jamz, please take a look at rev 5958, in particular the VBL_Functions.java at line 628 and see if the new code for getJSONdouble() fixes the problem. Thanks.

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

Re: bugs in latest patched version

Post by Lee »

Just chiming in to say that I probably won't have time anymore to fix how this works in b90. The change (from where I used to code fixes for base MT) to the new repository was not completely clean, so I had to transfer over things manually to a fresh checkout of b90. Obviously, something's missing as I have no problems whatsoever (even the bugs reported here) on both my fork and the b89- original source. Sorry, but this essentially won't be seen in official MT.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: bugs in latest patched version

Post by JamzTheMan »

Thanks Az, I'll check it out and have Wolf test since he has the test machine :)

@Lee, bummer. Maybe I'll create a fresh b89 and/or b90 checkout and apply the patch and see what happens. Otherwise I guess I'll try to track it down myself. It's a minor bug that I can sort of live with for now. It seemed to happen a few times early on and then was ok for pretty much rest of the night.

But something is causing the token to snap back to a previous "path" location.
-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
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: bugs in latest patched version

Post by wolph42 »

JamzTheMan wrote:Thanks Az, I'll check it out and have Wolf test since he has the test machine :)
i guess you'll give a heads up when you have that ready...?

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: bugs in latest patched version

Post by JamzTheMan »

Ok, Nerps version i is out. It includes Az's fix for the decimal bug. Let us know.

The token jump bug will still be in there. I need to build a fresh copy of Nerps as mine is pretty out of sync now from what's checked in. We'll see if that fixes it, if not I'll have to rip out Lee's patch.
-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
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: bugs in latest patched version

Post by Azhrei »

JamzTheMan wrote:Ok, Nerps version i is out. It includes Az's fix for the decimal bug. Let us know.
I'm not even sure how much of a bug that is. Numbers should not include group separators (such as 5,000.00 or 5.000,00) when used as input. However, we do allow that in some of the preferences fields, so I suppose we should allow it elsewhere.

(Some languages, such as Perl and Java 7, allow the use of an underscore in a number without throwing an error -- they simply delete the underscore. This allows numbers such as 5_000.00, but the language definition does not support localization of constants, so 5_000,00 is not valid. Of all the languages I can think of, none allow constants to be localized. User input is, of course, another matter.)
The token jump bug will still be in there. I need to build a fresh copy of Nerps as mine is pretty out of sync now from what's checked in. We'll see if that fixes it, if not I'll have to rip out Lee's patch.
Are you aware of the create-a-patch, grab a new project from the repo, apply-the-patch-with-a-fuzz-factor approach? The last part means changing the number next to the "Guess" button in the upper right corner of the dialog where Eclipse shows what the pre- and post-patch code looks like. It defaults to 0. Clicking the Guess button is supposed to make a guess as to what the proper fuzz factor is and then try the patch again. I've never had the Guess button for me, AFAICR. In general you don't want the fuzz factor to be set too high or the patch can be applied in the wrong place. You can use successive approximation to find the smallest number that applies without errors, then look at every patch hunk to make sure they make sense. So start with fuzz:8. If it works, try fuzz:4. If it doesn't work, try fuzz:6. And so on.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: bugs in latest patched version

Post by JamzTheMan »

Azhrei wrote:Are you aware of the create-a-patch, grab a new project from the repo, apply-the-patch-with-a-fuzz-factor approach? The last part means changing the number next to the "Guess" button in the upper right corner of the dialog where Eclipse shows what the pre- and post-patch code looks like. It defaults to 0. Clicking the Guess button is supposed to make a guess as to what the proper fuzz factor is and then try the patch again. I've never had the Guess button for me, AFAICR. In general you don't want the fuzz factor to be set too high or the patch can be applied in the wrong place. You can use successive approximation to find the smallest number that applies without errors, then look at every patch hunk to make sure they make sense. So start with fuzz:8. If it works, try fuzz:4. If it doesn't work, try fuzz:6. And so on.
Haven't messed with fuzz yet. The patch originally applied ok but I "may" be missing other checked in classes. This is due to the fact that just last week or so I found out about the new SVN URL so hadn't been getting some of the latest check-ins.

So I created a new project with latest revision checked out and I just need to apply a few patches. That way what I'm testing should be closer to b90.
-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
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: bugs in latest patched version

Post by JamzTheMan »

Wolf, go ahead and retest both bugs you found with version J now available. Both should be fixed. This build is pretty close to b90 now except for the FoW fix as I needed to leave that in.

Once b90 is out, we will most likely have to export our stuff out and into another campaign, sorry.
-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
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: bugs in latest patched version

Post by wolph42 »

movebug: fixed
getVBL (numberformatexception) bug: not fixed.

you do not need to apologize to me, for me its fairly easy to port the code... for you however to get the vbl from a to b ? (well you could use the database of course, but IRC you didn't want to do that).
that and I port my bot and fw from time to time to a 'fresh' campaign file to loose all the **** build up over the last period, so im accustomed to the process.

Some good news as well:
- The earlier 'major VBL bug' I reported where you draw one vbl line on the map and move a token around it, completely stalling MT after two or three moves, is completely gone IF you turn on 'clear fow at waypoints only'. So that's actually quite a big and vital improvement for b90.
- I also did the forest VBL test again and the movement increasement is ENORMOUS (without! clear FoW at waypoint only). Its pretty complex vbl but the move-drop is near instantaneously even for moves > 50 cells and also after 20+ moves. Funny thing is is that if I turn on 'clear at waypoints only' I don't notice anything different...

edit: I just had to check the forest VBL in b89 again cause I couldn't imagine that it was *that* bad... I tested it again and it *is* *that* bad (50 cell movement takes roughly 20 seconds). This will be a major improvement!!

Post Reply

Return to “Testing”