Print

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

[Vayra]

TooltipMakerAPI doesn't support the same highlight-text methods (specifically highlightInLastPara() to hightlight different strings in one para in different colors) as TextPanelAPI, and it tripped me up today. Would be cool to get that in, and maybe the other related ones too.

TooltipMakerAPI.addPara returns a LabelAPI, you can add the highlights to that.

(yeah this took me a while to notice too)

Could have sworn I tried that and it overwrote the previous highlights... I'll give it another shot, thank you.

[Histidine]

OptionPanelAPI.addOption(String text, Object data, int index);
(and overloads thereof)

Currently there's no good way to add a dialog panel option anywhere but the very end.

[AxleMC131]

(Not really sure where to put this, but it's part query, part complaint and part suggestion, so I guess here will do.)

It seems that a shieldless ship returns "null" under ship.getShield(). How come "NONE" is a valid type in the ShieldAPI.ShieldType enum list then? Seemed logical to me that to check if a ship was unshielded, I should just use:

Code

if (ship.getShield().getType() == ShieldType.NONE) {...}

As you may guess, that crashed the game with a NPE upon inserting a shieldless ship into the equation. What I needed to do was use:

Code

if (ship.getShield()== null) {...}

... which works perfectly fine.

I'm not really sure what to suggest in regard to this, since I don't know what the reasons are for it being the way it is right now, but it was definitely confusing to me, especially since I'm so used to just writing "NONE" under shield type in ship_data.csv for shieldless ships. Just thought it should be noted down that it's a potential pitfall for a newbie modder and it isn't immediately obvious what should be done.

[Histidine]

MarketAPI:

• MutableStat getNetIncomeMult()

I want to be able to apply a profit tax to markets.

[Originem]

ShipEngineAPI:

• float getAngle()
• float getBaseLength()

[Sundog]

Requesting that the following methods be supported at the time of ModPlugin.onGameLoad

• Global.getSector().getCampaignUI().showConfirmDialog [CTD due to NPE]
• Global.getSector().getCampaignUI().addMessage [silent failure]

NPE stack trace:

Spoiler

848390 [Thread-4] ERROR com.fs.starfarer.combat.CombatMain  - java.lang.NullPointerException
java.lang.NullPointerException
   at com.fs.starfarer.ui.while.show(Unknown Source)
   at com.fs.starfarer.ui.impl.float.show(Unknown Source)
   at com.fs.starfarer.campaign.CampaignState.showConfirmDialog(Unknown Source)
   at com.fs.starfarer.campaign.CampaignState.showConfirmDialog(Unknown Source)
   at starship_legends.ModPlugin.onGameLoad(ModPlugin.java:50)
   at com.fs.starfarer.campaign.save.CampaignGameManager.o00000(Unknown Source)
   at com.fs.starfarer.campaign.save.CampaignGameManager.o00000(Unknown Source)
   at com.fs.starfarer.title.TitleScreenState.menuItemSelected(Unknown Source)
   at com.fs.starfarer.title.C.actionPerformed(Unknown Source)
   at com.fs.starfarer.ui.OoO0.buttonPressed(Unknown Source)
   at com.fs.starfarer.ui.oooOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO.?0000(Unknown Source)
   at com.fs.starfarer.ui.oooOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO.processInput(Unknown Source)
   at com.fs.starfarer.ui.V.super(Unknown Source)
   at com.fs.starfarer.BaseGameState.traverse(Unknown Source)
   at com.fs.state.AppDriver.begin(Unknown Source)
   at com.fs.starfarer.combat.CombatMain.main(Unknown Source)
   at com.fs.starfarer.StarfarerLauncher$1.run(Unknown Source)
   at java.lang.Thread.run(Unknown Source)

[close]

[Alex]

Hmm - this is not really possible the way things are structured. If you load a game from the title screen, the game loading code finishes and then the game transitions to the campaign state - so at the point where the loading code finishes, the UI that would show the dialog/messages/etc doesn't exist.

[Sundog]

Yeah, I figured it must be something like that. Would it cause any complications to move the invocation of onGameLoad until just after the campaign state transition? I think that (like me) a lot of people would expect campaign features to exist at that point. Alternately, could we get something like ModPlugin.onCampaignLoad?

[Alex]

Yeah, it would likely cause complications. I mean, it's *possible*, but it's for sure more chance of breaking things in an obscure way than I want to risk at this point, if that makes sense - too much chance of me missing some kind of possible state transition.

For your specific case, would adding a campaign script that waits a few frames before running work? That's... more or less what I'd end up doing anyway, if I were to add something like an onCampaignLoad() method.

[Sundog]

That's how LazyWizard did it for Version Checker, but in my case that won't work well. I'm trying to set things up so I can let players know about errors in a more useful way. One of the types of errors I'm most concerned with are json read errors that may happen if a user (or another mod) introduces a syntax error into any of the files my mods read on game load. Waiting to read those files could easily cause instability. It shouldn't be too much trouble to delay the error message though, so no biggie. I was just hoping it would be an easy fix.

[Alex]

Right, gotcha.

[Vayra]

Any chance we could get a MutableShipStatsAPI.get<SIZE>WeaponRangeBonus, i.e. MutableShipStatsAPI.getSmallWeaponRangeBonus? 

There are a couple things where you can only tweak certain weapons by type, and others by size, and some by PD tag or projectile/beam, etc. and I bumped into this one recently.

EDIT: Or alternatively/maybe even better, something to modify individual weapon ranges on WeaponAPI or WeaponSpecAPI?

[AxleMC131]

Any chance we could get a MutableShipStatsAPI.get<SIZE>WeaponRangeBonus, i.e. MutableShipStatsAPI.getSmallWeaponRangeBonus? 

There are a couple things where you can only tweak certain weapons by type, and others by size, and some by PD tag or projectile/beam, etc. and I bumped into this one recently.

What if you want to start mixing weapon size and weapon type stat changes though? I feel like this would get clunky very fast. I love the flexibility that stats affecting certain sizes gives, but imagine having all the mutable stats a weapon can take multiplied by three for the different weapon sizes.

I suggest a potential extension of Vayra's request: for weapon-affecting stats that are applied to a whole ship (such as, say, weapon range), the stat change method ".get_WeaponRangeBonus()" could have an optional field before the modifier method that allows you to specify a size - either as an enum "SMALL / MEDIUM / LARGE", or just an integer from 0 to 2. So, to give a range buff to all of a ship's small-sized ballistic weapons, you could do this:

Code

...
stats.getBallisticWeaponRange(WeaponSize.SMALL).modifyPercent(id, someRangeBonus);
...

This could extend to all sorts of ship-wide, weapon-affecting stats - weapon flux cost, weapon damage, weapon rate of fire, etc. - in much the same way, keeping everything nice and tidy without MutableShipStatsAPI becoming a bit of a labyrinth (even if it already is ). Would such a setup be possible, or even sane?

[Histidine]

int FleetParamsV3.maxSize

More control over max AI fleet size, so it doesn't have to be either "config value" (i.e. 30) or "unlimited" (which with a sufficiently large fleet can lead to the bad old days of having to kill 100 frigates).

[Nicke535]

A method, of some sort, to adjust built-in weapons on a ship post-generation. Ideally, it would work in one of two ways: either ShipAPI.getVariant().addWeapon() would allow built-in weapon slots to be modified (which might not be ideal, or even possible), or some similar hook specifically for modifying built-in weapons could be added. This second hook could either be something similar to how built-in fighters can currently be modified (via list reference modification):

Code

java
ShipAPI.getHullSpec().getBuiltInWeapons(); /* Returns a List<Pair<String, String>>, with first element being weapon slot ID and second being weapon spec ID */

This has the added benefit of matching the existing getBuiltInFighters() and getBuiltInHullmods() functions. Or, if it's for some reason preferable, an entirely different endpoint could be used. Something like this:

Code

java
ShipAPI.getVariant().addBuiltinWeaponOverride(String slotID, String newWeaponID) /* Adds an override, making the variant replace the hullspec's built-in weapon */
ShipAPI.getVariant().removeBuiltinWeaponOverride(String slotID) /* Removes an override, giving control back to the hullspec */

Either of these solutions (or an equivalent solution) would allow for some more interesting weapons and hullmods to be coded, without messing with the autofit or fleetmember instantiators (which current attempts at "semi-builtin" weapons do), and several modders have already expressed desire to use the functionality this would allow.


Also, unrelated for the suggestion but related to the thread: the OP seems to be outdated, as several of its entries that now exist in the game are not marked as such.