Bug? Transitions on Logic Blocks not active at start up?

[Branigan]

Here's what I want to do. Have a logo slide in when the panorama starts, wait a few seconds, then slide back out.

The sliding out is easy, put a timer around the logo, on Active the position changes to X:-500 over a 1 second transition and away it goes.

Sliding In: not so easy. First I set the initial Position of the image to X: -500 to move it off the screen, then on any Position Logic Trigger at all (Player Width >0) set X:0 and have a transition of 1 second.

In theory this means it will immediately start sliding in over one second, then the timer will count down and that will slide it back out.

Nope. It's immediately visible. Setting the Transition time to 10 seconds = It's immediately visible. Setting any and all triggers to activate it: it's immediately visible.

I'm sure I could - and will probably have to - make this more complicated with a separate timer and variable to control it sliding in, but why doesn't the initial position Transition work?

I tried the same thing with Alpha fading up from 0 to 1 and got the same result: it's immediately visible.

Am I missing something simple, or do I have to complicate it further?

[Branigan]

OK, I answered my own question, but have no idea how it worked.

The trigger that worked was 'Loading' , which then set it to Transition smoothly from -400 to 0. So...backwards?
.

loading.jpg (46.72 KiB) Viewed 4263 times

[Multimediafabrik]

you could try to make a variable $(*finished_loading). Set an action on your container, with the source "images ready" ,the action "set variable value" and the value "true". then add a "on variable change: $(*finished_loading)" trigger to the logo slideIn. Its seems like the same thing as the "loading" = "false" Trigger, but I think when the page opens, the initial value of "loading" isnt "true". I think at first its on "false" and once you read the config it's set to "true". So your SlideIn fires before the config is loaded, and therefor doesnt have the "slideIn" effect, as it just places the image, without its extra parameter. I haven't tested it, but I have a hunch, that it works this way. I hope this works for you.

[Branigan]

you could try to make a variable $(*finished_loading). Set an action on your container, with the source "images ready" ,the action "set variable value" and the value "true". then add a "on variable change: $(*finished_loading)" trigger to the logo slideIn. Its seems like the same thing as the "loading" = "false" Trigger, but I think when the page opens, the initial value of "loading" isnt "true". I think at first its on "false" and once you read the config it's set to "true". So your SlideIn fires before the config is loaded, and therefor doesnt have the "slideIn" effect, as it just places the image, without its extra parameter. I haven't tested it, but I have a hunch, that it works this way. I hope this works for you.

Thanks, but I started with 'Player Width >0", which it obviously is, which should instantly trigger the value change and the subsequent Transition. The thing is: as it is true the value is changed, but the Transition doesn't bother to actually transition, it skips to 'finished!'.

It seems to be an 'order of operations' bug, because if I use Loading, then evidently it's not true immediately, so no Transition required; but when it is true and the Transition code is loaded and woken up and in place, it does its job fine. But on some platforms, it just loads faster, 'Loading' is true too soon, the Transition code hasn't woken up yet and it just skips to the 'done' stage.

With the timer I use, the tick is after a half a second or so, and it may not even get started until everything else is already loaded and running; by which time, when it triggers: the Transition code is in place and working and the banner slides as required.

It's the annoying little edge cases that cause the most grief.

[Branigan]

Here's a skin showing the problem.

A banner starts off screen, slides in on one timer, then out on another, except it should not need a timer to slide in if a condition that is True triggers a Transition.
.

Transition bug.ggsk

(1.65 KiB) Downloaded 156 times

.
It works with the second timer triggering it, but if you try anything else as the trigger for the Text to slide in: nada.

Even testing Display Width both as 0 and not 0 does not work. One of the times the test fails (as it should); but the other time when it is true, the Transition just does not transition and the position is updated immediately.
.

triggerworks.jpg (300.94 KiB) Viewed 4190 times

.
Change from the timer to just a true or false test and: not as expected.
.

triggerfails.jpg (57.24 KiB) Viewed 4190 times

.

triggerfails2.jpg (56 KiB) Viewed 4190 times

[Hopki]

Hi,
Looking at the request "Have a logo slide in when the panorama starts, wait a few seconds, then slide back out."

I would add your banner/text to the skin, and wrap a timer around it.
Set the timer:
• Type; Start
• Timeout: 2.00 seconds or whatever you want
• Repeat: One Time

Set the times position to X: -500px, Y:17px
Then set its position logic block:
Active, =, true X:17px, Y:17px

On open, this will slide out the timer and text box, after 2 seconds slide it back.
I also tried this with the alpha logic block and working.

LB.gif (944.13 KiB) Viewed 4162 times

Regards,

[Neal]

OK, I answered my own question, but have no idea how it worked.

The trigger that worked was 'Loading' , which then set it to Transition smoothly from -400 to 0. So...backwards?
.
loading.jpg

The reason that works is that loading is a percentage. That means it goes between 0 and 1. In javascript true = 1 and false = 0. There is a little bit more to it than that, but that is the basics.

[Branigan]

I would add your banner/text to the skin, and wrap a timer around it.
Set the timer:
• Type; Start
• Timeout: 2.00 seconds or whatever you want
• Repeat: One Time

Set the times position to X: -500px, Y:17px
Then set its position logic block:
Active, =, true X:17px, Y:17px

OK, great. Using the same timer to slide in and out? Nice.

So, I can use that as an alternative to what I'm already using, which now works anyway; but if you looked at my skin, you'll see that while it's not as elegant: in theory it should also work but doesn't, right?

If a Trigger is true, it should trigger the Transition, but the transition doesn't...transition. It just skips.
Are you going to acknowledge it's a (possible) bug for the bug list? OR have I misunderstood something?

The trigger that worked was 'Loading' , which then set it to Transition smoothly from -400 to 0. So...backwards?

The reason that works is that loading is a percentage. That means it goes between 0 and 1. In javascript true = 1 and false = 0. There is a little bit more to it than that, but that is the basics.

OK... but it didn't always work on all platforms, and on other True conditions the trigger activates, the position changes, it just instajumps so...still thinking it's a bug.

[Neal]

Here's a skin showing the problem.

A banner starts off screen, slides in on one timer, then out on another, except it should not need a timer to slide in if a condition that is True triggers a Transition.
.
Transition bug.ggsk
.
It works with the second timer triggering it, but if you try anything else as the trigger for the Text to slide in: nada.

Even testing Display Width both as 0 and not 0 does not work. One of the times the test fails (as it should); but the other time when it is true, the Transition just does not transition and the position is updated immediately.
.
triggerworks.jpg
.
Change from the timer to just a true or false test and: not as expected.
.
triggerfails.jpg
.
triggerfails2.jpg

Transitions are from one state to another. The player is created first and then the element. When the element is created, the player width is greater than zero, the logic block tells it where it should be placed. The transition doesn't work because the is no before state, the element did not exist. So there is nothing to transition from.

So for the transition to work, the element must be created off-screen first and then moved. That is why the timer works, it creates the element first off-screen and then moves it on-screen,

[Branigan]

Transitions are from one state to another. The player is created first and then the element. When the element is created, the player width is greater than zero, the logic block tells it where it should be placed. The transition doesn't work because the is no before state, the element did not exist. So there is nothing to transition from.

So for the transition to work, the element must be created off-screen first and then moved. That is why the timer works, it creates the element first off-screen and then moves it on-screen,

I'm guessing you've looked in the Player's .js code to come to those conclusions, I wouldn't know where to start.

Ignore the skin as downloaded: It works because I'm using two timers. Change it to use Player Width as shown in the screenshots.

If I'm following your train of thought correctly: Although I placed the element off screen (check its start position: X= -400 in the skin I uploaded. Make off screen elements visible in the Skin Editor to see it), it doesn't really/yet exist when the Logic test is done, so that's ignored? But if the Trigger value is False (Player Width = 0), it stays there, so it isn't ignored...? You can test that by placing it slightly on screen and that's where it will stay.

But when the test is for Player Width =/= 0 the Trigger state is activated, but with no previous text position for the 'non-existent' text element, as it gets created from....nowhere? the Logic Test goes: "Hey, where did you come from? Just stand over there in your new position, no Transitions for you..."?

I'm still confused. As text handling is apparently available fairly early in the loading process, so as to be able to show the loading bar text against a simple black background (then bits of the panorama tiles fill in on Light, you get a little more finesse with Pro), why isn't the Transition code also ready to deal with anything the text, or a banner image, might need to Transition to/from as well?

I'm guessing that to avoid failovers, any not-yet-initialised code is just skipped, but couldn't the loading order be rearranged, or it wait a few more seconds until everything is in place and ready to roll? That might also prevent the look of hotspots floating against a black background before the panorama tiles catch up to them (again: Light only, it's more smooth with Pro).

It's either a bug, or the order of operations needs defining and any limitations explained.

[Neal]

Transitions are from one state to another. The player is created first and then the element. When the element is created, the player width is greater than zero, the logic block tells it where it should be placed. The transition doesn't work because the is no before state, the element did not exist. So there is nothing to transition from.

So for the transition to work, the element must be created off-screen first and then moved. That is why the timer works, it creates the element first off-screen and then moves it on-screen,

I'm guessing you've looked in the Player's .js code to come to those conclusions, I wouldn't know where to start.

Ignore the skin as downloaded: It works because I'm using two timers. Change it to use Player Width as shown in the screenshots.

If I'm following your train of thought correctly: Although I placed the element off screen (check its start position: X= -400 in the skin I uploaded. Make off screen elements visible in the Skin Editor to see it), it doesn't really/yet exist when the Logic test is done, so that's ignored? But if the Trigger value is False (Player Width = 0), it stays there, so it isn't ignored...? You can test that by placing it slightly on screen and that's where it will stay.

But when the test is for Player Width =/= 0 the Trigger state is activated, but with no previous text position for the 'non-existent' text element, as it gets created from....nowhere? the Logic Test goes: "Hey, where did you come from? Just stand over there in your new position, no Transitions for you..."?

I'm still confused. As text handling is apparently available fairly early in the loading process, so as to be able to show the loading bar text against a simple black background (then bits of the panorama tiles fill in on Light, you get a little more finesse with Pro), why isn't the Transition code also ready to deal with anything the text, or a banner image, might need to Transition to/from as well?

I'm guessing that to avoid failovers, any not-yet-initialised code is just skipped, but couldn't the loading order be rearranged, or it wait a few more seconds until everything is in place and ready to roll? That might also prevent the look of hotspots floating against a black background before the panorama tiles catch up to them (again: Light only, it's more smooth with Pro).

It's either a bug, or the order of operations needs defining and any limitations explained.

Think of it this way, the player width is used to adjust the position of elements for different devices and screen sizes. Have the elements change position and sizes when you change the browser width is OK and looks good. But when you open the pano on a cell phone you really don't want the screen elements to start as if they were on a desktop and transition to cell phone size. You want everything to the show at the correct position for the cell phone.

The player creation is the starting point, it is the bucket that everything goes into. Until you have it in place, you have nothing to put the tiles, icons....into.

[Branigan]

Think of it this way, the player width is used to adjust the position of elements for different devices and screen sizes. Have the elements change position and sizes when you change the browser width is OK and looks good. But when you open the pano on a cell phone you really don't want the screen elements to start as if they were on a desktop and transition to cell phone size. You want everything to the show at the correct position for the cell phone.

The player creation is the starting point, it is the bucket that everything goes into. Until you have it in place, you have nothing to put the tiles, icons....into.

Yes, but all of that is irrelevant when I'm just using any aribitrary value's mere existence as a test of True or False.

You're trying to explain what you're explaining, without looking at the empirical evidence, or apparently using my skin to test it out.

I can and did use several other tests against things that just 'existed' to trigger the Transition from its original values to another one. If I could have found a way to test 1=1 that worked I would have just done that. In the end I used a Timer that took a while (0.35 s) to count down and set a trigger value to 1.

When I tried just initialising that same variable to 1: No Transition. It needed the short wait.

All the other tests of 'things existing' all triggered the Logic test as True because they were always true and however long it took for the Logic code itself to get started up: they'd remain true, it Triggered, the position was correctly updated from its start position - off screen - to the new position - on screen - but without showing the Transition movement because: too soon for that. The same applies to Opacity. That instantly goes to 100% from 0% if you copy the logic test to there instead of Position.

This (IMO) consistently points to: The transition code - or whatever internal timer mechanism it used to do the transitions - just isn't there to run when everything else is.

Using 'Loading' as a Trigger worked on the desktop because I suspect it wasn't considered as 'True' until the Transition code had a change to start up, and so it did actually Transition.

But on mobiles, where I have smaller, faster loading Tiles, then it became True sooner, the condition was triggered sooner, but...Transitions was still loading up/being installed/linked/threaded/whatever and...Instant position change because it wasn't yet ready to do the Transitioning.

Now that's the same flag being used under different timing conditions, so...where does it suggest the cause is?

It appears that things get loaded in stages: Variables (user and built-in: Display Width, Browser type etc.), Timers, Logic Test code to check things and react, then Transition code.

Need a Transition before its code is ready, but after the Logic code has reacted? You're SOL.

I'm just trying to join the dots, but if you've got a theory that fits the same evidence, I'd be happy to hear it.

[Neal]

I looked at your skin, what it is doing, and how. It is working as it should. I think there is a key point that you are missing. The skin editor does NOT create the objects, it creates a set of INSTRUCTIONS that creates the object.

The instructions in your skin say to create a Text banner that is 400 by 140. The logic block states that if a condition is true, create the banner at 0,-10 else create the banner at -400,-10. The transition setting says when you move from one place to another, transition that move over 0.5 seconds. When the banner is first created, it is not moved from anywhere, it is created at the position the logic block determines at the moment of creation.

So if the condition in the logic block is false, the banner would be created at -400,-10. When it is true, the banner is created at 0,-10.

After creation, when the value of the condition in the logic block changes that triggers a movement. The banner was created at one position, and the logic block now states it should be at a different position. Per the transition setting, that position should occur over 0.5 seconds.

For the conditions, there are statements that are always true, statements that are always false, and statements that change between true and false. Only the ones that change will cause motion.

[Branigan]

I looked at your skin, what it is doing, and how. It is working as it should.

Yes, I know it works as it is because that's the one I'm using. You're supposed to change it to break it and then explain why it breaks.

What you are saying happens according to Logic Block rules is not backed up by any other documentation or experience. And you can change what happens by introducing a small delay, so it's certainly not consistent doing what you claim it is.

Where does it say that the default value for something is not created before the Logic block triggers, considering the default position value is always there and will remain there if you remove the Logic Block itself?

We're just talking across each other, so consider this: why would the code say: "I know there is a default value, but I'll ignore that (somehow?) and only bother to set it according to either of the True/False values, when the logic block triggers; and even if I set it to the value triggered by the condition being valid, I'll ignore the Transition part"? If it does do that, then: dumb code.

You have a default value, you do the IF and don't do the THEN if not triggered. You should not really need the ELSE to put back the default value because it''s already there.
Even if is does do that just to have a redundant overwriting of a value that already exists: irrelevant because it's what happens in the THEN section that's screwed up.

I don't think you've changed the test condition to see what happens, so try this instead:
.

Transition bug4.ggsk

(1.65 KiB) Downloaded 156 times

.
It now tests for 'Has Touch' instead of my working Variable that's set by a timer. It's a good as any either "does it exist?" as "Player Width >0" and "Sky=Blue". The default starting position of the text's Logic block is X= -400, offscreen. If I remove that Logic block test, it will remain offscreen. It IS off screen.

The Logic Block comes along and tests for the trigger. In a Desktop the FALSE is the valid trigger value. IF it is Triggered, THEN the value is changed AND the Transition should do its job, but it doesn't. The position is changed instantly. It's ignoring the Transition part of its obligations.

Now do the reverse. Change the test to TRUE, so it goes IF Triggered....no THEN to do here... so skip to ELSE...which should do basically nothing because the default values should still be there. As said previously: shouldn't really need the ELSE, but: doesn't matter because the THEN is where the main work is - or should be - being done.

What happens is...the box does not move and stays off screen, because the Logic block skipped the THEN section and either overwrote the default value in a (redundant?) ELSE section, or just left it alone with its original default starting value. This is correct and expected behaviour, BTW.

The "....AND....now do a Transition" after the THEN (when triggered), is the broken bit. It's either not yet got the Transition code loaded, or it forgets to check the Transition Checkbox flag completely, but that's where the problem seems to be.

If there are dependencies based on when things load so we can't make assumptions at loading time that we can later - because then they'll work differently - we really need to know what they are.

[Neal]

Yes, I know it works as it is because that's the one I'm using. You're supposed to change it to break it and then explain why it breaks.

I did try to break it. I used different triggers, both true and false conditions, added delays. It worked according to the code. I did the same with the skin you just submitted. Now, that doesn't mean the block slide in and out as you wanted, it means that the block was created as the code stated.

Where does it say that the default value for something is not created before the Logic block triggers, considering the default position value is always there and will remain there if you remove the Logic Block itself?

The definition of default is what you do when there are not alternatives. I think that is what you are not understanding. So yes, you do ignore the default when the logic block gives you an alternative. No, you don't do the default first and then the alternative. The default is only done when there is nothing stating an alternative.

What you are saying happens according to Logic Block rules is not backed up by any other documentation or experience. And you can change what happens by introducing a small delay, so it's certainly not consistent doing what you claim it is.

Several of the trigger change values during the loading process. That is how they should work. What you are calling a delay is not a delay. It is the condition initially being such that the block is created off-screen and then changing so the block moves on screen.

(a bunch of stuff addressed by the definition of default)

The "....AND....now do a Transition" after the THEN (when triggered), is the broken bit. It's either not yet got the Transition code loaded, or it forgets to check the Transition Checkbox flag completely, but that's where the problem seems to be.

The actual code handling the transition is located in the browser. It is in place well before you ever start typing in the URL for the pano.
Transitions require both a from and a to. Without a from, there can not be a transition.

If there are dependencies based on when things load so we can't make assumptions at loading time that we can later - because then they'll work differently - we really need to know what they are.

That is why there are different triggers because we can't know how fast items will be loaded. "Loading" changes from true to false when the configuration is loaded. "Loading tiles" changes from true to false after the tiles have finished loading. "Start" is triggered when the skin is first called. The time when those triggers occur change based on loading speed and other events outside of the program's control.

Assumptions -- I have been doing this for a long time. My first lines of code were written over 4 decades ago. The hardest thing to learn about computers and coding is to not make assumptions. If your code depends on items happening in a specific order, and you do not have control over those items, you need to check that they occurred as you wanted. If you want your banner to show after the tiles are loaded, you need to check the status of "Loading tiles". Now the documentation does assume some basic knowledge of webpage design and coding. That level of knowledge is needed for the level of control and customization that it gives you.

For demonstration purposes, I suggest that you change the default location for the banner to 100,100. That will allow you to see when and where the banner is created, and when it is moved. It will better allow you to see what is happening when you change the different conditions.