MapTool ALPHA Build 103 Development Notes
Moderators: dorpond, trevor, Azhrei
- trevor
- Codeum Arcanum (RPTools Founder)
- Posts: 11311
- Joined: Mon Jan 09, 2006 4:16 pm
- Location: Austin, Tx
- Contact:
MapTool ALPHA Build 103 Development Notes
Well, I think it's down to just polish
I'm fleshing out some of the keyboard movement stuff from the feedback we've gotten already.
I need to get with the design team to figure out the large token movement issue.
Also, a really, really big issue is updating the documentation. If anyone is so inclined to work on that, feel free. You might send a note to the forums with a link to the page you've updated so we know to go review it.
I'll also start updating the docs with what I know.
From there we'll probably have a build 102 to check some of the smoothing out, and the final large token movement tracker, then we'll make a formal release candidate.
CHECK IT OUT, there should be only one more development build until 1.0 WOOOOO (finally I'll get to work on the more interesting features again)
I'm fleshing out some of the keyboard movement stuff from the feedback we've gotten already.
I need to get with the design team to figure out the large token movement issue.
Also, a really, really big issue is updating the documentation. If anyone is so inclined to work on that, feel free. You might send a note to the forums with a link to the page you've updated so we know to go review it.
I'll also start updating the docs with what I know.
From there we'll probably have a build 102 to check some of the smoothing out, and the final large token movement tracker, then we'll make a formal release candidate.
CHECK IT OUT, there should be only one more development build until 1.0 WOOOOO (finally I'll get to work on the more interesting features again)
Dreaming of a 1.3 release
-
- Dragon
- Posts: 780
- Joined: Tue Jan 31, 2006 9:01 pm
- Location: Beneath the Aurora Borealis
- Contact:
Re: MapTool ALPHA Build 103 Development Notes
trevor wrote:finally I'll get to work on the more interesting features again
Re: MapTool ALPHA Build 103 Development Notes
The large token movement issue is that the squares that are being drawn to show the path of the token are always one square even through the token itself is 4 squares. Also, the path for the large token is always tracked through the upper left hand corner of the token. not throught the center of it.trevor wrote: I need to get with the design team to figure out the large token movement issue.
Seems there are a couple of issues revolving around things that should be token centered but are currently constrained to a grid snap point. (Light being the other)
You might be able to kill several bug/requests with one stone. Adding an additional snap point to each grid center and the center of line segment making up a grid square might be a quick solution. In effect you'd have another set of invisible grid lines in between the existing ones. The problem with this is it might confuse users who suddenly see things snapping to half grid points.
It seems the better solution in the long run is making the center point of each token a snap/anchor point. That way area of effect weapons, light, and the movement path can be 'centered' on a token.
That's my two Troll pence.
You might be able to kill several bug/requests with one stone. Adding an additional snap point to each grid center and the center of line segment making up a grid square might be a quick solution. In effect you'd have another set of invisible grid lines in between the existing ones. The problem with this is it might confuse users who suddenly see things snapping to half grid points.
It seems the better solution in the long run is making the center point of each token a snap/anchor point. That way area of effect weapons, light, and the movement path can be 'centered' on a token.
That's my two Troll pence.
- trevor
- Codeum Arcanum (RPTools Founder)
- Posts: 11311
- Joined: Mon Jan 09, 2006 4:16 pm
- Location: Austin, Tx
- Contact:
Re: MapTool ALPHA Build 103 Development Notes
Yeah, know what the problem is, what I meant is what the right answer for the solution isjay wrote:The large token movement issue is that the squares that are being drawn to show the path of the token are always one square even through the token itself is 4 squares. Also, the path for the large token is always tracked through the upper left hand corner of the token. not throught the center of it.trevor wrote: I need to get with the design team to figure out the large token movement issue.
Dreaming of a 1.3 release
- trevor
- Codeum Arcanum (RPTools Founder)
- Posts: 11311
- Joined: Mon Jan 09, 2006 4:16 pm
- Location: Austin, Tx
- Contact:
unfortunately it's a little more complicated than that. The pathing (and hence measurement) algorithms are built with one cell walks in mind. Paths are then rendered as cell paths. What happens to the path when a token is bigger than a single cell ? It gets a bit complicated. First have to figure out what it should look like. Also have to figure out what it means to move something bigger than a cell.RPTroll wrote:You might be able to kill several bug/requests with one stone. Adding an additional snap point to each grid center and the center of line segment making up a grid square might be a quick solution.
Dreaming of a 1.3 release
At least in d20 systems light isn't centered on a token, it always starts from a corner. One thing we need to do is get a better understanding of the systems that actually allow other light effects and their square patterns. Our current template drawings intentionally highlight affected squares (per d20 rules) even though most light sources would "appear" circular.RPTroll wrote:That way area of effect weapons, light, and the movement path can be 'centered' on a token.
So if you would use a light source in a system other than d20, please provide us with information about what squares would need to be highlighted for a token-centered light source.
~Giliath
Blue line is the movement tail (trail, breadcrumb,whatever).trevor wrote:You might have to define what you mean by movement tail
I think it serves to clarify "squares moved through" as an absolute path -- did I or did I not provoke from that cave troll kind of questions. The blue line may accidentally be drawn to clip corners as it is more stylized version of the path moved. Only the computer knows if the blue line actually crosses through that boundary or is just drawn to appear to pass through it.rptroll wrote: In other words, what function does the cell-filled path server that the movement tail does not?
Notes from discussion with tcroft about pathing
The distance calculation is correct and is in the upper left square (any are usable)
The rendering would also be correct if 2 things occured,
1) It was rendered from the center of the token or offset = ((token size - 1) * grid size ) / 2 (NOTE: medium creation (1-1)*GS, large (2-1)*GS)
2) The size of the drawn square was the size of the token (NOTE: there will be overlaps, but that is the most correct implementation)
Calculating the affected cells is easy
Look at the original path (from upper left) and fill in the additional cells.
Fill it will lots of little squares for now, and after we get the functionality done, we should be able to see a better L&F to implement.
The rendering would also be correct if 2 things occured,
1) It was rendered from the center of the token or offset = ((token size - 1) * grid size ) / 2 (NOTE: medium creation (1-1)*GS, large (2-1)*GS)
2) The size of the drawn square was the size of the token (NOTE: there will be overlaps, but that is the most correct implementation)
Calculating the affected cells is easy
Look at the original path (from upper left) and fill in the additional cells.
Fill it will lots of little squares for now, and after we get the functionality done, we should be able to see a better L&F to implement.
~Giliath
I call the movement tail the blue line with the red way point dots that appears when you are moving that is centered in the path shaded squares. If what folks are concerned about is the shading being the size of the token, it might be easier to take it out rather than size it properly.
But, that being said, I don't know what the original reason for the shading is so it might serve some important function.
But, that being said, I don't know what the original reason for the shading is so it might serve some important function.
- trevor
- Codeum Arcanum (RPTools Founder)
- Posts: 11311
- Joined: Mon Jan 09, 2006 4:16 pm
- Location: Austin, Tx
- Contact:
Additionally, it uses what's called A* path finding (think of Baldur's Gate and the like), it's what figures out the path a unit should take from one point to another.
Eventually the idea is to make the GM be able to create non-occupiable cells, and the token will pick she shortest path around the obsticles. That'll be super neat
Eventually the idea is to make the GM be able to create non-occupiable cells, and the token will pick she shortest path around the obsticles. That'll be super neat
Dreaming of a 1.3 release