R0J0hound's Recent Forum Activity

  • You’ll probably have to restate the question. And no, just adding /2 isn’t what I was suggesting.

    What alexto suggested is elegant imo. It reduces all those events down to one event. And anything can be modified to meet other requirements you may have later. We generally reply with ideas that ideally you can then use or maybe modify to be useful for you.

    I don’t get the idea that formulas are your thing. I mean we all are at different levels. So here’s one last attempt.

    315 to 45 should be -22.5 to 22.5

    0 to 90 should be 22.5 to 67.5

    45 to 135 should be 67.5 to 112.5

    … and so on

    Notice the pattern? Where one range stops the next one starts so there is no overlap and no directions will seem to be skipped.

    I’ll leave it to you to find the other ranges but you can calculate them with:

    a-45/2 to a+45/2

    Alexto’s formula rounds an angle to the nearest 45 and combines it with an animation lookup. That’s super useful to simplify things.

    The meat of it is round(a/45)*45 which rounds to the nearest 45.

    And sure he wrote it for one animation type but it should be trivial to use the same idea for other animation types.

    Anyways, that’s should get you some ideas maybe. I don’t think I can give anything simpler that wouldn’t require a lot of extra work on my part.

  • If visuals help you could draw a circle cut into 8 slices like a pizza and measure angles of the edges.

    Otherwise I’ll just defer to suggestions of others.

    Again it looks like the angle ranges you’re using are overlapping each other which makes it seem like things are being skipped. You need to reduce the angle ranges so they don’t overlap.

  • Consider the first two ranges 315 to 45 and 0 to 90. They are overlapping by 45 degrees. And all of your ranges overlap similarly.

    Those should be 0-45/2 to 0+45/2 and 45-45/2 to 45+45/2 and so on. Notice the pattern? You could also use the condition angle is within 45/2 degrees of 0.

  • The angle ranges you’re checking are overlapping. That would explain the skipping. Probably making the angle ranges not overlap would fix it.

  • Hi, no worries. Glad some of what I wrote was helpful. I haven’t been able to look into this further. There’s no urgency to reply to forum posts.

    Forces with the physics behavior are off by 50 times. So unfortunately a calculated force will be off unless it’s adjusted.

    What I mean by those velocities is say you want to calculate the force to stop an object in motion in one second. The start velocity can be anything and you’d want the end velocity to be 0 in that equation.

    So the formula would simplify down to:

    Forcex = -mass*velocityX

    Forcey = -mass*velocityY

    Now to make the units correct you have calculate the mass yourself since the expression is off.

    It comes out to something like this as I recall with the physics behavior.

    Mass = area*density = (width/50)*(height/50)/1

  • That’s an easy fix. Move the is in viewport check above the pick random instance condition. That way it won’t pick an instance you already used.

  • If you aren’t concerned with where the ray is hit you could set the ray angle, then set the size to 1000,1, then do events like

    Ray: overlaps wall

    Wall: pick closest to Ray.x, Ray.y

    Beyond that I don’t know what to tell you. Try searching for an addon that does raycasting for you.

  • I mean either you’d need to move overlapping objects apart or you’d repeatedly try a new random location if an object overlaps anything else.

    Another idea would be to manually design some spacing of objects to use, and utilize some alternate arrangements for variety.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Well maybe something like: 

    Var a=0
Var r=0

Create sprite at 320,240
Set a to random(360)
Set r to (random(1)^3)*100
Sprite: set x to self.x+r*(cos(a)/4-sin(a))
Sprite: set y to self.y+r*(cos(a)/4+sin(a))/2

    The logic is we create a random point in a circle. Which would be a random angle from 0-360 and a random radius from 0-100. Ah just noticed you wanted an oval so I added the /4 in there to indicate the x radius is 1/4 the y radius. Then you convert that to isometric. In general it’s simpler to just do the math in top view then covert it after.

    Anyways, the main addition is we can modify the distribution of the random points to favor the center instead of more uniformly by doing: (random(1)^3)*100 instead of random(100). You can change the 3 to make the center be favored more or less. Just an idea. There are probably other ways to have random points favor a point but nothing super simple comes to mind.

    Another idea to have them clump toward the center while not overlapping could be to move them to the center and push away from each other if they overlap. But that may be more involved.

  • I’ll have to look at your examples later.

    Most of the complexity of my example is replicating what the physics behavior does for you but I just like doing stuff from scratch.

    You can combine the physics behavior with other behaviors but I tend to prefer doing other things than working around behavior conflicts.

    Anyways, your physics terminology is a bit off. Presumably you could just set the angular and linear velocity of the car depending on if it’s moving forward or backwards and depending on the wheel turn. But that’s not really physics

    If you want to control everything with forces you’d do it with friction per tire.

    Inertia isn’t a force. It’s basically a property that controls how resistant an object is to changing its velocity.

    Maybe you’re just after finding a force to change the velocity in a specific way?

    You could get that by solving this for the force. Note you’d split that into two formulas for x and y.

    Force = mass * acceleration

    Force*time=mass*(velocityEnd-velocityStart)

    I guess time would be a timestep dt. But maybe it’s better to do that instantly so you could solve for impulse instead:

    Impulse = mass*(velocityEnd-velocityStart)

  • Sure. Just make a thin sprite angled in the direction you want it to go. Then starting with it short make it longer till it collides with something. That’s basically it.

    All the rest is doing things to make it faster and more accurate.

  • Inertia means it tends to keep going in the direction its moving. With a car it turns due to the friction on the tires opposing sliding sideways.

    Put another way, if you just apply forces and torque to the center of mass of an object you end up with floaty motion much like BB-8 or a vehicle that is rolling on one big ball.

    You can model a car much better by simulating wheels. Aka you'd apply force from the back two wheels and then apply a friction force to any sideways motion on each of the four wheels.

    Mouse up/down to adjust gas/reverse, Left/right to steer, and click for handbrake.

    dropbox.com/scl/fi/g9p9bdi5etv39r7jwz4tw/car_physics.capx

    Probably can be improved in many ways. One that comes to mind is instead of directly applying acceleration to the back tires we could just apply wheel spin and rely on friction to accelerate. Beyond that weight transfer per tire, but that may be delving more into 3d stuff. It would probably benefit by making a distinction between static and kinetic friction.

    I ended up not using the physics behavior but the idea can be applied there too. Here are some useful formulas as well:

    velocity along angle:

    vel: vx*cos(a)+vy*sin(a)

    velocity on point:

    vx: body.velx-body.angularVelocity*(pos.y-body.y)

    vy: body.vely+body.angularVelocity*(pos.x-body.x)