99Instances2Go's Forum Posts

  • How is the circle moving ?

    Do you use 'is overlapping' ? Or 'on collison' ? A lil more info plz ? A picture mayby ? A capx ?

    You cant have to many instance for it to stop working.

  • An 'is falling' under a 'on collision' can not work = flawed logic. Because when the collision happens it cant be in a state of falling after the collision check.

    It works sometimes because of the animating colision polygones. Wich is a bad thing.

    Animating colision polygones in big steps can NOT handle Collisions, Solids, nor Physics.

    Use One conddition. the condiditon 'is overlapping at ofset' for this situation. Replacing the 'on condition' and the 'is falling'.

  • Easyest is to dissable the jump key. But then u have to set 'default controls' on 'no' in the behaviour. And simulate (thats an action in sprite > platform) all the keys. Ex. : When left key pressed > simulate left.

    For the jump you need a variable that you set to zero on start up. And set to 1 when player jumps.

    So logic for jump is this.

    In the same event: 2 conditions combined :

    Up key pressed

    variable = 0

    actions :

    simulate jump

    set variable to 1

  • I am a bit suprised that it works at all. Because, when the collision is happening it is done with falling.

    That logic is flawed.

    Did you check the collision polygones? Do they grow with the animation (and shrink) ? That would explain why it sometimes does work. Because the animation, when it goes from frame 2 to frame 1, schrinks the collsion polygones on the moment it dedected a collsion, therefor it goes falling again.

    A better way of dooing this is with ONLY a 'is overlapping at offset' with y = 15 pixels or so. Dunno how big your objects are.

    More about those collision polygones animating. Imagine an object 1 pixel above animation fram 0. All is fine. No solids stuck in eachother. Then it animaties (like poof, in big steps) to animation frame 2, and suddenly the solids are caught up in eachother. Got to watch that, dangerus, errating movements as result.

  • How you mean only one time ?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I made my 2 projects in jan. and febr. After that my time got limited again, and i dropped in a black hole. Whitout a running project i have 2 options, lose what i learnded, or learn by solving other peoples puzzles. I learned an awfull lot that way, past months. I help when it is a challenge for me (well i hope i help). So for me, the motivation is differend. But yeah, i got that feeling you have a lot. And i dont feel a 'dick'.

  • Use a family.

  • I dont get the logic.

    For a 'every X seconds' to work its needs to check its time kinda every tick.

    Lets say its must fire every 2 seconds. First tick it sets that time, next ticks its askinig the system "is it time yet". And when it reads 2 seconds, it will fire and reset the clock.

    You would do the same, keeping an eye on that watch.

    A function gets called. Then it runs one moment. The containing events and actions dont get called/checked/compared/activated again till the next call. So that 'every x seconds' aint gonna do one thing.

    If you need that timer, use a real timer. Outside the function. Thats a behaviour. Start a timer with a specifiek tag in layout start up. Use a 'on timer' condition. And bring in there that whole on locate function. No need to call it, it calls itself when it is time. The on failed path is then not needed to.

    If you want it to it to find a path 2 second after it has sight on the player. Then make the 'has LOS' a top event. And start the timer in there. Make the inverted to stop the timer.

    'on arrived' is not needed, because the timer will catch that.

  • Marked this for later for myself.

  • Yes Sir. MUCH easyer. Because they lay on a vertical shifted grid. The node-lanes are now predifined by that grid. As well as the nodes. Those are well organised, following strict rules too. There almost nothing random anymore.

  • Is this what we talk about ?

    https://drive.google.com/open?id=0B1SSu ... Wg3eVlrRFk

    (so much easyer if you provide that capx)

  • I understand the your problem (now). Still, it would be nice if you gave a dummy capx with just the problem. I am sure someone will work on it.

  • Same idea. Much better coded. Now the events effectively wait till the objects are created/destroyed.

    I know when i can pick a newly created object.

    I still have problems with conditions picking allready destroyed objects. Would ne nice if someone explained me the rules arround that.

    https://drive.google.com/open?id=0B1SSu ... jg2b0NXUW8

  • There must be a better solution. This has me caged.

    I just cant find the logic in it. I thougt, if you break a link in two, and the middlepoint is closer to another node then to the starting node or the end node, then its a link that can be forgotten. It works that way, but that is a serious iteration.

    I like what Pulsar has done, but as he says, it has a few little problems.