FGU ref-manual, inline images, "invisible".

[celestian]

Is there any reason this image block would appear "invisible" (taking up space/etc) and when you click the space it should be, it pops up as a image window as you'd expect.

Did the blocktype change for inline images in FGU?



<id-00007>
<align type="string">center</align>
<blocktype type="string">image</blocktype>
<caption type="string">Image: Horse at the Gate</caption>
<image type="image">
<gridsnap>on</gridsnap>
<layers />
</image>
<imagelink type="windowreference">
<class>imagewindow</class>
<recordname>image.id-00005@B2: The Keep on the Borderlands (L1-3)</recordname>
</imagelink>
<size type="string">350,500</size>
</id-00007>


This is what it looks like. When the cover pops I clicked on the blank space where it should appear in the ref-manual.

https://i.imgur.com/9GPQwAo.gif

I've attached the full module to the post if that's necessary for review.

[damned]

If you make the refman window wider does this happen?
I seem to recall this happening in early versions of refman.

[Sulimo]

I'm not seeing the same in the reference manual for RMC Character Law, created a new campaign to test it out, I did not need to resize the window.

https://i.imgur.com/IJRxL31.png

[Talyn]

Easy:


<image type="image">
<gridsnap>on</gridsnap>
<layers />
</image>


Drop the gridsnap and layers, that's not part of the refblock markup. You're missing the recordname to the actual image, therefore nothing is rendered.

[celestian]

Easy:


<image type="image">
<gridsnap>on</gridsnap>
<layers />
</image>


Drop the gridsnap and layers, that's not part of the refblock markup. You're missing the recordname to the actual image, therefore nothing is rendered.

This helped me narrow down the issue. It looks like:

DB.setValue(nodeBlock,"image","image",DB.getValue(nodeImage,"image",""));

i.e. DB.getValue(nodeImage,"image","") doesn't return the same values in FGU ... which is where I get the value for the block.

[Bale Nomad]

I'm having a similar issue. The imagelink works, but nothing in the reference manual page. Here's the relevant block of XML:
<id-00001>
<blocktype type="string">image</blocktype>
<align type="string">center</align>
<size type="string">657,224</size>
<image type="image">
<bitmap type="string">hidden_images\tied_scroll.jpg</bitmap>
</image>
<caption type="string" />
<imagelink type="windowreference">
<class>imagewindow</class>
<recordname>hiddenimage.id-00001</recordname>
</imagelink>
</id-00001>

[Talyn]

I'm having a similar issue. The imagelink works, but nothing in the reference manual page. Here's the relevant block of XML:


<id-00001>
<blocktype type="string">image</blocktype>
<align type="string">center</align>
<size type="string">657,224</size>
<image type="image">
<bitmap type="string">hidden_images\tied_scroll.jpg</bitmap>
</image>
<caption type="string" />
<imagelink type="windowreference">
<class>imagewindow</class>
<recordname>hiddenimage.id-00001</recordname>
</imagelink>
</id-00001>

Try this instead:



<id-00001>
<blocktype type="string">image</blocktype>
<align type="string">center</align>
<size type="string">535,182</size>
<image type="image">
<bitmap>hidden_images/tied_scroll.jpg</bitmap>
</image>
<caption type="string" />
<imagelink type="windowreference">
<class>imagewindow</class>
<recordname>hiddenimage.id-00001</recordname>
</imagelink>
</id-00001>


I changed the size because the 'usable' width of a default refblock is ~535px. We shouldn't be designing refpages that require the user to resize them.
The second change was eliminating the type="string" which is why your image is not displaying. I also switched the backslash to a slash in the path, as that is how the Wiki reads and that's how FG builds its markup.

[Bale Nomad]

Thanks for the advice, but it didn't work. I tried both suggestions independently and together, and I scaled down the image itself in case scaling from the original size to the specified size was a contributing factor. The image is a simple grey scale image of a scroll tied with a ribbon from page 24 of Rolemaster Companion III. It's not super high resolution or 32-bit color or anything.

[Talyn]

The markup I gave is correct so that leaves me thinking your path is incorrect. I see you keep using hidden_images is that in fact the folder name? The imagelink below uses a recordname of hiddenimage so you've got two things going on: there needs to be a \hidden_images\ folder and all the images you're wanting to be hidden from the Images window on the sidebar should be stored there, and the image data for them needs to be in <hiddenimage> in your XML.

If the image is not displaying on your refpage, it should still be drawing the box where the image should be and your imagelink is clickable. If that doesn't bring up the full-size image then both of those recordnames are incorrect.

[Bale Nomad]

The "hidden_images" does exist and it does contain the image file. Is the text in the <bitmap> tag the path and file name, or is it supposed to be a reference to the "recordname"? I thought it was the path and file name.

The <hiddenimage> tag also exists, and the use of the "recordname" in the link to that resource does work.

[Moon Wizard]

You'd have to provide an example where it's not working. Maybe a one page manual with just that inline image?

Then, we would be able to figure out what is not working for you.

Regards,
JPG

[Bale Nomad]

Here is a sample module that exhibits the behavior I first described. The image is not displayed embedded in the reference page while clicking the underlying link opens a separate image window that does show the image.

Bale Nomad

[Talyn]

Oooookay ... so you're building this in FGU, that's the main problem. This .mod works perfectly fine in Classic except the imagelink brings up a blank window because it doesn't know how to deal with FGU's new image markup. If I had to purely take a guess, I'm thinking perhaps the image control called by the refpage also doesn't know how to deal with FGU's new image markup when it's used in a refpage versus a standard image window? @Moon Wizard can give a more technical answer, however. On the "official DLC Developer" side of the fence, we're pretty much under orders to not develop in FGU (other than extracting LoS occluders where applicable) because anything made there is not compatible with Classic and everything in the Store has to be compatible with both. If you're building this for personal use, you're all fine and good once this technical issue gets resolved.

[Bale Nomad]

I removed the FGU-specific markup from the <hiddenimage> tag, but there was never any FGU-specific markup for the image embedded in the refpage. Now the module works as expected in FGC, but not in FGU (neither the embedded nor the linked image actually display). Is there some "secret sauce" for this to work in FGU? I have purchased modules that work perfectly in both environments. Or are they actually different when they come through the updater for each environment?

[Bale Nomad]

I was thinking the control for displaying the embedded image didn't need the extra FGU-specific markup to display the image in FGU, because it wasn't being edited. Apparently that is not the case. When I include the FGU-specific markup in both the embedded image tag and the <hiddenimage> tag, then it works in FGU.

So the "secret sauce" is to include the FGU-specific markup wherever an image is to be displayed.

[Moon Wizard]

If you use the FGC specific markup, it should work in both FGC and FGU. Do you have a FGC version that is not working?

Also, any modules that can be used in both FGC and FGU must be created in FGC.

Regards,
JPG

[Bale Nomad]

Here is one that works in FGC, but not FGU.

[Sulimo]

I cannot answer the why, but at the top of your files you have this:



<root version="4" dataversion="20201016" release="2.1|CoreRPG:4">


When I changed that to the following it worked.



<root version="3.0" RMCVersion="2.0">


I think your root version='"4" is hanging you up, when I changed the line I had from 3.0 to 4.0 it stopped working. It could be another part of the line as well, I'm not really sure. What I have does work though.

I had a problem a while back with a reference manual I was building as well. Interestingly enough I am building it in RMC as well.

[Moon Wizard]

Yes, the data version of the file must be the correct version for FGC; or the data will not be read correctly by FGU. If the version is set to 4, it will assume it is in FGU format.

Regards,
JPG

[Bale Nomad]

Thanks - it works. I really appreciate the help!