AuronUmbra

I posted a mod idea titled Deconstruct, that would scale the tier (Calibrated, Advanced, etc) of weapons and gear you can make based on your perks in Weapon Engineering and Spacesuit Design respectively, after learning the base recipe by destroying an item.

Proposal: Deconstruct adds the ability to make new weapons and gear at their respective workbenches, once you've learned the recipe. To learn the recipe for a given weapon, helmet, suit, or pack, you'll have to reverse engineer it at a Research Lab under the new Deconstruct tab; then you can create it from resources at a weapon or suit workbench, under a new interface panel. Deconstructing an item destroys it, but if it had any Rare, Epic, or Legendary traits, you'll learn the recipes for these too, as shown in the info before you confirm Deconstruct. No matter the tier of the item you reverse engineered, your Weapon Engineering or Spacesuit Engineering perks determine what tier new items will be once crafted: without perks, you'll get a Basic item; with perks 1-4, you'll get Calibrated, Refined, Advanced, or Superior versions of the items respectively. Some items don't have Advanced or Superior variants, so you'll just get the best version of the item with Rank 4 of the above perks regardless. With Rank 2-4 perks of the Special Projects skill, you'll unlock the ability to add Rare, Epic, and Legendary traits to applicable items, respectively, using recipes you've learned. These options will appear as new mod slots labeled as "Rare Trait", "Epic Trait", and "Legendary Trait". The item will be designated Rare, Epic, or Legendary based on the highest trait tier assigned. (Notwithstanding the fact that there are unique weapons in the game that have a single Legendary trait but are designated "Rare".) Note that traits have distinct tier levels; "Rare" isn't just limited to having a single trait on an item, but a certain list of traits; same with Epic and Legendary traits. So you might have unlocked the ability to add Rare traits, but you won't be able to apply Assisted Carry or One-Inch Punch to your items even if you've learned the recipes because those are designated as Legendary traits only.

Proposal: After the first conversation with each companion to explain how they'll occasionally give you gifts, every other gift will automatically be disbursed when the companion says "I have something for you" without having to talk to them.

Check out my other concept, More Immersive Space Travel (MIST).

I've seen CCR and bat file mods to set Rosie to the doctor faction, but with new tools, we have more options to make Rosie an actual ship doctor! Proposal: When Rosie is assigned to your ship or outpost, you can interact with her to buy medical supplies or pay her to heal you, cure afflictions, or both - just like any on-world doctor - ideally with appropriate vanilla dialogue responses from Rosie. Moreover, if you have an Infirmary on your ship while Rosie's assigned to your crew, she'll treat you for free. This may require CK, but ideally, while she's on board, she'll also spend most of her time in the ship Infirmary, and when she's somewhere else on the ship, you can activate one of the hospital beds in the Infirmary to be treated without having to find her.

I love mod title acronyms! SCHISM expands the ship technician repair service to include an option to repair all damaged systems in addition to the option to only repair hull damage and adds a function to calculate the hull repair cost rather than always a flat 1000 credits. The hull damage repair cost is calculated as the percentage of the hull health lost times 2% of the ship value (as seen in the Ship menu). So if your ship value is 300,000 credits, and your hull has 1000 max health and lost 300 in your latest battle: 2% of 300,000 is 6,000, times 300/1000 (30%), equals 1,800 credits - right in line with the cost of Ship Parts plus labor. For the other damaged systems, as indicated by red bars in the power allocation menu; each red bar will cost 0.1% of ship value to have repaired instantly. Repairing these systems is done using a separate ship technician dialogue option which simply repairs everything, calculated hull repairs included. You can always just repair the hull alone, as usual, in case you want to save the credits and just wait for the ship elves to fix the other systems as you go. Either or both ship repair dialogue option(s) will now be hidden if no repairs are needed. Repair costs are adjusted based on Commerce skill perks. SCHISM also adds a FOMOD optional game mechanic that requires ground maintenance. While a damaged ship system repairs itself automatically, with this option, each red bar has a 6% chance to cause a bar to become yellow, meaning it can't be automatically repaired. A yellow bar must be repaired by a qualified starship ground crew, which uses the same repair-all option as above. The probability is calculated for each ship system based on the red bars on that system once combat ends. So if your engines took 4 red bars of damage during a battle, there's a 24% chance that the top bar for engines will turn yellow once you're out of combat and cannot auto-repair. If you go into another battle, the calculation will run again once combat ends based on any new red bars to determine the chance of a yellow bar; if you already have a yellow bar, the chance will apply to the next bar below it. The last bar will always be able to auto-repair.

The goal of More Immersive Space Travel (MIST) is primarily to make traveling through space in Starfield feel more like a proper expedition and less like fast travel, despite the space setting and technical limits on contiguous flight in the game. I believe most of the Starmap features described can be done with plugin and interface mods, but I'm much more familiar with the CK, so leaving this to more skilled hands. The Travel Component below is by far the more complicated, I imagine, so it's more a dream that I'd still like to put out there for you all to contemplate. Starmap Component Proposal: MIST modifies the galaxy, system, and planet map interfaces so using the star map feels less clunky and more immersive. In the galaxy map, you can now zoom out further and even rotate the map for a better view without it automatically snapping back to the default angle. You can of course use "Show Me" to return to the default view. Hovering the cursor over a system in the galaxy view shows its usual info in the left side panel, though now slightly compacted so as to also include travel info in the same panel (distance, jumps, fuel, prompts, etc). Holding the usual travel button or key initiates travel to the selected system immediately rather than opening the additional travel window on the right side first. This is an annoying bit of friction in vanilla. Tapping the travel button/key to "Plot Course" places a custom marker which can be cleared by tapping the travel button/key again on the marked system or by placing a marker on a different system. Custom markers now appear as orange versions of mission markers in the gameplay view and persist unless manually cleared or until you arrive. In space, these markers can be easily selected to travel, just like blue mission markers. Activating a star as usual opens its system map. In the system map, hovering the cursor over a planet or moon likewise shows the info panel complete with travel info. Hold the travel button/key to immediately initiate travel to its orbit or tap it to place a marker over the planet or moon. The planet map, and thus the ability to select a place to land on a planet or moon, would ideally only be available while in orbit, to avoid selecting your destination twice - another annoyance in vanilla. If you have the right perks to scan a planet or moon while not in its orbit, you'll no longer automatically zoom to its planet map upon scanning. Importantly, the zoom-out mechanic now allows you to back out from planet to system view or system to galaxy view; zooming in and out is now faster, with no acceleration effect. The exit button/key now does exactly one thing: from any view in the star map, tapping exit once (without needing to hold it) will exit the map menu. Travel Component Proposal: Rather than a cinematic take off or landing and cut to the respective orbit or landed position, the cinematic has been modified so that the gameplay camera (third person ship or first person cockpit) follows the whole process. The idea is that we should be part of these sequences rather than feel like we're teleporting. During take off sequences, controls are disabled as usual but the player keeps their gameplay perspective starting from the ground and going well into space; this visual replaces the loading screen, to whatever extent is possible. Once in orbit, the player regains control as usual. After leaving a planet, in orbit, the default space view is facing toward outer space rather than facing the planet. Upon activating landing, whether through the map or by selecting a site with the ship scanner mode, the gameplay camera again follows the ship as it descends. There is a moment during which the planet skybox appears to rapidly approach, with grav drive-like distortion around it, then the ship rotates so that the landing gear faces the ground and the player only sees space (or the effect of thruster exhaust or colliding with the atmosphere), which replaces the loading screen (as far as possible), as the landing area is rendered and the ship touches down. For traveling between planets, the ship proceeds on course while following the gameplay camera instead of playing a cinematic cut. To obscure loading, a grav drive distortion effect plays during the trip between planets, which transitions to an orbital view of the destination planet. This transition scene appears as a rapid expansion of a tiny image of the destination planet to the full size orbital view, as though you've traveled to it at near light speed. I've seen other mods that radically increase boost speed achieve a similar effect when approaching planets, so there seems to be a basis in vanilla to work with. MIST introduces a travel delay. The travel delay is a function of distance to the destination, engine power allocation, and ship mobility. With the option to initiate travel, the HUD and starmap show the travel duration in real world time next to the distance. In-system travel: T(seconds) = 200 * distance(AU) / (mobility * engpoweralloc%). Traveling between the furthest two planets in a large system, with a ship having 100 mobility, and fully powered engines would take about 24 seconds. Travel is unavailable for completely damaged or unpowered engines. Once travel begins on a course that will take longer than 20 seconds, the player can get up from the pilot seat and move about the ship. A persistent notification appears showing the time until arrival such as "Arrival at Eridani II in 00:24" and disappears when it reaches 0 to be replaced by a notification of arrival such as "Arrived at Eridani II"; crew might also announce arrival using existing dialogue lines and prompts. The ship may be hailed or engaged in combat upon arrival, as usual, so be ready to get back in the pilot seat. Travel between star systems works basically the same way, but requires jump fuel, shows the more dramatic grav drive effect, and takes longer. Travel time is a function of total distance in LY across all jumps needed, grav drive thrust, drive power allocation, and ship mobility. Interstellar travel: T(seconds) = 3000 * distance(sumlightyears) / (gravthrust * gravpoweralloc% * mobility). So making a five-system jump traversing a total of 100 LY with a fully powered grav drive having 25 thrust in a ship with 80 mobility would take 150 seconds (2m30s). Selecting a Mission marker or custom marker from space shows the travel time on the HUD next to the marker; time can also be seen in the travel info in the star map. On activating travel, the usual countdown begins, provided the grav drive is powered. The end of the countdown dictates the start of the jump at which point battles, scans, and similar have been evaded. The visual grav drive effect is a less climactic looped snippet of the vanilla version so it can be played continuously while the jump is in progress. Once the jump has begun, options will appear while seated in the cockpit to wait until arrival using the same key/button as to take off or undock, as well as to get up and move about the ship using the same key/button as usual, provided the travel time is longer than 20 seconds. While on course, the player may use a bed for the option to sleep until arrival. Plotting a new course is unavailable while a jump is in progress. Adding power to the grav drive during a jump updates the calculation for travel time accordingly, but at least one unit of power must be retained until the jump concludes. Just by adding such visual substance and time delays to travel would significantly improve the experience compared to the vanilla fast-travel-anywhere method, as though heading off into the void is actually a meaningful endeavor. In space, traveling to planets, systems, and locations, including procedural landing sites requires the whole process outlined above; there's really no sense having a fast travel system on top of what is effectively a default fast travel system, even with the above proposals, especially with the option to wait. Naturally, travel to discovered locations on-world should have the usual fast travel option, so for discovered locations on the surface; again, tapping it adds (or removes) a Plot Course marker and holding it initiates fast travel. Note: MIST proposes none of the following, but extended travel through open space would be an excellent opportunity to add new content, reposition encounters, or even just pick up signals from nearby systems which may be announced by the crew or appear as Activities in the quest log to investigate. For instance, the player might receive a notification or crew announcement of a disruption, giving the player the option, from the cockpit, to exit the jump prematurely and later resume course by using the same key/button as to open the planet map when in orbit. In doing so, instead of being at the intended destination, the ship may encounter a derelict station, a rogue planet, or a stranded ship in open space. For technical reasons, leaving an open space location may only be possible by resuming the plotted course with the same key/button. Thanks all! [Edited: Corrected a typo.]

These are all intriguing mechanics and features, especially having the separate inventory for fuel and crew help out with refueling. I was thinking that given the limitations of existing mod tools for Starfield, adding a refuel mechanic needs to be barebones for the time being. To add to my OP, it looks like the base fuel economy (at least of the Frontier) is about 1.6 He-3 per LY; so instead of having to edit every tank for more capacity, perhaps revising base fuel consumption to say 1 He-3/LY would be more efficient and more compatible with other mods that affect fuel tanks.

This. 110% this. Imagine touching down on any human settlement in the new universe and every human NPC is dead and in their place, Terrormorphs. About a 3 person to Terrormorph ratio. You enter New Atlantis to see a locked down spaceport, debris and bodies litter the streets, roars echoing in the distance. You get to the lodge and a swarm of heatleeches slither away, you open the library to be greeted by a terrific roar and the bodies of constellation members. You manage to take down the Terrormorph there to loot its body for the artifacts, starting materials...and Sarah's outfit.

Fuel in vanilla Starfield magically refills after every jump; effectively, fuel capacity just adds loading screens to your course, in addition to the redundant "undiscovered route" limit. Thus, travel doesn't feel earned; it just feels pointlessly limited. This mod concept proposes removing the "undiscovered route" check and deducting fuel as you jump, so fuel becomes the reason you can't just go anywhere - a real reason. You'll have to think carefully about your jumps, refueling stops, and ship fuel storage capacity. How far you can travel will depend entirely on how much fuel you have and the total lightyears a route will cover; naturally, grav drive range determines how direct (short) or winding (long) the route will be. Jumping costs a number of units of Helium-3 per light-year, which even in vanilla can be improved with perks. Also, it may be appropriate to increase the capacity of all fuel tanks to ensure this proposed mod adds more immersion than grind. To refuel, you'll have a few options. At any ship services location where you can have your ship repaired, you will also have the option to refuel. The price is calculated based on the credits you'd pay for units of the resource Helium-3 from any vendor and the amount of units you'd need to fill the empty space in your tanks. Alternatively, if you have Helium-3 in your cargo, there will be an option in the ship menu to "Refuel Ship". For instance, tapping the repair key or button could refuel the ship; holding it would consume a ship part to repair as usual. Refueling will use as many units of Helium-3 as necessary to fill your tanks, which could be up to all the Helium-3 in your cargo. Helium-3 stored in fuel tanks won't contribute to cargo mass. To ensure you are never truly stranded, almost all asteroids will provide Helium-3 when mined, and almost all random ships you encounter will now have some Helium-3 for sale or drop some when destroyed. In the worst case, it seems every system has a planet or moon where you can extract or collect Helium-3 yourself.

The concept is to add a resource-only inventory accessible through the ship cargo hold menu (like an outpost Transfer Container) when landed at any spaceport with a ship technician; the contents of which may be used anywhere for crafting, like the ship cargo hold. Ideally, access to such a feature in-game would require some kind of perk, completing cargo link or delivery missions, or even paying the ship tech say 10,000 credits per 1,000 kg with the option to upgrade by the same amount; but there really needs to be a clean and simple way to store resources planetside. This would save players time and effort dealing with a constantly full cargo hold and inventory; it would also make the game loop flow better and make way for more advanced mods like building ships from raw resources or salvaging them for the same (I've already made recipes for every single ship part based on its value, if you're interested)!