RPTools.net

Hi,

I'd like to contribute to Maptool's code. (You wouldn't guess, how long it took me to get out this first sentence. It' the first impression that counts, but still...
I downloaded the SVN-latest a few weeks ago and after my vacation implemented a sample feature to get a hold on the project: autodetect toplogy. You mark a rectangle and the code looks for walls, etc. in it. This works (best) for maps that differentiate opaque objects as black on a white background. That is true for most maps I use in gaming where topology matters. I'd say it is ready for alpha-testing (even beta-testing).

Since it contains new classes and an icon, Eclipse doesn't properly generate a patch (at least I couldn't get it to include the new pieces). How would you want this to be sent in? Is there anything else you'd like to know, for instance, about me?

Michael

Welcome to RPTools! We're glad to have you join us.

First, you'll want to send a PM to jfrazierjr so that you can be added to the Testers forum; it's a great place to get people to try out new code.

Second, patches should be generated by right-clicking on the "maptool" project and choosing Team > Create patch... That way the proper context is set up for the generated patch file.

We are currently in a feature freeze for 1.3 so we won't be adding anything new. That means if you want to contribute to the current version, bug fixes are probably better targets. I can provide a list of high priority ones, if you like.

Thanks for the welcome.

First, I tried. But I get "We are sorry, but you are not authorised to use this feature. You may have just registered here and may need to participate more to be able to use this feature." I assume I need to keep bothering you then for now.

Second, I knew that. That's what I did. I haven't worked too much with Patches & Eclipse yet, so I might be doing something wrong, but it seems to be omitting new files (the one I created).

When I checked out SVN, I assume I got the last of 1.3 and not 1.4, right? The code I added can be disabled by commenting out one line, so no worries. I will keep it in my private version. In case any of "my" bug fixes touch the same classes, we'll see. That may well be when 1.4 comes out Okay, give me a list of bugs you think me capable of solving.

Yeah, we required two approved posts before allowing unmoderated posts or any PMs. That was in your welcome/activation email. This helps prevent spammers.


Hm, nothing comes to mind as an option that would cause that. I can create new classes and they show up when I choose Create Patch...


Yep. We'll be using Git for 1.4 so the SVN tree will stay clean.


Heh. Well, I don't know what you're capable of. There's a list linked to from the wiki's ChangeLog page (I've removed the ones I plan to do myself). Warning: each fix needs to be a separate patch file. This is a pain to manage on your end, I know (I've been there!) but I want a commit comment that defines what the patch does so I prefer one-patch-per-bug-fix and one-fix-per-patch.

1. Loading campaign doesn't always draw the screen correctly on the first refresh of the map (maybe only for older campaigns?)
2. Moving seems to clear fog for all players, while Meta-I only clears for the selected token(s).
3. Add build.xml target for clearing the version.txt to get back to DEVELOPMENT
4. Add Help menu option that displays Java SystemProperties for debugging purposes (Java version, user.dir, other information from SysInfo?)
5. Add startup check that grabs notes from rptools.net for display to user (used for things like version notes, update notes, etc)
6. Review feedback on SVN 5769 viewtopic.php?f=60&t=19195
7. Dropping first token doesn't use Preferences setting for Filename vs. Creature name? viewtopic.php?f=3&t=19202&p=202692#p202692
8. Movement metrics need to be displayed above hard fog
9. If statsheet is being displayed, map rendering should be clipped out of that area (on OSX I get token vision outline drawn on top of statsheet)
10. Right-click menu on tokens sometimes is above or under the statsheet (seems to be based on renderTokens() being called repeatedly while popup menu is being shown)
11. When I draw VBL with the Poly Line tool and try to start a new line where the last line ended, it won’t work. I have to literally draw the line somewhere else and then go back to that point.
12. Using the # in campaign properties should imply the *, but without the * actually showing up in the list

Umm err what? I thought you changed the movement code so that a token could not be dragged through hard FOW? if that's the case, is there any point to this?

So, I'll wait until I get these posts through without explicit approval and then I'll mail him. Unless he already entered me into that list, because he read this thread.



I don't understand this either, because it should be standard fare for Eclipse. But it just creates one "patch.txt".



I'll start with these two. The second is pretty easy to do. For the first, can you supply a campaign file that exhibits that problem? (Preverably in reduced form.) Mine don't have it.
Or maybe you can explain what the "first refresh" refers to. Maybe it's correct on initial display and a "refresh" from, say, another window moving across it fails. Then doing so again, corrects it?

I have a campaign file that has this bug reliably, but it isnt in any way reduced. You would have to reduce it yourself.
You can - if interested - download it here: http://www.peoplecoveredinfish.de/_medi ... _b75.cmpgn

Its a campaign file created late in 2009 and updated ever since (since this is my framework development file). The map contains of a bunch of large tiles. On campaign load the tokens are not displayed. Zooming in or out fixes that.

Yes, thats correct.. all source files will be included in the single patch file... However... note that binary files will need to be done via email/post/etc since patch format won't work with the binaries...

If thats NOT the issue, it's perhaps due to selection level within your project/workspace thats the issue as you make the patch...

That's correct. This is because if you drag a token with a wall of hard fog immediately to the south of it, the token labels and movement metrics are drawn underneath the fog. Which of course means they're not visible.

That's probably fine for GM movement (since the GM's hard fog is semitransparent anyway) but it's a bummer when players are moving their own tokens. Not sure but I think any player-owned token should have its labels displayed above the hard fog...

Somebody wrote in AppActions.java:


One lightning coming up. While adding some debug prints I found a concurrency violation on Zone.tokenOrderedList in here. Whether this is the root cause of the problem, I don't know yet. Too late for a fix today anway

Adding SwingWorkers usually isn't too tough, it's just no one has sat down to do it yet. If you need examples, there are other places in the code that do create SwingWorkers to do off-thread processing.

Hmm... something in the back of my head is flashing a warning sign here.. but I can't for the life of me remember why... I guess Dorpond and Phergus would need to test the patch well before it's commited to SVN....

All I know is that what it does now is definitely wrong. As a player I can't move my token throw a corridor that's only one grid cell wide and see my movement distance. That's obviously incorrect.

At a minimum, the person moving the token should see their movement metric above the hard fog, but I see no reason why other people shouldn't be able to see it as well. (Of course, the GM moving an NPC can/should stay hidden from players.)

I decided to synchronize the access methods. That helped. Unfortunately, that did not fix the root cause.

But that's the thing... SOME (crazy ) people let Players control tokens of type NPC.... I understand what your saying though, it's just one of those things that I don't think has a "good" solution in 1.3