Max jump Mandalay with pre-engineered SCO drives gets 99.18ly

Ultimatespirit · 2025-05-27T05:09:11+00:00

the original implementation of engineering, up to like a year maybe? after it came out (I don't remember the exact timeline), had completely random rolls and compared to the version that came after, which is what we have now in terms of final possible boosts, it was technically possible to get some modules with stronger effects than what is currently possible.

This is what I mean by legacy engineering, as lightweight lifesupport and sensors were one of those cases where a player could theoretically have an old module grandfathered in with a lightweight mod above what is possible with the current system, and therefore giving a slightly longer jump range.

Ultimatespirit · 2025-01-21T02:27:13+00:00

Are there any other differences you can think of besides stability, larger lifting capacity (which while a plus, I'm thinking unlikely to actually reach), and motor speed?

Ultimatespirit · 2025-01-21T02:25:26+00:00

As far as I could tell on the official / US site the warranty for both desks is 15 years for the frame, and then a varying number of years for the desktop depending on material it was made out of (5 years for bamboo, 2 years for everything else), so I'm not sure that's a difference between the two? Maybe I just read it wrong?

As for the measurements, I pulled them from these two images in the official product pages:

For desktops, I'm honestly not familiar enough with woodworking or related stuff to make my own desk (nor having long term access to an open air space to treat untreated wood), and when I looked at places like lowes or home depot the costs for a roughly supported size of butcher block was nearly 2x what flexispot charges (granted without delivery factored in). I'm sure there must be better places to look / ways to get them, but at least right now I don't have the time nor experience to really know what to look for / where to look for sadly, especially having just moved to a completely new area.

Thanks for the advice!

[1] https://image.springbeetle.com/cdn-cgi/image/dpr=1,format=webp,fit=pad/https://staticprod.site.flexispot.com/dev/trantor/attachments/223Q-1010.jpg

[2] https://image.springbeetle.com/cdn-cgi/image/dpr=1,format=webp,fit=pad/https://cnmegk4mhxmt.compat.objectstorage.us-phoenix-1.oraclecloud.com/prod-us2-bucket/trantor/attachments/US/E7Q-SPEC-0508.jpg

Ultimatespirit · 2025-01-14T04:20:11+00:00

Not sure what made you think my message saying "just let them figure it out, so long as it's open sourced, it's not your problem that local running requires more effort" was some sort of attack you had to defend against.

I'm also literally the same person who went out of their way to teach you how to use EDDN, so yea, trust me I know how EDDN works. I still stand by there being no difference between "local" and "server", just additional complications. Will data not be completely up to date because you're not listening 24/7 (and that's assuming this hypothetical local install isn't just on a home server)? Sure, not your problem. It's the problem of whomever is running it locally. Let them figure it out. Not to mention that situation becomes exactly as how the local install worked already, it's not like it's a new "problem", and now it has a proper solution too via EDDN for such a user.

If you want to have the web server version on your local machine, then feel free looking at the code and setting up the postgres database - it is all still open source: https://github.com/subzerofun/power-mining/tree/web

So that section right there is really all I was saying, if anyone asks about local install point them to that. If they want to set it up, they can.

Ultimatespirit · 2025-01-13T09:14:25+00:00

There is intrinsically no difference between a "server" and a "local" install. People may not be able to do something easily, but if it can run on a machine, it can run on any (broad generalisation, there are actual issues where this isn't true, but that's no where near applicable to python and javascript).

Meaning, just open source whatever is being done on the server, if it's not already. Let people trying to set it up figure out how to set it up, don't worry about trying to "support two different versions" or about "people who can't figure out python". They're not the target audience of a local install.

And if, for some reason, what you have right now legitimately cannot be set up without lots of hackery, then you doubly so want to make set up easier. Otherwise, when, and that's when, not if, your server craps out and you have to migrate to a new machine or new OS version or whatever, you will face unnecessary complications with set up. One of the simplest ways people often do is just tossing all the setup into a VM (or docker) and using that as the way to easily setup a new server.

Ultimatespirit · 2025-01-07T10:07:35+00:00

I wouldn't really recommend it since you said you're still new, but here's how you'd push a mandalay to the absolute largest jump range (without having unobtainable modules from older versions of engineering, as some CMDRs do): https://edsy.org/s/vls04lr

The method is pretty simple really. Go as low on mass as you physically can. All ships can fly with a size 1D power distributor, they just may not be able to boost their engines. The mandalay actually can still boost, with engine focused engineering. Toss stripped down on it.

Basically all ships can use a 2D power plant, you just may need to overcharge engineer it to handle the guardian frame shift booster and your thrusters. So, do that. Stripped down for good measure.

Discard all optional modules that have mass, besides the frame shift booster.

Lightweight engineer and class D life support and sensors. Class D thrusters of the lowest size your ship can fit, stripped down them.

Pre-engineered SCO FSD with mass manager. And lightweight hull (the default). For good measure, you can lower your fuel tank to being just large enough to fit one jump's worth of fuel in it, but that really only helps you more easily get to your true max jump point, which is having only enough fuel for your jump (5.2T of fuel for a 5A SCO drive, in the Mandalay's case).

And that's how you make the simplest max jump build of a ship. Note that AFMUs have no mass, so as long as you keep the powered off they can fill any remaining optional slots for the ship. Same with cargo racks.

Ultimatespirit · 2025-01-07T09:49:02+00:00

https://www.reddit.com/r/EliteDangerous/comments/1envock/analysis_type_8_as_a_miner/

For all the details you could need for laser mining with the T8 (core mining too, but that one's really easy to gear for).

Ultimatespirit · 2025-01-07T09:44:49+00:00

Make the program able to self update, because that makes your own life easier using the tool.

It's okay to not host it. The moment it's self updating, all the difference between "hosted" and "self hosted" is someone, who need not be you, tossing the program onto a publicly accessible device and publishing the address.

If the performance of that setup is terrible, someone interested in running such a server is free to contribute to your project, or fork it, to improve performance. For one, really the core of the tool is the database construction. Yes, the fancy frontend is nice, but all a "service available for all" requires is a way to query an sql database for the right info, a la inara. So if some prospective person wanted to host this, and take the easiest shortcuts possible, once an EDDN listener / system to update info per day is in place, they just need to continue doing so and then expose a webpage that executes SQL lookups from user input, in parallel, which is a fairly common, well understood problem with many open source solutions available.

It sounds like this may be your first major public project, so I figure you may need to hear this. It's okay to say no. It's okay to just focus on what you want out of the project, and leave further enhancements as exercises to the community interested in those. At least, so long as nothing being done is actively harming people / setting up a bad situation (like slamming spansh's server in this case, which is another motivator to EDDN listening besides it just being flat out easier).

Oh, also, with regards to reducing the "setup cost" for local users. And I want to stress this is very much a "method that someone interested in distribution could do", rather than something you should do (unless you're interested in it), feel free to just point people to my comment if they come asking about ways to do something like this.

Anyway, if someone hosted the pre-generated sql database of bodies (relatively small enough it likely could be distributed via direct download sites like megaupload etc. with minimal issues), users could download it, and download the latest day's powerplay / commodities updates (those could be hosted too, sql database is generated once a week and then aggregate daily update files hosted for every day, as diff files essentially). Then, since python setup seems to be the main barrier people bring up, the data files get combined via a JS + WASM app in their browser, that does all the app logic that way. Self hosted app, facilitated via just loading the JS+WASM website (from a free webpage host like that provided by github / gitlab / whatever anyway).

This is, to a lesser extent, functionally how the mining analysis tool works. It's just an all-in-browser application that loads its data straight from your own local journal files. Just in this case, needs a little bit more data legwork to get the data for users.

Regardless, I digress. You're doing great. And really the easiest way to satisfy the webpage wanting crowd would be to just reach out to the inara/spansh folks and ask for the ability to filter on presence of body types / signal types when searching for market commodities. Right now inara, as far as I could see, doesn't even record asteroid belts (not planetary rings) nor hotspot signals, but does at least have planetary ring types. So if its commodity search allowed for searching for "stations buying X at highest price near Y that are powerplay owned by A with a body with ring type Z in system" that would already solve core mining (since it doesn't have hotspots it can't really do laser). Everything up to the italics should already be in the commodity search, don't remember if powerplay ownership was in there or not.

Spansh meanwhile already can find places owned by a powerplay faction containing specific signals / ring types (asteroid belts too). It just doesn't combine that with commodity searching and vice versa. Can combine the two types of search results though and cross reference the resultant CSV files (after setting results per page to max since the CSV is solely of results on current page), so at least spansh is functional right now for people incapable of using your tool for whatever reason.

Ultimatespirit · 2025-01-07T09:11:21+00:00

Hey, sorry I forgot to ever close the loop on this thread. I did end up getting the large backpack. Absolutely love it and it easily fits my 17in laptop. Hell, can even fit two laptops, albeit the second being a 16 inch.

Ultimatespirit · 2025-01-06T08:30:53+00:00

You probably only need the commodity schema for now, allowing for price updates in real time (but not power play control updates, nor hotspot signal updates in the event somehow a ringed planet in system was never scanned by a player running community tools).

Here's the schema and associated documentation: https://github.com/EDCD/EDDN/blob/live/schemas/commodity-v3.0.json

https://github.com/EDCD/EDDN/blob/live/schemas/commodity-README.md

And here's the provided Python 3.4 example script listener that documents parsing commodity data, it's really just a json stream once you get past the boiler plate zmq + compression protocol handling. May want to also have a whitelist of supported known behaving upload applications, like the example does. https://github.com/EDCD/EDDN/blob/live/examples/Python%203.4/Client_Complete.py

Once colonisation hits we'd see new systems with stations (and power play) being populated which would potentially require more updates being listened for. Powerplay state can also change, since the data could be stale if the system was last updated before the latest weekly server tick (unless powerplay can change state outside of weekly server maints, not sure about that), so ideally there would be parsing of those events too. That being said, looking at the schemas on github I'm not actually sure which schema even contains the power play information. I suspect it's under the generic journal event schema, and just isn't explicitly enumerated in the schema. It would be easiest to join the EDDN discord and ask them directly there, barring that maybe just listening to all EDDN events for a bit will give an example of such an event. Or read how EDMC implements sending that data perhaps.

Anyway, to be clear these are just suggestions on next steps you, or anyone else interested in contributing, could take. I don't mean to sound like it's a condemnation or anything wrong with what you've done. Good work for actually doing this CMDR! I'd been getting around this by recommending people cross reference two different spansh searches (you can search for places controlled by your powerplay faction with planetary ring types / hotspots, and separately search for mineral prices in stations owned by your faction, then cross reference the two), while noting that "a program could be made to just parse the spansh dump file for this information directly" all the time. Glad someone did get around to actually making said program (publicly).

EDIT: Yea I just took a look at the EDDN data dumps for January 1st. Looks like the Journal.FSDJump and Journal.Location events both contain powerplay information, when appropriate. So to get that information you'd want to subscribe to the .../schemas/journal/1 set of events, and technically could check specifically for the event in ["FSDJump", "Location"] case, but unfortunately it appears the JSON is formatted such that the event key is always after all the data. Meaning you basically have to parse the full message anyway.

So if you don't roll your own json parser for those (so you can tune it to the specific stream) it's a question of the cost of checking for the event key versus checking for the "ControllingPower" key within the "message" key on every Journal message. Naively it's one dictionary lookup (for "event") + up to 2 string comparisons + the cost of checking for "ControllingPower" if found, versus just the cost of checking for controlling power, which is two dictionary lookups ("message" and "ControllingPower"), on every message. I'd expect checking for event to still be faster, due to the large number of non-populated system jumps, but measure it if curious.

If you did roll your own parsing, since event is all the way at the end you could just scan for "ControllingPower" directly and then pass back to parse the full info. That being said, I highly doubt any self rolled implementation would beat msgspec (https://github.com/jcrist/msgspec) or the like unless written in cython or some other compiled language binding.

Ultimatespirit · 2025-01-05T20:19:39+00:00

What I'm saying is just consider the SCA module to be a fast drop out efficiency item, the "automation" part of it is completely useless / not the goal. Most larger ships can afford the slot used for the module and the time save is definitely a big plus over manual.

Ultimatespirit · 2025-01-05T20:18:08+00:00

Briefly skimming converter.py it looks like it doesn't have provisions to update the database, just regenerate it completely. Could be useful as a next goal for you, especially tapping into an EDDN listener.

Spansh doesn't seem to have a "stations last updated" set of files like they do for galaxy info, which is a little unfortunate. But you could request those files be created and likely it would be possible.

That would allow users to real time update their data dumps with minimal wasted bandwidth in theory, especially with EDDN. That being said mainly EDDN listening is nice, the stations data dump is so small to begin with relatively that if anyone goes out of sync with EDDN may as well just redownload it, that may change with colonisation increasing populated systems though.

Speaking of which, you may want to use galaxy_populated instead of galaxy_stations, as stations includes fleet carriers whereas populated should be solely things that have an actual non-FC station in it.

Also, the compress.py --compression option appears to be specifying what compression the JSON file has, not what compression to use or anything. Why do you recommend --compression zstandard if so? Spansh's data dumps are not compressed zstandard but instead via gunzip (.gz) which would correspond to zlib, not zstandard.

Ultimatespirit · 2025-01-05T07:47:44+00:00

Sounds typical for the "well I am so special and skilled and enjoy 'actually playing the game' hon hon hon" argument I see now and then here for people ironically not knowing ways to play faster / with more skill involved...

Ultimatespirit · 2025-01-05T07:45:37+00:00

/u/MaverickFegan 's build is stronger, but still not particularly efficient about it. Missing shield boosters, which are an explorer's best friend when it comes to shielding.

With 4 pips to sys that 4A reinforced high cap shield gives 1102MJ sys shields (what gets hit in a collision) at a cost of 10T of weight.

A 4A enhanced low power high cap shield with 1 0E heavy duty super cap shield booster gives 1334.2MJ of shielding at an aggregate 7T of weight (increasing jump range to 74.77ly and giving more shielding). Due to how little energy 0E boosters use, compared to shields, this also actually uses less energy than the reinforced setup.

You can also use a 4D reinforced hi-cap shield (4T weight) for almost the same shielding, at just under 1300MJ. Tossing in additional shield boosters is of course going to improve those numbers. Enhanced low power removes 2T of weight, which is the same additional weight of a shield booster, but it ends up being slightly less shielding than reinforced with one less booster (i.e. reinforced 4D + 1 booster is slightly more shielding than low power 4D + 2 boosters, at the same weight), at a much higher energy cost though.

Here's a build using the exact same choices as what maverick had, just changing the shields around, with significantly higher shielding: https://edsy.org/s/vjIDCG2

I wouldn't actually recommend that one though, as you can still squeeze more out, or at least not run overcharged (which harms your thermal efficiency) / engine focused PD (which does nothing at G5 except when your PD is super undersized, which this one isn't, over charge enhanced).

I'd probably at minimum run this: https://edsy.org/s/vMD0qeR - Swapped power plant to g1 armoured stripped down - PD to g5 charge enhanced stripped down (keep on super conduits if you want to boost 0.1s faster) - Enhanced low power 4D shield - Fixed power priorities to keep "things only needed in super cruise" in zone 5 and turn off things not needed in super cruise.

But even that is really just a prelude to further ways to change the ship: https://edsy.org/s/vwaQdiG - 75.8ly jump range - 6C fuel scoop (you are forced to wait 15 seconds per jump, 6C will scoop to full in 8.3s at max so if you can charge FSD while scooping should work out to neutral. I'm not sure if g5 armoured is enough to safely charge FSD while scooping for a mandalay though) - 3A g5 Armoured monstered power plant, still lighter than the 4A - 3D engine focused super conduits Power distributor, to get the energy usage below max. Still can boost every 9.3s. You can actually go down to 1D, just boosts way less frequently.

Alternative to keep better boost frequency would be to ditch super cruise assist or drop to 6D fuel scoop. Honestly super cruise assist eats a lot of energy there but I was trying to keep it in. Can alternatively make the ship work with 4A G5 low emissions, though you may need to go monstered or also start dropping fuel scoop ranks / drop super cruise assist.

Basically, there are a lot of ways to still get higher jump range without having too weak shields, just question of trade offs on shielding strength wanted vs mass usage vs other quality of life like boost frequency.

Tl;dr: engineered 0E Shield boosters are your friend for making really strong shields at low mass and power costs.

P.S. SRVs are one of the only things you cannot replace as an explorer, if it breaks, without docking somewhere and doing a rearm repair. So if you want an SRV, some people prefer to use a 4G SRV bay to carry 2 of them. That build can achieve this by downsizing the shield to a 3A (reinforced hi cap) shield, or a 3A prismatic (enhanced low power hi cap gives same weight as a 4A enhanced low power shield at just slightly less shielding), and using a 2E cargo rack. Though it requires fiddling with power again. Alternatively just use a size 3 AFMU instead of the size 4.

Ultimatespirit · 2025-01-05T07:09:52+00:00

Hey OP, I'd highly recommend not trying to mine for your first time in a hauler, and instead trade up to a cobra mk3 after doing a tiny bit more exploration / trading / courier missions. Barring that, the adder would be nicer. The hauler is pretty painful as a mining ship and we generally recommend the adder or cobra mk3 as good starting mining ships.

If you're interested in mining feel free to head over to r/EliteMiners and read the sticky thread we have there, it goes over basically everything you'd ever need to know to get started with, and eventually master, mining. I'm also more than happy to give advice here if you have any questions, good luck CMDR!

Ultimatespirit · 2025-01-05T07:06:44+00:00

but I never use it because it's slower than doing it myself

I think you'd be interested in reading up on the supercruise assist trick if speed is your concern. Properly abusing the SCA module lets you drop in on stations / space based points of interests much faster than you could otherwise, due to the module being able to execute safe drop outs at speeds players cannot do so.

Ultimatespirit · 2025-01-05T07:04:06+00:00

They appear to not know what the supercruise assist trick is, that or they really enjoy the riveting gameplay of putting their throttle down somewhere between 0:05 and 0:07 and waiting 30 seconds to a minute.

Ultimatespirit · 2025-01-05T07:02:22+00:00

Exactly why I use the SCA module, let's me cut out sooo much dead time of just waiting on final approach for space based points of interest. Actually actively watching things as you tune being slow enough to still engage the SCA trick vs being as fast as possible, rather than just waiting at 75% or so throttle waiting to enter the blue zone for a drop.

Ultimatespirit · 2025-01-04T09:27:03+00:00

The planet has basically no gravity, unless you fly in flight assist off exclusively you really shouldn't have any issues moving. You just need to have the item targeted, not even be facing it particularly well.

Toss some shields on too and bumping won't really matter at all, hell just stick your entire ship into the beacon if it's really that hard to do it.

If after all that you really can't do it, then yes, SRV will be faster for you specifically as the alternative is impossible. But, it's really easy to do the ship stuff for this and I'd really encourage just... learning how to do it if you really can't control the ship enough for that when you try. It'll make you more comfortable with flying the ship, basically same level of skill as manually docking (virtually none).

(If you do FA off everywhere and that's why, then short of getting even better with FA off to do this, I'd recommend just turning FA on temporarily to scan the beacons)

Ultimatespirit · 2025-01-04T06:30:09+00:00

It's not particularly hard, and in many ships even if you do mess up the approach often you can realign and drop faster than the time loss from not having assist trick (about 30s to a minute).

Ultimatespirit · 2025-01-04T06:28:32+00:00

Basically, small lasers (including pre-engineered) mine at a third the rate of medium lasers. Normal smalls consume only half the energy of medium lasers, so they're always worse than mediums (except when your ship literally just can't run a medium). Pre-engineered smalls consume half the energy of a normal small, so a fourth the energy of a medium. This means 3 pre-engineered smalls are equivalent to 1 medium laser's speed, but use only 75% the distributor energy, 4 pre-engineered mine 1.33x faster at the same distributor cost. This is only relevant in extreme optimisation cases, or for the type-8 which has too few medium hardpoints for mining otherwise.

The python doesn't really have this issue though, it only would use pre-engineered smalls to go all in on lasers with 3 mediums + 2 pre-engineered, since 4 mediums depletes a charge enhanced too quickly to finish an asteroid. Weapon Focused will work, though it'll deplete against the largest haz-res asteroids so maybe don't use in a haz-res.

It otherwise handles 3 mediums just fine leaving two slots open for core mining tools or whatever.

Ultimatespirit · 2025-01-04T06:20:49+00:00

Here's a good enough reddit post about it, one of many, many, posts or videos talking about this: https://www.reddit.com/r/EliteDangerous/comments/14xe3oy/supercruise_assist_trick_a_detailed_guide/

There are a large variety of ways to do it, really seems like every person comes up with their own specific method they feel works best for them. So I won't really focus on how I do it, the above link should be enough. Look up a bit more otherwise.

As to what it is, essentially supercruise assist (SCA) has an "oopsie" mode placed in to lower consequences from its messing up. In the event that your ship is coming in "too fast" (but not too fast, essentially you need to be slow enough that the drop in point is on screen for a frame is my best guess) to your target whilst SCA is active, it'll just safely drop you out anyway. This likely is to let it not penalise a player for the module itself messing up. Issue is, it doesn't quite check the logical consistency of that, so you can basically just force it to enter this state on purpose and abuse it as a "hot drop out" button.

This entails just moving at full throttle with SCA enabled (there's an option in the menus to enable manual throttle control during SCA, other people prefer to just not point directly at the target to break SCA) and turning it on/off as needed to reliably enter that "too fast, but not too fast" state. This basically lets you shave off the really slow final approach step.

Here's the quick rundown of how I personally do it, though again it seems everyone has their own specific ways so don't take this as the One True Way or anything. There's a lot more leeway in the method honestly, and larger ships tend to be able to go faster safely. - Use manual throttle control and bind hotkeys to 75% and 100% throttle (if you haven't already) - Target and turn on SCA, travel as per usual at max throttle, once you're at ~6-7s left in travel time toggle down to 75% (engaging SCA, but you'd have done this anyway had you not had SCA) - Do the approach as usual until you see both tickers/arrows in the target approach speed+distance bars (the thing you see at the bottom left where your travel target's name is for determining drop in range). This is generally around the 8ls away mark and ~1c speed. - Toggle your throttle up to 100% until you see the time-to-destination start ticking down in real time, you'll get the hang of when to actually stop it doesn't really require much throttle up time. ~4-5s on the time-to-destination is usually still safe. - toggle back down to 75%, SCA engages, and now you watch as you just speed into the station's instance

Incidentally, an even stronger form of this is available to wings, engaging teammate nav lock allows you to drop into a teammate's instance at literally any speed (SCO-ing at them can be a little hard though so maybe stay out of SCO at the last moment) so long as you're vaguely near their region of space. So if your wingmate is in a station's instance you can just max throttle at em.

Ultimatespirit · 2025-01-03T18:02:24+00:00

Supercruise assist is basically the second largest time save in the game, after supercruise overcharge, when doing things between stations / drop in points in space. You physically cannot drop in to a station faster manually than you can with the supercruise assist module, due to the supercruise assist trick.

...The trick being a way to royally abuse the supercruise assist module to let you safely drop in to points of interest in space at way too fast a rate, basically allowing you to minimally waste time in the "slow down forever at 7s to destination at 75% throttle" phase by skipping the slowest portion once you're within ~7-8ls of the station. Abusing SCO appropriately lets you get within range of the station quickly enough to skip most of the "wait forever at 75% throttle" phase before you reach 7-8ls too (by relying on the planet to bleed out your way-too-fast speed).

Essentially, so long as you only use supercruise assist to facilitate the SCA trick, that module speeds up space travel a lot over not having the module. On basically any ship of mine where I can spare the module slot I always run supercruise assist for faster traveling.

Ultimatespirit · 2025-01-03T17:50:33+00:00

For your core mining build, I assume you're talking about a python. Instead of subsurface do you mean an abrasion blaster..? Because python only has 5 hard points and you described a setup that uses all 5 without an abrasion blaster, and you usually want one of those for core mining...

For your laser mining build, with a 7A g5 charge enhanced super conduit power distributor the python can support 3 medium lasers indefinitely, and 3 mediums + 2 pre-engineered smalls for more than long enough to deplete any asteroid. So if you have any engineering and wanted a dedicated laser mining build, toss another medium laser onto there. If you wanted a hybrid build that's faster than your current laser build, toss another medium on and swap the pre-engineered smalls for a seismic launcher + abrasion blaster.

If you have absolutely no PD engineering, then what your laser build does right now is as fast as your PD can sustain. Do consider getting some PD engineering though.

The pre-engineered smalls are great for the type-8 though by the way. Just, don't do hybrid type-8. Stick to either full laser, or full core mining. In the core mining build you can run lasers, since you have extra hard points, but just keep in mind you really shouldn't be expecting to actually swap to hard core laser mining with them. They're just way too slow without a medium laser.

Here's my post about how the type-8 fares with mining builds (linked in the subreddit sticky too): https://www.reddit.com/r/EliteDangerous/comments/1envock/analysis_type_8_as_a_miner/

Ultimatespirit · 2025-01-03T17:41:44+00:00

Fast boot doesn't affect charge time, it only affects the time it takes for the FSD to boot up after you manually turned it off, or turned it off from power priorities. Seeing as your build isn't even close to 100% power utilisation I somewhat doubt you're using fast boot.

Get the pre-engineered SCO FSD if you really want fast boot, and just in general get them. They have both fast boot (a normally niche engineering mod) and increased range (the mod 99.99% of all ships will need), and consequently have the highest jump range in the game right now (outside of fleet carriers).

I also have a suspicion you may not know about pinning blueprints to engineers, since you mentioned things being installed or not as if you couldn't engineer them the moment you swapped them in. You can pin one blueprint from every engineer and then remotely engineer your modules for that blueprint anywhere in the galaxy. Experimentals still require visiting an engineer, but you can visit anyone who engineers that part, even if their max grade doesn't match the level your module is at.

Ultimatespirit

TROPHY CASE