zorder used with addhotspot()

  • Is there any way to get zorder to behave properly with addplugin() and addhotspot()? The only behavior I got was that the thing that was created last, is on top, no matter the zorder...

    As my plugins remain in memory, and the hotspots are created dynamically for each pano, the hotspots move on top of the plugins (floorplan, house map). It doesn't look very convincing that way. *unsure*

    Here is a copy of my project as it is presently. The magnifying glass hotspots move in front of the floorplan, even though plugin[floorplan] has zorder 10 and hotspot[hotspot_pano007] and his buddy have zorder 1...

    According to an explanation by Protected, things like addplugin() and addhotspot() should work properly with zorder, but I can only conclude that they don't... Or am I doing something wrong?

  • Jarredja, unfortunately it doesn't help. Zoom is true now for the hotspots only, but they still move over the floorplan.

    About the error when doing "load this xml", it is the same error I described here, it happens when krpano wants to cleanup the hotspots. It is outside my control.

  • Hi,

    is that 'penthouse' image a normal <plugin> image?
    or was it added directly from flash or manually moved to a other displayobject?

    normally it's impossible that an <plugin> image can be over an <hotspot> image,
    there are two global layers - the plugin and the hotspots layer, and the plugin layer is the higher one,
    so it would be never possible that an element from the hotspot layer can overlap an element from the plugin layer...

    best regards,
    Klaus

  • Klaus,

    The following plugins are defined in the original xml: plugin[housemap] (the white surface in the bottom left), plugin[floorplan] (the floorplan on top left), and plugin[map_handle] (the handle on the right side of the floorplan).

    All the icons on top of plugin[floorplan] and plugin[floorplan] have been created with addplugin(), and have one of these as their parent. So plugin[plugin_floor_0], which is the "penthouse" image, is part of those dynamically created plugins.

    The magnifying glass hotspots have been created with addhotspot().

    I'm starting to wonder if the hotspots that are created with addhotspot() actually end up in the hotspot layer you mention. Also my presentation in post19061 about hotspot.visible not working with dynamically added hotspots, seems to point in the same direction.

    Zitat

    normally it's impossible that an <plugin> image can be over an <hotspot> image,
    there are two global layers - the plugin and the hotspots layer, and the plugin layer is the higher one,
    so it would be never possible that an element from the hotspot layer can overlap an element from the plugin layer...

    I guess you meant that it's impossible that a <plugin> image can be underneath a <hotspot> image. That would indeed be the expected behavior. Therefore, I can only conclude that either addplugin() or addhotspot() put them in the wrong layer. And since I get the strange error when removing these hotspots, as described in post 19012, I suspect addhotspot() to be the culprit.

    Does that make sense?

  • I do not know AS3, nor do I know where to find it or how to use it, so if I do modify the krpano Flash DisplayObjects somehow or other, then I'm certainly not aware of it... I only use the scripting facilities made available through the XML krpano object.

  • Klaus: Is there a hotspots Sprite containing all the hotspots and a plugins Sprite containing all the plugins or are all the hotspots and plugins inside the same Sprite but in different layers?

  • Hi,

    Klaus: Is there a hotspots Sprite containing all the hotspots and a plugins Sprite containing all the plugins or are all the hotspots and plugins inside the same Sprite but in different layers?

    there is one layer (a AS3 Sprite Object) that contains all <plugin> elements, it can be accessed from AS3 via the "plugin.layer" variable,
    and there another layer that contains all <hotspot> elements (hotspot.layer),
    and there is an additional but internal layer, the STAGE layer (for using - parent="STAGE"),

    this the order of these layers:
    1 - the pano layer (image.layer)
    2 - the hotspot layer (hotspot.layer)
    3 - the plugin layer (plugin.layer)
    4 - the internal stage layer (no direct access),

    regarding to the problem - I think the 'penthouse' image must have set - parent="STAGE",
    this is the only thing which could explain that behavior...
    ... but I can't find that in the xml

    best regards,
    Klaus

  • Thanks very much to Klaus and Protected for trying to help me here.

    okay, but your xml is not easy to understand...
    to what have you set the "parent" attribute for the image and to what for the hotspots?

    I know it's hard to read, because you don't see the comments in the editor. If you wish, I can send you the original xml files as a private message, but of course you can also just pluck them off the server.

    The floorplan image (top left) has no parent set, while the icons on it have plugin[floorplan] as parent.
    Also the housemap (white surface bottom left) has no parent, and the images on it have plugin[housemap] as parent.
    The names of the icon plugins, made with addplugin(), start with "plugin_".
    The hotspots (magnifying glass) have no parent set. They are created with addhotspot and their names start with "hotspot_".

    I can't find addhotspot/addplugin in your xml files, can you please tell me where they are? You have a lot of stuff there spread across at least 3 files so I may have missed it.

    krpano.xml contains all the code (will be used to display all kinds of estates). Floors.xml contains the data structure for this particular estate.

    The plugins and hotspots are created in <action name="create_spot">
    <!--
    Creates an image hotspot or image plugin
    %1 = object instance that contains general data of all floors|panos
    %2 = object instance that contains general data of this floor|pano
    %3 = object instance that contains specific data for this spot
    %4 = object instance that contains specific data for this visual layer of this spot
    %5 = core name of plugin|hotspot to be created (without "plugin[]" or "hotspot[]" itself)
    %6 = type: "plugin"|"hotspot"
    %7 = offset to parent's zorder
    -->

    To find addhotspot() or addplugin() there, look for add%6 instead.

    I know it's very overwhelming at first, I'm sorry about that. It's also not my latest code, yesterday I figured I can use images with multiple icons in it, and then crop the desired part, which divides my number of plugins needed by 3.

    But I thought the real-time information as can be obtained from the xml editor is more useful, because there you can inspect the objects as they are at the very moment they are misbehaving...

  • regarding to the problem - I think the 'penthouse' image must have set - parent="STAGE",
    this is the only thing which could explain that behavior...
    ... but I can't find that in the xml

    YES!!!! You are correct! I tried that because I hoped it would solve my previous troubles.

    You don't find it because it is in floors.xml, which contains general descriptions of plugins and hotspots, and then also a list of all plugins and hotspots. The part in particular you are looking for is:

    <component name="hotspot">
    <type name="pano"
    parent="stage"
    baseurl="../../_images/"
    zorder="100"
    align="lefttop"
    edge="center"
    onclick="next_pano"
    />
    <type name="still"
    parent="stage"
    baseurl="../../_images/"
    zorder="1"
    align="lefttop"
    edge="center"
    onclick="show_still"
    />
    </component>

    I've disabled it now by changing it into xxxparent="stage". Will that solve all my problems, including the failing automatic cleanup of the hotspots after loading a new pano?

    PS. It is strange that the parent for the hotspots is not mentioned in the XML editor...

  • I've disabled it now by changing it into xxxparent="stage". Will that solve all my problems, including the failing automatic cleanup of the hotspots after loading a new pano?

    I can't say that for sure, but it should be helpfully of course,

    why have you used the STAGE parent?
    normally it's only useful when wanting to place objects outside the pano area when using a smaller pano area (by the <area> tag)

  • Interesting stuff, thanks Klaus.

    rd: I see. I kind of just skimmed through your files (including utils.xml) so I didn't catch that, sorry. I'm simultaneously struggling with AutoPano trying to make it stitch flat images (and failing miserably!)

  • I had no idea it was so bad to use STAGE as parent... *whistling* I had assumed that STAGE was the bottom-most layer, not the topmost. I don't remember right now what made me try that.

    In order to find out if also the error on removing hotspots is gone, I have changed the line
    fadeout(%1[%2], get(default_tween_time), set() );-->
    into:
    fadeout(%1[%2], get(default_tween_time), set(%1[%2].keep, false) );

    It looks like it's working now, even after changing panorama after panorama, everything still looks fine. However, I don't have a flash with debug here with me, so only tonight will I be able to know for sure if these problems were also solved by removing "STAGE" as parent of the hotspots. But so far it looks good. *thumbsup*

    I really want to thank you very much for your most excellent support.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!