RPTools.net

Yeah. Something like that would be good...

So is this release stable? I'm one of the holdouts waiting for stable before I switch from
the ole 1.2.

The majority of builds since 56 at least have been as stable as 1.2.
More importantly for you, now is certainly a good time to upgrade, since b64 is probably not going to differ much from b63, and Trevor has stated b64 will be final for 1.3. 1.4 may not even be put out for a while, much less very stable at all. So we're going to be using b63-4 for a long time, I expect.

I've asked/notified/warned Trevor multiple times that I'm going to apply my patches and put out a release (which will be b64) and he's not said a word about it, although he's sent me other emails (even replies to messages that included the warning). I'm going to take that as approval. He wouldn't have added me to the SVN list without a reason.

I don't have much, just a few things that have been either (a) important in my own games or (b) pretty simple to fix. I also have patches from jfrazier (GM-only auras) and Rumble (auto-select on init change) that will likely go in. I know jfr's will make it, but I haven't looked at Rumble's yet in any great detail. I wanted to do that this weekend, but my time has run pretty thin. I might get it done tonight, otherwise it'll be Wednesday.

don't forget the italian translation. ^^

Tell me if you need the file.

Yes, I do!

Open call to anyone contributing: If you've sent something to Trevor that didn't make it into b63 and you think it's in the wings for b64, send it to me! Either as a PM or an attachment to this thread. (I'm subscribed to this thread, so I'll receive an email as replies are added.)

It's 1:30AM and I'm not going to get the build done tonight, so you've got until Wednesday now... I'll apply any patches I get on Wednesday and then do some minor testing before releasing b64.

Hell frakking yeah!!!

You have a list of new features that you know of are going to implemented in B64..? can't wait.. hopefully i can test it this sunday at my game... *ROAR* i'm excited...

These are the things that are the patches I'm applying:

*Add confirmation dialog to right-click macro menu Reset option (maptool.client.ui.macrobuttons.buttons.MacroButtonPopupMenu.java:238)

*Add check to Campaign Properties to disallow property names that differ only in their case (in TokenPropertiesManagementPanel.java:225)

*Modify getPropertyNames() so that it returns mixed case variable names (parser.CaseInsensitiveHashMap.java:73)

*Assets in RPToks are still being written out as MIME64 encoded text instead of as binary images (maptool.util.PersistenceUtil.java:453)

*Fix for RPToks ballooning in size by not merging old assets from file into new file (unless requested?) (rplib.lib.io.PackedFile.java:222-251)

*Remove the Macro tab and all references to macros on the token editor dialog (maptool.client.ui.token.EditTokenDialog.java)

*Disable the rest of the UI while the Test Connection is doing its thing (see MapToolFrame.showModalGlassPane.java:677). This could be done better, but is an easy quick fix for now.

Then there's the already mentioned GM-only aura patch from jfrazier and Rumble's auto-select-on-init-change patch. I also have (or will have) updates for the Spanish, Italian, and French translations! Very cool! It probably won't happen for b64, but I plan to move the translations out of the main JAR file and into a directory; that would allow updates without requiring a new build. As it is, if an update occurs to the English file, the translations will always be one step behind because they won't find out about the change until after the build is released. Separating them would let them update in parallel.

Nice work Az.

Any reason you're not giving us the "save/load maps" addon? I think that would be brilliant.

Cheers
Blakey

Changes to CaseInsensitiveHashMap will probably break using saved files from Character Tool in Map Tool. These will probably break the drag and drop from Init Tool also. So I'd like a chance to fix these problems before it is final. Will that be possible?

Ooh, I haven't looked or thought about that in weeks - you may want to take a careful look at it before committing it to the final. It wasn't in a "final" stage at last look.

Ouch! Thanks for pointing that out! I don't have either of those checked out so there were no obvious dependencies for me to notice when I did the References check...

I can leave the existing code as-is and simply add getPropertyNamesRaw() or something similar that preserves the case-sensitivity. Then the MTscript language can use that instead, perhaps even adding the corresponding MTscript macro function as well? (I don't like bloating the MTscript API unnecessarily, but I'm not sure it's a big deal.)

Does that work for you?


Are these two what you're referring to for the dnd functionality?

I'll do some more extensive testing of the saveAssets() and loadAssets() in the PersistenceUtil class, including backward compatibility of dnd data.

For the duplicate assets, I can't see how that would affect CT or IT. Basically, when MT writes out an RPTOK, it preserves the original assets and then writes any new ones. Over time the RPTOK becomes very large and yet the assets inside are not being referenced elsewhere in the RPTOK. Do you see a problem with CT or IT in that regard?


Oh, okay. Thanks for the heads-up.

That would probably be OK. But I don't mind fixing my code either. I've done it often enough that I've gotten pretty good at it.

It wouldn't actually break the compile, but it would effect how I generate the output XML. And if it doesn't match what MT is expecting MT will refuse to load it, or worse.

The last thing I did with it was send out that custom JAR file for testing, but then I never was able to actually test it. If you want to get 1.3 final out the door, I don't think select-on-initiative is important enough to worry about.

Yeah, my focus was really going to be bug fixes and very minor stuff.

RPTroll is having problems with dnd on Ubuntu, so I want to try to get that in there. I ended up with some time this evening, so I'm going to look into that.