R0J0hound's Forum Posts

  • Physics joints will never be completely solid. You can increase the iterations to make the joints more solid though. There’s an action for that.

  • Another idea is to make the bouncing not quite realistic by moving and bouncing vertically and then horizontally. Hitting corners would probably just reverse the motion then. Typically when a ball hits a corner its motion angle can change considerably but it’s not something you really see happen in breakout clones.

  • They probably just add some y velocity when the y part of the velocity is near 0.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You can try increasing the iterations to try to help the solver not explode like that (there’s a physics action for that).

    Another thing you could try is a distance joint from the first link to the last to help it from not getting too long. This is a general box2d idea, not sure if that shakes out in construct.

    Another idea is since box2d resolves joints with changing the velocity you could try adding some damping on the chain link objects.

    Final thought as to why the chain explodes is when the physics object gets updated. The loop is basically behaviors->events->draw->next frame. Any changes to the physics objects happens at the behaviors step. So maybe the lurch is from the links being in different orientations when the joints are added.

    What I did once to correct that is to create the links, wait till next frame (after the behavior runs again), then add the joints. Or something like that.

  • The idea is

    Save scale, make unscaled, check for collision, then restore scale. I guess what makes it complicated is depending on if the mouse is overlapping or not you also what to change the scale. What i wrote was on possible solution.

    And yes that’s a division. There is no expression for an objects so that is a way to calculate it.

  • It’s fairly simple. “A is overlapping B” will pick any A’s and B’s that overlap. It’s not a loop, it will just pick the ones that overlap and passes on to the next condition. If you want to examine individual pairs you’d need two for eaches. 

    For each A
A overlaps B
For each B

    As to what the set position action is doing. It’s basically this with the picked instances. 

     for(i=0; i<A.length; i++)
 A[i].setPosition(B[i%B.length])

    Or in other words it moves the first A to the first B, second A to second B, and so on. If it runs out of B’s it just loops back to the first B again.

  • If the mouse plugin or the c3 scripting api doesn't provide access to the additional buttons then its simple enough to just hook the mouse events with straight js.

    In general you can add event listeners to the document (or canvas if you know a quick way of accessing it) for the mousedown, mouseup and mousemove events. In the events you can access clientX, clientY (which is the xy in canvas coordinants) and button (0 through 4). To make it usable i'd just have them call some c3 functions with those values. and there you can use the CanvasToLayer expressions to get the mouse position in layout coordinants.

    As an example here is the js to run at the start of the layout. 

    document.addEventListener("mousedown", (e) => {e.preventDefault(); runtime.callFunction("mousedown", e.clientX, e.clientY, e.button)};

    And here is what the events would look like: 

    var mx=0
var my=0
function mousedown(x,y,button)
-- set mx to CanvasToLayerX(x,y,0)
-- set my to CanvasToLayerY(x,y,0)
-- do whatever

    Do the same thing for mouseup and mousemove and that covers about everything. The only thing missing is a condition for "is mouse down". For that you'll have to just update some variables as the buttons are pressed and relased.

    In the js you see it call a function called preventDefault. That should stop those additional buttons from navigating away from the page in theory. It's what c3 already does to keep you from right clicking on a canvas to get a context menu.

  • You could just set the scale to 1 when checking for collision and back to scaled directly after. So the idea would be to save the current scale to a variable, set scale to 1, check for collision, then restore the scale. With some fiddling it should work with whatever system you have in place to adjust the scale.

    Every tick:

    — sprite: set savedscale to self.width/self.originalWidth

    — sprite: set scale to 1

    — sprite: set scaleMe to false

    Mouse: is over Sprite:

    — sprite: set scaleMe to true

    Every tick:

    — sprite: set scale to savedscale

    Sprite: scaleMe

    — sprite: lerp scale to 1.5

    Negated sprite: scaleMe

    — sprite: lerp scale to 1

  • I still think it would be helpful to look at the touch examples for working demonstration of use. Your screenshot shows one thing and you talk about different things. It’s probably a bug with your events, not a bug with the plugin.

    I will say that a Touch ID is different than getting the nth touch

  • Well nothing came to mind when I wrote that. I’ve already become unfamiliar with what my example did.

    Well the idea is simple. Find if a ball shaped player is overlapping the wedge shape. If it is move out in the closest direction. And since gravity and the motion directions aren’t parallel with the slopes sliding occurs which is semi realistic.

    There are likely many solutions. I mentioned the idea to push up maybe when on a slope, but it would require logic to not push up when moving from the sides.

    Possibly we could guess when you want to push up by looking at the z component of the normal.

    Another idea is to disable gravity when on the ground. Again you should be able to know that based on the z of the normal, or we could make the collision detection return what feature of the wedge we are pushing out of. Then when on the ground we could make the motion be parallel to the slope so no sliding would occur. It would require rotating the motion axis’ with the normal.

    Third idea is a vertical ray cast to find the ground level and just change the z to that.

    Anyways most of those would work best by scrapping my example and making a new one.

  • Maybe you could do the parallax manually. Just need two instance variables: startx and rate. Then you could do something like this: 

    Start of layout
— sprite: set startX to self.x-scrollx*self.rate

Every tick
— sprite: set x to self.startx+scrollx*self.rate

    Maybe tweak the start offset as needed.

  • Spritefonts are a good option.

  • It’s probably just a place to clean up any gpu resources that you created to use for that object. So looks like it’s mentioned if you create text to render. Probably would be a place to release textures you created too.

    construct.net/en/make-games/manuals/addon-sdk/reference/graphics-interfaces/iwebgltext

  • Personally I’d say just go for a simpler interaction with touch. 

    Var startX=0

On touch
— set startX to touch.x

Is touching
— rotate by startx-touch.x
— set startX to touch.x

    Which works great if you only have one touch at once.

    The touch id stuff is only useful when you are dealing with multiple touches. Each distinct touch will have its own unique id.

    Fastest way to get an example of how to use one of the bundled examples.

    But off the top of my head you’d get the id when the touch starts, then use the id to reference that touch, and finally unset the variable when that Touch ID releases. 

    Var myid=-1

On touch
Myid=-1
— set myid to touch.id

Touch: id myid is in touch
— do something

On touch released
Touch.id = myid
— set myid to -1

  • It would but you can keep that in mind when using tokenat. It’s just a complexity trade off.