MapTool 1.3 Development Build 63
Moderators: dorpond, trevor, Azhrei, Craig
Re: MapTool 1.3 Development Build 63
Yeah. Something like that would be good...
The guy in the green hat.
Re: MapTool 1.3 Development Build 63
So is this release stable? I'm one of the holdouts waiting for stable before I switch from
the ole 1.2.
the ole 1.2.
Re: MapTool 1.3 Development Build 63
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.
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.
Drop-In Utilities:
My Spell Manager for D&D3.5 and PFRPG
My Inventory Manager for D&D and PFRPG, but more generally useable than that.
My Message Manager -- My Top-Down D&D Token Images
and my Custom Initiative & Status/Spell-Effect Tracker (work in progress, but functional).
My Spell Manager for D&D3.5 and PFRPG
My Inventory Manager for D&D and PFRPG, but more generally useable than that.
My Message Manager -- My Top-Down D&D Token Images
and my Custom Initiative & Status/Spell-Effect Tracker (work in progress, but functional).
Re: MapTool 1.3 Development Build 63
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.
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.
Re: MapTool 1.3 Development Build 63
don't forget the italian translation. ^^
Tell me if you need the file.
Tell me if you need the file.
La nuova Era - Sito italiano dedicato a MapTool e D&D 4th edition.
Gringoire's FrameWork Il primo e unico FrameWork completamente italiano, sviluppato da un italiano.
Gringoire's FrameWork Il primo e unico FrameWork completamente italiano, sviluppato da un italiano.
Re: MapTool 1.3 Development Build 63
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.
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.
- Oompa
- Cave Troll
- Posts: 98
- Joined: Thu Nov 19, 2009 3:39 am
- Location: Europe - Netherlands - Schiedam
- Contact:
Re: MapTool 1.3 Development Build 63
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...
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...
Keep rollin them dice...
Re: MapTool 1.3 Development Build 63
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.
*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.
Re: MapTool 1.3 Development Build 63
Nice work Az.
Any reason you're not giving us the "save/load maps" addon? I think that would be brilliant.
Cheers
Blakey
Any reason you're not giving us the "save/load maps" addon? I think that would be brilliant.
Cheers
Blakey
The guy in the green hat.
Re: MapTool 1.3 Development Build 63
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?Azhrei wrote:These are the things that are the patches I'm applying:
*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)
Re: MapTool 1.3 Development Build 63
Azhrei wrote: Rumble's auto-select-on-init-change patch.
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.
Re: MapTool 1.3 Development Build 63
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...jay wrote: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?Azhrei wrote:These are the things that are the patches I'm applying:
*Modify getPropertyNames() so that it returns mixed case variable names (parser.CaseInsensitiveHashMap.java:73)
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?Azhrei wrote:*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)
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.Rumble wrote: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.
Re: MapTool 1.3 Development Build 63
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.Azhrei wrote: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...jay wrote: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?Azhrei wrote:These are the things that are the patches I'm applying:
*Modify getPropertyNames() so that it returns mixed case variable names (parser.CaseInsensitiveHashMap.java:73)
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?
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.
Re: MapTool 1.3 Development Build 63
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.Azhrei wrote: Oh, okay. Thanks for the heads-up.
Re: MapTool 1.3 Development Build 63
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.
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.