I have 1 object and they will respawn every minute, but whenever another aparace buga because the events of one happens in the other, example: a ship only shoots when its line is pointing the player, but when it has 2 ships it only shoots when the two lines are in the player
Hmmm.... your program is very confusing
But from what I can see its a picking issue lacking a for each, but there are so many checks for the same things in your code, that you could probably fix it, simply but correcting all the "Linha is overlapping" events. but I don't really think you will get a lot out of it, due to how you have structured your program in general, I think you would do yourself a favor, if you started from scratch and get the structure of the program designed in a more logic way where you can work with it.
Because looking at it now, I can say with 100% certainty that you will run into similar problems sooner than later, I don't say this to annoy you, but to help you avoid spending a lot of time on something that you will loose control over very fast as you expand your program, so I hope you don't misunderstand what im saying, its meant in a friendly way.
To help you get started, here are some ideas that I think would help you.
1. Use telling group names and comments.
Having groups named C, C2, C3... Group 1, Group 2 etc. is never going to work, it might work the moment you work in that particular group, but the moment your program begin to grow, you will loose control. Always add comments of what the event is suppose to do, even if it seems very simple.
Like:
//Enemy will attack player if they move to pickup crate
Even though the code for something like that might be very simple, just having the description written down will help you the next time you have to look through your code and to quickly get a overview of what is suppose to happen in a given event. If you don't use comments you will loose control of your project at some point, its 100% certain.
2. Structure event where they make sense
Having several "On start of layout" varies places throughout the code will make things very confusing compared to making it the first event on each event sheet and only add one. It will not benefit you having several of these.
Add event sheets for specific tasks or objects.
As an example, you have a Player and you have some enemies, but also you have some events to control the game, like "On start of layout". So instead of mixing all these together, like Player functionality with Enemy functionality, you make an Event sheet called Player and one called Enemy and one called Game, since the Game event sheet controls the overall game, you include the Player and Enemy event sheets into that.
It will help you a lot when it comes to finding stuff later, so if you need to make some corrections to the player, you know that its most likely to be found in the Player event sheet.
3. Use functions and avoid repeating functionality
Using functions will really make things easier, both to program but also when it comes to testing and bug fixing, because you can specifically test a function input and output very easy.
If you use a lot of "X is overlapping Y" with varies conditions for the same thing, like if the purplebeam is overlapping player, you will end up with a huge amount of events for no reason. You can think about it like, you have to find common conditions in order to reduce complexity.
So if this is one event:
Purplebeam is overlapping Player
X = 0
And this is another
Purplebeam is overlapping Player
X = 1
Then Purplebeam is overlapping Player is a common condition for both events so you can combine them into.
Purplebeam is overlapping Player
X = 0
or
X = 1
[/code:1dkforij]
This will help you reduce the amount of events, which again will make things a lot easier for you.
[b]4. Get a good understanding of picking[/b]
Understanding how picking work is essential if you want to do anything in C2. So really spend time getting to understand this is crucial in my opinion, by far the most mistakes people make when they are new to C2 is wrong picking from what i have seen and think everyone when they started have made their fair share of mistakes here .
The best way to understand picking is to see it as a way to reduce potential objects of interests.
For instant:
Object is a car
Car must be red
Car is not broken
Each of these steps reduce the number of potential cars that we are interested in, so always start as wide as possible and keep reducing until you are satisfied.
The reason I write this is because when looking at you code you seem to get it backwards a lot of the time.
Example:
[code:1dkforij]
For each Sprite
Sprite.Physics X velocity > 200
[/code:1dkforij]
There are situations where this way of using a For each is beneficial, but for the most part this is the wrong way to do it. Because what you are interested in, is picking all Sprite.Physics X velocity > 200 and when you have found them, you want to do something with them.
So the code should be:
[code:1dkforij]
Sprite.Physics X velocity > 200
For each Sprite
[/code:1dkforij]
Anyway hope you see what I mean, because its just to help you and to save you some time and frustrations. It is really worth spending time on these issues compared to just programming like crazy only to having to dump it all due to loosing control. Even when you get a hang of it and really think you have a good structure etc, it will be the biggest issue and main reason for dumping a program I think.