Psynaptik's Forum Posts

  • You may find this helpful when doing the conversation/dialogue:

    http://www.chatmapper.com/

    It exports in XML for import into other programs.

  • I'm using a Grayscale and Brightness effect on my layout.

    Trying to find the actual values in the inspector (rather than the values of text indicators I'm using to track it visually in game) during debug layout.

    Where are the layout effect values hidden? Can't seem to find them!

    Cheers!

  • You can do

    When sword collides with rock >> destroy rock.

    OR

    If player presses space + is facing correct direction + rock is overlapping at offset >> destroy rock.

    For multiple rocks, you have one rock but just have multiple instances. That will be 10 copies of the same rock, behaviours, logic and all.

  • Do they have to be separate objects?

    If I was doing this (based on the details you give above, I don't know the wider context of course), then I would change animations rather than destroy/respawn object.

    If Animation1 is playing + object clicked >> change to animation2

    If animation2 is playing + object clicked >> change to animation1.

    Glad to see you've started using C2. I was a former MMF2 user and I've found C2 to be fantastic personally.

    Let me know if that helps and answers your question.

  • If you've placed them manually in the level, won't they reappear where you placed them?

  • What mist said.

    Make sure you use the search bar in the top right when looking for conditions - it can save you a lot of time.

    e.g. in this example type in 'layout' and then you are only searching for ACTIONS (not conditions as you say above) that relate to layouts.

    What you will end up with is something like

    If player collides with exit > Then goto next layout.

    ...or whatever your 'win' condition is.

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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.