R0J0hound's Recent Forum Activity

  • Sorry for the delay. May take a bit longer for me to open the example since I’m not on my computer.

    But my guess is what I wrote doesn’t make it completely clear what is a sub event and what isn’t.

    In the meantime here’s a slightly different idea. If the objects aren’t all the same type then put them in a family. The create another sprite marker, and make it invisible. 

    On click
— destroy marker

On click
For each family
— create marker at (family.x, family.y)

On click
For each family ordered by random(1)
Pick nth: marker instance loopindex
— family: set position to marker

    Anyways, just an idea. If you placed the marker sprites down over each object in the layout you wouldn’t need the first two events.

    I’ll make an example of both when I get a chance.

  • Ah, I know that issue well. Events don’t excel at dealing with two instances of the same type independently.

    Personally I like just having a single type, putting that into a family, and adding the instance variables to a family. That way you can use picking to get two separate instances and still access the variables for both.

    I’ve attempted to two family method but I ran into the same issue. Can’t access the instance variables in one of them.

    A third tool we have is sprite(2).x. That expression will give you the x of the sprite with iid=2 no matter what is picked, and it will work for any property.

    So for your example you probably could do a hybrid of iid and the second family idea. The instance variables would be added to family1, and the second family2 would have the same objects and would be used to utilize the overlapping conditions. Anyways to access the variables from a family2 instance you’d do family1(family2.iid).z.

    In theory something like this would then work. I’m going with the premise that family1.iid and family2.iid have the same value for the same object. 

    Every tick
— family1: add 300*dt to vz
— family1: add self.vz*dt to z
family1: z>0
— family1: set z to 0
— family1: set vz to 0

For each family1
Family1 is overlapping family2
For each family2
Compare family1.z<family1(family2.iid).z
Compare: family1.z > family1(family2.iid).z-family1(family2.iid).zheight
Compare: family1.z< family1(family2.iid).z+family1.zheight
— family1: set z to family1(family2.iid).z-family1(family2.iid).zheight
— family1: set vz to family1(family2.iid).vz

  • Here’s one idea. You can put all those sprites in a family to simplify the events. Basically you’d swap the positions of random pairs of the objects. 

    Var i=0
Var xtemp=0
Var ytemp=0

On button clicked
Repeat 10 times
— pick random family
— — set i to family.iid
— pick random family
— — set xtemp to family.x
— — set ytemp to family.y
— — family: set x to family(i).x
— — family: set y to family(i).y
— pick family instance number i
— — family: set x to xtemp
— — family: set y to ytemp

  • Sure, the physics is a position based dynamics simulation, so you just need to move the points.

    left is pressed

    — p: set x to self.x-100/60

    Just put that event towards the top of the event sheet. That would move it left at 100pixels per second at 60fps.

    But we can probably do better. Instead of moving all the points we could move the top ones more than the bottom ones, which would let it roll.

    Var ymin=0

    Var ymax=0

    For each p

    — set ymin to loopindex?min(ymin,p.y):p.y

    — set ymax to loopindex?max(ymax,p.y):p.y

    Left is pressed

    — p: set x to self.x-(self.y-ymax)/(ymin-ymax)*200/60

    That should move the top points more than the bottom ones. Might need to change the 200 if it doesn’t move it enough to roll.

  • I think it’s in notification settings under construct 3 updates. I have both turned off but hopefully the second unnamed one is that

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I guess you could give the bowl more mass or the balls less.

    If the balls are still leaking through then you are running into the limits of what that particular physics engine can do. Probably need to reduce speeds and make things move more gradually like changing the 10 to a smaller value. That or make things bigger. Those things and my precious suggestions in theory should help prevent objects from passing through each other.

    I think overall the physics engine was made to be general purpose and work pretty well. It is possible to break the simulation pretty easy though. When that happens you just have to dial things back I suppose.

    Reduce speeds, enlarge objects, make the masses more similar. Might be able to make it run better by increasing the iterations of the simulation. There’s an action for that. Not sure.

    The alternative is to scrap using the physics behavior and just devise a way to keep the balls from moving through walls with raycasts or something. The con of that is the rest of the physics would need to be done too. I don’t really think a hybrid approach would be any easier than from scratch.

  • Ah. Yeah I did link the wrong file. Fixed now.

    It uses the 8-direction movement and does the z axis movement with events. It toggles the solid behavior as needed and checks what blocks are above and below the player to handle z-axis collisions.

    Camera controls are completely independent of this. So I didn’t move it at all.

  • Depending on how deep you want to go you can get 3d collisions with a bunch of math.

    Using oosyrag's idea you can see if two boxes also overlap on the z axis with: 

    box1 is overlapping box2
box1.z>box2.z-box1.depth
box1.z<box2.z+box2.depth
-- do something

    Or if you want to find the next box below the first box: 

    box1 is overlapping box2
box2.z<box1.z+box2.depth
pick box2 with highest z
-- do something

    Pseudo logic of utilizing that could be: 

    move on z axis
if overlapping in 3d: move up
move on xy
if overlapping in 3d: move backwards

    More finesse is needed to make it smooth. To have wall sliding or some more robust collision response you'd need SDFs(signed distance fields) or SAT(separating axis theorem) or probably some simplification of those.

    Heightmaps are also a technique to do terrain. You just need either a function that gives a height for an xy position. That can be done either with some equation or sampling an array of values with interpolation or sampling from a noise function.

    After that it can get a lot more complex. In general a good practice is trying to to do collision detection and response in 2d first with just events or js. Most of the ideas do carry over. Overall it may be more involved than most want to deal with.

    Here's a possible example of being able to jump on and go under 3d blocks. There was more nuance than I anticipated, but maybe it's useful.

    uca805441632bdb76c0d9075a2bd.dl.dropboxusercontent.com/cd/0/get/Ch6_S9gpxG8eOTsJP1yibsRSUAjCxwSZA6Xar6X9bGx81ApKIzlWUmRfZLetkFAk0h1BZAYSztW13bfoT7xpMzaE-kgp5qzlOPWCl20uPy4g9AQqhAY18_oWUmdI55tSCuFMJvEolYT3RM_I9vJdKbfe/file

  • Here's one idea:

    Attach the bowl to an immovable physics object with a revolute joint.

    Then change the angular velocity to turn toward the angle you want.

    Details with some more explanations:

    uc1c55c57e5abc2244ef18613f33.dl.dropboxusercontent.com/cd/0/get/Ch_lzbnsNAl_oMvJ-A4sg2sLY2VyDpaVsJjG_Moqd8rRvU6EdQUlzEcqkagjmGsDe3pFcefVRzRNAU75vfkLdGo2Bw3gGxspotpxebZLLH6-t3dP0YBUG8lj6jGSY9WUi3CSGboPZozBaNC24Um_wUKJ/file

    In general think of setting angle or position of physics objects as the same thing as teleporting. In your example you set the angle directly so if you rotated the bowl object fast enough the balls could suddenly be on the other side of the walls of the bowl. The physics engine won't think the balls went though the walls.

    However when setting velocities the physics engine can do it's magic to avoid jumping through walls. Especially if the "bullet" setting is enabled which does continuous collision detection.

  • For physics to work best you'll want the motion of objects to only be handled by the physics behavior. Any other behavior will interfere. Also at no time use set position or angle. You can set angular/linear velocities, apply forces or impulses to move things.

    For something like a rotating box you'll need to do that with joints to put it together. Then with the "bullet" setting the balls will bounce off walls no matter how thin.

    uc47696de6c42a4dbe9eff0e74c9.dl.dropboxusercontent.com/cd/0/get/Ch_1xm0HvBBNKunZldKccY8IgweHDcTVxj_f7dt7wZR0dK8nXDpW_cPjQm3GV7CJW51lhXDNvmfhLvZhdgVZcEDjB6fKyBYUEIKxr4xKhcCFlCqZR-LvQtFyCzokKvtnrt1fDW5pvWYH0-pBL3jqd1vI/file

    Of course you still can overpower the joints at times, but usually it's stable.

  • Only use the physics behavior, and there’s a continuous collision detection check mark I think.

    Physics doesn’t work with other behaviors.

R0J0hound's avatar

R0J0hound

Member since 15 Jun, 2009

Twitter
R0J0hound has 155 followers

Connect with R0J0hound

buymeacoffee.com

Trophy Case

  • 15-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

28/44
How to earn trophies