You could try making it so that the door code is actually the sum of all the separate numbers added together, and inputting the code just adds the numbers up. Then when the sums match, the door opens. Kind of a cheap way to do it, but it would work. Then they could punch the numbers in in any order they wanted.

I know, but doesn't the .mod plugin like, translate stuff into direct...

You know what, nevermind . I don't know how any of this works, let's just pretend I didn't ask anything.

I think it's under a + rollout thingy labeled "Advanced" or something like that. I'm not sure, I'm not on my Construct computer right now.

How will this new XAudio2 thing affect .mod files? Will they still play normally?

I just recently found a .mod tracker that I'm comfortable with (it has a piano roll instead of the usual top-to-bottom setup that trackers have) so I'm getting into making .mod music because the file sizes are so much smaller.

Edit: Never mind.

I should really check if there's another page before replying.

A bit off-topic: I hope they plan on making the sprite icons update automatically whenever the sprites are edited; but that's more of a feature request.

The sprite icons will update if you edit them by double-clicking frame 1 of the default animation in the Animation tab. You can use this as a workaround until it's fixed. This will update the icons for the object pickers in the event sheet editor.

I've noticed though that the Object list tab won't update the icon until the .cap is closed and re-opened... yet again another small bug that I've been meaning to report but haven't got around to. I should really set aside some time to report all these, I keep putting it off. I always just say "eh, I'll do it later" and then promptly forget all about it.

Maybe I should just make a quick list as I come across them to remind myself and submit the list all at once when I'm not busy.

Try using the timedelta override in the App properties.

My last problem is that the character will run into a "wall" which is declared as a solid, yet the character will magically "jump" to the top of the wall or even stick to the sides half way up/down the wall... even if I change the collision mode for the player to bounding box (which I don't really want anyway). I fixed that by making an event "if player collides with wall">"player stop" but this creates undesired results depending on the current animation frame of the player if they are running.

This happens when your animation frames aren't a consistent size (which is almost always when it comes to animation). What's happening is that on one frame your animation might be 20px wide, then your character hits a wall. The next frame is then a pixel or few wider, which means your character is now intersecting the wall.

The platform behavior automatically pushes sprites up when they're stuck like this. This is necessary for gravity to work... when a sprite is falling, the platform engine checks for intersection, and if there is, it runs a quick loop to jump the player to the top of whatever it's intersecting.

The way to work around it is to make a separate sprite for the player that is a constant size. A one-frame, one direction, single-animation, perfectly rectangular bounding box. The bounding box is what you apply the platform behavior to. Then you make it invisible and overlay your animation frames on top of it.

It's best to make your bounding box a sort of "average" size for your sprite, something that covers the main torso/head and goes straight down to the floor from there, so that extremities don't get in the way. If you need pixel-perfect collision for enemies or bullets or whatever, you could always use the player sprite to check for that (though I wouldn't recommend it for Mario type games).

Anyway, with a Flashback type engine you might want to avoid using the Platform behavior altogether. I know it would be a lot of work (one reason why mine is on hold) but it's such a unique type of platforming that trying to recreate it with the Platform behavior is probably a lost cause. Things like running and jumping aren't so much about moving the player sprite in x/y over time as it is about playing a specific number of animation frames to get from point a to point b. In Flashback all movement is very pixel-precise... the player's feet always land in the same place, he always jumps the same height/distance, and he's always lined up exactly with platforms when you stop, etc. The Platform behavior in contrast is very loose and sloppy in that regard. Trying to whip it into shape would be a lot of work, and you'll likely go completely insane from it.

As for the animations stopping, go ahead and post your .cap or PM me and I'll take a look at it.

Sorry for the WALL OF TEXT but hey, that's my style

You could do it with containers, sure. Put each key (you will have to make four different ones), a computer, and a door in to a container.

I don't know how you have the keys set up, so I couldn't exactly say how you should make them, but if you do something like this for the doors it should work fine

+computerSprite.Value("unlocked") = "yes"
  -doorSprite: Set animation to "Open"
[/code:2hsp6q2z]

I don't use Construct any more

You say this every time you post. You should just put it in your sig to save time

Deadeye, will that method save processing time? What i mean is, do you think containers are so much faster that having some invisible objects will still be faster that using the current method?

Honestly I really have no idea if it would be faster, I was just suggesting something else to try besides loops.

I am wondering something though... do your ships really need separate turrets? Like, is it purely cosmetic or do the turrets themselves take damage/get destroyed? I'm asking because maybe you can fake it with different ship sprites. Like, have one animation for your ship that has one turret, have a second animation that has two turrets, a third with three, etc. It would cut down on the total number of objects dramatically.

It seems to me that even without loops you're eventually going to hit a wall where you start getting sucky fps. Six hundred ships, each with multiple guns, each gun firing multiple bullets... that adds up pretty quick even without loops. It just sounds to me like you're going to have to make some sacrifices and cut some corners somewhere. Be as frugal as possible with your assets while still retaining the core of your gameplay idea.