Another weird layer bug?

Armelline

This post is something of a rant, something of a musing, something of an appeal for help. Unless solving puzzles in GameSalad is a passion of yours, I'd recommend skipping it. It's a long read. Perhaps @BlackCloakGS or somebody from the GS staff can shed some light on it. I'd like to submit a bug report but I'm really not sure what it should be a report of.

A while ago somebody asked about Fruit Ninja style blades. I figured that I'd throw together a bunch of them to put on one of the template sites, as I'd not seen a decent one offered anywhere. This post is about a bug, not a template, so please do not PM me about getting it, and it's not for sale anywhere at the moment. I've kept the title deliberately vague to try to get people reading the thread who are interested in bugs, not blades.

I had no trouble getting the blades made, and was really quite pleased with the results. However, I kept encountering a bug and couldn't for the life of me figure out where in my logic the problem lay. Below are two videos. One demonstrating the effect I was after (right at the end after all the boring discussion), and one specifically highlighting the bug.

You'll notice that in the bug video, the first segment of each blade would not fade out like intended. For some reason, the logic in the actor would apply only after a couple of seconds had passed, or the touch was released. This felt like an issue that must be logic related. Something to do with the touch logic, or something to do with the logic triggering the fading out of each segment.

I spent hours testing and tweaking and disabling rules and adding in conditions and trying everything I could possibly think of. I even tried flat out destroying the first segment of each line, but when I did that the bug just shifted to the second segment. I tried having the first segment never being made visible, but again when the first segment didn't show, the bug would just shift to the second segment.

This made me start to think that perhaps the issue wasn't with my logic, but was perhaps with GameSalad itself. This is a conclusion I really don't like to come to, but sometimes is inescapable. 99.99% of the time when someone on the forums says "My game doesn't work, it must be a GameSalad bug", they mean "My logic is wrong, but I'm too confident in it to admit that". I've done the same dozens of times, only to prove myself wrong after more testing and consideration. In this case though I was really starting to think it was GameSalad at fault.

I gave up. I put the project away in a folder and didn't think about it again until today.

I stumbled upon it doing some cleaning up of my filesystem an hour or so ago, and decided that dammit I was going to figure this one out. I re-trod some of the same steps I'd taken back in February to try to figure it out. Then I noticed something I'd not noticed before - or at least not realised the significance of. When I let a line fade away completely, the bug happened on the next line I drew. If I started drawing the next line before the previous line had completely faded away, the bug didn't happen.

This led me to an inescapable conclusion: If an actor was already present on the scene, the bug didn't happen. Crazy as that might seem, it had to be explored.

I started off by thinking that perhaps it was still my logic, and so I pre-placed one of the line actors on the scene, disabling the logic that would affect future actors. The bug went away. I still couldn't see how this actor could possibly be doing anything to prevent the bug though, as most of the logic in it was necessarily disabled. So I made a new actor, and put it on the scene instead. The bug was still gone.

The inescapable conclusion at this point was that the presence of any other actor when the line was spawned would prevent the bug occurring. Even though the line being spawned had absolutely no connection to the pre-placed actor.

Relief! Bug fixed, not my logic's fault (probably). Then I remembered that I already had an actor on the scene. There had to be an actor pre-placed on the screen to register the initial touch - my "Spawner" actor. After that, everything happening logic-wise happens in the line. It's just one condition and one spawn actor behaviour in the "Spawner" actor.

So this blew my "has to be an actor on the scene" theory out the window. But putting an actor there was fixing the bug. There was only one other conclusion I could come to - one influenced by a discussion several forum members had in the Line of Sight thread yesterday. I'm going to be tagging you at the end of this post, sorry if you didn't want that!

I moved the empty bug fixing actor down beneath the "Spawner" on the layer list. From this:

To this:

Bam, the bug was back. It wasn't the extra actor that was making a difference, it was the position on the layer list that the line actors were being spawned at. If they were at the top, the bug would happen (but only on the very first actor spawned). If they were not at the top, the bug didn't happen.

This presumably meant my Bug Fixer actor was redundant. There was another way to ensure my spawned lines weren't the top of the layer list. So I deleted the Bug Fixer actor and made one simple change:

And with that change, the bug was gone again.

I'm still clueless as to why it was happening. I'm relived to have fixed it. I'm hoping it really is a bug in GameSalad and not my logic. I'm at a loss as to how anything in my logic could be causing it, especially considering the layer effecting things.

So I welcome any comments or suggestions or insight anyone can provide! Either that, or suggestions as to how to submit this as a bug report I'll happily provide the project file to any GS staff member who wants it to look at. I'm really not sure how to make a project specifically to highlight the bug as I've never seen it before under any other circumstances.

Perhaps the issue explored in the LoS thread and highlighted by @BBEnk in his bug comment is having a broader effect than just collisions? Or perhaps I've just totally missed something obvious?

@tatiang @pHghost @AlchimiaStudios

tatiang

You had me at

solving puzzles in GameSalad is a passion of yours

Go on...

I even tried flat out destroying the first segment of each line, but when I did that the bug just shifted to the second segment.

I feel you. Experiences like that make me want to pull my hair out!

The inescapable conclusion at this point was that the presence of any other actor when the line was spawned would prevent the bug occurring.

Ack! What?!

I appreciate the thoroughness of your explanation! So interesting to read through your thought process...

Here's the TL;DR version for other people:

When an actor is spawned at the top of the layer (e.g. "front of actor"), this actor permanence bug occurs. To fix it, either add an actor above it in the same layer or spawn it to the "back of the actor" to cause it to be below the spawner actor.

I'm sure it has to do with layers, as you described, and I'd recommend submitting a bug report with a link to this thread. Create two scenes, one with the actor spawned in front of the spawner and one with the actor spawned in back of the spawner so that GS Staff can compare.

Socks

@Armelline said:
The inescapable conclusion at this point was that the presence of any other actor when the line was spawned would prevent the bug occurring. Even though the line being spawned had absolutely no connection to the pre-placed actor.

This has been in GameSalad for as long as I can remember, it doesn't only effect spawned actors, although that's where I first encountered the glitch (the first actor being spawned in a timer loop misbehaving).

I've always called my fix actors (the ruleless blank actors) 'buffer' actors ! My thoughts were that the issue was a timing issue, with GS needing a temporal buffer so as to process data before moving onto the next cycle/frame/instruction. I also went through the whole spawn to back of layer, spawn to front of layer, move the actor up and down the layers (etc) routine, but now I just use a buffer actor, and in some complicated scenarios more than one . . . (see 'Layer Cam Buffer' in screenshot below).

Socks

@tatiang said:
When an actor is spawned at the top of the layer (e.g. "front of actor"), this actor permanence bug occurs. To fix it, either add an actor above it in the same layer or spawn it to the "back of the actor" to cause it to be below the spawner actor.

It effects not only spawned actors . . . and the actor not fading when it should ('permanence') is not the only way it manifests itself (although, again, this was the first way I came across it too), it can also, for instance, cause small positional issues with actors and other 'weirdness' (technical term, look it up).

Braydon_SFX

Interesting - I don't know if I've ever experienced this. I would guess it's a bug - has it been reported? I would assume so since @Socks has encountered it before and we all know that he hates bugs.

Socks

@Braydon_SFX said:
Interesting - I don't know if I've ever experienced this. I would guess it's a bug - has it been reported? I would assume so since Socks has encountered it before and we all know that he hates bugs.

I gave up reporting bugs a long long long time ago, it doesn't seem to get results, and the bug reporting system is (counterintuitively) limited to only Pro users, us poor folk can't report bugs I say it's counterintuitive because a non-Pro user discovering that (for example) using Futura as a font on a Galaxy Note II locks the phone up is valuable information that can only benefit GameSalad . . . anyhow, another discussion for another day . . . . but I think you are nearly always better off posting the issue on the forums, someone usually comes up with a clever solution or two, and this happens in hours rather than months/years, GameSalad is surprisingly flexible so where you do encounter a bug there will usually be a way to implement a good workaround.

Oh, yeah and I love bugs.

Socks

Here's a quick example that doesn't display 'permanence', but instead displays a positional error, but it's the same basic bug, which can be cured with a buffer actor to keep the spawned actors away from the top of the layer stack.

The video quality is terrible on Youtube, so the glitch kind of gets lost in Youtube's own stuttery playback - so I've attached the orginal Quicktime below, you can see it much more clearly in the original movie.

Summation

@Armelline Shot in the dark here, but maybe spawning in front of the actor somehow delays the start time of other logic?

Can you put a timer on the first five or so line segments and display them after your swipe is finished?

Socks

@Summation said:
Armelline Shot in the dark here, but maybe spawning in front of the actor somehow delays the start time of other logic?

Agreed, I also think it's a timing issue of some kind.

Armelline

Thanks for all the comments! Relieved to see other people have encountered this too!

When each actor is spawned, it registers the position of the touch at the moment it is spawned. This appears to be happening correctly. Once a certain condition is met, it is "placed", and made visible. This is also happening correctly. After that, it starts the process of fading out - this is the point where the problem happens. So about 20+ pieces of logic are running before one of them trips up. At that point, it does do what it's supposed to, but in the weird way demonstrated.

Summation

@Armelline I assume one of the 20+ pieces of logic you mention is a routine that tells the fadeout of the line pieces to happen in order of first to last?
If you're keeping track of positions via table, it should be a simple matter of telling the logic to do the rows (or columns) in order?

Armelline

@Summation said:
Armelline I assume one of the 20+ pieces of logic you mention is a routine that tells the fadeout of the line pieces to happen in order of first to last?
If you're keeping track of positions via table, it should be a simple matter of telling the logic to do the rows (or columns) in order?

Once a condition is met, a boolean is changed from false to true. Once it's true the fading takes place - within a timer (every 0.05s). I tried removing the timer behaviour and replacing it with a custom timer based on game.Time, though, and it didn't help. The lines fade almost immediately, as the preceding logic takes place over a fraction of a second. It isn't performed in certain order - each one starts fading essentially as soon as it's spawned. The first step of the fade does seem to happen immediately, it's the second step that doesn't. That's why I thought it might be the timer - runs first time, doesn't run correctly the second.

Summation

@Armelline Perhaps creating a maximum swipe time? Then, after all positions have been recorded, start the ordered fadeout? I know this isn't the effect you're looking for, it's just a check to see if this implementation will work as intended in order to narrow down the problem.

AlchimiaStudios

I actually often encounter a similar issue to this, which may have to do with the same layering issue. @Armelline

I also assumed it was because of the timing of layers as they execute in a certain order @Socks said. But it does seem to present a lot of problems.

The way it manifests itself for me is that I use an invisible movement actor for my game (2 actually, for the two active characters on screen) and then a separate actor for animations and other assorted logic. These are using constrains obviously, and in general work fine.

However when you change the layer order it begins to cause a constrain jitter, (constrained actor cant keep up and shakes visually) as if it is not updating quite as fast as before.

Sometimes even when I think I have the order right it begins to manifest itself again. Weird stuff. Seems like layering could be better for sure.

Summation

@Armelline @tatiang @AlchimiaStudios @Socks
I made a quick fading line demo if you want to check it out.
The "line" is by no means smooth (unless you go very slowly), but it seems to fade out reliably.

Rainbros

I've been having weird layer problems forever, including this actor permanence thing, jittery actors, delays, etc. Super annoying.

Attached is a stripped-down version of a little thing I had started (so I apologize for all the extraneous stuff) that demonstrates layer problems pretty clearly. As you said @Armelline, it's very unpredictable and hard to pin down. To see the problems:

First preview the game as it is. You'll be able to move the paddle via mouse and hit the ball around. Works fine.

Then, go into the control actor and change the spawn behavior to "in front of layer". Now preview and you'll see that it completely screws up the game, for no apparent reason.

Next, change that behavior back to in front of ACTOR so that it's back to normal. Then simply remove the blue actor from the scene. Preview now, and you'll notice that the paddle control is very glitchy and unplayable, even though the blue actor in the scene wasn't actually doing anything.

I really wish we could get a "stable" build that's actually stable.

Socks

@AlchimiaStudios said:
However when you change the layer order it begins to cause a constrain jitter, (constrained actor cant keep up and shakes visually) as if it is not updating quite as fast as before.

Yep, although I know the Armelline issue of actors not fading (and this is where I first came across the issue) the jittering is the main way it effects me - and yes it only happens with constrained actors - and it looks exactly as you explain, as if the constrained actor 'cant keep up'.

@AlchimiaStudios said:
Sometimes even when I think I have the order right it begins to manifest itself again. Weird stuff. Seems like layering could be better for sure.

Again, also agreed, sometimes you insert a 'buffer' actor to keep the actor away from the top of the layer stack, then later change something else (which doesn't effect position) and the issue is back !? Using multiple 'buffer' actors can sometimes remedy the issue, I've used as many as 4, take just one away and the glitch returns, my theory is that by adding extra actors above the problematic actor (in the direction GS scans the layers - bottom to top) You are forcing GS to enter extra steps (even if it is just to scan an empty actor for code) so that there is a momentary pause before moving on to the next instruction (there's a lot of supposition here, but as a basic idea it seems to work when practically applied).