NN81's Forum Posts

  • It would look the only way I hoped for some automatic feature of the tool that could simplify the job

  • Thanks for the answer, I had already thought about something like that, is there no other way to do it?

  • Hi guys, my question is simple: is there a simple way to make solid walls "irregular" without having to use dozens of solid sprites rotated and resized? For example in this image, wanting to make these solid walls along the contour of the drawing, how could you do it?

    I hope you understand my need and as always I apologize for the bad English translation

  • why not.. Roboxtory??

    good TNT

  • I did a lot of things since the last post. So:

    - You can now push boxes around. That was something many People mentioned. But there are still a few bugs right now.

    - An also important Change is that the Robot now have a battery pack. Means that every secound the Player lose engery. And when the battery is empty you must load (you cant move).

    - There is now a Little lightning (look at the gif)

    - And there is a new trap: The Press

    Should i always make a to you NN81, mercuryus ??

    Hopefully you like the News

    Cryttexx

    good

  • In my ignorance what I do not understand is why you keep talking about "overlapping" when a sprite has "solid state" there is no overlapping but only a contact / collision with this.

    What else I do not understand is why all this complicated way to handle collision when XY coordinates of all sprites are well known to the tool, so it would be very easy to point out when the box has to stop on a sprite with "solid state".

    However my problem is those microscats because the graphics with my player's animations are bound to the box, so when this does "crazy collision" my Player suddenly changes animations from idle to walking, causing a very unpleasant effect in the game.

  • ok R0J0hound, im agree with what Aphrodite say in the link you shared.

    at this point I do not think it's a bug, it's just something badly designed and done worse. Thank you anyway for further clarification and deepening. At least I know now what I have to do. And still apologize for my English pessim translated with google.

  • 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

    It would seem to me the opposite, that when the box comes to the solid, it slows down and stops a bit earlier..

    However, I tried to decrease speed (if speed was the problem) and nothing was fixed

    Kindly, where did you find this information on the logic of "8 dir behavior"?

    Because I checked the manual and did not find anything so specific around.

    kindly, i would like to know if you have any other source or if I checked badly the manual...

    Anyway, thank you for your attention and helpful advice, Your reputation is undoubtedly well-deserved.

  • the problem in my game is strictly related to this collision issue, I have preferred to go to the source of the problem so that it does not give rise to misunderstanding or evasive reasoning about it.

    once it resolves this the rest I can fix it by myself ^^

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • > any help about this prob?

    >

    There is a verry simple solution. Open the collision box of the box. And subtract or add to every Point about 3. So the collision is a Little bit smaller than it should be.

    My friend is not as easy as it seems, the problem is not for a graphic aspect, in fact the player box puts it invisible to sketch the Player's graphics above. The problem is in the mechanical logic of the collision, because instead of detecting collision ON and stop, the tool detects collision ON, then OFF, then ON / OFF etc., you can see if you put an event that when the BOX collides with the wall adds 1 to a variable X. If you do it you will realize that when you go with the BOX against the wall the value of the variabe does not rise by one and then it stops but it also rises by 3/4 units if I hold down the key to send the box to the bottom

  • any help about this prob?

  • I do not know how you planed your events, but if you use sprite for the player, try reducing the collision polygons a bit, until the sprite perfectly snaps in the background.

    The question is simple, and has nothing to do with how I put 2 simple events, it is a perfect square sprite that collides with other perfectly square sprites and occasionally occurs the problem of the attached photo above.

    I think it's probably a bug of the tool on the collision management, but maybe someone knows a way to fix it..

    imhotep22 try the capx, no events.

    https://drive.google.com/open?id=0BwNG7 ... DhhemZGZWs

  • What exactly you want to do? Make the player touch the wall perfectly, or make the player stay a few pixel's away from the wall?

    i want a perfect always 100% guaranteed collision between the box and the wall edge.

  • Hi guys, I have a problem with the collision of a sprite used as a "player box".

    When I go to the walls, not always the collision is perfect. Most often stops at a few pixels from the edge, and just holding down the direction against the wall, or trying to detach me and go back to the wall, it resolves with a perfect collision. This is giving me so much trouble, is there a way to overcome the problem? I point out that the box is a perfect square with "bounding box" collision and NOT "polygon", and the walls too are perfectly square with the "solid" behavior activated.

    Every help would be highly appreciated

    this is a link to download a sample capx with the issue

    https://drive.google.com/open?id=0BwNG7 ... DhhemZGZWs

  • i like the style of this game ^^

    but hud objects imho are too big > <