Hello @for_reason,

I am unable to reproduce this issue on the current stable version of 1.8.0.13. May you plese share the exact steps you took? Perhaps a video demonstrating a minimal setup?

I opened a fresh GM Arland. Added US as playable faction. Then after clicking on the faction used the quick action in the middle to place a spawn point for us. I then manually added a second spawn point by going into the entity browser and looking for the US one there. I then entered the spawn menu and saw both are available, spawned and saved. Then loaded the save, killed my character, and when in respawn menu both were available to me. When clicking on the properties for them, both show as spawning enabled after loading a save. When snapping them to ground after save, no duplication seems to take place.

The number is not a magic constant from gamecode. It is all configured by the base game config setup. If you want to overrule something you look up the configuration it currently matches under (persistence diag menu shows you the GUID of the rule you can search for in the top left of config viewer) and there you will see the rule type and priority it is assinged.

In general first priority is checked, no matter what rule type. higher number wins. some vanilal rules have higher than 30k by default. set your test to 9999999 or something to be sure nothing is higher. if two rules have the same prio then prefab wins over component that wins over entity class filter. if they are still the same type they are compared by the individual filter as a final tie breaker. if that is the same the order in which the rules are declared in the config wins.

When requesting an already existing instance like that it should fail with bad request at that point, and not continue for ever - unless your outer call logic then re-attempts it. Maybe you can prepare a small repro code snippet like I did to show us the problem.

Hello,

We are unable to reproduce this issue. Can you please give some more details and especially a logfile created using CLI params -loglevel spam -persistence dig so we can see what exactly is spamming? The spawn request collects all known IDs and emits result callbacks for them immediately before sending a query to fetch additional data if there were not explicit includes given.

There may be a potential issue when sending an unconditional query into a collection, attempting to respawn instances already loaded, but this does not seem to fit the description of your issue.

This is what we tried:

class PersistenceRepro
{
	static void Do()
	{
		auto persistence = PersistenceSystem.GetInstance();

		PersistenceSpawnRequest request();
		request.Collection = persistence.FindCollection("Character");
		request.Include = {"01a018a9-d796-8886-8400-000000055a6e"};
		
		persistence.RequestSpawn(request, new PersistenceResultCallback(ReproCallback));
	}

	static void ReproCallback(EPersistenceStatusCode statusCode, Managed result, bool isLast)
	{
		PrintFormat("Callback invoked: %1, %2, %3", statusCode, result, isLast);
	}
}

While there are some edge cases that we are fixing, in general, adding new rules with higher priority should work. Perhaps you had existing save data locally while making the changes? Once registered, an instance remembers which configuration it was created with and keeps it over its lifetime. So if you want to test rule changes, you should first clear local data between runs.