99Instances2Go's Forum Posts

  • On collision (sprite) with Particles creates a picklist containing That Sprite and That Particle.

    Any other following pick condition in the same event and in sub events will start to pick from that picklist (containing That Sprite and That Particle)

    Hence, that sprite that collides with Enemy1 is not present in that picklist (at this point the previous picklist).

    Whatever the outcome of the condtion (true or false) the actions have no object to run on.

    Conclusion: you have to start picking from scratch for the second condition.

    Conditions:

    On collision with Particles

    is GeiserOn

    Actions: whats needed to be done

    New condition (picking from scratch)

    On collision with Enemy1

    Actions: whats needed to done

    This ofcours leads to re-using the same actions and to more code. Get a long with that using a function.

    So.

    Event:

    On collision with Particles

    is GeiserOn

    Action: call function with parameters the UID of That one sprite and That particle

    New event (picking from scratch)

    On collision with Enemy1

    Action: call function with parameters the UID of That one sprite and That particle

    New event.

    On function

    Pick Sprite by UID ... do your thing

    Pick particle by UID ... do your thing.

  • I think event 10 should be 'on jump'. As a top level event, no sub.

    12 should be (no sub)

    Is on the floor

    Is moving

    or

    is on the floor

    compare two values ... abs(sprite.flatform.VectorX) .. > ... 1 (rather this)

    13 should be (again no sub)

    Is on platform

    compare two values ... abs(sprite.flatform.VectorX) .. <= ... 1 (rather this)

    Because jumping/falling/landing = moving

    Look a second at my example in here

  • I am not aware of an entry in the manual about this. I had to learn this the 'hard way'.

    You can read about this in the forum.

    https://www.google.be/search?q=scirra+p ... ly+created

    A lot of poeple have problems with this. But once you understand it, it means nothing.

    Since i had a hard time to learn this lesson, i understand that new users bump easy on this. So i kinda take every opportunity to shine my little light on this.

    The moment you have this 'newly created objects thing' under control, and from the moment you understand this manual page (https://www.scirra.com/manual/75/how-events-work), you understand everything about c2.

    Oh and, what i call a 'new root-event' is also called a 'top-level-event' on the forum. It just means an event that starts at a zero margin, no sub.

  • That last Capx works by accident. And here is why it works...

    First this. You can not read properties/values from a newly created object until the next new root-event. 'On create' is no more then a special function, so, it does not count as a new root-event.

    Since you cant not read its Solid flag at that point, the path does not know that is a solid. Therefor that newly created object is not added to the obstacle map. And the pathfinder sees trough it. A solution by accident, and only working under those specific circumstances.

    Just switch the solid to off before finding a path and back on during 'on path found'.

  • Suprised you dont like the 'pauze' caused by the 'wait'. Never use wait (until you have read the manual 105 times). (I almost read it once)

    Here is a capx (yours).

    https://www.dropbox.com/s/kkzhy6vnqhfj6 ... .capx?dl=0

  • Think you have to create them yourself.

    Can do with a grafics edior of you choice.

    Or with this nice creation from blackhornet

  • You can make a sprite global, you can give a sprite the Persist behavior.

    You can also make a layer global.

    Global sprites (and theire instance variables) or sprites on a global layer stay in memory when swapping layouts.

    Not sure how the Persist behavior actual works, memory wise. I guess that they stay in memory.

    All 3 are really nice features. Got to look em up in the manual, when you plan to change layouts, or take objects from one layout to another (like HUDS).

    Memory used by the variables is negligible though, compared to the memory use by the graphics. So, if you have to worry, worry about the amount of sprites (and theire animations) used (independed from if they are global are not). Althaugh, you can have a lot of sprites on screen, as long as you dont try to give them all a personal movement system.

  • Better post a link to the capx.

  • Global variables are ... well .. global.

  • Condition > Any 'prefiltering' pick condition

    condition > sprite > pick top/bottom

  • That is a problem with a 3th party plugin ?

  • The first 2 you can combine in 1... system > Is between Values.

    Or you can do it all in once by using logical operatiors in an expression. As you wrote yourself.

    Compare ... first value ...(a = 1 & b = 1)|c = 1.. second value ... =1

    But i am not a specialist in that.

  • Look for "Minimum framerate' in this document: https://www.scirra.com/tutorials/67/del ... dependence

    10-15 fps is a serious deviation from the 'acceptable fps that is smooth correctable by dt'.

    The best solution is to optimize the game.

    Setting the minimum framerate to 10 is a no, no.

    Collissions will not be dedected and all sorts of other culprits.

    You can make a timer based on the expression 'wallclocktime'.

    The maximum error will then be the timeresolution, beeing 1 * dt, but usualy 1/2 * dt.

    Dont use =, use > or <.

    But, altaught this timer will be reasonable right, still ....

    The BEST solution is to optimize the game, to keep dt between realistic boundarys.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads