interstitial ads causing delays in timer triggered events

playincorporatedplayincorporated Member, PRO Posts: 18
edited June 2014 in Working with GS (Mac)

Hey everyone,

When changing scenes from one to the next, any timer related events on the subsequent scene are delayed. They eventually fire, but only after a variable amount of time passes (the duration of which seems to be dictated by the time spent with the interstitial ad onscreen).

It appears that the actor who has the timer has had their self.Time modified to a negative number. The size of that negative number directly relates to the time (in seconds and milliseconds) that the interstitial ad was onscreen.

It may be that all actors have their time made negative.

Has anyone else come up against this? Super frustrating as each scene in my game has animation that is delayed by "after X seconds" timers. Please see the attached game project.

Psuedo timers (using self.Time) do not seem to solve this issue. Nor does fudging using interpolation (see the disabled "interpolation timer" on scene 2). All are delayed.

Comments

  • playincorporatedplayincorporated Member, PRO Posts: 18
    edited June 2014

    Update: actors placed off screen for use as pseudo timers (testing for an actor's position after interpolation to that position) are moved so that the distance traveled is equal to the timer plus negative time (if that makes sense).

    Basically, whatever speed the actor needs to travel at to be at the new X co-ordinate is multiplied by the negative time to create a new starting point... again I'm probably not being super clear. See attached updated test project - the pseudo timer actor is originally placed at x440. Depending on the time spent with the interstitial onscreen, the actor is moved by GS to another x co-ordinate, one that will satisfy the original interpolation speed plus the negative time.

  • playincorporatedplayincorporated Member, PRO Posts: 18

    This issue renders monetization via interstitial ads a no-go. The delay this causes makes our app look like its poorly built and will likely cause the user to rapidly un-install the app.

    With the lack of IAP abilities, ad monetization is a priority. Hopefully GS can investigate and get to the bottom of this in a nightly build.

    Thanks!

  • playincorporatedplayincorporated Member, PRO Posts: 18

    Found a wonky work around... hopefully this helps someone.

    Instead of changing to your actual scene, change to a intermediate scene. A scene that only has two actors on it, both with their opacity set to 0.

    Have them overlap (this is key).

    In one of them, have a rule that states that if the actor overlaps the other actor, change to your actual scene.

    This is important. Just making an actor change the scene without interaction doesn't seem work. So the overlap kludge is necessary and, as far as I can tell, works.

    Hopefully this helps someone.

  • jferris1392jferris1392 Member, PRO Posts: 1

    playincorporated,

    Your work around has helped me fix the interstitial issue. Thank you! :smiley:

  • Walter01Walter01 Member Posts: 10

    @playincorporated said:
    Found a wonky work around... hopefully this helps someone.

    Instead of changing to your actual scene, change to a intermediate scene. A scene that only has two actors on it, both with their opacity set to 0.

    Have them overlap (this is key).

    In one of them, have a rule that states that if the actor overlaps the other actor, change to your actual scene.

    This is important. Just making an actor change the scene without interaction doesn't seem work. So the overlap kludge is necessary and, as far as I can tell, works.

    Hopefully this helps someone.

    Thanks
    I had a similar problem & this did work to correct it
    it still gets stuck sometimes though, but that may be due to a different issue

Sign In or Register to comment.