[4.5.0 L] Relative positioning of files and folders is MAD!

[LondonLight.org]

Resulting folder structure:


HTML5 Output parameters:
Settings > Tile Settings > Image Names set to tour/images2/$ut_o.jpg
There's no images2 in the output so I don't know if it's relative positioning is sane. I guess this is because Multiresolution is enabled, but then the whole Tile Settings frame should get disabled as soon as I enabled Multiresolution.

Settings > Skin/Controller set to images1
It gets put into /Kitchen/, so its relative to... what exactly? To the completely different HTML tab?

Settings > Output > Output File set to tour/$ut.xml
Put into the right place, /tour/Kitchen.xml, as expected.

Multiresolution > Filename set to tiles/$ut/c%c_l%r_%y_%x.jpg
"tiles" saved to /tour/, relative to a setting again in a completely different tab, Settings!

HTML > Flash fallback file set to $ut.swf
Looking inside the HTML file I see "../Kitchen.swf" ARGH! So this one is relative to the .p2vr?

This is insane, please normalize this, either make them all relative to the root and let the user clearly set the root, or make it clear what each one is relative to and keep them in a sane tab/frame structure.

[JimWatters]

HTML5 Output parameters:
Settings > Tile Settings > Image Names set to tour/images2/$ut_o.jpg
There's no images2 in the output so I don't know if it's relative positioning is sane. I guess this is because Multiresolution is enabled, but then the whole Tile Settings frame should get disabled as soon as I enabled Multiresolution.

Yes when multiresolution is enabled some of the main Settings tab items are ignored. Except Image Quality is used to define the quality of the image tiles, Window Size is used to determine the preview image if ggpkg.ggt is created as HTML output.

Settings > Skin/Controller set to images1
It gets put into /Kitchen/, so its relative to... what exactly? To the completely different HTML tab?

Should be The XML file. Creating HTML is optional.

There does seam to be a bit of a bug here. Normally the XML and HTML file would be saved to the same folder and this would not be noticed. Bug if HTML output is enabled then Images and the skin files are relative to that folder. Otherwise to the XML folder. see Issue #1123

I have used ../images_simplex, so the files are stored in a sibling folder and can be reused and don't have to upload multiple copies. Using a unique name to reflect the skin being used. You do need to remember to upload the first time.

Settings > Output > Output File set to tour/$ut.xml
Put into the right place, /tour/Kitchen.xml, as expected.

If you are using the Pro version and creating a tour with multiple panorama then you will want to make sure you use Tour|Edit Master Node,| to set and modify Userdata.
You may want to use the project name in this case $p.xml

Multiresolution > Filename set to tiles/$ut/c%c_l%r_%y_%x.jpg
"tiles" saved to /tour/, relative to a setting again in a completely different tab, Settings!

It is better to use $n instead of $ut in case you give multiple pano the same title.

HTML > Flash fallback file set to $ut.swf
Looking inside the HTML file I see "../Kitchen.swf" ARGH! So this one is relative to the .p2vr?

Unless you want a very different skins for Flash and HTML5 using Flash Fallback player instead of Flash Fallback file.

This is insane, please normalize this, either make them all relative to the root and let the user clearly set the root, or make it clear what each one is relative to and keep them in a sane tab/frame structure.

Many of the paths are the way they are because of legacy reasons. Big changes coming to the layout in the next version that make it easier for new users.

[LondonLight.org]

When providing users with the power of customization (always a good thing) it is important that this power is not confined to a little box. As you pointed out, it is possible to re-use images, and that is how I'm coding my website - everything is reused, including JS files, so no bandwidth wasted and no waiting for server responses, just re-use from cache, and the only new things needed are the actual tiles. However the mess with relative paths now makes it a trial-and-error task getting things right, and it really does not have to be so.

I think we agree that most users do not even touch the placeholder settings (or else I'm sure there would be a lot more complaining here!), so the default values shipped with Pano2VR should be sane (and they are), but what is not sane is their relativity. I think all entries, all of them, should be relative to the .pano2vr file, and then the sane defaults shipped with Pano2VR should build up from there using placeholders. So the end result would still be the same structure as is now, but at least if someone wants to customize the paths because they understand what they're doing and have a different vision of things, they should be able to change the placeholders and get a result that is consistent with expectations, and not this complete messy surprise as it is now.