Thanks for the quick replies!

I don't think I'll have as much as 100, but even if it won't make much difference, I'd rather stay safe and optimize it.

Thanks again!

Let's say I want platforms that move and some that don't using the Sine behavior.

-I could either make 2 different object types, one with the sine behavior and one without the sine behavior.

-I could also have just one type of object, with the sine behavior, and to platforms that don't move put all the "Sine stuff" to 0 (or just disable the behavior on them).

So my question is simple: are platforms with Sine behavior set to 0 (doesn't move) taking any more resource than a platform with no sine behavior at all?

Thank you for the feedback! So, that's why I can't disable collision... good to know.

Yeah I noticed it's now a mess, the more I tried to fix my issue, the messier it got.

And all the sub-events are just "patches" I put up on top of it, trying to fix the issue, and can all be removed.

The "If enemies are not overlapping with the platform at offset" was a way I found to make enemies turn at the edges of platforms without having to put edge markers at every platform edges. I guess I'll have to either tweak it or scrap the idea completely. (EDIT: I'm scrapping it) That way, I'll be able to just "turn collision off" on the enemies and eliminate most of the mess I shared in this topic! lol

I actually tried turning off collision before, like you yourself tried, and got the issue you mentioned, but couldn't understand why.

Thanks again!

Hello! Thanks for taking the time to enter my topic. I've been trying to fix that for like 10 hours. Tried many different things, all fail.

Overview of what I need and the issue I have with it:

-I have different colors of enemies (color families), and the user can make one color at a time disappear from the screen (they become invisible, solid becomes disabled, and they get pinned to background :: that's what I'll mean in this topic when I say an enemy becomes "inactive"). To make it simple, in my example the user simply presses the arrow keys to decide which one becomes "inactive".

Issue: When an enemy walks in front of an "inactive" enemy, the inactive enemy isn't filtered out correctly and performs an action that should only be performed by an active enemy. In this case, the inactive enemy currently going to the right changes direction ("go_left" boolean variable becomes "true"). I tried to fix that for 10 hours, trying many different ways to filter it out, but everything I try fails. In my last attempt, which is represented below by the sub-events, I tried to use the enemy graphics and then in my last attempt even added a ridiculous opacity check (the inactive enemies now also get their opacity set to 50) so that they would be filtered out for sure, but it still doesn't work. I have no idea why the opacity check doesn't work.

One thing I noticed, it seems that the issue only occurs with the "inactive enemies" with Go_Left set to False. If Go_Left is set to True, the issue doesn't occur and they don't change direction. Which means to reproduce the issue, make an enemy inactive while it is going to the right, wait for the other enemy to walk pass it, then make the inactive enemy active, and you'll see he changed direction.

One way to fix the issue easily would be to code every color family separately, each having their very own "Go_Left" variable. However, that would mean having 4 times more code for everything that has to do with them changing direction (there will be 4 colors in total), and thought it might be the "lazy" way out for me, and that there's probably a better way to fix the issue.

After 10 hours it is getting me insane and thought it would be a good opportunity to ask for help for once. The capx file is attached. Thanks!

Note: I don't know why the pics don't appear here, but if you right click them and copy the url you can check them out!

Okay, that's what I thought but wasn't completely sure (maybe in some rare cases for reasons I don't know it would have caused issues).

Thanks a lot for confirming it!

No time to check myself, but have you tried using containers (read the whole page: https://www.scirra.com/manual/150/containers) to associate your enemy boxes with the enemies? And then rework your whole thing with the containers in mind. I'm still a noob but just read that page and thought it could help you (and LittleStain quickly mentioned the containers already).

Sorry if it's not actually helpful, but I think it could get you rid of the whole ID variables idea which could be causing your issues. If you're already using containers, my bad.

First, Ashley, it was a great tutorial, very easy to follow. I completed it last week, and then later did the part about adding the Game Over screen and having the monster get faster and locate the Player if closeby, etc.

My question is simple:

You set your Game Over object to be visible, and then at the start of layout you set it to invisible. What I did in my version, instead, I set my Game Over object to invisible, and then, when dead and the user presses Space to go to layer 1, I set the Game Over object to invisible.

It seems to me that there's no difference at all, the result is the same in both mine and yours. So my question: is there any reason why doing it your way would be better? Why set it to "visible" in its properties? Any problem with my way?

(Anyone can answer even though it seems like I'm asking Ashley, lol.)

So, I ended up buying the non-steam version license. ^_^

So, if I get it right, this list is always kept up to date when there's new behaviours and plugins. Am I right?

EDIT: Okay nevermind, it's obvious it IS always kept up to date. Sorry, lol. Thanks for taking care of this thread, very helpful.

I wouldn't have to ask that if the forum was saying something like "edited on X(date)" at the end of posts..

Sorry if it seems obvious, but I just want to make sure before I purchase.

Thanks a lot!

Following your link I found that list here scirra(dot)com/forum/c2-plugins-and-behaviors-list_t65170 (your topic actually) and, just with a quick look, I'm pretty sure I recognize at least some behaviours from the steam free version, such as Turret and zig zag, which makes me think there's probably many that are already in the steam version.

It seems that list was posted in 2011, is it being updated via edits when there's new ones to stay up to date? (If so, I could just install them all and I'd be sure to have all the ones steam has).

EDIT: sorry for the "link", I'm not allowed to post links yet.

EDIT2: hum, okay, maybe I'm mistaking about them being already in (weird, then what are the other turret and zig zag behaviours that are already in? and then why make a plug-in..), but my question about -- if the list I linked is up to date still stands. =)

I already found threads about what you're referring to, but most complaints are from 2013 and most of the more recent posts say "it's better now" about the steam version problems.

That said, I'd like answers to my original post. But thanks anyway.

EDIT: And yeah, I meant plug-ins when I said mods... same thing I think. ^^'