Thanks. I knew I was doing something wrong. I didn't know the order mattered. I'll keep that in mind from now on.

I wasn't sure if this was a bug or if this is being caused by something that I'm doing wrong. I was pretty close to submitting this to the bug tracker but then I reconsidered since this may not be a bug (or maybe it is, I don't know).

Anyway, take a look at this:

http://machriderx.googlepages.com/shooter.cap

Open the .cap and run the layout. Notice that when you shoot an enemy, it destroys all the enemies at once.

Now go to the event editor, remove the "enemy is on screen" condition (only the "enemy on screen" one, leave the collision condition alone) and run it again. Now the enemies are destroyed by your bullets one at a time, how it should be.

I'm puzzled though. Why does adding the event "enemy is on screen" make it so that it destroys all enemies? Is this a bug?

If it isn't, how do I make it check for whether each individual enemy is on screen? I thought it was automatically supposed to do that.

Yeah like that cut out animation thing...man I wish I had known about that program before...I could have used that instead of programming a new behavior

Nah, don't say that. Anime Studio is nothing like the behavior you're making. It's just a program that makes (typically simple and rather primitive looking) cartoons using cardboard cutouts.

Here's a typical example of an animation it can make:

Here's a not so typical example video using the pro version (this person really put time into this one):

Anyway, it can't really be used for anything that would be usable in an actual game. Unless, of coarse, you wanted to make a cutscene with it.

Now the bone movement behavior you mentioned in the update, man, that's something else. I'm already envisioning making a 2D version of Toribash with it or even some ragdoll physics. Would that be possible with the new behavior? If so, that is amazing. Or sounds amazing anyway, I can't wait to try it out and see what it can do.

I don't quite understand what the problem is here. But I'll give it a shot.

In the pong example, the bats don't use a behavior (built in movement). They are controlled by events to move up or down by their Y axis values. That is why they are able to move through the red bars, even though the bars are set to "solid" (which only effects behaviors).

Construct already is set to handle solids and collisions between solids, but it only does it for behaviors (the built in movements).

However, as an alternative, you can also make your own movements using events. But if you do that, you also have to code in the collisions yourself (which the Pong example doesn't do).

The platform behavior only allows you to enable or disable "inverse controls" or "bunny hopping" through the properties window in the IDE.

There is not an option switch either of the two settings on or off through the event editor, at runtime.

This is important, mainly for inverse controls because when you switch the gravity direction to up, left becomes right and vice versa. Being able to add an event than turns inverse controls "on" would make it so when you reverse gravity, left still makes the player go to the left and right still goes right.

But in general, having more control over a movement is a good thing. And as it stands, you can alter all of the other platform behavior properties at runtime (through events) except "inverse controls" and "bunny hopping." I think this needs to be fixed.

Dunno if that helps i was working on a game and have made something like that

-day\night effect

-attack

-minimap

-small interface

M - show map

Crtl - attack ( if you have a sword)

Spacebar + direction keys -> browsing trought yhe menu

http://www.speedyshare.com/595271361.html

Hmm.. interesting. You used the canvas object to obscure the regions of the map that haven't been discovered yet. I never thought of that.

Maybe I might be able to do something with the canvas object. The only thing is that I don't want the actual level to be blacked out since it is a platform game (with jumping and platforms) and blacking out parts of the level could be fatal.

I'm going to try messing around with it and seeing what I can do.

Also, I still want to know, is there a way to make the minimap zoom in closer?

Nevermind, I figured it out. It was rather simple. All I had to do was "If "Tile" is on screen" then "draw terrain "Tile" on minimap" and it worked.

The only thing is though, I used quick backdrops for a large portion of the tiles (I got tired of cutting and pasting tiles over and over again), and this ends up showing the entire batch of tiles all at once rather than one at a time, revealing huge chunks of the level that I don't want the player to see yet.

I guess I could replace the quick backdrops all with single tiles, but that really is a pain.

Edit: Anyway, here's an updated cap (with only quick backdrops shown on the minimap, notice how much of the level gets shown).

http://machriderx.googlepages.com/quick ... roblem.cap

Time to start replacing those quick backdrops with single tiles, I guess. That is, unless someone knows a way around this.

Oh and btw, I also would still like to know how to zoom in more on the minimap if anyone knows.

I am making a platform game with a minimap. The levels in my platform game will have many secrets and traps. I tried making the minimap display the level terrain but it ends up spoiling all the secret areas that I don't want the player to see.

I want something like the minimap in Super Metroid, where you can only see the areas on the map that you've actually been to. As you advance through the level, you begin to reveal more and more of the map.

How exactly do I go about doing this though?

Edit: Here is the .cap file I'm working on, if you want to look at it:

http://machriderx.googlepages.com/minimapexample.cap

Also, on a related note, how do I make it so that the minimap is not zoomed so far out? I want the minimap to be zoomed in a bit closer to the action rather than zoomed all the way out.

Can't you just assign the controls to this blank space?

Doesn't work for the car movement for some reason. It just causes it to default back to left and right arrow (making the behavior go back to the whole only turning while moving thing). I forgot to mention that.

I'm not sure if it's a bug or if the blank space is supposed to even do anything. I think it does for other movements, but the car movement just defaults back to left and right arrow if you try to use the blank space.

Edit: I just tried using the blank space to replace the "move left' control on a platform game I was making. And guess what? I tried it in game, and left arrow made my character move left, even though I assigned the key to the blank space.

Well, since this seems like a bug, I'll try to report it using the bug report tool. But that's hardly what I wanted to suggest on this thread. To get back on topic, let me repeat by saying all I'm suggesting is to add a checkbox to make it so that the car can still rotate while stationary. Just a minor little thing, but I still think its a good idea.

Yes, I'm able to achieve the same effect without it, but that's not the point.

I don't need to. I already had a work around before I even suggested this. I fixed it in the events rather easily. I just disabled the built in keys (assigned them to ESC anyway, you can't seem to outright disable them which is a real pain) for car rotation, then made it so in the event editor the right and left keys rotate the sprite clockwise and counter clockwise.

But, yeah, that's all besides the point. Even though I am able to fix it with events, that doesn't change the fact that this feature still ought to be there in the first place. Just a simple checkbox to enable rotation while stationary would still be a good idea.

The car movement doesn't let you rotate when your object is standing still. This is great and realistic for a car. But say you have a hovercraft, or maybe even want to make a top down survival horror game with "tank" (early Resident Evil game) style controls. For that, you would need to make it so that the player can still rotate even when standing still.

Anyway, all I suggest is just a small checkbox to "Allow rotation while not moving" or something like that.

Okay, thanks. Yeah, I wasn't checking under system, I didn't expect it to be there. I was looking under the object itself because MMF/TGF and other CT products usually have the compare condition listed there. Old habits die hard, I guess.