Shrugger! Unity!

[keith.lamothe]

Well, it's not all that important, I guess...until I have to build a catapult, at least.

Oh, simulating a Space Trebuchet is easy.

Just give it a 100% chance of failing catastrophically.

[Shrugging Khan]

Heh. I'm currently making good progress on my physical object management system (POMS!), which will allow me to have space AND planets! With gravity! It just took me a few months to figure out how to convert Cartesian to polar coordinates to orbital elements and vice versa. Now I just have to manage some floating origins, ignore relativity, trick unity into doing my bidding and add some actual content...

...actually an older version of my space game already had space trebuchets. They might have been based on linear magnetic acceleration. The AI also had a 100% chance of utilising them incorrectly 

[Draco18s]

As for the broken part's velocity:

http://www.dummies.com/how-to/content/calculating-tangential-velocity-on-a-curve.html

Figure out the magnitude and direction as if the parent object wasn't moving (just spinning) then add the result to the parent object's non-spin velocity.

Then yeah, add some random spin for tumble, will be close enough.

[kasnavada]

If I understand well, if "object 1" is the base object, object 2 being the one separated... I'd consider the center of gravity of "object 2" as being a "point" on a circle centered on the center of gravity of "object 1" (and make both shapes irrelevant). Then this model applies:

https://en.wikipedia.org/wiki/Circular_motion

[Shrugging Khan]

Thanks for the links, gents. I'm just horrible with Math, so it'll take me some time to figure out how it all works for 3D (all examples I can find are 2D only).

Unrelated: I'm currently encountering some potential performance problems with the POMS!. Since an object will recalculate its mass, center of mass and other stats when a subobject is attached or removed from it, and all objects are attached to the planet in one way or another, the planet has to iterate through every object there is every time something gets chopped off of or welded to something. I was hoping my POMS! would be able to work without exceptions, but this one has me stumped a bit. I suppose this would've been a problem for any sufficiently complex object...maybe some sort of bucketing is in order. Does anyone know a good algorithm to determine what the ideal bucket size is? I know one has been mentioned in a lecture, but that was a fair while ago...   

[Shrugging Khan]

Does anyone here know their Lambda expressions?
I'm getting NullRef Exceptions at the following line:

Code: [Select]

List<TLO> tlos = abstractablesThisTurn.Select(item => item.objekt as TLO).Where(item => item.GetType() == typeof(TLO)).ToList();Where abstractablesThisTurn is a List<Abstractitem>, AbstractItem.objekt being the interface Abstractable, and TLO implementing said interface.

The error reads as following:

Code: [Select]

POMS.AbstractionHandler.<Update>m__17 (POMS.TLO item) (at Assets/SKRIPTE/Physical Objects/Physical Object Management System/AbstractionHandler.cs:152)
System.Linq.Enumerable+<CreateWhereIterator>c__Iterator1D`1[POMS.TLO].MoveNext ()
System.Collections.Generic.List`1[POMS.TLO].AddEnumerable (IEnumerable`1 enumerable) (at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Collections.Generic/List.cs:128)
System.Collections.Generic.List`1[POMS.TLO]..ctor (IEnumerable`1 collection) (at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Collections.Generic/List.cs:65)
System.Linq.Enumerable.ToList[TLO] (IEnumerable`1 source)
Now, this won't be a hassle to rewrite without Lambda trappings, but they're just so damn elegant when they do work.
So if anyone knows their way around them, please do tell me what I borked here 

[keith.lamothe]

Does anyone here know their Lambda expressions?

Enough to avoid them They should be fine in general, but it's an additional layer of indirection where I may or may not understand what the compiler actually does with it. Kind of like the difference between for(int i = 0; i < Length; i++) and foreach; similar semantics but very different performance implications in some circumstances. But with lambdas having much higher potential for that kind of gotcha.

That said, I don't think the nulls here are due to the lambdas. Maybe it's a cast that it can't actually perform at runtime, though that seems odd. Best to just strip away the extra complexities and debug the logic itself, with something like:

Code: [Select]

List<TLO> result = new List<TLO>();
Type tloType = typeof(TLO);
for(int i = 0; i < abstractablesThisTurn.Count; i++)
{
  Abstractable item = abstractablesThisTurn[i];
  if(item == null)
  {
    Debug.Log("see the violence inherent in the system!");
    continue;
  }

  if(item.GetType() != tloType)
    continue;

  TLO itemAsType = (TLO)item;
  if(itemAsType == null)
  {
    Debug.Log("bwuh?");
    continue;
  }
  result.Add(itemAsType);
}

And if that works, then investigate the lambda-specific parts.

[Shrugging Khan]

There's a performance difference between for and foreach!? D:
*googles*

The for-loop is faster than the foreach-loop if the array must only be accessed once per iteration.

Alright, so nothing unexped!

So back to the Lamdbas: I guess you're right, in that I shouldn't try to optimise. Especially when all I stand to gain is concise code. I suspect I sometimes mistake concise code for fast code, to be honest.

Having switched to Non-Lambda, it works. Once again readability saves the day. So thanks for reminding me of that 

[keith.lamothe]

There's a performance difference between for and foreach!? D:
*googles*

The for-loop is faster than the foreach-loop if the array must only be accessed once per iteration.

Alright, so nothing unexped!

I didn't mean that at all. That kind of overhead is fine.

What I mean is that entering a foreach involves allocating an iterator object, at least in mono. And if you have a heavily nested section that involves a foreach, such that the section can get hit thousands of time per frame, and you're going for 60fps, you're going to pile up an awful lot of temporary allocation. That's not a semantic problem, but it can lead to frequent garbage collection, which can be quite a bane. We ran into it in a serious way when porting AIW to unity, because the GC was happening so often it was chopping the music playback to pieces, nor was it great for general responsiveness.

When we converted some of the most frequently hit foreach's to for's, that problem mostly went away. There are other things like List<T>.Contains() where T is a value-type that cause similar problems, or anonymous delegates that involve local parameters from the calling scope, but step one was "stop using foreach"

So back to the Lamdbas: I guess you're right, in that I shouldn't try to optimise. Especially when all I stand to gain is concise code.

I think the optimization is fine, as long as you understand (and are willing to accept) what it's actually doing. And remember that the biggest optimization is from "not working" to "working".

Are you sure the problem was actually in the lambda, or was the list being iterated containing some nulls or whatever?

[Shrugging Khan]

the biggest optimization is from "not working" to "working".

I have to pin that to my bathroom mirror or something. It really should have stuck by now, but I keep wasting time on everything but that.

Well, the new code is simply

Code: [Select]

List<TLO> tlos = new List<TLO>();
foreach (AbstractItem ai in abstractItemsThisTurn) {
Abstractable a = ai.objekt;
if (a.GetType() == typeof(TLO)) {
tlos.Add((TLO) a);
}
}And it runs fine. I really don't know what to blame if not the Lambda thingy.

When we converted some of the most frequently hit foreach's to for's, that problem mostly went away. There are other things like List<T>.Contains() where T is a value-type that cause similar problems, or anonymous delegates that involve local parameters from the calling scope, but step one was "stop using foreach"

Gah, GC! That, and memory leaks, is things that I really try to pay attention to, but without really knowing what I'm doing...sometimes I wish I were using C++, where everything is a huge hassle but at least I know roughly what's happening to memory

[keith.lamothe]

Memory in C# isn't all that mysterious, once you know what it's doing. Though with the higher-level-abstraction stuff like lambdas and LINQ and whatnot it probably gets pretty crazy. I use anonymous delegates a lot (passed into our own functions) but nothing fancier. Even that has unintended consequences, it just saves so much code duplication when doing stuff like "for each building owned by this race that's fully constructed and not shut down, do X".

Conciseness, I can take or leave. Avoiding tons of code-duplication, on the other hand, is really important.

[Draco18s]

Having recently dived headfirst into contravariance,* I discovered that the .NET version used by Unity (yes, even Unity 5) is .NET 2, so its possible that what you're trying to do is fine....in a newer version of .NET, but not in 2.0

*I wanted to write my own event system where I could make a call like this:

Code: [Select]

... {
    someObject.attachEvent(someFunc);
}

public void someFunc(SomeEventType event) { }
But I couldn't 'cause .NET 2 doesn't support the contravariance required to figure out what Type the attachEvent function's parameter is supposed to have.

[keith.lamothe]

But .NET 2.0 supports plenty of contrariness!

[Shrugging Khan]

New Issue: I have to handle a large number of objects, each at a specific point in time.

Essentially, every time I'm done handling an object, I estimate when I'll need it again and toss it into some collection with a note saying "take a look at this again at (UnityEngine.Time.time > 418.012)" or somesuch.

But I've no idea what kind of Collection to use. List? SortedList? Some sort of Set? Since this has to handle pretty much every object in the game world, of which there may be many, it has to be as performant as possible - both when inserting new elements, when I get at them again, and when I eventually throw some out. And I have to be able to either cheaply remove and re-add elements, or it has to support changing their assigned date when I reexamine them.

Any ideas?

[keith.lamothe]

New Issue: I have to handle a large number of objects, each at a specific point in time.

Essentially, every time I'm done handling an object, I estimate when I'll need it again and toss it into some collection with a note saying "take a look at this again at (UnityEngine.Time.time > 418.012)" or somesuch.

But I've no idea what kind of Collection to use. List? SortedList? Some sort of Set?

Try a List, get it working, optimize later if needed.

To clarify, does this collection have to have the items sorted in order of when they next need to be checked?