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.

There are USB external numeric keypads available for laptops if you don't have a function key that enables use of the right side letters that may have number markings on them as some laptops have. I assume you are looking for a way to put the reaction wheels in an action group to turn them on or off as needed, right? You don't need a keypad for that. The top row of numbers is used for action groups as well. To set up action groups, use the menu with the 3x3 grid of dots to open up additional options, like resource management for moving fuel, and kerbal management for moving kerbals around between modules. Your action group options are in there. Scroll down the menu on the right and select the group number you want to use. Then that shows up on the left with assigned actions. Your parts list is then on the right and you can expand any part and select from available actions, like toggling reaction wheels. You cannot yet adjust sliders with this though. I find it handy to use two groups to turn them on or off so I know they are all in the same state at the same time. Did this while driving around on Eeloo for a contract. Go airborne, turn reaction on. Land, turn them off only when you need to move forward or back. Reaction wheels still help with controlling your turns and rolling level. Kerbal EVA jetpack can be toggled with R, or what ever you bound RCS to. You should be using RCS thrusters while docking anyway though smaller craft often don't need them as they can turn quickly.

I think I found some new and interesting correlation. The setting for persistent debris, if set to zero, may influence this bug. I ran several test and observed in map view after staging that many of the debris trajectories would blink just as the ship trajectory does, and with zero persistent debris, I see the ship get eaten up with the debris clean up. I thought this setting only affected what debris is saved so it would be cleared when you reloaded from a save, but if my new theory holds any weight, the cleanup around the launch site and low atmosphere is including the ship because all debris are vessels, and the cleanup may not be properly checking if a vessel is debris before cleaning it up.

This bug seems to be related to the ship parts and how they are assembled. I took the ship I can reproduce the bug with and slowly started stripping away parts to test it in launch. I found there were sections of the ship I could remove that would prevent this bug from popping up, but when I took note of the parts I removed that were not located anywhere else on the ship, I was reduced to just 3 suspect parts. I tried building a simple ship using those parts and still could not replicate the bug, so I have to believe it is maybe not the part but how they are connected. In all instances of the bug however, I had to be in map view when I staged to replicate it. I suspect it may have something to do with the launch clamps on the ground but again, simpler ships using suspected parts are not triggering it. Something else I had considered was that the ship had to be massive and take off slowly, or be moving too slow at a higher altitude when that first stage is fired. I have yet to find a definitive cause, but perhaps this info will help.

I am saddened that the inflatable heat shield is broken in KSP2 because all of my great Eve Entry methods are busted because of this. In KSP, the inflatable shield can withstand 3500 K, which is 200 more than the other shields having ablator. I know they said KSP2 would be different, but that shouldn't change the fact that this shield should tolerate much higher temperatures than most other parts, even if collapsed (3250 K in KSP). Ref: https://wiki.kerbalspaceprogram.com/wiki/Heat_shield

The inflatable heat shield exploding has got to be a bug. It is supposed to withstand heat better than any other part, and yet much of the ship seems to pull through far better than these hydrogen filled balloons.

Reported Version: v0.2.0 (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 I couldn't find the report on disappearing trajectory or ship reverting to landed while in flight so forgive me if you know this to be a duplicate. Maybe the old report was lost due to the recent maintenance. This report is to add that I replicated the bug three times with the same ship. After the first, I reverted to launch. Then I quick saved before the next stage. I watched in map view when I staged to see my trajectory line vanish. The tracking station confirmed my ship was landed, not in flight. I reverted to the save and repeated. Same thing. Then I reverted to the save and remained in flight view. The bug did not trigger. Included Attachments: .ipsImage { width: 900px !important; }

At least the sun still moves (an related shadows and solar panels).

You tested this by docking the same rovers twice? There is a line item in the save files for last docked part. Maybe repeating the same connection isn't going to reproduce the bug. Try docking rover A with rover B, then undock using the docking port on rover A while in control of rover A. Then dock rover A to rover C. Now repeat test by undocking A/B using the docking port on Rover B while the controlling part is still on rover A. Then Dock each with rover C one at a time and see what happens. I've been meaning to get around to this but been busy with another mission. It seems to me, the culprit could be related to which part has control and which docking port is closest or farthest from that controlling part at the time of separation, or which part is used to cause the separation. There are at least six different combinations of this to run through. Edit: I just ran some tests with three rovers and verified the smaller docking ports as well as the Docking Port Sr, which is what I most commonly see this bug with. In my tests between three different rovers and all combinations of controlling parts and which part was used to decouple, I could not replicate. I know this bug happens though, so we might need someone with access to the code to drill down and find it.

Reported Version: v0.2.0 (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: While running tests with a heavy craft to test landing on Kerbin with parachutes and LT-3 Landing legs attached to ST-XS-4 girders, during free fall in Kerbin atmosphere at 5990m (Sea) altitude and 145 m/s (Surface) speed, the "linkage" between these two broke. No parts were actuating at the time. The ship was rocking back and forth in the wind is all. There may be some clipping between this part and the inflatable heat shield, but the heat shield was deflated long before the linkage broke. Not all of them break. In this run, two of them broke. Previously, only one broke. There are 24 on the ship. Included Attachments: .ipsImage { width: 900px !important; }

I am seeing this problem as well. Way too many parachutes on this craft to repack and deploy again and not enough time. Gonna have to try from an earlier save. One might think that once chutes deploy, there is not much you can do to affect how your craft lands, but this is not always true. Craft aiming to land on Eve and take off again might have things they need to do before the final landing in preparation for takeoff. Saving before staging anything is just a precaution many of us like to have and reloading that save should not make matters worse.