Testing b90 pre-build

[JamzTheMan]

OK, so notice a few new things in current code base already

VBL Crosses, nice! FYI, I'm seeing 2 buttons for this in the panel, 1 in the front of Square, one at the end. Assuming first is a duplicate.

Anything else new sneaking in that needs testing?

FYI, suggestion? The hollow rectangle and cross both have a thickness of 2 where the Polyline is thickness 1. Be nice if it was uniform. Also makes for better VBL when capturing via getVBL. You get 1 pixel on either side of a gridline instead of a .5 pixel.

PolyLineTopologyTool patch

Code: Select all

Index: src/net/rptools/maptool/client/tool/drawing/PolyLineTopologyTool.java
===================================================================
--- src/net/rptools/maptool/client/tool/drawing/PolyLineTopologyTool.java	(revision 5962)
+++ src/net/rptools/maptool/client/tool/drawing/PolyLineTopologyTool.java	(working copy)
@@ -62,7 +62,7 @@
 		pen.setEraser(isEraser());
 		pen.setForegroundMode(Pen.MODE_SOLID);
         pen.setBackgroundMode(Pen.MODE_TRANSPARENT);
-        pen.setThickness(1.0f);
+        pen.setThickness(2.0f);
         pen.setPaint(new DrawableColorPaint(isEraser() ? AppStyle.topologyRemoveColor : AppStyle.topologyAddColor));
 
 		return pen;

[wolph42]

is this in your nerps 89 test build?

apparently it is. Just tested getVBL() on the 'local computer' but its not working, same error: numberformatexception etc.

[JamzTheMan]

The polyline change? Yes, for several versions now. I was tired of using rectangle to draw thicker lines.
The Cross VBL? Yes, in version J.

I was thinking it would be a nice option to put a dropdown or number selector right on the VBL panel to allow variable thickness of lines when drawing.

[wolph42]

edited last post

and yes, that would be a nice option. I like the X too btw.

edit: hold the horses on the getVBL comment, used older version... brb

final (?) edit: confirmed: bug is still there, same error as before.

[Azhrei]

FYI, I'm seeing 2 buttons for this in the panel, 1 in the front of Square, one at the end. Assuming first is a duplicate.

It is. Not sure how it got there, but I've removed it.

Anything else new sneaking in that needs testing?

Hm, it wasn't as time-consuming as I remember in the past... New ChangeLog has been posted. It'll likely be updated a few more times before we're done because I need to include the new launcher in the MT build process.

PolyLineTopologyTool patch

Patch applied and committed.

[JamzTheMan]

Az, I didn't see upnp fix in the change log? Otherwise healthly list.

[Azhrei]

Hm, you might be right. The upnp source code is in a separate project with its own history so it wouldn't have shown up on MapTool change history.

I just checked. The new upnp library is dated June 3rd and is in the maptool/lib/ directory, which means, "Yes, UPNP is in there." There's no history item for it though, but I'll look at the commit comments for June 3rd and 4th and find out which one added the file and annotate it.

Edit: It's part of rev 5946. I've updated the ChangeLog. And I'll get the code uploaded to SF tomorrow night.

Thanks for noticing. I'm glad at least someone is looking at the ChangeLog.

[wolph42]

couple of small things: (tested in version b89-p)
- when saving a map its saved without the .rpmap extension
- when loading a map I get a pop-up: this is an experimental feature loading map (gm logged in remotely)
but this is a local instance running...

[Azhrei]

couple of small things: (tested in version b89-p)
- when saving a map its saved without the .rpmap extension

Wow, that's strange. First I'd heard of that problem. I'll check it out.

- when loading a map I get a pop-up: this is an experimental feature loading map (gm logged in remotely)
but this is a local instance running...

Heh, that's strange too! Maybe I got the logic backwards. Thanks for the report.

[wolph42]

I haven't tested this in b90. But there is a conical light source bug in b89. I've marked the post.

[Lee]

I haven't tested this in b90. But there is a conical light source bug in b89. I've marked the post.

Fixed. I put a poll up before submitting the patch so I'd know what to send in.

[wolph42]

In the mean time, the next bug in b90:

getLastPath() returns very strange values when used on a token unsnapped to grid. When snapped, the function returns each cell that the token has passed over, unsnapped...

e.g. dragging a token (unsnapped) from 0,0 to 100,0:

« getLastPath() = getLastPath() = [{"x":0,"y":1},{"x":100,"y":-99},{"x":101,"y":0}] »

0,0 to 300,300:

« getLastPath() = getLastPath() = [{"x":0,"y":-3},{"x":100,"y":97},{"x":200,"y":197},{"x":300,"y":297},{"x":400,"y":397},{"x":300,"y":297},{"x":400,"y":397},{"x":301,"y":303}] »

the begin and end values are correct, but in the middle stuff really goes haywire.

with waypionts: 0,0 - 0,100 - 100,100 - 100,0 - 0,0 (square):

Code: Select all

« getLastPath() = getLastPath() = [{"x":4,"y":3},{"x":4,"y":-97},{"x":4,"y":3},{"x":4,"y":-97},{"x":4,"y":3},{"x":4,"y":-97},{"x":4,"y":3},{"x":4,"y":-97},{"x":4,"y":3},{"x":4,"y":-97},{"x":4,"y":3},{"x":4,"y":-97},{"x":4,"y":3},{"x":4,"y":-2}] »

As Im using the lastpath extensively for the BoT this can lead to some considerable issues. but apart from that...its a bug.

[JamzTheMan]

Just a note. I do have Lee's FoW fix applied to my build (because I like it) but it's not part of b90. I don't know if that messes with pathing or not.

So for any bugs, please confirm them in b89 as well. If it's only b90 it helps narrow things down, like in this case, I don't believe theres been any other patches that may have touched that code.

[wolph42]

Just a note. I do have Lee's FoW fix applied to my build (because I like it) but it's not part of b90. I don't know if that messes with pathing or not.

So for any bugs, please confirm them in b89 as well. If it's only b90 it helps narrow things down, like in this case, I don't believe theres been any other patches that may have touched that code.

Open mt, impersonate a token, unsnap it, drag It over the map and type getLastPath() in the chat.
It's really easy to test.

[Lee]

@Jamz you might just have to revert to original source, I'm afraid. The issue reported by wolph looks familiar but it's not supposed to behave that way. What the logic does is generate a path from point a to point b for unsnapped movement that is similar to snapped movement .

As I suspected previously, there's a missing element somewhere in the patch I submitted. The FoW fix was coupled with the path compute fix as they shared common classes. I don't have the time right now to separate the 2, but if you want to tackle it, best of luck They were the 2 of the more trickier ones I had to fix

@wolph Out of curiosity, what was your distance per cell set to? Were there any other changes?