R0J0hound's Recent Forum Activity

  • You could change it to only add points to the array if the head is moving instead of every tick. Basically:

    Compare: distance(head.x,head.y,array.at(0,0), array.at(0,1)) > 0

    That would keep it from stacking on top of itself if it stopped. Possibly good enough.

  • You could also have the function return nothing and set some global variables instead that you’d use after calling the function. For example:

    Global number retx=0
    Global number rety=0
    
    Function rotate90(x,y)
    — set retx to -y
    — set rety to x
    
    Every 1 seconds
    — function: rotate90(sprite.platform.vectorX, sprite.platform.vectorY)
    — sprite: platform: set vectorX to retx
    — sprite: platform: set vectorY to rety

    You can do that with anything. Instead of returning a value you just save the result somewhere. Or if you want it to be more dynamic you could say, create an array, fill it with values and return the uid of the array. There are tradeoffs for readability and ease to use though.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Hi,

    No need to ever tag me. I don’t look at alerts and I skim over all the new posts when I visit the forum.

    I’m guessing you’re trying to do it by moving the head and having it leave a trail that everything else follows. One way to do it is add the head’s position to the front of an array, and just always position the body parts from an offset in the array. Finally you’d want a way to remove stuff off the back of the array when it gets too big.

    The main complexity here is the offset calculation. A simpler formula could be (self.iid+1)*30 to just have each part be 30 frames (or 0.5 seconds at 60fps) behind the part before it.

    (self.iid+1) gives 1,2,3,…etc
    (self.iid+1)*32 gives a distance of every 32 pixels: 32,64,…etc
    (self.iid+1)*32/100 if the head always has a speed of 100 this converts the distances to times
    (self.iid+1)*32/100*60 Finally this converts the times to frames. 

    So events would look like this

    Start of layout
    — array: set size to (0,2,1)
    — body: set offset to (self.iid+1)*32/100*60
    
    Every tick
    — array: push front head.x
    — array: set at (0,1) to head.y
    — body: set x to array.at(self.offset,0)
    — body: set y to array.at(self.offset,1)
    
    Array.width>6000
    — array: pop back

    You’d just move the head however you like. And at 60fps and the head moving at 100 pixels per second the body parts would be connected. There are likely many improvements to this idea but that’s the simple gist.

  • Without a layer you could draw them to a drawing canvas at 100 opacity and then make the canvas have opacity.

  • Probably add a “for each mover” condition to the top of that event.

  • The pin lag has to do with the order the pin behavior runs among the instances. As you’ve noticed moving the object types around in the project folder can change the order of things but I wouldn’t consider that a great solution.

    However if you wish to solve it that way you probably can come up with a strategy. I’m guessing the object types list is ordered alphabetically. I’d imagine folders just are expanded in place so that would allow changing the order in that way.

    The second part would be to find an order where the lag doesn’t happen in specific cases. Depending on the pin configuration you may or may not be able to solve the lag in this way though, or at the very least you’d only be able to solve lag in a specific chain of pins I imagine.

    Alternately I’d just do the pinning in another way besides the behavior so that you’d have more control of the order of things. That could be wackyToasters suggestion or just setting the position somehow.

  • It’s probably easier to just use smaller images and more compressed audio and just let construct handle the loading.

    Construct’s docs say it loads images layout by layout, and audio is loaded as it’s used.

    My guess is what the loader does automatically is load the layouts and events data (which is very small) then loads the image files and maybe audio files, and then when changing layouts the textures are loaded/unloaded from video memory from the images.

    Anyways I guess one strategy would be to make all the animations use tiny images and load bigger images yourself from the files folder (which isn’t automatically at all).

    Overall it seems tedious to side step construct’s loading to do your own. Maybe do some tests?

  • Things you can search for is “trail”, “scarf”, or “cloth”. To get some ideas I realize the forum search isn’t the best, but you can also utilize google to search for posts too.

    At a glance of looking at footage of that game the scarf just looks like it’s a trail left behind from the neck. With maybe some waviness from a sine wave based on how far along the scarf. Or something.

    I don’t have a lot more to add at this time.

  • I guess the basic logic would be this. With no easing.

    var startX=0
    
    on touch 0 start
    -- set startX to touch.xat(0)
    
    has touch 0
    -- sprite: set angle to touch.xat(0)-startX
    
    on touch end
    --sprite: set angle to 0

    A simple way to add easing is to set a target variable which the actual angle is lerped to. Here i used curAngle as one more layer over the sprite's angle to handle the jump from 0 to 360 in a graceful way.

    var startX=0
    var curAng=0
    var targetAng=0
    
    on touch 0 start
    -- set startX to touch.xat(0)
    
    has touch 0
    -- set targetAng to touch.xat(0)-startX
    
    on touch end
    --set targetAng to 0
    
    every tick
    -- set curAng to lerp(curAng, targetAng, exp(-20*dt))
    -- sprite: set angle to curAngle

    If you wanted to limit the rotation of the wheel you could just clamp() curAng.

    Now using lerp() in that way is ok for an ease out, but it will cause jumps if you change the target angle drastically.

    Lately I've found a lot of use for damped springs to do stuff like this. Here it uses the x motion of touch to drive the spring. The result is pretty smooth and even some overshoot when turning back to the rest position (although that can be tuned by changing the numbers in the spring event).

    dropbox.com/scl/fi/15r86pr9k1k6xvyjxul9y/steering_wheel_horz_touch.capx

    Also it's trivial to do the rotation based on how the touch drags around the wheel instead of just x. It's a bit more intuitive imo.

    dropbox.com/scl/fi/15r86pr9k1k6xvyjxul9y/steering_wheel_horz_touch.capx

  • You can check this by putting a sprite with z=0 next to the cube.

    The bottom of the cube has a z of 0 and the top will have a z of 100

  • move the knife to the bg layer

    edit:

    wait, you want it above the face but under the texture.

    Here's one way to do it.

    layer 1, Force_own_texture=true
    -- face, blend=destination_in
    -- bee_texture
    layer 0
    -- knife
    -- face
  • It doesn't provide any other info in the browser console about why it's invalid, or which json file is invalid?

    I did a quick skim comparing your json with the sdk example on github and nothing stands out as amiss. Btw if you put source code in code tags (Ctrl+\) it's a bit easier to read on the forum.

    If it doesn't provide any more info, then I'd try taking the example on the sdk, see if that loads, then try incrementally changing that into your effect to hopefully find the issue.