Ah, that makes sense. I tested it and yep, it doesn't seem to be compatible :(

Oh well, I'll find another way.

Pode, this is a very useful plugin! Thank you. How well does this currently work with AppMobi's DirectCanvas? I am wondering if I can use this for my mobile application. If it doesn't yet work, how soon can we expect a DirectCanvas compatible release? Thanks!

Hmm, if that doesn't work, try using some physics equations! To get you started, observe that during your trajectory, your object's coordinates will change as follows (from physics equation for an object under constant acceleration i.e gravity):

y(time) = initialYSpeed * time + ( acceleration * time^2 ) / 2

x(time) = initialXSpeed * time

To show your trajectory, just run a loop for (time = 0) to (time = 10) or something similar, and create a circle at your calculated y and x, using loopindex as 'time' in those equations. Experiment until you get the result you are looking for. You'd be best off using small 'circles' that make up the path instead of wanting a continuous line. You can either destroy all the circles every tick, or use a set amount of circles and position them each time. I can try doing an implementation if that will help. But I'll only be able to get to it in a couple days.

sqiddster, you are completely right. I didn't read xeed's last post properly about being able to draw the line.

A little math will do it for you without behaviors or additional objects, in a way that's easier to tweak, and in a way that's overall much simpler. This would be the best method in my opinion. First, establish how far the enemy can see in front of him (SeeingDistance) and how big his field of view is (FieldOfView). Imagine a viewing cone.

Now, you just need to make a condition that tests these 3 things:

distance(Enemy.X,Enemy.Y,Player.X,Player.Y) <= Enemy.SeeingDistance

angle(Enemy.X,Enemy.Y,Player.X,Player.Y) <= Enemy.Angle + FieldOfView/2

angle(Enemy.X,Enemy.Y,Player.X,Player.Y) >= Enemy.Angle - FieldOfView/2

The distance will tell you whether or not the player is close enough to potentially be seen. The angle will give you the angle between the player and the enemy. You have to check whether the enemy is turned to that angle, but with a little leeway, given by the field of view. We add half the FieldOfView to either side of the angle to get a viewing cone centered around the direction the enemy is facing.

kalewind1 here's how to implement the example from your last post, which will give you ideas on how to accomplish the more complicated tasks you are after:

Step 1:

Add an instance boolean called 'ContainsKey' to your 'Tree' object and set the default value to 'false'.

Step 2:

Create an object called 'TreeSpawnPoint' and place several of them all around your level wherever you want a tree to potentially show up.

Step 3:

In your events, create a new condition "System: On Start Of Layout + System: Repeat x times + System: Pick a random 'TreeSpawnPoint' instance", where x is the number of trees you'd like. As the first action to this condition, create a tree at the point (TreeSpawnPoint.X,TreeSpawnPoint.Y). As the second action, destroy the TreeSpawnPoint. So now, when it repeats, it'll select from the remaining TreeSpawnPoints and a new tree will be created at a different area.

Step 4:

In your events, create a new condition "System: On Start of Layout + System: Pick a Random 'Tree' instance. As the action to this condition, "Set Tree.ContainsKey to true". So you picked one random tree out of all your trees and said that you want it to contain the key. Great.

Now you're all set. A 'random level' will be generated and a tree will be selected to place the key in. Now when your character destroys a tree, test to see whether that tree 'contained the key' by testing 'Tree.ContainsKey'. If it does, then create the key there.

I can create a .capx later (not now), but it might be better for you to just implement it yourself, so you can really grasp what you're doing.

Yes it's possible, and there are several different ways to go about doing this. Example:

Keyboard ('Down Arrow Pressed'): Add 500*dt to Sprite1.Y

Keyboard ('Up Arrow Pressed'): Add -500*dt to Sprite1.Y

Keyboard ('Left Arrow Pressed'): Add -500*dt to Sprite1.X

Keyboard ('Right Arrow Pressed'): Add 500*dt to Sprite1.X

Keyboard ('S Pressed'): Add 500*dt to Sprite2.Y

Keyboard ('W Pressed'): Add -500*dt to Sprite2.Y

Keyboard ('A Pressed'): Add -500*dt to Sprite2.X

Keyboard ('D Pressed'): Add 500*dt to Sprite2.X

There, Player 1 can control Sprite1 using the Up, Down, Left, Right arrow keys and Player 2 can control Sprite2 with WSAD.

How about using Developer Mode (updates plugins every time you preview)?

scirra.com/manual/15/sdk/page-1

You'll still have to modify the plugin outside of Construct 2, but you'll be able to use 'preview' without having to restart Construct 2.

Otherwise, you might want to just create a new 'Set' action for the plugin that modifies that property.

BUMP. I say it's a bug! Nothing works after the 'wait', not even for other objects. My first thought was that it was some quirk in picking objects, but I guess not.

On top of that, try making a sub-event under the 'or' block that's always true (like 'every tick') and then moving all your actions into that. Technically, shouldn't this logic be equivalent to how it was previously? Except it's not. The object goes back to it's normal size. Can't think of how it could be a logic error. Must be a bug.

A quick and simple alternative in case you're interested. Simply add two sine behaviors to the object you want to move in a circle. Make the two behaviors identical except make one vertical and one horizontal. Also, choose one of them and change the period offset to 1/4 the period. Done!

To tweak, you can change magnitude to change the radius of the circle, or make the magnitude negative to change the direction of movement. Just make sure when you change a parameter, change it on both sine behaviors. The two should be identical except for direction of movement and period offset.

Your last event is the culprit:

Sprite2: Set Angle Toward (Sprite.X, Sprite.Y)

Replace the action with:

Sprite2: Set Bullet angle of motion to angle(Sprite2.X,Sprite2.Y, Sprite.X, Sprite.Y)

How about a Tic Tac Toe game where you want to keep track of which square contains what symbol? One option is to have a variable for each square. You could have variables Top-Left, Top-Middle, Top-Right, Middle-Left, Middle-Middle, Middle-Right, Bottom-Left, Bottom-Middle, Bottom-Right. And then if the 'x' player clicks on the symbol called 'Top-Left' I could have an event that sets the variable Top-Left to 'x'. And then if the 'o' player clicks on the symbol called 'Top-Right', I could have an event to set the variable Top-Right to 'o'. Oh, and now I have to test to see if anyone got three in a row. So what are my possibilities?

If Top-Left, Top-Middle, Top-Right are all 'o',

If Top-Left, Top-Middle, Top-Right are all 'x',

etc.

What happens now if I want to make a simple change in logic, or even worse, make a 10x10 tic tac toe game. So many more possibilites, the events would be endless!

OR I can just use an array that is 10x10 and use math to calculate where the player places an 'o' or an 'x'. Let's say the player 'x' clicks position 3,5. And then all I have to say is set Array(3,5) to 'x'.

That's one possible use of it, out of INFINITELY many! The more game development you do, the more uses you'll see of structures such as arrays. Just wait... In fact, the whole JavaScript game engine that Construct runs on is guaranteed to be full of arrays and loops through those arrays, because it has to keep track of several objects and set common properties on all of them. We are lucky that Construct handles all that stuff for us, so that we only have to use arrays for more specific applications.