jclovis3

I received the update and it included a text list of all the games they included optimizations for. KSP2 was among the list. I suppose if you needed a web source, you can use https://www.nvidia.com/en-us/geforce/geforce-experience/games/

Nvidia just released optimized graphics settings for KSP2. They're not giving up either.

Just found a couple of posts on LinkedIn I thought you all might like to see. Chris Adderley - https://www.linkedin.com/feed/update/urn:li:activity:7201300880581697536/ Rafael Calonzo - https://www.linkedin.com/feed/update/urn:li:activity:7213717842611908608/

The depots show updates are still being pushed into the private branches. Does T2 have to continue to pay to keep the game on Steam even after development stops? From what I have found, they do not. At least, not for data at rest anyway. They give up 30% of the sales revenue as a commission to steam on all future downloads instead. They may be sitting on the IP to collect revenue from future sales or trying to sell the IP to relieve some of their debt but I doubt they will get back everything they spent on development in such a sale. Other posts I have read suggest that single player games in Steam will remain in your library unless the developer pulls your licenses to the game for some reason. By leaving the game in an EA state, they are protected by Steam's EA policies regarding player owned risk. I do not expect to see KSP2 ever released out of EA without being fully completed.

You simply don't understand the importance of secrecy in business. Companies rival one another to get similar products out the door first because the first to release is empowered to call out any other for copywrite infringement, solidifying their position in the market. Having too much shared publicly in the way of how certain challenges were faced may give competitors working under the radar a way to jump past their own hurdles and next thing you know, they get past the final block preventing them from going public all of a sudden. You may care to read up about the split up of Bill Gates and Steve Jobs back when graphical GUIs were being created into an OS. They started out working together, and then Macintosh and Windows became the split difference. Another reason for secrecy in the video game industry is management of player interest and expectations. Show too much too early and players will get angry that those features haven't released soon afterward. Once a feature is shown off, players expect it to be implemented in time so there is no latitude to change your mind later on a feature. At the same time, keeping everything a secret prohibits growing interest, something which helps to promote early sales while the game is still in Early Access. It's a delicate balance that needs to be maintained, even if the game development is put on hold while finding a new buyer. Leaking any additional information out too early can spoil the potential value and power a new developer would have in managing that balance later.

You looked up jobs at Take2. Try https://www.interceptgames.com/#jobs which is what still has these postings. It does seem however that the links to each of the three jobs are stuck on loading. EDIT: Never mind. I just saw the links to those jobs go to the take2games.com domain as well.

I am under an NDA with another game company and the {modified} verbiage in that contract includes such text as, "Your obligation to keep the {test group name} Materials confidential will continue until such time and to the extent that {company} makes such materials publicly available." This means that certain aspects of the NDA can indeed extend for a very long time, but possibly not longer than 15 years, depending on the laws in the country in which they are based out of. I am not even (nor have I ever been) a paid employee of the company to which I am obligated to under this NDA and my knowledge of classified information from my days in the military will also carry a lifetime lock and key in my mind, partially because I can lose my Pension.

The game is still titled with "Early Access" so I have to ask, earlier than what? Does this mean we can still expect to see more production? A Google search for "jobs intercept games" shows at least 3 job openings for a "UX Designer", "Senior Software Engineer, Graphics", and "Lead Designer" suggesting that maybe the top end of development is being replaced and when they are, they will be responsible for any personnel changes down the pipe. As it stand, it still has fewer features than KSP, and none of the new features promised for KSP2 other than perhaps the training simulators and new wing construction. The added parts (or at least the NERV) could probably be slipped into KSP just as easily.

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.