How to distinguish between multiple components of same type (C#)

I was trying to use (GetComponent) in C# but my game object has 2 components from the same type (Wheel Joint 2D) so please how can distinguish between them?
i can’t use the drag and drop thing because i use instantiate function.

 

1) why do you have 2 WheelJoints on the same gameobject?

2) in what manner do you want to tell them apart?

 

You can use https://docs.unity3d.com/ScriptReference/GameObject.GetComponents.html instead and save that into an array. Then you can access them with name[0] and name[1].

You should answer lordofduct though since I'm not sure why you need two WheelJoints as well.

 

because i have to wheels on the car?

 

i'll try that thanks

 

thanks it worked. I use 2 because i have 2 wheels, is there something wrong with that?

 

Usually having more than 1 component of the same type on a GameObject isn't so common. There are exceptions to this of course, so it's not a hardfast rule... it's just a general thing. And when I hear of more than one component of a type on the same GameObject, my first question is "why?" If there's no good reason as to why... then it's probably not supposed to be like that.

Take example of a WheelJoint and WheelJoint2D... imagine if you put the WheelJoint's on the wheels, as opposed to the body of the car.

Now you have 1 joint per GameObject, and each wheel is easily identifiable by the GameObject they're on.

Then on your body you'll probably have a script for driving the car. On it you'll probably have fields for 'DriveWheel', which references the wheel that actually drives the vehicle (front wheel, or rear wheel, drive), and then an array for all other wheels (maybe it has more than 2 axes, like a tractor trailer). If it's a 4 wheel drive vehicle (2 axes), you might have 2 fields for 'DriveWheel', and then array of wheels for non drive wheels.

Furthermore, you never answered my question 2:

My point being... what's the difference between the both wheels? Having an array with both wheels doesn't mean much of anything unless you know which is which, and WHY you must know which is which.

Like... is this a front wheel drive car, so you must distinguish each wheel from each other so you know which one is the drive wheel, and which isn't? Ok... well, see my previous comments above about how that impacted my theoretical design. With just an array... how do you know which is the front wheels and which is the rear wheels? A rear wheel drive vehicle controls differently than front wheel drive. So that implication is sort of important.

And usually you would tell by which wheel object each is connected to. That is the gameobject the component is on if you put the WheelJoint on the wheel itself... or the GameObject the WheelJoint points to if you had put them on the body.

 

You shouldn't assume here. I am working on a 2d program that uses excel like fields, with a row containing multiple items, and I've decided to make rows GameObjects with it's fields components of those GameObjects (I can instantiate one row at a time as needed).. It isn't exactly excel, but the anology applies.. Then I only need to resize one object for instance. It's cleaner. I shouldn't have to explain this.

 

I didn't assume here.

My entire point in that post is that more information was needed so one doesn't have to assume.

And yes, you shouldn't have to explain this... no one asked you to dig up a thread over a year old to explain your edge case. An edge case I excepted for in my explanation by saying it's not a hard fast rule.

 

Even for this excel-like thing, child gameObjects are better. Resizing the parent still works perfectly. It makes it simpler to re-arrange, test, add new parts later. It makes moving NxM chunks simpler. Without them you usually end up pulling out matching Components, maybe saving them somewhere else, then realizing that's exactly what gameObjects are for. They're just nodes, who doesn't like nodes?

 

bruh, wheeljoint2d's don't work when theyre on Empties or the wheels