PDA

View Full Version : Modules, maps, Best Practice?



celestian
February 24th, 2017, 20:26
So, I was thinking of bundling my custom maps for ToEE into a module and making them available. I'm curious what the "best practice" is for such a thing? What is standard filesize? What about map size? The pixel width on grids varies also because I was trying to make the maps as high detail as I could and CC2/3 would barf at a certain point and die. So, some are 50, some are 75/etc.

Would it also make sense to split them into DM and player versions? I build all my maps with 2 different types so that I can see the secret doors and "critters" that should be in the area. It's less useful in FG since you can't layer/hide the DM map and see it while the players just see theirs but perhaps there is a use I am not seeing.

Zacchaeus
February 24th, 2017, 21:12
Generally keep the maps to below 1Mb in size preferably lower. Output as jpg of medium or lower quality if necessary. There's some discussion that maps sizes over 2048x2048 cause problems but I do not subscribe to that - size is more an issue that resolution. You can export from CC at the best quality PNG that it can stand and then re-export (and resize if needed) in GIMP or Photoshop as .jpg file.

FG's standard grid is 50px per 5' so it's usually best to stick to that unless there are compelling reasons not too. Yes, have DM and player versions. Player versions should be gridless (i.e. don't export from CC with the grid on - turn it off in effects before you export). Usually you can put a guide square somewhere on the map (top left or top right) which can be used to align the FG grid. Before exporting from FG to a module draw the FG grid on the map.

I think that's all I can think of off hand.

damned
February 24th, 2017, 22:09
Place FG grids on them as well - especially if they are of two different resolutions.

celestian
February 24th, 2017, 22:13
Generally keep the maps to below 1Mb in size preferably lower. Output as jpg of medium or lower quality if necessary. There's some discussion that maps sizes over 2048x2048 cause problems but I do not subscribe to that - size is more an issue that resolution. You can export from CC at the best quality PNG that it can stand and then re-export (and resize if needed) in GIMP or Photoshop as .jpg file.

FG's standard grid is 50px per 5' so it's usually best to stick to that unless there are compelling reasons not too. Yes, have DM and player versions. Player versions should be gridless (i.e. don't export from CC with the grid on - turn it off in effects before you export). Usually you can put a guide square somewhere on the map (top left or top right) which can be used to align the FG grid. Before exporting from FG to a module draw the FG grid on the map.

I think that's all I can think of off hand.

I'll load up CC3+ and see if it can cope with it better and see how it turns out. Thanks for the details.


Place FG grids on them as well - especially if they are of two different resolutions.

Good idea. I think I've got one map that barfs cc3 on 50 pixel size (hommlet town map?) so if I preset the grid in FG they won't need to figure it out.

damned
February 24th, 2017, 22:24
For huge maps you might like to have an overview map that stays within 2000x2000px and has pins to higher res maps of smaller sections of the village... if that makes sense....

Trenloe
February 25th, 2017, 02:43
There's some discussion that maps sizes over 2048x2048 cause problems but I do not subscribe to that - size is more an issue that resolution.
Ooohhh, bold statement my skirted friend!

I thought we'd been through this before - with lots of evidence to support it. File size effects only one thing - the time it takes to share the map to the players, that's it. File resolution (width x height in pixels) effects how much memory the image takes up in FG. Fantasy Grounds has very limited memory, and can crash when that limit is approached, so the strong recommendation is to keep all maps below 2048x2048 pixels. It's "OK" to have the odd map a bit larger than this - say a regional map that you keep referring to, or a large dungeon map. But don't have more than a couple of maps over 2048x2048 pixels, and definitely don't have any double that or more.

Trenloe
February 25th, 2017, 02:46
Options for large maps (expanding on what damned mentions in post #5) and discussions of the impact of them, here: https://www.fantasygrounds.com/forums/showthread.php?36330-Player-s-FG-folder-and-pre-download-images&p=317064&viewfull=1#post317064 And the rest of that thread.

Bidmaron
February 25th, 2017, 02:58
FGU will eliminate this memory problem, right? Obviously, there is still a bandwidth problem with high res images during sharing with players, but the program memory limit will go away right? (well, as much memory as your computer has anyway, and i presume it will page out to disk if you exceed that).

damned
February 25th, 2017, 03:54
FGU will eliminate this memory problem, right? Obviously, there is still a bandwidth problem with high res images during sharing with players, but the program memory limit will go away right? (well, as much memory as your computer has anyway, and i presume it will page out to disk if you exceed that).

Id suggest that the "current limits will be increased" but there will still be plenty of practical limits and things like the GM has 32GB memory but Player C still only has 4GB.
More importantly than the actual limits - it should be more efficient at how it stores stuff in memory.

Zacchaeus
February 25th, 2017, 08:40
Ooohhh, bold statement my skirted friend!

I thought we'd been through this before - with lots of evidence to support it. File size effects only one thing - the time it takes to share the map to the players, that's it. File resolution (width x height in pixels) effects how much memory the image takes up in FG. Fantasy Grounds has very limited memory, and can crash when that limit is approached, so the strong recommendation is to keep all maps below 2048x2048 pixels. It's "OK" to have the odd map a bit larger than this - say a regional map that you keep referring to, or a large dungeon map. But don't have more than a couple of maps over 2048x2048 pixels, and definitely don't have any double that or more.

See it is worth saying controversial things because you then get lessons from Trenloe :D

It's just down to my experience; big maps (in terms of resolution) can take a looong time for the players to load (because they are also big in terms of size) but once d/l everything seems fine.

celestian
February 26th, 2017, 00:13
I guess the 8250x6050 will not work to well then.

https://drive.google.com/file/d/0B53Z1k8zPr4cdklVM0N5aDE3Uk0/view?usp=sharing

damned
February 26th, 2017, 00:32
IMO there is no need to have a map like this gridded for movement unless there is a large scale assault involving many parties.
Id have this map at 1000px wide and Id make smaller maps of each area with appropriate grid sizes.

Trenloe
February 26th, 2017, 01:16
I guess the 8250x6050 will not work to well then.

https://drive.google.com/file/d/0B53Z1k8zPr4cdklVM0N5aDE3Uk0/view?usp=sharing
Yeah, far too big. Have a small scale overall map and link that to a bunch of sub maps that are full scale. Info here: https://www.fantasygrounds.com/forums/showthread.php?36330-Player-s-FG-folder-and-pre-download-images&p=317064&viewfull=1#post317064

celestian
February 26th, 2017, 02:47
IMO there is no need to have a map like this gridded for movement unless there is a large scale assault involving many parties.
Id have this map at 1000px wide and Id make smaller maps of each area with appropriate grid sizes.

I tend to grid everything unless it's a regional map. This is the city map. To make that 50px grid thats only way I could do it. I did get it to load up (was testing before I saw the size restrictions mentioned) and I didn't crash or anything. The map filesize is 2meg.

Not gridding it and just making it large enough so things look good might work out. I'll poke at it and see. Otherwise I'll do the points that load other maps but I'd like to avoid that if I can.

I've got a map for barrowmaze (a wide dungeon instead of deep) and it's about 6kx5k for a 10px map I think ;(

Trenloe
February 26th, 2017, 03:00
...(was testing before I saw the size restrictions mentioned) and I didn't crash or anything.
Just doing a basic test isn't really going to prove anything. When running a game you'll have lots of other resources enabled within FG, all of them taking up memory, which slowly climbs the longer the game runs. Hence the recommendation on keeping all maps below 2048x2048 pixels. Your large map will work OK at the beginning of a session, but if the GM or a player opens it after a few hours gaming then it's going to tax the system a lot - and can cause FG to crash (with the possibility of corrupting/losing data if it's the GM that crashes).

We're not just throwing these numbers out there just for fun. These are recommendations that come direct from the main FG developer and are based off many, many hours experience of running and supporting Fantasy Grounds. I've seen many people come on these forums complaining of crashes, exception errors, etc. - all due to FG running out of it's limited memory. The big hog of that memory is images. Keep them smaller than 2048x2048 (even smaller if there's no need for the image to be large - e.g. character images don't need to be huge) and minimise the chance of FG running out of memory during your games.

celestian
February 26th, 2017, 03:30
Just doing a basic test isn't really going to prove anything. When running a game you'll have lots of other resources enabled within FG, all of them taking up memory, which slowly climbs the longer the game runs. Hence the recommendation on keeping all maps below 2048x2048 pixels. Your large map will work OK at the beginning of a session, but if the GM or a player opens it after a few hours gaming then it's going to tax the system a lot - and can cause FG to crash (with the possibility of corrupting/losing data if it's the GM that crashes).

We're not just throwing these numbers out there just for fun. These are recommendations that come direct from the main FG developer and are based off many, many hours experience of running and supporting Fantasy Grounds. I've seen many people come on these forums complaining of crashes, exception errors, etc. - all due to FG running out of it's limited memory. The big hog of that memory is images. Keep them smaller than 2048x2048 (even smaller if there's no need for the image to be large - e.g. character images don't need to be huge) and minimise the chance of FG running out of memory during your games.

I get that. I wasn't testing it to see if it crashed. I was testing the grids and how it would look in FG. As I said, before I saw the bit about recommended size limits.

Trenloe
February 26th, 2017, 03:30
Cool. :)

Full Bleed
February 26th, 2017, 03:47
File size effects only one thing - the time it takes to share the map to the players, that's it. File resolution (width x height in pixels) effects how much memory the image takes up in FG.
Truth.


Fantasy Grounds has very limited memory, and can crash when that limit is approached
The 32bit limitation is a killer when it comes to large image files. I take it FGU will be 64 bit? If so, this issue is going to go away.



I guess the 8250x6050 will not work to well then.

https://drive.google.com/file/d/0B53...ew?usp=sharing
That's a fun Hommlet map, thanks for sharing.

But my favorite is still the one Blando did... which, coincidentally enough, I just recently purchased.

Check it out: https://theredepic.bigcartel.com/product/the-village-of-hommlet-digital-download

celestian
February 26th, 2017, 04:21
Truth.


The 32bit limitation is a killer when it comes to large image files. I take it FGU will be 64 bit? If so, this issue is going to go away.



That's a fun Hommlet map, thanks for sharing.

But my favorite is still the one Blando did... which, coincidentally enough, I just recently purchased.

Check it out: https://theredepic.bigcartel.com/product/the-village-of-hommlet-digital-download

Yeah, his are much more artsy than mine. I went for direct duplicate of the original in CC3. I imagine his is photoshop or something? They look great. I'm more of a system admin/programmer than graphical design so I just made them with the idea of functionality and held true to the original (scales/etc). If he had done the Moathouse/dungeon and Temple plus those 4 levels I'd snag'm in a heartbeat and save myself the work ;)

Varsuuk
February 26th, 2017, 04:34
Yeah, his are much more artsy than mine. I went for direct duplicate of the original in CC3. I imagine his is photoshop or something? They look great. I'm more of a system admin/programmer than graphical design so I just made them with the idea of functionality and held true to the original (scales/etc). If he had done the Moathouse/dungeon and Temple plus those 4 levels I'd snag'm in a heartbeat and save myself the work ;)

Please (if OK by you!) continue posting ToEE maps etc if you feel so inclined. I LOVE the module and it is my dream to get it into FG format someday!!

I suck at art. I did buy CC3+ this past TurkeySale so I have it and am occaisionally trying to make time to go through tutorials. So, if you don't mind other GMs leeching your creative goodness, I will do so for my personal use :)

One of my first projects for CC will be working on those sort of maps but I think it won't be for a few months yet based on my other TODO queue :(

Varsuuk
February 26th, 2017, 04:35
Truth.


The 32bit limitation is a killer when it comes to large image files. I take it FGU will be 64 bit? If so, this issue is going to go away.



That's a fun Hommlet map, thanks for sharing.

But my favorite is still the one Blando did... which, coincidentally enough, I just recently purchased.

Check it out: https://theredepic.bigcartel.com/product/the-village-of-hommlet-digital-download

That looks worth getting too. I assume there are different resolution versions in there? The one he listed, if I tried using it, would fly in the face of this discussion :)

Varsuuk
February 26th, 2017, 04:42
That looks worth getting too. I assume there are different resolution versions in there? The one he listed, if I tried using it, would fly in the face of this discussion :)

Ugh... ok - its apparantly only HQ as he mentions:

"This HQ file is 5000 x 4000 pixels and is ready for use on both tablet and screen. Spice up your game with a perfect map for a country campaign!"

Wahhhhhh

celestian
February 26th, 2017, 05:10
Please (if OK by you!) continue posting ToEE maps etc if you feel so inclined. I LOVE the module and it is my dream to get it into FG format someday!!

I suck at art. I did buy CC3+ this past TurkeySale so I have it and am occaisionally trying to make time to go through tutorials. So, if you don't mind other GMs leeching your creative goodness, I will do so for my personal use :)

One of my first projects for CC will be working on those sort of maps but I think it won't be for a few months yet based on my other TODO queue :(

I've mapped everything for ToEE (the AD&D version) and a few other adventures I've run online over the years.

Feel free to use any of these. Someday I'll get the mod thing but if you have a need... you'll probably need to use gimp to shrink the filesize down. I didn't have an issue with that in maptools (size of map or the actual filesize) so I think at least one is 15 meg.

https://drive.google.com/open?id=0B53Z1k8zPr4cfkxZZFlIb21IeFNneFV0WTNIWDBxM S1uWktvbi16ZUxQUUhlVUJiY0xRM1k

If you want the FCW files for them for CC3 let me know and I'll put them up tho I'm not sure how well they'll turn out as some of the maps I used placeables that are not part of CC.

Some of the maps are better than others. I was learning over the years while I was making them.

Bidmaron
February 26th, 2017, 13:43
....
The 32bit limitation is a killer when it comes to large image files. I take it FGU will be 64 bit? If so, this issue is going to go away.
....[/url]

The only thing that will go away is the memory crashes and the non-responsiveness during single-threaded downloads. FG is a client-server system. It will still be very important to limit graphic size, as most folks have fairly low upload speeds to push the graphics to the clients.

seycyrus
February 26th, 2017, 15:50
...
If you want the FCW files for them for CC3 let me know and I'll put them up tho I'm not sure how well they'll turn out as some of the maps I used placeables that are not part of CC.
...

Yes, PLEASE!

Trenloe
February 26th, 2017, 16:46
Ugh... ok - its apparantly only HQ as he mentions:

"This HQ file is 5000 x 4000 pixels and is ready for use on both tablet and screen. Spice up your game with a perfect map for a country campaign!"

Wahhhhhh
Why the "Wahhhhhhh"? You just need to reduce the resolution (and JPG quality) in any standard image application. This is what *every* FG GM should do when they download/create images for FG - look at the resolution, reduce it as necessary; *and* save as JPG with a quality between 50-75 to reduce the file size.

Full Bleed
February 26th, 2017, 17:49
If he had done the Moathouse/dungeon and Temple plus those 4 levels I'd snag'm in a heartbeat and save myself the work ;)
Prepare to be happy.

Huge dump of ToEE maps here:

The Inn of the Welcome Wench, Nulb, Waterside Hostel, Moathouse, Moathouse Dungeon, Temple grounds/gate, 4 Temple dungeons, and some other assorted maps:

https://cultofj.com/wp-content/uploads/2016/05/

There are a lot of "detail" maps in that directory... but look hard enough and you'll find the high rez full sized maps (often with GM and night/day variants)... some probably too high rez for FG so you will probably need to slim them down.


I only see the fire node in there though... I thought I had the others somewhere... *shrug*

Full Bleed
February 26th, 2017, 18:29
FG is a client-server system. It will still be very important to limit graphic size, as most folks have fairly low upload speeds to push the graphics to the clients.
Well, let me put it this way, I use a 9500x7000 DPI Greyhawk world map in another client-server VTT (with over 200 tokens deployed on it). The map itself is only 9 megs compressed... maybe another 4-5 megs in tokens (it's mostly text and icons in this case). You don't need much upload speed to push that to 4-5 people. Go get a drink... talk about the latest Game of Thrones for a couple minutes... transfer done.

I'd expect to have no trouble using the same map in FG once 64 bit Unity is on deck. Would I make a habit of pushing 15+meg maps all the time? Probably not. A map half that size (4750x3500) would use 1/4th the memory footprint and be around 1/3rd the physical size (just checked, it's 3.2 megs)... and while still too big for FG (currently) would still make for a (comparatively) high resolution affair that I think will fall well within the tolerance level and capabilities of modern day file transfer speeds.

Bidmaron
February 26th, 2017, 18:35
Full Bleed, FG is the only VTT (I believe) that uses the DM's computer as the server. Every other one uses the cloud and their own servers with ultra-high speed connections. So FG may not perform as well as those other systems. It is the weakness of the model FG uses. However, the good thing is that FG is not dependent upon the cloud or any other server. Not that it is likely, but if SmiteWorks ever went down, the only thing you would lose is the ability to connect using the four word system (well, demo license users would be affected I guess because there has to be a license check to ensure the GM has an ultimate license). Users would have to connect using the IP address.

All the other VTTs out there if the cloud host went down, so would everyones' games.

Trenloe
February 26th, 2017, 18:44
MapTool is client/server. d20Pro is client/server. And I'm sure there are others, those are the only two I've personally used that are client/server other than FG.

Bidmaron
February 26th, 2017, 18:51
Forgive me, Trenloe. I thought I remember in another thread that the claim was that FG was the only one using GM's computer as the server.

Blood, sorry about that. Once Unity is out, it is probably not unreasonable to expect similar performance between any client-server VTT. But you have to remember that FG is pushing a lot of other data (depending on what you share) than the other ones (but that data is generally a lot less bandwidth than a high res map).

FG might even do better if the other VTTs aren't implementing an intelligent cache like FG does.

celestian
February 26th, 2017, 20:26
Prepare to be happy.

Huge dump of ToEE maps here:

The Inn of the Welcome Wench, Nulb, Waterside Hostel, Moathouse, Moathouse Dungeon, Temple grounds/gate, 4 Temple dungeons, and some other assorted maps:

https://cultofj.com/wp-content/uploads/2016/05/

There are a lot of "detail" maps in that directory... but look hard enough and you'll find the high rez full sized maps (often with GM and night/day variants)... some probably too high rez for FG so you will probably need to slim them down.


I only see the fire node in there though... I thought I had the others somewhere... *shrug*

Yeah, several of those are my maps (at least the ones I peeked at minus the Hostel) ;) Linked previously. Glad someone was able to use them other than me!

At some point I'll clean them up for FG and make a .mod of them.

Varsuuk
February 26th, 2017, 23:55
Why the "Wahhhhhhh"? You just need to reduce the resolution (and JPG quality) in any standard image application. This is what *every* FG GM should do when they download/create images for FG - look at the resolution, reduce it as necessary; *and* save as JPG with a quality between 50-75 to reduce the file size.

<emilylitella>See, told you I suck visually...assumed taking a lossy standard and reducing/reprocessing would cause noticeable degradation. I thought "reducing" jpg quality was referring to when creating jpg from the original sources...my bad</emilylitella>

For buck and quarter, will buy for visual to players if nothing else! Awesome.

(PS - Yup, having no trouble, or little - running around various layers, with ruleset code ... except figuring out how to create window elements and positioning, offsets etc... yeah a huge part of ruleset, but I'm more the codey/transformy type. Think I will avoid the rabbit hole I wasted time in today and make horrid square boxes with big left side labels in no arrangement just to get the coding part underway then re is it UI at end! ... tangent from my efforts today)

Tailz Silver Paws
February 27th, 2017, 10:54
I find having the grid switched on, messes up tokens. FG seems to want to scale tokens to fit a grid square. Which messes up tokens that are larger than a grid square (eg: a large table). Is there a way around this?

damned
February 27th, 2017, 11:31
I find having the grid switched on, messes up tokens. FG seems to want to scale tokens to fit a grid square. Which messes up tokens that are larger than a grid square (eg: a large table). Is there a way around this?

Tailz you probably work almost exclusively with your own tokens and so they are all scaled correctly to each other. In your case that would work fine. The way to scale a token independently of the autoscaling is to ctrl+scrollwheel over the token/portrait in the combat tracker or on the map.

Andraax
February 27th, 2017, 13:16
Or you can turn off auto-scaling in options, drop the tokens you don't want scaled, then turn it back on.

Tailz Silver Paws
March 1st, 2017, 00:00
Tailz you probably work almost exclusively with your own tokens and so they are all scaled correctly to each other. In your case that would work fine. The way to scale a token independently of the autoscaling is to ctrl+scrollwheel over the token/portrait in the combat tracker or on the map.
Not really what I mean. What happens is I build my module, place tokens on map, then set the map grid, then export the module. But when I then review the module (eg: load it as a module). Any maps that have the map grid turned on, the tokens on those maps get squished to fit a map grid square instead of retaining their scale.

eg: working on Grunk's Lair at the moment, and the Ogre's boat, which is well over 15ft long, ends up squished into a 5ft square.

The way around this at the moment seems to be, not to enable the grid, which I feel is letting down players/GM's are it should already be setup for them.


Or you can turn off auto-scaling in options, drop the tokens you don't want scaled, then turn it back on.
I don't think the settings are saved when exported.

damned
March 1st, 2017, 00:09
Not really what I mean. What happens is I build my module, place tokens on map, then set the map grid, then export the module. But when I then review the module (eg: load it as a module). Any maps that have the map grid turned on, the tokens on those maps get squished to fit a map grid square instead of retaining their scale.

eg: working on Grunk's Lair at the moment, and the Ogre's boat, which is well over 15ft long, ends up squished into a 5ft square.

The way around this at the moment seems to be, not to enable the grid, which I feel is letting down players/GM's are it should already be setup for them.


I don't think the settings are saved when exported.

This is because auto sclaing will assume all objects are M in size (1 grid square) unless you tell FG otherwise and the only ways to do this are to set the size in the NPC (eg Large, Huge or whetever the other sizes are) or by scrolling and setting the scale manually. That is what [B]auto scale/B] does :)

Tailz Silver Paws
March 1st, 2017, 00:17
This is because auto sclaing will assume all objects are M in size (1 grid square) unless you tell FG otherwise and the only ways to do this are to set the size in the NPC (eg Large, Huge or whetever the other sizes are) or by scrolling and setting the scale manually. That is what [B]auto scale/B] does :)
Yes, but it is pain in the behind. Plus not all placed tokens are creatures, eg: barrels, a boat, those are just placed tokens.

So far I'm exporting maps without the grid so the tokens don't re-scale. But the grid should be setup...

damned
March 1st, 2017, 00:26
The grid doesnt force scaling. The option Token: Auto-scale to grid is what scales. You can have a grid and turn off scaling.
But that is a setting in your campaign not in the module.
You could put a note in the module to this effect but its almost guaranteed that the players tokens will not have the same token scale as your stuff does.

I know the other objects arent NPCs. You could add a wishlist entry requesting that size data can be added to generic tokens. eg 3x1 or 2x2. But right now you can auto scale or not autoscale and autoscaling works for most people because their tokens are not all matching in resolution/size.

Trenloe
March 1st, 2017, 00:50
Just to be clear - the scaling option being talked about is set per campaign, not module or anything else. Unset it once (it's on by default) and that will be the setting whenever that campaign is loaded.

See "Token: Auto-scale to Grid" here: https://www.fantasygrounds.com/wiki/index.php/Options#Token

celestian
March 2nd, 2017, 20:51
Yes, PLEASE!

Sorry this took so long. I've been super busy. Here is the raw FCW files.

https://dl.dropboxusercontent.com/u/30284331/ToEE-FCW-Maps.zip

I might just put them in github (all of my map projects) at some point.

As I said, some of these will look odd when you load them up because of missing images (you can replace them with your own) because I use custom map placables.

Use need Campaign Cartographer to load these files. I use CC3+ tho I think it'll load fine in CC3.

seycyrus
March 3rd, 2017, 13:07
Sorry this took so long. I've been super busy. Here is the raw FCW files.
...


Thanks a bunch! I'm familiar with the process of dealing with red Xs. Thanks again!