R0J0hound's Recent Forum Activity

  • Found him. Must be on vacation?

  • Enums are just numbers under the hood but I can see the value of ensuring that only a certain set of values are used. You could use a function to set the values with events and do the checks there if you really wanted to.

    As for using array.asJson, if you look at the manual you can access the array object directly from JavaScript instead of having to pass the json back and forth.

    Personally the hoops needed to jump between programming languages is annoying enough that I try to avoid it completely. Events only in construct and if I want to use JavaScript I just don’t use construct at all.

    The exception is for performance. Same algorithm in events vs js can be x10 faster in js in some cases. So I’ve done that sometimes. I personally think there’s no reason events can’t be made to perform nigh as fast as JavaScript with some internals reworking. But I’d rather not worry about something I have no control over.

  • It’s mainly useful to interact with other js/ts libraries if you don’t want to deal with making a plugin. Although plugins/behaviors are simpler to use for end users and provide some deeper hooks into the engine.

    It’s also a nice advertisement point for Construct and attracts some users that don’t like visual coding or look at it as a way to dabble in coding along with events.

    JavaScript/typescript code can perform better than events for more algorithmic stuff but it really depends on what you’re doing.

    There are pros and cons of course. Cons off hand are you have to deal with more boiler plate code to interact with the api, debugging is more involved, and you’re kinda thrown out there dealing with how those languages work. Construct can only help so much with that.

    Overall events and typed code have their own workflows and it mostly comes down to personal preference. Pick your poison. They all have their annoyances when trying to implement some logic.

  • Forum is pretty inactive and probably few have suggestions. You can only say you’re being ignored if it’s someone’s job to answer questions I think.

    Anyways, the enemies stop moving since you’re only moving to the first node of the calculated path. You’ll probably want to have it move to each node one by one, and once the enemy is close enough to one node move to the next.

    As for the floaty movement you’d need to calculate different forces to do that. A force to a position generally is always floaty. Intuitively a force perpendicular to the velocity should help it turn faster.

    Or you may be able to throw some math at it to calculate the force required to change the current velocity to another one in one frame.

    Force = K*(TargetVelocity-currentVelocity)*mass*60

    Or split into xy components:

    Forcex=k*(targetvx-currentvx)*mass*60

    Forcey=k*(targetvx-currentvy)*mass*60

    Where k controls how rigid it works. 1 means the velocity changes in one frame, and 0.5 would make it a bit floatier.

    The target velocity would be something like:

    A=angle(enemy.x,enemy.y,node.x,node.y)

    Targetvx=speed*cos(a)

    Targetvy=speed*sin(a)

    You could also try limiting the velocity or force as well. In general you can limit xy values with:

    Mag=distance(0,0,x,y)

    If mag>limit

    — set x to x/mag*limit

    — set y to y/mag*limit

    Anyways, just some ideas.

  • You can incorporate time delta (dt). Basically rate*time=distance.

    Your growth rate is 1 pixel per 1/120th of a second or 1/1/120 which is 120.

    That would basically look like this in events: 

    midi: key is down
— 9patch: set height to self.height+120*dt

  • There’s a stickied topic somewhere with how to report bugs. I’ve never used it though.

    I still wonder if putting all the objects on the same layer that you want to glow and adding the effect to the layer would work. I’m becoming less familiar with construct by the day though so I probably won’t get around to testing it.

    I’ll defer to anyone else that has suggestions.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The effect likely needs to be fixed to not sample beyond the edges of the sprites. So if it’s an official bundled effect you can file a bug report for them to address.

    Again, it happens at export and not during preview because of spritesheeting.

    You possibly could work around it by adding a wider transparent border around the images the same as the glow radius. Or maybe adding the effect to a layer instead of individual sprites.

  • To fix you need to put a 1 pixel transparent edge around your images. In the image editor the crop button does that for you.

    Without that transparent edge the colors can get sampled from beyond the edge of the image and cause the edges you are seeing. You don’t see it when previewing because each image is a separate image and there is nothing beyond the edges. However, when exporting the images are spritesheeted together into a few bigger images so now other things can be just past the edges.

  • Getting the exact path isn’t as simple as you’d think. Objects are moved in steps with the timestep which can vary so when a collision is detected it will overlap by a varying amount. You can test that. Repeatedly launch a ball from the same spot to see the path. As long as the framerate is consistent the path will mostly be the same but the more dt varies the more the paths will deviate after a bounce.

    Anyways, maybe a close path would be good enough.

    One way to see the path of an object is to use a loop to simulate many frames at once. Basically use a clone object of the ball. Set the clone to the same position and velocity of the ball, then move the clone with a loop. The bounce logic can be involved if you do it yourself, but if you used the bullet behavior it would be simple. 

    Every tick
— clone: set position to ball
— clone: set vx to ball.vx
— clone: set vy to ball.vy

Repeat 60*3 times
— clone: set position to self.x+self.vx/60, self.y+self.vy*dt
— clone: overlaps wall
— — clone: bounce off wall

    Manually finding the collision normal for a bounce is more involved and a different question.

    Anyways, for the dashed line you only have the consider the positions where the ball bounces and stretch a tiledbg of the dashes between them (or maybe the drawing canvas lets you draw dashed lines)

    Another idea instead of using a loop to simulate motion in steps is to do a kind of shapecast (kind of like a ray cast but considering the shape of the object too). It’s an algorithm that would need to be implemented, but the result would be exact collision detection when the ball would just touch the wall. The con with that is it wouldn’t match how the ball actually moves, as mentioned in the first paragraph.

    Anyways, if very exact is required I’d also change how you move the ball. Basically, shapecast the ball to the walls to get an exact position and time of collision. Calculate the normal and reflect the velocity along that. Then repeatedly shapecast again. You’ll end up with a polyline path. Then it becomes just a matter of moving along a path which you can do exactly.

    But again, you probably want a simpler solution that’s good enough. The quoted pseudo code above is probably the simplest. Especially if you utilize the bullet behavior’s bounce action. However you will need to change from velocity from vx,vy to speed and angle of motion.

    Anyways, just some thoughts.

  • Or if you want to use just one loop. 

    Start of layout
Repeat layoutWidth*layoutHeight/16/16
— create sprite at 8+loopindex%(layoutWidth/16)*16, 8+int(loopindex/(layoutWidth/16))*16

  • Instead just setting the position you’ll want to do it in steps.

    One idea is to take the angle from the object to the touch position, and then simulate a control if it’s close to that angle. For example: 

    Angle angle(object.x,object.y,touch.x,touch.y) is within 45 degrees of 0
— object: tileMovement: simulate control right

    You’d just do that for 0, 90, 180 and 270 degrees. And you’d depend on the solid behavior to keep from moving over other things.

    Another very visual way to do it is to use some sprites to use as detectors, and position them one grid space in all four directions around the object as well as on the object itself. Then you’d just pick the closest object around the player that wasn’t overlapping something to move to. 

    global uid=-1
On object touch
— set uid to object.uid

Pick object by uid uid
— det: destroy
— create det at object.x, object.y
— create det at object.x+32, object.y
— create det at object.x-32, object.y
— create det at object.x, object.y+32
— create det at object.x, object.y-32

Det overlaps wall
— det: destroy

[inverted] pick object by uid uid
Det overlaps object
— det: destroy

Pick object by uid uid
Det: pick closest to touch.x, touch.y
— object: set position to det.x, det.y

    Just some ideas.

  • What problems? You forgot to specify what they were. I have some down time to guess though, but I may or may not be around to reply again.

    Last I checked the drawing canvas object doesn’t store depth, it only stores color. So pasting 3d objects results in the 3d faces drawn in an arbitrary order instead of sorted with a z buffer.

    If you mean pasting stuff onto a distorted drawing canvas. I think that never worked, or worked as if the canvas wasn’t distorted. But maybe things have changed with newer updates.