m4ti140

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.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: Ryzen 9 7950X | GPU: RTX 3080 | RAM: 64GB As title says, numbered action groups activate one action at a time. When the key is pressed, instead of all actions listed triggering at the same time, only one of them gets triggered. Subsequent presses cycle the actions in random order. Possibly also because of this: Action groups for mirrored parts, like wings, straight out don't work, see the craft file in other files - AG1 should deploy flaps, it does not work. Included Attachments: Mun-1.json Sabre.json .ipsImage { width: 900px !important; }

+1, I'm baffled it's done the way it is

Does anyone else have a problem where the map view is broken for the command pod that comes with this mod? When switching to map view the icon for the active vessel is not displayed and there is no way to focus the ship. The orbit is still drawn correctly however (it's not filters), so the position can be guessed from the orbit line fade. Also the Space Center button at the top is inaccessible, as if the shuttle was eternally in atmospheric flight. I imagine this could be interference with other mods (I have plenty) but since only SOCK seems to be affected by this bug I wanted to check with other users if anyone else can observe this problem before I start hacking away at my install. EDIT: I discovered the reason for the problem: the hatch locking feature seems broken. It doesn't actually lock the hatches and removing it from cfg fixed the map screen bug.

Ok, wasn't going to even comment but I find people poor shaming others over an educational game aimed at kids to be extremely offensive behaviour. The reason KSP 1 looks the way it does is not because the engine can't handle it (as evidenced by mods, which arguably make the game look prettier than what we've seen of KSP2 so far at lower hardware cost, despite alleged poor optimization) but because it deliberately never received significant graphics upgrades to make it as accessible as possible. The truth is, if you make enough money to be able to afford to shell out $1000 (realistically it's going to be $2000 especially outside of US) for a gaming PC then you're literally not the target audience for Kerbal Space Program. And you're a part of an extreme nieche. KSP is an educational game. It's supposed to make kids interested in aeronautics and spaceflight. The school license exists for a reason. And that reason is gone in KSP2. KSP1 ran fine on school computers, do you expect schools to shell out for RTX 2060s to run KSP2? Or do you maybe expect kids to ask their parents for $2000 PCs to play KSP2, especially outside of the US again. By the time these kids will be able to afford a PC, they will probably have lost all interest in spaceflight, not to mention any opportunity they could have had for education towards aerospace engineering. You are disconnected from the reality 99% of people live in if you think this is fine. Overwhelming majority of people this game is aimed at will probably never be able to play it. KSP2 has one of the highest graphics requirements on Steam right now when per its mission it should be aiming at the exact opposite. I do not live in the US and I literally can't afford a PC that can run this game with my salary, so for me it's end of the road until PCs become more affordable. And same applies to the majority of existing KSP users.

Nah, this looks perfect, exactly how Eve should look. It has the same vibe as Nassault's "Emerald Sunrise" video but it looks way better. Between this and Parallax Laythe looks like planet Vvardenfell now, which is amazing At this rate KSP2 will be graphically obsolete at launch.

Do command line arguments still work using this method? I'm running the game in DX11

[disregard]

So... there are still some gremlins with the LM IVA, the RotateInternal module seems to fix it but I had it revert to backwards orientation on crew transfer. Switching vessels or saving/loading fixes it again. It could be the Reviva mod interfering though, will check without it.

Yeah, I play on 3.2. And so far overhauled Apollo didn't need any boosts to parts, it's just the SLA that had an issue (and the regular one was fine in the first place). I'll check out the repo. I think I'll just do PRs for the cfg file stuff I mentioned above.

I did some testing on this on the release: the jettisonable SLA doesn't just fail to shield the payload, it itself seems to be a massive source of drag. I'm playing on a 3.2 scale system (which seems otherwise perfectly suited for the new Saturn parts) and with jettisonable SLA I was not able to reach orbit in Saturn IB without a stage 1 extension, it wasn't lofting the trajectory high enough for S-IVB to have time to circularize. I wasn't carrying any payload other than the CSM itself (open top version obviously, in case that makes a difference). With non-jettisonable version I could get into orbit just fine with otherwise identical config (SM in ASTP config, empty bay with just a docking target). Looking at flight recorder revealed that drag losses with jettisonable SLA were more than doubled, over 800 m/s against 300 m/s with non-jettisonable one. I will look if the latest changes in repo fix this scenario. Other, problems I noticed with the overhauled Saturn/Apollo: 1. The heatshield and CM do not have the body lift disabled. This is bad, because the body lift vector is opposite to the lift surface vector, resulting in completely bogus aerodynamics: at reentry no lift is generated without extreme pitch angles (because the body and lifting surface lift cancel each other out). At subsonic airspeeds the pod gets completely overtaken by Kraken (especially with offset CoM set) and starts to attempt doing loops, because for some reason the body lift completely overwhelms the lifting surface. This is thankfully a very easy fix, just set disableBodyLift = True in ModuleLiftingSurface for both CM and heatshields, increasing the lift coefficient for the heatshield might also help but haven't tried it yet. 2. Less bugs and more design considerations (some are probably bugs though): The lunar ascent module needs an additional, forward facing control point, this is thankfully a simple cfg edit The CM experiment storage container doesn't have canBeTransferredToInVessel = True and canTransferInVessel = True, as a result experiments can't be transferred from ascent module without EVA A stretch maybe, but S-IVB IU could use an additional control point too, this time rolled inverted, (0,180,0) as the reference frames of launch vehicle and spacecraft are rolled 180 degrees from each other - the rocket flies the ascent with the CSM facing heads down, but for the launcher that's actually a heads-up attitude. Not really necessary though, this can be accounted for in kos/mechjeb

@PART[bluedog_Apollo_CrewPod,bluedog_Apollo_CrewPod_5crew]:NEEDS[ComfortableLanding]:AFTER[Bluedog_DB] { MODEL { model = ComfortableLanding/Models/BDapollo/AirBagBDapollo scale = 1, 0.88, 1 rotation = 0.0, 0.0, 0.0 position = 0.0, -0.05, 0.0 } MODULE { name = ModuleAnimateGeneric animationName = CL_BDapollo startEventGUIName = Deploy endEventGUIName = Close actionGUIName = Toggle //restrictedNode = bottom eventAvailableEditor = true eventAvailableFlight = false eventAvailableEVA = true } MODULE { name = CL_ControlTool } MODULE { name = CL_Buoy buoyancyAfterInflated = 1.5 COBAfterInflated = 0.0, -0.2, 0.0 playSoundPath = ComfortableLanding/Sounds/Inflate_B volume = 1.0 animName = CL_BDapollo animLayer = 0 } } Here's my version of the patch, with some additional edits I didn't test yet to CoB position and max buoyancy. I also rescaled it to fit the model better (with additional last minute changes that I also didn't check yet, will update if they end up being broken. I also removed all the bogus, gamebreaking changes to ModuleColorChanges and removal of existing ModuleAnimateGeneric - turns out neither of those changes are needed for the mod, I have no idea what they were doing there.

They're not supposed to be lined up like this. The original was accurate to how it looked IRL, they were too far away from the center axis, not at a wrong angle. IRL each bag is attached in 2 points, not one, to both neighbouring flanges, and stowed underneath the main parachutes. For it to be truly accurate you'd need a new flotation bag model

I have same issue (it's not just ship icons, the whole map screen is jittering and even planets in high orbit become weirdly smeared), the only mods we have in common I think are Scatterer and DOE, but you should post ALL of your mod list, literally just print dir to file using console. I'd add that it started after I updated both of those mods. It could be a rendering issue.

Does anyone else have the issue where using modular launch pads completely throws off delta-V calculations in mechjeb, breaking PVG?