Map scaling and other oddities.

[SirJoe]

Just when I thought I had it all nailed down...

I have been creating a set of room maps for use with FG with the following properties:

1. JPG file format
2. 96 dpi resolution with;
3. 62.5 pixels for every 10f of the map scale. (ie. a map that 160' foot wide would be rendered at 1000 pixles wide.)
3. various lengths and widths, depending upon room size

Most of the time, when these are loaded into FG2, they come in without zoom and at a pixel ratio of 1:1. That is, one pixle in the jpg file correspondes with 1 pixle on the screen, which is perfect for these maps.

*However* sometimes - and for the life of me I cant figure out why - the maps load up zoomed (by what appeara to be 1.5 to 2 times) and cannot be scaled back down to 1:1. At other times, maps come in at the correct scale (1:1 pixles) but with a small window view. When I enlarge the window, the map starts to scale up as well.

What I need to know is, how can I force a 1:1 pixle scale for images in FG2, and how can I adjust the window size of an image without affecting the scale of the image the window contains.

Any help would be muchly appreciated (and will probably end up in the tutorial I'm working on re mapping into FG.)

Cheers,
JS

[Dachannien]

Do these odd zooms occur when the map aspect ratio is particularly far away from 1?

[Casamordius]

I noticed something similar but I'm not sure when it happens. I think teh window size is somehow related to the last image you opened an not the size of the actual image... or at least not always ;-)

I'm sorry to say that I do not have a solution.

[SirJoe]

Here are the maps in question. The Evil Alter 2 file is the main one that goes wierd, but the cells files are also giving me grief. While the evil alter is way out of 1:1 aspect, the cells are not. Pls note that these maps are not all finished, but are a work in progress. Some have been made specifically to test FG2 and this sizing issue, etc.

Once I nail down a fix or work-around for this quirk, I'll finish up these maps - plus a few more - and post into the armory.

Best regards,
JS

[SirJoe]

I've been messing with the maps again and I think I've uncovered the cause of the problem.

Each 'slot' of the image list in FG2 has a memory of the window size. Images show up in the FG2 images list window in alphabetical order.

If you add an image to the images directly and it appears in the list in a slot previously taken by another picture, the ratios get screwed up.

Eg. If I had the following maps in my images directory:

A Map.jpg
C Map.jpg
D Map.jpg

and ran FG2 the first time, all maps would appear correct.

However, if I then added a map called

B Map.jpg

to the images directlory, then maps B and C would be scaled incorrectly, while D map would appear correct as it is filling in a 'new slot.'

Deleting the maps through the menu does not fix this, nor does deleting the images, restarting FG2, then replacing them back inthe images directory.

Somewhere FG2 is remembering image sizes...

Any ideas on how to overcome this quirk?

Best regards,
JS

[Dachannien]

The only ones that came up already zoomed for me were the hallway ones that were really narrow.

The ruleset determines the minimum and maximum sizes for image windows in the file adventure_images.xml. The minimum is 200 pixels in each direction, and the maximum is 700 pixels. If an image has a dimension less than 200 pixels, it will open up pre-zoomed so that that dimension fills the 200 pixel minimum. If an image has a dimension more than 700 pixels, the remainder of the image will extend off the edge of the image window and allow you to use the scroller widget to view the rest of it.

If you manually resize a window, the new window dimensions become both the minimum and maximum dimensions for the window. So, if you resize an image to 400x400, but the image's actual size is 200x800, it will automatically zoom in at twice magnification so that the 200 side is expanded to 400, while the 800 side will be mostly outside the window (since it's expanded to 1600, but only 400 is shown).

If zooming out would cause the image's window size to change (i.e., one of the scaled dimensions becomes less than the current dimension of the window), zooming is not allowed.

Finally, FG remembers the window size and position for every image window you open (and, generally speaking, other windows as well). These are stored in campaignregistry.lua, but unfortunately, they use ID numbers rather than filenames for the images. The cross-reference between image ID and filename/image list name is in db.xml.

Anyway, put all this together, and you arrive at the conclusion that resizing an image window is a Bad Thing. What you are seeing is the result of manually resizing the Evil Altar 2 and Cells image windows. Every time you open that window from now on, the window will be whatever size you last set it at, and since there's no window measurement display, you have no way to restore it to 1:1 with the associated image. In the case of the hallways, they are already narrower than 200 pixels, so they will always be zoomed in.

[Hamish]

Have you checked CampaignRegistry.lua?


Ah, makes me feel kinda foolish for posting such a short reply, but I was on the right track anyway.

[SirJoe]

Dachannien... thank you so much for your detailed response. It's perfect!!! If its ok by you, I will include this info directly in a tutorial on preparing maps for FG2.

Best regards,
JS

[Dachannien]

Sure thing :) Glad I could help.

[darthfrodo]

Hey Guys,
I'm having the same problem, and Dachannien's reply seems detailed, but it doesn't seem to say how to get the image to return to normal/original scale. I'm having to manually put the original .jpg file into the apdata images folder to get it back to the correct size, which of course means I lose any setup I've done, such as token placement and mask.
peace,
Darth Frodo

[Dachannien]

You can edit the campaignregistry.lua file, find the appropriate entry that corresponds to the image that has a problem (you can find the cross-reference between the id-00000 numbers and the filenames in db.xml), and delete that entry.

You can probably instead edit the ruleset to create a way to restore the zoom for a window to 1x, but this is less convenient if you're using the default ruleset.

[[email protected]]

You can edit the campaignregistry.lua file, find the appropriate entry that corresponds to the image that has a problem (you can find the cross-reference between the id-00000 numbers and the filenames in db.xml), and delete that entry.

What I did was to delete all of the entries under the image window entry (starts with ["imagewindow"] ={ and ends just before the ["lightingselection"] = { line), then re-started FG and it re-sized all the image windows correctly and re-built the entries in the campaignregistry.lua file.

Strongly recommend you make a backup first, in case you screw it up.

[JMOxx75]

I can't believe this is still relevant! Glad I found it, I was going nuts.