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

Pages: [1]
1
Blog Posts / Re: Of Slipstreams and Sensor Ghosts
« on: September 25, 2021, 12:20:07 PM »
This looks incredible!  One point of feedback -- the visual representation of slipstreams on the sector map needs to be scaled by intensity. 

In the examples, the slipstream indicators seem to have the same intensity regardless of width, so wider areas of the slipstreams stand out much more.

This is the inverse of the actual gameplay effects, where a narrower slipstream is 'faster' than it is when it widens out, a big fat wide arrow slipstream indicator stands out a lot more than the narrowest segments.

Thinner sections of the slipstreams would benefit from proportionally boosted brightness or opacity on the starmap to make them 'stand out', the way they will when you're zipping through 'em.

2
Announcements / Re: Starsector 0.8.1a (Released) Patch Notes
« on: June 10, 2017, 05:28:38 PM »
In battles against nastier opponents, I've had excellent results in 0.8.1 using a combination of ordering all of the less-survivable ships to escort something tougher and judicious application of engage/eliminate/avoid orders against specific enemies to provide an overall guide and take advantage of local mismatches.

Ideally, the escort pairings make sense, like two Lashers escorting a Hammerhead, or a SO Medusa with a Tempest escort.

This can even be chained, four Lashers escorting two Hammerheads that are in turn escorting a Dominator or something.

At that point, even an unlucky frigate is unlikely to get far enough ahead to become an easy victim, and your fleet can mostly be relied on to take care of itself.

3
Clearly volume isn't deemed to be working for Steam now, thus the paywall cash grab

Steam doesn't need a 'cash grab'.  By a conservative estimate, Steam pulls in $3B+per year in revenue for Valve... from estimates based on just their revenue streams that are publicly available.  That's comparable to Nintendo, Vivendi, EA, massive corporations with tens of thousands of employees.  Of all the arguments you could make, that's one of the least plausible.

4
The activation time for transverse jump has really cut down on the amount that I use it, especially dropping out of hyperspace.

It makes sense that TVJ shouldn't be a get-out-of-smuggling-free card in-system, but does it really need the activation time jumping back down out of hyperspace, where you can only use it within a small radius of a nascent gravity well and evading by dropping back through a nearby jump point is often easier than getting to the nascent gravity well to begin with?

The charge time coming out of hyperspace feels more like a useless delay without any corresponding gameplay benefit.

5
Suggestions / Re: Sensor Normalization
« on: December 23, 2015, 06:35:01 PM »
In terms of conveying everything that goes into it, though... that's where it gets complicated, and part of the question is just how much to explain. I mean, talking about "logarithmic dropoff" is probably not a good idea.

... it'd be a lot simpler if ships could just contribute a linear amount. Too bad this leads to ranges that just don't work out gameplay-wise - either super-tiny on the low end, or super-huge on the high end.

I think this is one of those situations where trying to keep the mechanical calculations elegant is a losing battle.  Starfarer is already condensed to 2D, even pseudorealism can take a back seat to being intuitively explainable.

I propose a hybrid exponential system:
  • Per-ship contributions can be presented to the player in terms of standard covered area rather than an arbitrary range.
  • Summed coverage areas represent the total circular sensor/detection area of the fleet vs. a lone frigate.  The radius of this circle can be substituted for however base fleet detection ranges are currently calculated -- linear individual ship contributions to total covered area, making individual ship contributions scale exponentially to effective fleet ranges.
  • Fleet modifiers can then be applied as in the current system.

 (following numbers made up-- individual ships can start balanced approximately where they would be now.  )

Say an Onslaught is visible to a 'standard' baseline frigate sensor array at half a parsec - 500 units.  This range defines a circle with an area of ~758,000 microparsecs².

A lone phase frigate on the other hand is way harder to see, and that frigate would need to be within 100 units -- effectively a circle of 31,500 µpc².

The two ships combined have a standard sensor visibility of 789,500 µpc², or a circular radius a bit under 502 units, so 502 milliparsecs is the value shown in the sensor range displays on the main screen.  Adding a phase frigate next to an Onslaught has a minimal effect on the distance that the Onslaught would normally be visible.  

Adding a second Onslaught to this fleet takes us to 1547,500 µpc², or a circular radius a bit under 702 units.

The same concept could be applied to sensor strength, which right now is very abstracted and does not do a good job conveying of what the actual effect will be of changes in fleet composition.

Putting it all together:

  • Individual ships get a meaningful, context-independent standard coverage area to display for their base sensor/detection values.  This is good on many levels, I can only imagine what a nightmare it is trying to visualize and balance ship stats against normal usage and edge cases in the current system.
  • The tooltips for detection range display contribution in area on a per-ship basis --  ShipInfo - Current Sensor Coverage Area (base) - Current Detectability Area (base), sorted in descending order by coverage area or detectability depending on which display you're mousing over.  This provides instant feedback to the player about the sensor/visibility contribution of individual ships.

Let's say we have a Medusa and Wolf(D) that have some negative modifiers, so they are more detectable than they usually would be.

ShipSensors(base)Detection(base)
Medusa185,000µpc²(185,000)220,000µpc²(100,000)
Wolf120,000µpc²(150,000)180,000µpc²(40,000)
Fleet Total305,000µpc²(305,000)400,000µpc²(140,000)

This gives us a standard sensor range of 312 units (milliparsecs) and a standard detection range of 357 units, the approximate ranges where an unmodified lone frigate would expect to see/be seen this fleet.

Stuff that affects the entire fleet could scale the per-ship contributions appropriately in the tooltips, although I'm not sure how you'd display all of the multipliers cleanly without nested tooltips, which sounds terrible.

Also, this provides the opportunity to add other per-ship scalars and convey that information to the player in an intelligible way.  A wolf with a fleet travelling at burn 6 doesn't need to burn at full speed, and has the ability to hunt around a bit without needing to stick to the main fleet's course like glue --> minor bonuses to coverage from being able to move out a bit for a better view, minor reductions in detectability because the engines aren't burning full-blast.  Or however we want to run it!

6
Announcements / Re: Starsector 0.7.1a (Released) Patch Notes
« on: December 05, 2015, 05:30:07 PM »
I think of hostilities involving the independent faction as a result of the other faction authorizing attacks against neutrals from their side.

Something like "Unrestricted Hegemony attacks on neutral shipping have resulted in a state of hostility between most independent groups and the Hegemony navy."

Independents don't have to be a unified faction to have a de-facto state of war with a faction that is, whether that is ranging from "Hegemony forces have banned neutral shipping in the Corvus system." to "Tri-tachyon is reacting to recent attacks from disguised Luddic Path forces by treating all unaffiliated ships in the sector as hostile."

Gameplay wise, it should be rarer, and hostilities should be initiated only by organized factions who have some reason to do so.

7
General Discussion / Re: .7 just isn't fun ...
« on: December 01, 2015, 04:18:01 PM »
I find that it helps with the early game to accept that the AI my plucky crewmen are better than I am at some most micro aspects of combat, not least shield micromanagement and targeting small/fast objects.  I haven't been a teenager since the 90's, and there are reasons that the youngsters are the ones with their itchy trigger fingers on the twitchy buttons.  Putting the ship in a tactical situation where my AI minions / auto-firing weapons groups can take care of business while I think about what we should be doing is my job.  Situation under control?  Autopilot algorithms My brave and experienced crew are handling it.  All of a sudden that Enforcer over there is venting/overloaded and needs a well-placed reaper?  BEWM, I'm on it.

I'm not a one-man armada, and that's OK.  I've got virtual minions for that, ignoring the strengths they contribute is a handicap I can't afford in an uncaring sector.   ;D

In my view, the changes from 0.7 are uniformly excellent, the AI feels much more capable all around and officer personalities are great, and the 0.7.1a changelog makes me feel even better about the prospects for being a senior lunatic officer making my way in the 'sector.

8
Bug Reports & Support / Re: Some tooltips need revision
« on: November 25, 2015, 08:42:38 PM »
Related, the Burn Drive tooltip seems to be the reverse of what is intended. 

It says "The following ships are the slowest ships in your fleet:" but incorrectly lists the 10 fastest ships, so the current tooltip is not helpful for knowing what to change since fleet speeds that are restricted by the slowest ships.

On the plus side, running into this issue and wanting to analyze burn drive speeds in general eventually led to finding the ship_data.csv file, which is awesomely handy.

9
Blog Posts / Re: Let Me Draw You A Starsector Ship, Part 1
« on: May 17, 2014, 04:06:20 PM »
Saw new blog post.  Cheered.

Saw poster dgbaumgart.  Tickled memory.  Thought.

Familiar somehow, dgbaumgart... from Clockwork Empires!?!

Sudden paranoia. 

Could David Baumgart right now be stealthily involved with developing more games I'm anxiously awaiting?  And if so... how?

10
Blog Posts / Re: Comm Relays
« on: April 21, 2014, 05:30:19 PM »
It's entirely plausible that spending a lot of time around a giant, somewhat mysterious, high-tech installation capable of interstellar high-bandwidth FTL communication might be either unpleasant or actively unhealthy.  That's how I'd spin it, anyway.

11
Bug Reports & Support / Fatal: Ship hull variant CTD
« on: October 13, 2013, 05:06:45 PM »
So, I've been running into a CTD unpredictably when I take ships from the Abandoned Storage Facility and add them to my fleet.

Code
Fatal: Ship hull variant
[exported_variant_hammerhead_6d8ea2d8-b86f-45b6-b705-c75d077eedd9] not found!
Check starsector.log for more info.

Code
697111 [Thread-6] ERROR com.fs.starfarer.combat.String  - java.lang.RuntimeException: Ship hull variant [exported_variant_hammerhead_6d8ea2d8-b86f-45b6-b705-c75d077eedd9] not found!
java.lang.RuntimeException: Ship hull variant [exported_variant_hammerhead_6d8ea2d8-b86f-45b6-b705-c75d077eedd9] not found!
at com.fs.starfarer.loading.L.super(Unknown Source)
at com.fs.starfarer.loading.SpecStore.super(Unknown Source)
at com.fs.starfarer.campaign.fleet.FleetMember.super.float$Object(Unknown Source)
at com.fs.starfarer.campaign.fleet.FleetMember.<init>(Unknown Source)
at com.fs.starfarer.campaign.fleet.FleetMember.<init>(Unknown Source)
at com.fs.starfarer.codex.ui.Object.<init>(Unknown Source)
at com.fs.starfarer.codex.ui.E.super(Unknown Source)
at com.fs.starfarer.codex.ui.E.do.super(Unknown Source)
at com.fs.starfarer.codex.ui.E.øo0000(Unknown Source)
at com.fs.starfarer.coreui.B.actionPerformed(Unknown Source)
at com.fs.starfarer.ui.privatesuper.super(Unknown Source)
at com.fs.starfarer.ui.F.processInput(Unknown Source)
at com.fs.starfarer.ui.OoOo.o00000(Unknown Source)
at com.fs.starfarer.OoOO.øÒÒ000(Unknown Source)
at com.fs.super.oOOO.Ò00000(Unknown Source)
at com.fs.starfarer.combat.String.o00000(Unknown Source)
at com.fs.starfarer.StarfarerLauncher$2.run(Unknown Source)
at java.lang.Thread.run(Thread.java:619)

The only commonality I can think of is that any ship that has crashed has been running a custom variant.  I have been unable to replicate this crash by re-loading the last saves. 

Other possible risk factors:  I use the same save folder with separate starsector installs on multiple desktops via the magic of cloud storage, so I suspect something may be expected outside of the save when a custom variant is exported.

When a custom variant is exported, is it included in the savefile, or is that information expected somewhere else?

12
Alex -
Just a quick heads up that W+A+S+D testing via keyboard is not entirely reliable when troubleshooting possible input-conflict issues.

The contact overlays used on most modern membrane-switch keyboards are not physically capable of discerning additional keypresses or releases when some related combinations of keys are already active.

Any two simultaneous keypresses are guaranteed to register correctly even on the cheapest keyboards, as each combination has a unique signature of an input being shorted to an output.  Additional keys may not register dependent on how the contact grid is wired-- mo' manufacturing resources assigned to additional contacts or layers typically being associated with fewer keys associated with any given input or output and thus a better chance that additional keypresses won't run into a conflict.

In case anyone is curious, imagine the simplest setup: Nine keys, each row of keys is assigned to an input A/B/C, and each column is assigned to an output X/Y/Z.  Pressing the key makes contact between its input and output.

So, the sequence of events is:
First key A-X  outputs connect AX - only one keypress combination produces this state.
Second key B-Y outputs connect AX and connect BY - only one keypress combination produces this state.

At this point, adding either the key A-Y, or the key B-X outputs connected ABXY, so EITHER keypress combination will have the same output.  Designers tend to avoid false positives, so this input will not register because there's no way to tell which was actually pressed.  Other permutations can get even weirder, like AX then BX then CX then CY each registering because there is only one keypress that can produce the state changed, but leaving the system in a state where releasing CX will not register because the output does not change.

Rule of thumb:  Two simultaneous keys will always register correctly.  Three keys will usually work. Four keys in one area of the keyboard is likely to run into trouble for many users, and in nondeterministic ways because it is entirely dependent on the keyboard's internal layout.

"Crap, when i tried to jump, strafe left, move forward, and melee, it didn't smack him in the face!"

A massive geek am I. :P

13
Suggestions / Re: RFE: undecorated windowed mode.
« on: December 18, 2012, 08:26:26 PM »
Seconded.  Borderless windowed mode is by far the optimal solution for multi-monitor setups.

Alt-tabbing runs into all kinds of native color depth and screen-switching problems, whereas borderless windowed just works.

Pages: [1]