R0J0hound's Forum Posts

  • If you are utilizing a translator then it has made your question confusing.

    I can’t read the language in the picture so here is your events written with “white”, “grey” and “variable” instead of your language. 

    For each white
Trigger once
White overlaps grey
— white: destroy
— white: set variable to 1
— white overlaps grey
— — white: destroy

Every tick
White: variable=1
— white: destroy

    Instead of all that, wouldn’t this work to destroy white when it overlaps grey? 

    white: overlaps grey
— destroy white

    But maybe you’re trying to do something else. Also, I should point out that you probably never want to use “trigger once” in a loop.

  • You do not have permission to view this post

  • Can’t test but you can look at it in the debugger. If you position the sprite at instance 0 and set the instance variable n to 0 then it should be there.

  • When it’s under a sub-event you run into how newly created objects aren’t available for general picking till the end of the current event tree. Search the forum about “toplevel events” to find many explanations about it.

    Anyways what’s happening is the p sprites are created but aren’t pickable the first time the every tick is run. At that point there is likely 0 pickable instances so you get a nan.

    Quick fix? Don’t make the every tick a sub-event, and instead just add the variable compare condition to it.

  • Basically if two adjacent points of the path are at the same location then the formula will become 0/0 which equals NaN.

    So make sure the path has at least two points and there are no two adjacent points that are at the same location. That should prevent it.

    But say there are cases when the path has less than two points temporarily. You’d fix it by setting the sprite you’re dragging’s position after creating all the points or just don’t update the position if t is nan or if p.count<2.

  • As is the p(n).x expression doesn’t deal with picking at all.

    You could do an object type per path and duplicate the event. Or just have one type with all the paths where you’d pick the path you want and create p sprites on them. Or you could store the points in an array and do array lookups instead of accessing the nth instance.

    You could stick with one type and consider a range of iids for each path. That would require some logic to loop the indexes in the range.

    You could also break the formula apart to be longer and more verbose using variables. Then you could mark the p instances with a path id. You’d pick the instances with a certain id then use pick nth instance for the two points and set variables from each.

    Anyways just some ideas.

  • Try dragging from the first point away from the second. I'm not sure if that's the behavior you were after.

    Anyways here's what I posted about in example form. Most of it is just drawing and loading paths, but the last event is what limits the motion to the path. The path is defined by the p instances, and the position on the path is updated in two instance variables of the sprite object. There is also one action you can toggle to consider the path as looping or not.

    dropbox.com/scl/fi/hoj7vjcz24ufemt894uqd/drag_along_path2.capx

  • Assuming the path is a polyline and you can get the xy of all the points the you could just loop over all the pairs of points and find the closest xy on that line segment closest to the mouse, then use the closest of all of those.

    If ax,ay and bx,by are two points then the closest point to the mouse (mx,my) would be: 

    t=clamp(((mx-ax)*(bx-ax)+(my-ay)*(by-ay))/((bx-ax)^2+(by-ay)^2),0,1)
x=lerp(ax,bx,t)
y=lerp(ay,by,t)

    That’s the math part at least.

    So roughly you’d loop over each pair of points on the path, calculate and create an object on the closest point on that line segment to the mouse, and the pick the new object closest to the mouse and position the player there. The only drawback is you can jump to any point on the path.

    An improvement would be to keep track of what line segment the player is on and when you calculate t you can then check if it’s 0 or 1. If it is then you could also check the neighboring line segments for the closest points. You can do that repeatedly but doing it once per tick should be enough unless you’re using very curved paths with short distances between points.

    Anyways that’s the general idea. The path can be anything and come from anywhere but you’d need it to be a list of points that make up a polyline. You’d find the point on the current segment closest to the mouse, and if the point is on one of the ends of the segment you’d move to the next or previous pairs of points for the next iteration.

  • 1. Just fiddle with the settings. This is what anyone that posts a solution will do, but you can do it too. There’s probably a setting to randomize the x position a bit.

    2. Probably not possible to limit where the particles can go. It’s more like it launches the particles with some properties and you can’t interact with them at all after that. You could possibly clip the particles with blend modes though.

    The particle object won’t cover all use cases so it’s ok just to do it with sprites. Like create rain at a random x at the top of the screen. Move the rain down, and destroy them when hitting walls or if the go off the screen.

  • That’s not how picking with conditions works. Each condition will pick from what the previous ones pick.

    One way to go about it is this: 

    Sprite: pick by comparison sprite.iid>=7
Sprite: pick by comparison sprite.iid<=9
Sprite: frame=0
Compare: sprite.pickedCount=3
— add 3 to score

    But what I’d do in this case is give the sprite an instance variable for its row and set that on the layout. It would look more readable. 

    Sprite: row=0
Sprite: frame=0
Compare: sprite.pickedCount=3
— add 3 to score

    There are probably ways to simplify it further.

  • The platform behavior triggers on landed after the collision is resolved so you won’t know the speed. What you probably can do is save the y velocity to a variable every tick. And since the behaviors run before the event sheet the variable will be the y speed one frame behind. 

    Global number vy=0

Every tick
— set vy to player.platform.velocityY

Player: on landed
Compare: vy>100
— screen shake

  • Snapshot only saves what is drawn to the canvas. HTML elements are placed above the canvas and not drawn to it.

    This isn’t limited to construct. In general it looks like it’s not possible to just render html elements to a canvas but here’s a js library that does its own rendering from the html elements onto a canvas. However it says the result may not always look the same.

    html2canvas.hertzen.com

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You could look into listening to pointer events which apparently work for styluses.

    developer.mozilla.org/en-US/docs/Web/API/Pointer_events

    However I have an older stylus that just moves the mouse when close to the surface. Maybe it’s something you can configure with your stylus’s settings.

  • As an implementation detail 1 meter = 50 pixels in the physics behavior. We shouldn’t need to worry about that except the conversion was inconsistently applied to all the values when you get values. So often values are off by a factor of 50.

    64x64/50 =81.92

  • Construct maps touch and mouse coordinates from the screen into layout coordinates. If you transform the canvas those will be off. In concept you can get the mouse coordinate on the screw and transforming it by the inverse of the matrix and take that and map it to layout coordinates. But that’s more low level so you’d end up only being able to use touches and clicks and get coordinates with your own math. The devil is in the details though.

    My other thought is if dragging changes the distort you may run into the issue of it running away from you as you drag. Could be better to have the dragging done on something that doesn’t get distorted.

    Anyways just some thoughts.