Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Starsector 0.97a is out! (02/02/24); New blog post: Simulator Enhancements (03/13/24)

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 ... 42 43 [44] 45 46 ... 143
646
Suggestions / Re: NPC fleets "taking" missions outside the core
« on: November 07, 2020, 02:45:25 PM »
Ah yeah! I think it makes a lot of sense to tie flavor to dynamic events that already exist. That way the flavor itself is dynamic.

Unless it proves to be too complicated to implement or otherwise exploitable, it would be really satisfying to have these events fork into other events from "cause and effect" that the player can weigh in on or ignore. There could be a standard path (with a couple different random outcomes even!) if the player ignores the event, such as:
Bounty > NPC bounty hunters > bounty hunters fail > distress call near the bounty location > NPC rescue operation fleet

But then if the player interacts with the event at one point in the chain, it changes the outcome and creates a different effect tree:
Bounty > NPC bounty hunters > bounty hunters fail > distress call > player intervenes > gets pointed to nearby bounty with an increased reward

 - Stuff like that

647
I like this too and I agree that max CR reductions are the simple way to simulate this. Capping max hull/armor/flux cap would be more visually cool though.

One thing to consider however is that this should probably be designed as a "heavy on flavor and light on gameplay consequence" kind of change. Otherwise, it runs the risk of becoming an unintended and very tedious limitation to exploring outside the core. I like the idea of the salvage gantry removing or reducing the penalty though. If that vessel were ensured to be accessible fairly early on, for instance, then I could see this suggestion as more playing into the "build a fleet for exploration" kind of playstyle that requires more thoughtful choices on what ships to bring, etc.

I'm sure there are some who would resent the need of yet another ship cap slot being "mandatorily" not a combat ship though. My personal opinion as far as that is concerned is that such things are necessary both to make the civilian/utility ships useful/desirable in general. I don't necessarily think a player should be able to get away with a mostly combat ship fleet unless they are near a resupply point. It is another way to create unique challenges for the player based upon factors other than just how big or strong the enemy NPC fleet is. Less combat ships being a requirement to get to the location is interesting rather than frustrating - at least to me.

648
In terms of how modded ships and weapons look and feel the only way I see if it's made into its own separate mod if the mod author really wants his ships to be able to go toe to toe with AO's ships.
hopefully, someone makes a ship or faction mod that fits this mods theme and design

another question, how do you dictate how much flux and hull the ships have? since I want to modify the mod ships flux and hull to be at least comparable to that of AO without making them op

I can give you a rough guide to the considerations there, but the best thing to do would be to use the spreadsheet. Here, I can link you the most current one from the pending update since I think it is the most balanced. (This won't work with the existing mod, so DONT OVERRIDE your existing one. This is for reference only.)

In general, hull depends upon the size of the sprite but also the DP of the ship. The ratio of increase between each hullsize is such that the difference between frigate and destroyer is relatively large, but the difference between destroyer and cruiser is relatively small in comparison. Capitals have a very large amount of hull.

Armor and flux stats are, for obvious reasons, a lot trickier. You'll see that heavily armored ships tend to have all flux stats nerfed in comparison (this is actually a bit different than vanillla which uses shield efficiency as a separate balancing tool for ship uniqueness - though it still tends to scale "up" in terms of shield effectiveness as tech gets newer). What I mean by all flux stats is that they have stacking downsides of worse dissipation, worse shield efficiency, and lower max flux all at the same time. Their armor is significantly better though and their ship systems often take advantage of that for a burst of speed and sometimes increased offense potential - depending upon the ship.

Just like vanilla, midline ships are a balance between the two principles. Their ship systems are generally either mobility or defense-oriented and they tend to be able to field more fighters either defensively or offensively. For the midline capital, it stands out among other capitals because it has a significant built-in range increase - similar to the vanilla Paragon's design (the Paragon is a speedy damage powerhouse).

High tech ships have the best shield efficiency and flux stats in all cases. They also have virtually no armor and high DP costs. If a ship has built-in wings and isn't a cruiser or higher, it gets a spike in DP cost as well.

Conversions, civilian ships, and combat freighters all have their respective stats reduced slightly. At least most of the time.

Numbers are in the spreadsheet for benchmarks. For instance, you can see that the range of shield efficiency between low-high tech is 1.25-0.6 but most ships fall into the 1.15-0.85 range with a couple of outliers in the extreme sections of the spectrum.

649
Hello there!

First of all great mod, I've been playing it more than the original game for quite a while now.
I feel like this mod makes the ships and weapons feel quite powerful while the overhaul to the wings is also really amazing.

My question at the moment is if there are any faction mods that are compatible with AO (other than interstellar imperium)
and if there is any way to balance out the faction ships to be able to keep up with AO ships

Thanks!  :)

In the current update, I'd say most faction mods that make their own ships/weapons and don't use vanilla ids should be compatible. In the next release, I have removed the override behavior of most of the vanilla stuff (variants I think are the only exception for now) so that should open up the mod to most if not all faction mods to be crash free.

As for balance, here is a brief summary of how I design the mod's balance (brought down from an earlier post for convenience):

Spoiler
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.
[close]

Keep in mind these are more like guidelines and to get a real sense of the scale that I tend to shoot for would require study of the data spreadsheets for things like weapons and hulls, etc. Another thing that is going to prove difficult without sprite edits will be hullsize scaling. The addition of more small weapons as a part of the aesthetics of the mod and a defining difference between hull sizes makes balancing against standard vanilla balance very tricky. Even if I mathed out the percentage of dps for 1 AO small weapon to 1 vanilla small weapon on the entire spectrum of damage range, for instance, that would work maybe for frigates and destroyers but not cruisers or capitals, if that makes sense. If I balanced around capitals, then frigates would feel off. It is kind of like fitting the square block into the circle hole unless the mod follows the same weapon scheme for hulls (described above).

TLDR: Balancing other factions will require a certain amount of modding ability that will vary from mod to mod. (For anyone who doesn't already know: Please do not publish any rebalances without the mod author's permission - but personal use is fine. :) )

After I release the next update I may formally make a post in modding and add more detail to it over time. That would get a more comprehensive guide going, but for now the update is enough work as it is - way more than I anticipated, actually. Variant overhauls are brutally tedious lol. Full disclosure: RL stuff has gotten more demanding of my attention lately as well.

650
Modding / Re: Modding-wise, what is most exciting about 0.9.5a?
« on: November 02, 2020, 02:45:54 PM »
Quest API definitely, but I'd say a close second would probably be the combination of more fleshed out raiding mechanics and story points tying into said quests.

Then there is the newly announced additional weapon groups, improved phase AI (and really AI across the board) and several very useful new AI hints for weapons and fighters.

Idk I feel like a kid in a candy store, honestly!  :D

651
Suggestions / Re: Finer weapon control without needing more weapon groups
« on: November 01, 2020, 02:25:52 PM »
Whoa! Thanks Alex!  :)

652
Suggestions / Re: Finer weapon control without needing more weapon groups
« on: October 31, 2020, 11:54:20 AM »
I presume this would have virtually no effect on AI loadouts.

Hmm, I'm not super keen on additional things that further differentiate the AI and the player's capability - such as this implication would likely result in. The benefit of additional weapon groups is that it allows for more weapon types for AI ship builds as well. (UI issue makes that tough, certainly, but if work was done on weapon control I'd rather it be towards that then additional fine tune functionality for the player only.)

Now, if the AI could be adjusted to also support the unified/separated idea then I'd be all for it. I feel that the use case here is more for missiles than for other weapons anyway. They tend to have more niche uses that require timing to be the most effective - so grouping different types together is generally not a good idea.

653
Modding / Re: Additional mod_info flags / mod version stuff
« on: October 30, 2020, 01:01:13 AM »
*delete please*

654
Modding / Re: Additional mod_info flags / mod version stuff
« on: October 29, 2020, 03:34:53 PM »
Re: False Positives and False Negatives

Yes I understand that and why it is appealing and that it would save someone (including myself) some extra time, potentially. I'm talking about the psychology of user feedback. Making the lives easier of experienced modders inherently widens the gap of what is overall acceptable to the average user. Sad but true.

Let me put it another way. You have 3 restaurants. 2 of the 3 make a mistake 10/100 times and automatically refund your meal, no questions asked, for 7 of those 10 mistakes without a trip back to the restaurant. The 3rd restaurant makes a mistake 35/100 times and you have to return your food with a receipt within 30 minutes of pickup - untouched - for a refund.

Which restaurant are you likely to get food from?

I'm not against meritocracy or anything, but the odds of restaurant 3 going out of business (a.k.a a new modder sees the quality and automation gap between their mod and others and is overwhelmed) are a lot higher with a lot of these kinds of automation in place. The more complex or the higher amount of automation "plugs" required for QOL features, the less likely they will all get picked up and the worse those who do not pick them up look.

Now I want to be clear that the above reason isn't justification enough to not make our lives as modders easier sometimes. It's just... well a very real side-effect. So, I would caution against going overboard with it. I'm also not saying that this particular suggestion is overboard and I know it's opt-in and all that, but I did want to bring up this downside as a part of the discussion.

(I think modders who are used to a professional development setting often want to utilize those principles and have the same QOL support as they would have there... but you have to be careful because this isn't a professional setting and to make it seem like one will kill the desire of the hobbyist to get involved. I can't speak for everyone, but I only got the degree I did because I started modding as a hobby a long time ago. I chose Starsector, not just because I could see the game's potential and boy was I right! - but also for the very reason I bring up - that it had an "ease of access and expectation" when considering other moddable games. In short: it was one of the easiest games I could find to mod at the time. Maybe this makes me foolish as I get that technical considerations like compiling code into a jar, etc, become necessary in the long haul. As much as I understand that, I still try and do my best to keep it accessible when stuff like this comes up.)

"Hey there is a 1.4.5 (internal 23) - go try that first!" is wrong, user is on 1.4.4 (internal 22) so he can only use internal 22 (1.4.4).Also, same as above, we can get Major from save and tell user to user downgrade to the latest Major release.

Whoops - typo! I meant 1.4.5 (internal 22) - so compatible with any internal 22 release but not the 2.0.0 (internal 23) release.

But anyway:

User with 22.4.1.0 that upgraded to 23.1.3.4 should revert to latest 22.x.x.x.
User with 23.0.8.5 does not need to revert, as line 23.x.x.x is save compatible with any previous versions in that line.
In both cases we can present user correct version to downgrade (download latest Z.x.x.x, where Z is already stored in a save-game).

This is what I mean by "too smart" though. You are wanting to use the version in the save to allow for parsing the compatibility component (hence exposing Internal/Major as compatibility) in order to use logic to determine "best backward compatibility" (so as you say - detect the Z from Z.x.x.x or x.x.x.Z or x.Z.x.x, etc)

Alternatively, instead of through code logic on save load, if a user does ask about it, (so the primary purpose of version control to avoid thread support has failed, as it were) - then you at least have a frame of reference (if they know the save version, mind you, as the app version doesn't matter) to say "latest" Z.x.x.x update should be fine to use.

Yeah I can definitely see the appeal.

My point is that, while admirable, it would be far simpler to just forget about Z altogether, and use the launcher's logic to simply display the version from the save - and recommend that - instead of the extra step of trying to find a better/newer version with the same compatibility level - "Z". That way, Z doesn't need to be in the version and won't get confused with content (especially because most games version themselves around content not compatibility).

The benefit to what I will call "finding the best Z" as you are describing, is that it can potentially allow the addition of some new minor content or bugfixes during midgame for the user. The downside? If you are wrong somewhere along the line, especially if you are not made immediately aware of that fact (think of the hullmod example) then the additional complexity is pointless and more confusing. Since you are correct that mistakes will happen even with intensive testing, I'd say simple is best here.

For instance, I'd hate if a user was on bug-free stable version 23.1.4.5 and came back to the game after a while and updated to 24.2.5.3. The message would say "Revert to the latest 23.x.x.x version" and they would see that 23.2.5.1 was the latest in this case. I think it is unwise to assume that 23.2.5.1 would be the best reversion. It could have additional bugs that were fixed in the first 24.0.0.0 version but weren't present in 23.1.4.5 (yes I get that is a mistake of the modder to not patch 23.2.5.1 to 23.2.5.2 but trust me it can happen with large projects - cutting a release takes time and sometimes you just want keep moving on with development), or worse, be one of those updates that slipped through the compatibility cracks and breaks the save further down the line.

That's a headache for everyone when the simpler solution was to just paste the original save's version in the message. Errr, is this making sense? lol It's hard to translate brain to text sometimes and I'm fairly sleepy atm.  :P

Anyway, good discussion and thank you for being courteous!

*EDIT*
That's a headache for everyone when the simpler solution was to just paste the original save's version in the message. Errr, is this making sense? lol It's hard to translate brain to text sometimes and I'm fairly sleepy atm.  :P

I reread this and just in case it came across as sarcastic: I'm genuinely trying to think of ways that this kind of feature can backfire.

655
Modding / Re: Additional mod_info flags / mod version stuff
« on: October 28, 2020, 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 23.1.3.4 and one user has 22.4.1.0 and another 23.0.8.5 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: 23.2.0.0 - 22.1.4.5 - 22.1.3.0. The message is still going to be pointing the user to their save's version - 22.1.3.0 even if, via the version control, 22.1.4.5 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.

656
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.

657
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! ;)  )

658
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.

659
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.

660
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.)

Pages: 1 ... 42 43 [44] 45 46 ... 143