Alshain

It would be hard to do with a webpage, I mean this forum is a webpage. I thought you were just talking about a tool to create patch config files or remove them with a user interface. Maybe I don't really understand what you are trying to do.

@Yemo There is no reason SETI-rebalance has to be the only one. Not everybody agrees on the standards by which the game should be balanced. There are plenty of 'competing' mods out there, so this would be no different. If linuxgurugamer things he can provide something that others will want, then he should go for it.

It's a neat idea, but I think as a mod would be unnecessary. There is no real need for it to be run in-game, you could do it as an application instead.

Well, I'd be happy to look at them but I'm not sure of what the numbers should actually be. It's more of a concept than anything. I just know you can't have balance without a standard for balancing. A lot of the time KSP part stats feel like they just selected numbers at random.

There is a patch in my MM thread (in signature) to fix it too. To me, crew parts seem simple. Come up with a mass per seating capacity and adjust all parts to match. Lander cans get a fixed % bonus reduction (to make them worthwhile, they aren't designed for re-entry after all) and crew cabins get a bigger % bonus reduction (they do need re-entry but have a lack of significant electronics). I do not understand why it is so difficult for Squad to figure that out. Seating capacity (and maybe heat tolerance) is really all the difference there is between them, so it should be easy to balance.

Fuel ammounts are stored in the craft. That way it knows if you customized the fuel level in the tank. That's not really what I consider part of the stats, though I suppose the max fuel is a stat. In general, things that can't be changed by the player aren't stored. For example, the tank's dry mass isn't in there. I don't know about the tanks, but I know of a lot of other parts that do need work... like the Mk1-2 Command which is probably the worst offender. It's better to use a Mk 3 cockpit on a rocket than that to use that silly command pod.

I don't think it is anything you can add, it doesn't exist. This is all stock suggestion for improving the part upgrade feature. @Gotmachine might be able to add it as part of his mod somehow though (if it doesn't already exist). But mods should not be required to fix a stock feature and therefore I still contend part upgrades should not be used on stock parts until Squad fixes and fleshes out the feature. This has kinda gotten off topic but it does relate back to a conversation about using part upgrades to balance the parts.

Correct and incorrect. It depends on what you call 'existing'. Parts in persistence (i.e. launched vessels) do not get changed. Saved craft and subassemblies do however and that is part of the problem.

The basic feeling is that until Squad improves the part upgrade feature, stock parts should not use it. It breaks craft sharing, challenges and such since you don't know which version of the part the craft was designed for. We are talking about a feature allowing you to 'turn off' upgrades like the mod he linked. Right now in stock you can't, once the tech is unlocked it's assigned to all new parts of that type automatically and permanently. However, if such an improvement were to be added in stock, there would also need to be a way to do so en-masse, based on what Tier the upgrade was unlocked, in order for part upgrades to be acceptable for stock use. That way, if I am attempting to build a set of generic Tier 5 lifters in sandbox, I don't have to right click every part and turn off the upgrades. Instead I can click a button that says "Limit to Tier 5 and below" and anything I grab will be in that targeted range.

That would be a step in the right direction to fixing the upgrades system to make it usable. However, there also needs to be a Tier limiter in there. Right now in stock (no upgrades) we can filter parts by tier, so if I'm in sandbox designing something to be used at a specific point in career, I can quickly pull parts from specific tier levels, but going through each part and disabling a bunch of things wouldn't be an acceptable solution. Instead of I would need a way to limit all upgrades to tier X and below without modifying each and every part.

Then they need to find a way to save the part stats into the craft file. They are saved in the persistence file, but they have to save them in the craft file and allow you to switch between upgraded and not upgraded and which upgrade level so they don't break craft sharing... or they could not do upgrades and just add them as separate parts. The upgrade system was a thing that seemed like a good idea, but really was not. That's probably why they didn't implement it in stock parts. But really, who cares about breaking existing craft. It's fun to build and redesign craft. They should just rebalance the parts outright, don't screw around with the upgrade junk. Not all instances, craft that have been launched have their stats saved in persistence (because that would be magic, suddenly upgrading a craft at Jool)

Fixed that for you.

Unity 5 does have GPU Accelerated physics on CUDA but it is very limited. Cloth rendering only AFAIK. So they could make the flag at KSC more realistic, but that's about it.

I'm with @Red Iron Crown on this one. Why add something that people will just install a mod to avoid using? They might as well not waste their time.

It wouldn't matter. If they make the 1.2.2 distribution at the same time as the 1.3 release, you just select that after they do. Worst case, it has to re-download a little but but this game isn't all that large to begin with. It won't hurt anything if it updates, Steam is smart enough to revert it, and it won't touch files that are not part of it's own installation (i.e. mods and saves).

If I am not mistaken, the Guidelines apply to all possible content on any Squad sponsored medium. An avatar is a means of communicating to others (it help communicate your digital identity) so it falls under the definition of rule 2.1 http://forum.kerbalspaceprogram.com/index.php?/guidelines/ FWIW: I'm not a moderator but I see nothing wrong with your avatar. (Though I feel like I've seen it before, and if it is used by a moderator/staff member you may have to change it, I'm not sure where I saw it though)

I think a better solution would be to offer the 'welding' option in a limited fashion as it would typically be in the real world. Having several fuel tanks as individual pieces to form one rocket with wobbly joints between them isn't realistic, having a space station composed of many components docked together is. I feel like anywhere there is a decoupler or docking port should be separated physics as well, but two fuel tanks stacked on one another can definitely be joined into a single rigid body. However, all of this is a bit off topic as this is a KSP design issue and not a Unity issue.

If you make your craft a single rigid body, it would drastically alter gameplay. There is no technical reason, true, but I wouldn't want to play that game. It would take away a lot of the design challenge. I think the VPP package they use change that though. I could be mistaken, I just thought I read that somewhere.

@Xavven Graphics Cards process visuals for display, but they do not add detail (except in the case of GPU accelerated physics, which afaik is limited to Nvidia, and doesn't do much). Elite dangerous uses single model physics. Again, your whole ship is one object. Each space station is one object. etc. It's not calculating the physics colliders that KSP asks of Unity. It only has to calculate when your ship hits something else, it doesn't have to calculate if your engine or cockpit is going to fall off the rest of the craft due to stresses. Also, KSP is older than Elite Dangerous. No, a small indie studio will not likely ever come out with a game that looks like a AAA game on their own. That isn't big news. However, that has nothing to do with the game's engine. Again, KSP uses Unity far above what it was designed to do. It wasn't designed to calculate orbits, but neither are most other game engines. These problems would likely exist on Source, Unreal, or Cry as much as they do on Unity. There is no other engine out there that would be better suited for all the tasks that KSP does. Some may be equivalent, but certainly not better. Comparing it with Forza is a another example of how KSP is pushing the envelope of what game engines are designed for. In Forza they can assume that only the bottom of the wheel will touch the ground. So only that part has the collider... the invisible thing that simulates contact, friction, etc. Your wheels in Forza are actually not wheels at all, they are flat surfaces with decorations that make them look as if they are wheels. In KSP we can turn wheels in all directions (there is no "bottom"), and that led to issues because the conventional wheel systems didn't work when the wheels were upside down. Once again, KSP is not your typical game. Forza and Elite Dangerous are both drastically more simplistic than KSP, that allows them to spend more efforts on other areas, like terrain and detail.

Depends on how you look at it. It's a limit on computing power due to the design of KSP. Most games treat a vehicle as a single piece, KSP handles physics on each individual component of a vehicle. The fact is KSP pushes the boundaries of what game engines are designed to do. As an example, a 100 part space station in KSP would be like having 100 cars on screen and physically interacting with each other in a game like GTA. No game engine ever made was designed with a KSP type game in mind.

It could probably be done if you don't need any more than about 5 parts per craft, and 10 parts total ever in physics range.

Then why were you commenting on our discussion about boomerangs? Also, the Boomerang is an American craft, or at least it was built by an American.

@Azimech That looks nothing like a boomerang.

You are mis-attributing design decisions of KSP as faults of Unity. KSP does not fully utilize the graphical capabilities of Unity and that is not Unity's fault. KSP could have visuals like that, but KSP has so much else going on and the intent of the game was always space, so most of the time you wouldn't be able to see that kind of detail. They made the choice not to invest heavily in terrain details when developing KSP. Unity itself is capable of quite a lot.

That's the list I guess. You may not need the really big ones, but you need at least the double wheel. Somewhere on the back, it's not super important as long as it isn't in the heat. I usually put them near the base of the engines. Nose cone is all you really have in stock. You don't need intakes for a standard shuttle, and a parachute would probably pull you around the wrong way there. The Vector is designed for it, but they are not the only option. (In fact they may be too powerful). Space shuttles can be quite difficult. The hardest parts are 1. Getting the engines balanced across the center of mass so it doesn't go tumbling on takeoff. 2. Getting the drag and mass balanced so it doesn't go tumbling on re-entry. Don't overbuild. One of the biggest mistakes people seem to make when designing an STS lookalike is using the large cargo bay, but that isn't proportionally sized to match the STS and will mess with your balance. Of course you don't have to build an STS lookalike either.