m4ti140
-
Posts
359 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by m4ti140
-
-
On 1/6/2024 at 8:23 AM, Bingmao said:
Due to lack of imagination of how I can make use of trusses and tubes visually and practically, I would really appreciate some screenshots of how you used them, to spark my creativity.
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.
-
On 1/1/2024 at 11:39 AM, The Aziz said:
They're just dead weight. Anyone actually using them? Like, for practical purposes? I'm glad they're in the very back of the tech tree so they're not required for any other more important unlocks.
Yes I'm in the efficiency squad, anything that's not useful in any way other than shedding weight, adding functionality or vehicle capabilities, is garbage. I see no use for them when I can do effectively the same without them (as in, adding even more mass)
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.
-
On 12/27/2023 at 12:14 AM, Falki said:
Yes, biomes changed, or rather it's that a new concept was introduced.
Copy-pasting from another server:
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.
-
2 hours ago, The Aziz said:
That's what workspaces are for, up to you to decide how to use them.
Workspaces allow for only one named vehicle per workspace...
-
On 1/1/2024 at 3:33 AM, The Aziz said:
Welcome to tech tree. Feature designed to do that.
On 1/1/2024 at 4:51 AM, Kerbart said:If only the game had some kind of mode where you are unconstrained in what you want to build. Anything! Like a kid in a sandbox!
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: 64GBAs 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:
-
+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.
-
9 hours ago, Kerbart said:
Let's see, we've been promised:
- Large vessels with amazing detailing
- Better physics with thrust under timewarp
- Micrometer precision at interstellar travel
- Transparent cockpits with animated Kerbals inside
- Clouds! Water! Trees!
And everyone seriously thought this all came for free?!
Seriously, y'all need a reality check. I'm just happy my local PC Seller has hardware meeting requirements for less than $1000, not as bad as I thought it would be. But I'll let others (that means, yes, YOU who are reading this) do the dirty work of finding out what works and what doesn't before I spend a dime on that.
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.
-
On 1/7/2023 at 12:41 AM, blackrack said:
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.
On 1/5/2023 at 10:07 PM, blackrack said: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
-
-
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.
-
46 minutes ago, Jcking said:
The H03 SLA (and I believe the normal SLA) have had their drag issues resolved in the dev versions, and BDB has been built for a 2.5-2.7 scale system with KSP naturally making large diameter rockets over perform due to mass fractions.
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.
-
On 4/24/2022 at 4:35 PM, Zorg said:
What do you mean by not shielding? is the payload being destroyed? Or is it just a matter of drag. Because in my testing moduleCargoBay was working correctly and shielding the payload. If its drag I will see what can be done.
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. -
On 4/27/2022 at 4:30 PM, UnanimousCoward said:
@linuxgurugamer I modified the config to rotate the model. It looks like this:
The balloons line up (just about) with the physical struts now. Personally I have an odd OCD about symmetry and rotation, and I actually prefer the look of the non-rotated version. But of course, you make the decisions for your own mods. If you prefer the rotated version, I can patch it myself.
Updated version of the patch with the 45-degree rotation:
@PART[bluedog_Apollo_CrewPod,bluedog_Apollo_CrewPod_5crew]:NEEDS[ComfortableLanding]:AFTER[Bluedog_DB] { !MODULE[ModuleAnimateGeneric]{} MODULE { name = ModuleColorChanger shaderProperty = _EmissiveColor animRate = 0.8 animState = false useRate = true toggleInEditor = true toggleInFlight = true toggleInFlight = true unfocusedRange = 5 toggleName = Toggle Lights eventOnName = Lights On eventOffName = Lights On toggleAction = True defaultActionGroup = Light redCurve { key = 0 0 0 3 key = 1 1 0 0 } greenCurve { key = 0 0 0 1 key = 1 1 1 0 } blueCurve { key = 0 0 0 0 key = 1 0.7 1.5 0 } alphaCurve { key = 0 1 } } MODEL { model = ComfortableLanding/Models/BDapollo/AirBagBDapollo scale = 1.0, 1.0, 1.0 rotation = 0.0, 45.0, 0.0 position = 0.0, 0.0, 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 = 2.75 COBAfterInflated = 0.0, -0.3, 0.0 playSoundPath = ComfortableLanding/Sounds/Inflate_B volume = 1.0 //animName = CL_BDapollo //animLayer = 0 } }
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?
-
On 7/24/2021 at 11:38 AM, ROCKETGOOSE said:
Hey, has anyone had any luck using this in 1.12?
I tried, but it didn't seem to be working.Might be something I've done wrong though*EDIT* Got it working!
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
-
On 8/9/2021 at 12:57 AM, bigyihsuan said:
As noted in the SMURFF.cfg comments, a lever of 1 is at "real" scale performance , and 0 is stock performance.
What should a person with an in-between scaled system set the levers, e.g. should a 6.4x player set the levers to 0.64?
Stock is balanced for 2.5x roughly.
-
On 12/14/2021 at 2:09 AM, Kerbart said:
Totally different case:
- T2 reissues old games but has them refreshed and upgraded
- T2 totally botches this release
- Modders roll out their own upgrade basically saying "DoN't BuY tHaT CrAp RelEaSe GeT OuRs InStEaD."
While all of the modders points might be true — It's not inconceivable the newly released game is riddled with bugs, and that the modders did reverse the source code without reusing IP — it's also clear that this undercuts T2 sales. Not just "even if all of the above is true" but especially if the above is true. A lawsuit might be bad publicity, allowing people to pick the free mod over the (probably indeed horrible) commercial release will certainly kill it. From a business point of view that makes the lawsuit pretty much a no-brainer. And yes, had they released a quality product that wouldn't have happened.
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.
On 12/14/2021 at 7:37 AM, J.Random said:I'd say there may be a plausible reason to block KSP1 mods which could make it look or play similarly to (or better than) KSP2.
This. Things like scatterer/EVE/parallax, kopernicus and planet packs. There are lots of places where the axe could fall.
-
On 7/24/2021 at 6:53 AM, ToastedToast said:
EDIT* I found the problem it had to do with Boulder Co being installed for anyone with the same problem.
"BoulderCo" is your EVE config folder, without it it shouldn't work unless you have another one from a visual pack.
KSP2 Does not follow the coriolis effect.
in Science & Spaceflight
Posted
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.