Print

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

[Alex]

Presumably because the stats got recomputed (and a new stats object created) since the point where you'd saved the reference to the previous stats object?

[presidentmattdamon]

Presumably because the stats got recomputed (and a new stats object created) since the point where you'd saved the reference to the previous stats object?

the previous stats objects in this case are the ones stored directly on the fleet members. the one i'm performing the "search" with are passed to applyEffectsBeforeShipCreation.

if a new Stats object is being created and not being set on the fleet members or their variants before the call to applyEffectsBeforeShipCreation, that would cause this issue. if that's supposed to be the case, that's okay.

edit: i've rewritten my code to not use a buff manager, and the issue was resolved. pretty weird, honestly. thanks for the help, i appreciate your patience

[King Alfonzo]

Hey Alex,

Discovered something strange, and I'm not sure of the source. I've made a weapon that has two beams, and have Converge on Point set to true like the Guardian. However, when the AI fires the beams at missiles in the simulator, they converge just slightly to the left of the missile and never hit. I've attached an image to demonstrate.

Spoiler

[close]

Is there something I'm doing wrong, or is this a vanilla based bug?

[Alex]

edit: i've rewritten my code to not use a buff manager, and the issue was resolved. pretty weird, honestly. thanks for the help, i appreciate your patience

Cool, glad you got it working! Stuff in BuffManager is applied at some point in the "update the stats for this ship" process so it's not *too* surprising that would go wrong sometimes.

Hey Alex,

Discovered something strange, and I'm not sure of the source. I've made a weapon that has two beams, and have Converge on Point set to true like the Guardian. However, when the AI fires the beams at missiles in the simulator, they converge just slightly to the left of the missile and never hit. I've attached an image to demonstrate.

...

Is there something I'm doing wrong, or is this a vanilla based bug?

Ah - looking at the code, convergesOnPoint will aim for the endpoint of the first beam, so it's not going to work with a pair of offset beams like that. The first beam "barrel" defined in the .wpn file pretty much needs to point straight down the middle for this to work.

[presidentmattdamon]

Hey Alex,

Discovered something strange, and I'm not sure of the source. I've made a weapon that has two beams, and have Converge on Point set to true like the Guardian. However, when the AI fires the beams at missiles in the simulator, they converge just slightly to the left of the missile and never hit. I've attached an image to demonstrate.

...

Is there something I'm doing wrong, or is this a vanilla based bug?

Ah - looking at the code, convergesOnPoint will aim for the endpoint of the first beam, so it's not going to work with a pair of offset beams like that. The first beam "barrel" defined in the .wpn file pretty much needs to point straight down the middle for this to work.

is it possible to have an invisible 0 damage beam as the first beam?

[Alex]

AFAIK you can't define damage or color per-beam.

[SafariJohn]

Ah - looking at the code, convergesOnPoint will aim for the endpoint of the first beam, so it's not going to work with a pair of offset beams like that. The first beam "barrel" defined in the .wpn file pretty much needs to point straight down the middle for this to work.

That seems like a bug which could be fixed by a simple offset check.

[Alex]

(It's definitely not a bug. It could probably be changed reasonably easily, though.)

[King Alfonzo]

Ah - looking at the code, convergesOnPoint will aim for the endpoint of the first beam, so it's not going to work with a pair of offset beams like that. The first beam "barrel" defined in the .wpn file pretty much needs to point straight down the middle for this to work.

Alright, thanks for that. Should be a simple fix then.

[Timid]

Is there any way for a "sub-faction" to spawn smodded variants using a Lion's Guard HQ or...? I have a Lion's Guard-like faction that I wish for it to spawn with specific smods that I've already specified inside the variants. I thought the variants saved with its smod variant would be able to work, but that didn't seem to be the case.

[presidentmattdamon]

is there any way to get an expandable tooltip for a hullmod, like press F1 for it to expand and show more?

[Histidine]

Sort of a modded-bug-report thing: Is there a smarter way to handle ShardSpawner's use of setCombatNotOverForAtLeast(time)?
Currently if a player or allied shard spawner ship appears in a battle and doesn't get disabled or retreat, the combat won't end except using devmode/console.

[Alex]

Is there any way for a "sub-faction" to spawn smodded variants using a Lion's Guard HQ or...? I have a Lion's Guard-like faction that I wish for it to spawn with specific smods that I've already specified inside the variants. I thought the variants saved with its smod variant would be able to work, but that didn't seem to be the case.

Hmm - a custom fleet inflater is always an option. To be honest, I don't remember how the default one works; a little surprised that it wouldn't keep s-mods specified in a .variant file, though.

is there any way to get an expandable tooltip for a hullmod, like press F1 for it to expand and show more?

I don't believe so, actually - looks like that's a case where there *isn't* an "isTooltipExpandable()" method for it.

Sort of a modded-bug-report thing: Is there a smarter way to handle ShardSpawner's use of setCombatNotOverForAtLeast(time)?
Currently if a player or allied shard spawner ship appears in a battle and doesn't get disabled or retreat, the combat won't end except using devmode/console.

I'm not sure I understand. setCombatNotOverForAtLeast() gets called from that hullmod's advanceInCombat() method, which will not get called if the ship is removed from combat for example via script. Between that, disabling, and retreating, what other state is there for a ship to be in where you *wouldn't* want it to prevent combat from ending?

(Incidentally, I'm surprised it works at all on the player side; wasn't really coded with that in mind at all...)

[Timid]

Hmm - a custom fleet inflater is always an option. To be honest, I don't remember how the default one works; a little surprised that it wouldn't keep s-mods specified in a .variant file, though.

In a way, it sort of does if you specified the fleet spawn to have an average of >0 smod. However, I would like one that it would ignore hullmod restriction and let me spawn "illegal" variants like a Flux Shunted Caps 

[Histidine]

I'm not sure I understand. setCombatNotOverForAtLeast() gets called from that hullmod's advanceInCombat() method, which will not get called if the ship is removed from combat for example via script. Between that, disabling, and retreating, what other state is there for a ship to be in where you *wouldn't* want it to prevent combat from ending?

(Incidentally, I'm surprised it works at all on the player side; wasn't really coded with that in mind at all...)

Well the specific issue that came up is that Nex had a way (which was disabled for other reasons) to temporarily get an Aspect in the player fleet, but using that ship results in the battle not ending after the player has won (enemies all retreated or disabled).

EDIT: Hmm, one potential fix would be to suppress the setCombatNotOverForAtLeast call if enemy has no ships deployed, and (no ships in reserve, or is in full retreat). This is what was checked for by the old mod-side fix for the "modular ships retreating prevents battle from ending" bug.