megatronx's Forum Posts

  • you just got to have solid disabled, and make up with events. Keep collisions enabled, and for the characters that are supose to not to pass the wall, set collision check on overlap, and the result of it should be for them to either stop, or reverse. And if it's a platform, for the period of which those characters are on the platform, set fixed Y.

    Ashley But I really want in the future for Solids ( as well as other behaviors ) to be expanded, cause "ways around" kill the momentum of development.

  • create a family of avoidables and set them to ignore?

    If it is applied to platform characters, as was said above, they will fall trough floor

  • Tough situation. You'd need to simulate all of that when player returns to the game, give a moment to process everything that happened ( which would be generated with event's when player returns to the game ) and show some sort of loading/processing bar. I suspect it will only last up to several seconds.

  • I second this feature request. Disabling all collisions for the sprite isn't an option if you for example have enemies (using platform behavior) you want to disable character collisions with but still want them to not fall through the ground. Or if you have certain solids you want to disable character collisions with but still want the enemies to not fall through.

    That's right.

  • Hi,

    I have this idea, to make included event sheets work like groups, so you can expand/collapse them for quick view of the event. And this is a better solution, then current opening in new tab ( thought it can be kept, letting the user to choose the way), because it will let user see and compare events on same events sheet. Even letting user edit those would be even more useful. This idea came to me in search of more organised workflow (if you'd want to read about it, it in the next paragraph).

    For a very long time, I've been always aiming to use as little events as possible, by using families. But there is always a breaking point for me, especially after short break, and even with notes, and documentations, I just get lost in what I did. So now, while being in bathroom ( as it is commonly the case ), I thought that I will be making event sheet per object, and possibly only making some general, family based events for most basic and common tasks, like State Machine. But all other stuff will be on dedicated sheets, even if that would mean that I'd have many events that could be made with one event group. I just think this will help me keep things simply organised [thought if you have any word on the performance impact, I'd like to know that]. But having that kind of ability to collapse/expand included event sheet, would be a step in to streamlining the workflow.

  • > Intel GPUs are really weak, I don't know if they will run anything well

    >

    Well, my i3-3110m could run Guild Wars 2 on medium settings, so I'd expect these chips to handle an average 2D game.

    My i5-4210U runs 2d perfectly, except for c2 games.

  • Please, really please, include native resolution change, so we can get better performance in full screen. Thanks

  • Will we ever see a happy ending to this? >.>

  • how about instead of overlapping with offset you start using dist (sprite1.x, sprite2.x, sprite1.y, sprite2.y) <32 -> destroy sprite1 ?

    problem with overlapping - imagine my object is a big ">" form like this one (sprite 1). And now imagine your second sprite is a dot "."

    if you check for overlapping with -32 x and y - they will never overlap and therefore your event will never fire, even though the dot is under 32 distance from <.

    Also you have to take in that origin point of your sprite is the point where you calculate your stuff from. not borders. sprite x,y = origin point. So using distance from sprite 1 to sprite 2 you get this:

    if ( dist (.x,.y,<.x,<.y) < 32)

    destroy <

    (it won't matter if left, right top or down, each will work. )

    math pls.

    In certain circumstances distance is of no good use, for example n isometric view. But otherwise it is very useful.

  • If you want same object, then you must use families. Create two: 1st, 2nd ( just for tests ), and do events like this : 1st overlapping at offset 2nd, destroy.

    Thing is... looking at the capx, this way you will destroy all, probably.

    Eventing in construct s really context dependent. Again, looking at capx it's hard to know what you're after. If in your game objects that are surrounding main objects are not the same, then what you're doing right now is, sorry to say, pointless. But if they are the same object, then you mist go deeper. So you must do conditions for two situations: one is that object s surrounding same object, but only at one offset, then use or ( and families ), but you must find a way to specify that if objet os surrounded from 4 sides, it is not being destroyed. Boo ( boolean ) var ( variable) might help in achieving this.

  • Select all 4 "is overlapping", click rmb, and select "or". And I think that should work.

  • *See reasons for making Construct 3.

    We're waiting, and we're very hopeful.

  • Construct 2 (or 3) needs to take care of this topic. Either by making it easy to use the current system or developing a more powerful one. Don't misunderstand, I have no intention to give more work to the Scirra Team, but I do believe that as an engine that gives the power of programming to people who can't write code, it must have a feature like this usable by the common developer.

    Yes, everything can be made accessible, fast and still versatile.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I just closes part of a little job today, and was warming myself up to continue my game. With improved performance on intel gpu it sounds like great news all around!

  • I have 4th gen i5 integrated gpu, so I'm looking forward to do some tests when stable nw will be released.