I think I'm having a similar problem here: https://www.scirra.com/forum/making-turrets-target-objects-based-on-team-instancevariable_t166138

I can't figure it out. Any ideas?

I have a problem.

I have a game with many units, but each unit has an instance variable called Team which marks what team they are on.

In this example, it's a space ship called SpaceFighter-- this is only one Object type. I do not want to clone this object type or make a duplicate object type, I want to do this using instance variables. There's two teams. Team 1 and Team 2.

So there's two SpaceFighters.

SpaceFighter 1 : Team = 1

SpaceFighter 2 : Team = 2

They fly around and also have a Turret behavior, it's great. However, adding targets has proven to be difficult.

I obviously only want SpaceFighter 1 to target objects on Team 2 and not it's own team (Team 1), but I'm not sure how to do that.

Does anyone have any ideas?

This is an old post, but I believe I'm experiencing this issue right now. If it's by design, it's flawed design, what is the workaround? I'm trying to have turrets only target objects on teams other than it's own team.

You need to put the anchored object within the dotted line area which I think are called margins.

I had to unsubscribe from Scirra emails, after 30 or so emails, it got to me.

Closing as by design: restarting a layout first destroys everything on the layout, and naturally that creates anything you create in "On destroyed". What should happen if you create an object half way through destroying everything because the layout is ending is a question with no clear answer in IMO, and the C2 engine happens to leave them there for the next layout which I think is reasonable. If it went back and destroyed the newly created objects too, it could easily end up hanging, because it could get stuck in an infinite loop as the new objects are destroyed, which creates new objects, which are destroyed, which creates new objects...

Workaround: set a "don't create objects" flag just before restarting the layout, and don't create anything if that flag is set.

Hi Ashley,

Thanks for your constant presence on the forum.

I hope I can change your mind on something, or at least begin a dialogue about it.

I think we're all stuck in this mindset where the only possible way to remove an object is to 'destroy' it. The problem here is that 'destroy' comes with the option to have conditions of "on destroyed" triggers.

This is great, but obviously becomes problematic when going to a new layout. I think destroying all objects on layout change is a mistake, and a new term should be invented within Construct 2. The term should be "remove". Add a "remove" feature to Construct 2 and don't give users the option to have "on remove" triggers.

Remove should be the same as 'destroy' but now it simply removes or deletes the object instead of destroying the object, which can lead to unintended consequences on layout change.

Once a "remove" feature is put into place, then make C2 "remove all objects" upon layout change, instead of "destroy all objects."

--

I think this is important because errors can occur with the current set-up. For example, if you have a chain of on-destroy triggers, and you do two consecutive layout change with different layer quantities or set-ups, an error will occur and functional gameplay will cease.

Example:

1. On BigShip destroy, spawn two ShipHusk.

2. On ShipHusk destroy, spawn Rubble.

Layout 1 has 7 layers, Layout 2 has 1 layer, Layout 3 has 7 layers.

Change from layout 1 to layout 2, Bigship is destroyed, two ShipHusk are created on Layout 2.

Change to layout 3, the two ShipHusk are destroyed and Rubble is created on Layout 3-- but it's not sure what layer to put it on, resulting in an error.

Yes, this can be worked around by adding a variable to all On Destroy triggers. But that means you're asking users to use a workaround for something you won't consider a bug. What is it a workaround for? A lack of a feature?

--

I hope this post finds you in a good mindset and open to ideas. Thanks for your time!

About that walk, yes, it does. I usually only post on here when I can't figure something out on my own for hours of struggling.

Sometimes the answer just pops into my head when I'm not even trying to think about it, such as in the shower or in a meeting at work. Figuring it out on your own is rewarding.

I remember reading in the past that the Else doesn't work as intended in some situations, perhaps this is why

Wow this took a turn.

Bottom line: nothing holding anyone back from actually learning a language.

I love C2, it makes me barking mad, but i love it. But nothing stops me from jumping into unity, or unreal, or gm, and nothing stops me from continuing to use C2 (it is great)

But in todays fast pased world, a profeciency in some languages is a must.

I am writing my CPP (C++ Certified professional Programmer) exam in 12 weeks... the thing is WE can't stop learning. You stop learning, you stop developing and you will fall on your face.

I hope to get professional certificates for all the C's and possible a CPS (certified senior Programmer).

Truth is, my brain has come along in years and learning isn't as easy as it used to be. I see youngsters complaining about everything, and they have the time and brain power to actually learn, but do nothing.

You are limited only by your ability and not the ability of the tools you use

What are you on about? Did you seriously just brag about taking a programming exam in a Construct 2 post criticizing flaws in a game engine that is marketed to non-programmers?

We didn't buy this program to get frustrated and learn how to program. Some of us, like myself, bought Construct 2 to make games and we're running into some serious performance issues. This thread isn't for you.

Anyway, I've arrived at this thread because I too am experiencing some serious performance issues that really shouldn't be happening. I hope we can get somewhere with this and reach a conclusion.

I get 13 FPS on a computer I edit video on, anyone else get a low FPS?

To play devil's advocate, they aren't described to work in the other way, either. (firing the triggers from the old layout onto the new layout)

If I had to choose the more logical outcome (stopping triggers from firing vs firing the triggers in random locations on a new layout) I'd choose the former.

There's two possible fixes, really.

1) Add a 'remove' feature and set it so changing layouts removes instead of destroys.

or 2) Destroy everything BEFORE the switch to the new layout instead of at the same exact time.

Finally found this thread to help me fix this issue. I'm going to post this in feature requests, but I think we should have a "Remove object" feature, and also have the layout "remove" objects on layout change rather than "destroy." (Because destroying triggers "On destroy" effects... I think it's obvious that unwanted effects will occur here.) That would have saved me about 4 hours.