Fractal Softworks Forum

Please login or register.

Login with username, password and session length

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - float

Pages: 1 [2] 3 4 ... 18
16
Newest update:
- Finally updated the hullmod icon, uses a sprite Serenitis posted in 2022: Here
- Added LunaLib support
- Added a setting to condense XP gain messages
- Changes Global.getCombatEngine() calls to CombatEngine.getInstance(), the latter of which actually creates the engine if it doesn't exist, so this should in theory fix the rare, nigh-impossible to reproduce null pointer issue.

Updated to 1.0.0 not because it's a big update, but because this mod is essentially feature-complete and I don't intend to add any additional features other than easy maintenance / bugfixes. You can still request new features, but you'll have to implement them yourself and make a pull request.

17
Modding / Re: [0.97a] Ship Mastery System (4/2/24)
« on: April 03, 2024, 03:54:13 PM »
Does the skill changes conflict with Quality Captains?
If you use Quality Captains, the skills from that mod will stick and those from this mod will be discarded (reason being, Quality Captain's id is higher alphabetically, so that mod gets loaded first, so it gets to make its skill changes first and any subsequent replacements are ignored).
This is a soft conflict, as this mod still works with Quality Captain's best of the best and cybernetic augmentation. It just means that you'll be getting an additional s-mod slot (up to 4 at max mastery) and losing the up to 12% OP bonus from this mod's cybernetic augmentation.

That said, you could try deleting the best of the best and cybernetic augmentation skill replacements in the mod_info.json of Quality Captains if you wanted to use this mod's version of those skills (haven't tested it, so not sure if it actually works).

18
Modding / [0.97a] Ship Mastery System (4/4/24)
« on: April 02, 2024, 03:10:05 PM »
Ship Mastery System
 

Gain mastery in ship hulls to unlock S-mod slots and additional bonuses. (Sort of) a spiritual successor to Progressive S-Mods.

Requires Particle Engine.


Ship Masteries

  • Gain mastery points (MP) in a specific ship type randomly while gaining XP.
    • XP gained from combat has a chance to grant MP in combat ship types in your fleet.
    • XP gained from any other source has a chance to grant MP in civilian ship types in your fleet.
  • MP can also be acquired by consuming knowledge constructs, which appear as rare loot under certain circumstances.
  • Use MP to build in hullmods or advance your mastery level in a specific ship type.
    • Each ship type (a.k.a. hull spec) has its own MP pool that is shared between all ships of that type.
    • Mastery level and mastery selections (for levels that have more than one option) are also shared between all ships of a ship type.
  • Advancing your mastery of a ship type improves its performance in a variety of ways. Some mastery levels have randomized bonuses, while others' are fixed.




Revamped S-Mod System

  • All ships start with 0 S-mod capacity. Level up ship mastery to gain S-mod capacity.
  • Each ship class has exactly 3 available S-mod capacity upgrades, available at levels 2, 4, and 6.
  • Building in hullmods no longer costs story points, instead costing mastery points (MP) and credits.




NPC Masteries

  • NPC fleets follow the same general rules as player fleets, and may have mastery levels in some ship classes.
  • Ships in an NPC fleet that have mastery effects applied will also have a marker hullmod added, so hovering over that ship will show its mastery level.
  • Adds a post-inflation sequence to add S-mods to ships in generic NPC fleets, if they've unlocked mastery levels that grant them S-mod capacity.
  • NPC fleets' average mastery levels (and other mastery-related settings) can be changed in the difficulty subsection of the settings.



Skill Changes
Best of the Best

  • Removed the additional S-mod from Best of the Best; default cap is now 3 (at max mastery) regardless of skills.
  • Added effect: +20% effectiveness of all mastery bonuses.
  • Added effect: +15% CR, +10% hull and flux capacity for capital ships with officers.


Cybernetic Augmentation

  • Removed the 1% damage dealt / damage taken bonus per commander's elite skill.
  • Added an ordnance points bonus that scales based on the number of ship types the player has mastered (bonus is fixed for NPC fleets)

[close]

Miscellaneous Features
Adds a system for reclaiming ships lost in battle

  • Player ships that are lost but not recovered, either by choice or due to disengaging early from or losing a battle, spawn as derelicts near the battle site.
  • In order to spawn as a derelict, the ship must have been recoverable should the player have won (affected by reinforced bulkheads / hull restoration / etc.).
  • If the player is given a post-battle salvage option, weapons and wings from the wrecks are stripped.
  • The wrecks disappear permanently after 365 days, or if the player dismisses the fleet log entry.
  • Greatly facilitates insurance fraud if using Nexerelin's ship insurance feature.



Adds an S-mods option to the refit screen autofit menu

  • This will attempt to copy S-mods from the goal variant, automatically spending the required credits and mastery points.


Also adds a small amount of exploration content.
[close]

Version log

19
API request: can you expose (or create a getter for) claimsHistory in InsuranceIntelV2? I’m writing something that’s susceptible to insurance fraud when combined with this mod, and would like to implement a (non-reflective) way to handle such scenarios. Thanks!

20
Modding Resources / Re: [0.97a] Particle Engine (3/3/24)
« on: March 25, 2024, 11:12:11 AM »
Awh, is there a sane way to attach an emitter to a weapon? I'm trying to make a funnel particle system which is attached to a weapon and simulates in local space, respecting both its position and rotation.
The workaround was to make a wrapper CombatEntityAPI, which returns the necessary position, but I find this mildly cursed:

Code
if (dummyWeaponEntity == null) {
            dummyWeaponEntity = new DummyWeaponEntity(weapon);
            engine.addEntity(dummyWeaponEntity);
}

/* and then just pass that entity as an anchor */
emitter.enableDynamicAnchoring();
Particles.anchorEmitter(emitter, dummyWeaponEntity);

Oh, anchorEmitter is basically just syntactic sugar, totally unnecessary. It's just setting the emitter's location to the entity's location each frame, which you can easily do manually with something that isn't a CombatEntityAPI in one of two ways:

1. In a script with an advance feature (EveryFrameCombatScript, AdvanceableListener, etc), just keep track of the emitters you have and set their locations and rotations to the respective weapons' locations and rotations each frame.
2. You can achieve the same thing via a StreamAction in Particles.stream, in particular pass an anonymous class (or a lambda in the next update, finally Java 8 language features support) into doBeforeGenerating that sets the emitters' locations and positions each frame. See the simple trail example for an emitter that does exactly this but with a projectile instead of a weapon.

21
Is over-engineered from EHM? Doesn't that mod do a bunch of really weird things like generating new hull specs for each ship? I imagine it'd have to do that if it wanted to e.g. change ship systems or individual ship OP.

I'm having a hard time imagining exactly what would cause a ship to strip all its weapons. But if EHM is doing refit screen reflection stuff, it's possible that there's some issues with syncing and saving the refit screen's variant, as that's the only time the change actually propagates to the fleet member. But that shouldn't have anything to do with opening this mod's build-in screen, which doesn't modify the variant at all except for adding and removing hull mods...

Unsure if its just this mod or some combination of other mods. But when I open the manage s mod screen and go to a multi-module ship it strips all weapon slots and fighter bays. Deleting these things in the process. Really gamebreaking.

Are you sure it strips?

I have a bug where they don't *appear" equipped on mouse-over, but the available OP shows them fully fit as does testing / using them.  This usually goes away if I switch from one ship to another in refit screen. 
What do you mean they don't appear equipped on mouse-over? Is this the left hand side of the refit screen? That's not a bug, it's a vanilla "feature." It's showing the fleet member's variant, which is independent of the variant of the ship on the RHS of the refit screen, which is actually just a dummy ship. When you do something that saves the variant, such as switching to another ship, that's when the changes actually modify the fleet member's variant. This is also why you can get "financial transaction confirmed" when you switch between ships. Also, if you click undo, the dummy ship's variant reverts to the saved fleet member's variant, which should be what's shown on the LHS of the refit screen.

22
Modding Resources / Re: [0.97a] Particle Engine (3/3/24)
« on: March 24, 2024, 07:21:07 AM »
Excellent. I was implementing quite literally the same thing. Reading through the code made me very happy, very neatly done.
I wonder if Mac would return true for GLContext.getCapabilities().OpenGL33? This should return the capabilities of the context, not hardware right? If so, it would be nice to cache the result somewhere and expose it, so that we could have a failsafe in case the context doesn't support OpenGL 3.x calls. (Also gate the implementation side behind this condition, some 3-4 ifs won't ruin anything).

I’ve actually done a bit more research since my last post, and unfortunately it’s a bit more complicated with Macs. Macs don’t support OpenGL compatibility mode for some reason, which is required for contexts to use both immediate mode and retained mode features, since the former is deprecated. So you’re stuck with a legacy context or with core profile; in the former this mod won’t work and in the latter the base game (which makes extensive use of legacy OpenGL) wouldn’t work.

The only (possible, not sure if it’d actually work in practice) solution would be to use multiple contexts. Unfortunately this isn’t an option in LWJGL2, which only supports a single display via the Display class. So yeah, I think we’re out of options at that point.

I’ve added an option in the settings in dev to disable the mod’s features while keeping it active. It’s not pretty — particles won’t be rendered at all — but it should at least allow mods that use this as a dependency to run. I’ll include it in the next update, whenever that might be.

23
Unsure if its just this mod or some combination of other mods. But when I open the manage s mod screen and go to a multi-module ship it strips all weapon slots and fighter bays. Deleting these things in the process. Really gamebreaking.
I can't reproduce this. Tried with vanilla stations and solvernia, and I am able to build stuff in fine without encountering the behavior you're describing. You'll have to be more specific about exactly what you were doing and how it happened, and make sure that it can be reproduced reliably.

Nexelerin's ship collector event doesn't seem to return used story points for S-Modding with this mod, but here's the thing: while it shouldn't return anything for S-Mods in particular, since installing them "doesn't require story points", increasing the S-Mod limit actually costs something, and in this particular case the points aren't being returned, even though it feels like they should. I understand that these points are spent on capacity increase rather than S-Mods themselves, but since there's no other way to spend SP on ships with this mod, it's a bit confusing.

Not sure about how patching small text works, but to remove that message from the dialogue if both mods are loaded should resolve that confusion without changing any mechanics or altering balance. If that's possible.
Thanks for the report. Looks like Nexerelin is using PlaythroughLog to check what built-in s-mods are built in using story points. The PlaythroughLog s-mod entries require a list of hullmods installed, so it's not compatible with the way this mod is using story points. The text itself is from Nexerelin, so I can't do anything about it. The best thing to do is just make a mental note that Nexerelin doesn't refund SP spent on increasing s-mod limits, and use that to inform your decision to sell a ship or not.

While using Unusually Gullible Hullmods, the two Shield Shunt specific hullmods, that being Shunt Distributor and Shunt Diverted Thrusters, can't be built in through the interface. You can't even install the mods without shield shunt on the ship (nor can you remove them without removing shield shunt, which will take them off automatically), however the game just shows red text on the installation UI stating "Removing the Shield Shunt will remove the (hullmod)"
Pretty sure I've gotten this report before. It's because that mod has a strange (and imo, wrong) implementation of some methods.
I can build in shield shunt just fine even with Unusually Guillible Hullmods, so it's probably a mod interaction issue (that is, some other mod is setting shield shunt unable to be built in). In fact every time you leave the refit screen, PSM unsets the no_build_in property of any hullmod that was not declared no_build_in when the game starts.

As for shunt distributor, it's because it's misusing getCanNotBeInstalledNowReason and canBeAddedOrRemovedNow. If you take a look at shunt distributor's canBeAddedOrRemovedNow, it returns false if the ship has shield shunt installed, but at the same time it can only be installed if shield shunt is installed. So, you see, this means that it should in theory *never* be able to be installed, since it's only applicable if shield shunt is installed (but also can't be installed right now if shield shunt is installed).
You could argue that because it works in the vanilla hullmod picker it should work here, but remember that the vanilla hullmod picker only lets you build in hullmods that are already on the ship, so it's likely forgoing some unnecessary checks, while the PSM checker allows you to build in hullmods that aren't already on the ship, so it needs these additional checks.

24
Your safe file also only shows 2 $exceptionalSleeperPodOfficer entries, not sure where you were getting 4 from. So it is true that there are only 2 exceptional officers anywhere in the sector (and they're both in your fleet).

I wonder if what happened is that the sector spawned with 2 persistent exceptional officers, which you found. Then, another two may have spawned later that expired and were despawned, e.g. what if some randomly spawned derelict in hyperspace (I'm not actually sure SALVAGE_SPECIAL derelicts can even spawn in hyperspace) that only showed up at the edge of your screen for 2 seconds contained an exceptional officer, and despawned some time later?

I feel like for this reason, maybe the spawned exceptional officer count shouldn't increment until you actually have the officer in your fleet. And when you have 4, all other exceptional officers anywhere in the sector spontaneously disappear. Hmm, maybe I should add this to a mod.

25
Can't say without the save. All of the saves I've tested have shown no discrepancy between $SleeperPodsSpecialCreator_exceptionalCount and the number of officers shown with the console command. And this lines up with the actual game code -- it doesn't seem like the game is spawning exceptional officers anywhere except inside SALVAGE_SPECIAL entities.

26
Are you sure that's the right save? It has Industrial Evolution stuff in it and you don't seem to have *any* officers. And running the console command that I posted shows there are four exceptional officers, in Zumu, Bhel, Chax, and Alexiar.

27
I have 2 in my fleet that I found just by exploring the entire Sector. I'd be okay with accepting that only 2 spawned in, but my confusion lies in the fact that when used the Find function in Notepad++, I found data for 4 officers labeled ExceptionalSleeper with name data and everything! I just haven't found a way to find them yet lol. I just did the same with Find with the $SleeperPodsSpecialCreator_exceptionalCount you posted and it does say 4, furthering my confusion. Any ideas? Thanks again for the info, this has already been very illuminating  :)
Huh, now I'm confused too. Maybe the code I posted wasn't so robust and there are other ways exceptional pod officers can appear. If you don't mind, you could upload your save file somewhere (not here, there's a limit of 192kb) and I could take a look, that is assuming you're running mostly vanilla.

Edit: is it possible you could have selected "not now" when asked to open the pods, then proceeded to salvage the entity anyway, and in that way possibly "destroying" the officer?

28
That means the command didn't find any exceptional officers, which likely means there aren't any in the sector. IIRC the number is hard capped at 4, but sectors often spawn with fewer. It's a 20% chance per spawned officer (of which there are about 20, according to settings.json), with seemingly no "bad luck mitigation", so I guess you could end up with none if you're really unlucky.

You can check to see how many exceptional officers have already been spawned by searching for $SleeperPodsSpecialCreator_exceptionalCount in your save file.

I suppose it's possible for newly spawned entities to have an exceptional officer in them, but I'm not sure what sort of entities even spawn after new game creation. Only thing I can think of is random derelict ships in hyperspace / from battles, but I don't know if those can have special salvage in them.

29
If you have Console Commands, open the console (ctrl+backspace), then paste this and enter (code taken from Officer Extension mod):

Code
runcode 
import com.fs.starfarer.api.campaign.rules.MemoryAPI;
import com.fs.starfarer.api.impl.campaign.rulecmd.salvage.special.SleeperPodsSpecial;
for (StarSystemAPI system : Global.getSector().getStarSystems()) {
            for (SectorEntityToken entity : system.getAllEntities()) {
                MemoryAPI memory = entity.getMemoryWithoutUpdate();
                if (memory == null || !memory.contains(MemFlags.SALVAGE_SPECIAL_DATA)) {
                    continue;
                }
                Object o = memory.get(MemFlags.SALVAGE_SPECIAL_DATA);
                if (!(o instanceof SleeperPodsSpecial.SleeperPodsSpecialData)) continue;
                SleeperPodsSpecial.SleeperPodsSpecialData data =
                        (SleeperPodsSpecial.SleeperPodsSpecialData) o;
                if (data.officer == null) continue;
                MemoryAPI officerMemory = data.officer.getMemoryWithoutUpdate();
                if (officerMemory == null || !officerMemory.contains(MemFlags.EXCEPTIONAL_SLEEPER_POD_OFFICER)) continue;
                Console.showMessage(system.getName() + ": " + entity.getFullName() + ", " + entity.getLocation());
            }
        }

For the coordinates, center is (0, 0), and each grid tile on the map is 2000 units.

30
I have the option to uninstall a built in hullmod that is not an smod. The accelerated shields here are a hullmod that comes with the ship.
Just checked and the removable list is just using getSMods(), which I just confirmed (at least normally) only shows modular built-in hullmods and not those that are enhanced/enhanceable. This would suggest to me that somehow accelerated shields is both in the s-mod list and the hull spec's built-in list, which would be an inconsistent game state and not something that should be happening.

Is it just that ship? I don't know what mod it's from, and I can't get that behavior from any vanilla enhanceable built-ins. It's possible that mod is manually adding accelerated shields to both lists for some reason.

Pages: 1 [2] 3 4 ... 18