Print

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

[Alex]

Hmm. I want to say this was intentional, but I'm having a hard time remembering why. Maybe I just wasn't thinking of the "faction with lots, but not all no_bp_drop items". Let me change it so those don't go in the picker, that really does seem to make more sense. Done.

[Tartiflette]

Tiny one, but ammofeed uses modify.mult for increase and modify.percent for a reduction.

Code: java

public void apply(MutableShipStatsAPI stats, String id, State state, float effectLevel) {
		
		float mult = 1f + ROF_BONUS * effectLevel;
		stats.getBallisticRoFMult().modifyMult(id, mult);
		stats.getBallisticWeaponFluxCostMod().modifyPercent(id, -FLUX_REDUCTION);
	}

While the former is consistent with the system's description, the latter is puzzling.

[Alex]

Huh, odd - fixed. Thank you!

[Yunru]

I'm not sure if this counts, as it depends on your intentions:
the float DMOD_EFFECT_MULT is set up in the DMod's classes such that it can be any float, but in SafetyProcedures it's called as a final so it can't be modified.

Obviously not an issue if it wasn't intended to be accessible, but with the way it's accessed it looks like it was intended to be open to modification.

[Alex]

Hmm, yeah - this thread, and subforum, is for things that are bugs - that is, things that cause problems in the game and make things not work right. What you're talking about - while valid - is more of a modding-related request. I have been going through and removing "final" modifiers in things as I see them, though; mostly they just get in the way.

[Tartiflette]

Sorry for the Necromancy trick but this fits here I believe:
ShipAPI.getVariant().getNonBuiltInWings() returns an empty list on ships that have both built-in and non built-in wings

[Alex]

No worries, that's what the thread is for!

Hmm, yeah, looks like you're right; fixed this up. Thank you. (The problem was it was skipping over built-in wings but not incrementing the counter that indicated when it got to the non-built in ones, so it just always skipped over everything...)

[HySOqvs0sB8]

Hello,

I was running a profiling with Java Mission Control on the game, and something struck my eye in the method profiling page: 




CombatState.traverse() looked like a hot method that did not compile for some reason. Just to be sure, I ran a few more battles, but it still didn't compile.

Now, I have a good guess for what the cause could be. The Hotspot JVMs have a "huge method limit", basically anything above limit will never be compiled. The limit is 8000 bytes of bytecode instructions, and the CombatState.traverse() method is just above it with 8250 bytes, according to the classfile.

A fix would be straightforward, just refactor the method into smaller methods, and see what happens.

[Alex]

Thank you for the info! Hmm. I kind of doubt that this method (while lengthy) is doing heavy-enough things where trying to optimize it would make a difference. Most importantly, nothing in there should scale with he number of entities in the game/on screen/and so on - it's just a static cost.

Let me move a few things out into other methods, though - might get it under the 8k limit, and I suppose it wouldn't hurt. It's a painful method to refactor, though, because there's a lot of local variables that get used throughout.

[HySOqvs0sB8]

I looked at the com.fs.starfarer.ui.v.updateCopyIfNeeded() method, and it seems that the boolean flag should be set back to false there.

[Alex]

Hmm, I think you're right - thanks! "Fixing" this could cause some unintended behaviors, though, so I'll need to keep an eye on it. Did you notice this being an issue in the profiler or some such? UI stuff generally isn't so that'd be surprising.

[HySOqvs0sB8]

I'm using Java Flight Recorder with Mission Control to profile a mod, and the method showed up as a noticeably sized allocation event(50MB per minute) during battles. From the name I was wondering when the copy was needed, and I figured the answer should not be "always".

I recommend you to try out Flight Recorder if you haven't already, it is very powerful out of the box, and once you start using custom events, you can profile almost anything, and for very low overhead.

[Alex]

Ah, gotcha - thanks for the details! I'll make a note to look at it at some point...

[SafariJohn]

This transponder check in MarketCMD.bombardMenu() causes the hostility warning to not show when the transponder is off, even though that is when it is most relevant.

Code: java

if (!hostile) {
	if (tOn) {
		info.addPara(Misc.ucFirst(faction.getDisplayNameWithArticle()) + " " + is + 
				" not currently hostile. A bombardment is a major enough hostile action that it can't be concealed, " +
				"regardless of transponder status.",
				initPad, faction.getBaseUIColor(), faction.getDisplayNameWithArticleWithoutArticle());
	}
	initPad = opad;
}

[Alex]

Thank you! Fixed.