m4ti140

Right click the navuitls icon and check if the option to hide the UI in IVA is turned on, disable it.

For some reasons the Dessert Airfield runway does not appear on the list, even though the configs are definitely there. EDIT: Copypasting the MH config into default runways fixed the problem.

There appears to be an issue with the thrust reversers, where they irreversibly accumulate thrust during flight, resulting in insane amounts of thrust upon activation on landing even with engines on idle. The problem does not occur when testing the reversers from the standstill, fresh after spawning. However after taking off and landing, the same test results in reverse thrust 2+ times higher than the nominal thrust of the engines, while the engines in question are on idle. Note that this has happened with afterburning engines (Panther), so multiple modes might be a trigger too. EDIT: I looked at the original code and did some more testing: indeed, it appears to be a problem with multi-mode engines: specifically, the code sums up the current thrust value from all engine modules on the part. Problem is that if a mode is currently disabled, it appears to hold the last thrust value it had at the moment of mode switch. As a result if the engine is spooled up to maximum wet thrust and switched to dry mode without touching the throttle, upon activation of the thrust reverser it will apply the full wet thrust even with throttle at idle. Quickly cycling the modes when the issue occurs clears the bogus thrust value and returns the thrust to normal.

Internet Archive isn't fully safe either, because they are under assault by corporate lawyers recently. They had to take down 500k books that were all lent one copy at a time, rather than distributed for free download. It's not out of the question that they could go down completely one day. Someone needs to store the dump locally in case it ever needs to be hosted elsewhere. EDIT: nvm, I see that this was the intention all along, disregard.

They cannot update anything if you don't allow it to update. KSP has no DRM, it's portable (even if you buy it on Steam: you can copy the whole installation folder elsewhere, even to another system without Steam installed, and run it from the KSP_x64.exe file) and requires no internet connection. You can literally make a flash drive that contains every version of KSP ever released, ready to run right off that flash drive on any PC, without any online clients. And you can make that drive using Steam if you want. In fact if you're this worried about mods, I'm shocked you're even running the game through Steam to begin with.

For KSP this is actually wonderful news, anywhere is better than T2 for the IP. What I'm afraid of is that this might kill The Outer Worlds 2. Considering this is basically T2 outsourcing to Microsoft, they will probably not sell it, they'll just kill it.

I believe he was referring to the code base, and unfortunately no, he's right, it should be nuked and rewritten. Like it should have been done from the start. You can reuse the assets, but the code is a waste of time and resource. It would literally be faster and easier to start over at this point.

The only thing that killed the game was corporate greed and mismanagement. Nobody from the team was deleting or shutting down suggestions, the only pushback I noticed was from users, I did have run in myself with that, I won't say who but everyone can read through the forums if they want to know There were certain individuals that were acting like the game was perfect as is and attacking anyone who posted suggestions, which devs asked for as that was the point of EA program to begin with, in a forum specifically dedicated to it. But again, those were not admins or devs, those were users, even if we put on a tinfoil hat and assume they were T2 paid trolls, all they could do is yap, it had no influence over the devs. What killed the game isn't the right question to ask, the correct question to ask is who killed the game. T2 pencil pushers did. Corporations aren't a force of nature. The devs weren't given a chance to finish it. Whether it was corpo or studio higher ups that caused the delays in development doesn't really matter.

Where are you doing this? You do realize Coriolis force is not present at the equator? If you travel further north or south and leave your aircraft flying horizontally you will see that it will, in fact, fly along a curved trajectory and will not reach the pole if you set off heading directly North/South without corrections.

The entire landing stage structure is based on trusses. Also the RCS ports.

I would suggest talking to blackrack. He developed flowmaps for volumetric cloud movement in his EVE rework. It would probably be smart to make the two mods interact, i.e. allow syncing EVE flowmaps to wind, or straight out use the same system. This would allow clouds to be synced with wind, making stuff like Duna dust storms or Jool weather patterns actually deadly instead of being eye candy.

They're very light weight compared to other parts, so they're the material of choice for more complicated designs. E.g. something like a skycrane with engines offset from the center - the engines can be connected by trusses. Also offset RCS ports. Granted, they'd be more useful if we could build in space or had robotics (both KSP1 features) but there's still plenty of uses for them. One use I can think of early on is for escape towers - the existing escape tower part is useless (too little delta V and too much thrust vector offset, making the capsule spin instead of flying away from the stack) and only exists in S size. EDIT: Another use I forgot about, one that is the most common although I don't really like it cause it's a bit of a hack: surface attachment of parts that can't normally be surface attached. There's a dedicated part for it but it's heavier and bigger. Also yes, you can achieve anything you can build with trusses by simply using the offset gizmo and having parts float in the air, but that's not a problem with the trusses, that's a problem with offset gizmo being OP - it shouldn't allow offset outside of the bounding box of the original part. Finally: replicas of real spacecraft and stations will often require trusses - this goes back to the escape tower use, yes you can just revert in KSP (unless you play with reverts and quicksaves off) but you might still want to make something like a Mercury replica and that will require a truss to build the LES tower.

Regarding this, if I may suggest something: Discoverable mapping should require the other two maps to be completed first, at least in the areas discoverables are originally in The optimal altitude for them should be 0 m AGL (requiring aerial survey in case of atmospheric planets) and the penalty should be precision: the map should simply show a circle, with the discoverable at random position within this circle. The lower the scanning altitude was, the smaller the circle should be. The site should not be identified (just ??? for name on map) until it is scanned from within a fairly small distance, say 1000m agl, or landed at and taken science from (which would pinpoint the exact position on map) This would form a gameplay loop where orbital surveys would be used to determine general area for search and then the players would transition to more local and more precise methods until they find the exact location of the anomaly.

Workspaces allow for only one named vehicle per workspace...

Are you being disingenuous on purpose, or did you misunderstand what OP wrote? If you're discrediting legitimate feedback on purpose, isn't the whole point of Early Access supposed to be precisely this? I came to search for this because I agree with the OP, the aircraft tech progression order makes absolutely zero sense. You get overpowered parts at the beginning (A single Wheesley can easily propel any aircraft you can build at this tech level past the speed of sound without a problem in this game), while the lower power J-20 isn't unlocked until Tier 2 at 400 science. Together with fixed front landing gear - while fixed main gear is in first aviation tech node. Then it gets even more ridiculous when tail booms aren't unlocked until Tier 3 at 1400 science! Those are all low tech parts that, in some cases, are obsolete by the time they're unlocked due to being placed too far in the tree, while more powerful parts appear too early. It's the same issue as with docking ports and decouplers, with smaller decouplers unlocked too late in the tree. In KSP1 the first aircraft players would build would typically use Mk1 cockpit, fixed landing gear and twin J-20 (i.e. weakest) engines, with empennage attached via tail boom to save part count and weight (in career mode, since buildings had to be upgraded to increase those). This made perfect sense, as it was the lowest tech, lowest performance aircraft that could be built even in sandbox mode, those were simply the weakest parts - so they were early in the tree. Here it feels someone moved these parts around at random so that it doesn't look too much like the KSP1 tree (why?) discarding any logic behind their original placement. Now the basic, low power builds require Tier 3 of tech tree and a trip to Duna, even though we can build supersonic fighter jets by this point in the tech tree.