Fog of War and Map scale

edited March 2014 in EpicTable Discussion
I'm running an old D&D module - the map takes up the better part of a 8.5x11 sheet: 42 by 33 200-byte grid squares in EpicTable. I've entered it into EpicTable (after a few attempts :)), but the fog of war feature only covers about the top left 40% of the map.



I should note that in 100% view, I can only see a 25 by 24 grid: the rest of the map vanishes (can't be scrolled to). I'm sure it's not coincidence that this area matches the Zone of War coverage.



Is this expected behaviour? I acknowledge that the map is probably larger than intended; would it be possible to ask what the map size should be before starting? However, I've used the "old-school" solution that John mentioned in a post - created a pen 200 by 200 to block out squares that need to be hidden that aren't covered by the fog of war.



One hint that I can offer (that's probably already well known) - I drew most of the map with the 200x200 grid. For areas that weren't square (insets for fireplaces, for example), I would change the grid to a 50x50, to allow me to draw a fixed distance in (e.g, indent 5' for the fireplace, and start it 2.5' in from the end of the wall).



Vince.

Comments

  • Vince, would I be correct in interpreting this as your drawing the whole old school map on a texture-backed EpicTable map? That's a lot of drawing....



    I'm sure you've thought about scanning in the map--a lot of the really old school ones don't translate very nicely to electronic play. They tend to have things like irregular grids.



    Based on your description of what you're doing and the problem you're having, I think you're running into EpicTable's limitation on the size of a texture-backed surface. It's weird--I was just thinking about that limitation today and the fact that it might be unnecessary since the rewrite of the surface (i.e., maps/tabletops) code. It was there originally because the technology I was using made it complex for me to have a dynamically-sized or huge surface. So, for texture-backed surfaces, I picked 5000,5000 pixels. I presume that when you say, "42 by 33 200-byte grid squares", you mean 200x200 pixel squares, and 42x33 of them. That would give you an 8400x6600 map, so yep, it would get cutoff.



    I was thinking today, though, that this limitation is no longer necessary, and I can see what it would take to remove it.



    In the meantime, what I do, and what I'd always envisioned, is cut my map up into encounter maps. That is, I don't try to put the whole dungeon (or whatever) in one EpicTable map. I create separate maps for each encounter or each region. There's not so much zooming and panning that way.



    Finally, I have to ask...200x200 grid squares? Isn't that huge? EpicTable's default is 50, some drawing tools use 60, and the Maps of Mastery maps in the box set have 90 pixel grid squares. You're not getting many squares onscreen at once, are you?
  • > Vince, would I be correct in interpreting this as your drawing the whole old school map on a texture-backed EpicTable map? That's a lot of drawing....



    It is ... which is why I found the "erase all" misclick so problematic :)



    > I'm sure you've thought about scanning in the map--a lot of the really old school ones don't translate very nicely to electronic play. They tend to have things like irregular grids.



    I did - but I wanted to be able to move the characters about the map, and I wasn`t sure if that could be done on top of a scan.



    > Based on your description of what you're doing and the problem you're having, I think you're running into EpicTable's limitation on the size of a texture-backed surface. It's weird--I was just thinking about that limitation today and the fact that it might be unnecessary since the rewrite of the surface (i.e., maps/tabletops) code. It was there originally because the technology I was using made it complex for me to have a dynamically-sized or huge surface. So, for texture-backed surfaces, I picked 5000,5000 pixels. I presume that when you say, "42 by 33 200-byte grid squares", you mean 200x200 pixel squares, and 42x33 of them. That would give you an 8400x6600 map, so yep, it would get cutoff. I was thinking today, though, that this limitation is no longer necessary, and I can see what it would take to remove it.



    You've got it exactly - and I figured that it was an inherent limitation in the system, having pre-allocated the memory to display.



    > In the meantime, what I do, and what I'd always envisioned, is cut my map up into encounter maps. That is, I don't try to put the whole dungeon (or whatever) in one EpicTable map. I create separate maps for each encounter or each region. There's not so much zooming and panning that way.



    I could do that - but then, the movement from encounter to encounter could be problematic. I wanted to be able to show exactly on the overall map where the party was for the people playing remotely. I can also reveal any hidden or secret doors as the party passes by them, if they are found.



    > Finally, I have to ask...200x200 grid squares? Isn't that huge? EpicTable's default is 50, some drawing tools use 60, and the Maps of Mastery maps in the box set have 90 pixel grid squares. You're not getting many squares onscreen at once, are you?



    It was a cheat that I used to make drawing easier. When playing, I revert to the 50-pixel square (so that the tokens aren't too huge). However, since this is character-size, I've assigned four 50-pixel squares to represent ten feet. Therefore, for drawing purposes, using a 200-pixel square means that I can draw 10' without having to constantly check and count that I've got 4 50-pixel sides for 10 feet, so it sped up drawing. Then, for playing and character placement (or detailed drawing in less than 10' increments), I revert to 50-pixel.



    At 56%, the entire map can be displayed using the drag bars in the window. With my laptop display, I get to see an area 2400 by 1200 pixels (120' by 60').
Sign In or Register to comment.