calebbennetts's Forum Posts

  • I've done you up a working version that doesn't use the bullet behaviour - no doubt there is still a better way to do this, but it seems to work pretty well. You can download from here

    I would go with a different method than the exact one you used, signaljacker, because the way you have it would make the zipline move different distances for different framerates.

    heyguy: I've had bullet problems like the one you're talking about before. I would turn the bullet's "set angle" setting to "no" and set the bullet angle of motion to 180.

  • I just use subevents. I think that's the easy way to go, unless you're running out of events.

    I think I figured out why so many people start new Construct 3 forums instead of searching for this one: they can't.

    "Construct" is far too common a word on these forums, so the search engine throws it out, and "3" is a single character, so that gets ignored, too.

  • But are you doing that every tick?

  • Okay, that is really good. What are the chances you'll make a full game from it?

  • I don't think you need an expert; just an extra pair of eyes (useful on any project). You can add an event to make the trees go at the right speed every tick:

    System: Every Tick

    tree: set angle -90

    tree: set bullet speed to speed

    I noticed another problem, though. If you move to the side long enough and get enough speed, you can have a wall of trees appear along the bottom of the screen.

  • So, you sent me on a quest to find "alien technology," I see some aliens, I shoot them down, I grab a piece of floating technology... and I won't spoil what it is, except to say that it doesn't let you through the black hole. This is one of the greatest games ever.

    Three suggestions:

    1-When the ship lands, the astronaut spawns directly above it. I had problems with getting in and out of the ship repeatedly by accident. Can you find a way to fix this, maybe disabling the controls after the astronaut spawns until the down key is released or another key is pressed?

    2-I would wrap the edges of the planets and space so you keep traveling infinitely.

    3-If you want to, you can make the planets persistent pretty easily. Just give your ship and every planet the "persist" behavior. If you went that route, you would also need to make sure your planet-spawning logic only runs the first time.

    Wonderful game, thanks for making it!

  • Animmaniac: Woah … My mind is blown. That WOULD be good for C3.

    Aphrodite: I agree, we need to test at lower framerates. I just meant I’m not sure how to force it low enough to test it.

    Here’s the spreadsheet I had up earlier, with newly-corrected numbers comparing the actual physics, the built-in behavior from C2, and my Platform Minus. It shows two important things:

    1. IF we could assume a constant framerate, Platform Minus would give less variation in jump height than the built-in behavior as the framerate is set lower and lower. This indicates, but doesn’t absolutely prove, that Platform Minus would improve consistency between machines.

    2. In both Platform Minus and the current behavior, velocity seems to lag behind position by one tick. This might mean position should technically calculate before velocity (so it’s using the previous tick’s velocity values), but I'm not 100% certain, and I also couldn’t say whether you would get enough extra accuracy to justify the change.

    Thanks for your support, everyone else who’s commented so far. Thanks for your help with the math, Aphrodite and Colludium, and especially, thanks, Ashley, for considering my idea.

    Also, would anybody mind if I saved a copy of this forum topic as it stands now? It might come in handy as project experience on a resume. Collaborating to solve a technical problem, providing data to support my claims…

  • Aphrodite: I’m not sure how to test it effectively with lower framerates, except 60 fps. I set minimum framerate to 60 and tested the program. With “null,” jump height is about 216.7, with “plus,” it’s around 211.4, and with “minus,” it’s around 222.1. I think we can consider my original suggestion (subtracting (1/2)*a*t^2) quite well out of the running, and the additive method gives a more accurate result than the built-in behavior, but to see how well it keeps accuracy with changing framerates, we would probably have to turn back to the spreadsheets.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Does it seem to be 90 degrees off from the mouse? Because I was thinking, what if you just went into the image editor for your selection indicator and rotated the entire image 90 degrees clockwise? Then it would be laying flat at zero degrees and point right at the mouse.

  • What I'm using for an upcoming project is the for each (ordered). I put each object that needs to be stacked in a container with its "shadow," which always stays at the floor level. Then I put these shadows in a family, let's call it "Stackers." Then, I use...

    System: For Each Stackers order by Stackers.Y ascending => Stackers: Move to top of layer

    and then move each object to above its shadow (e.g. move the player above the player shadow, move a wall on top of its footprint...)

    This might not work if you have more than one floor level. If you do have multiple floor levels, please tell me; I would like to find out how.

  • Ashley, Tom, and C2 are great!

  • I saw a request a while back for a way to draw collision polygons, like with a mouse or tablet, right over the editor window.

  • Colludium Thanks for your data. We definitely want to get as close to Newton as possible.

    However, neither my originally-proposed method nor the built-in calculation method is correct. We actually need to add (1/2)*g*t^2.

    I made a mistake in my calculations. Due to the discrete/continuous difference Ashley mentioned, I mismatched position and velocity by one tick. When I fixed the error, Platform Minus gave a worse error than the built-in Platform behavior.

    However, ADDING (1/2)*g*t^2 seemed to give a smaller error than the built-in calculations. I built a test program in Construct 2 that measures the unchanged, added, and subtracted jump heights.

    Thanks to Aphrodite for the max height equation, the actual maximum height for a 650 jump strength and 1000 gravity should be 211.25 pixels.

    The Platform behavior yields a 213.958 px jump height.

    Subtracting (1/2)*g*t^2 gives a less-accurate jump height: 216.667 px.

    But adding (1/2)*g*t^2 gives a jump height very close to the expected value: 211.285 px.

    You can find the test .capx here.

    To use it, go to debug and select the array. After you jump and land, the third array value will be your jump height. Press 0, 1, and 2 to toggle between the unchanged, subtracting, and adding calculation methods, respectively.

  • Wow, this is pretty cool! I've always thought collisions would be really difficult, but your explanation makes it sound easy (or at least possible), and in a variety of ways!