newt's Forum Posts

  • The license isn't really for support, that part is free for everybody.

    The license is for when you make a profit from the use of the product.

    I can tell you what little extra support is needed is timely, and efficient.

    Keep in mind there are two people running this.

    edit: ninja'd....

  • Rojo's canvas plug would work nicely except for the webgl thing.

    Just draw a spline along the x axis, and give the control points random(-5,5) integers that you lerp out over time.

  • +1

  • I asked this question waaaay back when CC was first started, and the answer was a no. The problem is that once you get past a third point it tends to complicate things almost exponentially.

    I've been wondering why we didn't get a cosp. Could be that even that is a bit too much for the jscript.

  • No, but they will be, hence the phrase "the first taste is always free".

  • Actually the api is pretty straight forward. You should be able to do everything using the Ajax plug and Kyat's Cb hash plug.

    Obviously it would be somewhat awkward to make an example as you would have to expose the private key in the capx.

    I would suggest some experimentation. Set up a game on the site, gather the required info, and test away.

    If you have any questions they have a chat on GameJolt, and there's always the forum here.

  • Ah, ok I was expecting node(0) to be at sprite's xy at the time the find path was called.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Alright that makes sense. I adjusted the initial xy with an offset for half the cell size, and there was no turning.

    I would be a little worried about that node at 0,0 though.

    Thanks

  • There is no destination object. The path is self.x+64, and self.y.

    There is only one solid object on the map. The turning happens even if you remove the solid behavior from that object.

    I've added a loop to generate nodes. If you want to take a look at it again.

    Since the path at first has no object in its path the loop should only make two nodes, the start, and the end, however it seems to be setting the first node at 0,0 for some reason.

    No idea if that has anything to do with the turning.

  • Link to .capx file (required!):

    https://dl.dropbox.com/u/666516/rightTurnclydepathfinding.capx

    Steps to reproduce:

    1. Run preview

    Observed result:

    The green square will turn to its right slightly on the first movement

    Expected result:

    There are no obstacles within the path, and the ending xy should be within grid coords so the object shouldn't need to turn

    Browsers affected:

    Chrome: dunno

    Firefox: yes

    Internet Explorer: dunno, duncare

    Widows 7 & service pack: blah

    Construct 2 version:

    119

    Thanks

  • Whats wrong with using an array? All you do is check to see if the current x +1 is of the same type, if it is check current x +2, if it is then you have just one of the many types of match types. You then do stuff to the corresponding grid coords... current xy * tile size.

  • The Pathfinding behavior is great and all, but sometimes you don't need Astar.

    Sometimes all you need is the ability to make your own path.

    My suggestion is, would it be possible to add to the existing plug by adding an add node action?

    That way you could set up your own path(xy's) and get more versatility out of the existing plug.

    Plus it might be very useful to add to the Astar path once it was found. Say for example you didn't want the object to go to the exact coords at the end of the regular path, but some random position close to it. Very, very useful for multiple units.

  • Its pretty easy with a variable.

    He has the groups thing, haven't investigated it much tho.

    Note: you could do the same thing with Rex's move to plug.

    example

  • We don't have great access to per-pixel operations with html5.

    However it is possible to use an fx(webgl) to do that.

  • Yes iid is the sprite(index), so sprite(iid) is the picked sprite.

    sprite.uid is also the picked sprite, but it has no use unless you save the uid to a variable, because you can't possibly guarantee what its uid will be at runtime.

    The general rule of thumb is if you are not creating a bunch of new instances all the time, then use iid.

    If you are then use uid, and pick via variable, or uid, as in object.uid= object.variable... do stuff.