mattihase

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.

yeah so long as you never need to middle hold and drag.

Oh boy yeah that's been super common in 2 compared to 1. Perhaps having the gear temporarily anchor stuff could be a good replacement for physics easing.

I've known some games livestreaming QA/devs showing off builds before. Probably almost impossible to get the go ahead for from the publisher but it would be a pretty good way to both host a casual, real time chat between the devs and the community and showcaste truthfully the states of upcoming builds.

oh yeah they're not exactly consumer friendly but but honestly as far as "long term support" for games goes they're probably a decent example for AAA compared to all those dead live services.