Hi. I have two arrays. one float calculate the distance for trees. Other for the tree objects. The float array I can sort it but the trees array I don’t know how to sort it. I want to sort trees array as i did on distance array to get the Y value later for the first and second one.
public GameObject[ ] trees;
public float[ ] distances;
public float[ ] PosY;
void Start()
{
trees = GameObject.FindGameObjectsWithTag(“tree”);
I’m not that good with array. I know how to sort distance because i’m using “Vector3.Distance” values. But trees is object. compares distance ! I’m a bet of lost here. Show me how to do it.
You can use ‘System.Linq’ to sort your objects by distance. In the following example script, the object transforms are sorted when you click the ‘left mouse’ button…
using UnityEngine;
using System.Linq;
public class Test : MonoBehaviour {
// Public References
public Transform[] trees;
// --
void Update () {
//
if (Input.GetMouseButtonDown(0)) {
trees = trees.OrderBy((d) => (d.position - transform.position).sqrMagnitude).ToArray();
}
}
}
You can create a custom IComparer for your trees and use it with Array.Sort.
using System;
using System.Collections.Generic;
using UnityEngine;
public class Compare : MonoBehaviour
{
public Transform[] trees;
private DistanceComparer distanceComparer;
private void Awake()
{
distanceComparer = new DistanceComparer(transform);
}
private void Update()
{
Array.Sort(trees, distanceComparer);
}
public class DistanceComparer : IComparer<Transform>
{
private Transform target;
public DistanceComparer(Transform distanceToTarget)
{
target = distanceToTarget;
}
public int Compare(Transform a, Transform b)
{
var targetPosition = target.position;
return Vector3.Distance(a.position, targetPosition).CompareTo(Vector3.Distance(b.position, targetPosition));
}
}
}
Never use LINQ. And especially never use LINQ in an update loop. LINQ generates a HUGE, no, MASSIVE - amount of garbage for the system to collect and clean up. LINQ is arguably the #1 way to kill your frame rate.
necro to complain about a tool that lots of people use regularly
I use linq, it’s perfectly fine. Yes you shouldn’t overdo linq, especially in Update. But it’s perfectly fine to intermitently use it as it is well… very powerful.
Lots of stuff you do in code is expensive… it’s why computers are better today than they were 20 years ago. We want to do MORE expensive/costly things. Don’t be afraid to do them just because you’re scared it “might” cost you something. Of course it will… the fastest code is no code at all.
OP should get it done, keep on moving, and if the game ever ends up being too slow. Well they run the profiler and if it turns out this linq statement is the bottleneck… THEN you rewrite it to be more efficient.
This of course isn’t to say always use linq. If you happen to know off the top of your head a simple way to get it done another way. That’s cool too. Point is… get the job done as well as you can. You can always refactor later if it proves to be slow.
Especially if that optimization is minor… linq is not the horrible beast people make it out to be. Linq doesn’t create massive amounts of garbage, it creates some garbage… if it’s creating massive amounts that’s usually because you’re throwing large amounts of data at it (large collections) and probably doing things that require copies of it being made… in which case your hand written version will likely also create copies as well (unless you really know your ish well, in which case, you likely already understanding the risks of linq and how to optimize like a pro). You know, like how someone points out the Array.Sort that takes 2 arrays… ok, that one is going to mean I have to create an array as large as my current one which will then become garbage!
To say NEVER use something, is bad advice. Especially a valuable tool like LINQ, because it CAN cause issues. So can rendering too much. Should we avoid rendering? Or do we try to tame the beast so it can become our friend.
When my friend wanted to learn Unity and programming, he came across various posts that read “avoid properties, they can kill performance.” So when he saw me nilly willy making properties in my classes, we had to have a chat about the difference between MonoBehaviour properties and the ones you create. Now when I see “never” or “avoid” for something that is useful. I can’t help but think of that moment of trying to explain to someone, what they read was wrong. Having to walk them through why its not a bad thing, when you don’t do what someone else did with it.
Rider can automatically take your Linq statement and convert it to standard code, which technically makes this a worse comment than “Never use LINQ”. Udonegoofed.
Necroed a thread to respond to a comment you clearly missed the point of.
They were making the point that “Riderfan” (someone whose name implies they like Rider) is merely espousing arbitrary opinion by responding with arbitrary opinion. It doesn’t matter what Rider can/can’t do… it’s conjecture for conjecture’s sake.
I don’t see how you’re making the same “opinion is opinion” riff though. You seem to be saying “your example is bad because Rider has this feature”… where’s the unsubstantiated opinion there? Where is the conjecture?
conjecture - an opinion or conclusion formed on the basis of incomplete information.
By definition not including that Rider can convert linq to non-linq code is “incomplete information” only adding to the evidence their statement was conjecture… I still don’t see how yours is.
If you interpreted what I have said as anything other than replying to a dumb joke with another dumb joke, that’s on you. There was absolutely no want or need for a reply to it in the first place.
I was not making any relevant correlation to Rider’s ability to process LINQ .
Sorry if that went straight over your head at light speed.
I was saying the point is null and void, it makes no sense saying “Never use LINQ”.
That’s just dumb. So I responded with an equally dumb statement, "In that case never use Rider,
because it makes about as much sense as what he said.
Now, I won’t say “you done goofed” because that’s just another dumb thing to say.
