[Bug] Possible regression with @EntityId on IntBag

[DaanVanYperen]

@junkdog Another one after running the debugger ;)

Observed @EntityId with CHECK_SOURCE_AND_TARGETS cleans up deleted entities from ints and IntBags, but only on EntityLinkManager proces.
Expected @EntityId with CHECK_SOURCE_AND_TARGETS cleans up deleted entities, each time a system finishes processing.

Is this a regression or is it intended? What use is CHECK_SOURCE?

Tests for reproducing the above:
https://gist.github.com/DaanVanYperen/507888e83d9b1ff9d35810f671595360

[junkdog]

I'll take a closer look tomorrow, but I think it's intentional. IIrc - only clean-up/callback when entity has been purged by the EntityManager, otherwise entities may be evicted prematurely (ie; "some" time before EntiySubcriptions have fired)

[DaanVanYperen]

Purges are after each system invocation right? System1->purge->System2->etc.

Maybe I'm doing something wrong. As it is now, when I delete a referenced entity in System1, the @EntityId annotated reference continues to dangle throughout System2..SystemN until the EntityLinkManager is invoked and it is finally cleared.

[junkdog]

Ah, sorry, purge as the final step in world.process() - ComponentManager and EntityManager purging/resetting:

	public void process() {
		invocationStrategy.process();

		IntBag pendingPurge = batchProcessor.getPendingPurge();
		if (!pendingPurge.isEmpty()) {
			cm.clean(pendingPurge);
			em.clean(pendingPurge);

			batchProcessor.purgeComponents();
		}
	}

[junkdog]

Ouch. Yeah, sounds like a bug with impl.

[DaanVanYperen]

Maybe @LinkPolicy javadoc can be clarified a bit as well. Especially how each option interacts with @EntityId.

[junkdog]

Yeah, I need to brush up on the inner workings as well... (a testament for the need for good documentation!)

[DaanVanYperen]

Delaying this one release for when we have more breaking changes (gdx 1.10 etc).