• Could someone please explain to us that we still do not understand. Why the variable scope is especially helpful? I have read trying to understand, but I still do not grasp the meaning and I would like to understand how to apply the concept
    thanks in advance
    Ramiro

  • Could someone please explain to us that we still do not understand. Why the variable scope is especially helpful? I have read trying to understand, but I still do not grasp the meaning and I would like to understand how to apply the concept
    thanks in advance
    Ramiro


    pr12


    pr13

  • Very nice update! Thanks for your continued support and development *thumbsup*

    Is it possible to use the new "fisheye image"-support to also embed undistorted fisheye-images as hotspot or plugin/layer?

    And is it now possible to change the pano-image on the fly? For example changing a 360-photo for a 360-video without loading a new scene?

  • Quote

    And is it now possible to change the pano-image on the fly? For example changing a 360-photo for a 360-video without loading a new scene?


    Why would you want that?

    Tuur *thumbsup*

  • Could someone please explain to us that we still do not understand. Why the variable scope is especially helpful? I have read trying to understand, but I still do not grasp the meaning and I would like to understand how to apply the concept


    Hi,

    e.g. when doing a:

    Code
    set(i, 0);

    anywhere in a normal action then that 'i' variable will be defined in a 'global' scope - and that means that variable will be available also everywhere else in all other actions.

    Here a case where this is problematic - one action does a for loop using an 'i' variable as counter and in the inner loop it calls another action that also does a for loop using an 'i' variable:

    Both actions are using the same 'i' variable and so the output will be 3 x hello, because after the inner action call the 'i' is already 3 and so the outer loop will also end.

    But when adding scope="local" to the actions:

    both actions will define their own local 'i' variable and the output will 9 x hello.

    That means it can help avoiding conflicts when using the same variable names in different actions.


    The next thing is that this local variable scope for an action allows adding variables that will exist only in that action. And this is ideal for passing arguments. An argument passed to an action can be made available as local variable in that action.

    And arguments as local variables has these advantages:

    • It allows writing better self-describing code - e.g. using 'caption' instead of just a '%2' in code.
    • It avoid problems with string escaping - when an argument will be a string that contains quote or comma characters then it can be problematic to quote the %NN placeholder in a way that it can be used as string again.
    • When the action doesn't contain any %NN placeholders, its code will be basically 'static' - and this allows internally to cache the parsing or to pre-compile the code - and this can make its execution much faster (currently this not implemented, but its' already in work for the next versions).


    That means ideally all new actions should use scope="local".
    With the following versions I will also update/port all current xml templates, plugins and examples to that (some where already updated).

    Best regards,
    Klaus

  • Is it possible to use the new "fisheye image"-support to also embed undistorted fisheye-images as hotspot or plugin/layer?

    No, the fisheye support is currently for pano images (btw - the fisheye support is not 'new' ;-)), but I was also already thinking about providing that feature also for hotspots - although there is a bit more difficult to implement, especially the hit-testing will be challenging - that would require an inverse formula for the fisheye distortion, but I think that's mathematically not possible...

    And is it now possible to change the pano-image on the fly? For example changing a 360-photo for a 360-video without loading a new scene?

    What's the problem with doing a loadpano/loadscene/loadxml call to change the pano image?

    Best regards,
    Klaus

  • What's the problem with doing a loadpano/loadscene/loadxml call to change the pano image?


    It would be a very helpfull feature for very complex tours with lots of global actions (events onnewpano, onremovepano etc.) and scene-based onstart-events. If you just need to switch to a 360°-Video for a short time for example, there are a lot of if-then-else routines necessary in those events, event-driven actions and autostart-actions to exclude their auto-execution. It would help to reduce the amount of work drastically if you have just a few scenes but each scene needs to switch to 10+ 360-Videos for just 10-20 seconds. With the possibility to replace the pano-image/video on the fly a simple action could replace 100+ 360-video-scenes.

    And it would also be a great way to include window-views for example without the need to load a new scene. Just switch to a quick 180°x180° fisheye-pano for a few seconds and return to the room WITHOUT loading all scene-elements again. The keepall-flag is just not the best way all the time *sad*

    Best regards,
    Nupsi

  • Very nice and stable update *thumbup*

    Minor issue : Is it possible to avoid the image blink when editing a textfield css on the fly with an [img] link into ?
    It can be tested on the Combobox sample with a "rounded" design on the "thumbnails bar".
    And also with a multiple scenes project the select of an item can be masked into the list if a removeAll / addItem is used prior to the select.

    Edited once, last by benji33 (September 27, 2017 at 10:59 AM).

  • Hi Klaus,

    try out the new features...MANY THANKS for the cool new updates... *thumbsup*

    Found out, that if you use an own tour.xml, not that one that's generated by the VTOUR droplet, I can`t add/edit hotspots.
    With the old flashPlayer Version it was/is working...
    My panos are also seperated in scenes like in your tour.xml, but I don`t use the "vtourskin.xml" and the "skin_settings"...


    Will that be considered in future/final version?

    Best regards,
    Steve

    Edited once, last by svb (September 28, 2017 at 3:38 PM).

  • Ummm...this update totally killed all the (html) input fields in our plugins. Works well with 1.19 pr10, does not in pr13. Any ideas?

    (ps.: not talking about mobile stuff, this is on the desktop platform)

  • And it would also be a great way to include window-views for example without the need to load a new scene. Just switch to a quick 180°x180° fisheye-pano for a few seconds and return to the room WITHOUT loading all scene-elements again. The keepall-flag is just not the best way all the time *sad*

    Additional IMAGEONLY and NOEVENTS flags for the loadpano/loadscene/loadxml actions might be a possibility for such...
    What do you think?

    But sending no events could be problematic when the fov-ranges of the new image would be different...

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!