MapTool 1.3 Development Build 48

[n3phrit]

Aha. ok, so that is why I spent 2 hours around my macros using rude words all around?!! I know this is a development build, but this is just ridiculous...

In a meantime, I found another bug. I was not able to get more than 4 property strings out of macro.return (via getStrProp()). Any help?

[Rumble]

Aha. ok, so that is why I spent 2 hours around my macros using rude words all around?!! I know this is a development build, but this is just ridiculous...

In a meantime, I found another bug. I was not able to get more than 4 property strings out of macro.return (via getStrProp()). Any help?

Do you mean you have four proptery strings embedded within another string property, or you can only get four items out of a property string you pass back to a macro?

[PyroMancer2k]

Aha. ok, so that is why I spent 2 hours around my macros using rude words all around?!! I know this is a development build, but this is just ridiculous...

In a meantime, I found another bug. I was not able to get more than 4 property strings out of macro.return (via getStrProp()). Any help?

Well the problem isn't so much that it's a development build as it is also a community project. What I mean by that is people come and go along the way. They contribute some features to help improve MT to trevor and he then puts them in the next build along with whatever else he was planning. So trevor has the final say in things.

Well k.fan the person who wrote those said he submitted the changes to trevor and assumed they were going into the next build so he updated the docs for the functions he wrote. The problem is they didn't get put in and from the sounds of things they seem to have been "lost". Well k.fan said he would resubmit them for the next build but then he vanished from the forums. Last time I checked he hasn't even logged in since the forum moved.

As for you macro.return thing I have no clue on that I've never used it to return large strProps only short list or strProps of 2-3 items.

[n3phrit]

Do you mean you have four proptery strings embedded within another string property, or you can only get four items out of a property string you pass back to a macro?

I am sending list of 6 items in macro.return (checked twice)
it is like "name=foo; damage=1d6e; size=1; in=0; oc=0; id=3"
if I use more than 4 getStrProp() calls macro stop working without error msg.

Well k.fan the person who wrote those said he submitted the changes to trevor and assumed they were going into the next build so he updated the docs for the functions he wrote.

I think that thing are a bit unorganized around here. There are much bigger project around the world that has no such issues. Even javadocs would be enough at least to generate from the code.

[Azhrei]

I agree about the Javadoc. There isn't much self-documentation inside the code and there should be.

At some point, I'm going to sit down and write up Javadoc for the parts of the code that I can understand. (Which doesn't include the light/vision stuff!) But it's a daunting task as there is A LOT of code in the MapTool base, not including the parser, dice roller, and a bunch of the other libraries.

If you scan the forums, you'll find there's been a lot of talk by users about documentation, and a few of the developers have put together some really good docs that are being set up as wikis or Google docs. But it's definitely an uphill battle.

[PinkRose]

Your post made me very upset.
If you don't like the way the project is run, do something about it or leave.

Volunteers need not be put down and Trevor could erase the whole project if he wanted to.
You spent 2 hours of your life on this. Sorry. Here's a cookie.

I hope you understand how this works.

If you don't like the program or the effort that people make here, go buy the WotC version.

[n3phrit]

I didnt want to be bad mannered and I definitely do support whole project.
BUT it does not mean that generating obsolete (or none) documentation
is something somebody should be proud of. Or any other bad habits should be
overlooked. At the end, we all have the same goal, make MT better and
accessible for more people. I am just frustrated that after spending of several
days on doing MACROs (which is main feature why I am learning this, before I used
1.3.39.) I see a lot of potential, but somehow low focus on code quality. That is
my observation, so dont be too overprotective about yourself.

[Orchard]

I didnt want to be bad mannered and I definitely do support whole project.
BUT it does not mean that generating obsolete (or none) documentation
is something somebody should be proud of. Or any other bad habits should be
overlooked. At the end, we all have the same goal, make MT better and
accessible for more people. I am just frustrated that after spending of several
days on doing MACROs (which is main feature why I am learning this, before I used
1.3.39.) I see a lot of potential, but somehow low focus on code quality. That is
my observation, so dont be too overprotective about yourself.

Hmph.

Actually, I see that their is a focus on code quality...don't assume that just because updates, documentation and such don't happen at the speed you would like, that they aren't happening at all. Again, it is a community project, and as such it is as good and as focused on quality as the community wants it to be. If we want good documentation, then we need to make it happen. Waiting for it to magically appear while simultaneously expecting the programmers to give us a free product is a bit naive.

[Azhrei]

Heh, yep. The people who complain are in the 99% group who don't step up to solve the problem.

This is prevalent at all layers of society. Every once in awhile you'll read about someone doing something out-of-character, like a local couple who donated $270,000 to a local school so that the staffers who work there would have a Christmas bonus this year. But that's the exception, not the rule.

I'm guilty as well. I make a few mods to MapTool to make it better for me (import and export of maps, for example) but I don't contribute those back to the core. I haven't used SVN much yet and I'm not familiar with building patch sets in Eclipse (although I'm quite familiar with diff, patch, quilt, and the rest of the tools).

Okay, so I've been shamed into helping. I'll contribute the map patches to Trevor and put them on my web site as well (link forthcoming). And I've added a page to Craig's wiki for macro documentation and I'll try to write some more.

Perhaps n3 would like to jump on the wiki and explain the problems he had and how to solve them? That kind of this is perfect for the FAQ or HOWTO section of the wiki...

[Rumble]

Do you mean you have four proptery strings embedded within another string property, or you can only get four items out of a property string you pass back to a macro?

I am sending list of 6 items in macro.return (checked twice)
it is like "name=foo; damage=1d6e; size=1; in=0; oc=0; id=3"
if I use more than 4 getStrProp() calls macro stop working without error msg.

What is the entire macro? I have seen this behavior when you simply end up with too much stuff inside of a { } block. It doesn't take much sometimes - I have choked what seems like relatively short macros with the addition of just one additional line. On the other hand, I have used several macros that get or set dozens of properties without trouble.

One thing to consider: if you are passing in a large string property list, and you are doing things like:

Code: Select all

[h:name=getStrProp(passStrProp, "name")]
[h:damage=getStrProp(passStrProp, "damage")]
.
.
.

just use

Code: Select all

[h:varsFromStrProp(passStrProp)]

This will generate a series of variables that have the same name as each key in the string property list, and assign the value from each item in the string property list. You don't have to do any getStrProp() calls.

Perhaps you're already doing this, though, in which case it sounds like you're flirting with the complexity limit of the macro parser and will need to refactor your macro to make it streamlined.

[Rumble]

Performance Question:

I have a campaign loaded and I'm seeing very slow performance on two operations in particular. I have a set of 16 tokens on one map (just practice tokens for messing with). If I drag-select them, it takes about 10 seconds from the moment I've described the selection box with the mouse to the moment they appear to be selected. If I then hit the Delete key, it takes about 10 seconds from the moment I do so until the tokens are actually deleted.

Is this typical? If so, can that be improved in future builds? And if not - what should [i]I[/i] do to improve performance on my machine?

I'm running b48, standard stack, 1024MB allocated memory. The campaign file has 5 maps, a few tokens (except for these 16 tokens I was messing with), and is 2,212MB.

[trevor]

@n3phrit I can certainly appreciate your frustration. Documentation and code comments have been on the back burner for too long. The problem is that this dev build has gone on far too long. Typically I spend the last part of a dev cycle polishing and tidying up, but we haven't gotten to that point in a while.

I've been working on getting things settled so 1.3 can finalize, and the clean up can commence. Please bear with us.

Fortunately the community is very willing to help out when there's a question, so don't feel bad about posting a specific question.

[dorpond]

Performance Question:

..and is 2,212MB.

Wow! and I thought my 33meg campaign file was big!

When you look at the lower right hand corner, you will see two memory values xxx/yyy. If the x value goes higher than the y value (which should be 1gig because that is what you said you were running), then Maptool/Java will crash. Have you looked at these values throughout your troubleshooting process?

Also, Trevor and I identified yesterday just how bad color lighting affects overall performance (which really stinks actually since I play D&D and dim lighting is important to see); do you have color lighting on the map by chance where performance is terrible?

I have never loaded campaign files that large. Perhaps there are others that have who can pipe in on this. Out of curiousity, what are the dimensions of those maps?

[Rumble]

Performance Question:

..and is 2,212MB.

Wow! and I thought my 33meg campaign file was big!

When you look at the lower right hand corner, you will see two memory values xxx/yyy. If the x value goes higher than the y value (which should be 1gig because that is what you said you were running), then Maptool/Java will crash. Have you looked at these values throughout your troubleshooting process?

Also, Trevor and I identified yesterday just how bad color lighting affects overall performance (which really stinks actually since I play D&D and dim lighting is important to see); do you have color lighting on the map by chance where performance is terrible?

I have never loaded campaign files that large. Perhaps there are others that have who can pipe in on this. Out of curiousity, what are the dimensions of those maps?

Sorry, that should be 2,212KB. In other words, 2 megs. Whoops

No colored light, some topology, the maps are JPG images with a few items on the object layer. The map in question is just "Grasslands" with a bunch of tokens on it and some drawing objects, like so:




As for the memory usage, I've watched, and it usually says something like 26M/57M or so. When I initiate the select process, it pops up to 40/60 or so, but that's it. It still takes 10+ seconds to select the 20 tokens.

Edit: Additional testing - in a campaign with no maps save the default, and all settings aimed at high performance:

Selecting 2: no appreciable delay
Selecting 4: no appreciable delay
Selecting 8: 1 second or so
Selecting 16: about 3 seconds between dragging box and tokens showing selected
Selecting 32: 10 seconds or more

Edit again: ...aaaaand it seems to have something to do with token macros or the information contained in the token. I created a blank map and dragged new tokens onto it. These tokens are not configured - they have mostly empty properties and no macros. There is no appreciable delay in selecting them, even in numbers beyond 64. By contrast, the tokens I was testing with (the "M") tokens have around 15 macros on them.

[dorpond]

Rumble, can you send that campaign to Trevor so he can profile it?