R0J0hound's Forum Posts

  • 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.

  • Had a look. Looks like that example just has a terrainheight function that gives the z height of any xy point on the terrain. They used a bunch of formulas to define the shape of the terrain. Cool but not necessarily the easiest to tweak. They could have sampled a greyscale image or used a noise function to define the shape as well.

    The idea could be used with wedges. Basically pick the wedges under an xy, and calculate the z with some math. The main issue is that method isn’t enough to deal with walls too. It’s mostly good for smooth terrain. So wall logic would be separate.

  • I’d have to look.

    I’d think raycasting in the z direction would give the z position on the slope without sliding. There are various ways to do that but projecting the xy position onto the equation for the plane of the top face of the slope is one idea. But youd have to do some checks to consider what direction you were moving into the wedge so you’d hit it from the side and such.

    Or actually we could take the push out direction in my example and if it’s mostly a change of z then do the z ray cast.

  • I’d say what you're doing is fine. You could also add semicolons to the front and back of the string to be able to have one replace work for all positions. Then you could remove the semicolons at the ends with mid() but usually I leave them there if I’m doing that sort of thing.

    Do bear in mind that if two or more tokens are the same then the replace will remove them all.

    A general solution could be to make your own tokenat that returns the index of a token. And then you can remove that with a left and right I imagine.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The method works by finding the closest point on the shape’s surface and pushing the object away from that. A side effect of that is wall sliding. Guess you don’t like how it’s slower moving up a slope because of that.

    There isn’t really a fix with this method. Maybe one of the other ideas floating around would help.

  • Instead of touch.x which grabs the coordinates from the bottom layer you can use touch.x("TouchInderface") to get it from the specific 2d layer.

    That should solve the touch coordinates issue I think.

  • Most of the ideas have limited times they can be used. Events aren’t flexible in all ways so I generally decide what I want to do with consideration of what you can do with events.

    Stuff like interfaces lose me. I mean I could look up what they do but they seem like just an abstraction like much of object oriented stuff that just adds complexity.

    The event system is basically a mix of multiple things. The picking system which is kind of like functional programming, and without that it’s structured programming like a limited c without pointers or structures. On the object oriented front we have plugins which act as objects and families which are more like genetics than inheritance. I guess behaviors and custom actions could considered a bit object oriented too.

    As a whole the event system doesn’t adhere to any specific paradigm or even map directly to JavaScript. It’s just a little of everything with many useful parts, arguably missing parts, and a few really awkward parts that require you to choose a different approach when doing some things.

    In the end we all have our preference on how we want to structure or abstract our code.

    Personally I want to use as few languages as possible so I use events and js only to add missing engine features when absolutely necessary. The engine as a whole has good coverage of features but like anything it has limits which require doing things a different way. I don’t make plugins or effects because I hate dealing with build systems, I don’t want to maintain such addons and deal with comparability across browsers and systems. The reason I use a program like construct is because I enjoy the fast edit->run cycle to iterate on stuff. My goal is to do stuff in the least amount of events possible while remaining readable so only add abstractions where it simplifies stuff and makes it readable.

    Cheers

  • You could set an instance variable to self.y and use “pick highest variable”.

    Or You could add a “for each ordered by sprite.y descending” with a stop loop action.

  • Yeah, the pick2 is for the reverse case.

    The pick alls aren’t needed but I added them to show that you need all the instances to be picked for this to work. Actually, it would work if the same instances were picked in both families too.

    This is what a normal filtering condition like this:

    Sprite1: width = sprite2.width

    Expands to roughly under the hood: 

    // Sprite1 and Sprite2 are lists of the current picked instances. 
for(let i=0; i<Sprite1.length; i++) 
if(Sprite1[i].width == Sprite2[i%Sprite2.length].width)
 Pick Sprite1[i]

    A normal filtering condition is stuff like compare width, compare x, pick by comparison, … etc. Static conditions such as is overlapping or pick nth instance do their own thing.

    Anyways the relevant bit is what instance of other types are used in the condition. In practice we tend to just filter the other types down to one instance before doing a condition like that but it can be useful when the instance counts are the same.

    Actions reference other instances in the same way and has more utility. Most useful is “sprite1: set position to sprite2” if sprite1.count=sprite2.count then each sprite2 will have a sprite1 on it. And if sprite1.count=2*sprite2.count then each sprite2 will have two sprite1 on it.

    And yep that’s how else works with picking. You’d have to use a for each to avoid that.

  • Here's an example that uses mesh distort to make any polygon. Events 4-5 are the relevant ones. It takes the points variable as a comma separated list of xy coordinates as input. It sets the mesh size to 2 x count/2, then loops over the top row, and loops backwards over the bottom row to set the points.

    construct.net/en/forum/construct-3/how-do-i-8/manipulate-mesh-points-175978

  • Here’s a rough way to do lift. Basically you find the velocity perpendicular to the wing with a dot product and apply a force from that to do lift. It’s modeled after a lift formula found on Wikipedia. You’d tune it by adjusting the lift variable. 

    Var vrel=0
Var lift = 0.01

Every tick
— set vrel to sprite.physics.velocityX*cos(sprite.angle +90) + sprite.physics.velocityY*sin(sprite.angle +90)
— sprite: apply force -sign(vrel)*lift*vrel*vrel at angle sprite.angle+90

    Drag can be done similarly but with sprite.angle instead of sprite.angle+90, and it would have its own drag variable to tune instead of lift.

    It can probably be modeled better by scaling the lift by the width of the wing and scaling the drag by the wings height. But that would require tuning the scaling variables more. It probably could give pretty convincing motion with a wing a tail and a prop to give thrust.

    There are probably many other improvements to make the model better

  • There’s a system action now to set the collision cell size. I don’t recall what release it was added.

  • You can indirectly do it with a distort mesh since that distorts the collision poly too.

    Say you have 64 point polygon you want to use, you’d take a sprite with a square collision poly and apply a 32x2 distort and position the points to the poly. It won’t necessarily look pretty so you’d have it invisible and attach the visual on top of that.

    So apart from distorts changing or adding collision poly points nothing is setup for modifying collision polys outside the editor.

    Maybe with JavaScript but you’d have to bypass the scripting api to get into the unsupported and undocumented innards that has a has the possibility of changing per release and breaking anything you do with it.