RPTools.net

I thought I would start my own thread so I could better track and link what patches/fixes/enhancements are currently in my custom JAR.

Current version: 1.4.3.20 (not to be confused with the public versioning)

What's included?
Jump to this post for up to date info...
http://forums.rptools.net/viewtopic.php ... 45#p262579

getVBL(JSONArray, [0|1])
HTTP functions *no official patch, beta testing only
Darkness as Lightsource [Beta]*patch pending testing
[patch - MapTool] FoW mods + path computation fix



Included forum links where possible

<reserved>

bringToFront

I'll post all my test findings here, instead of per thread:

bringToFront returns the "current z-order + 1" it should return the "current z-order"
dito sendToBack() but then 'current z-order - 1' where it should return "current z-order"

basically you expect the function to return the value to which the token has just been set.

btw: thanks for implementing this!
______________________
poly line correct
I can't test this as I cannot create a reference file. This because you ALSO included lee's FoW speed-up. Basically I need to identical MT version, with one with triangle VBL lines and one with square VBL lines. Thats the only way to conduct a proper test.
I did one test though, one drawn vbl lines and a cross stamp on a token, then disabled onTokenMove macro. Moved the token 2 squares and MT crashed...
...and then I did a test in b89 current build and that one started to panic as well after a while..and crashed. I'll try to create repeatable situation
--b87 crashes as well... funny.

Ok here the how to:
- draw a VBL polyline, from 0,0 to 10,10 using the meta key so it snaps to grid.
- then place a token at one end of the line so -1,-1
- then set the token to PC and normal vision.
- Hit meta+w (turn on FoW).
- drag the token 1 cell to the left
- drag the token 2 cells to the right: MT crashes!! (that is: EVERY update takes about 2 minutes)

ill create a separate post about this as this happens in b87+

wolph42 wrote:bringToFront
basically you expect the function to return the value to which the token has just been set.

btw: thanks for implementing this!

No problem, but it requires some testing as not sure if it's going to help if dealing with multiple tokens. There may still be a timing issue.

wolph42 wrote: poly line correct
I can't test this as I cannot create a reference file. This because you ALSO included lee's FoW speed-up. Basically I need to identical MT version, with one with triangle VBL lines and one with square VBL lines. Thats the only way to conduct a proper test.

Actually you just need the proper VBl and can test in any version of MT.

1. Create VBL using manual PolyLine tool in stock b89.
2. Export map
3. Create VBL using new tool in custom jar (or using vbl macro's)
4. Export map
5. Import both maps into any version of MT, test.

In fact, you should be able to do all of this in stock b89 if you use the macro's to simulate the new drawing tool. All we are testing is if extra data points affect performance.

If you are in the mood, you can test both and see if the new FoW patch improves performance between versions (since in theory you would/could have timings from stock b89)

this took me two hours to figure out...
it turns out that setTokenShape(shape[, id]) does NOT always eat the id of the token. I believe even in most cases the id is ignored.

Sorry about that, there is indeed an extra line in the code that totally shouldn't be there and overrides the parameter passed in. Not sure how that slipped by.

I need to see what Az has checked in for VBL_Functions class so I can build a patch for it but should be ready for b90 provided Az isn't buiding it right now.

Patch submitted and Custom Jar updated with fix.

[patch - MapTool b89] setTokenShape bug fix

Build updated to includes Lee's [patch - MapTool] FoW mods + path computation fix

is your sig updated with this one as well?

Yes. I only have one build now and my sig always connects to the latest version. The zip is never renamed with version but the JAR inside is.

Version i patches a decimal bug for certain language/region areas for the VBL macros.

OK, version J is out. It's a new build based on latest revisions in SVN + Lee's FoW Patch (with my fix).

*Warning: Any campaign saved with any version past version G is incompatible with b89 and most likely b90 due to the FoW fix. Once b90 is official, I'll decide to rip this patch out or not then.

I'm going to go through versions quickly I think this week.

Version K.

o Rolled back jsonSort function to previous revision to restore functionality.
o Changed getVBL to return JSON Array vs String. Test to see if this solves decimal conversion issue.

Wolf, if you could test the second?

I will bet that if you make the two new fields that Lee added to the Token class as transient, the campaign files would be fine.

If they're transient, they won't be written to the output. Which means they would be readable on older versions. It only when new fields are added that the older versions can't deal with it -- they can't know if something important is being left out!

JamzTheMan wrote:o Changed getVBL to return JSON Array vs String. Test to see if this solves decimal conversion issue.

Hm. I saw his comment that it still didn't work but haven't gotten to checking into it yet. I'm not exactly sure why he was having a problem anyway. If numbers are stored in a JSON object as numbers (ie. with quotes around them) then there is no conversion problem. It's only when the number is actually stored in a string and contains the grouping separator for numbers (ie. 5,000.00 or 5.000,00 depending on your locale setting).