megatronx's Recent Forum Activity

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • > 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.

megatronx's avatar

megatronx

Member since 25 Sep, 2008

Twitter
megatronx has 1 followers

Connect with megatronx

Trophy Case

  • 16-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

23/44
How to earn trophies