R0J0hound's Forum Posts

  • LaroTaio

    fixed link

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Well I actually agree the way the behavior works is in want of a revamp. It should be made to not have this issue, and it is possible.

  • It's paraphrased from the Javascript source of the behavior which can be found in C:\program files\construct 2\exporters\html5\behaviors\8driection\runtime.js. Also how I described it working does cause what you're seeing. Lower speeds reduces it but doesn't stop it.

    Here is a post from the dev that says the same thing:

    Here is a rough visual example of how it works. When the wall is overlapped the sprite jumps to the last position when it was not overlapping, stops, and if the player is still pressing that arrow key will accelerate toward the wall again.

    Anyways that's why it happens. Making it better isn't exactly "no programming required" friendly from a user standpoint. It's irrelevant to me if it's considered a bug or limitation, but there's always the option of bringing it up as a bug report.

  • The 8direction behavior logic is basically:

    save previous position of sprite

    move sprite

    if sprite overlaps a solid then move sprite back to it's previous position and stop it

    The result is at higher speeds the sprite will stop short of the wall, which is the issue you're seeing.

    In cases where that isn't acceptable then one option is to remove the solid behavior from the walls and handle it yourself with events. Here's one possible solution that also allows for wall sliding as well:

    Or if you want something less deluxe you could do something as simple as:

    if sprite overlaps a wall?

    then repeatedly move backward until sprite no longer overlaps wall

    and stop sprite

    Or in events:

    +-----------------------+
    |sprite overlaps wall   |
    +-----------------------+
       +--------------------+
       |while               | sprite:  move -1 pixel at angle sprite.8Direction.MovingAngle
       |sprite overlaps wall|
       +--------------------+
       +--------------------+
       |                    | sprite: 8direction: stop
       +--------------------+[/code:12g1y7kb]
    The -1 means it moves a pixel at a time which makes the gap be less than 1.  You could use -0.1 to make the gap smaller, it just would loop more.
  • Here's you version tweaked to work:

    https://www.dropbox.com/s/68gwhdp68n5na ... .capx?dl=1

    And here's a few points of what had to change:

    1. Angles in js are in radians and in C2 angles are in degrees. All this means is you replace pi with 180 in all the formulas.

    2. Position information is being lost since x,y is being rotated and projected every frame. The solution for that is to store the original position in px,py,pz variables and set x,y,z from that. This is actually the biggest reason it didn't work.

    Other than that there were some things you could simplify but it wasn't crucial.

  • There are two expressions that you can use to calculate the position. You just provide the the same xy values you use is in a add vertex action. It's relative to the objects position in the layout but I don't seem to have provided position access to the event sheet which isn't great.

    There isn't a limit, the examples use well over 34 quads.

    In general I've stopped working on this. It was a fun expirement and hopefully it has its use as is to some.

  • bjayfont

    [quote:vzadujwl]So then I don't suppose there's any way to do collision with events then..?

    Yes, and no.

    Search google for "collision detection tutorial" to get ways to do the math and stuff. Not exactly simple. The drawback is it won't interact with C2's collision system, so unless you want to do all the movement behaviors with events too it may not be the best choice.

    The polygon plugin may be a workable solution, since it can interact with c2's collision system. Presumably you'd just need the positions of the corners of the quads to set the vertices of the polygon plugin. It's probably easier said than done.

    Anyways those are some ideas to try out if you'd like.

  • Persist is so the object stays the same when you go to another layout and come back later. You probably want to make the objects global so they don't get destroyed when the layout changes.

  • lennaert

    Effects being lost when pasting objects to it is a limitation of the canvas plugin. The paster plugin was then made to support webgl and pasting with effects. Unfortunately for your case the paster plugin doesn't let you access pixel data like the canvas. It is concivably possible to add such a feature the paster but I've no interest or motivation to do that.

    However if you don't mind some juggling you could take the paster.imageUrl expression and load that into the canvas object.

  • I think it's to be expected. A "wait" only saves the picked objects as far as I'm aware. Parameters aren't saved and I'm pretty sure local variables aren't either. One solution would be to right before the wait you create an object and save all the relevant info in it, then destroy it after the wait since we only need it saved temporarily.

  • Follder22

    link updated

  • Wouldn't this condition work?

    System->compare triangle.zorder < square.zorder

  • azurekame

    links updated