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 !

Regarding ESA's collaboration for SLS's EUS, there was apparently talks about using Vinci rocket engines in place of the RL-10C3 https://web.archive.org/web/20161227034806/http://seradata.com/SSI/2014/11/next-steps-for-sls-europes-vinci-is-a-contender-for-exploration-upper-stage-engine/ Though given the delays they had in develloping that engine...

Well, something at least sized like ISS solar panels (kerbal scaled of course), even at kerbal scale it would be nearly 3 gigantors long & two side by side wide - for 1 kerbal scaled iss solar panel. Going from there, a way to disable the panels automatic suntracking, especially if we could combine that with a servo that can do sun tracking (this way we could create iss style rotating assemblies). (that kind of sun tracking servo could also help for radiators) else, a way to 'wrap' folded solar panels around cylindrical bodies would be nice too, so they could more easily fit within fairings (look at folded soyuz / zarya / zvevda solar panels) As for procedural solar panels, i guess rosa style solar panels could be the right tool

When looking at Gerakl concept, looks like that's where stratolaunch's inspiration came from (minus the forward canards) as far as crazy arrangements with canards, i think the be-2500 concept still as it beaten - with jet engines above the forward canards ^^

With the front right of the wingbox / forward aircraft spine damaged, the forward fuselage / cockpit collapsed on itself (especially if fire weakened further the structure). with the spine damaged, the nosecone locking system was likely not enough to preserve the fuselage rigidity (they might not even be locked if the aircraft was undergoing servicing) the aircraft Aft section fared better, as the spine was not damaged on this side of the wingbox, and there's no rear ramp on the AN-225 to compromise rear rigidity. AN-124s have the rear ramp i've read somewhere that the planned a conventional tail for the second 225 (similar to the 124 tails), combined with a rear ramp to achieve rollon / roloff of cargo. (The split tail was for limiting the effect of turbulences from external payloads) on the tail) As for the fire, there seems to be very limited charring (even on the right wing), there was no fuel to further the fire from the ordinance initial explosion. (Fuel tanks were likely fully drained as they removed several engines for maintenance)

[snip] for mriya itself, forward fuselage and cockpit seems completely destroyed (maybe the floor fared better but...), wingbox seems damaged (right wing is twisted it's root severely damaged, and seems barely hanging to the wingbox), aft fuselage / tail seems relatively intact. Not really easy to see the damage to the main landing gear. on the left wing, two engines seems to have been removed during the planned maintenance, the remaining engine seems to not have suffered external damage

A new very short video of the airport, with mriya's hangar in the background Not a lot to be seen, but the aircraft seems to have been really badly damaged (More than likely complete loss) only the nose is recognizable... edit : same video as @DDE's link

Port wing deployment has started https://blogs.nasa.gov/webb/2022/01/07/primary-mirror-deployment-has-begun/ From the blog, releasing the latches / relatching once it's in position is going to take the most time of the operation (rotation of the wing itself is only 5 minutes) - i guess they have to operate & check that each latch worked correctly after triggering them. (Plus maybe check the port wing systems after the operation)

You would see yes, but mostly by occultation. not very useful for checking if there's wrinkles in the sunshield with a camera. you can see how much light earth atmosphere is diffusing - even in the shadow, while iss parts are seen by occultation. (Outside of the few parts that receive some light from earth itself) And according to the comments, the series of photo for the vid below has 1.6s exposure time...

On earth, atmosphere scatters a lot of light and reflects / deflects some of it, even during the night without clouds or moon (light pollution is a thing) , the same way they can bounce radio waves against the atmosphere. in vacuum, they would need a lot of exposure time per frame to get enough light on the cold side to see anything (even then, you would mostly only be able to see through stars occultation) without also having projectors (light or IR) scroll around the ISS EVAs videos, you'll see quickly how dark it is with cameras in space when iss is in earth's shadow

Well, on the cold side, you won't have light outside the stars, so any camera would need to have a way to illuminate the parts to have a chance to see them - which would be likely to disturb the instruments (between the heat from cabling resistance, etc) - and you'll need cameras able to resist to the extreme cold. on the hot side, outside of the antenna, flap, solar arry and external sunshield, you don't really have anything to look for that couldn't be easily tested. antenna and solar array are pretty straightforward, if they didn't deploy you wouldnt have power or high speed communications. (Easy to test) outside of reading motor values, basic detectors on the latches can check if the various parts reached their intended positions. And i guess they could measure the angular moments the spacecraft was submitted to from deploying the parts from the gyroscopes, so you can know if the parts moved accordingly too The more or less only 'unknown' would be the sunshield's layers, and i guess they can check from the pulley system if there's abnormal forces from the motors to detect anomalies.