Print

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

[Alex]

@celestis: I'm a bit hesitant to do that b/c it'll break backwards compatibility pretty badly. (I realize this probably sounds a bit funny given that 0.65a broke everything, but...)

Would it be possible to have the FleetEncounterContextPlugin overridable like the other Plugin types please? 

Presumably this would also require BattleAutoresolverPluginImpl and FleetInteractionDialogPluginImpl to call a factory method to get their instances of the FleetEncounterContext (or overriding plugin) rather than just newing a concrete instance.

(I'm trying to change what happens immediately after a battle, without changing any of the other stuff.)

Hmm. FleetEncounterContext isn't something the core of the game is aware of, it's *only* used from code that's already moddable. Basically, it's an implementation detail of FIDPI and BAPI. FleetEncounterContext has many methods that both FIDPI and BAPI use that are not in the plugin interface, b/c the core doesn't need to be aware of them.

(Have you looked at CampaignEnginePlugin.reportBattleOccurred()? Guessing you have and it's enough for what you want, but wanted to mention it just in case. Otherwise, you'd probably want to provide custom implementations of the fleet encounter dialog and the battle autoresolver.)

[Darloth]

I eventually did notice that FleetEncounterContext actually had a LOT more going on than its corresponding Plugin, yes.

reportBattleOccurred (part of the CampaignEventListener system, not the CampaignPlugin? I'm not sure what CampaignEnginePlugin is, is that new?) doesn't seem to have any hooks into the respective cargo of the fleets before it gets discarded after a battle.

At the moment I can get what I want by copy-pasting the entirety of FIDPI and BAPI and changing one line in each, so I'm doing that, but it feels... well, wrong

(Specifically, I'm changing them to have

Code

FleetEncounterContext context = new PersistantDebrisFleetEncounterContext();

which is a subclass with slightly expanded autoLoot and afterBattleBlah calls.)

That's why I hoped they'd call out to a factory class instead, and why I wanted FleetEncounterContext to be more moddable.  I'm aware it is completely moddable right now, but because it's only used as a private instance variable in both cases, you can't change it without also changing FIDPI and BAPI, so I suppose that's my request, I'd like to be able to change it separately without all this copy-pasting.  Any ideas?

Edit: It's not that copying FIDPI and BAPI isn't working, it's just going to be bad for inter-mod compatibility unless I provide instructions on how anyone else modifying FIDPI and/or BAPI can selectively use my new FleetEncounterContext subclass, which on second thought is an amazing position to be in, and I commend you on your mod structure that my only REAL complaint is "I'm changing something really deep in the implementation code, could it please be easier for other mods to automatically pick that up". I know I've mentioned it before, but you really deserve praise for your game+engine's moddability, it is the best.

Edit2: Looting doesn't remove stuff from the cargo in question... *bleeeeeerrrrgh*
Edit3!: CargoAPI.getStacksCopy() isn't guaranteed to actually be a -separate- copy of every stack... double*blergh*

[Talkie Toaster]

Hmm. FleetEncounterContext isn't something the core of the game is aware of, it's *only* used from code that's already moddable. Basically, it's an implementation detail of FIDPI and BAPI. FleetEncounterContext has many methods that both FIDPI and BAPI use that are not in the plugin interface, b/c the core doesn't need to be aware of them.

(Have you looked at CampaignEnginePlugin.reportBattleOccurred()? Guessing you have and it's enough for what you want, but wanted to mention it just in case. Otherwise, you'd probably want to provide custom implementations of the fleet encounter dialog and the battle autoresolver.)

It would be convenient to have. I haven't had a chance to look at the new combat dialogues but in the last version I got stumped trying to write custom encounters with a few minor alterations to them. As it stood, I ended up having to duplicate a lot of code. That's certainly a solution, but it's not a great one for compatibility and whilst it might not technically need to be core it's something that's going to be wanted for a lot of mods (and even for core potentially if/when we get stuff like dialogue-triggered missions during escort runs or whatever).
Though I may just be confused here as I gave up a few months ago.

[Alex]

reportBattleOccurred (part of the CampaignEventListener system, not the CampaignPlugin?

CampaignEventListener, I misspoke.

That's why I hoped they'd call out to a factory class instead, and why I wanted FleetEncounterContext to be more moddable.  I'm aware it is completely moddable right now, but because it's only used as a private instance variable in both cases, you can't change it without also changing FIDPI and BAPI, so I suppose that's my request, I'd like to be able to change it separately without all this copy-pasting.  Any ideas?

No ideas, unfortunately - copy/pasting seems to be the only way to go here. Which is hardly ideal, of course.

Edit: It's not that copying FIDPI and BAPI isn't working, it's just going to be bad for inter-mod compatibility unless I provide instructions on how anyone else modifying FIDPI and/or BAPI can selectively use my new FleetEncounterContext subclass,

Also @Talkie Toaster:

Yeah, I get what you're saying. The thing is if I do this, it kind of feels like making FIDPI etc part of the API rather than part of the implementation. Where would this config go? Into settings.json? Into a picker method in ModPlugin? It doesn't belong in either of those places because FIDPI is just an implementation detail... plus this would involve extracting another interface out of FleetEncounterContext, which would involve rather more thought than I really want to give it - it's nice to be able to say "this is an implementation class, let's just make it work" instead of "let's make it generic and extensible". It's especially convenient for classes that have the potential to mutate a whole lot down the line.

Edit2: Looting doesn't remove stuff from the cargo in question... *bleeeeeerrrrgh*
Edit3!: CargoAPI.getStacksCopy() isn't guaranteed to actually be a -separate- copy of every stack... double*blergh*

It returns a shallow copy of the stacks ArrayList.

[Talkie Toaster]

Edit: It's not that copying FIDPI and BAPI isn't working, it's just going to be bad for inter-mod compatibility unless I provide instructions on how anyone else modifying FIDPI and/or BAPI can selectively use my new FleetEncounterContext subclass,

Also @Talkie Toaster:

Yeah, I get what you're saying. The thing is if I do this, it kind of feels like making FIDPI etc part of the API rather than part of the implementation. Where would this config go? Into settings.json? Into a picker method in ModPlugin? It doesn't belong in either of those places because FIDPI is just an implementation detail... plus this would involve extracting another interface out of FleetEncounterContext, which would involve rather more thought than I really want to give it - it's nice to be able to say "this is an implementation class, let's just make it work" instead of "let's make it generic and extensible". It's especially convenient for classes that have the potential to mutate a whole lot down the line.

That seems fair enough; making the functions in the implementation public so we can extend it, rather than just copying it, would be nice instead?

[LazyWizard]

CombatEngineAPI:

• boolean isUIShowingMap()
• float getUIFadeAmount()

These are needed to have custom HUD elements that perfectly match vanilla. The vanilla UI fades out when you enter the map tab, and it's jarring when custom elements don't.

[Darloth]

That seems fair enough; making the functions in the implementation public so we can extend it, rather than just copying it, would be nice instead?

Hmm, yes, this.

If you make everything in FIDPI and BAPI public, I think the problem mostly goes away - we can override only the functions we need, and even better if we only want to add stuff we can override it to be almost a tail call like:

Code: java

@override
public SomethingAPI IUsedToBePrivate(FleetContextThing thing)
{
    SomethingAPI firstReturn = super.IUsedToBePrivate(thing);
    return myNewMethod(thing, firstReturn);
}

That would be great, because then anyone who can see our source can -easily- integrate the mod just by calling that method.  Which we should also make public, of course.

Basically I think modders (and you when it comes to Impl classes) shouldn't be too worried about encapsulation given that people might very well want to mess with the internals.  Maybe just Protected would be good enough, I haven't given it a huge amount of thought, but either would be a great easing of the difficulty in changing what happens in these Impl classes at the moment!

[celestis]

I have a suggestion to extend WeaponAPI.WeaponType enum, so that modders can restrict some slots to be fitted with only particular weapon class. Probably named CUSTOM_1, 2, etc. Currently we have hardcoded ENERGY/MISSILE/BALLISTIC/UNIVERSAL as weapon types, which may be still be not enough.
I mean, what if your ship has a special "utility" weapon slot, which should not allow conventional weapons, but it is still not a SYSTEM slot (can be fitted with several weapons of some "mod-specific" class)? It will be easy to implement if you just add a couple of additional values to enum and a bit of code to ship fit code - I suppose this is not very difficuly?

[Tartiflette]

In that case better why not makes it work both ways and have "UNIVERSAL" weapons that can be mounted anywhere... Like support modules, drones launchers or external hull-mods that occupy a weapon slot instead of costing OP.

[celestis]

Tartiflette, not exactly. It will not solve the problem that I don't want any OTHER weapons be mounted there.
Here is the example of what it is needed for:
Assume we have a support ship.
Apart from that let it be designed for 3 purposes:
- generic fire support (any common weapon) - slot 1
- aid friendly ships (for which we have for example: armor repairer or hull repairer weapons) - slot 2
- electronic warfare of some kind (for example: jammer or tracking disruptor or target painter weapons) - slot 3
So, here on the ship we have 3 groups of slots, which are not compatible with each other. Neither we can fit the common weapon to EWar slot nor EWar weapon to aid slot.
Currently such combination is not possible. But it can be made pretty easy if slots (weapon groups) 2 and 3 have different enum value (CUSTOM_1 and CUSTOM_2). This was just an example from the mod I'm developing, but I suppose other modders will benefit from such change too (allow only weapons of particular faction, for example).
Solution with enum may seem not very "neat" because we still will limit the number of such groups (not more than entries in enum), but I don't think people will need more than 10 or so...

P.S. Damn, I forgot that this thread is only about existing features. My bad. Shall I delete posts from this thread and move to separate one?

[Tartiflette]

I very well understood what you wanted, but I was proposing to also allow weapon types that can be mounted in more than one type of weapon mount.

[Debido]

void FluxTrackerAPI.stopVenting() for times when you need to stop a multiship UNICHILD type segment stop venting when the ROOT or CHILDHOST segment is NOT venting.

[celestis]

I've got two suggestions.
1.
Extend com.fs.starfarer.api.combat.ShipEngineControllerAPI.ShipEngineAPI with the method
void enable() which will (obviously) enable the disabled engine.
OR
void setDisabledTime(float time) to modify the time directly with possibility to set it to zero

2.
extend BeamEffectPlugin interface to have methods related to hit start and hit end:
void hitStart(BeamAPI beam)
void hitEnd(BeamAPI beam)
which should be executed once when the beam is hitting a new target and once it is no longer hitting previous target, respectively.
The reason that it would help a lot in making some weapons affect target stats: first method can apply stats and the second - unapply. Currently this needs some cludges to be implemented, since the advance() method is the only thing the interface has.

[silentstormpt]

JSONArray   SettingsAPI.loadJSON(java.lang.String filename)

Right now we can only get a JSONObject formatted json but it should be possible to get JSONArray formatted json. Just need that constructor added in there.

[Debido]

WeaponAPI
boolean isInterruptibleBurst() <-- certain conditional statements that cannot catch weapons such as thumper/storm needler.

Also as an aside IF it is at all possible
void interruptWeapon() <- to interrupt a weapon mid-fire in much the same way that flux venting will interrupt a weapon firing. I'm not sure how you interrupt weapons when venting, but THAT method that you use there.