• Dear Klaus,

    As it is now, if there is serious trouble inside an action, apparently the action may abort. However, if there were any push'es and pop's inside the action, and it aborts between a push and a pop, then the whole stack becomes corrupt.

    Such a problem is very hard to debug. I'm still in the process of figuring out which of my actions is aborting exactly where...

    Therefore I have 2 requests:
    (1) an onend="" event for <action>. It should always be executed after the action has ended, even if the action got aborted for whatever reason. Pop() statements can then be placed there.
    (2) if an action aborts, it would be nice if one could see that as a warning in the trace log, if possible with the exact command that caused the abort.

    Thanks for considering this.

  • I figured that the action "wait(0)" does not return in my script. I inserted it because otherwise I get the error "WARNING: actions overflow".

    I found this out by putting a trace just before and just after wait(0);
    It never reaches the 2nd trace, nor does any code get executed at all after that.

    Did anyone else ever had to deal with a non-returning wait(0) ?

    PS. A definable maxaction variable would really come in handy here...

  • That seems strange. Have you looked carefully around the wait statement for mismatched parenthesis, or quotes? These can sometimes cause very bizzare problems.

    Rather than an onend event which would fire every time an action completed, perhaps we could get an onerror event. That's where it would most make sense to put your cleanup code.

    I agree that error messages with line numbers and tracebacks would be a great addition, as well as the ability to have unlimited action depth.

    good luck. I know how frustrating this can be...

    steve

  • Steve,

    It was not my code. The same code is used repeatedly, and it only occurred when going from the initial pano to a next one.

    This morning I found the cause (well, more or less):

    So far, I had only dealt with plugins, but now I also needed hotspots. For my plugins, I was setting "keep" to true, and then removed them manually before a next set needed to be created. But for the hotspots I figured, hey, why not set "keep" to false here, because anyway all hotspots need to be released before each new pano. But right there, the erratic behavior started. I'm not sure why, as one would need to search inside the belly of krpano, but I tend to believe it has something to do with an onout event still being called of a hotspot while (or just after) it is being released. This is just my speculation.

    Anyway, as I'm way over my deadline, I need to keep going. So now I'm releasing the hotspots manually in my code, and it is behaving properly now.

  • Actually right now I'm again having more or less the same problem: sometimes, wait(load) just gets stuck, even though the loaded pano is all there and everything looks fine. But this time, when I click the pano when wait(load) got stuck, suddenly the action continues. Oh man...

    I guess it must be some timing issue. Not so easy to find out...

  • Hi,

    (1) an onend="" event for <action>. It should always be executed after the action has ended, even if the action got aborted for whatever reason. Pop() statements can then be placed there.
    (2) if an action aborts, it would be nice if one could see that as a warning in the trace log, if possible with the exact command that caused the abort.

    normally the actions (without using oninterrput or breakall,stopall) will be never be aborted,
    but when there is a syntax error, it's possible that they got parsed wrong...

    do you have an example where this is happening?

    best regards,
    Klaus

  • Yes, a few times it has been due to a syntax error. However, I believe it has also happened when accidentally null got passed as a parameter to certain built-in actions. Unfortunately I have not saved exact records. I will let you know if I would again bump into such an issue.

    Would you have any idea why wait(load) could get stuck, even though the pano has loaded? I have a trace before it and one behind it, so I can see it is really the wait(load) which got stuck.

    Code
    trace("%0 waiting till pano has loaded");
    		wait(load);
    		trace("%0 pano has loaded");

    Actually it would be an incredible help if one could turn on debugging, in such a way that each command would get shown in the trace log as it is being processed.

  • Thanks, I didn't know about that. I installed it for Firefox, and get the following:


    TypeError: Error #1010: Een term is ongedefinieerd en heeft geen eigenschappen. [meaning something is undefined and has no properties]
    at krpano.Kinterface::Kinterface_array/removeItem()
    at krpano::krpano_base/removehotspot()
    at Function/http://adobe.com/AS3/2006/builtin::apply()
    at krpano::krpano_interface/call()
    at kflashpano::Kactionqueue/process_actions()
    at action_baseclass/stop()
    at action_wait/process()
    at action_baseclass/actiontimerHandler()
    at flash.utils::Timer/_timerDispatch()
    at flash.utils::Timer/tick()

    I still have to investigate as to the reason. Seems like a hotspot is being removed which is not there... But which one, and why is it not there, that is what I'm going to try to find out now.

  • While debugging, I ran into this:

    Code
    <krpano default_tween_time="0.50">
    
    
    ...
    <action name="create_spots">
    		...
    		trace("%0 almost end ", get(default_tween_time));
    		wait(get(default_tween_time));
    		trace("%0 end");
    </action>


    gives:

    INFO: create_spots almost end 0.50
    WARNING: unknown action command: null;
    INFO: create_spots end

    I'm starting to think that somewhere I'm doing something which is somehow screwing up all the wait() commands, because the above certainly doesn't make much sense.

  • Hi rdhoore108,

    I have tried your code above and for me it seems to work correctly:

    Code
    INFO: krpano 1.0.8.11 (build 2010-05-31)
    INFO: Flashplayer WIN 10,0,2,54 PlugIn (debug)
    INFO: create_spots almost end 0.50
    INFO: create_spots end

    A little note: the get() action inside a trace() is not needed... trace() solves the variable itself...

    Code
    trace("%0 almost end ", default_tween_time));

    Have an happy coding time *g* *wink* ...

    SAlut.

  • Michel, well yes, that's what I mean: it's not supposed to produce that error. It also does not when I make it into a little isolated .xml. It only does it when it is part of my project. But unfortunately I need one big project, not some small isolated xml's... *unsure*

    I'm starting to think that it is NOT the wait command which is producing that error, but rather a command which gets executed as a donecall for a tween. It just happens to appear in the trace log at the wait command, probably because krpano handles its "interrupts" right there. And because there is no explanation of what line in which xml produced that error, I've allowed myself to be fooled in a grand way... *mellow*

  • This happens when "removehotspot(myhotspotname)" is called as a tween() donecall.

    So, my conclusions so far are:

    • it is not a good idea for me to set "keep" to false and have krpano remove the hotspots upon loading the next pano, because one of the hotspots may still have a tween action going on
    • it is also not good if I remove it myself, even after a wait, most likely for the same reason
    • therefore I figured, instead of removing the plugin, I will set "keep" to false, so that at the third pano, krpano will then remove the hotspots from the first pano automatically without problems, because by that time, these hotspots will be invisible and not in use by anything whatsoever.


    However, a similar flash error occurs when I click a hotspot on the second pano, to load the third pano (see below). Now I'm not removing them anymore, so it is krpano which tries to remove those hotspots with keep=false. But why that error?? *confused*

    TypeError: Error #1010: Een term is ongedefinieerd en heeft geen eigenschappen.
    at krpano.Kinterface::Kinterface_array/removeItem()
    at krpano::krpano_base/removehotspot()
    at kflashpano::Kpano/remove_not_keeped_objects()
    at kflashpano::Kpano/loadpano()
    at kflashpano::Kactionqueue/call_action_loadpano()
    at kflashpano::Kactionqueue/process_actions()
    at action_baseclass/stop()
    at action_baseclass/actiontimerHandler()
    at flash.utils::Timer/_timerDispatch()
    at flash.utils::Timer/tick()


    Of course, when I make a small sample xml, trying to remove a hotspot on the fly, it works just fine. Only in my project it needs to make trouble. *cursing*

  • I found the reason for the error.


    The reason is that I was storing some information of my own in the hotspot, for example I had added a property "prevscale", to be able to restore the scale to the original value after an "onover" tween.


    And flash doesn't seem to like that very much. *huh*

    Edit: forget what I wrote, the error is still there. It does not appear every time, therefore I made a wrong conclusion.

    It's like this: either the error comes, or otherwise wait(load) gets stuck.

    So I'm still in the mud. *thumbdown*

    - Ronny D'Hoore

    Einmal editiert, zuletzt von rdhoore108 (27. September 2010 um 15:32)

  • The only solution I found is to never remove a hotspot, but to make them invisible instead. Krpano doesn't seem to mind if one later calls addhotspot() using the name of a hotspot that exists already.

    It pretty much solves all the odd behavior.

  • Hi,

    TypeError: Error #1010: Een term is ongedefinieerd en heeft geen eigenschappen.
    at krpano.Kinterface::Kinterface_array/removeItem()
    at krpano::krpano_base/removehotspot()

    this error is very strange, and should normally never happen!
    what have you done with the hotspot before to get that?

    Zitat

    Krpano doesn't seem to mind if one later calls addhotspot() using the name of a hotspot that exists already.

    right, calling addhotspot for an existing hotspot is unproblematic, nothing will happen in this case,

    best regards,
    Klaus

  • Update: This was solved by Klaus in another post. The cause of the Flash error when deleting hotspots (manually or automatically by krpano upon loading a new panorama), was that I had assigned "STAGE" as the parent of my hotspots. Never do that! STAGE is a very bad parent, at least to hotspots it is. *tongue*

Jetzt mitmachen!

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