This is what I am now using. I need to set the speed up to 10,000 just to get the fruit to move off the screen in under 2 seconds. I have pinned an object to my Game layout and set the paralax to 0,0 I can see it scrolling along with me. But the Fruit still try to go to 0,0 of the entire layout.

<img src="http://img21.imageshack.us/img21/6581/quhh.png" border="0" />

https://www.dropbox.com/s/fslf5xkj8b5iwr0/FruitMovement.capx

Unfortunately, I use an older version of Construct 2 so can't view your capx. I would suggest perhaps posting screenshots of the relevent code, rather than your entire game though. Unless you don't mind sharing your code of course.

Where is it that you want it to go exactly?

I haven't used custom movement myself. but once it reaches sprite.x, sprite.y, shouldn't you set the acceleration to zero?

You could do this by creating a new event to check when the object is at position sprite.x, sprite.y, or when the object has collided with the sprite object, then set acceleration to 0. Or disable the custom movement entirely.

GeometriX Okay, thanks for your help. I have implemented what you have shown me and I am getting the same result. I should have mentioned that I want the angle to update every frame.

You see if the player is running and collects something, the item will actually end up going off the screen lower than intended. The same goes for the player running the opposite direction. The collectable will end up going off the screen somewhere near the top/middle of the screen.

I am think I need create an Every Frame event, but I am not sure about how to go about this. I will play around with it in the mean time.

Thank You,

Stephen

Could you not create the object on a layer with its Parallax X and Y set to 0? That way the object's position would be independent of your movement layer. If you have a HUD layer, you could just move the object to that layer with Move to Layer, and you'd only have to calculate the angle once.

Seems a bit more economical than constantly readjusting the angle.

This should give you a good starting point;

scirra.com/forum/how-do-i-make-earth-rotate-around-the-sun_topic45633.html

Then every time the object makes a full orbit, or x amount of time has passed, slowly decrease the distance until it collides with the object.

I think you'd need to use delta timing to decrease the orbit, but if you store that rate in a variable, you'd also be able to increase the rate the object gets sucked in the closer it gets to the object it's orbiting. Which would make for a much better gravity effect.

You could create a circle "gravity field" object and turn off its visibility, and use that to detect when an object has fallen into the object's gravity well. I think you'd need to pin the gravity field to the object you want to have gravity, and then resize it based on the mass of the object.

Once your object collides with the gravity field, that's where you'd start the orbit away from the centre of your larger object, so you'll need to calculate the distance between the small object, and the centre of the larger object, and make that the point that the object starts orbiting.

Hope that gives you some general direction.

Nullus The INCLUDE FIXED IT!! I had include in the wrong place! Thank you thank you thank you Nullus!

Don't mention it. Sometimes you just need a fresh perspective to make you spot the problem. I don't know how many times I've completely overlooked something simple that I didn't even consider could be the problem.

Awwww man I really want to have my player switch between layouts but when i switch it shows my player in the sky but my mask falls to the ground. I have them on Global and they wont stay pinned together when switching.

Behaviours should remain if the player object is global. Events, though, are Event Sheet dependent. If you're handling player events in one layout, then moving to another layout without those events, then they won't apply.

Remember that "Pin to object" is a behaviour, so if your new layout doesn't have that behaviour, you'll lose the pin.

It may be a good idea to have all of your main player events on a single event sheet, then "include" that event sheet in the event sheet for every level. That way you don't have to re-write your player events, and can use them on every layout.

Or you could just copy the Pin event across each event sheet that you need the Pin behaviour for.

Nullus, agreed. I forgot to mention how I handle event sheets. I create a single, all-encompassing event sheet that contains basically anything that's likely to happen more than once across my levels. This includes player controls, UI, enemy interactions and debugging.

I then create an event sheet per level to handle that particular level's parameters (enemy spawn rate, enemy types, total number of waves, etc.) which are passed on to the main event sheet. Each level event sheet includes the main event sheet.

I also put all my global variable in their own event sheet, just to keep things neat.

I agree that this is a good apprach to handling larger games.

Would you mind elaborating a little further on this point, though? I'm interested in what you meant by;

which are passed on to the main event sheet.

With my current project, I'm planning to take the approach of using spawn points, storing spawning behaviour via instance variables, and then using each individual level's event sheet to change those instance variables after the first wave, up until the final wave.

I'm a stickler for efficiency, so any advice on the best way to take advantage of multiple event sheets is of great help.

I'm perhaps not the best person to answer your questions in-depth, but in regards to question 2;

One way would be to keep all your player stats as instance variables for your player, but also store each variable as a global variable in an event sheet (global variables are accessible across all event sheets). Just before you move to the next layout, set all of your global player stats to your player's current instance variables.

Then, on the start of the new layout, you spawn your player object, then set your player's instance variables to the values you saved in the global variables after exiting the previous layout.

I think it depends on the type of game you're creating as to whether or not you think having a main event sheet is going to cause clutter. This is where creating groups becomes very useful; gets rid of all that clutter by grouping together related events.

I think you may be getting layers a bit confused there, though. You don't need a layer for every level. Layers are for seperating types of objects on your layouts; sprites on one layer, background on another, text on another, etc. You wouldn't store seperate game levels on them. That's what layouts are for.

You can have multiple layouts share a single event sheet, or each have its own event sheet, or each have its own event sheet, and include other event sheets.

You can set each layout to a single event sheet if you want, or have every layout have its own event sheet.

A better way to do it, personally, would be to store all your main game events in a single event sheet, but then have a seperate event sheet for each level to do all the things that are going to change per level. To include your "main" event sheet in every layout, you can use "Include event sheet" in each level event sheet.

scirra.com/manual/121/event-sheets

If, however, all that's going to change each level is where you place your objects, then there's no reason that you couldn't do it all via a single event sheet.

I, personally, would start with one event sheet, until my project got large enough that I could see that there were some events that rarely or never changed (these would become part of my main event sheet), and other events that were being repeated, or changed for each level. These would become my event sheets for each new level.

If you're finding yourself changing the same variables over and over again each level, then that'd be a good reason to have one main event sheet, seperate event sheets for every level (aka layout), and include your main event sheet on every level event sheet.

why do you have that second line in everything

and why not set it to default controls and delete all that stuff

The default controls move the player up/down/left/right in absolute terms. I want to move the player relative to which direction the player is facing.

So if the player is facing left, then "up" will move the player left. That's what the second line is for. It binds the keys to all the angles relative to whatever direction the player is facing.

I've looked around the forums and tutorials, and can't seem to find anything on this. I've also been digging through Construct 2's various control methods, and can't seem to find anything there, either.

It may not be possible, but I want to be able to bind the up/down/left/right arrow keys relative to the player's angle, which is determed by the mouse. I want to use 8Direction style movement, and also ignore mouse input when the up/down/left/right key is still being pressed.

My current thinking is;

<img src="http://s16.postimg.org/rezwjjx51/Player_Movement.png" border="0" />

Which kind of works, although the main issues are;

1: I want it to ignore or delay mouse input when a key is pressed (Think I can figure this one out)

2: I want to be able to use 8Direction controls Max speed, Acceleration, and Deceleration, rather than a fixed speed.

Any ideas? <img src="smileys/smiley1.gif" border="0" align="middle" />

As a control method it's a bit work in progress. I'll probably end up altering it, or decide it's not really going to work. It'd probably be better off using left/right to rotate the player, and up/down to move backwards and forwards. Still, it doesn't do any harm to experiment with input.

Nullus

You can add multiple conditions to an event, so:

      Compare Two values: (Score % YourVariable) = 0

      Compare Two values: Health = 0

the conditions are in a "And" Block by default

are your conditions, and you add a action to that single event.

Ah. So the action isn't tied to just the one condition to the right of it? A block of conditions have to all be satified to perform the action?

Does it matter which condition the event is next to?

Edit: Ah. I understand now. They group together and are treated as a single larger event.

Thanks for clearing that up for me.

You can write your own Plugins, and there appear to be many community-made plugins available in the Plugins for Construct 2 forum section if you head on over and take a look.

May be worth having a browse there to see if it answers your question. <img src="smileys/smiley1.gif" border="0" align="middle" />