jclovis3

What does 10.273lbs 9oz actually convey? That is not how the imperial system works. Where'd you guys go to school? Canada? To see what I'm asking about, look at that 4th photo showing the fractions on some other parts. Okay, true story. I went into Starbucks one time and asked for a Pint-o-Pumpkin-Latte. The young lady looked up at me and said we don't use metric here.

Regarding #6 on time warp restrictions... I understand that maybe part of this lies in lessons learned from KSP1 where an auto time warp has to be able to increment and decrement the time scale as you get closer to celestial bodies (CB) because when you get below a certain altitude, say the height of the tallest mountain, you need time to calculate the terrain mesh to see if there will be an impact. But, IMHO, if your Pe is greater than the height of the tallest mountain AND there is no atmosphere, THEN the time warp restriction should be raised. There is but one reason I can think of to have a relatively lower time warp within a small body SOI and that is for how quickly you can run into and beyond the Pe marker if the player doesn't have enough time to react and abort or slow it down manually. For this, I would say that the time warp restriction should at the very least force the player to observe the active vessel passing through the SOI for at least ten seconds if an escape is trajected. For stable orbits however, there should be no limit, or at least not while the CB itself is the center of the camera focus. I can see maybe setting a limit when the ship is the center of focus as it can be near impossible to see where the ship is in relation to it's Ap/Pe markers when the camera is moving around rapidly. The other reason I think time warp scales were meant to slow down at higher altitudes is because they didn't just jump directly from 10000x to 4x but had to decelerate smoothly over time, which could lead to an overrun of the expected stopping point if there wasn't a way to force a step down in warp speeds getting near it. This though I feel can be overcome with a calculated curve similar to the trajectory curve where the rate of time warp can be reduced as you approach the intended stopping point just as smoothly as the rate of altitude change slows as you approach the Ap of a suborbital trajectory. For LOD settings on CB assets, you can use the lower resolution textures while at higher warp speeds to improve performance. LOD need not be reserved for distance.

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 22H2 | CPU: AMD Ryzen 7 7800X3D | GPU: MSI Gaming GeForce RTX 4080 16GB GDDR6X PCI Express 4.0 | RAM: 128 GB DDR5-6000 What happened: My attempt to land on Eve with 10 kerbals was almost a success but the automatic settings for landing gear was not sufficient. Upon loading a quick save where the entry trajectory was already set, the atmospheric reentry incurred overheating not seen in the first run. No changes were made to make this any different. Just loading from the save file. After parachutes deploy, I would have manually tightened the landing gear to see if it would land better. Could not load from a save with parachutes deployed as they would all be cut. As I cannot reload and have parts not overheat, a save file would be useless. What was expected: The results of entry should be the same before and after loading from a save. Evidence: Much of the video was increased to 16x speed on account of getting only 4 fps with stretched time. Included Attachments:

Atmosphere Samples from Eve atmosphere (shallows) show that it contains: sulfuric acid gas - a strong oxidizer that enhances the combustion of other substances but does not burn itself. (https://www.sciencedirect.com/topics/earth-and-planetary-sciences/sulphuric-acid) sulfur dioxide - forms when sulfur-containing fuel such as coal, petroleum oil or diesel is burned. Has oxygen so maybe it can be extracted and used for air breathing engines. hydrogen iodine - Kind of useless unless you extract the hydrogen to combust with oxygen from the sulfur dioxide water vapor - Another source of hydrogen and oxygen which only takes Ec to separate

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 22H2 | CPU: AMD Ryzen 7 7800X3D | GPU: MSI Gaming GeForce RTX 4080 16GB GDDR6X PCI Express 4.0 | RAM: 128 GB DDR5-6000 To replicate: Have two very massive ships about to dock and when within a few seconds of docking, quick save. Now observe that docking does not cause a collision. Next, reload from quicksave. What happens: The loading screen is still up but you hear the crunching of your ships colliding as if they were in motion without the physics engine (such as a time warp) and then phased into one another when the physics engine turns on, blowing up before you even have a chance to see or interact with them. What should happen: Loading from a save should enter a pause state until the user can access the GUI and unpause it or make choices during the paused state, like adjusting camera first.

Devs: Why are we cutting parachutes that can be repacked? There should be no cut action. The repack parachutes presumably uses a motor to pull them back in so how would it pull a parachute back in that was cut? If a parachute was cut, we should not be able to repack it, especially while flying. Just do away with cut and jump straight to repack. Additionally, maybe set the Arm or Deploy action to automatically repack first if it is not packed.

Still happening in 2.0. Even when you manually select a part to control the craft from, as soon as any major parts separate, there is a risk that the controlled craft is not the one having the part you selected to control from. Expected behavior: Upon separation of parts, even if both have controllable modules, the part having what I specifically set to control from should be the craft in control. What's more, the brackets should allow me to switch craft in the event that a debris is the controlled vessel. At present, you have to pause and enter the tracking station to do this.

Happens with fuel lines too. Probably uses the same mechanic.

Along with the rover distance bug, maybe there is correlation with what happens when physics unlocks on a craft that you EVA'd far away from (low grav moon) and back where the ship may either spawn above ground and crash, or for any other reason just fall over and/or break apart. Also, I'd like to suggest maybe SAS not changing state when a kerbal exits/enters a ship if there is at least one other kerbal or probe core controlling the ship (with enough EC). I think the missing trajectory bug and the mysterious landed state are one in the same. People missing their trajectories should check their state in the tracking station view directly from flight (don't load into KSC first). They may see this to be the case. I request some features in the VAB: 1. Add a way to see which direction the ship is facing on the launch pad in case you rotate it around as anyone creating a plane-like rocket will want to be belly facing east or west. Putting a compass rose on the ground would suffice. 2. Remove the right-click to auto center on a part. It just gets in the way when you're trying to right click and drag to move the camera. Maybe a double right click on a part can be used. Double-click thresholds would have to be set up in options though. 3. Allow turning VAB lights off to check your lighting conditions in the dark. A whole new lighting setup may be required to ensure emergency exit signs over doors and other pathway lighting remain lit for worker safety. 4. Add a control to center the active vessel on the cross hairs seen on the floor. 5. Align the isometric view grid with the cross hairs seen on the floor (especially if #4 will not be implemented). Looking forward to finishing that last remaining contract (held on to for so long) to land and return a bunch of Kerbals from Eve.

I'd also like to mention that KSP1 had different colors for physics enabled time warp, and they ranged from 2x-4x. Most importantly, you could use this in space to speed up a slow turning ship by holding right alt while tapping the warp increase > key (at least while entering 2x) to tell the game you want to advance only into the physics warp. After that, if you hit the > key again without the right alt, it would remain within the physics warp speed set and would not go past 4x if you kept hitting it. Returning to 1x would reset it to the normal behavior again so hitting > again would advance you in the non-physics warp mode. There is a rather troublesome delay, especially with big ships, when you enter or exit the on rails time warp that sometimes messes up your thrust calculations during warp. Tapping the > multiple times during this delay seems to cause more trouble so I tap it once and wait until I see the dV or other trajectory indicators moving again before increasing to a greater warp.

There is an option to use a 24h Earth day in KSP1 and I believe they intend to add that to KSP2 if they haven't already. Standardizing the display output makes it easier to verify screen space usage with either game option being used by the player. Another important matter to address IMHO is the fact that KSP1 had an auto-naming scheme that relied on optionally set names and priorities for each command module or drone core so that when you dock vessels together, the controlling part with the highest priority and after that, closest to the root node, would set the name of the vessel and when you undock them the same algorithm would determine the name of each vessel. In KSP2, every time you dock or undock you get some random crap like Combined, or your original vessel name with a number appended. Then we have to go back into the tracking station view to rename each one. I just want what we have in KSP1 again. This of course will still be more useful if we could have individual PAWs when we right click a part instead of the part manager's list view.

Uh, no on that. You still have to prove your vessel can land and remain stable, especially if it ends up landing on the side of a hill or mountain. Also, depending on your parts, your vessel may sink rather than float on splash down. The speed at which you impact the ground and the mass of the vessel and other attributes all contribute to the chance that your vessel could break apart or even blow up on landing. Your vessel may not slow down enough if it lands in high altitude as the air is thinner and thus the parachutes not as effective. So in short, a shortcut to recover a vessel that is still falling with parachutes should be an option in the cheat menu or other configuration but not in the default play setup. If you're going to do that, you might as well add recovery of vessel to any CB since one day when we have colonies, we might be using that anyway.

You can leave a controllable (if not flyable) vessel on the ground near these items to "Control" or "Set Target" on any time you want to see or visit these features again next time. When you visit under the contract, take along a probe you can decouple from your craft and leave behind as a geotag marker. In KSP, we could at least target flags we place but not in KSP2. Do you think this is going to punish Intercept Games in any way? You already paid them for the game. Uninstalling isn't going to get you your money back. Best to keep it as a reminder of why you enjoy KSP1 so much. Even KSP1 was a work in progress for years and is still quite buggy. Give IG a chance to build this one up the right way. You wouldn't call a cake crap just because it hasn't been iced yet. They need to make sure it's not raw in the middle before they add all the icing.

I believe the Dev intent here is to reduce the number of vessels needed just to establish and maintain a clear net to any location in favor of all the outposts we will be building and keeping within our save files. More vessels and outposts means more to process each frame. I can see perhaps a technology leap where a single part can deploy to release a constellation of communication probes that slowly take orbit around a CB and become non-interactable and non-physical. These probes would constitute a net around the CB and to any long range antennae in low orbit of it. You could interact with the craft that deployed them but the part that deploys them will be considered used and cannot be packed up. These micro-probe constellations may even have a life span like the nuclear generators due to possibly being powered by the very same technology (making it a dependent tech). Not having the ability to scan a footprint to see where various biomes are in relation to the craft as it passes over is frustrating, especially with science equipment that runs in low orbit and is biome specific. Currently, contracts are the only way I know to locate these POI's and I do hope at some point in the future, they give us the area scanning ability. I find it odd that probes like the Stay-Put-Nik can use SAS to it's fullest degree, let alone other probes having full use of SAS as well. In KSP1, you had a reason to unlock better probes to have a fuller range of functionality. Now it is all about size matching and power consumption or mass.

I expect it means that they feel our pain. I believe the reason time warp restrictions were so restrictive in both KSP and KSP2 around these low gravity planets was due to how location changes are calculated during warp vs non-warp. I believe that during non-warp, and when you have control of a craft, location data is more accurate and centered around the controlling craft so it doesn't need to be able to represent much farther distances than perhaps the CBs SOI you are in. Time warp needs to allow for your craft to jump through other SOIs and cross greater distances, so the accuracy of your location may be dropped by a bit or two in favor of adding more significant bits on the higher end. This degree of imprecision could have consequences if too close to other celestial bodies. A more aggressive tuning may be in order to determine the actual safety limits and possibly set them with respect to CPU speeds as well.