Sabre insanity, also known as one proc adjustment that might possibly fix stuff (now includes ~300% more proc adjustments)

[DeltaFire15]

About The Pull Request

There is some bug going on with miner sabres sometimes getting nullspaced and I spent hours without finding out why. The one part of the entire proc chain that is basically always questionable is the weird ships[] list so I passed some better values for now and we'll see if that fixes it.
TM this please. We'll see if someone gets nullspaced with this and if someone does I go back to the mines.

Attendum

Did some more diving. Found one very specific edge case where a ship with a reserved z that docks somewhere can potentially send other ships in system who-knows-where.
Rewrote some of the remove_ship() code to hopefully make those cases less unsafe and applied it to cases where remove_ship is used to remove a ship from the overmap entirely as opposed to FTL-related things mostly.
Also made deletion of ships remove them from the system after all else is done, which should only impact situations where a z carrier ship is deleted.

Might be a bit more volatile now. Please look over this PR before updating its testmerge & make sure I'm not doing something weird. (I've not seen anything weird in my tests but better safe than sorry)

Why It's Good For The Game

Fix man good.

Changelog

🆑
fix: Possibly fixes some weird Sabre behavior.
fix: Also makes one single gun check of the plasma caster slightly safer.
fix: Fixes a weird edge case with docking behavior.
fix: Fixes remove_ship() assuming all remove_ship() calls were FTL based.
fix: Overmap objects when deleting have remove_ship() called for them (this should mostly only affect z carriers which drop their z or pass it to another ship).
fix: Overmap objects that are deleted now drop their current_system var.
/:cl:

[DeltaFire15]

Of course this PR has 666 in its number..

[Bokkiewokkie]

Fine hotfix, but since we don't know the exact cause and regarding all of the comments you left, do you want to keep this testmerged until we find the issue? Otherwise I'd like for you to move your comments to a new issue instead so someone else can potentially look at it instead.

[DeltaFire15]

do you want to keep this testmerged until we find the issue? Otherwise I'd like for you to move your comments to a new issue instead so someone else can potentially look at it instead.

Essentially, this might resolve it or it might not. It's the only place I found that looked potentially volatile, and I wasn't able to reproduce how to trigger the issue in the first place, despite someone managing to trigger it in the first system without having jumped. It also didn't cause a runtime during the time I helped someone out on the server.

If it doesn't happen again, this was probably it, if it does, I'll have to check vars again and question them aswell so I can have some different occurances to compare.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[DeltaFire15]

Found another issue, did a bit of rewriting things that might resolve even more or might brick some edge case if I forgot something.
(Appears to work properly in testing but you know how it is)

[DeltaFire15]

I think this has been working? Not heard of any miners getting sent to nullspace or things going wrong that would be caused by this. Probably good to merge.

[Bokkiewokkie]

I think this has been working? Not heard of any miners getting sent to nullspace or things going wrong that would be caused by this. Probably good to merge.

Let's do that then, it looks good to me