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

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.

16

General Discussion / Drop Phaeton down to Burn 8 to match Buffalo (And is this the standard now?)

« on: January 12, 2019, 12:37:33 AM »

Seems the Buffalo got slowed from Burn 9 to 8 in the 0.9 update. As far as I can tell, the Phaeton is the last civilian ship with a "military grade" burn level.

> Rapidly checks ship_data.csv

... Actually, scratch that. The Starliner is too. And the Tarsus got dropped from 9 to 8 alongside the Buffalo - what's up with the Condor's 9 burn? And that of the Buffalo Mk.II for that matter?  Is this purely to do with ship balance?

> Checks more values

And why's the Gemini still got a civilian burn speed when it ain't got Civilian-Grade Hull? I love the poor freighter to bits and always pick one up when I can, but it seems strange she's still only a burn 8 ship.


... Okay forget the original question. How about this:

Is there supposed to be some kind of standard for civilian ships (ie. those with the "Civilian-Grade Hull" hullmod) having a burn speed of 1 less than a non-civilian ship of the same hullsize? How strongly is this standard enforced, and why do the current outliers exist (if intentional)?

As a modder with a few civilian ships of my own under my belt, I'd like to do my best to keep things consistent, and if a set of rules are applied to vanilla civilian ships with such stats, I'd like to use the same rules for my own content, if that's alright.

17

Modding / Drone Launcher Systems VS Built-in Fighter Wings - A brief comparative measure

« on: December 31, 2018, 03:31:19 PM »

Since Starsector version 0.8 and the massive changes to how carriers and their fighters work, Drone Launcher ship systems have just about died out.

They've certainly gone out of fashion, being overtaken by the practicality and new-fangled mechanics of built-in fighter wings. This change has been shown in the vanilla game with both the Shepherd and Tempest having their drone systems shifted to fighter wings. Several carriers, the Apogee, and most recently the Prometheus, have also lost their various forms of drone systems entirely, in favour of other systems.

Now, I have nothing against these changes. The idea of a "drone tender" employing its drones as a fighter wing rather than a ship system - and therefore having that system slot open for something else - tickles me greatly, and we all love the Shepherd early-game. But as a modder, seeing the Drone Launcher disappear from my radar almost overnight has left me a little uneasy. They're a highly versatile piece of content that I've loved for a long time, and even today they should still (in my view) be holding strong as they have so many fundamental differences to fighter wings.

For instance, did you know that drone systems can give their parent ship stat buffs (like movement speed or sensor range), and that these buffs can scale depending on how many drones are deployed? And did you know that drones can be given very specific behaviours, so they can hold position next to their ship in carefully set locations, or even orbit it, with different drones in the same system orbiting at different distances and speeds? While I love fighters just as much as the next spacer, drone systems, as I see them, have so many key differences to fighter wings that they still have their place in ship design, and modding in general.

So, partially as a homage to drone systems, and partially as a pseudo-guide to modders wondering which to choose, I have compiled a collection of the benefits and caveats of both Drone Launcher ship systems and built-in fighter wings. These pros and cons are intended to be completely objective facts (though which category they fall under may differ depending on your view), but if there's anything I've missed or gotten wrong here, please do let me know.

Regardless of how people see fighter wings and drone systems as a whole, I hope that somewhere a modder about to put a built-in fighter wing on their ship might read this, reconsider and opt for a drone system instead.  


[!] Disclaimer: I have sorted these points as Pros or Cons based on the amount of control they give a modder (or player) for creating something cool, unique and (ideally) well-balanced. They are NOT sorted on how "powerful" they make the option for the player. Please bear that in mind.

Drone Launcher Ship System

Pros
- Can have limited replacement units
- Can set specific orbit or “hold position” behaviours, including giving different drones within the “wing” different orbits.
- Don't generate flux when ordered to attack
- Can be recalled and repaired/rearmed at any time
- Can give stat buffs to parent ship, scaling based on number of drones deployed
- “Wing” size not limited
- Have up to three control modes (recalled/holding/free roam)
- Does not prevent the installation of Converted Hangar

Cons
- Takes up ship's system slot
- Ship can only have one “wing” and type of drone
- Cannot be made to require crew
- Break formation when ordered to attack


Built-in Fighter Wing

Pros
- Can be crewed
- Affected by various hullmods and player skills
- Leaves ship's system slot available for something else
- Ship can have multiple different wings built-in
- Can be given different AI types (in wing_data.csv)
- Can be given specific attack formations

Cons
- Cannot have finite replacements
- Cannot be recalled and repaired, will only land if an empty bomber
- Limited to a maximum wing size of 6 units
- Only have two control modes (regroup/engage)


In Combination

Of course, if you want to get really wild, a ship can have both one or more built-in fighter wings and a drone system, and control them independently.

18

Suggestions / Allow fighters to capture Objectives again (just not very efficiently)

« on: December 22, 2018, 10:39:15 PM »

I'm imagining this being implemented through carriers being able to "target" objectives in a combat scenario and then ordering their fighters to Engage.

It's been mentioned to me that this would make frigates invalid (I don't fully agree with this cos I like frigates, but anything that keeps them relevant is good to me), so perhaps the ability of a carrier to project objective capture at insane range - and speed in the case of some fighters - could be balanced in the following ways:
- Fighters capture objectives slower than warships
- If fighters and a ship of opposing sides are both in the capture range of the objective, the point is not "contested" but is instead captured by the ship as if the fighters weren't there.
That should encourage actual ships be used to capture key objectives, and leave fighter captures more suited to the very opening stages of a battle, and also to capture "that objective over there on the side" without having to dispatch a frigate all the way out there.

Also, obviously if multiple fighter wings of opposing sides are attempting to capture a point, it would be contested as if two ships were attempting to capture it, and wouldn't capture until one side wins out over the other. Yay epic dogfights!  

19

Suggestions / Swap hull bonus from Reinforced Bulkheads and Blast Doors

« on: December 11, 2018, 12:41:08 AM »

Disclaimer: I am, of course, ignoring semantics and any lore-related shizz about the names of hullmods. Please don't argue that "the names make more sense with what they do right now don't change it", because A) that's been pointed out to me already and if a name needs to be changed I'm not going to stop it, and B) that's not what's being discussed here.


This just cropped up in a discussion on the usage of the Reinforced Bulkheads hullmod in the Unofficial Starsector Discord, and I raised (what I thought was) an interesting argument on why it's so preferred over it's not-so-sidegrade hullmod Blast Doors.

Reinforced Bulkheads, as we should all be familiar with, does two things. First, it "almost" guarantees the ship will be recoverable if destroyed in battle (and, y'know, stops it breaking into bits if it does). Then, it gives the ship +40% hull integrity. Pretty damn good all-round.

Blast Doors, from what I can tell much less commonly used, also does two things. First, it reduces the amount of crew losses taken due to hull damage in combat, and likewise when the ship is destroyed. Then, it gives the ship +20% hull integrity.

The problem I'm seeing is that Reinforced Bulkheads is quite often a no-brainer. Having a ship be "almost" guaranteed to be recoverable after a battle is great, whether you're a new player or not. Ships die a lot, and it's very nice to be a little more relaxed about ships dying. Then there's that 40% extra hull (that's a damn lot on some ships!) which is always just as welcome.

Blast Doors, in contrast, seems a less obvious choice in many situations. I'm aware it's designed for the same role as Bulkheads: in a fleet of expendable "junkers" that are regularly destroyed and recovered, Bulkheads does the recovery while Blast Doors ensures you don't run out of willing sacrifices I mean, ah, crew members in the process. However, crew losses from combat never seem very high to me. Perhaps they should be more punishing, but that's a different Suggestion post. Regardless, it seems that the benefit of Blast Doors' crew loss reduction is quite minor. On top of that, crew are easy to find and aren't very expensive to buy. Relative to the base losses perhaps, the benefit is very appreciable I'm sure, but those base losses always seem so low anyway that I struggle to justify it.

Bear in mind that the two hullmods cost the same amount of Ordnance Points, and that both coexist as available options (they're both available to install from the start of a new game). If I ignore the hull integrity bonus, Reinforced Bulkheads seems the better value option for general loadouts - saving the ship is usually more valuable to me than saving the crew (... uh oh). When you account for the extra hull, Blast Doors is left in the dust - in fact I've gotten to the point that I will only put Blast Doors on with Reinforced Bulkheads to make a ship super hull-tanky.



... Wow. Quite the setup. I suppose this bit is the TLDR. The suggestion that comes from all that babble is this:

Swap the hull integrity bonuses of Reinforced Bulkheads and Blast Doors, so RB gives the +20% and BD gives the +40%. I feel this would make them much more like sidegrades of each other, as they should surely be, and give me a more pressing decision over which is more valuable to me when designing a ship's loadout.

20

Suggestions / "Ship Variants" Codex entries should also show equipped fighters on ship image

« on: December 07, 2018, 04:05:40 PM »

Hopefully self-explanatory. In 0.9 we got the ability to see a ship's equipped fighters from the Fleet menu - ie. when looking at the player's fleet, or ships in a market/storage, you can see the equipped fighters pop up as little icons on the ship card next to the ship image, without having the go into its loadout details.

I was genuinely a little surprised to note that the "Ship Variants" portion of the Codex, however, does not display fighters in this manner. It's a trivial thing, I'm sure, but it'd be nice if only for a little internal consistency. 

21

Bug Reports & Support / [0.9a RC10] Increased "Sensor profile" stat shows as a good thing

« on: November 30, 2018, 11:58:33 PM »

As seen here (ignore the mod ships):

Spoiler

[close]

The "Sensor profile" stat is increased courtesy of Degraded Engines (Civ-Grade Hull has been cancelled out by Militarized Subsystems), yet although this is a bad thing it highlights the net increase in green. Surely this should be presented in red, like the "Skeleton crew required" stat a little above it?

22

Bug Reports & Support / 0.9 - Tutorial debris and a Falcon with spare Ordnance Points

« on: November 16, 2018, 12:22:17 PM »

Just a couple of early quirks in 0.9. - I have yet to go past replaying the menu tutorials and a few brief glances through the missions, so I'm just skimming the surface here.

Firstly, and I'm sure this is a trivial one (and also not the fault of 0.9 in particular), but in the Advanced Combat Tutorial it's possible for the Enforcer's debris to block the shots of the "hidden" Wolf. This is the part where the tutorial says "You're about to be attacked by beams", but in this case they never appeared. No idea how this can be fixed (or if anyone should bother?) but I thought I'd mention it anyway.

Spoiler

[close]

Secondly, the Falcon's "Attack" variant seems to be 6 OP short on its budget.

Spoiler

[close]

That is all for now. 

23

Bug Reports & Support (modded) / Critical Malfunctions can disable every weapon? Are decoratives the culprit?

« on: October 20, 2018, 03:55:44 PM »

I'm pretty sure this is a (vanilla) bug, since I seem to recall that Critical Malfunctions - as caused in this case by Ill-Advised Modifications - could never fully disable all of a ship's weapons. It would always end up leaving just one single weapon intact. If this is wrong then stop me here.

Anyway, I've got a Pather version of a new ship I'm working on for my mod here, and as you can see it's just completely lost its last gun by critical malfunctions.  

Spoiler

I started off with two fully-functional Light Dual Machine Guns and now I got squat.  

[close]

I have a theory that this is because this ship also has two DECORATIVE weapons which interact with its ship system. I'm wondering if the critical malfunction algorithm counts decorative weapons in the "weapons the ship has left" count, and is perfectly happy to disable all regular weapons because it still has "functional" decoratives. Is this the case? And if so, is it somehow intentional???

(EDIT: These are the mount locations on the base version of the ship in question. The only thing that changes on the (LP) version in the above image is that the two turrets change type from HYBRID to BALLISTIC. The decorative mounts are untouched.)

Spoiler

[close]

Any help here would be much appreciated.  

24

Suggestions / Remove hard-coded graphical explosion from MIRV missiles

« on: October 04, 2018, 10:54:01 PM »

This has come about in my head after toying with a number of custom MIRV missiles, and I'm starting to get a little annoyed with those little yellow sparks that always appear when an MIRV projectile splits into its next stage. Granted these experiments of mine are admittedly hacks that could otherwise be achieved with custom missile AI, but I think the point should be made anyway.

We already have a space for a custom particle effect we can put into an MIRV split. Why do we have a hard-coded one as well? It seems a little strange to me. If anything, I'd be fine with it being an option within MIRV behaviour of the weapon's ".proj" file;

Code

"alwaysSpark":"true"

or similar.

It's mostly a personal grudge, and I know it's not a major thing relating to 0.9 in any way, so no hard feelings if this is ignored or declined. Just thought I'd put it out there. 

25

Modding / What's the difference between "getWings()" and "getFittedWings()"?

« on: September 01, 2018, 09:07:35 PM »

Specifically within the ShipVariantAPI. The two methods both return lists of strings. Is there a fundamental difference between them, and what is it?

26

Suggestions / Jump Point fleet warning, apply to stellar terrain effects as well?

« on: August 24, 2018, 09:53:37 PM »

https://twitter.com/amosolov/status/1033208473989931008

Given this, might we see a similar thing if the other jump point is inside stellar terrain/phenomenon? Say, within a solar flare or neutron beam? Hostile fleets are definitely not the only risk when "jumping blind".

27

Bug Reports & Support (modded) / Player-piloted fighter "wreckage" freezes on death & weapon arcs remain visible

« on: August 18, 2018, 09:21:14 PM »

It's probably safe to say that this isn't a big concern, but MesoTroniK suggested I point it out anyway, so here we go.

Spoiler

Portions of this image have been [REDACTED] for your own sanity.

[close]

As you can see in the screenshot, I was manually piloting a fighter (courtesy of DevMode) and got killed in a dogfight. On death, the fighter sprite vanishes, as they do, but the arcs of the selected weapon group remain, apparently emerging from nothing. Not only that, whatever it is I'm now in control of - the nonexistent wreckage I suppose - immediately stops moving, even though the speed readout on the HUD says I'm still moving at 243 speed.

Merely a foolish assumption that this is in fact a bug of some description, and not intended behaviour - I'm aware it's not at all normal for a player to be piloting a fighter (cough cough Diable Avionics cough), but just in case something's actually wrong with this situation, here it is.

Currently active mods:
- Combat Chatter
- LazyLib
- Practise Targets
... and a [REDACTED] experiment this particular fighter is a part of. (Pretty sure the little guy ain't the cause, but he has a custom ship system so ya never know!)

28

Bug Reports & Support (modded) / Ran out of "buffer elements" when taking a screenshot of the missions screen

« on: July 20, 2018, 04:44:39 PM »

This is definitely a weird one, and I know that because MesoTroniK responded with "wat" when I showed him the error.  


Situation: I've just been setting up a new experimental mod environment. All it has at present is a mod_info.json file; some empty folders right where they should be; an as-yet unused sprite; and a single mission which uses only stock ships, with nothing fancy whatsoever in it at all.

I was displaying progress to MesoTroniK via Discord as I'm working on this, and started the game with the new mod environment running to check that the mission was loading correctly. It was, so I pressed the screenshot key to take a snapshot of the mission details screen.

The game immediately crashed, giving the following error:



The log was not much more helpful:

Code

... 126868 [Thread-10] INFO  sound.oo0O  - Creating streaming player for music with id [miscallenous_main_menu.ogg]
126869 [Thread-10] INFO  sound.OooO  - Playing music with id [miscallenous_main_menu.ogg]
126915 [Thread-8] INFO  sound.OOoOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO  - Creating music buffer #1
127603 [Thread-4] INFO  org.histidine.chatter.combat.ChatterCombatPlugin  - Chatter plugin initialized
131437 [Thread-VC-Main] INFO  exerelin.utilities.versionchecker.VersionChecker  - Local Starsector version is Starsector 0.8.1a-RC8, latest known is Starsector 0.8.1a-RC8
131491 [Thread-VC-Main] INFO  exerelin.utilities.versionchecker.VersionChecker  - Checked game and 7 mods in 4.745 seconds
141793 [Thread-8] INFO  sound.oo0O  - Cleaning up music with id [miscallenous_main_menu.ogg]
141923 [Thread-10] INFO  sound.oo0O  - Creating streaming player for music with id [miscallenous_main_menu.ogg]
141923 [Thread-10] INFO  sound.OooO  - Playing music with id [miscallenous_main_menu.ogg]
142364 [Thread-4] ERROR com.fs.starfarer.combat.CombatMain  - java.lang.IllegalArgumentException: Number of remaining buffer elements is 746000, must be at least 4196352. Because at most 4196352 elements can be returned, a buffer with at least 4196352 elements is required, regardless of actual returned element count
java.lang.IllegalArgumentException: Number of remaining buffer elements is 746000, must be at least 4196352. Because at most 4196352 elements can be returned, a buffer with at least 4196352 elements is required, regardless of actual returned element count
	at org.lwjgl.BufferChecks.throwBufferSizeException(BufferChecks.java:162)
	at org.lwjgl.BufferChecks.checkBufferSize(BufferChecks.java:189)
	at org.lwjgl.BufferChecks.checkBuffer(BufferChecks.java:258)
	at org.lwjgl.opengl.GL11.glReadPixels(GL11.java:2466)
	at com.fs.starfarer.util.o0OO.o00000(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)

... And it didn't take the screenshot either.  

Modlist - Only the highlighted elements, as well as the [REDACTED] mod, are those running:

Spoiler

[close]

I tried to reproduce this several times, and have been unable to. Screenshots are now being saved perfectly fine, and yes the mission itself works and plays with no issues whatsoever. I have genuinely no idea what caused this or even what the error means - any help or advice much appreciated, as it's freaking me out a little!  

29

Suggestions / Allow Scavengers to interact with jettisoned cargo

« on: June 29, 2018, 03:37:37 PM »

Just my random thought for the day.

When the player jettisons cargo in space, it leaves behind a collection of cargo pods which will despawn after a short amount of time, or can be "stabilized" to last much longer. I'm wondering what the connotations might be of having Scavenger fleets who encounter cargo pods stop to investigate, possibly then picking up the cargo themselves.

Now, obviously this would be problematic for a player who has stored some excess cargo with the mindset of returning to pick it up at a later date. But, it could be strong material for helping the player interact more with the sector. We know you can lure unsuspecting fleets into their doom by, say, using your Distress Beacon unfaithfully to set a trap. What about using jettisoned cargo as bait then hiding in a nearby hyperspace cloud or asteroid field, to attract an unwary Scavenger?

As far as user interface goes, I would suggest that when a scavenger encounters cargo pods, they make a quick decision (perhaps random) whether to stop and look, and if they do they approach and hold position near the pods for, say, a day. Then they may leave, taking the cargo with them, or leave it where it was and carry on. In the case of the former I would love to see the player be able to chase the fleet down, kill the ships and then reclaim the "bait" cargo along with the battle salvage.

In the situation where a scavenger encounters a player's cargo pods and the player is nowhere around, in this case it may be sensible - for the player's sake - to have the scavenger fleet stop until the player enters the vicinity, to prevent scavengers from stealing goods the player has intentionally left behind because they didn't have the cargo space to carry it home in one trip. Then they could perhaps contact the Scavenger fleet and do a fun little "Hey, that's our salvage!" dialogue interaction, perhaps resulting in a smaller fleet backing off and a larger fleet standing their ground (or even demanding ransom), or maybe just go straight into a fight in order to reclaim the goods.

Thoughts?

30

General Discussion / One for the Devs: "Au Naturel" Phase Skimmer behaviour

« on: April 06, 2018, 08:52:38 PM »

Steps:
- Give the Phase Skimmer ship system an arbitrarily large number of charges
- Spawn a Wolf into the simulator
- Spawn one of Tartiflette's lovely practice targets in front of it
- Target the target
- Hold F

Result:



So, I've got to ask. Is this intentional? And if so, why? Any further details the Devs want to share about why and how the Phase Skimmer works the way it does?