99Instances2Go's Forum Posts

  • As nickar said, it is not know how you exactly increase/decrease 'combo'.

    Even not with that weird explanation (to me) above. So lets (again) gamble.

    If Combo gets its value with some logic, then the spawning works as expected.

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

    You can drag the green one to alter the overlap condition.

    So, what i miss (besides a clear .capx) ?

  • Basically i think that Platform is more accurate. Bullet is way more accurate. Thanking the team very much.

    But .... Sprite.Platform.VectorX * dt is not. (or Sprite.Bullet.Speed, for that matter)

    Adding (Sprite.Platform.VectorX * dt) to itself, (basic stuff) will still accumulate the little errors into big errors.

    Adding (Sprite.Platform.VectorX / fps) to itself, seems more reliable.

    So, overall, it feels like, under the hood it is possible. For the engine, yes. For the user, no.

    I conclude (with my average dumb brain) that the same accuracy must be possible (without breaking current dt) in an expression like :

    (System) PixelsPerSecondToPixelsPerPixel(n) .... And the inverse for feeding values to the behaviours. With the same trick as done for the jump height.

    (hell of a name, i know,sorry for that)

  • If you say so.

    Yet.

    The platform behaviour is more accurate, and is made more accurate to be able to predict its movements with a high precision. So far i am very happy with the change.

    But, now, if i want to predict platform movement, i need the tools that are as accurate, and that has everything to do with a conversion from pixels/sec to pixels/tick. Because the velocity's are in pixels/second units and a typical 'every tick event' is in pixels/tick units.

    You can open/inspect the .c3p that i posted here.

    And tell me if we can predict the velocity's with a higher precision now. I feel it is not the case. But hey, i have been wrong before, and will be tomorrow again. And i can keep using the (slower fluctuating) fps.

    I would just like a reliable ,fast, under the skin, conversion without the random fluctuations, expressions would be something i can use, and (more important) something i can explain easy.

    But if none is up to it. Well, drop it. All fine by me.

  • Excerpt :

    With the new mode, jump heights are calculated with very high precision, even when delta-time has some random variations.

    Dt is not reliable, you (seem) to know this.

  • I have read your blog.

    https://www.scirra.com/blog/203/some-bo ... onstruct-3

    Sounds to me that there is now a better conversion between pixels/tick and pixels/second. Why not make that public available?

    Can i please have a System expression that makes a accurate conversion from pixels/tick to pixels/second.

    And.

    Can i please have a System expression that makes a accurate conversion from pixels/second to pixels/tick.

    Ty.

  • Need to pick the spawning sprite.

    Use the System condition > Is between values, to compare.

  • That is correct, so this way it animates, by setting a tile each tick for a region.

  • 3dski

    I was reading your first post. I noticed things like :

    "having to repeat the same initial object selection for every single item"

    "spawned copy at the target"

    "spawned copy at the target"

    So, i made this, up to you if you read it.

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Make 2 events from event 7. One for 'on start layout', one 'for every tick'.

    Move the 'on start layout' way up.

    Now just make a new event containing a system > For each (Ball) condition.

    Drag all events (except the 'on start layout) as a sub under that new 'For each' event.

  • Plz, set a default protocol handler (if possible) for .c3p.

    Ty

  • Dont understand situation.

    I suppose 'velocity' is the amount pixels/tick that you move the sprite.

    'velocity' can be positive or negative (event 3 & 4).

    There is no Y position changed, so i suppose the sprite move only horizontal.

    The sprite can approach the tile from the left and from the right. (neg and pos velocity)

    We look in the future (x+velocity) and when sprite overlaps a tile, it gets positioned just outside the tile.

    Then its velocity is mirrored. So far the basics. As far as i understand them.

    When the sprite is approaching from the right (negative velocity) it gets positioned outside the tile on the right side of the tile.

    But. When the sprite is approaching from the left, it gets ALSO positioned outside the tile on the right side of the tile (tile index * 32 PLUS 16). Now it is flying trough the tile. The positive velocity is set to negative, as a result it returns (starts moving to the left) inside the tile (AGAIN) the next tick. And is indeed locked up.

    I think it should be (again if i understand it right, i dont see the layout, so sorry if i am again wrong)

    For each Sprite

    ______________ Set sprite to the future

    ___ Sub event :The tile check condition

    ____________Sub event : velocity > 0 <--- means it is approaching coming from the left.

    ___________________action: set outside tile .. = (tile index * 32) - 16 <------ on the left side

    ___________________action: make velocity positive

    ____________Sub: Else <--- means it is approaching coming from the right.

    ___________________action: set outside tile .. = (tile index * 32) + 16 <------ on the right side

    ___________________action: make velocity negative

  • I guess i could be possible to ....

    ...1/ ... save a Family as a Family Template (without the objects).

    ...2/ ... make it possible to copy/past Family's as a Template (so, without the objects) between layouts/projects.

    This way you could store anything and everything that is attached to a Family (instance variables, effects, behaviours) .... And recall it later in any project/layout .. even share it with any and everyone.

    All you have to do then, to have a sorta kinda reusable behaviour bank, is add the objects.

    I know a empty family needs to be addressed then.

  • If the condition in event 2 is true for the first sprite, then it has to be untrue before it can run again due the 'trigger once while true'. As a consequence, when the condition is true for the second sprite(after it was true for the first one) it will not run.

    Why is the 'trigger once while true' needed ?