Figure token rending order
Moderators: dorpond, trevor, Azhrei
Forum rules
Posting now open to all registered forum users.
Posting now open to all registered forum users.
Figure token rending order
If I have a Figure token on the Background layer (say, to represent a wall in the background), shouldn't it render BEFORE an Figure tokens on the Token layer?
Was trying to create something so that inside of a building, you see the walls in the background...but outside, you don't see them.
This works fine from the outside...but inside, once I'm against the "wall" (which is a Large Token) and in the top square (of its 4 squares), I get clipping on my NPC token.
Cobblestone on the ground represents the edges of the "room", the wall is the black in the background.
This is good...
This is not so good (see the clipping?)
And you can see that outside of the "room", I'm getting the effect I'm looking for (can't see the walls)...
And finally, here's the wall image itself (red background is transparent)...
Maybe there's a better way to achieve this, certainly open to that. But it seems that things on the Background should render before things on the Token layer.
Thanks!
Was trying to create something so that inside of a building, you see the walls in the background...but outside, you don't see them.
This works fine from the outside...but inside, once I'm against the "wall" (which is a Large Token) and in the top square (of its 4 squares), I get clipping on my NPC token.
Cobblestone on the ground represents the edges of the "room", the wall is the black in the background.
This is good...
This is not so good (see the clipping?)
And you can see that outside of the "room", I'm getting the effect I'm looking for (can't see the walls)...
And finally, here's the wall image itself (red background is transparent)...
Maybe there's a better way to achieve this, certainly open to that. But it seems that things on the Background should render before things on the Token layer.
Thanks!
Re: Figure token rending order
Can you upload the campaign file. Tokens on the background layer should not cover tokens on the token layer. There may be an exception having to deal with token vbl though and I'd like to see how you have your tokens set up.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: Figure token rending order
Sure...whats our preferred method for sharing files nowadays here?
Re: Figure token rending order
Yeah, that's a bug. If the image is dropped on to an iso map as a token, it keeps that z-order even when changed to the background. If you drop it as background image you won't have this problem. Unfortunately, you can't adjust the z-order once it's dropped on the token layer so the image will have to be deleted. I think this only happens for the iso map. Bring to Front, Send to Back doesn't help either.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: Figure token rending order
Hmmm, I cleared all the walls off the map, then pulled the image onto the background layer...same issue.
You're right about Bring to front/Send to back not helping, but it also doesn't seem to help if you drop it onto the background layer rather than the token layer.
I assume its something about the "Figure" type? Like the z-order doesn't care what layer its on if its a Figure token?
You're right about Bring to front/Send to back not helping, but it also doesn't seem to help if you drop it onto the background layer rather than the token layer.
I assume its something about the "Figure" type? Like the z-order doesn't care what layer its on if its a Figure token?
Re: Figure token rending order
Figure tokens should only be on the token layer. I'm not sure of the behavior if on a different layer.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: Figure token rending order
Wait, so if you want an object (Say, a pillar or a chest) to behave like a figure token (that is, allow something to pass behind it), you should be putting that on the token layer? That doesn't make sense, then pretty much all of the assets for an isometric map would go on the Token layer.
AM, is that what you're saying?
AM, is that what you're saying?
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
Re: Figure token rending order
I haven't messed with ISO but generally MapTool draws all Background objects first, then Object, then Hidden, then Token. But "walking behind" things would require drawing based on z-order across all layers. I could be wrong but I believe what AM is saying is correct.
Isometric isn't the 100% but better than nothing?
Isometric isn't the 100% but better than nothing?
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
Re: Figure token rending order
K, maybe I'm just pushing on stuff in Maptool that it isn't ready for yet...no worries.
Re: Figure token rending order
Actually isometric does work on items on other layers, although I stick to just the object layer.
I believe the problem you are experiencing is due to how the iso code works out where the base of the token sits. Your wall token's base extends below the other token. So is considered to be in front.
I have used this extensively for doors but you will have issues with wall sections if they extend over a single square.
I believe the problem you are experiencing is due to how the iso code works out where the base of the token sits. Your wall token's base extends below the other token. So is considered to be in front.
I have used this extensively for doors but you will have issues with wall sections if they extend over a single square.
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
Re: Figure token rending order
@Jagged, it sounds like we need the "footprint" to be isometric really.
Was that a can of worms? How many story points would you give it?
Was that a can of worms? How many story points would you give it?
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
Re: Figure token rending order
So maybe this would work the way I'm envisioning it if my wall section was just medium sized (like a door)? I'll fiddle around with it and see if I can get it to play nice.
Re: Figure token rending order
Setting the wall token to Medium actually did the trick. No clipping and it rendered correctly.
Room with 4 walls (DM view).
Then, in Player view, from the inside (the walls at the bottom disappear, because you wouldn't want to see them blocking the floor).
And then, if you're outside the room...
So the only thing that isn't perfect is the fact that the walls don't extend "upwards" as much as I would like...but I don't think there' much that could be done about that and it still works pretty well.
Coolness...
Room with 4 walls (DM view).
Then, in Player view, from the inside (the walls at the bottom disappear, because you wouldn't want to see them blocking the floor).
And then, if you're outside the room...
So the only thing that isn't perfect is the fact that the walls don't extend "upwards" as much as I would like...but I don't think there' much that could be done about that and it still works pretty well.
Coolness...
Re: Figure token rending order
Figure Tokens can be as high as you like. Visibility is based entirely on the footprint.xavram wrote: So the only thing that isn't perfect is the fact that the walls don't extend "upwards" as much as I would like...but I don't think there' much that could be done about that and it still works pretty well.
Coolness...