Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  


Starsector 0.9.1a is out! (05/10/19); Updated the Forum Rules and Guidelines (02/29/20); Blog post: GIF Roundup (04/11/20)

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

Pages: [1] 2 3 4
Mods / Re: [0.9a] Sylphon RnD 0.9.3
« on: January 16, 2019, 11:00:56 AM »
I think Dread Eagle plays much better now with the flux change, big thumbs-up for that. Putting everything into capacitors before to try to fit its role felt suboptimal compared to everything in vents.

Sylphon RnD - Update 0.9.4
- The Sylvetra's nanobots have had their metal-to-ammo gain rebalanced; they are now slightly better at refilling high-ammo weapons and slightly worse at refilling low-OP weapons (most notable on Reaper-like torpedoes)

Haha, the longer I wait to work on ICE the more all of its old specialties will look like they've been plagiarized from newer mods.

Also, did I meet you playing Dreadnought at some point (as "Anthem")?

Mods / Re: [0.9a] Vesperon Combine 1.0.0 - 13/01/19
« on: January 15, 2019, 05:53:25 PM »
There's no need to expend effort stopping them, you just choose to not pay them any attention and not let them bother you. But that sort of stoic doctrine seems unpopular nowadays and admittedly I've never been able to convince anyone that hasn't already had lots of practice following it. I guess on a forum there are logistical problems too.

I don't think the sand castle simile applies well, since it is still up to people whether they want to install his mod and presumably xenoargh is not going out of his way to make people install it. On the other hand if it advertised or implied high compatibility then that would be bad manners (I haven't looked). I am not familiar with the history so perhaps I am not qualified to comment more on it.

I think enforcing it in any way, even social censure, is a lost cause, but I don't think it's a complete waste of time to ask people who make mods that have wide-ranging effects on core gameplay systems to think carefully about how they do that.
All I was doing was recommending the best practice
You are right, and that is fine. But conveying it more courteously will only make it more convincing, and can be done just as succinctly.

But now I am splitting hairs. Looking forward to the update.

Mods / Re: [0.9a] Vesperon Combine 1.0.0 - 13/01/19
« on: January 15, 2019, 04:14:56 PM »
I respectfully disagree with many of posters here.

This is clearly a mod which at least some players will legitimately want to use. It perhaps warrants some sort of incompatibility warning, but whether it can exist and advertise itself for use should not be in question.

Mods for singleplayer games are opt-in; each player is responsible for managing how they want to play their own game, and even "ruin" their experience from your subjective perspective if they choose to, provided they don't try to blame everyone else. It is nice of mod authors to build in support for everyone else's mods and especially cool if it leads to proper tie-ins, but it is hard to argue that it even approaches an "obligation" for them to support inter-mod compatibility, much less wide-ranging compatibility that addresses edge cases in other mods which themselves work because of specific assumptions made about vanilla. Every single other modding community (Total War, for example, to cite a case where mod conflicts are a serious problem) simply deals with this by acknowledging that conflicts can cause bug reports in the wrong places, makes the first step of debugging is "what's your mod list" or perhaps "do you have one of these known high-conflict-risk mods installed", and making it perfectly acceptable for each individual author to say "that problem is caused by another mod, and I'm not willing or able to devote time to it at the moment". Starsector's modding structure is super-easy and innately low-conflict by comparison but I don't think that is good reason to turn about and paint wide-ranging compatibility as an "obligation" for other mod authors. Of course it would be another matter if that mod author was maliciously creating incompatibilities and stirring the pot, but there's nothing to warrant accusing Straticus of that. To turn the question around, why should new mod authors be "obliged" to write in special-case support for older ones, provided that they are not applicable to all players (e.g. graphical enhancements) but only cater to players that want a specific gameplay experience?

The thought had occurred to me to resist making this change
This would have been a perfectly supportable position, but I think where you're going is a nice direction too.

It's a nice idea for a mod that I'm sure lots of players will like, but it's undoubtedly going to be a huge headache for mod makers.
Other mod makers are under no obligation to provide tech support for this mod or anyone using this mod, and this mod is not forcing itself into anyone's game directory without player intervention. Individual players can trivially make their own edits and break mods, and what this mod does is not a difference of kind if it does not claim that it is highly compatible. You could make a reasonable argument that it creates more tech-support work for other mod makers, but that seems like a logistical (forum moderation, perhaps) issue rather than a fundamental problem.

-It breaks the number one ethics rule in any kind of modding, starsector modding or otherwise: Allow mods to OPT IN, don't force other modders to opt out or "code around" your mod. It makes it easier on both parties and helps with bug hunting. And by the looks of it, I'm not even seeing a way to opt out either...
- As Midnight said, it is ethically *highly* frowned upon to create work for other modders.
Citing "ethics" here is a long stretch for the above reasons, and I wager you know that and you are using the word in a more discipline-specific sense.

Some of this reeks a little of the same smell from that thread for xenoargh's balance mod, where much of the behavior and tone by respondents was frankly disgraceful for a community for a game that benefits greatly from different mod options. Assuming that individual players ("fools") can't be responsible about using mods by default is rather denigrating and pretentious, and in any case, it is not your business how others choose to play a singleplayer game with no scoreboard or competitive element, especially one where mods and base content are open in structure and easily modifiable by the end user. But it is also not anyone's obligation to support people who can't be responsible with using mods.

All that aside, I do think that there is an unsolved issue for authors that would rightfully like to hide some of the content in their mod, exert some control over how the individual mod is played, or discourage people from peeking into the files and ruining the well-crafted surprises (I regret looking at the Blade Breaker content and generation stuff before having experienced it in-game, for example). It would be nice if there was an idiomatic or officially supported way to do this. That's a separate question from whether this mod should be on this board. This one probably does warrant an incompatibility notice, though.

Regarding the mod itself:

I think it is a little bit too easy gameplay-wise, since money is so easy to get and the fleets aren't all that hard. It might be more fun if the trigger was something more difficult or fun but still more generatable by the player, like making it loot remnant fleets with custom compositions that require specialist fleets or are super difficult or something. It makes stuff too accessible for me to keep playing with it on.

Mods / Re: [0.8.1a] Sylphon RnD 0.8.1
« on: October 12, 2018, 10:06:00 PM »
Somebody's spent a lot of time playing around in Ar Ciel.

Mods / Re: [0.65.2a] ICE Faction
« on: June 28, 2017, 05:14:00 PM »
ICE was my favorite mod back in the day too, and I've been working on some code reorg on and off for a while in preparation to build the mod into a usable state in 0.8.1a. Life's been busy and I doubt I'll be done for another few months yet. If someone else wants to snipe it, be my guest. I've also yet to ask Sundog for permission, since I don't believe it's sufficiently complete to merit even considering release.

Some rambling: with the overall lowered combat lethality in 0.8, some significant balance issues with playing ICE in extended campaigns are less problematic, but there's still the fundamental issues:
1. balancing defense of phase-only factions in general, and
2. the weapon range "normalization" built-in hullmod combined with the weird ICE weapon ranges which make ICE/vanilla/other-faction interop weird and often unbalanced.

For the former: I've been tinkering a bit with a different system to change how ICE defense works to make damage taken follow a shallow log growth curve - basically, damage shaving that's increasingly effective against high single instances of damage. This is a way to address a frequent frustration (in my perception) with unshielded ships where you're much more vulnerable to instant death from e.g. Reapers or high-alpha strike weapons in situations where a shielded ship could just eat an extra-long overload, since shields are instant-toggle but phase ships are subject to the phase cooldown. There needs to be a downside too, which I haven't fleshed out yet - likely one of two things:
1. decreased armor damage reduction vs. low-damage attacks, e.g. a Hellbore hit will do reduced balance, but sustained Light Assault Gun fire will be more damaging than usual; or
2. damage reduction based on distance from your enemy, which may be impossible since iirc it's not yet possible to find how far a given projectile has traveled.

For the latter - I think it should just be removed, and weapons balanced appropriately so that they're not overwhelming when mounted on other ships but sufficiently useful on ICE ships. Achieving this could require some kind of penalty or bonus built-in to ICE ships, but the weapons themselves should be balanced to the vanilla baseline. The precise mechanics of the Falx beam are also a headache - it should probably stay a ICE-only builtin. Armor repair is a rabbit hole as well - maybe some sort of per-engagement cap, or have ICE armor breach earlier and "leak" hull damage at a higher rate so hull attrition can accumulate.

I'm not sure whether this will turn out to be a fun way to differentiate ICE or just a bad gimmick. I did really like how different the ICE playstyle was, despite the occasional balance problem, and I want to try to preserve that uniqueness while fixing some of the edge cases.

Deathfly, you planning on fixing up that EMP death throes functionality and adding it in? Seemed entertaining.

Mods / Re: [0.7.2a] Neutrino Corp. (v. 1.83RC3.6)
« on: June 23, 2016, 05:17:35 PM »
Bane and presumably Misery crash game when hitting Templar ships. The lattice shield's class has moved from data.hullmods.TEM_LatticeShield to data.scripts.hullmods.TEM_LatticeShield, and the import and checks in NeutBaneEffect needs to be updated.

Mods / Re: [0.7.2a] Diable Avionics 1.63 (10/04/2016)
« on: June 23, 2016, 04:58:47 PM »
Uhlan crashes game when placed in a hidden slot due to use of return from getAnimations() without a null-check in diableavionics_UhlanFire.

I guess there are not exactly many large hidden slots (none officially?), but in case you're fooling around with one, you can patch it with attached.

Old sprite was cool, but new sprite with animation is super-duper-cool.

[attachment deleted by admin]

Modding Resources / Re: [0.7.2a] ShaderLib Beta 1.2.1
« on: February 29, 2016, 09:18:44 PM »
Spotted infrequently, most recently in Duel of the Century:

141622 [Thread-4] ERROR com.fs.starfarer.combat.CombatMain  - java.lang.NullPointerException
at com.fs.starfarer.settings.B.getTextureId(Unknown Source)
at org.dark.shaders.util.ShaderLib.renderForeground(
at org.dark.shaders.util.ShaderLib.isForegroundEmpty(
at org.dark.shaders.light.LightShader.drawLights(
at org.dark.shaders.light.LightShader.renderInWorldCoords(
at org.dark.shaders.util.ShaderHook.renderInWorldCoords(
at com.fs.starfarer.title.C.o0oO$Oo.?00000(Unknown Source)
at Source)
at com.fs.starfarer.combat.CombatState.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$ Source)
at Source)

Maybe today's the day everything I knew about short-circuits gets overturned.

If a ship or wing is part of a control group you've defined previously but does not have sufficient CR to be deployable normally, you can still select it for deployment via the control group key only. When deployed, they will immediately retreat.

Is it possible to lock a weapon to a specific angle, aside from issuing a setCurrAngle() every frame? Is it possible to restrict the firing arc of weapons dynamically?

Are there any foreseeable issues with doing either of the above from a ship system, rather than a EveryFrameWeaponEffectPlugin?

Mods / Re: [0.7.1a] Diable Avionics 1.4 - More stuff! (09/01/2016)
« on: January 25, 2016, 12:19:47 AM »
I hacked an indicator together, if you want to take a look:

When I was testing this, I noticed that the range bonus definitely applies to all weapons, rather than just weapons under the range threshold as claimed. Try watching the default Calm's beam range in the simulator. Perhaps the lines after the getWeaponRangeMultPastThreshold().modifyPercent(...) call aren't necessary.

Playing with the indicator in place, I noticed that the great majority of fleet battles (even in the level >50 stage of the game) will be over before your capital ships can even spin up past normal accuracy. Might you consider making the boost stepping finer-grained (30s?) and reducing the required time for cruisers/capitals a little bit?

I also packed in tried exact copies of the Valiant, Raven, and Warlust set to alternate AI types (INTERCEPTOR for Valiant, SUPPORT for others).

Takeaways from comparing results from a few rounds in the simulator:
- Valiant combat AI behavior is unchanged. Not sure if increased response rate to Intercept orders would actually have much impact in a real engagement.
- Warlust combat AI behavior vs. single targets was greatly improved, I think. The FIGHTER role tends to do "attack runs", peeling off after a little circling to come back for another pass. This gives targets windows of opportunity to vent in relative safety. SUPPORT will linger in range and circle the target until it's dead or until individual fighters decide it's time to drop flux/refit. Warlusts will circle close enough to consistently fire the Grim. In larger engagements, results are less clear; SUPPORT has less of a tendency to overshoot the leading ships in the enemy line and get shredded by dense fire from the center of the enemy's formation, but the difference isn't very notable.
-Raven combat AI behavior is somewhat improved. Observations are largely the same as the Warlust. However, I noticed that SUPPORT does a better job at facing the target at all times, especially considering the Raven's slow turnrate. The aforementioned "attack run" behavior of FIGHTER often put the Raven in situations where it would be in range but wasn't facing the right way to fire.

Looks like both Ravens will use Flicker Core in combat, they just won't use it for transit. If you think it's worth the visual improvement, maybe setting the AI hint for effective speed increase to 0 might work? I'll give this a try later.

E: Link replaced.

Mods / Re: [0.7.1a] Diable Avionics 1.4 - More stuff! (09/01/2016)
« on: January 23, 2016, 11:37:21 PM »
Noticed a few things:

-It seems that only one Raven out of a pair will use its Flicker Core.
-I tried and got uncertain results, but alternate wanzer role settings might be worth a look. Warlust/Raven would make more sense as SUPPORT, and Frost/Valiant might work better as INTERCEPTOR, for example.
-The Valiant tends to untransform too late when entering combat, and takes some unnecessary fire. Perhaps the threshold should be 1.2x nominal range rather than 0.9x.
-Vapors will continuously use Evasive Maneuver on cooldown, even when holding still. Maybe a different AI type will work better.
-An indicator of the current level of Advanced Avionics would be nice.

New sprites are spot-on and really nice. Aesthetics-wise, I think the Hexafire's shot group could use some front-to-back separation in addition to the horizontal drift. It looks unnaturally neat at the moment.

Mods / Re: [0.65.2a] Blackrock Drive Yards v0.7.4
« on: October 16, 2015, 08:11:02 PM »
You should perhaps leave the self-righteous IP crusading to the content owners, who are unlikely to need your help.

I played a bit with the Krait Dragon. Spark Drive plus phase cloak on a large ship is pretty terrifying, but if it had fair flux stats and mounts it would probably be a cool ship to include in a campaign.

Mods / Re: Diable Avionics (v.1.05)[0.65.1a]
« on: July 01, 2015, 11:07:18 PM »
They've got to have some kind of disadvantage.

Pages: [1] 2 3 4