Actually it would be way better to have the player choose which of the two he/she wants to use, or even to choose his/her own keys..

Then using keyboardkeycodes you wouldn't have the above issue anymore..

I'm not sure what you mean?

Seems like you don't want the car behaviour, because cars don't behave like that..

If you are talking like asteroid-type-spaceship-movement This tutorial might help..

[edit] Glad you figured it out![/edit]

Add another condition to the "failed to find path" event?

Maybe a boolean, set on a timer or a wait for signal?

That is what I have right now. All the blocks have "On Key Pressed W" or "On Key Pressed Up" simulate control Up (I have 8 way control on the player). But diagonal doesn't work. I made sure that 8-directional is enabled in the behavior too.

As for the addition and subtraction I slightly edited that. Instead of using "Add" and "Subtract". I just use "Set" so I don't have to worry about the player pressing both button options at the same time.

Here is how it looks now:

This setup doesn't allow diagonal movement. If I tried to add a new block with a new number, it still doesn't work. I am guessing to allow diagonal movement I need either to use the default controls + unchanged 8-way behavior or mouse + WASD controls, right?

Well if you change something, some things change..

I had very specific reasons for using the adding and subtracting..

Not using it the way I set it up makes the setup unusable..

You'd just need events that don't contradict..

if you have an event

up is down

and an event

right is down

and an event

up is down 'and right' is down

all three events are true when both up and right are down..

So you'd need extra conditions to prevent them all from being true at the same time..

The example I made was made to simplify that process..

If you have the animations for that, it's possible..

If the character is made out of parts (animated with spriter for example) this would make the eventing easier..

It's all possible..

Seeing that you are new here, it might be better to start with something easier to code, but like I said, it's possible..

I guess if you just want blood you could spawn it on an imagepoint of a hitbox that detects the collision..

> Would be nice to know what "Doesn't work" means..

>

it doesn't create the blocks grid.

What does it do?

Do blocks get created?

How many?

Where?

Is the event sheet attached to the layout?

Are the blocks set to visible?

Is the animation speed set to 0?

Changing it to or blocks should work,

on up pressed

'or'

on W pressed

Problem is that than it would be possible to press both at the same time which would add the number twice..

So probably creating a new event "on W pressed" with an extra condition "keyboard 'up' is not down" and adding W is not down to the on 'up' pressed would be nescessary..

You mean something like this?

System create object at x = random(4,25) y = 200

As you can see X is inside a random range and Y is constant..

If you want to create the object after a certain time you could use a wait action in a triggered event or use timer behaviour for it..

I don't know about that, my game is still really slow.

If you want to check out the .capx see my forum post here: https://www.scirra.com/forum/viewtopic.php?f=180&t=167483&p=1009072#p1009072

You don't know about what?

Could it be the game is slow, because you have thousands of objects?

I can't open your capx, because it uses the third party plugin noisejs, which I don't have or need..

If you name the animations correctly it works..

For example there is no animation called "Down", it's called "Front"

Also Construct2 read events top to bottom, so if you want to use the "right" and animation for up-right and "down-right" you should put those events at the bottom or add conditions to the above event..

Setting the animation to play from current frame might be needed if you choose the first option..

The big difference between my example and what you do is I don't use "key is down", but "on key pressed" just adding and subtracting, so the diagonals are immediatly considered and that's why I don't need to add as many conditions..

>

> Ok..

> I'm sorry, but I don't understand why that would be important..

>

> But if you really, really have to, you could do it by using bullet behaviour for the movement and only use the pathfinding behaviour for the pathfinding..

>

> Like in this example:

>

> Pathfinding in circles

>

Ah, well - I guess there's no logical explanation to why I want it, other than wanting to make rotation and movement look seamless. Was hoping it was possible to constrain angles.

Like I said, it is possible, when using the bullet-behaviour for the movement..

Just setting the angle of movement of the bullet to round(bullet.movingangle/5) while moving should do it..