Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

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 - Morrokain

Pages: [1] 2 3 ... 99
Modding / Re: Additional mod_info flags / mod version stuff
« on: Today at 03:27:07 PM »
I would also add user experience and value to business (modder in this case).

User experience (as a user) - being consistent and meeting expectations. My experience is good when I upgrade the mod and my game does not break.

Right, in general I agree, but it wouldn't be the case for everyone because of knowledge requirements for Best Effort. Because of that, the above benefit is illusory to a user in the actual modding scene. Again a "business" has the expectations of quality control that you are speaking to because they have infrastructure dedicated to acquiring talented and knowledgeable staff to interpret and implement the requirements. That is simply not the case here, and so enforcing helps some and hurts some - with it causing the most problems for those just starting out. It certainly brings value to a modder who understands all the requirements, no argument there - it is just that it is disingenuous to assume that all do. That wouldn't be a problem in and of itself, but as those who understand the requirements raise user expectation in this way, those who don't suffer a larger penalty of "user disappointment" that they don't.

If that is correct, the big problem which I brought up in the other thread is that the actuality of that information isn't guaranteed to be correct.

I would have to disagree with you on that. This could be said about any software that does not have a full suite regression tests in place. At this point you are trying to accurately infer backward compatibility based on the changes you did to your software and your understanding of its interaction with other software. Best effort is enough.

Going further, it does not need to be correct, it only needs to be enforced correctly. If I mark my new version 1.5.2 as incompatible upgrade even though it might be compatible with 1.4.0+ that's not a big issue (will only prevent users from upgrading mid-game), and something I as a modder can do.

I really fail to see a difference except the key one: best effort isn't a guarantee. Your example, of course, has no downsides because marking an update incompatible when it is, in fact, compatible leaves the user none the wiser. What about the reverse? You mark it compatible and it is not. Keep in mind, a user won't always know this when trying to load the save. Off the top of my head, they have a ship with a hullmod equipped in storage on some market somewhere and that hullmod was removed in the current (supposedly compatible) update. They won't get a crash until probably interacting with that market, etc. (Not really sure if this is true anymore, but it was at one time.)

I mean, this isn't the worst thing in the world if it happens. My point was that the difference between this happening now and after the suggestion is implemented (to a user) is that it might actually end up being more off-putting because it was clear, concise, and in your face so many times before. That, and because mods that manage the feature well and don't make this mistake cause it to be a rarer occurrence - which again is more likely to effect a new modder than one who understands the game engine and API to the point that they can effectively manage this. I mean, I'm not trying to say it would be awful or ruin the modding scene or anything, but it is certainly something to consider.

(Tartiflette's separation of versioning and compatibility control is the best way to do this, I'd say, since it removes the additional issue about versioning clarity through always incrementing Major if unsure about save compatibility. But mark my words, it will still open up a can of worms the first time anyone is wrong should it be implemented!  )

This is a huge can of worms. Let's go back to initial requirements: "consistency", "user expectation" and "user experience".

Modder releases a new version, 2.0.0 (internal 23), that comes after 1.4.5 (internal 23), that comes after 1.4.4 (internal 22). User can no longer upgrade from <=1.4.4. If we prevent user from loading the game, what do we show? Please downgrade? User goes back to 1.4.5 (which he skipped). Same problem. We can say "Downgrade to internal build 22 (it also need to be stored in a savegame, because internal might not be simply current - 1). But internal version is being hidden, which makes user go straight back to forum thread, which tells user "open mod_info and find one with 22", which means "keep downloading previous versions until you find one matching" (as internal is not published). Also this does not solve consistency, as you can't tell from version alone which versions are safe to replace current version.

 ??? Maybe I'm missing something here? I don't see how having internal exposed in the version, itself, helps make it more clear to the end user what their course of action should be. Like, if you release and one user has and another there is still a lack of clarity what version to revert to unless the version of the save itself is exposed to the user (which it is already, right?). If you are speaking to the idea that the version is stored in the save file and the user can be pointed to it explicitly that way, then why does internal even need to be exposed? It would point to the version the user was last using regardless, and that version is guaranteed to be at the compatible internal level of the save...

I don't think "at a glance" compatibility via the suffix implementation is worth entangling content and compatibility into the same number. That, I believe, was Tartiflette's point. What you at least seem to be thinking of in this case, is when a user asks why their save isn't loading and all they have is their current version number. It would would be useful, in some ways I suppose, to have at-a-glance compatibility then. Even that is a little suspect, come to think of it, because you'd still need to know the version the save is trying to reference - so you're back at square one. But when considering the warning message when trying to load a save? All pertinent information is already available from the perspective of what such a feature is trying to accomplish.

If a user's save is 1.4.4 (internal 22) and the release is 2.0.0 (internal 23), it doesn't matter whether a 1.4.5 (internal 23) exists or not, the message would still point the user back to the save's version (1.4.4 internal 22). Trying to be extra smart and say "Hey there is a 1.4.5 (internal 23) - go try that first!" - wouldn't be possible even if the versions were, respectively: - - The message is still going to be pointing the user to their save's version - even if, via the version control, would technically be compatible.

To do otherwise would require every legacy version of the mod to be stored in a database, and queried to check for "best backward compatibility" each time a mismatch was found. That's extremely unlikely to ever happen.

Announcements / Re: Starsector 0.95a (In Development) Patch Notes
« on: October 27, 2020, 02:52:05 PM »
Quick question: have you considered making smaller updates over the course of the year, while you work on the "big bad update"? I'm talking about relatively small things like those already included in these patch notes, like adding a ship here and there, balancing some weapons, adding small stuff etc. 
While not substantial and hype inducing, they could help keeping the playerbase engaged and speaking about the game to their friends/making youtube videos etc etc (which of course, means more sales for you). 
I personally have no trouble waiting, however i do find myself picking the game for a bit, and then forgetting about it until i randomly remember months later and check about the update progress. If even 20% of the current patch notes were separated into smaller updates every couple months or something, it could make many people happier and keep the community strong imho.

He could, but I think that would only further slow down the big update. It's not one of those things where you can just throw some extra stuff in there - at least most of the time. He'd probably have to fork the whole project each time, then there is polishing that forked update, making it consistent with the big update when things in the big update change pre-mini-update, etc.

So considering that, I'm not sure it is worth it. Idk, just my opinion though and I'm making assumptions there.

Modding / Re: Additional mod_info flags / mod version stuff
« on: October 27, 2020, 02:39:42 PM »
The important thing here is consistency and user expectation though. What I mean by that is what something like what was suggested does is give modders a way to specifically say - through loading/not loading or backwards compatibility messages - "Hey my update won't break saves! Go ahead!" Or "This will 100% break saves - wait until a new game to update!"

Am I correct in that interpretation?

If that is correct, the big problem which I brought up in the other thread is that the actuality of that information isn't guaranteed to be correct. This isn't proven logic determining whether this is true, it is the modders faith in what they know about the update - which in some cases could be wrong! In the cases where it is wrong, it creates extra confusion for the end user and probably extra saltiness to their response. It might seem silly to bring that up since that is the modders own risk, etc, but I don't think we can discount the impact to end user expectations here.

That is why the warning doesn't make guarantees - and why modders probably shouldn't either - at least technically through things like launcher messages. It seems like a good idea when you first think of it, but in reality it will probably lead to less than desirable outcomes. I get that you can already do this to some extent with messages like "Will/Won't Break Saves" above the update link, but to me at least, that is different than what seems like "logic is working to determine compatibility" that is in fact still just the modders opinion of if it will work or not like what a message over the download link clearly implies. Does it seem like splitting hairs to say one is ok and one isn't? Absolutely. But remember we are talking about the end user who doesn't read anything or try and learn how stuff works - they just want it to work so they can play. The launchers seems too "official" to state something that is, in fact, really a judgement call.

Hopefully that makes sense. Its not about what versioning style to use or how to go about official compatibility warnings, but should such warnings be possible when they aren't guaranteed to be correct?

(Tartiflette's separation of versioning and compatibility control is the best way to do this, I'd say, since it removes the additional issue about versioning clarity through always incrementing Major if unsure about save compatibility. But mark my words, it will still open up a can of worms the first time anyone is wrong should it be implemented! ;)  )

Announcements / Re: Starsector 0.95a (In Development) Patch Notes
« on: October 26, 2020, 06:51:00 PM »
I always assumed Alpha Cores was basically wishing on the Monkey's Paw. Sure you get what you want, but it will come to bite you eventually. Perhaps I've been tainted by Crusader Kings 3 (which if you go down the Intrigue route, you'd have "wit checks" against other characters) but if a rogue AI kept on making harsher and harsher demands of the player, or else scuttling industries or even the whole colony, their fickle nature would be well-learned. Of course, if some Cores did no such thing, or caused minimal trouble, the player may be willing to roll the dice. In short, it'd be cool if Alpha Cores had personalities like Compliant, Mischievous, and Chaotic.

Neat idea! Though perhaps instead of difficulty variance, the *types* of trouble they cause (i.e. economic vs military vs faction rel) could be a little more predictable - or at least thematic in nature? I say this because having RNG effect the downsides' severity or number like that could mislead new players into thinking they understand cores when they have a good first experience, install a bunch off that first impression, then really regret it afterwards.

Ah ok I looked in the Nex faction config for Nex itself and found:     "noRandomizeRelations":true,

 - so that should be the soft override I'm looking for.

Random relations are off by default; however, Nex does alter the vanilla faction relations to make the game more "interesting" by default, iirc.

Thanks! I checked the independent file in Nex and it shouldn't interfere with the Archean Order Nex config itself. It could be possible that another mod is doing something by implementing their own independent faction Nex config, but even then it shouldn't affect the Adamantine Consortium Nex config sooo... I honestly don't know.

The soft override for random faction relationships was easy enough to add that I will include it in the next AO update. That way users will have to disable it within the AO mod as well - which at the very least should prevent this from happening on accident.

Modding / Re: Additional mod_info flags / mod version stuff
« on: October 26, 2020, 03:58:47 PM »
The game already shows a "mod compatibility warning" when you try to load the game (I'm not 100% sure if this is in 0.9.1a, actually), and will also show the saved with/current versions for all the mods involved in the save game's tooltip, so I think this should be covered?

I think based upon this thread there is a desire for modder customization of version control. So what I think Wispborne means with the suggestion is that a modder can determine for themself which versions will actively break saves rather than a warning just when the mod version and save version mismatches.

Even though some version mismatches won't actually break saves, the user still gets the warning if the versions are different.

(Personally I'm on the fence about it for the reasons I've stated in the thread.)

Modding Resources / Re: [Guide] Semantic Versioning for mods
« on: October 26, 2020, 02:54:24 PM »
I get that standardizing the versioning would remove a lot of headaches for experienced modders. It is really annoying when you spend the time posting details and a user disregards them, slaps a million mods on, and gets mad and flame posts that your mod doesn't work, the game is buggy, etc. I think we can all relate to that being frustrating when you have spent so much time on your work.

I'm going to have to echo what many said here, though, and say I don't think strict version management like this is good for the community as a whole. Standardizing the versioning is fine and I think the guide is very helpful, but having additional software purposefully lock out a game load or cause a well-meaning CTD creates a larger barrier of entry to would-be modders and even more unrealistic expectations of end users.

Why? A new modder has to have intimate knowledge of what causes saves to break. That is definitely a learn-as-you-go kind of thing and as the code base of a project expands, more things can go wrong in that regard. So they have two choices:

A) Release every version of their mod as a Major release so they protect themselves from additional flak from end users - since there would then be "no excuse" for a save-breaking update as a Minor or Patch update from the perspective of the end user.

B) Release the actual version of their mod considering the added content/etc, and risk being wrong and the save being broken. In that case, again, end users now have higher expectations and therefore greater wrath than before for mistakes. That point also goes (possibly doubly so) for experienced modders who make a mistake - which will likely happen from time to time.

Option B's downsides are self evident. Option A's downsides are a lack of clarity on actual content contained in a Major update. What this would likely translate to would be: experienced modders generally follow the guidelines (except then they don't! - because they know a hotfix breaks a save, etc) and release a lot of additional content under the Major update. New modders will be all over the place, and the frustration of the end user when a problem occurs will be greater - not less - for situations where a save is broken because they had a false illusion of safety. Those situations may happen less as a whole, true, but it is skewed in the benefit of those with experience - as would be the Major update in general since more experienced modders can take better advantage of it and bring more consistent results (that end users now expect!) each release.

So, imo, even though the desire for SemVer enforcement is well-meaning, it doesn't *really* solve the problem at the end of the day. It ends up making things more confusing for everyone, end user included, and makes a new modder's job even harder.

SemVer is great for tech companies and technical teams to manage their version control and choose release candidates for low-margin-of-error production environments, but it really has no business being enforced in a hobbyist modding scene. When a mod update breaks saves, it may annoy some end users, but its not like you are going to have to explain to a project manager why the release went so bad. It's a hobby you are doing for free.

Now, all of that being said, something like what was proposed here that would allow a modder, themself, to create CTDs based upon versioning within their own mod - and not globally to all mods - would be ok. That way, a modder can opt in to the additional pressure of increasing user expectations by controlling their mod's launch-ability when encountering mismatching versions. Unfortunately, that will still create situations where an end user posts on a newbie modder's thread wondering why their mod doesn't police its versioning like X mod does, but that is at least better than a universal standard of expectation for releases as would be found in a professional environment.

Nexerelin also has a "random faction relations" toggle

Ahh, that makes more sense, ok thank you for the info I did not know that! I'll keep that in mind. I assume it defaults to false, but if not, I'll look into maybe a soft override option for not-random-generated campaigns in order to help preserve the lore mechanics of the standard core starts. Probably not this update since my plate is full there, but the information itself is very helpful.

If no override option exists, oh well *shrug*. Custom start options from the perspective of a 4x design make sense, but it does help to explain why some experience reports seem to defy the intended lore mechanics from the Nex config. Honestly, I need to take a break and play a full campaign with Nex at some point to better understand all the mechanics there. Same for modern vanilla, really. I'm not sure I fully fleshed out a campaign since ~0.7-0.8 - though some of that was purposeful to not spoil anything for myself and then get a fresh new experience. Also - time spent not modding - obviously. It's a delicate balance alongside RL lol.

Announcements / Re: Starsector 0.95a (In Development) Patch Notes
« on: October 25, 2020, 03:30:07 PM »
Right, yeah; this is a good thing to think about, vis a vis "does this change encourage weird gameplay patterns". I'd be lying if I said I'd considered every detail (this was, to be honest, kind of an impulsive addition based on a suggestion from, iirc, Gothars), but!

I think overall having more/better officers will always be good - they do reduce the difficulty of the fight, but I think not to the point where it's better not to have them. It'd be pretty much impossible to do anything real meaningful without them. And, while officer level/presence matters here, it matters less than e.g. for deployment points distribution, so it shouldn't discourage putting officers in small ships. Player level - rather than specifically combat skills - factors in here, but, again, it's not an overwhelming factor. Weapons/dmods etc don't factor in; it's based off the base deployment points of a hull and officer levels. Again, though, I don't think it's something where trying to optimize out a dmod or two would make much difference.

(Officers that aren't assigned to a ship still count, since otherwise you'd be encouraged to unassign officers you're not planning to use in the fight... made that change just now, actually, since wasn't thinking about that aspect of it before.)

Overall, the hope is this is something that's worth playing around on the macro level - in terms overall fleet size/composition/engagement choices - but not on a micro level, trying to wring an extra couple of percent out of it.

I agree that TheLochNessCheeseBurger has a really good analysis.

To the point on officers, I'd say it won't matter if more officers are technically unattractive to get more XP as long as there are threats that essentially require them to beat. To this end, it will largely depend upon how strong combat skills are. If they make piloting skills impactful enough that the officer bonuses aren't needed for high level challenges, yeah I could see this becoming an issue for design.

Imo, there is always going to be a "most efficient" strategy to things and that is likely unavoidable. As long as there are situations where that doesn't hold true, I think that's fine.

A good thing about avoiding officers early, if this proves to be the case, is that it indirectly encourages players to learn to pilot better without stat boosts right out of the gate. It also means that additional fleet complexity is indirectly discouraged early on - which allows players more time to choose a playstyle.

If you have 3 officers with carrier skills, for instance, you are encouraged to play with carriers more than warships. In that sense, getting specialized officers too early somewhat limits an early player's desire to explore different ships and builds.

Thank you for the detailed reply, that answers everything I needed.

As far as the independent fleets are concerned - they became less of an issue after a bit of time had passed. I suspect that the independent fleets initially attacking me were largely "already" in my area or nearby at the time that my relation with them became poor, but once I cleared out enough of them and my colony defenses were working they became less of an issue. Or perhaps - since the Independents are rarely hostile to anyone - there was less of a risk of their fleets being destroyed, so they were too numerous until they threw themselves to their deaths upon my forces? I'm unsure, especially since I don't know how the spawning works exactly, but it seems to have resolved itself. Though I may want to look into this more in the future.

It makes sense from a lore perspective that they would dislike my saturation bombing. What confused me more was that the Adamantine Consortium had done the exact same saturation bombing to one of my colonies, and (at least with my mods) that should have made the independents hostile to them. Which in turn should have made them not care as much about my saturation bombing, as everyone else who hated the Adamantine Consortium "overlooked" the issue (which was pretty much everyone). Might be a Nex related issue.

Np! For exact stat comparisons, the spreadsheets are labeled pretty clearly by hulls size and weapon size/type. I'd probably wait until the next AO update to start modifying any other factions though. For one, you'll have access to the new designation hullmods that will be included. For another, the file/override structure of the mod has been greatly improved upon and it will be easier to decipher stats and such. I'm working hard on this today. I had taken a small break after making a bunch of new weapons (and I still have two more to make) to give more Legendary options and fill in some niches.

As for the independents thing, I'm glad the spawning seemed to hold true. I may have changed this is the update version so maybe this isn't accurate to the currently released version?, but I checked the Nex faction config and independents have a starting relationship of "Vengeful" with the Adamantine Consortium, and a 0.01 chance of a positive diplomacy event. Even then, the max relationship should be "Inhospitable" so it's weird that they weren't hostile to each other.

Adamantine Consortium, too, has a starting relationship of "Vengeful" with Independents and should be locked out of Diplomacy altogether.

So, maybe something else is coming into play or I have the wrong values for the exerelinFactionConfig files?? I'm not really sure. I'll have to ask Histidine for some advice for better control of the faction config. It should be really rare for those two factions to be at peace. Hmm.

General Discussion / Re: so how does security actually work?
« on: October 25, 2020, 02:08:34 PM »
You bought off the black market. The more you buy, the more likely a patrol will try to scan you.

There is also a way to look at how suspicious your overall transactions are and how likely a patrol will pursue you. If you hover your mouse over the black market icon, at the bottom of the tooltip it was say "suspicion level: none" at first but as you buy or sell off the black market it will change to "suspicion level: low" - "suspicion level: medium" - "suspicion level: high" etc.

The patrol chasing you is RNG, but this rating affects how likely or unlikely it will happen. Reputation is also a large factor here. So if you are friendly with a faction, even a "suspicion level: high" transaction is far less likely to provoke a patrol into pursuing and scanning you.

Also keep in mind that even if they scan you there is a chance that the patrol won't find your contraband and you won't lose any rep. If they do find it and the fleet is weaker than yours, I think you can simply refuse to hand it over for a rep loss - or just refuse the scan in the first place.

Also, during the transaction as your suspicion raises you can somewhat lower it back down again by also making transactions on the regular market to "cover" your black market dealings with legitimate business. It takes a disproportionate amount of legitimate trade to do this. One thing I like to do is purchase black market goods after a salvage run because I typically have a large quantity of metals to cover the black market transaction by selling the metals on the normal market.

General Discussion / Re: so how does security actually work?
« on: October 23, 2020, 07:44:51 PM »
Sorry you are feeling frustrated! (FWIW, it took me a bit to figure the stealth mechanics out too.)

This might help: Make sure you aren't using overly large or easily "spot-able" ships when you are trying to sneak. This is determined by your sensor profile - which notably increases with hull size and if the ship is considered civilian. Iirc, only the top 5? ships in the fleet with the highest number contributes to your profile, so the addition of even a single ship of a large hull size will make a huge impact.

There are some hullmods (insulated engines and militarized subsystems I think) that reduce this number for a given ship and can even negate the effect of the civilian ship's profile increase, and phase ships also have lower sensor profiles than other ships.

Once your profile is low enough, you should be able to see visible rings representing the distance where a patrol can actually see your fleet and from there it is just a matter of avoiding the rings until you can dock at the market.

Thank you for answering Echonian's questions! I appreciate it.  :)

First, welcome to Starsector and the forums and thanks for trying out the mod! I'm glad you are (mostly) having a good time with it. I'll add two things to Albreo's response:

1) Alongside the coming AI changes in the next Starsector update, the next Archean Order update will remove the jump ability from the Tyrant in place of a speed boosting system that is more punishable. If it makes the Tyrant weaker in the AI's hands until the official update, so be it. I'd rather that than a tedious battle every time. It might not weaken the AI with it though as one additional thing I've done is create some flux free builds. It might make the AI more willing to engage before its flux gets too high. We'll see I guess, I can't really afford the time to deep dive test its performance.

2) Sat-bombing a colony of any faction will make any faction that cares about atrocities (defined in the faction file under: "caresAboutAtrocities":true,) hostile or lose a lot of rep. Even though the independents hate the AC, from a lore perspective bombing not only kills dreadlords and barons but also the slaves that work in their colonies. That will make the independents angry at you for the collateral damage caused. I'm surprised that it didn't make the Sci-Corps mad at you too to be honest - but maybe distance matters? Either way, it's not something I directly manage in the mod. It relies on vanilla settings and mechanics there. Nex could also affect rep in different ways than vanilla, but I'm not really sure. Trying to change existing rep impacts would require way too much hackery though. It would make the mod incompatible with a lot of other mods.

FWIW that experience sounds highly annoying. From what I remember, I thought independent fleets wouldn't spawn from faction colonies that are hostile to independents and vice versa. I'm not sure if this directly applies to player colonies though - there could be something special going on I'm not aware of. If you have the save still, you could try setting that value to "false" for independents and then sat bomb the AC again and see if the same result occurs. I think it is still overridden in the current release, but I don't override a lot of faction content in the next update since its technically redundant unless I'm making changes.

For Console Commands:

SetRelation independent neutral (or w.e relation you want them at) should do the trick.

Since my previous post was answered more or less, I had another question.

Is there a particular balancing philosophy behind specific weapons, ships, or other aspects of this game which could be shared so that I might be able to potentially rebalance some faction packs to work properly with this mod?

I realize adding new factions officially might be too much work, but I'm considering the idea of doing the testing and implementation myself for one or two custom factions at least. Since I really love the custom factions in this mod as well as the combat changes, finding a way to make it work with other faction mods would be great (even if the lore might seem a bit odd).

I might not end up actually doing this, but it is something I have been looking into, so if it's even a possibility any relevant balancing information would be appreciated.

There is a set of balance sliders I use, yes. A *short* summary:

1) Weapon counts:

Frigates: 4-6 small weapons or 3-4 small weapons and one medium weapon, etc. If a hangar bay exists, 1-3 weapons. The more weapons, the less defense or higher the DP as a counter-balance. A built in wing is generally smaller and replaces slower than standard module wings, and either costs more DP or takes the place of a weapon or two.

Destroyers: Same number of small weapons but also typically 3-4 medium weapons. Slightly greater defenses and lower combat speed than frigates. Less maneuverability. Slightly higher DP. Destroyer carriers get 2-3 hangar bays (Epiphany now has 3 for the next update). Same number of small weapons but 0-1 medium weapons. The presence of a medium weapon should remove a hangar bay or have very high DP.

Cruisers: 8-12 small weapons and 4-6 medium weapons and 0-2 large weapons. Same stat differences that differentiate frigates from destroyers but by a larger margin comparatively. Carrier cruisers usually have 4-6 hangar bays and only 6-10 small weapons and ~2-3 medium weapons. Combat cruiser still have 2-4 bays, but can't use them as efficiently as carriers (will discuss details further down)

Capitals:  15-30 small weapons -- 8-12 medium -- 3-6 large (variance depends on DP/defense/role). Much higher defensive stats for capitals and low speed. Like cruisers, non-carrier capitals have 2-4 inefficient hangar bays while carrier capitals have as many as 10 efficient hangar bays. 10 is the max because with the hullmod bringing the total to 12 that is the most the UI can reasonably handle in the refit screen.

Weapon layout guidelines: Weapon arcs and position are such that at least 2 small weapons can be used for PD at most directions for a frigate or destroyer and 3-4 can be used for a cruiser. Capitals have the most overlapping arcs, but keep in mind that you can't overlap too many arcs for both aesthetic reasons and because that is oftentimes wasted ordinance when considering lots of small targets. At least 3 large weapons and 4 medium weapons should generally be able to focus fire on one target in the case of capitals.

Sprite size guidelines: Each weapon size is one size smaller relative to vanilla. So vanilla medium is AO large, vanilla small is AO medium, etc. From there, sprite size generally scales with OP cost or possibly the range of the weapon. Fighters are a lot smaller than vanilla, but typically have similar wing sizes. They replace slower and have less standard range than vanilla wings since carriers will buff these values with hullmods.

Weapon flux cost guidelines: Short range, low armor penetration and fast firing weapons don't usually cost flux. These are considered assault weapons. PD weapons also don't cost flux. Heavy assault weapons, such as the Railgun or Dual Railgun, fire with 0.2 - 0.4 flux efficiency considering they are longer range than the standard assault weapon. Strike weapons deal a lot of damage very quickly, but fire with 0.4 - 0.8 efficiency or have a lot lower sustained dps. The higher the armor penetration for an assault weapon, the lower range or DPS it probably needs to have. Fire support (or very long ranged) weapons have greater than 1.0 firing efficiency and lower sustained dps in most cases. Missiles are different. Many strike missiles don't cost flux but have very low sustained dps and can be heavily mitigated by PD (see Atropos) and long range missiles are also heavily mitigated by PD but have better efficiency to fire (~0.5 - 0.8) compared to non-missile fire support weapons.

Designation details: (these are done using built-in hullmods -- more of these will be added in the next update)

Frigates: +100% damage to strike craft -- +50% damage to missiles -- maintains 0-flux speed boost until 35% of max flux not considering skills.

Destroyers: +50% damage to strike craft -- +50% damage to missiles -- maintains 0-flux speed boost until 20% of max flux not considering skills.

Cruisers: Either -- (+45% additional non-PD weapon range -- +30% additional PD weapon range -- OR -- +20% additional weapon range) -- maintains 0-flux speed boost until 7% of max flux not considering skills -- has hangar bays unless a phase ship -- OP discounts to interceptors and fighters depending upon tech level/manufacturer.

Capitals: Either -- (+45% additional non-PD weapon range -- +30% additional PD weapon range -- OR -- +30% additional weapon range) -- maintains 0-flux speed boost until 7% of max flux not considering skills -- half the 0-flux speed boost -- has hangar bays unless a phase ship -- OP discounts to interceptors and fighters depending upon tech level/manufacturer.

Carriers (any size): Same designation benefits as warships but also -- half the 0-flux speed boost unless a capital which already has that -- 50% replacement rate bonus -- 100% range bonus for effective wing range -- OP discounts to weapons depending upon tech level/manufacturer.

Phew! That's a start anyway! Obviously these are just guidelines that I go by, and exceptions of all kinds exist in order to create unique ships. At the end of the day, playtesting is important both 1v1 and fleet simulations. I hope this helps give an idea of how to approach a rebalanced faction mod or creation of additional custom ones.

Announcements / Re: Starsector 0.95a (In Development) Patch Notes
« on: October 18, 2020, 06:03:21 PM »
Imagine if the endgame enemy was the Hegemony, and you were facing a couple of Lashers. Maybe with a pre-buff Enforcer thrown in there, to make it a challenge.

Wow that's even better than I hoped. That is... extremely exciting!



IIRC not generally, and unless the ship is panic-firing. But e.g. it might fire them at a high-flux enemy to force them into a tough choice, etc, so it's not a cut-and-dry binary thing.

Ah thanks for the info!

Announcements / Re: Starsector 0.95a (In Development) Patch Notes
« on: October 18, 2020, 05:29:11 PM »
Finally got through all the notes. Wow! I'm super excited for the new story content. Lots of quality of life improvements too.

Do the new enemies represent the intended pinnacle of enemy difficulty or are there more intended tiers coming after? (Being only a *hint* of end game after all)

The new fighter AI tags are interesting! What inspired those for vanilla? Or are they more for modders?

Also, does the CONSERVE_FOR_ANTI_ARMOR hint mean the weapon isn't used on shields?

Pages: [1] 2 3 ... 99