I have to objects: “Ext” and “Int”. When “Ext” collides with “Int” “Ext” is destroyed; while when “Int” collides with “Ent” a new “Int” is instantiated in a particular position.
What is the right order and code to write this and make it work?
I tried stuff but I end up with Int spawning endlessly and Ent not being destroyed.
Maybe only one of them should have the collision code to handle it. For instance ‘Ext’ handles both by checking for its collision with ‘Int’ then calling a function on the ‘Int’ object’s script.
How are you doing it currently? What is your setup? Which object is executing the code, which code? Or are both running some script? Also, how do you plan on determining which object collided with the other? A collision is a collision, there is no object specifically colliding with the other, as if the other did not as well collide with the first. So what do you intend to base this on? Their relative movement directions? Their speed?
You both have good points. I decided to do what adehm suggested and divide the work on two scripts, one for each object. Now Ext checks for collision and then destroy itself, after this Int instatiates another int.
I am far from finish and I am proceeding one step at the time. However I already met with some hiccups.
This should be unity scripting 101, but for some reason I cannot destroy Ext when it collides with Int:
Here’s the script:
public class Destroy_Ext : MonoBehaviour
{
private GameObject colliding;
public void Update()
{
}
private void OnTriggerEnter(Collider other)
{
if (other.gameObject.tag == "Int_Molecule")
{
Destroy(this.gameObject);
}
}
Be a bit more clear when talking about a problem. What happens instead? If so what? Does nothing happen? If nothing happens, check if the function gets called at all, and if the if-statement gets entered as you expect. Placing a couple Debug.Log statements can help you gain additional information about a problem.
I’ll give you the complete picture: the behaviour that I am exactly trying to get is the one in this animation: https://s10.gifyu.com/images/organ.gif
And I think I was finally able to do it with the code below.
Int_Molecule should instantiate only once, but if it touches more than one corner (UR = UP RIGHT, UL = UP LEFT, etc.) it instantiated twice. Is there a way to instantiate the object only once?
Have your functions return a bool. Only check the others if the one before it did not attach.
This will also reduce performance cost somewhere between 0-75%.
Other than that, looks like a lot of redundant code tho. You could write one function that combines your 4 into one, which would then simply need to be parametrized to take an holder and detector as input. Everything else seems to be the same, repeated 4 times separately. It’s usually a good idea to avoid such code repetition for maintenance reasons.
Alright i did not see you added it to the condition within the function there. That’s a bit tangled.
I would have ordered it more like this:
Each function returns a bool based on whether they executed the attachment code or not
You do know that functions can return values instead of void?
In your Update() you define some bool continue_checking=True
Now you simply execute something like if(continue_checking){continue_checking&=!UR_Attach()}
for each of your functions
, meaning continue_checking would always start as True in Update(), and since you ‘and’ it with the negated return of each function, it would become false as soon as one of the functions returned true, ie executed the attaching part.
Your problem is that your system resets itself in the next function call.
Imagine this hypothetical scenario: the bool starts as False, every function wants to attach.
What happens:
UR can execute and sets the bool to True
UL cannot execute, thus sets the bool to False again
DR can execute again since the bool is False already again, which you dont want
…
So that’s not working.
In general, when you have a problem like this and dont know why something works different from how you expect it to work, i recommend playing Debug.Log statements to gain additional informations. You could have, for example, printed a message at the start of each frame (Update) and then in each function within your attachment code part. This way you would have seen that still two attachments can happen per frame. Furthermore, you could have printed the value of the bool to gain additional information.
Granted that, since you execute everything every single frame, that would have become very spammy on the console.
The a bit more advanced solution would be to use a proper debugger, which lets you set a breakpoint and then step through the code line by line and inspect the values of involved variables.
You are still executing all of your functions. You now just potentially do it twice.
Also, you either missed a bracket, or your UR_Attach function is now declared within Update, which you do not want.
(I hope that’s valid C# as im only working with Python recently haha)
However, if only one of your functions gets called then the initial assumption that this might be caused by multiple functions being triggered might be wrong. Does the bug happen with anything other than DR at all? In the GIF you posted above it was also DR causing the problem i think. Maybe there are special circumstances in DR? Or a typo?
To make sure all your functions behave the same i would, again, recommend combining them all into one function.
Meaning one single “Attach()” function, which has parameters for a detector and a holder, which you then pass to it for your 4 cases in Update. This cuts down on code redundancy a lot, and makes it impossible for a typo or other mistake to make one of your functions behave differently than the others. This is also what functions are for: reduce code repetition.
Debugging is all about gaining additional information.
Try placing some more Debug.Log messages and find out, for example but not limited to:
Is the / a situation that causes the additional spawn reproducible? If so, this makes it a lot easier to gain additional information by analyzing what exactly happens.
Which part of the code spawns the additional square? Is it actually where you think it is?
When does it happen? In the same frame the intended one spawns? A frame later? Even later?
What triggers the additional spawn? What collides with what? Why? (Maybe it collides with the object you Destroy, since those get cleaned up at the end of the frame, but i dont think so since Update should only be called next frame.)
It’s syntax valid, but I am not sure it achieves it. What does “&= !” mean?
The fact that is always DR is just a coincidence of me testing the game the same way. It does with all of them.
I will implement the one function you suggest once I figure this problem out (and once I figure how to do the one function). It’s a good recommendation.
I am not sure how to debug this further, but I think I might know the reason.
There is no way the Attachment script can distinguish the different detectors that collide and the holders that are spawned. So it treats all of them as the same: when it collides with X Int it instantiate in X holders.
Make sure that if detectors hits A, B and C an Int only instantiates in either A,B or C (but on the base of what? Shorter distance from the centre of Ext?)
Drop the Ext Int distinction and have an Ext molecule to move to holder position instead of instantiating a new one (an object cannot move to two different positions at the same time, so I suppose it will choose one? However I don’t recall why I had to do this distinction in the first place, might have been important)