Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Alex]

Ah, yeah, if you're doing this in the refit screen, I can see how there'd be problems with it not refreshing. I was thinking of if it was applied with code at some other point.

[presidentmattdamon]

Ah, yeah, if you're doing this in the refit screen, I can see how there'd be problems with it not refreshing. I was thinking of if it was applied with code at some other point.

It's applied in a dialog, not in the refit screen. The issue is that you need to interact with the refit screen by installing any random hullmod or switching to/from another ship for the changed OP to actually take effect before you can modify the ship to take advantage of it.

[Alex]

Hmm - make sure you're doing addListener() inside applyEffectsBeforeShipCreation, and that your hullmod overrides the affectsOPCosts() method and has it return true. (Edit: if neither one is the problem here, I'll be preeeetty confused...)

[presidentmattdamon]

Hmm - make sure you're doing addListener() inside applyEffectsBeforeShipCreation, and that your hullmod overrides the affectsOPCosts() method and has it return true. (Edit: if neither one is the problem here, I'll be preeeetty confused...)

so the Listener is supposed to be applied to the stats object and not the ship? maybe that would explain it, actually.

edit: sorry, looked at the wrong one. the listener is applied in applyEffectsBeforeShipCreation, and the hullmod returns true in affectsOPCosts

[Alex]

Right! Per the javadoc:

Only applies when added to MutableShipStatsAPI, not to ShipAPI or the combat engine.

[presidentmattdamon]

Right! Per the javadoc:

Only applies when added to MutableShipStatsAPI, not to ShipAPI or the combat engine.

sorry, posted before i looked at what the code was doing. the listener is applied to the Stats object in applyEffectsBeforeShipCreation, and the hullmod returns true in affectsOPCosts.

[Alex]

I just tried it and it works for me. That is, I built in a permaMod that affects OP this way with code on a button press, and the OP changes are reflected immediately upon opening the refit screen.

One other key point - and this applies to any other ship variant manipulation with code - is if you're going to change a variant, and its .getSource() != VariantSource.REFIT, you need to clone the variant and set the fleet member's variant to the cloned version of it. You can search FleetEncounterContext for .clone() to see an example of code doing that.

[Timid]

It'll fire the rule with more matching conditions, so if one of them has more than just $option == <id>, then that might be it. Otherwise - if both of the rules have the same number of conditions and they all match - it should be 50%.

It doesn't discriminate on what type of conditions right? Like if
option1 has $option == <id>,$alwaystrue,$alwaystrue as opposed to
option2 has $option == <id>,$alwaystrue3,$alwaystrue4

would have the same 50%?

[Alex]

Right.

Just for general information, you can append " score:<number>" (without the quotes) to the end of a condition to set its score; the default score is 1. So in your example they'd both have score 3.

But if you did:
$option == <id> score:2
$alwaystrue
$alwaystrue

Then that would have score 4.

[presidentmattdamon]

I just tried it and it works for me. That is, I built in a permaMod that affects OP this way with code on a button press, and the OP changes are reflected immediately upon opening the refit screen.

One other key point - and this applies to any other ship variant manipulation with code - is if you're going to change a variant, and its .getSource() != VariantSource.REFIT, you need to clone the variant and set the fleet member's variant to the cloned version of it. You can search FleetEncounterContext for .clone() to see an example of code doing that.

i'm using a BuffManager to apply the hullmod (which is probably now a less-than-efficient way of doing it)

the code that applies the variant is like so

Code

			if(shipVariant.isStockVariant()) {
				shipVariant = shipVariant.clone();
				shipVariant.setSource(VariantSource.REFIT);
				member.setVariant(shipVariant, false, false);
			}

inside of a BuffManager that is applied to a FleetMember in dialog. after this, the BuffManager applies the hullmod, and finally FleetMemberAPI.updateStats is called

i'll add a check for the source to apply the cloned variant if the source isn't refit, but otherwise i think i'm doing the same thing as you. the only thing i could think of is you may be using a dev version where this single oddity is already fixed.

edit:

here's my investigation after adding the check.

this picture shows off the dialog-applied hullmod
https://i.imgur.com/66V6kWu.png

this picture shows off the ship's OP after applying the hullmod, with the ballistic weapons in frame.
https://i.imgur.com/IJlQEOt.png

this picture shows off the fleet refit screen, where it shows the free OP that the ship should have.
https://i.imgur.com/gnc0FdM.png

additionally, and this is a bug i hadn't noticed before, when closing and reopening the refit dialog for that specific ship, the free OP disappears as well, and it appears i was mistaken about the OP appearing if you install something on the ship. it only appears if you switch what ship you are looking at.

looking at the logs, it appears the WeaponOPCostListener is called very often, much more often than applyEffectsBeforeShipCreation is, which is called twice because of the affectsOpCosts method returning true in the hullmod

[Timid]

Right.

Just for general information, you can append " score:<number>" (without the quotes) to the end of a condition to set its score; the default score is 1. So in your example they'd both have score 3.

But if you did:
$option == <id> score:2
$alwaystrue
$alwaystrue

Then that would have score 4.

Thanks!

[Alex]

@presidentmattdamon: hmm, that's weird. I don't remember changing anything related. This could actually be related to doing this in a BuffManager, so I'd suggest trying it just as code in response to a dialog option being selected or something.

looking at the logs, it appears the WeaponOPCostListener is called very often, much more often than applyEffectsBeforeShipCreation is, which is called twice because of the affectsOpCosts method returning true in the hullmod

It would be, yeah, since it's called for each weapon.

[presidentmattdamon]

@presidentmattdamon: hmm, that's weird. I don't remember changing anything related. This could actually be related to doing this in a BuffManager, so I'd suggest trying it just as code in response to a dialog option being selected or something.

looking at the logs, it appears the WeaponOPCostListener is called very often, much more often than applyEffectsBeforeShipCreation is, which is called twice because of the affectsOpCosts method returning true in the hullmod

It would be, yeah, since it's called for each weapon.

i'll set up a way that works withouta buff manager. i've done some more investigation and i have this:
a stats object that doesn't match a single fleet member in my fleet!

Code

681977 [Thread-3] INFO  extrasystemreloaded.hullmods.ExtraSystemHM  - [ExtraSystemsHM] applyEffectsBeforeShipCreation
681977 [Thread-3] INFO  extrasystemreloaded.hullmods.ExtraSystemHM  - [ExtraSystemsHM] stats getEntity null getFleetMember null
681977 [Thread-3] INFO  extrasystemreloaded.hullmods.ExtraSystemHM  - [ExtraSystemsHM] could not find a fleet member for this stats object!

681978 [Thread-3] INFO  extrasystemreloaded.hullmods.ExtraSystemHM  - [ExtraSystemsHM] applyEffectsBeforeShipCreation
681978 [Thread-3] INFO  extrasystemreloaded.hullmods.ExtraSystemHM  - [ExtraSystemsHM] stats getEntity eagle_Balanced null [eagle] getFleetMember Balanced,Eagle, owner: 0, name: PLS Blueshift
681978 [Thread-3] INFO  extrasystemreloaded.hullmods.ExtraSystemHM  - [ExtraSystemsHM] found fleet member Balanced,Eagle, owner: 0, name: PLS Blueshift
681978 [Thread-3] INFO  extrasystemreloaded.hullmods.ExtraSystemHM  - [ExtraSystemsHM] FleetMember has augment Spooled Ammo Feeders installed
681978 [Thread-3] INFO  extrasystemreloaded.hullmods.ExtraSystemHM  - [SpooledFeeders] applying upgrades before ship creation to stats
681978 [Thread-3] INFO  extrasystemreloaded.hullmods.ExtraSystemHM  - [SpooledFeeders] stats did not have a spooled feeder listener!

i'd like to continue by saying that sometimes this isn't an issue:

Code

681965 [Thread-3] INFO  extrasystemreloaded.hullmods.ExtraSystemHM  - [ExtraSystemsHM] applyEffectsBeforeShipCreation
681965 [Thread-3] INFO  extrasystemreloaded.hullmods.ExtraSystemHM  - [ExtraSystemsHM] stats getEntity null getFleetMember null
681965 [Thread-3] INFO  extrasystemreloaded.hullmods.ExtraSystemHM  - [ExtraSystemsHM] found fleet member Balanced,Eagle, owner: 0, name: PLS Blueshift
681965 [Thread-3] INFO  extrasystemreloaded.hullmods.ExtraSystemHM  - [ExtraSystemsHM] FleetMember has augment Spooled Ammo Feeders installed

so this one must not be attached to any single FleetMember at all, whether by calling fm.getStats, variant.getStatsForOpCosts, stats.getEntity or stats.getFleetMember

[Alex]

This seems normal, stats are recomputed from scratch all the time - any time you open the fleet screen, make a change to a fleet member, etc.

[presidentmattdamon]

This seems normal, stats are recomputed from scratch all the time - any time you open the fleet screen, make a change to a fleet member, etc.

why wouldn't the stats object be attached to the fleet member in that case though?