mattihase

I think it would be a really helpful design tool for engine placement asymetrical crafts to be able to show where the centre of mass is when a craft is fully fuel (to whatever the user tweaked) vs where it would be on the craft when it's out of fuel. It would definitely beat having to empty 50 tanks by hand to find out where the COM ends up, and manually refill them one by one.

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i7-10870H | GPU: RTX 3070 | RAM: 16GB Tried to get some screenshots of my SSTO leaving the KSC from afar only to discover the space centre has been pulled into the shadow realm Included Attachments:

Behold the Sideline, a (theoretically) reusable shuttle without any need for disposable side boosters: One of the brighter ideas of those nerds over at NASA was the Space Shuttle, a rocket which stores its expensive engines on a spaceplane segment which can return them back to earth for re-use. A pretty clever idea with a couple of hitches in the execution: See those two big boosters on the side? Yeah. Those bits aren't on the reusable spaceplane bit, and it's a real hassle to go out and recover those seperately. The Sideline Shuttle (with Big Orbital Tank) concept attempts to remedy that one singular sole problem with the Space Shuttle, by simply placing two Sideline Shuttles either side of the disposable tank. As you can see, twice as many main engines can be recovered now, 6 in total, and we've gotten rid of those silly booster things too. This was a pretty fun craft idea to explore, and I ended up creating two variants of the Sideline, one with a small passenger tube (in the first screenshot) and one with a Mk2 cargo bay capable of ferrying around small satellites or station components (in the second screenshot), both coming in at about 22 tons by the time they seperate from the main tank and make it into orbit. The Sidelines can make a powered landing, though ironically, given the whole reason I designed them, I've yet to have any of them return from orbit without spinning out and damaging their precious engines during the inevitable crash, but hopefully I'll be able to work that out eventually. I was planning on working on a bigger 4 engine per shuttle variant shortly before posting but then the VAB ended up freaking out and creating a part singularity so I've decided to call a day of it for now.

Aside from the not working when paused/out of fuel problems, I thought it might be a good idea to write down some other useful features for Maneuver Plans going forward in KSP2. A couple missing features from KSP1, and a couple new things that could make their way into the game. Set for future orbits Give us the exact time til the point the node is on the orbit (the midpoint of the burn) Give predictions for how long a burn is going to take based on a configurable throttle level Have the option to set up nodes to work over multiple passes (only burning at periapse for max orberth effect kick) Have an app/widget that shows you info about all planned Maneuvers, and a summary of the total Delta V cost RCS Mode: how long will you have to hold down H to complete this Maneuver?

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i7-10870H | GPU: RTX 3070 | RAM: 16GB As the name describes. Sometimes when reloading workspaces by reverting from launch, all parts seem to form a singularity on the floor. Included Attachments: .ipsImage { width: 900px !important; }

I've been running into a few issues with delta V calculations in the game recently so I've ended up using the strout.net Delta-V Calculator website to work out the delta V of my craft manually. Kinda nostalgic feeling, because I did this a lot back in very old versions of KSP1 but I can certainly say I'm glad we don't (usually) have to tab out of the game to work this stuff out anymore, and I'm definitely glad I haven't had to manually work out a vessel's dry mass in a long time. However, I realised there's probably people around new enough to KSP that they're not familiar with this so I just figured I'd make this post to bring awareness to make more people aware of its existence/remind people of it while we're waiting for the delta v calculators to be ironed out. https://www.strout.net/info/science/delta-v/intro.html

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i7-10870H | GPU: RTX 3070 | RAM: 16GB The cargo bays seem to be the cause of a lot of issues regarding Delta V calculations that I have encountered in the game. If you take the bottom node of an engine and attach it to any of the attach nodes on a cargo bay (any cargo bay), both that engine and any engines on the craft attached to the root of the craft via the cargo bay become removed from the vessel delta v calculation. This sometimes happens with radially attached engines (and sometimes doesn't), leaving the radially attached engine fine but any other engines removed from the delta v calculation. Also, the longer you mess around with this, the less stable the delta V calculations seem to get as during testing I managed to get to a point where I had a vessel consisting of a probe, fuel tank and engine only with no delta v, simply because a cargo bay had previously been attached to the craft. Included is a craft file of the craft I built to work out whether or not cargo bays were causing my problems. It has 0 Delta V but goes pretty far despite that. The best way to scope out this bug however just seems to be messing around in the VAB with engines and cargo bays. Included Attachments: LookMaNoDeltaV.zip

Reported Version: v0.1.5 (latest) | Mods: community fixes, microengineer, flight planner | Can replicate without mods? Yes OS: Windows 10 | CPU: i7-10870H | GPU: RTX 3070 | RAM: 16GB I keep on running into crafts having their Delta V accidentally calculated as being 0, I've reported this as a seperate issue in the past, but an unfortunate side effect of this I've been running in to has been that the game completely locks you out from creating maneuver plans when your delta V is calculated as 0, regardless of whether this is correct or not (as you can see in the screenshot, I cannot create a plan as the delta V reads 0, meanwhile all of the engines still have access to fuel). I would like to request the devs make it possible to create maneuver plans regardless of delta V status so that I can actually use this feature to play the game regardless of whether or not the game glitches out on me when it comes to Delta V calculation problems. I really do not want to have to eyeball a bunch of interplanetary transfers if the game decides it wants to ignore my fuel. Included is the craft file, I hope it helps work out what's causing the delta V problem. Included Attachments: BOT.zip .ipsImage { width: 900px !important; }

Hey, we programmed the probe software right! It's the user's fault the thing caught fire the moment they tried to make it bank to the left. Actually that does remind me, Perseverance is based on Self Driving Car tech. I do definitely think, at least in an interplanetary setting, KSP's probe cores are fairly accurate equivalents to what we could probably do with modern tech today. For interstellar (and with radiation being a planned thing) I just think we'd need something that feels more robust is all.

Interstellar cores should have to be massive, mostly shielding, and only capable of following simple commands like hold/point at orientation when further from the nearest colony. All but the smallest science payloads should also be impossible to transmit over interstellar distances without a colony with a big radiotelescope array. This makes sense both as a realism thing (if we're sticking to present/near future tech) and as further a gameplay incentive to design crewed and colony building missions.

I disagree. I think interstellar probes should be inherently limited in function in some way (perhaps to harden them against cosmic rays outside of the heliopause) to encourage going places interstellar with your kerbals.

I think it'd make more sense for class experience game to not be tied to their abilities to do basic stuff in flight, but rather improve what they do when colonies are implemented. Pilot levels not unlocking SAS nodes, but rather how complex automated routes can be. engineers can always do engineer stuff but more xp makes them able to mantain more of a colony with fewer kerbals, scientists of higher levels can perform new experiments in colony labs, etc. So like keep the pilot for cockpit SAS (as you can get around that super quick but it still makes them a good choice for low mass/early flights), engineers repair, scientists refit expendable experiments dynamic, just remove the frustrations from it and move the level up stuff into the management sim level of things.

are there mods to turn off orbital mode yet?

I've seen that HUMANS mod recently that replaces the textures/tints on kerbonauts and I'm kind of interested in doing something similar, but for adding to the kerbals' models. Specifically I want to add gamer catgirl headphones to the available roster of "hairstyles". Do we have a way of doing this yet?

This for me was one of the strong points of KSP1's UI. Far from perfect, but battle tested enough that it did everything you needed it to in a relatively accessible way. that explains why my attempts to put rovers into planes has been a dead bust then? All things considered though, as much as I was considering waiting for 0.2.0 for getting back in to the game, patch 5 seems genuinely worth a try out.

I do think it'd be interesting to have a split of ISRU you can do on craft and ISRU you need a base for? Maybe limit ISRU on vessels to electrolizing water/ice, creating a situation where you can refuel some engines mid mission (essentially just NERVs) but for other/more processed resources, you need to bring out a tanker or build a base. sorta creates a lifeline for grand tours being still possible but without trivialising resource gathering otherwise.

good to hear.

Is there any way IG can set up an officially hosted wiki like with ksp1 so we don't have to put up with a wiki hosted on Fandom's garbage ecosystem? I think having a real wiki would also further... further the game's focus on being accessible to new users.

I remember having falling through the ground problems back in either 0.1.0 or 0.1.1, Whenever I went out to the island air field whatever I'd landed there previously would just fall into the world. I think it was back when I was posting bug reports on the pd site though. The thing is it was happening from the launchpad, so at a range of around 30km. Video evidence from a thing I submitted to a challenge back then. As you can see the craft I was using, which was also the one (an earlier version of which) was parked on the island, didn't have landing legs, just fins, and it often landed on its side/tank/intake too.

Hey, so I know CBT is the fancy new terrain system coming in the future but... as with all fancy new things I can imagine bugs are no doubt going to creep their way into it. Would it be a good idea for the first few versions that implement CBT that there be a toggle in the options menu to go back to using PQS so that if CBT starts causing unexpected issues in certain gameplay situations players have an option to temporarily swap back to the older, more longer developed terrain system if they experience any gamebreaking bugs? Only for a couple updates while all the kinks get ironed out.

Is the phantom force in the direction of/opposite direction of the spin of the planet? oh wait I see frank answered that. OK very weird

I imagine you'd get "good enough" results for far render distance with one billboard constrained to yawwing and one overhead static render? another problem to consider is that of shadows though especially at sunrise/sunset. those might be difficult to get looking right.

could be good for designing landers with landing lights too.

thank yes!

probably depends. Last time I had spontaneous dissasembaly that was down to small RCS thrusters spawning midair and I think that one's fixed at the very least. But other things could cause similar issues.