MapTool 1.3 Final, patch04 (build 87)

[Lee]

Nothing's been changed about the handling of abort() and assert(), has it? I'm just assuming it's different because of the context being within the development environment since using both generates a roll error i.e.    

"Error in body of roll.
Statement options (if any):
Statement Body : abort(0)"

which in turn halts the execution of my framework when the parser encounters these. Even just typing assert() or abort(0) in chat generates these results. I was continuing dev on my framework under the latest svn to see if it'll be compatible with b88 (and the console dump is much easier to read in eclipse I found ). I hope I'm right as I have made fairly extensive use of these

[Azhrei]

Nope, abort() and assert() work the same way. I was mucking around with exception handling and accidentally broke them but they should be working now (SVN 5840).

Using exceptions to handle these is a bit ugly. Expedient perhaps, but ugly. I was trying to catch all exceptions and report them but then found out that these two generated exceptions and had to add special code to trap them. I took the easy approach as well and should've refactored the existing code so that both were subclasses of a common class so that the exception handler could catch just that one. Maybe later. (Or maybe not at all. )

[Lee]

Nope, abort() and assert() work the same way. I was mucking around with exception handling and accidentally broke them but they should be working now (SVN 5840).

Using exceptions to handle these is a bit ugly. Expedient perhaps, but ugly. I was trying to catch all exceptions and report them but then found out that these two generated exceptions and had to add special code to trap them. I took the easy approach as well and should've refactored the existing code so that both were subclasses of a common class so that the exception handler could catch just that one. Maybe later. (Or maybe not at all. )

I checked SVN 5840 out and doing an abort(0), and assert(0, "message here", 0) now generates:

macroExecutionAbort:
Statement options (if any): h      
 Statement Body : abort(0)

macroExecutionAssert
Statement options (if any): h       
Statement Body : assert(0, "hi", 0)

respectively. Would these exceptions be thrown when combined within actual code blocks? I have a couple of hacks in my framework that places abort(0) at the end of frame generating macros to kill extraneous blank lines that I can't get rid of otherwise. What happens with this build is that the abort() breaks my code throwing errors depending on where it was found. In my example, it threw an "error in body of roll" exception which disappeared when I took the abort line out.

[Azhrei]

I checked SVN 5840 out and doing an abort(0), and assert(0, "message here", 0) now generates:

Sigh.

There must be something different about my environment. There was also an update to the rplib project but I don't think it would have affected this. I'll play with this some more after work tonight.

The code used to ignore the Abort and Assert exceptions so nothing was displayed. The problem with that is that other exceptions would likewise not be caught and the stack would unwind. If it unwound further than MapToolLineParser.parseLine() there was no way to know which macro statement actually caused the exception since the information would be lost. So I added a catch block and planned to re-throw the exception wrapped up with information about where the macro was when the exception occurred, thus helping folks who were trying to debug their macros!

The problem is that some exceptions are NOT supposed to report the error, such as the Abort and Assert exceptions (which I found out about late in the process). I could catch those exceptions and ignore them. I don't remember why that didn't work when I tried it though; there must've been some other interaction with the code. Since you have Eclipse installed you can try just commenting out lines 1229 and 1232 of MapToolLineParser.java (you can use the Shift-Meta-T command in Eclipse to find the class quickly). If that works for you in your testing then I'll make the same change and commit it to SVN.

Edit: Oops, that's not right. Instead of commenting out those lines (which removes the exception entirely), the original exception needs to be rethrown. So comment those out and add throw e; as a replacement. Darn, I had actually climbed into bed before I realized this and then had to get back up. .

Thanks for your help with this, Lee.

[Lee]

I checked SVN 5840 out and doing an abort(0), and assert(0, "message here", 0) now generates:

...Since you have Eclipse installed you can try just commenting out lines 1229 and 1232 of MapToolLineParser.java (you can use the Shift-Meta-T command in Eclipse to find the class quickly). If that works for you in your testing then I'll make the same change and commit it to SVN.

Edit: Oops, that's not right. Instead of commenting out those lines (which removes the exception entirely), the original exception needs to be rethrown. So comment those out and add throw e; as a replacement. Darn, I had actually climbed into bed before I realized this and then had to get back up. .

Thanks for your help with this, Lee.

No, need to thank me, Azhrei. If anyone should be thankful, it should be me for all the hard work on MT I had a glimpse of the TODO list and it looks like a ton of work
I did as you told me to, and it works like a charm; meaning it performs as it did in b86 and my framework runs unbroken through all its processes. Console's clean too with only a reference to "net.rptools.maptool.client.functions.AbortFunction$AbortFunctionException: macro.function.abortFunction.message" when the parser hits the abort line.

Sleep well

[Azhrei]

Console's clean too with only a reference to "net.rptools.maptool.client.functions.AbortFunction$AbortFunctionException: macro.function.abortFunction.message" when the parser hits the abort line.

Hm, there must be a println() in there somewhere.

When we switch to 1.4 I'll need to find all System.{out,err} references and remove them...

[wolph42]

A picture says it all:

light issue screenshot.jpg (104.66 KiB) Viewed 1617 times

I actually thought that this issue was fixed in b87 which was one of the reasons why I finally switched to b87, it turns out not to be the case.

In case its not entirely clear, if you move your grid a bit (meta+shift+a) then the light source around the token gets disaligned. Making the players token look like this:

light issue screenshot2.jpg (25.89 KiB) Viewed 1617 times

For me this really is an issue!

[aliasmask]

I see what you mean. With a new map and default conic vision, the left is with no vision and the grid adjusted, the right is with daylight on.

I do like how the grid only adjusts to one square max away, but another weird thing happened that I didn't notice before but makes total sense. When I changed the vision to conic vision, the next time I moused over token the facing attribute kicked in. That's another good feature I never noticed. I don't usually use conic vision though.

I haven't run in to the graphical glitch though. I use to have those on occasion until I updated my video driver and java.

[jfrazierjr]

A picture says it all:

light issue screenshot.jpg

I actually thought that this issue was fixed in b87 which was one of the reasons why I finally switched to b87, it turns out not to be the case.

In case its not entirely clear, if you move your grid a bit (meta+shift+a) then the light source around the token gets disaligned. Making the players token look like this:

light issue screenshot2.jpg

For me this really is an issue!

Known issue that won't be fixed in 1.3. That's(at least from my recall) one of the reasons Trevor never put in a modify map function in the first place. The idea here is that if you modify your map information(grid), then you should do so PRIOR to adding tokens and/or VBL.

[jfrazierjr]

I do like how the grid only adjusts to one square max away, but another weird thing happened that I didn't notice before but makes total sense. When I changed the vision to conic vision, the next time I moused over token the facing attribute kicked in. That's another good feature I never noticed. I don't usually use conic vision though.

Yes, thats because if facing is not set, but vision is turned on, you get null pointer exceptions cause it's trying to determine which way to point the cone and can't cause there is no facing set! So, after I added conic vision way back, I had to go back in and submit another patch to Trevor to default facing as soon as vision was turned on IF vision type was conic. I am not sure(since I did not do the lights), but I think the same is true with conic light sources.

[wolph42]

Known issue that won't be fixed in 1.3. That's(at least from my recall) one of the reasons Trevor never put in a modify map function in the first place. The idea here is that if you modify your map information(grid), then you should do so PRIOR to adding tokens and/or VBL.

ok so if I FIRST adjust the grid and THEN put token on it, then it will work as expected?
*opens MT*
nope, disalignment is still happening.

-open MT
-ctrl shift a
-move grid and ok
-drag token onto map
-set map to night and token vision to conic
-->disaligned vision. Same for using light source.

btw I usually move my tokens AFTER I have moved the grid. Not because I knew about this bug, but because I move(d) the grid to align with a background pic first. Then start adding objects and finally add tokens.

[jfrazierjr]

Known issue that won't be fixed in 1.3. That's(at least from my recall) one of the reasons Trevor never put in a modify map function in the first place. The idea here is that if you modify your map information(grid), then you should do so PRIOR to adding tokens and/or VBL.

ok so if I FIRST adjust the grid and THEN put token on it, then it will work as expected?
*opens MT*
nope, disalignment is still happening.

-open MT
-ctrl shift a
-move grid and ok
-drag token onto map
-set map to night and token vision to conic
-->disaligned vision. Same for using light source.

btw I usually move my tokens AFTER I have moved the grid. Not because I knew about this bug, but because I move(d) the grid to align with a background pic first. Then start adding objects and finally add tokens.

Hmm.. I see... It looks like the ZoneRenderer.renderVisionOverlay() needs to be updated.


My quick guess is that:

Code: Select all

af.translate(zoneScale.getOffsetX(), zoneScale.getOffsetY());

zoneScale's offsets are not being updated when the grid is moved....

[Lee]

I'm not quite sure if it's something worth pursuing but I found it odd enough to say it here since I found it to occur in b86 and the dev build. I have a fairly complex combat sequence handler and for a while now there was a minor annoyance that kept cropping up that I ignored since I thought it happened due to the heavy processing that occurs when my macro passes initiative. What happens is that when I pass initiative either through nextInitiative() or setCurrentInitiative(getCurrentInitiative()+1), the program passes to the next token, hops back to the previous token, and then passes initiative for good.

Well, I sat down to see what was causing this since I'm in the optimization stage of development and it wasn't as easy to pin down as I thought. But eventually, I did catch what was causing it. It looks like some weird interaction occurs when the initiative functions are used in the same macro with setLibProperty() (and I'm guessing, similar functions). When a single setLibProperty() line is in the macro, it's barely discernible but you can still see the check mark denoting the token with current initiative flicker.

The funkiness really starts when 2 setLibProperty() calls are made within the macro. What I did to finally fix it was to extract those lines from the macro and do the commits to the lib:token before and after the initiative macro (though I think I still had one left in there). I made a test case that simulates it:

Code: Select all

[if(getCurrentInitiative() == initiativeSize()-1), code:{
[setCurrentInitiative(0)]
[setLibProperty('<!-- any lib:token commit -->']
[setLibProperty('<!-- any lib:token commit -->']
<!-- My actual code: [setLibProperty("jsonDelay", "[]", "Lib: Properties")] -->
};
{
[nextInitiative()]
}]

[sortInitiative()]
[h: bringToFront(getInitiativeToken())]

You'll have to click really fast for it to trigger what I'm trying to describe. When you see the check mark jump around, you can see the offsets in chat reflect the jump instead of the proper sequential order. Of course in a heavier macro, it becomes really evident even in normal use .

[aliasmask]

I think I understand what you're saying, but I think your problem is somewhere else. When setting the current init to 0, then sorting it, the current init will follow the the first person in order before the sort. I would just move that line to the point after the sort and the sort in to the first condition unless you really want to resort for each initiative.

Code: Select all

[if(getCurrentInitiative() == initiativeSize()-1), code: {
   [setLibProperty('<!-- any lib:token commit -->']
   [setLibProperty('<!-- any lib:token commit -->']
   <!-- My actual code: [setLibProperty("jsonDelay", "[]", "Lib: Properties")] -->
   [sortInitiative()]
   [setCurrentInitiative(0)]
};
{
   [nextInitiative()]
}]

[h: bringToFront(getInitiativeToken())] 

[Lee]

Oh, the code I posted was a heavily bastardized version of what was in my real code. The extraneous parts I cut out handled effects where characters gained advantages to initiative through techniques etc, so I had to sort initiative prior to starting the next round. I only left it because I wanted to show what initiative functions I was using, though I should have added the setInitiative() stuff just for completeness sake. But the sort has indiscernible impact, it's really the setLibProperty() function that causes the hiccups, something I tested and distilled down to the sample code I posted earlier.

I'm no expert on the underlying architecture, but I'm guessing it's how MT handles code on the macro level as what's really weird is that 2 setLibProperty() calls before and after the called macro operates roughly 5 times faster than when I had them inside the macro itself, and even when I reduced it to one macro inside, the 2 outside still produced no "yo-yo" effect . It's not a big deal for me really, once I figured how to circumvent the behavior, but I'm hoping that it's not a surface symptom of something more far-reaching with regard to performance and stability. Obviously, when the current token focus behaves this way, and I'm passing large objects containing character info, I'm concerned if the data will get corrupted in some way or gets attributed to another token's context; which I have observed, though I'm not saying this is the cause as I'm still hunting for other culprits (as I mentioned in my other post in the Macro forum)