Ignoring specific solids using the platform behavior...

This looks very promising

Ashley What do you think about this workaround ? Can you implement it in the official plugins ? Would it have negative effects (bugs/glitches) ?

I think he blessed it to some extent judging by ruskuls conversations with him?

We specifically recommend you do not do this. Your modified platform behavior will not stay up to date with future official changes to the platform behavior.

I'm not quite clear what the changes are for and why they are necessary - but it would be far better to update the official behavior to incorporate this. Having said that, the platform behavior is very complicated and we've had a lot of trouble with even minor changes causing a cascade of other bug reports afterwards. So this may not be easy to integrate.

We specifically recommend you do not do this. Your modified platform behavior will not stay up to date with future official changes to the platform behavior.

I'm not quite clear what the changes are for and why they are necessary - but it would be far better to update the official behavior to incorporate this. Having said that, the platform behavior is very complicated and we've had a lot of trouble with even minor changes causing a cascade of other bug reports afterwards. So this may not be easy to integrate.

Oh yes, I've seen recommendation against fiddling with official plugins, but must needs and all.

Okay, Ashley let me explain. In Fusion 2.5, The Games Factory or Multimedia Fusion (remember these?)

I might decide to have a staircase for my player to either walk past or walk up, depending on if he falls on it (lands on stair) or walks past it (stays on ground floor).

Now, obviously the jump-through behavior might work here, but it's buggy and doesn't like slopes, etc, etc, etc.

So I might have a detector set to the players feet, if it it overlapping the ground-floor and I touch the stairs, I go up them, if it's NOT overlapping the ground-floor and I touch them, I go up them.

Here's where Multimedia Fusion is cool! I just disable collisions on my player character when I touch the stairs by adding a condition whereby:

[quote:3labwl9a]+ if basePlayerdetector is not overlapping groundFloortiles

+ PlayerObject is falling

= Simulate platform behavior collides with obstacle

Thus, this effectively happens:

[quote:3labwl9a]+ if basePlayerdetector IS overlapping groundFloortiles

+ PlayerObject is walking

= DON'T Simulate platform behavior collides with obstacle

Unfortunately, this is where Construct2 has difficulty since it handles all of it's object collisions based upon the OBJECTS solid state, rather than the players.

Doesn't seems like a problem though, does it? I can after all just do this in Construct2:

[quote:3labwl9a]+ if basePlayerdetector is not overlapping groundFloortiles

+ PlayerObject is falling

= Set staircase to solid enabled

Thus, this too happens:

[quote:3labwl9a]+ if basePlayerdetector IS overlapping groundFloortiles

+ PlayerObject is walking

= Set staircase solid disabled

However! What happens when we have enemies that want to walk up and down stairs?

What happens when we have multiplayer characters that want to walk up and down stairs?

So, we now have only the player character to decide if a staircase should be walked up or not, rather than every individual character being able to walk and down a staircase at will.

Simply because C2 handles the staircase's solidity, and Multimedia Fusion handles the individual NPC's collisions with the object.

Ashley further reading:

We specifically recommend you do not do this. Your modified platform behavior will not stay up to date with future official changes to the platform behavior.

I'm not quite clear what the changes are for and why they are necessary - but it would be far better to update the official behavior to incorporate this. Having said that, the platform behavior is very complicated and we've had a lot of trouble with even minor changes causing a cascade of other bug reports afterwards. So this may not be easy to integrate.

So, Ashley can we expect a "disable collision filtering" event in a forthcoming C2 update?

Can you file a bug report requesting this with a demo? It will most likely be lost in the forums otherwise (as looks like has already happened before!)

Can you file a bug report requesting this with a demo? It will most likely be lost in the forums otherwise (as looks like has already happened before!)

Okay Ashley , I'll throw together an example of how it could be done with a comment denoting where such an event would be useful. If anyone else here has any other examples that could be useful in this request, chime in...

Can you file a bug report requesting this with a demo? It will most likely be lost in the forums otherwise (as looks like has already happened before!)

Ashley all done!

If there's anything I could do better with this example: let me know and I tweak it to present a better case to Ashley

Please, we need a few weeks to even review bugs reports, and then actually implementing it can take a few weeks more, but can be delayed further as we have to schedule all the work we do with the great many other feature requests/bug fixes many other users are requesting of us, as well as Construct 3 development. Please be patient.

Zebbi - Did you answer your question about instance based update vs object based update? If I'm understanding you correctly, then I use it to control each instance as I see fit. You can update all of the objects or you can use the conditions to narrow down which ones are affected.

You need to make sure all get updated though and that none get updated more than once... unless you are simulating high speed and need more checks per tick for whatever reason.

-Honestly though, at the end of the day, I have yet to be able to put the platformer behavior to a good use baring simple use case scenarios. I usually end up making my own, that way it is something new, unique, and mine. Its hard but then you can do anything and not worry about side effects of using the behavior.

Addressing this would be great (collision filtering solids)... though I believe the most useful thing that Ashley could provide is more tools for lower level designs (access to the built in collision detection for example). Custom movement is an idea in the right direction but really lacks the tools needed to work with ideas similar to what Zebbi noted. Not being able to access collision information, I had to basically make my own collision detection, filtering, and then built a custom platformer behavior over that. At this point I still tell people c2 is great for speed and prototyping, but once you get down to "making the game" you have to script- even in c2 - if you want something original, that is, from a mechanical perspective.

Zebbi - Did you answer your question about instance based update vs object based update? If I'm understanding you correctly, then I use it to control each instance as I see fit. You can update all of the objects or you can use the conditions to narrow down which ones are affected.

You need to make sure all get updated though and that none get updated more than once... unless you are simulating high speed and need more checks per tick for whatever reason.

-Honestly though, at the end of the day, I have yet to be able to put the platformer behavior to a good use baring simple use case scenarios. I usually end up making my own, that way it is something new, unique, and mine. Its hard but then you can do anything and not worry about side effects of using the behavior.

Addressing this would be great (collision filtering solids)... though I believe the most useful thing that Ashley could provide is more tools for lower level designs (access to the built in collision detection for example). Custom movement is an idea in the right direction but really lacks the tools needed to work with ideas similar to what Zebbi noted. Not being able to access collision information, I had to basically make my own collision detection, filtering, and then built a custom platformer behavior over that. At this point I still tell people c2 is great for speed and prototyping, but once you get down to "making the game" you have to script- even in c2 - if you want something original, that is, from a mechanical perspective.

I see what you mean, I'm still in the middle of switching to using this method fulltime since I'm not sure if it will work in the way I need, here is the example I built for Ashley to look at: https://www.dropbox.com/s/3ezha00yp7da5 ... tairs.capx as you can see, that just uses the stock c2 event, but you can understand with that how it SHOULD work, and how it's not possible to work currently due to the collision restrictions. Can I use the Ruskul mod to get this to work in the way I've exemplified?

Of course, we might be closer if Ashley goes ahead with adding the simplest little event to disable collisions per instance: viewtopic.php?f=151&t=170337

Ashley's looking into it, lend your support!

We specifically recommend you do not do this. Your modified platform behavior will not stay up to date with future official changes to the platform behavior.

I'm not quite clear what the changes are for and why they are necessary - but it would be far better to update the official behavior to incorporate this. Having said that, the platform behavior is very complicated and we've had a lot of trouble with even minor changes causing a cascade of other bug reports afterwards. So this may not be easy to integrate.

Just wondering Ashley if you still don't understand the issue we all have with the default engine and the simple switch that would open up so many possibilities if implemented?

Any thoughts?