Non-solid attribute

This forum is currently in read-only mode.
0 favourites
  • So what I'd basically want is a non-solid attribute. What would it do? Basically it means that if you have an object that has the solid attribute and then put another object on top of it with a non-solid attribute, you can then move within the object with the non-solid attribute. This would basically allow destructible environment without the usage of Canvas object, making destructible environment much more feasible for large layouts.

  • Um, I think unticking the "Solid" attribute achieves exactly what you've described. Any objects that aren't "Solid" will be ignored for purpose of collision check.

  • It doesn't - that's the whole point. If you place an object that doesn't have a solid attribute on top of an object with a solid attribute, the solid attribute still applies at the parts where the objects overlap. With this kind non-solid attribute I'm describing, it'd mean that the solid attribute of the object underneath wouldn't be in effect as long as the player is overlapping the object with the non-solid attribute.

    So for example, if you'd create a player sprite and put a "force field" around him that doesn't have a solid attribute, you'd still be stopped by objects with solid attribute. If you put this kind of non-solid attribute to this "force field", it'd mean no solid object would stop the player, as the solidity is getting cancelled by the non-solid "force field" around the player.

  • Why not just set the sprites collision mode to none whenever the forcefield is active? You will still be going through solid objects, just that instead of making them non-solid you will instead turn off collisions. That way you wont need a "forcefield" object around the player.

  • So, you're talking about... like "un-solid" or "anti-solid" mask. If the force field overlaps a solid block partially, say, it overlaps the upper part, but not the lower part, only the lower part would act as solid, since the anti-solidness would cancel the solidness of upper part of a block.

    So, it would would work like mask - but it would mask the collision mask, not graphics. And it would indeed be useful for destroyable terrain, or let's say that you have a solid object "mountain" and then you place antisolid "tunnel" on it, and the antisolidness masks off the solidness of the mountain - and you can move in the tunnel, but not elsewhere in the mountain.

    I think it's a really useful feature to have, but the problem is, how easy it is to implement technically. I think the devs could say something about that :)

  • Drasa, exactly.

    Scidave, I'm not specifically trying to achieve the kind of "force field" I described, I just thought of a random example that wasn't "destructible terrain".

  • Daiz, ok that makes sense. Drasa's mountain example was helpful in explaining how it would work. I could see this being a useful feature as well. I still think there is a work around with setting the player's sprite collision mode to none based on its position to other objects, but it would be potentially tedious... and Construct is about easy ways to do things. We will have to see what the devs think.

  • Cool idea, but there is already a good destructible terrain model available in my Tonks demo.

    If you want the terrain cap file to see how it works I'll be more than happy to upload it

    This idea would certainly make "tunnels" easier though... I'm actually kind of struggling with idea's as to how this would work with my current terrain model.

    ~Sol

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • if you make your own custom movement

    you can use a workaround for now

    if 'object overlaps solid object'

    (negated) 'overlaps nonsolid object'

  • if 'object overlaps solid object'

    (negated) 'overlaps nonsolid object'

    Yeah, but that isn't same. With "Overlaps nonsolid" (Though I prefer antisolid, it's clearer way to say it) collision event triggers only when the sprite doesn't overlap tunnel at all, but collision event SHOULD trigger when even PART of the sprite is not overlapped by nonsolid. In another words, the condition should be "(negated) totally covered by nonsolid object". And we don't have this kind of condition.

    That "totally covered by" would be nice feature to have also... the collision checker wouldn't search for pixels which collide, but pixels which DON'T collide.

  • If I understand correctly, you just want an attribute that undoes 'solid' and makes its opaque area count as non-solid space?

    I'm not sure using hundreds of anti-solid sprites for destructible terrain is a good idea performance-wise - it might be better just to use lucid's suggestion, especially given it could be tricky to program an antisolid attribute.

  • If I understand correctly, you just want an attribute that undoes 'solid' and makes its opaque area count as non-solid space?

    Exactly.

    I'm not sure using hundreds of anti-solid sprites for destructible terrain is a good idea performance-wise - it might be better just to use lucid's suggestion, especially given it could be tricky to program an antisolid attribute.

    That might probably be the case, but I'd say this would still come in useful, for example if you have large destructible terrain but few ways to destroy it. Like for example a scrolling platformer where you get grenades - you could make pretty holes with the grenades without having to use canvas for the whole level (or every destructable part of it). You could also do temporary passageways and other similar neat things.

    As a sidenote, Clickteam's products have this - you just place an object marked as "not obstacle" over an obstacle. At least this was the case with TGF, I don't remember if this is the same with MMF/MMF2, but I think it is.

  • If I understand correctly, you just want an attribute that undoes 'solid' and makes its opaque area count as non-solid space?

    I'm not sure using hundreds of anti-solid sprites for destructible terrain is a good idea performance-wise - it might be better just to use lucid's suggestion, especially given it could be tricky to program an antisolid attribute.

    There is another things you can do with this too. And it isn't possible to create simple moving and resizing etc. holes in solid with canvas. Say you want to have liquid, where the character can't go, but there's bubbles in the liquid, and the character can move inside these bubbles.

    Also, I can think uses for is fully overlapped/covered/whatever by ... -condition. Is it hard to do? For Construct 2, at least?

  • There is another things you can do with this too. And it isn't possible to create simple moving and resizing etc. holes in solid with canvas. Say you want to have liquid, where the character can't go, but there's bubbles in the liquid, and the character can move inside these bubbles.

    you can:

    click here for bubble example

    Also, I can think uses for is fully overlapped/covered/whatever by ... -condition. Is it hard to do? For Construct 2, at least?

    I'm not going to speak for the devs

    but I believe maybe for construct 2 it might not be so bad, but for construct 1 it would probably require adding extra code to every behavior that recognizes the solid attribute

    also, I think the current code for collision detection doesn't have a 'wholly overlapping' method

    so it would be a whole new avenue of potential bugs while we're on the 99-1.0 homestretch

  • you can:

    Oh, I see. I'm embarrassed to say that I have clearly used canvas object too little :P

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)