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.