The solid behaviour has nothing to do with physics. It's to be twinned together with the 'platform' behaviour.

What you want to do for those things that you gave the solid behaviour to is give them the physics behaviour and then set the 'immovable' trait to yes. This means that it's solid and won't move. Other sprites (that are not immovable of course!) will then be able to interact with it as if it were/solid/a platform/an obstacle etc.

It's not advisable to have physics and platform behaviours in the same layout really - it leads to some unpredicatable and screwy behaviour. Decide which one is going to be better for your project (physics/platform) and then run with that.

Let me know if that answers your question.

Also, be aware that laptops can present a problem if you're using WebGL in any way on those layers. I had a game I made in C2 where the game ran really slowly at random points and I couldn't work out why.

Turns out that when the game was running slowly my laptop was running off the battery. When that happens, many laptops disable the 'higher level' graphics chips to save power. This is worth keeping in mind both for debugging and for when considering distribution.

Is there a way to get round that, now that I think about it?

If you are launching the ball from a tube or similar, it could be that the impulse force is bouncing off of the object it's launching from. In which case it would be an idea to move it a few pixels away so it has a 'clean' launch area before the impulse force. This shouldn't be too obvious due to the quick frame refresh.

With regards to the arrow - that's a different question to what you originally posted, it's worth a separate topic.

If you don't want to ball to fall, then set gravity to 0. Physics works without gravity as well i.e. as in space.

Simple, and effective!

You, sir are a legend! Thank you, that's exactly what I was looking for.

How do I change header to 'solved'?

Okay, so I actually managed to introduce randomness into the angle part of the equation so that each new orbit is created at a different angle.

So I'm not getting bunching up in the corners, but all my objects go in and out at the same time. i.e. all bodies fly over/under player object at the same time and out at the same time.

Is there any way to stagger the orbits of these objects so that they are all at different points in their orbits and don't all 'come in and out' at the same time?

Here are the equations I'm using:

x: (cos(time*300)*Self.x_motion)*cos(Self.orbitAngle) - (sin(time*300)*Self.y_motion)*sin(Self.orbitAngle) + Player.X

Y: (sin(time*300)*Self.y_motion)*cos(Self.orbitAngle) + (cos(time*300)*Self.x_motion)*sin(Self.orbitAngle) + Player.Y

x_motion, y_motion and orbitAngle are set to a random number within a range when collided with by the player before it starts orbiting around them - meaning that each has a slightly different ellipse and angle of orbit. :-)

The 'self' is the object doing the orbiting, in case that's not clear.

I hope that at least the above helps someone! But could someone else help me with the above?

Cheers.

I'm not sure that you can do this.

How could Construct2 possibly communicate via code with C#? There's no programming language in Construct2 (only Javascript if you're developing extentions to the main logic).

What code have you tried to modify? Your post isn't very clear. If you explain a little more what you need then someone (better than I) is more likely to help you.

Off the top of my head I would say that you'd want to include the tanks as a solid obstacle to be avoided (since that example uses the pathfinding behaviour). This means that paths could be redrawn each frame to avoid each other (since they are dynamic and changing position all the time).

I haven't got chance to try that now, and I'm not sure what the effect will be on your framerate. It sounds as though there might be a lot more calculations going on since you'll have to refresh the pathfinding each frame to take into account the dynamic nature of where friends and enemies are. You'll have to test it and see - it depends how many other objects are on screen, how many of them are using this kind of behaviour etc.

Would someone else be able to comment on this?

Also, please don't bump after a short time - in this case it was less than 2 hours. Whilst it IS very frustrating to be stuck on something (we've all been there, and go back there FREQUENTLY!), this is a small forum with only a small number of people who will be able to help you, so you'll have to wait. I would suggest at least 24 hours before bumping in future. Frequent bumping will only lead to people being more likely to ignore you.

In future, find another problem to work on whilst you're waiting for a reply on this one.

Hope that helps.

Hi there,

I've got multiple objects orbiting around my player in elliptical orbits, using info from the thread below.

scirra.com/forum/solvedtilted-ellipse-orbiting-movement_topic64560.html

To add variety, and so all those objects aren't tracing the same path and covering up each other, I've used random ranges for x, y and orbiting angle to vary the paths (by implementing them as instance variables). This has worked very well, but if I collect several of these objects in quick succession then they all tend to bunch up in corners together.

Is there a way of getting them to start in different places so that this doesn't happen? Failing that, how would I introduce a speed variable so that they spread out? At the moment the position is linked to time, and I'm not sure how to implement a constant speed variable.

Thanks.

cincipon - would you happen to be able to post a working example like you did before? That link leads to a file that has nothing to do with this question.

Is there anywhere on the web you could point me to where I could learn about more 'gamey' maths stuff like this? I know that I might be able to just copy and paste and fiddle to get it working, but I'd rather really understand the maths behind it!

Cheers.

Yeah, there have been a fair few people posting about this, and there doesn't seem to be much info available in the forums either.

Is the Kongregate plugin useful/working and if so where can we get info/support for using it?

Would you not be better off using the pathfinding object now that you've got obstacles that you want the player to navigate?

What's happening is that you're clicking a location the screen and just telling the player object to go there in a straight line. There is nothing in the logic to tell them to walk around the bed in your example.

What you want to do here is use the pathfinding object and set the blue rectangle as an obstacle. Then Construct will guide the player round it for you.

As it stands, you are clicking somewhere and the player moves towards that location. The bullet motion is blocked when it reaches the EDGE of your collision rectangle. However, when you click again the player's x/y is moved BEYOND the edges of that rectangle and can carry on moving. That's why you see that bug.

Hope that helps.

By the way, that place where the file came from is well dodgy - PLEASE PLEASE PLEASE use a Dropbox or Google Drive account or similar to post files in the future. I now have to go and spyware scan etc. my computer because it installed loads of crap (not cool!).

Could I ask how you're going to handle the conversations and the conversation trees?

This looks fantastic by the way - with the portability of Construct2 you should be able to get a lot of people playing this when you're done!