I tested this out for several minutes and my MAIN concern - not being able to go through junctions when the path is open, and vise-versa - appears to be resolved. That is ABSOLUTELY a God-send! Thank you again! You're a life-saver! I'm trying to get this ready for a March 31 release and you nailed it!

blackhornet - Thank you so much! I'll have a look now that I can actually get back into Scirra.com.

While waiting for the servers to get fixed, I've doing my own tinkering and almost had a solution...ultimately, same problem. If this doesn't work, I'm going to try something different than the sliding walls altogether.

Also, I corrected the fact that you could slide through walls while they were moving - that's not supposed to be able to happen and I just hadn't gotten to a fix yet.

That two ghosts can be on the same junction shouldn't be an issue. ... But then (as you know) I'm in a constant discovery state, where things come up that I didn't know about or didn't account for. So, if it's an issue, it's PRESENTLY outside my scope.

Thanks for your help, as always! You're awesome!

As you suggested, blackhornet, I tested things on a smaller scale, and as far as I could make out, everything worked. I only changed the layout, using fewer sliding wall pieces.

When I copied my current layout and deleted about 2/3 of the maze, I didn't realize at first that that would re-do the UIDs for each object. So I updated the Wall_UID variable values for each of the JunctionCheck object instances. ... That seemed to work.

But then I went back to my original layout and found that all the WallSlide UID values and the Wall_UID variable values had not changed. There was no problem there. It was all exactly as I set it up and should be.

So now I have tried...

1. Removing the Pick All condition (lines 103 and 118), and putting them back.

2. Adding a For Each JunctionCheck as a 3rd condition on the same event lines.

3. Replacing the Toggle Boolean with If This/Else conditions for the same variables (sub-events for lines 103 and 118).

What I have found is that some of the Boolean values will change while others will not when addressing each set of JunctionCheck Boolean variables as related to their respective WallSlide object. When the WallSlide is done sliding positions, it seems that...

1. Two of the four JunctionCheck Boolean values will update properly.

2. All four Boolean values will be completely opposite of what they should be (making it possible to pass through the wall when you shouldn't, and the other way around).

3. Some JunctionCheck sets will update fine without any trouble whatsoever.

So I'm totally confused as to what's going on. I cannot figure out WHAT is causing this problem.

I THINK I discovered the issue. I must have manually set the instance values for all the JunctionCheck objects (which is the UID of each WallSlide object they're associated with) and then edited the maze further but did not update the UID values. As a result, the JunctionCheck variables are looking for a UID value NOT associated with the correct WallSlide object. I'm going to have to manually check this for each one to verify, but I already discovered one such discrepancy...

Heh, I did figure that might be the next step.

I shall do that...

.CAPX: https://dl.dropboxusercontent.com/u/36080515/Pacman%20Rush%200-2-4.capx

This may be a somewhat complicated/confusing issue, so I will try to be direct and clear. Please bear with me.

I am working on a Pacman remix game. To make things more interesting, there are sections of the maze where the wall shift, creating alternate junctions at the opposite end of the wall that shifted. These sections of walls switch positions (moving back and forth) randomly and independently of each other. SO the chaos is real, my friends!

I won't go into detail on how I make it work (you can review the .capx if you like), but I used sprites - the JunctionCheck objects - to identify which directions Pacman can travel at any given junction. (Yes, I tried to use the Solid behavior on the walls, themselves, but that proved problematic. Hence, this "convoluted" system.) With the WallSlide objects, the available directions open to Pacman or the Ghosts constantly changes every time the walls shift. For the most part, this system works...though I'd like to refine it a little.

The problem I have discovered, which seems to have come after some other changes I made, is that there are times when the JunctionCheck objects do not always get their respective Boolean values updated/toggled every time the WallSlide object shifts. (I use an instance variable to identify which sliding wall the JunctionCheck objects are related to.)

For instance, there is a corridor that runs north/south, and on the left side of the corridor, there is a section of the wall that shifts. It's in its "up" orientation. This means that the top part of the sliding wall is flush with the normal section of the wall. At the bottom end of the sliding wall, there is a junction where Pacman can move eastward.

If you open up the .CAPX I provided above, here's how the process works (starting at event line 94).

1. All WallSlide objects have their instance variable WallSlideTimer ticking down to zero.

2. If the timer is <1, a warning will occur signaling that the wall is about to slide positions. (This works fine.)

3a. If the timer is <0, reset the timer (to ensure this event only happens once while true) and set the instance Boolean variable IsSliding to true (this is to call on only the WallSlide instances that are ready to slide).

3b. The instance variable LerpLowHigh is my check to tell the system when to shift the wall up/down or left/right (in relationship to another instance variable).

4. While the Boolean variable IsSliding is true, the system will check to see when it has reached the end of its lerp transition. When it has, it will set IsSliding to false to ensure this process only happens once.

5. When the lerp has finished its transition, it will call on all the JuctionCheck objects that are associated with it. Each JunctionCheck has two sets of variables: one that says what directions are available at any given time and another that says which of those directions are to be turned on or off when the walls have finished sliding. So if the direction North was open to travel at a junction, but then the wall slides, the N_open Boolean will be toggled to false (where it was previously true). It will only toggle the Boolean values if its respective (direction)_changable Boolean variable says it can be toggled (it must have a true value itself).

6. Then, at lines 115 and 116, the position of the walls are updated accordingly.

The only thing I cannot figure out is why the Boolean variables (ie: N_open) will sometimes not update properly even when the other JunctionCheck objects associated with the same wall will update just fine.

I suspect the problem started when I added the IsSliding Boolean variable, but even if that's the case, I do not see how that could cause the problem. Alternatively, because there are so many JunctionCheck instance objects to deal with, it is somehow possible that some are not getting properly picked? (I have manually checked in the debug that all the instance objects are toggling, but occasionally they get "missed" and then end up with the opposite value than what they should have.)

Someone with a keener eye than mine would be greatly appreciated.

It's likely my understanding of how picking works or some other factor is escaping my grasp here...

Thank you again for your patience and your help.

PS: NO, I am not going to put this game up to sell. It will be free-to-play as I very clearly do not own the rights to Pacman. I'm doing this for my portfolio and to grow my game dev skills. ... Just because someone is GOING to ask and others already have.

Ashley - Thank you for the info. ...so much still to learn.

I must admit I only use Chrome (I know better, but I don't usually test on Explorer or FireFox).

I'll search so more for audio playback issues to see if I can find anything worthwhile.

May I ask what events you speak of that caused issues in the past? Maybe that's what I'm doing and don't realize it... Though, I would be surprised if that's the case since I don't think I'm doing anything extraordinary...but then, I'm not adept at audio, either.

Here's my .CAPX.

I'm just as confused. On occasion, it works just fine. No delay.

Ashley, may I inquire what it is that I'm missing in this case, please?

ultrafop - Yeah, it was my understanding that all sounds are preload at the start of layout...but that doesn't seem to be the case after all.

I go ahead and preload the sound file on a Start Of Layout event line, and then, on a new event line, I prevent the rest of the project from advancing until that sound has finished preloading. But, when I call on the sound file to play, it still has that split-second freeze-up. So that's what is confusing me.

it is my understanding that all SOUNDS in the SOUNDS folder should be automatically preloaded so that playback is instantaneous. However, every time I go to play a sound effect there is a brief lockup/delay in the whole project when the audio file is first begun. I even added an event that tells all other actions to wait until audio preloading is complete. The ONLY sound effect in the whole project now is no more than 10-11 seconds long.

What could be causing the audio (and the whole project) to delay/lockup upon initial playback?

Thanks!

teacherpeter - Yeah, originally I thought it might be a For Each loop I had going... SOMETHING that was demanding a LOT of checks per tick.

.CAPX: https://www.dropbox.com/s/x0raalfkw3rku3z/Pacman%20Rush%200-2-1.capx?dl=0

C2 RELEASE: r221 (stable)

ISSUE: Prior to adding any events or objects for the Ghosts in my Pacman remix game, everything seemed to be operating okay in terms of overall game speed. But upon adding the Ghosts (there is supposed to be 16 total, 4 of each color), the CPU usage amps up to between 90-100%+.

I toggled all event lines for the Ghosts as disabled, removed the Ghosts from the layout entirely...nothing helped. So I saved the .capx and restarted C2. At first, it seemed to work. But when I re-added all 16 Ghosts and re-enabled the event lines (incomplete as they are), the same problem resumes. After several seconds, the game seriously bogs down. It's playable, but the framerate hits near-bottom and is basically slugging.

None of my past projects have really gotten so far to the point where I've encountered this problem seriously, and even those past projects had DOZENS of objects with particle effects, no less. So I'm at a loss as to what's causing this slowdown. Your insight would be greatly appreciated. Thank you.

UPDATE: I think I have solved the problem.

In the in group (line 111) "Ghosts At Junction", I added a condition that checks for the lerp value of the shifting walls and then told it only to update the junction values just once while true. I re-ran the game and it is still going fine after a couple minutes.