You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The AddToManagers method should not be a virtual method. Instead, it should be called in the Base class, and then all other methods can be virtual and called by the base implementation so that it can control order.
Example problem
This is in context of Screens, but this change is probably okay to make on Entities.
Currently ScreenManager calls AddToManagers on a Screen, which is a virtual method. This gets overridden by derived Screens which do their addition first, then allowing the base screen to do its addition. I'm not sure exactly why but I suppose there is probably logic that requires the derived to do this first.
The problem with this is that the AddToManagers method is where Factories call AddList. Until AddList is called, if a factory instantiates an object, that object will not get added to the list. This can result in entities being created (due to derived code being called first), and those entities not being added to their lists.
For example, consider the following situation:
GameScreen is the base class so it is responsible for Initializing factories. Level1 (inheriting from GameScreen) creates an entity such as EnemyVehicle. EnemyVehicle may include its own entities, and these entities may be initialized in EnemyVehicle CustomInitialize. Since EnemyVehicle is created in Level1, its CustomInitialize is called before the base GameScreen has a chance to initialize its factories. Any entity that EnemyVehicle creates will not be owned by the factory.
Detailed Fix
As mentioned above, AddToManagers should no longer be a virtual method. It should be a method implemented only in the base object. Then it should provide virtual methods that overrides can call.
For example, this is the current GameScreen.Generated AddToManagers:
public void AddToManagers()
{
mAccumulatedPausedTime = TimeManager.CurrentTime;
mTimeScreenWasCreated = FlatRedBall.TimeManager.CurrentTime;
GameScreenGum.AddToManagers(); FlatRedBall.FlatRedBallServices.GraphicsOptions.SizeOrOrientationChanged += RefreshLayoutInternal;
InitializeFactoriesAndSorting();
// This replaces the bulk of the method:
AddToManagersTopDown();
AddToManagersBottomUp();
BeforeCustomInitialize?.Invoke();
CustomInitialize();
}
protected virtual void InitializeFactoriesAndSorting()
{
// .....
}
protected virtual void AddToManagersTopDown()
{
// ....
}
// and so on
This problem was encountered in Cranky Chibi Cthulhu when an enemy was attempting to create another enemy in its CustomInitialize. It's a bigger issue so I'm logging this here without solving it for now, and I'm going to work around it.
The text was updated successfully, but these errors were encountered:
Summary
The AddToManagers method should not be a virtual method. Instead, it should be called in the Base class, and then all other methods can be virtual and called by the base implementation so that it can control order.
Example problem
This is in context of Screens, but this change is probably okay to make on Entities.
Currently ScreenManager calls AddToManagers on a Screen, which is a
virtual
method. This gets overridden by derived Screens which do their addition first, then allowing the base screen to do its addition. I'm not sure exactly why but I suppose there is probably logic that requires the derived to do this first.The problem with this is that the AddToManagers method is where Factories call
AddList
. UntilAddList
is called, if a factory instantiates an object, that object will not get added to the list. This can result in entities being created (due to derived code being called first), and those entities not being added to their lists.For example, consider the following situation:
GameScreen is the base class so it is responsible for Initializing factories. Level1 (inheriting from GameScreen) creates an entity such as EnemyVehicle. EnemyVehicle may include its own entities, and these entities may be initialized in EnemyVehicle
CustomInitialize
. Since EnemyVehicle is created in Level1, itsCustomInitialize
is called before the base GameScreen has a chance to initialize its factories. Any entity thatEnemyVehicle
creates will not be owned by the factory.Detailed Fix
As mentioned above, AddToManagers should no longer be a virtual method. It should be a method implemented only in the base object. Then it should provide virtual methods that overrides can call.
For example, this is the current GameScreen.Generated AddToManagers:
This should instead be like this:
This problem was encountered in Cranky Chibi Cthulhu when an enemy was attempting to create another enemy in its CustomInitialize. It's a bigger issue so I'm logging this here without solving it for now, and I'm going to work around it.
The text was updated successfully, but these errors were encountered: