Skip to content

Fix !sandbox clean breaking factions when removing founder#147

Merged
Jimmacle merged 9 commits intoTorchAPI:masterfrom
LordTylus:master
Apr 22, 2020
Merged

Fix !sandbox clean breaking factions when removing founder#147
Jimmacle merged 9 commits intoTorchAPI:masterfrom
LordTylus:master

Conversation

@LordTylus
Copy link
Copy Markdown
Contributor

I have received instances where my RespawnFix Plugin failed due to an NRE when calling faction.Members.Keys

faction was protected by a NULL check so could not be NULL however. Calling Members creates a new Dictionary Reader which seems to cross reference the Known identities.

In the Dictionary that holds the members there ALWAYS is the ID of the founder added to the ctor. In the world that was provided to me there were factions without founder. And all of these factions caused an NRE when being worked with.

Interestingly the FounderID was still in the safe file but since its Identity was no longer there cross referencing the ID failed.

I verified that when doing !sandbox clean while I was a member of a faction I stayed member even if the founder was deleted. Which effectively broke the Faction.

Replacing faction.KickMember with the VST Call has the following advantages:

  • Kicks the given Member from the faction
  • Promotes the next Leader to Founder if Founder was Kicked, Or Member to Founder if no leader can be promoted
  • Removes the faction after the last member was kicked.

Theoretically with that the check for empty factions is no longer necessary however I left that code in as there may still be some old broken worlds out there.

…nd improved it a little to deal with offline players as well.
Main Advantage over faction.KickMember is that KickMember is only used for actually kicking members.

If the founder is kicked the next player in line wont be promoted. There are isntances where the identityID of the founder was still in the safe file, but the identity itself was deleted. causing internal NREs on faction.Members.Keys as the founder ID will always be in the members list.

But without identity building the DictionaryReader fails internally as it doesnt like NULL
@LordTylus
Copy link
Copy Markdown
Contributor Author

Also I should have recreated my fork instead of merging upstream master to my fork as the other commits are already merged to Essentials...

Welp will know for next time :-)

@Jimmacle Jimmacle merged commit 1f82b65 into TorchAPI:master Apr 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants