MapTool 1.3 Bugfix Build 77

[wolph42]

Ah. In that case my apos for my ignorance.

[Azhrei]

No problem. It wasn't spelled out in the OP's original post. But when he said the problem related to a "signed" JAR file, it was pretty clear to me.

[Taragnor]

Nope... I will say... there are no plans to do such in 1.3 as of right this minute(it could change tomorrow..lol)

This would certainly be a great feature to implement, since it's necessary for D&D sight.

[JonathanTheBlack]

I've played well over 100 hours of D&D 4e with MapTool without true to D&D LOS and there have been dozens, if not hundreds of LFR games as well. I guess people have forgotten how to use their eyeballs?

[usc]

With all the wonderful enhancements to the program, it's strange that the one feature I am most happy to see was setTokenPortrait() . My shapeshifters no longer need keep the same face all the time. (yes, I know it can be manually changed, but the change form macros are changing all the other relevent stats and the token image at the same time, it seemed irritating to have to change it by hand).

Great work on the prudct by the way. I'm going back to lurking now.

[jfrazierjr]

I agree about it not being "required". Necessary is a highly subjective term.

[Azhrei]

With all the wonderful enhancements to the program, [...]

Great work on the prudct by the way. I'm going back to lurking now.

Thanks. But you don't need to lurk all the time. We're always interested in your input!

I agree about it not being "required". Necessary is a highly subjective term.

Heh, exactly.

But I do understand the players who position their token at a corner and can't see around the corner because of VBL. So they're forced to move their token out one square, expose, then move back. So while the current vision stuff is more accurate from a realism standpoint, it's a major drag from the standpoint of usability in-game.

I never did do my timings the other night. I'll set that up now...

[aliasmask]

I never played 4e, but now I understand why CiF made the peek option for his movPad lib.

One thing I ran across while creating my first maps was I was making my walls cover 1 unit of space and then I would put VBL in center of wall. That essentially allowed me to see around corners.

[jfrazierjr]

Heh, exactly.

But I do understand the players who position their token at a corner and can't see around the corner because of VBL. So they're forced to move their token out one square, expose, then move back.

But thats not what the original question was. The question was about being able to do lines to points as a tool.

So while the current vision stuff is more accurate from a realism standpoint, it's a major drag from the standpoint of usability in-game.

I never did do my timings the other night. I'll set that up now...

I was thinking the other night that if timings were not horribly bad, "I"(meaning in my own personal build) might actually do 8 points. x,y; x+1,y; x,y+1; etc. this would account for cases where the VBL is on the point vertex of the token footprint's bounding box by moving the start point over one. that would allow me to get around the whole "almost" thing but it really is dependent on the timings and how much CPU that sucks up. Does that make sense?

[dorpond]

Um, why isnt the announcement section updating the 'last post' date? I had no idea b77 was released and my guess is that many others dont either. Shows me a date of nov21

[DarkWiz58]

.
During a game yesterday we had to stop play while using b77.

The changes to LOS and VBL are very nice and add a sense of greater spookiness to the crypt the group currently occupies.

However b77 seems to have broken things that used to work fine in Rumble's 507 framework.

Some things that were problems:

-tokens got lost in the VBL "barrier" even though the square was not totally obscured; previously a player could pull his token out of limbo if there was any visible part of it to grab onto.

-some players, and most of the NPCs used yesterday could not use the Rumble End Turn control: a java err and stack backtrace resulted.

-Rumble uses icon badges to indicate a wider variety of Conditions on tokens than are found in the basic MT set. These indicators on the tokens did not appear when more than one was required on the same token, and none of the ones showing in our game vanished at the correct time.



With a little difficulty I can PM a copy of the stack trace seen by the DM on End Turn. However at least one player saw Errs+stacktrace and I can't get those bc they were tossed by the human player.

We are dropping back to 76 to play. As a side note which possibly is not a bug, exported maps and saved token files from 77 cannot be loaded by 76, so the game needs hand tweaking on the old maps to show the minimal progress made by the players yesterday.

These are in my opinion errors classified as Severe and need to be addressed right away.

PM if questions.

[jfrazierjr]

-tokens got lost in the VBL "barrier" even though the square was not totally obscured; previously a player could pull his token out of limbo if there was any visible part of it to grab onto.

Hmmm not sure exactly what the problem might be. I just started two instances and can't recreate. As a connected player, I could move the token from out of VBL as long as I could see the token(this requires the centerpoint of vision being outside the VBL or the token is not visible to the player)

-some players, and most of the NPCs used yesterday could not use the Rumble End Turn control: a java err and stack backtrace resulted.

Yes, please send whatever stack traces you have.

[Rumble]

As a random "wondering," what new macro functions were added in b77? Is there any possibility I'm redefining a newly added function in my framework, that somehow causes consternation and great gnashing of teeth in MT?

[Azhrei]

this would account for cases where the VBL is on the point vertex of the token footprint's bounding box by moving the start point over one. that would allow me to get around the whole "almost" thing but it really is dependent on the timings and how much CPU that sucks up. Does that make sense?

I didn't use the corners in my testing. Instead I used the centerpoint of each side. Doesn't really matter I suppose.

I was surprised -- the vision stuff is fairly fast. My timings wrapped around the calculateVisibility() method only required 29ms for all four points. Moving a single Large token around was just as fast AFAICT. I have a few maps with complex VBL and that's where I tested.

There were a number of strange things that I can't explain however. For example, with the map set to Vision>Night, I was getting the wrong area showing up as visible. Probably a different section of code being used (obviously!) but I didn't spend the time to figure out where. But that makes me wonder even more about the current code base since it shouldn't be duplicating calls to that method I would think...

Edit: Ah, maybe it was my light sources. I may not have had a light source around the corner where I was expecting an area to be visible. Yeah, that's probably it.

-tokens got lost in the VBL "barrier" even though the square was not totally obscured; previously a player could pull his token out of limbo if there was any visible part of it to grab onto.

As jfrazierjr has commented, tokens are only selectable if their centerpoint is outside of VBL. It has always been thus.

As a side note which possibly is not a bug, exported maps and saved token files from 77 cannot be loaded by 76,

There is never any reason to expect backward compatibility. Adding new features means those features must be represented in the external files. And code written two months ago is not going to have any clue about such things. I plan to modify the way external files are created in late builds of 1.4 and it might help with this, or it might not. It depends on how it goes when I actually get into the implementation.

As you said, stick with b76. It is disappointing that none of the testers ran across this though, although we don't usually test frameworks just the core code.

[jfrazierjr]

this would account for cases where the VBL is on the point vertex of the token footprint's bounding box by moving the start point over one. that would allow me to get around the whole "almost" thing but it really is dependent on the timings and how much CPU that sucks up. Does that make sense?

I didn't use the corners in my testing. Instead I used the centerpoint of each side. Doesn't really matter I suppose.

I was surprised -- the vision stuff is fairly fast. My timings wrapped around the calculateVisibility() method only required 29ms for all four points. Moving a single Large token around was just as fast AFAICT. I have a few maps with complex VBL and that's where I tested.

Sweet!