sgt_flyer

One way could be to add attachment nodes to wing roots & wing tips - if the wing tip node is occupied, prevent contrails from forming there Those nodes could also technically be used to bind the wing root size of the children segment to the parent's wing tip size for seamless adjustment. (though, i guess it should also lock some of the parent wing's controls (length / angle / wing tip sizes) i guess allowing to adjust the wingtip rotation could be useful for seamless integration though, like if you go for gull wings, or to add sharklets.

I think there's also a problem with having no subassembly tab like in KSP1 - currently, the workspace can basically serve for storing subassemblies, which is quite tedious compared to the ease of use of KSP1 subassembly tab. (However, KSP1 Subassemblies were saved globally) it seems the Workspaces are currently supposed to try to tackle Folders,Versionning and subassemblies all in one. What i thought about it : it could be nice to get back to 1 craft Workspace = 1 Ship, (however, custom Subfolders or custom Tagging would be needed for sorting ships), which would be less confusing i think. in this version, the current workspace menu would only be there to allow you to manage Versionning and / or subfolder/tagging.: i would say at least 1 or 2 autosaves (in case of game crash) and 3 manual saves back (so you could revert in case you saved your craft after you deleted something) The name of the workspace would be the name of the ship (like in ksp1) The workspace could also save the name and / or ID of the currently loaded "world" (so you could easily hide rockets that have been created in other "worlds") Then, return of the subassembly tabs in the assembly building, However, you could have 2 subassembly tabs instead of 1 : - 1 Global subassembly tab (only subject to the whole game save - similar to the one in KSP1), (easy sharing of small parts, like custom RCS clusters between workspaces) - 1 Per craft save subassembly tab (so you could store for exemple side boosters for a specific rocket, so you could customise the rocket by swapping boosters, like Ariane 4 or Delta IV) Subfolders for subassemblies tabs could be a plus, but i don't think it would be that much needed. However, naming the subassemblies could be useful. When Merging workspaces, you could be allowed to pick what you want to merge : Craft, per craft subassemblies, or both.

Trying to recap everything that the workspace system tries to currently do : (outside of the naming system which is, in my opinion a separate issue, as vessel renaming inflight is problematic) - Storing multiple saves & autosaves of a ship - Storing subassemblies only for that ship (instead of having irrelevant subassemblies stored globally) - Potentially storing ship variants and or categories (hierarchical organisation) one question could be, why trying to store everything above in the same window in the game UI ? In KSP1, you basically managed subassemblies from the parts picker. Would it be possible to have subassembly tabs in the KSP2 parts picker ? : - 1 tab which would be Workspace subassemblies - stores subassemblies dedicated to the current ship. Loaded with the workspace - 1 or more custom tabs for storing & organizing global subassemblies (stuff that you reuse on a lot of ships, like custom RCS subassemblies). Always available for all workspaces. For hierarchical organization, why not allow to have a tree of subfolders when saving & loading the whole workspace ? This could allow : - Easier sorting through categories (ex : you only deploy the Launchers subfolders, containing multiple workspaces of launchers) - you could only have 1 ship per workspace (resolving naming issues) Basically, to resume the above : - The current Workspace UI would be for managing single ship saves & autosaves. (So you can roll back to an older ship save in case of problem) - the saving / loading menu for whole workspaces would allow for filtering and / or organize (through a tree structure) ship categories. - the part picker would have tabs for workspace & global subassemblies (so you could pick & paste subassemblies like in KSP1) - Merging workspaces should allow to pick what you want to merge - workspace subassemblies or ship for example with your currently loaded workspace.

I'm wondering that in addition to the old 'Science' Lore we had in KSP1, if "gating" at least some of the research behind specific science experiments could help ? Of course, in a way that would encourage to explore more - and still makes sense from a "Research" point of view. ex : various control surfaces & wings could require experiments to be run while flying in atmosphere, while more vacuum optimized engines could require space experiments. with maybe having enough reports of the type from x differents locations for later stage science to unlock a node.

I guess one of the problems is that in KSP1 the control surfaces did not deflect instantly to maximum deflection during micro inputs - they had an actuator maximum speed, contrary to KSP2, so short inputs from keypresses or SAS would only move the control surface slightly. I guess it's a problem with the current KSP2 procedural wings - you would likely need to vary the actuator speed depending on the mass of the control surface itself.

it would be interesting if there were attachement node points at wing root / wingtip that could "merge" the sliders of the used node : (only for wings of the same type of course) ex : 1) If a children wingroot node is connected to the wingtip root of it's parent, disable all of the parent's wing shape sliders. (that way, no need to have to recalculate the children wing's position if the parent wing sliders are changed) 2) the children wingroot node parameters (angle, length, thickness) are inherited from the parent's wingtip (so they seamlessly match) and are disabled. 3) Disable the wingtip trail on the parent wing. (currently on multisegmented wings, every wingtip generates a trail) At the same time, using those wingtip nodes could also be used to disable the wing contrails at the node (if a wingtip node is connected to another wing segment of the same type, don't generate the trail there) - that way only the final wingtip would display the trail (instead of each segment) If using nodes, having the ability to change the dihedral angle from sliders could also be useful (to keep the wing connection seamless) (would affect the lift vector of the wing piece) Additionnal options (toggeable) that could be useful : flaps (replaces standard control surfaces, not available if the control surfaces are disabled) - increases lift & drag of the wing. Possibly different type of flaps depending on the type of wing maybe ? (plain flap, fowler flap, fowler flap + leading edge slats for example) heat shield tiles for the underside options as other proposed before : spoilers (increases drag & reduce lift) wet wings (size of the fuel tank of course dependant on wing shape, & control surfaces sizes) With this, creating a compound wing could be really simple. ex : innermost segments : flaps instead of control surfaces, + spoilers. main outermost segment, control surface (roll) + potentially a winglet

I guess he's going for a swim on laythe afterwards ?

the control twitches because it's too near the com to know if it needs to go up or down. you should go into the advanced section of the wing controls to disable pitch & yaw on your wing control surfaces. (keep only roll on those) - on your tail, the horizontal elevators only need pitch, while the vertical rudder only needs yaw Now, the fact that wings have little effect on pitch is normal (it's basically physics). Also, you should not keep the center of lift lined up with the COM - real life planes center of lift is behind their center of mass. (but not too far, as it will decrease the pitch control surfaces effects) Basically : the center of lift too far behind the COM : the plane will react sloowly to pitch control. Center of lift very slighthly behind the COM o centered on the COM : the plane will react strongly to the control surfaces effect (acrobatic plane) Center of lift in front of the COM : the plane will want to flip to get the COM in front of the Center of lift (and promptly crash ^^) Hence the saying : a nose heavy plane flys poorly - a tail heavy plane flies only once think of control surfaces as levers acting on the plane, with the rotation point being the center of mass. pressing or lifting the tail will require not much force to affect the pitch of the plane, while pressing or lifting something near the center of mass will need much more force to affect the plane the same way. https://en.wikipedia.org/wiki/Flight_control_surfaces on a conventional plane with wings near COM (not delta Wings) : wing tips control surfaces are for roll control. Horizontal tail control surfaces are for controlling pitch Vertical tail stabilizer is for controlling yaw. On planes with delta wings or similar (military jets / space shuttle / Concorde), wing control surfaces can manage both roll & lift, the vertical tail stabilizer controls yaw. l

I'm looking forward to the every improvements and how i'll be able to mix & match parts to recreate all kinds of spacecrafts

Very nice i especially like the ladder animation - the hands and feets are perfectly lined up with the ladder !

My own take about interstellar's ranger saturn V takeoff is that while it's engines are very efficient, allowing for several takeoffs and landings, it still has finite expensive & hard to manufacture fuel for it's main engines, that they won't be able to refuel / renew once launched. Then the saturn V launch makes much more sense, as it allows them to use poorly efficient kerolox / hydrolox fuel, but very cheap compared to ranger fuel, allowing the ranger to get into orbit with a full fuel tank

Stumbled upon that entry once (might be from browsing tvtropes), but yeah that was my reaction too at the time ^^

https://en.wikipedia.org/wiki/Thunderpants ... of course, don't take it seriously as for your question, no. personally, i don't equate methane to farts. as others said, methane can be part of the gases produced by digestion, but it's not "pure", so you'll need to split the methane from the other gases. While feasible, its might not be the most effective way to manufacture methane compared to other methods (between the infrastructure complexity / energy requirements of each step, etc) - existing Power to Gas stations (to convert renewable electricity to storable methane) use the sabatier process

It was tested once by rocketdyne within a tripropellant rocket engine, with an ISP of 542 (record with chemical engine) https://en.m.wikipedia.org/wiki/Tripropellant_rocket they went with gaseous H2, Fluorine and liquid lithium. outside of the absolute madness of that combo : Lithium : in case of a leak, the lithium at these temps would end up catching fire by itself and be very hard to extinguish Liquid Fluorine : 'nuff said Afterwards you need to store those fuels in a rocket without thermal transfers between your h2 and your liquid lithium (180°c) . (Imagine between liquid hydrogen and liquid lithium naturally liquid metal at ambient temperature you likely don't want to handle that stuff (mercury).

Lithobraking succesful !