2 Line renderers in one script = Unity poops itself, and cowers in a corner

If you have two line renderer variables in one script and start making them do things Unity will fall apart and start confusing variables, ignoring lines of code and behaving randomly. It really pushes Unity to it's absolute limit if you start asking it to keep track of two distinct instances of line renderer components.

Truly a powerhouse of an engine.

 

The most likely scenario in this case is user error. Where the user is you.

If you want help, post code that is causing issues.

 

Aren't you just getting the same LineRenderer? After all the docs says this for GetComponentInChildren:

So if it finds a LineRenderer in the current GameObject then it will return that one, but only if there is no LineRenderer in the current GameObject will it go looking for one in the children to return.

Edit: hmmm, not sure why your post has suddenly disappeared, but when you posted your code I clearly saw you doing a GetComponent and then a GetComponentInChildren both for the same component (LineRenderer).

 

It was indeed me. I'm humbled once more. I was doing GetComponentInChildren when I should have been doing transform.GetChild(0).GetComponent. Because apparently GetComponentInChildren searches yourself before cycling through children. Dumb af, but I've wasted enough time already so won't waste any more complaining about this.

 

Thread should be renamed:

2 Line renderers in one script = @mat108 poops himself, and complains on forum

 

That's a pretty dense thing to say. Rather 'GetComponentInChildren' should be renamed 'GetComponentInMyselfAndIfIdon'tFindItLookForItInChildren'

 

Or you could read the documentation, which clearly says what is it and you don't shift the burden of change on millions of projects with your totally not necessary rename.

 

lol

 

That's a pretty good name but the grammar is misleading. It should be "GetComponentInMyselfButInTheCaseThatItIsNotFoundThenIWillSearchAmongMyChildrenForTheTargetComponent."

Since AND has certain implications in programmer jargon I think its necessary to avoid using that in a case that it wouldn't make sense. I think you'll agree that my name is more descriptive and should help new users avoid problems.

 

I dunno, I think we need to consider more natural, casual language to avoid scaring off new devs. I'd like to propose a new overall standard for naming that reads more conversationally, in this case "OkaySoWhatImLookingForIsAComponentInTheObjectsAttachedToThisOneButItsOkayIfYouFindItInThisObjectTooYouKnowNoPressureAnywayThanksPleaseGetBackToMeWhenYouCan"

 

That's an async call. Just sayin'

 

All calls should be async. It's only polite, after all.

 

A good code should document itself though.
GetComponentIncludingChildren<>() makes more sense in this case?

GetComponentInChildren implies the scope is the object's children only.

Parameters might help, but results in less readability.
GetComponent<>(includeChildren = true, includeSelf = false);

 

If they make a new API, sure, but it's stupid to change a well established API on a whim, just because you don't like it.

 

You're hitting the situation where human language is not precise enough to express intent of the method.
For example, the name you proposed does not specify that the method actually searches for the component, and also implies that it is the component that has children and not comonent of a child object.

For descriptive name, you'd need to use something like "TraverseHiearchy", "SearchHierarchy", etc.

This sort of method could be something like:

Code (csharp):

1.  
2. SearchType searchHierarchy(this GameObject root, System.Func<GameObject, SearchType> searchDelegate) where SearchType: new()
3.  

And you could use it like this:

Code (csharp):

1.  
2. GameObject obj = ...
3. obj.searchHierarchy( arg => arg.GetComponent<Renderer>() );
4.  

Then you can embellish it with filters etc, and end up with something generic like:

Code (csharp):

1.  
2. void walkHierarchy(this GameObject root, System.Action<GameObject> objectCallback, System.Func<GameObject, bool> objectFilter = null, System.Func<GameObject, bool> childTraversalFilter = null);
3.  

The question is whether you want something like that or not. Becuase that's linq territory.

 

Reminds me of this one https://github.com/neuecc/LINQ-to-GameObject-for-Unity

 

Can we just go back to discussing how glorious:

Code (CSharp):

1. gameObject.OkaySoWhatImLookingForIsAComponentInTheObjectsAttachedToThisOneButItsOkayIfYouFindItInThisObjectTooYouKnowNoPressureAnywayThanksPleaseGetBackToMeWhenYouCan()

would be. We need a whole api of that. don't make this into a boring thread of actual programming talk

 

if a thread with poop in the title turns serious i have no hope for the community

 

Both array and list can be verbs. ArrayComponentsInChildren and ListComponentsInChildren.

I love the idea but I wonder how it performs. The official thread is a bit vague about it.

 

I don't think @mat108 wants this thread to exist anymore.

 

There should be an API call to close forum threads too. Maybe something like

Code (csharp):

1.  
2. HeyListenIreallyBeefedItWithThisOneAndIJustWantThisToGoAwayYouFeelMe(true);

 

We've steered it off course to the point I keep having to check to remember who started it.

 

We could also go about it APL way and introduce a symbol just for this particular function. Then make a custom keyboard jsut for it.

https://en.wikipedia.org/wiki/APL_(programming_language)

Spoiler

 

There's probably some language out there with a term that means "a person and all their descendants". That English doesn't cover the case doesn't mean that all of human language is insuficient!