Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  


Starsector 0.95.1a is out! (12/10/21); Blog post: Uniquifying the Factions, Part 2 (04/30/22)

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.

Topics - AxleMC131

Pages: [1] 2 3 ... 5
Just noticed this one while testing some default variants for my mod via the main menu missions. If a ship in the refit screen is kitted out with Dedicated Targeting Core, and you go into Autofit, select and confirm a goal variant that has Integrated Targeting Unit, the ship will be autofitted without ITU, the remaining OP spent on capacitors/vents as applicable. Autofitting the same goal variant a second time will then install ITU properly.

It seems to not matter if the initial loadout was an autofit one, or had spare OP or not. Tried it with a couple of other ships in the mission fleet, same thing occurred. I briefly thought this could be something to do with ITU and DTC being normally incompatible, but note that in the Autofit menu, "Strip before autofitting" is ticked!

See relevant screenshots below.
Initial loadout, including DTC:

Choosing another loadout through Autofit. Note the goal variant I want here should have ITU.

Selected the goal variant, and the preview loadout is already missing ITU, extra OP going into vents/caps.

Confirmed autofit, final loadout is missing ITU.


Suggestions / Plasma Burn can be held down for one big burn
« on: April 24, 2020, 12:59:54 AM »
This is inspired by a modified Plasma Burn system I put together this evening for a ship in my mod, and I'm so gorram proud of it that I think it should be a vanilla feature. ;D

Basically, when you use the Plasma Burn system as on the Shrike and Odyssey (though I haven't considered the balance of the latter), if you hold down the system activation key it consumes both charges in succession and extends the burn as if it was one double-length burn. So, with two charges you can perform two separate 0.5 second burns, or hold it down for one 1.0 second burn.

(The system I've put together consumes charges one at a time, as the duration of each system "use" runs out, but it's also built for 3+ total charges so you can divide up the burns as you please with a bit of good timing.)

I thought it was so much fun, and could probably be done much more simply in the base game than through my hacky wacky code, that it might be neat to have as a vanilla feature of at least the Shrike's Plasma Burn. Thoughts?

Modding / How I Kitbash a Starsector Ship
« on: April 22, 2020, 10:57:48 PM »
Just a half-commentary half-timelapse video of me kitbashing the ship sprite that would ultimately become the Nightblade in Disassemble Reassemble. The commentary in this video is a healthy mix of things I actually consider useful advice for all, and explanations of what/how/why I do the things I do in the kitbashing process.

Note that the video was recorded over a year ago now, and even over that time period some of my techniques have been refined. The total real time spent on the sprite in the video was about one hour and twenty minutes - the timelapsed portions of the video are sped up to 4x regular speed.

For those unfamiliar with the ship in Disassemble Reassemble, here's the initial implementation in-game last year:


Bug Reports & Support / Is the Kite midline or low-tech?
« on: August 23, 2019, 05:23:24 PM »
I think the Kite is confused. In its hull file it has all the style values set to "MIDLINE", and is clearly a midline ship. Yet in ship_data.csv it has "Low Tech" listed as its design type.  ???

(I've always treated the Kite as midline, and regardless of what it's supposed to be here I will continue to.)

Modding / Manually changing of animation frame refusing to cooperate
« on: August 17, 2019, 05:44:23 PM »
I've been tearing my hair out for about three weeks trying to figure out why I can't make (what I thought was) a pretty simple setup work, and I've come to the conclusion that there's something very strange and fundamental going on in the core game that's preventing me from achieving this. Whether it is a bug or not I have no clue, but I would very much like it to be looked into either way, as it makes zero sense. Regardless, that's why I've stuck it here in Bug Reports. If a moderator would rather it be in the Modded subforum, that's fine by me, as long as it gets addressed, or at the very least explained.

I have a decorative weapon with multiple animation frames on a ship. The ship also has two unique hullmods: one built-in and hidden, the other modular and visible. The built-in hullmod does all the work. If the player tries to remove the modular hullmod, the built-in one notices this as a trigger, and "does something", before manually re-installing the modular hullmod. The result is a "cyclic" function that lets the player toggle through a series of options by repeatedly removing the modular hullmod. Presently, that series of options is the series of animation frames for the decorative weapon. (This is all cosmetic for now.)

No matter which way I slice this damn system, I cannot get the deco weapon to change animation frame in the way I want it. I can forcibly set it to a particular value if I just stick a hard number in the script, but the moment I put in a saved number attached to the ship ID (fleetMemberId actually), it refuses to change.

Worse, I've set up a logger so I can see if the saved value is incrementing... And it goddamn IS! For reasons beyond my comprehension, this line...
Code: java
... does not work.

For full context, here's the whole of the meat of the script (this is the built-in hullmod). "dara_arrow_paintcycle_trigger" is the modular hullmod that the player removes to cycle the setup.
Code: java
    public void applyEffectsAfterShipCreation(ShipAPI ship, String id) {
        String shipId = ship.getFleetMemberId();
        if (SAVED_DATA.get(shipId) == null) {
            SAVED_DATA.put(shipId, 0);
  "Reset frame to #0");
        if (!ship.getVariant().hasHullMod("dara_arrow_paintcycle_trigger")) {
            for (WeaponAPI wpn : ship.getAllWeapons()) {
                if (wpn.getId().contains("dara_arrow_paint")) {
                    int currFrame = SAVED_DATA.get(shipId);
          "Retrieved frame #" + currFrame);
                    if (currFrame + 1 > 12) {
                        currFrame = 0;
                    } else {
                        currFrame += 1;
                    SAVED_DATA.put(shipId, currFrame);
          "Incremented to and saved frame #" + SAVED_DATA.get(shipId));
                    runOnce = false;
As you can see, I've got multiple log outputs here, which have very clearly been showing the saved value incrementing, live, as I try to cycle the hullmod from the refit screen:

98010 [Thread-4] INFO  data.scripts.hullmods.dara_RedArrowPaint  - Reset frame to #0
98010 [Thread-4] INFO  data.scripts.hullmods.dara_RedArrowPaint  - Retrieved frame #0
98010 [Thread-4] INFO  data.scripts.hullmods.dara_RedArrowPaint  - Incremented to and saved frame #1
98977 [Thread-4] INFO  data.scripts.hullmods.dara_RedArrowPaint  - Retrieved frame #1
98977 [Thread-4] INFO  data.scripts.hullmods.dara_RedArrowPaint  - Incremented to and saved frame #2
113244 [Thread-4] INFO  data.scripts.hullmods.dara_RedArrowPaint  - Retrieved frame #2
113245 [Thread-4] INFO  data.scripts.hullmods.dara_RedArrowPaint  - Incremented to and saved frame #3
114526 [Thread-4] INFO  data.scripts.hullmods.dara_RedArrowPaint  - Retrieved frame #3
114527 [Thread-4] INFO  data.scripts.hullmods.dara_RedArrowPaint  - Incremented to and saved frame #4
127248 [Thread-4] INFO  data.scripts.hullmods.dara_RedArrowPaint  - Retrieved frame #4
127248 [Thread-4] INFO  data.scripts.hullmods.dara_RedArrowPaint  - Incremented to and saved frame #5
And yet, in the refit screen, the animation frame of the weapon does not change.

YES the deco weapon has the right frames setup and is visible and all that jazz. I've tried multiple ways to ensure this, everything from manually giving the setFrame() call values for each one, to just making the animation have a non-zero frame rate and watching it go through each one from the refit screen.

NO the frame does not update in combat. It refuses to work anywhere... Except for the codex. If you repeatedly click the ship's entry in the codex, you can see the image of the ship cycling through the animation frames exactly as I want it to elsewhere. What the hell!?

The worst bit about all of this? I KNOW that you CAN make a system just like this that manually changes weapon animation frame on a cyclic basis, because I've already done it once. I'm not annoyed because it looks like this is impossible: I'm annoyed because I know it IS possible, and I cannot understand why I'm unable to make it work a second time.

I'm at my wit's end with this damn thing, tried about five different methods to make it work, and I'm |this close| to giving up. Help is sorely, desperately wanted.

General Discussion / I'm worried about mines
« on: July 26, 2019, 03:39:18 AM »
... That's it really. I've heard a lot about how overpowered they are, on the Doom specifically, but that little has been said about them or the Mine Strike system being nerfed at any point in the future. :-\ I haven't experienced mines much myself, but I have flown a Doom post-0.8, and it was a barrel of fun. I would hate to see it lose the Mine Strike. But at the same time, I'm a big stickler for balance, and I did find it quite strong in combat.

Is there a nerf for mines incoming? The general consensus I've gathered is that there should be one, at the very least a damage reduction or similar.

Suggestions / Don't count mothballed ships towards the fleet cap
« on: May 31, 2019, 11:45:41 PM »
If this issue has been alleviated in the recent versions and I just haven't noticed, please discount this entire thread. ;D

I recall a common, minor (ish) issue prior to 0.9 with the function of post-battle ship recovery, that issue being that if your fleet was at the maximum number of ships (30 default), you would be unable to recover new ships. Perfectly reasonable, but not immediately obvious to a player who doesn't realise there's a fleet cap at all (or doesn't realise it prevents them picking up extra ships even if they aren't being used). The real issue is that the player has no way to access the fleet screen while in the post-battle recovery menu, so if they're at cap and have a tasty ship they could recover from the fight, there's no way to scuttle another ship they have to make space for the new one - ideally you would leave the recovery screen without recovering anything, then remove a ship from your fleet, then go back to the recovery screen... Except you can't do that. Darn. And sure, you can get around this just by "being prepared" and making sure to always have space in your fleet for newcomers, but again, I feel this issue is biggest for new players who don't comprehend this full extent of the fleet cap.

An option that could alleviate this somewhat is to have mothballed ships not count towards the fleet's maximum ship count, and also make post-battle recovered ships (at least if the fleet is already at cap) be automatically mothballed. Then, if the fleet is still "full" you simply lock any mothballed ships as such, and make them unable to be reinstated in combat/transport/whatever duty until another ship is removed or manually mothballed itself.

For extra points you could also have a warning popup in the Intel portion of the screen (like you would for the fleet being over cargo/fuel/crew capacity) that lets the player know "[Some number of] newly recovered ships have been mothballed... blah blah blah." You could also have a tip in there about having to mothball/remove other ships in order to unmothball the newest craft.

The Hound (A) still has the old Militarized Hegemony Auxiliary hullmod, but the Kite (A) and Buffalo (A) now have Militarized Subsystems instead. Yes, I know they're both Civilian ships to start with and the Hound is not, but that shouldn't make a difference in the grand scheme of things - neither the Buffalo nor Kite (A) retains the Civilian-Grade Hull hullmod in their transition to Auxiliary status, and you might as well just slap the modular hullmod on a regular one (yes I know the Kite (A) gets bonus OP), which takes out a lot of the flavour.

Originally I was under the impression that this was because Mil' Subsystems gives +1 to burn speed, and Heg Auxiliary does not, ergo the Hound (A) with Mil' Subsystems would be broken. Which would be fine! I like my balance... Except Heg Auxiliary DOES give +1 burn speed as well so that's irrelevant.  ???

So what the heck's going on here? I'd seriously appreciate some consistency - pick one hullmod for all the Auxiliary ships and be done with it, because I cannot understand why they're different. If there's some other fundamental balance concern going on here, I'd rather see the hullmods reconfigured to avoid that rather than picking one or another for different situations.

- Militarized Subsystems is the modular choice you can put on any civilian ships, in ADDITION to Civ-Grade Hull to make it less harsh.
- Militarized Hegemony Auxiliary is a more special hullmod that's part of the ship itself, which REPLACES Civ-Grade Hull and gives some more interesting bonuses.

With the Kite (A) and Buffalo (A) losing that - but the Hound (A) not - I'll be honest, I'm feeling a little lost.  :-\

Also it has the "[  ]" as if it's a surveyable planet. It isn't able to be surveyed, but having the exploration/survey brackets there (especially when the main star doesn't) is a bit odd.

This is the secondary star in a binary system. The screenshots should say it all:



General Discussion / Why was the in-combat nebula slowdown removed?
« on: April 25, 2019, 01:46:09 AM »
Dumb question I'm sure, but it's taken me this long since reading it in the 0.9 patch notes way back when to realise that I've never seen any reason for the removal of the speed penalty on ships in nebula clouds in combat. More to the point, I don't recall anyone else asking about it. And I really don't understand how I've been so unthinking about the whole thing until now.  ??? Alex mind-control powers confirmed (jk)

Was there some PSA about it that I missed? Why was the feature removed, and with such little fanfare?

Bug Reports & Support / New forum layout has no spoiler format!
« on: April 22, 2019, 01:02:01 AM »
I have no idea if the Devs are aware of this, but in case they aren't, there's no "Spoiler" formatting cue in the new forum posting window! Spoiler tabs in people's posts and comments are no longer working, and are showing any hidden content right up front for all to see. This might be a concern?  :-[


Might not have been noticed since it seems no vanilla weapon uses an interruptible burst combined with an arbitrarily high burst size anymore (pretty sure the Assault Chaingun and possibly Storm Needler used to use this setup), but usually such weapons tend to be rotary or sustained weapons that penalise you somehow if you let go of the trigger? For such weapons surely the burst size doesn't need to be displayed in the stat card - or at least hide it if the burst is above a certain value.

Or, y'know, perhaps add a "hide burst size" column in weapon_data.csv like we have for DPS values etc, but that might start getting messy - we have a fair few columns in that sheet now.

Yes I know, it's another consistency argument, but I like my consistency.  :D

What's up with [no_weapon_flux] and its placement on some fighters? The way I understood it, the hullmod exists for shielded fighters in order to discount weapons from the ship's flux handling, making its flux capacity purely a health bar with regard to its shield. For most cases this seems to work out, but there are a couple of strange exceptions I've noticed in Vanilla, and I'm wondering if these are intentional or not:

- The Wasp, despite being unshielded, has the [no_weapon_flux] hullmod. Why? Just up its flux stats so the PD laser doesn't appear to draw from its capacity.
- The Trident and Cobra, despite being shielded, do not have the hullmod. I know they have no flux-generating weapons between them, but another high-tech shielded bomber with no flux-generating weapons, the Dagger, does have the hullmod. What's up with that, and which one is the outlier?
- The Xyphos is the only fighter with the hullmod to have it given to it as a built-in mod in the .ship file. The others all have it given in their .variant files.

Any light that can be shed here would be much appreciated. 8)

Suggestions / Make matching sprite & .proj sizes for projectiles a STANDARD
« on: February 26, 2019, 12:07:56 AM »
Can we please make it a standard that projectiles have their size as set in their .proj file match the dimensions of the base sprite? It's a pretty weird inconsistency, and detracts from the "retro" pixel-artness of the game in my opinion.

(Apologies for the meme-ness, this wasn't originally intended for the forum, but I think it gets the point across quite well...)



The Annihilator is a really weird outlier right now, and it seems it's causing a couple of modders to generate some pretty strange bad habits (and using "but Vanilla does it!" as an excuse).

This comes following this bug report on Disassemble Reassemble:

Relevant image:

The "Black Arrow" shown is a skin variant of another ship called the Red Arrow. Among other contrivances, the Red Arrow sports a single fighter bay with a unique built-in wing. The skin for the Black Arrow includes a hidden hullmod that removes the fighter bay, however as shown in the above report a damaged version of it still somehow acquires carrier-related hullmods.

I have a theory that this is because hullmod compatibility checks - in this scenario of D-mod application - only look at the base hull file, rather than changes made by the skin. Would it be possible to change this? As otherwise the only fix on my end is to make the Black Arrow a fresh hull rather than a skin (which I'd rather not do unless I really have to).

Additionally: The Black Arrow skin does *not* restore to the base Red Arrow hull, and neither version of the ship has a "CARRIER" AI tag.

Pages: [1] 2 3 ... 5