Skip to content

Summon fix attempt1 - #274

Open
Geronim053 wants to merge 7 commits into
Battle-Brothers-Legends:developmentfrom
Geronim053:summon_fix_attempt1
Open

Summon fix attempt1#274
Geronim053 wants to merge 7 commits into
Battle-Brothers-Legends:developmentfrom
Geronim053:summon_fix_attempt1

Conversation

@Geronim053

Copy link
Copy Markdown
Contributor

I hope the commits are somewhat self-explanatory.
-summons summoned by legend_summon_skill now belong to faction PlayerAnimals. (so they do not count to brothers for e.g. sharing GroupXP)
-Wrap to actor.nut's "isPlayerControlled()" so it additionally checks for these new playercontrolled summons that belong to the faction PlayerAnimals.
-revert former fix
Additional:
-fix to summoner not gaining share of killerXP

changes tested once; scanned for whether playercontrolled PlayerAnimals could cause problems, but all mentions of the faction PlayerAnimals and all mentions of actor.m.IsControlledByPlayer should work fine for both vanilla and legends.

to account for the fact that summons now are(/will be) in  .Faction.PlayerAnimals
=>they will still count as player controlled for the turnbar
=>they will no longer count as bros (e.g. in groupXP-distribution)

contrapoint: this might still screw with things, but in theory should be fine for e.g. vanilla-hexe-charm
line 219 might not even be necessary; summon spawn playercontrolled = true anyways.

-changing their faction by itself shouldnt do anything to player-control, but would serve us in counting actual bros (e.g. for groupXP-distribution)
that is under the assumption, that we change the isPlayerControlled()-function of actor.nut to include the PlayerAnimals-faction
-changing the entity.m.IsControlledByPlayer shouldnt interfere with anything in legends or vanilla besides the isPlayerControlled-check
forgot this, good thing I do testing
for better debugging and marginally better functionality
idk what purpose `"addXP" in summoner` served exactly. Perhaps just to avoid errors in case addXP() was called?
current solution hopefully fulfills that purpose as well. (it makes sure the actor is a player, which should have that by default)
Enemy Necromancers do not have access to this anyways, so it should be fine.
former change now unnecessary. 
I just add this as commit to my branch. If it would be easier/better to revert it on your end, reject the pull.
In that case I would submit another pr without this change
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant