Remove FlxPathManager, let FlxObject take care of updating it (#1087)

[Gama11]

This takes care of any substate issues with paths still being updated while the object they belong to isn't. This solution works because every object can only follow one path at a time - for timers and tweens a different solution is needed. Similar to the original AS3 Flixel API, FlxObject now has a public path property.

Downside: it introduces a circular dependency between FlxObject and FlxPath.

[Gama11]

This is a terrible hack, but I couldn't think of a better solution right off the bat now that start() doesn't have an Object parameter anymore.

[gamedevsam]

A better approach would be to have @:allow(flixel.util.FlxPath) _immovable in FlxObject and @:allow(flixel.util.FlxObject) _desiredImmovable in FlxPath, and have a public property that users would use to manually modify these values, like so:

public var immovable(get, set);
public inline function get_immovable() 
{
    return _immovable;
}
public function set_immovable(val) 
{
    if(path != null && path.active)
        return path._desiredImmovable = val;
    return _immovable = val;
}

The FlxPath would need to set _immovable directly, instead of using the property to avoid overriding the user value.

[Gama11]

Hm, I'm not sure that approach is better. It leads to an even tigther coupling between FlxPath and FlxObject (accessing path._desiredImmovable), I already don't like it as is..

[gamedevsam]

I is convinced, ship it. 👍

[gamedevsam]

I think a better approach would be to migrate the managers to the FlxState class (when new Timer / Path / Tween object was created, it would get its manager from the active state). Everything has to be inside of a state anyways, so why not make each state contain its own set of IUpdatable plugins?

That way we could avoid instantiating the managers until they are needed (for example, currentState.timerManager could have a get property that would spawn the TimerManager if it was null). Still, any plugins would need to update before regular objects, to ensure order of operations wouldn't change.

I would prefer to address this problem for all plugins, not just for the path manager.

[Gama11]

I've thought about that. It's not really a solution to the underlying issue, it just prevents conflicts with substates. You might be manipulating the elapsed value of the super.update() call, and you'd expect the timers / tweens belonging to an object to slow down / speed up appropriately (the issue with that being that timers and tweens don't really belong to an object right now of course).

I think @JoeCreates' solution was essentially to add a lazily initialized manager to FlxBasic (which we could probably do without breaking changes if still keeping the old API available). Anyway, for FlxPath, a manager is overkill, since every object can only have one at a time.

[gamedevsam]

We should probably call path.destroy(); here instead.

[Gama11]

To me, destroy() implies setting path to null and letting it be garbage-collected. Like I mentioned earlier, the user might want to restart() the path.

[gamedevsam]

There's a bug here:

if (this.path != null)
            path.object = null;

Should be:

if (this.path != null)
            this.path.object = null;

I understand your point about wanting to restart the path, I agree that we shouldn't make assumptions about how users want to handle path use / reuse, good point.

[Gama11]

Fixed.

[gamedevsam]

I approve, 👍