Please, we need more addressable hotspot fields

[soulbrother]

Dear ggnome team,

the qty of existing and addressable fields in the hs editor are only 4:
title: $(hs)
description: $(hd)
url: $(hu)
target: $(ht)

PLEASE, PLEASE try to integrate a few more addressable fields, because the varialbes and filters allow so much creative design and functions, but the limitation of only 4 data-providing fields does not suit to some needs.

[Hopki]

Hi,
You can use all of the user data text fields but 5 of them will allow for lots of text as you can pop out a larger text entry field.
But it does depend on what data you want to store, you can use for example a text variable.
Then use a placeholder to read it.
Example, a text variable called: pano, the text in the variable would be: {node2}

You can then have a button to open this node using the action:
mouse click, open next panorama, url: $(*pano), target: xxxxx

When clicked this would open node two.

But as its a variable you can then have a button that could set the variable value, pano to say: {node3}.
So the next time the open next pano button is clicked it will now open node three.

So not only can you store a value you can also change it if you need.
Regards,
Hopki

[soulbrother]

Hi Hopki and thanks for your reply.

I know the power of user data text fields and I can operate and realize many ideas..

But I was talking about "info" point-hotspots (not node-hotspots) and "data or media" that needs to be set, displayed or changed, when clicking on a hotspot.

For all of my needs I have found solutions and workarounds, but it seems not as easy to manage, when the different "data" needs to be handled in the skin and choosen with the help of variables, instead of beeing able to use an own field in the hs-editor.

Because for me "hs-editor" means: to be able to edit the hs relating data and having a good overview - with the chance to use one "universal" skin for many projects.

[Hopki]

Hi,
May be me but I am struggling to see this.
We have different hotspot types which means the hotspot templates just use place holders to access the data in the hotspot.
Example, each point hotspot has a description text field for information text, so a text box with a set text action using $(hd) will display this.
The same for media and image popups.
Can you give me a use case to how having more user data text boxes will help.
If there is not a solution then I have something to add to feature request.
Regards,
Hopki

[soulbrother]

I try to explain my actual project:
I have a tour with xx panos.
In each pano there area few point-hotspots.
Those p-hs are using the same skin-hs-template.
This template contains:
- image popup
- text popup
- 2 buttons to open different url´s.

So I have used a unique hs-number: hs-01, hs-02 and so on (I need more than 30).
As the hs needs to set the 2 url´s, plus the title, plus a text, plus an image, the 4 fields does not fit and it is not even multilanguage!

A solution is of course doable, due to the new possibilitys with filters:
In the skin I have setup a variable, I named it: var_link_hs_id
this variable is set by a click on the hotspot and the text in the hs-title is used for setting this text-variable.

By doing so, I can setup the popup-text and write a text with a logic-block: "if var_link_hs_id is hs-01, show text: "blablabla"
I use the same variable for setting the link-url´s with the new filer in "actions", as Hopki showed in the new video-tutorial.

Try to imagine: A tour inside a trade-fair and in each panorama there are 3 or more different companies visible. I use this p-hotspot on each booth and with that p.-hs, the popup-image, the popup text and 2 (popup)buttons are shown.
BUT:
I need an extra list, to not loose the overview, because handling all urls and text infos within the skin only, is not as clear, as I would have a few more usable fields in the hs-editor, because in the skin, I don´t SEE the position of the hs in the panorama and therefore I don´t know the "company" (in that example).

in the hs-editor I can see the position in the panorama, so I know the company and could easily write the url´s, and the specific text and other specific infos, if needed.

This is the reason why I wrote: The hs-EDITOR shoud be used as editor, with out the need of writing all specific informations in the skin.

Understand right: I love the possiblities of V6 and use them, but for my actual project, I wished to have some more "direct" addressable hs-fields.

Thanks again!
Best regards!

[Hopki]

Hi,
I'll follow this up as there is feature request for this but know the devs are not keen on loads of text entry fields cluttering up the interface.
I think there are plans for another solution.

For now the two buttons that open up URLs.
Do that have to be buttons in the skin or can they be code added to the text?

As an example this is in the description text field of a point hotspot:

Code: Select all

This is information text that uses some HTML formatting.<br>

<a href="https://ggnome.com" target="blank"><b>Garden Gnome Software Website</b></a><br>

<a href="http://hopkimedia.co.uk/wp/ " target="blank" style="color:white; background-color:DodgerBlue;" ><b>Hopki Media Wordpress Website</b></a><br>

If you selected an image hotspot you can then have a popup that has your image, information text and text links to open your websites.
Just a thought.
Regards,
Hopki

[soulbrother]

Thanks for the hint, to setup links in the textfields, as this is of course a simple solution for some cases and some needs, but not for all

In this thread:
viewtopic.php?p=63600#p63600
has been shown a good example, of using the text-fields in the hs-editor with "another" function, so that is would make sense, to have some more of those "entering-fields", to be able to use the hs-editor as main editor for several needs...

[deedee123]

hi,

i also would not mind to have a few more entries there, especially to make multi-language tours a bit more straightforward. i know some language solutions from the forum and how to call text files with variable, but they feel like a workaround. so now i often end up using the fields to enter the second language. but for a third it's not possible as there are not enough fields.
as for the interface, there are ways to keep it clean.. should not be the reason to not add this functionality.
david

[Hopki]

Hi all,
All this will be in the next major update.
I have no idea when it will be released as work is ongoing with V6.
Regards,