gluckez

Not exactly. if you look at the roadmap, only the very first box is early access. when 1.0 comes out, it will feature science. There's probably a reason you see 6 development branches on steamdb, if you look at the amount of boxes on that roadmap. and each time they update the base development branch, all others need to be tested too for regression. The science update is the one where it goes out of early access, and is on par with ksp1. I guess they'll increase the price at that time, but that doesn't matter for me, as I already have the game xD

There are always some devs working on features, but they just won't be released to the public until the bugs are gone. The patches are coming less frequently, because in the beginning they focussed on the bugs that were easier to fix. The bugs that are still in the game now are the ones that are harder to track down and fix, such as wobble and orbital decay. other bugs may be fixed with a few lines of code, but some require an overhaul of the architecture, or are the result of tiny calculation errors made repeatedly every frame, over thousands of frames or while time warping. The features that are on the roadmap, are also in the game, but just disabled. If you go through the code you'll find systems for multiplayer, science, colonies, different kinds of kerbals, orbital assembly buildings, etc...

I think a lot of people are just lurking here, like myself. I don't often comment because every single conversation on this forum turns into the same old rant by the same people. it's almost as toxic as reddit. I'm just lurking in the hopes of seeing an update, or announcement of an update. It actually is fully featured, there's just a lot of features that are currently disabled because they're working the bugs out of the base game.

This is true, and got me thinking and doing some digging. I went through the code myself and noticed that the current implementation is only using configurable joints. There's definitely good arguments for that, probably the best one being the connected anchor and primary and secondary axis that you can set, as well as limiting rotation and motion between parts to some degree, but it's also prone to buggyness, and thus wobble. One option would be, that in case of vertically stacked parts, you could use the fixed joint. But the problem there is then that there's no wobble whatsoever. I think most people wouldn't mind that, for obvious reasons, but then you lose certain aspects that make the games physics simulation so fun. For example, you would expect a massive rocket, consisting only of small fuel thanks to eventually collapse in on itself, because that's just bad design, and fixing it all in place with fixed joints would cause it to be really stable, whereas reality wouldn't exactly agree with that. In that case, it's not the joints between the parts that are flexing, but the parts themselves, and replacing all parts with a soft-body (to a certain degree) probably isn't the way to go either. One other aspect to consider is clipping. Configurable Joints in Unity allow you to give an offset on the rotation and position of an object, and the engine would then use provided spring and damping values to try and keep it there, unless other forces (drag, collisions, gravity, thrust...) act on it. Fixed joints can't solve that problem, the only alternative would be to parent the gameobjects, but then you have overlapping colliders, and external forces couldn't break these things apart in any natural way, it would have to be coded, which would again result in several different sets of the rules of physics. Another way would be to use procedural meshes for the colliders, but that would create a big performance hit, and would be a mess to sync up in multiplayer, as well as pose a bunch of challenges when it comes to texturing and normal mapping. I'm pretty sure the devs have already explored all these options, and are indeed working to make things more stable. From what I've seen, with a decent ascent profile, and a good amount of struts, you could launch the ISS in one go on a rocket and you would get there. But IRL that would be an aweful choice, there's a reason why it was assembled in orbit. For the time being, I think we're stuck with the wobble, at least until all the forces on the joints are properly configured, but that's part of optimisation and is expected to take some time in EA.

That's not how that works. Daily scrums are something that every dev team does these days, and when the entire team sees that you've been investigating that same item for weeks or even months, they'll ask questions. eventually, you'll be held accountable for "just putting whatever information you want in it". Daily scrums exist exactly for that kind of situation, to unblock someone as fast as possible. so there's no doubt that multiple people are working together on solving the same issue if it's been open for so long.

I think that would only lead to players complaining on a daily basis as well. Also, "just a screenshot", means nothing to the majority of the playerbase as a lot of time as a developer goes out to things like technical analysis, meetings and unit testing.

I'm afraid that would only cause more kraken attacks. I think the bouncy legs are caused by Unity's spring joint clipping into the terrain when loading, which causes the engine to try and push it apart again, thus pushing the whole craft up. They would need to load in the spring joints at a set distance, saved when landed, and gradually lerp it to it's normal position, before increasing the spring strength. a fixed anchor would likely result in overlapping colliders because of that and make it worse. but I could be wrong.

I think that's a big part of ksp's charm. real landers will also try to not land on a slope, and landers are designed for specific area's as well, to make sure they don't tip over. the sliding is a different issue, but if your lander is tipping over, maybe it needs to be designed differently. it's also possible to adjust the strength of the landing legs already, so I see this as a non issue. the only issue I still see is that when the craft is loaded in on a surface, the craft sometimes bounces up.

why do you assume that's not what they're going to do? They've been investigating this for a while, so there's definitely a good chance that they've come up with some short and long term solutions that they want to address. Also, wobbliness is what's been the community's biggest issue so far, the fact that they're talking about it makes it communication. The community broadcasted it's concerns about this, and they heard it, and will address it. that's the 2-way you're talking about. or do you want them to hold your hand and bring you on the talk so you can express the same things everyone else has over and over again? let's see tomorrow after the talk if they've discussed possible solutions or not.

May he rest in peace. that's the reason that my first real mission was with a space plane to laythe, so he could chill at the beach

ksp2 hasn't even released yet

you're right, but I think this one is more of a bug than an actual kraken attack. the kraken attack is probably a result of several forces being applied simultaneously because of SAS and reaction wheels. So I believe these are seperate issues, but that this one can cause a kraken attack. either way, there's an important distinction that needs to be made between what causes the kraken attack, and the nature of the kraken itself. I think the nature of the kraken is those floating point rounding errors, but the cause can be anything from overlapping colliders, misaligned forces, etc. I'm pretty sure the dev team already knows better than I do how it works, but that it's also a complicated issue to crack.

I don't think it's that simple. I think it's related to floating point rounding errors, and overlaps between colliders caused by those errors per physics timestep. those colliders would need to be pushed apart, which causes other colliders to also need to be pushed apart again. It's easy to attribute it to unity itself, but I think the issue is related more closely to the nature of floating point calculations by computers in general.

then the question becomes: is that the desired behaviour? because if it's a non physical craft, how is it accelerating with the engines on? and with that implementation, parts of the ship will simply phase through objects during timewarp. that would make it very easy to avoid collisions when playing multiplayer, just turn on timewarp and wait until you passed through entirely. and being able to provide thrust during timewarp would also mean someone could mod the game and add a 1x timewarp that does the same, so you would never experience any wobble or collisions during takeoff.

that sounds a lot like a hack that would hide the underlying issue instead of actually solving the problem, and it would make it even more difficult to track the problem down and potentially raise more bugs if not implemented perfectly. it's also not just one variable, it's a system that needs to know exactly what is happening to a vessel, or a collection of game objects at any given time, measure it's momentum and apply a force in the opposite direction, unless the change in momentum is caused by a scenario that is either directly started by the player, or a consequence of interaction between 2 or more objects. So there's a lot of hidden variables. I like the active thinking and the willingness to cooperate with the devs though, good work!

yeah, people are impatient and easily triggered here, it's almost as toxic as reddit. You get a post about an AMA that the devs did, answering questions from the community, and almost immediately people find something they don't like and it turns into "The devs don't communicate and they haven't implemented this weird feature that I've been demanding since last week so they are worse than hitler". my advice: just lurk, don't engage xD. I'm pretty sure I'm already triggering some salty people here just by saying this and it only proves my point.

I can imagine that if that craft happens to be a space station, you wouldn't want all your kerbals killed because a piece of debris hit a solar panel. It's also not as simple as just treating it as a single part when you're actually working on the code of the game, because you're still tied to the limitations of the game engine itself. I agree there has to be a fix, not a workaround, but it's not as easy as sprinkling some "if(offscreen) Donwobble()" code over your codebase.

there's a lot more than you think. most features have at least a basic implementation already in the current version. and mechanics that are available in the EA are not exactly that easy to port. Coding would have to start from scratch basically.

oh, cool, is there a timeframe by any chance?

Nice, Vaos is great for this kind of stuff. Matt Lowne is too, but he'll go over the process of building quickly, whereas Vaos really explains in depth. Once you get used to it and have a good ascent profile, you can get almost any SSTO to orbit easily. I guess the next step is landing it on laythe and returning to kerbin xD that was my greatest achievement in this game so far.

@Mutant87 do you have reaction wheels by any chance? multiple control pods? I suggest disabling all but one of them. I had a similar issue once on takeoff, where it turns out my reaction wheel was upside down, which caused the vessel to spin. It's just an idea, but it might help.

well, small update after trying to launch the station again with the correct docking ports in the right orientation. After launching the first part and stationing it in mun orbit, I launched the second part and targeted it. I didn't see the orbital line, but I figured it must've bugged out or something. I remembered that sometimes the game stored the orbit wrong, so I went into the file and put it back to "Orbiting". now I did see the line again, and the line went straight down to the munar surface, and without engines (since I already ditched those) that meant I would need to launch it over again. I wasted a few hours trying different quicksaves, and changing some stuff, but wasn't able to fix it I guess I'll have to build my station after a future patch, because this isn't working. I never even got to docking this time.

Even that alone is a complicated task, you never know when something with a gravitational pull comes along and slingshots you into a different orbit. but ideally, yes, that's how it should be. I actually kinda like the idea of a kerbal colony where mistakes are made, it's in the nature of the game that things go wrong. not constantly obviously, but occasionally kerbals gonna kerbal. that would be only possible when the allignment between the ship and the celestial bodies is the same. sometimes you need a bit more or less deltaV because you're landing in a crater or on a mountain. me neither, and from what I've seen, that's definitely something that's on the roadmap. I'm just curious how it's gonna be implemented.

what if your craft that isn't rendered is on a collision course with an asteroid or another craft? I like the effort you put into it, thanks for that, but I don't agree with the premise. There will be plenty of situations where you aren't rendering your craft, but you still need physics. for example supply routes for colonies, where docking occurs often off screen.

I'll do some more testing specifically around this later as well and keep my saves and crafts. It might be worth looking into how docking ports are used on assemblies as well, because it's difficult to tell how they should be oriented, especially if you're new to them. In the first case I put them correctly, because I used the normal clamp o tron's before. But now I also have a space station around the mun that's basically useless because the large docking port is on backwards xD