Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by m4ti140

  1. The entire landing stage structure is based on trusses. Also the RCS ports.
  2. 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.
  3. 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.
  4. 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.
  5. Workspaces allow for only one named vehicle per workspace...
  6. 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.
  7. 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; }
  8. 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.
  9. 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.
  10. 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.
  11. Do command line arguments still work using this method? I'm running the game in DX11
  12. 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.
  13. 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.
  14. 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
  15. @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.
  16. 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
  17. 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.
  18. Does anyone else have the issue where using modular launch pads completely throws off delta-V calculations in mechjeb, breaking PVG?
  19. How did you get it working? For me it's doing nothing. EDIT: Nvm, it seems that it's doing something, I think it was another mod
  20. This is some pretty disgusting misinformation... That's not what happened, these mods were in works and were being showcased long before the official remakes were even announced. This. Things like scatterer/EVE/parallax, kopernicus and planet packs. There are lots of places where the axe could fall.
  21. "BoulderCo" is your EVE config folder, without it it shouldn't work unless you have another one from a visual pack.
  22. Too bad this is the last update, cause the same steering functionality would be EXTREMELY helpful for actual aircraft control surfaces. All aircraft capable of supersonic flight suffer from exact same issue, as you accelerate the control range becomes to large. It's so bad that beyond a certain speed SAS tuning is so off it causes catastrophic oscillations and needs to be turned off.
  • Create New...