sir_frost

you might be able to read the delta v of the stages. (I am not sure how available this is for k-OS) but it is information displayed on screen.

The only reliable source of power that can be sourced from a hydrogen gas gigant would probably be wind power. this seam counter intuitive when airships glide with the wind. but we make a tall craft with a wind turbine below, hanging like a pendulum beneath the craft. the the craft is placed in a way that allows the bottom part to drag in another another region with a different wind direction. since it will act like a neutrally buoyant pendulum it would be stable and gravity would counteract the torque from the wind differential. the downside is that you would have winds potentially blowing stuff of the platform. since the entire craft would experience relative motion compared to the surrounding atmosphere . i have no idea if using wind shear to power stuff will work, but it is a fun thought experiment.

the Wikipedia article you liked only applies to metals, i am no chemist but there should be other materials that could be viable? also the temperature does not need to be too high for the system to work, it needs to be hotter than its surroundings. as far as i could see the embrittlement process is still an active area of research, it might not be an unsurmountable obstacle.

the best analogy for real science gathering in KSP 1 are the science gathering contracts to be asked to take specific measurements at specific locations sound like real science gathering to me. but i would love to have different type of science missions. prototype missions to unlock parts by testing them in certain conditions. constructing science bases that explore the surroundings with rovers. deploying telescopes to study planets (and find areas of interest for new science) my main suggestion is to make science mostly a subsection of the contract system. the contract system is neat since it gives you missions based upon what you have done in the game so far. if you place a surveyor in Duna orbit you would be more likely to get a science contract to the surface. if science is more focused on contracts we could have mission specific science parts. imagine being asked to build the James Kerman space telescope or the JKST for short, and to put it in a LaGrange point (yea i know N body physics is not in the game). different contract Corporations could be focuses on different things for example the life on Duna society would like you to invest in Duna exploration missions and science. if you do successful contracts for them they will give you bigger contracts in the future. but the science gains from contracts should be diminishing returns for the same type of study on the same body. just studying the mun would be boring, and going to other planets would give much more valuable science.

this is a feature i would like, controlling planes with fine maneuvers is hard, and the SAS system in its current form is not the best autopilot. we would need some sort of autopilot with a target altitude and target heading. and it would keep level flight on its own.

hot air balloons will work in a hydrogen atmosphere, since hot hydrogen still occupy more space than cold hydrogen. if hydrogen leaks... it is not relevant with leakage in an open system. the question is at what depth could we expect to get enough buoyancy. if it is too deep then we cannot rely on solar power for the heating, and must rely on an onboard heatsource , like a nuclear reactor. weight constraints would be an issue. but if we give players the tools for this they could find ways within the realm of physics. the other thing we can consider is to build a Venus analogy in KSP 2. a rocky planet with a thick dense atmosphere. and a surface that is perhaps to hot or with pressure to high for vessels to operate. in this kind of atmosphere blimps, dirigibles and hot air balloons would all work great. If wind is added to the system airships would drift with the wind and would only be susceptible to changes in windspeed. or wind shear. this would make them drift across the surface in a controllable way without much risk. we as surface dwellers see high winds as something scary since we have a relative speed compared to the wind. high up in the clouds there is no debris to fly around with the wind either. it would create an interesting landing puzzle to land on a platform drifting with the wind.

having more symmetry options enable new things. 5x symmetry is my favorite modded symmetry from KSP 1. now you as a reader probably think: who would ever want 5x symmetry and why. the answer is: me and here comes the why: my first argument for 5x symmetry is redundancy when designing a lander how many legs should it have? well at least 3 because the center of mass needs to be within the triangle formed by the legs. 4 legs is not the best option (sorry Apollo) if any one leg fail the craft is unstable and it will fall over. 5 legs will allow for any single leg to fail and still be upright, and up to two legs could fail as long as they are not next to each other. but for me personally the main reason is to be able to build crafts like this. now how does 5x symmetry stand out from the rest? 5x symmetry allows construction of tesselating structures in 3d space (balls) one great example are the platonic solids, most of the fun ones require 5x symmetry. the one in the image is a Icosahedron that was twisted a bit. note that every node has 5 arms. there will probably be a mod for this, but to simplify craft sharing of designs like this it would be nice if everyone could download and play with them. as a spoiler i will add pictures of other designs that use the same symmetry. adding more symmetries would not be harmfull. 7x could probably be cool for making heptagrams or something. it would be a very smal addition to the game to add this and it would probably go unnoticed by many, but it would make my day!

this should definitely be a ting. but it should be a toggleable option in the VAB, and it should add weight. the weight should be proportional to the surface area of the shell of the tanks. the upper limit on the amount of fuel stored should be based on the volume of the wing.

As a GeoGebra entusiast i am more upset with using GeoGebra calculator, classic 5 is the only version of GeoGebra for me.

the Navball approach is certainly the way to go. it is simple and does not clutter you screen i would like to see an addition to the SAS controls to lock to the docking alignment indicator on the Navball. this would free up the brain for translation controls.

in my testing this works as intended. i just launched a craft in ksp 1 using the TT-38 radial decouplers the tanks with the highest fuel priority number drain first and then they sequentially drain in fuel priority order until the last tank is empty. the main difference with using fuel ducts in this case would be that the engines automatically cut off when the fuel in their tank is depleted. if you do not experience this expected behavior in KSP 1 i suspect it is a bug on your behalf. my hope is that the Developers of KSP 2 implement an identical fuel crossfeed system as KSP 1. i add a spoiler that contain my KSP 1 mission working as intended.

i do believe this is not a bug but intentional behavior from the developers. it makes falling of ladders "impossible" or at least harder. in KSP 1 we had the option to toggle stop att the end of ladders. i think this is the same thing except that we do not have a toggle for it. this seam like a easy fix with a toggle in the gameplay menu.

I built a snowman that is a fully functional rocket capable of going everywhere in the kerbol system. would make a great mothership for Jool runs.

you are wrong about the decouplers in KSP 1 fuel crossfeed require a upgrade of the RnD building to work when that is done all decouplers have crossfeed as an option in flight or in the editor. fuel lines in KSP 1 was made obsolete when they introduced the fuel tank priorities, because crossfeed does the same thing with no extra part.

in my own testing the vibrations could be because of an imbalance in your craft, making the wheels face the ground at a non 90 degree angle. this cause a lot of difficulty for me, i even built a frankendrive thing that use angled wheels to accelerate.

KSP Version 0.1.1.0 Operating System and version Windows 10 CPU and GPU models, RTX 3070ti AMD Ryzen 7 5800X Description of the bug. this is a way to achieve phantom acceleration without engaging motors. if wheels are angled with respect to the ground the suspension can be triggered to glitch. Expected Behavior crafts with unpowered wheels should not accelerate with the help from glitch suspension Observed Behavior crafts with unpowered wheels do accelerate with the help from glitch suspension Steps to Replicate build a craft with wheels, make sure the wheels face the ground at an angle. overload the wheels with high mass (or use smaller wheels) tweak the suspension if needed. the craft will start to accelerate in the opposite direction with respect to the angle of your wheels. so far I have tested this with RoveMax M1 and RoveMax TR-2L RoveMax M1 has a visual glitch that indicates if it is working (the uncontrollable shaking) Fixes / Workarounds (if known..) build crafts that have the wheels perpendicular to the ground or use this glitch to build stuff A list of ALL mods. If the list is long, please consider using a spoiler window. no mods Other Notes / Screenshots / Log Files (if possible..) this is my craft in the VAB, the wheels are mounted perpendicular to the ground but the shape of the craft will make it fall over and the wheels will be angled the fuel tanks are just there to add mass here we see the craft with the motor off at a high ground speed, note that the wheels are angled with respect to the ground. no inputs have been given. A resonable fix would be to keep track of the energy stored inside the springs. I expect the current functionality is that the springs force is proportional to the distance to the ground not to the actual compression. if the wheel is at an angle the ground distance would not give the same value as the compression.

a better way to do it is a prompt that asks how you want it. with a checkbox remember my choice.

as far as I am aware lights do not drain batteries at all in the current build of KSP 2 the only things that consume electric charge is wheels and ion engines. this needs to be fixed though

this is not a bug. this should be in the suggestions part of the forum on a side note i totally agree.

this is a legacy bug from ksp 1 the largest wheels use tank steering therefore they get power to their motors when turning usually the effect of the motors go down with speed. but the turning force on the wheels do not follow the speed curve. by quickly tapping A and D keys while W key is engages we can reach speeds up to 80 m/s (in my personal testing) the expected behavior would be that the largest wheels would turn by selective breaking instead or that the maximum output of the wheels would follow the speed curve.

how did you set your spring strength and dampeners? often the wheel jumping issue is a problem with too high spring strength. often i turn up the dampening to help absorb more of the bounces. if your rover turns over easily then try a wider base and lower the center of mass. also the speed of your rover will often affect your handling. if you adjust the steering so that only the front wheels turn (or the back) it limits the total amount of steering. the steering angle limiter and the steering response are good parameters to tweak as well.

this is a known issue with a simple fix (works both in ksp 1 and 2) the simple fix is to use actuation toggles to make sure the same thruster is not used for rotation and translation. in general you want omnidirectional RCS thrusters close to the center of mass to handle all translation. and optionally you can use RCS far away from the center of mass to rotate the craft but not translate it. personally i only use RCS for translation in docking scenarios. and i let the reaction wheels handle the rotation. to sort this out go in to the settings of your RCS thruster and click advanced controls then deselect pitch yaw and roll. see the imgur link for how to configure it. https://imgur.com/nDTnaiS when i first learned this trick i had problems with running out of RCS fuel for docking. often i would bring a spare tank just in case. now i dock with high precision and often only use the RCS fuel built into the capsules and have plenty to spare. the problem with having the RCS for translation and rotation. is the feedback loop that can occur with unbalanced crafts. and every time you translate the SAS will fire the opposite thruster to cancel the rotation. I hope this information is helpful

asparagus staging is indeed broken the problem is that there exist 3 separate systems for fuel transfer. we have fuel ducts: these should function in such a way that fuel from the transmitting end is uses instead of the receiving end. then we have fuel crossfeed in ksp 1 at least this ment that fuel could flow through a part, and all parts containing fuel had a fuel flow priority setting. the tanks with the highest number drained first. this was no issue to worry about since this numbering system was linked to the staging. in KSP 2 this system is nonexistent and all fuel drain evenly between tanks with crossfeed. the third system is the manual fuel transfer. this is at least working in KSP 2. whenever you do asparagus staging you need to manually transfer the fuel. the best solution is to reimplement the numbering system for fuel drain. then we let fuel ducts act like one way crossfeed. and we let the staging sequence be the base for the numbering in a way that tanks being dropped first should drain first (this would be the standard numbering but we need to be able to renumber them for whatever reason) in most of my ksp 1 builds where i use asparagus staging i have stopped using fuel ducts and instead use the more modern crossfeed system. it is more user friendly since you place parts, then enable crossfeed and it simply works.

i have encountered another aspect of the bug. i built a craft with several ion engines. when i burned nothing worked during timewarp. then i disable all but one of the engines, then it works just fine. other times it simply refuse to work with timewarp at all i can unfortunately see no patern in that behavior.

this is a useful feature from ksp 1. and i came here to suggest the same thing.