FG Image size/zoom issues

[Nickademus]

No clue how relevant this is, but some behavior I'm seeing in FG already that might be a problem for token scaling is the effect on images (maps) when I first pull them up. I'm not entirely sure the problem, or if it is intended behavior with a bug in it, so I'll just give an example of what happens to me.

I have five images, each created new with a 50-pixel grid draw on it and sized to the exact dimensions for their size (i.e. a 6x5 map is 300x250 pixels), and five 50-pixel tokens. The tokens are put in the token shared folder and appear in FG perfectly sized. The images are put in the campaign images folder. When the images are opened in FG they are always resized to twice the size and thus blur from the scaling. About 3 out of 5 times I can use the mouse wheel to zoom out and it returns to the proper size (this is necessary on the host and all clients it is shared with). About 2 out of 5 times the image won't zoom out, it will only zoom in, as if FG thinks the blown up image is already fully zoomed out and at the proper size.

By deleting and remaking the image as different files, I can sometimes get FG to accept one that can zoom out and be used normally. Other times, though, FG simply won't cooperate and any image (new or a re-save) that uses the visual of the bugged image will not return to the dimensions of the source image file.

Not sure why this is, and from reading here I'm suspicious of if it has something to do with the images being broken up into 512x512 chucks for processing (as if the dimensions of the source are the problem). I tried swapping height and width on a problem image, changing it from portrait to landscape, but I didn't try actually changing to two values to something else.

If it isn't an issue of image size, then whatever this problem is with the auto scaling of images may affect tokens as well when you attempt to auto scale them.

[Trenloe]

MODERATOR: Moved this to a new thread because I don't think it is related to the token sizing thread it was posted in. Also, this is relevant to all FG rulesets and FG in general, so it is good to have this information available in the Tavern.

I don't think this issue is related to token sizes, 512x512 chunks or anything similar. I think it is related to how FG stores image information in it's internal database and the campaign registry (window size and zoom level).

Let me explain the process... (Note, I include a lot of campaign file information below - these files are only updated when FG exits, it auto saves or when the GM issues a /save command in the chat window).

When a new Fantasy Grounds campaign is created it makes a new folder in the <FG App Data Folder>\campaigns directory with the same name as the FG campaign. Within this new campaign directory will be a number of files, 2 of which are db.xml and CampaignRegistry.lua. For a new campaign these are essentially empty:
DB.XML:

<root version="2.9" release="10">
<image>
</image>
<options>
<SYSTEM type="string">pf</SYSTEM>
</options>
</root>
CampaignRegistry.lua (this only has the window size for the initial 3.5e/PF selection window:

{
["windowpositions"] = {
["systemselection"] = {
[""] = {
["y"] = 304,
["x"] = 312,
["w"] = 400,
["h"] = 160,
},
},
},
["systemselection"] = "true",
}

When I add a new file to the campaign \images directory FG recognises this and adds the image reference to the DB.XML file:

<root version="2.9" release="10">
<image idcounter="2">
<id-00001>
<image type="image">
<bitmap>images/Black Echelon Operative.jpg</bitmap>
</image>
<name type="string">Black Echelon Operative</name>
</id-00001>
</image>
<options>
<SYSTEM type="string">pf</SYSTEM>
</options>
</root>
Note the DB reference ID that is automatically applied to this DB entry: id-00001 This is the unique image reference that FG will use.

If this image is then opened within Fantasy Grounds and then closed, FG will record the image size and zoom details in the CampaignRegistry.lua file:

["imagewindow"] = {
["image.id-00001"] = {
["y"] = -248,
["h"] = 1263,
["imagex"] = 0,
["imagezoom"] = 1,
["imagey"] = 0,
["w"] = 692,
["x"] = 166,
},
},

Note how FG references the image id: id-00001 in this file and how the image size and position within the FG window is stored - plus the zoom level.

If I then exit Fantasy Grounds and delete the image file from the \images directory and then load Fantasy Grounds again, FG recognises that the image is no longer there and removes it from the DB.XML file:

<root version="2.9" release="10">
<encounter>
</encounter>
<image>
<category name="" mergeid="" baseicon="0" decalicon="0">
</category>
</image>
<options>
<SYSTEM type="string">pf</SYSTEM>
</options>
</root>
But it does not remove the image position/size/zoom reference from CampaignRegistry.lua.

Then, if I add a new image file to the campaign, FG uses the next available id-xxxxx number, which will be id-00001 in this example:

<root version="2.9" release="10">
<encounter>
</encounter>
<image idcounter="2">
<category name="" mergeid="" baseicon="0" decalicon="0">
<id-00001>
<image type="image">
<bitmap>images/Shop.jpg</bitmap>
</image>
<name type="string">Shop</name>
</id-00001>
</category>
</image>
<options>
<SYSTEM type="string">pf</SYSTEM>
</options>
</root>

So, when this image is opened in FG the CampaignRegistry.lua file is checked for a previous entry for id-00001 and the entry from the original image is found and this is used to display the new id-00001 image, which usually results in the image not fitting the window, for example:
https://dl.dropboxusercontent.com/u/39085830/Screenshots/CampaignRegistryExample.JPG

The position/size/zoom of all windows can be reset by deleting the CampaignRegistry.lua file from the campaign directory (do not do this while FG is running otherwise it won't clear out properly).

[Trenloe]

So, the upshot of the above post (#2) is that if you delete images and then add new ones, the chances are the first time you open them they are going to have the old image positions, size and zoom level. You *should* usually be able to resize/rezoom the image. Perhaps the subsequent issues Nickademus encounters with not being able to zoom out the new images is related to the original image having a zoom scale of 1 and so FG thinks that it doesn't need zooming. I must admit, I have never encountered a resized image I can't manually resize and rezoom to an acceptable level - perhaps try holding CTRL down, left-click within the window and drag the cursor to resize the window and then try zooming with the mouse scroll wheel.

Or, if this still doesn't work - exit FG, delete the CampaignRegistry.lua file and reload FG.

An additional note: each ruleset has a minimum image window size. Usually 200x200 but it can differ from ruleset to ruleset. If an image with dimensions less than the minimum (on one or both axes) is opened the window size will be that of the ruleset minimum and the image will be zoomed on the relevant dimension to fit within the window and you won't be able to resize smaller or zoom out further on the minimum dimension.

[Nickademus]

Aw, I totally wanted to hijack Blacky's thread. Boo.

Just kidding. I thought it might be an error in scaling issue, but I understand what the issue is now. I remember you replying to a post of mine a while back about this and talking about deleting a file and re-adding it to FG. I misunderstood and thought you were talking about the same file being added back to FG without being properly deleted.

Now I see the issue is when a file is deleted from FG some of its metadata remains behind and is applied to a new, unrelated, file that is added in the same spot in the image list. That's a problem, but now that I know about it I can easily compensate. I probably run into this problem more than most people because I'm doing a lot of experimenting and testing in FG to get a good grasp of the program. This means a lot of Test Images, Test Encounters, Test NPCs, etc. I probably created and deleted a handful of images before loading in the actual ones I wanted to use.

My only question now, is (assuming FG is closed) will anything bad happen by deleting the CampaignRegistry.lua file? Will FG recreate it upon loading the campaign back up? And if all else fails can I close FG, open the lua script and manually set the scale and zoom for the images?

Okay, that was more than one question. But thanks for taking the time to explain this. It was the last major issue I was having with FG. Fixing this should be smooth sailing for Chronic games.

[Trenloe]

My only question now, is (assuming FG is closed) will anything bad happen by deleting the CampaignRegistry.lua file?
The only "bad" thing that will happen is that it resets all of the position, sizes and zoom levels of *all* windows in FG for the GM (story, NPC, encounter item, etc., etc..).


Will FG recreate it upon loading the campaign back up?
Yes it will - but it will be blank so all window positions for every window within FG are reset.


And if all else fails can I close FG, open the lua script and manually set the scale and zoom for the images?
Yep, absolutely. You'll need to work out which id-XXXXX entry ties in to which image by opening the campaign db.xml file as shown in post #2.


Okay, that was more than one question. But thanks for taking the time to explain this. It was the last major issue I was having with FG. Fixing this should be smooth sailing for Chronic games.
No problem at all. Hopefully it will help others as well, as this question has come up a few times before...

[Nickademus]

The only "bad" thing that will happen is that it resets all of the position, sizes and zoom levels of *all* windows in FG for the GM (story, NPC, encounter item, etc., etc..).

Hmm, that second etc. looks suspicious.... is that by chance the hotbar entries? Or are they saved in the db.xml?

[Trenloe]

Hmm, that second etc. looks suspicious.... is that by chance the hotbar entries? Or are they saved in the db.xml?
What I meant was all dynamic windows - windows that you open, move around and resize yourself. It does not delete any data - purely the size, position and zoom level of these dynamic windows. This does not touch the hotkey bar - this information is stored in the campaign usersettings\hotkeys_host.xml file.

[Nickademus]

Good to know. Thanks again.

[Dakadin]

I think your options are saved in that file also so if you delete it you will have to reset the options back to what they were.

If you aren't intimidated by removing the image entries, you could always try manually removing them from the file. Just remove the full section for the image entry. This would be one entry from Trenloe's example above:

["image.id-00001"] = {
["y"] = -248,
["h"] = 1263,
["imagex"] = 0,
["imagezoom"] = 1,
["imagey"] = 0,
["w"] = 692,
["x"] = 166,
},

I would recommend making a copy before trying it so you can always go back to the original.

[Trenloe]

I think your options are saved in that file also so if you delete it you will have to reset the options back to what they were.
In 3.5e and 4e options are stored in the db.xml file. Having a quick look at RMC, the campaign (GM) preferences are stored in DB.XML but it looks like individual player preferences are stored in CampaignRegistry.lua.

[Dakadin]

I checked an old 4E campaign but it might have changed since I last played 4E. Thanks Trenloe!

[Trenloe]

I think your options are saved in that file also so if you delete it you will have to reset the options back to what they were.
Having a quick look at a few different rulesets:

RMC: the campaign (GM) preferences are stored in DB.XML but it looks like individual player preferences are stored in CampaignRegistry.lua.

Savage Worlds stores options in db.xml but it looks like it stores card info in CampaignRegistry.lua.

Castles and Crusades stores options in db.xml.

Call of Cthulhu stores combat tracker data in the CampaignRegistry.lua file.

[Nickademus]

but it looks like individual player preferences are stored in CampaignRegistry.lua.

This shouldn't be a problem. In theory, I'd be deleting the lua script after getting the campaign all set up but before players ever joined a session.

[Trenloe]

This shouldn't be a problem. In theory, I'd be deleting the lua script after getting the campaign all set up but before players ever joined a session.
And this is only for the RMC (Rolemaster Classic) ruleset.

[Dakadin]

And this is only for the RMC (Rolemaster Classic) ruleset.

I hope to clear up these types of discrepancies as I rebuild the RMC ruleset to fully use FG v3.0. I am working on getting the current version compatible with v2.9.4 and v3.0. Then I will continue with the rebuild.

[Moon Wizard]

Actually, the "player" changeable options are saved in the CampaignRegistry. (wheel modification of number fields, double-click action, etc.)

In v3.0, the FG client will automatically save the window position and zoom state, regardless of ruleset. In addition, if a database node is deleted, the state information will be cleared on the next database save.

Regards,
JPG

[Bidmaron]

JPG said:

Actually, the "player" changeable options are saved in the CampaignRegistry. (wheel modification of number fields, double-click action, etc.)

JPG, I don't think that is always totally accurate:
This is the routine form CoreRPG in the Manager_Options.lua file:

function setOption(sKey, sValue)
if aOptions[sKey] then
if aOptions[sKey].bLocal then
CampaignRegistry["Opt" .. sKey] = sValue;
makeCallback(sKey);
else
if User.isHost() or User.isLocal() then
DB.setValue("options." .. sKey, "string", sValue);
end
end
end
end


It looks to me like if you don't set the bLocal flag when creating the setting, then the data is saved in the database (unless you are in client mode, in which case it simply vanishes into the ether). Not sure why that provison is there, but it is.

[Moon Wizard]

Yes, only the local options are saved in registry, the campaign options are saved in the campaign.

JPG

[Bidmaron]

Great, wanted to make sure I wasn't missing something.

[noelyuk]

Hey all.

Was this issue ever resolved in a way that is understandable to your average Joe? e.g. me. I'm having the same issue. I add a new image and only part of it is visible. When I drag the window to reveal the entire image, the image increases in size, and will never zoom back to it's original size. Can anyone explain to me as simply as possible how I can resolve this? I'm using the WFRPv3 ruleset by the way.

Thanks

Noely

[damned]

What is teh size of your image files?
Additionally have you ever replaced an image file with another that has the same name but different dimensions?

[noelyuk]

The image sizes are all fairly small. I thought it was a size problem so I reduced it to just 16kb but the problem remains. As for the image file it has a different name. However if you mean have I EVER replaced one image file with another similarly named item but with different dimensions. I suppose that's highly possible although they're all different names now. Do you mean that is the cause of the problem? And if so how can I remedy?

[damned]

16kb is never going to cause an issue - I was particularly looking for the dimensions of the graphic - all rulesets have a limit on the length/width of images.
Also it can definitely cause issues if you swap an image called image1 with another image called image1 that has different dimensions - but it should only affect image1 and not image 2 etc.

if you are online PM me and I will connect to your session and you can show me what happens.

[Nickademus]

Hey all.

Was this issue ever resolved in a way that is understandable to your average Joe? e.g. me. I'm having the same issue. I add a new image and only part of it is visible. When I drag the window to reveal the entire image, the image increases in size, and will never zoom back to it's original size. Can anyone explain to me as simply as possible how I can resolve this? I'm using the WFRPv3 ruleset by the way.

Thanks

Noely

If this happens, open the Image folder by clicking on the Folder link in the top right of the Image window. Then hold Ctrl and drag and drop the image a little bit to create a Copy of it in the folder. Delete the original and rename the "* - Copy" to the original image's name.

[Trenloe]

Hey all.

Was this issue ever resolved in a way that is understandable to your average Joe? e.g. me. I'm having the same issue. I add a new image and only part of it is visible. When I drag the window to reveal the entire image, the image increases in size, and will never zoom back to it's original size. Can anyone explain to me as simply as possible how I can resolve this? I'm using the WFRPv3 ruleset by the way.

Thanks

Noely
FG doesn't add any filler around the image in an image window. If you resize a window, you can zoom in ok but can only zoom out as far as the smallest dimension. If you have a narrow image, for example, don't resize it to be too wide on the screen as you won't be able to zoom out further than the bounds of the width.