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:


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.