stevehead

New customers also expect a released game to be polished and be able to stand on its own without new features, and for obvious bugs to be fixed in a respectable amount of time. What happens when word gets around that what is supposed to be a "released game" has many noticeable bugs, and that the game develops a reputation for rushed content releases? Simple situation for us to ponder on: someone who has never played KSP before comes to you and asks "do you recommend this game for me?", what would be your response? My pre-release response would have been: "The game is still being developed, but is pretty stable and tons of fun. You should definitely get it if you have any interest in space." My post-release response: "The game is quite buggy, and there are numerous balancing issues with features that have been added since release. I would hold off for a while." It hurts me to say that last bit as I have invested so many hours into this game, but it's the truth for me.

pfj commented on Scott Manley's recent Youtube video on installing RSS + RO: "Currently RealismOverhaul is marked as depending upon RSS in the CKAN metadata, so installing RO will also grab RSS for you. I'm not sure that technically should be a hard dependency, and one could play RO with 6.4x kerbin or similar mods." That comment was made about 10 hrs ago. I'm confused though because Github shows that RSS was switched from a required to recommended mod in RO's netkan file on Github 26 days ago, and I honestly do not remember it being required when I installed RSS/RO not too long ago. Regardless, I think its good RO no longer depends on RSS since there are scales such as 10x Kerbin for which RO would work.

If the game was still in pre-release, then I would agree that their time would be better spent on focusing on the switch to Unity 5. But the game is now officially released, and that means their priority needs to be on the present state of the game, not the future. It could be a while before 1.1, so that means we have to put up with extremely annoying bugs until then. Any other good game out there will recognize these quality hindering issues and do what they can to quickly fix them. I'm getting tired of spending a lot of time designing something in the VAB only to find out I need to redesign it because of some random cubic octagonal struct exploding from overheating on the launchpad or having to revert my launches often because the launch clamps respawn in my rocket during ascent and causes it to explode, among many other issues. 1.0.x has been my worst playing experience due to bugs and performance issues ever since I started playing the game two years ago.

I'm definitely looking forward to 1.1. I just wished there was a 1.0.5 to address bugs that have been present for several versions now.

This has been happening to me since KSP 1.0.2 RO release, including today's latest version of Real Fuels: I was wondering if anyone else is having issues with saving subassemblies? I have to reconfigure the fuel types for all the tanks of a subassembly that I use; everything else is saved properly such as engine configuration, tank types (e.g. cryogenic), etc. It does this for both stock and procedural part tanks. I also tried saving a single tank manually configured through the UI as a subassembly with no luck thinking there might be a conflict with an engine. I thought it might have been a conflict with Tweakscale (heard it was buggy, only wanted it for IR), so I removed it and still the same problem. This problem does not affect saved crafts. Wanted to see if others were having this problem or is a known problem before submitting a proper issue. Craft File: https://www.dropbox.com/s/6xxce9vnvzl898g/Launcher%201%20Test.craft?dl=0 Subassembly File: https://www.dropbox.com/s/nsgw0vqbra6pzet/Fuzpret%201.craft?dl=0 The rocket is supposed to be similar to the Titan II. Mod parts for the above: NRAP test weight for the craft file, Proc Fairings and Parts with various textures (I have all listed on CKAN), KW Rocketry, AIES, Remote Tech.

To be honest, I wouldn't know how to perform such a calculation. Not only would inclination be a factor, but so would argument of periapsis. Then, I would assume, would involve a solution to Kepler's equation to find the time difference between true anomalies at the point you are in darkness the longest, and my old college calculus and diffy Qs knowledge is quite a bit rusty to attempt that much math. If the orbit is a little eccentric, I would just calculate for a circular orbit with the same periapsis; higher eccentricities, you can use the circular orbit as an upper limit for maximum darkness and judge accordingly. A low periapsis with a high eccentricity is going to whiz around the planet.

Ah, cool. Thanks for letting me know. Wouldn't want myself or someone else to attempt a config if it already exists.

Alright, I setup a Github repository for planet packs support: https://github.com/stevehead/ksp-KScale2PlanetPacks My release posts and info can be found at my original post for this: http://forum.kerbalspaceprogram.com/threads/125357#post2031390 I was having an issue with Trans-Keptunian, so the latest release doesn't include it. I haven't checked to see if it was an issue with it or with my own configs, may simply not support the latest Kopernicus or something. Will look into it.

Alright, I've been playing a fresh KScale2 install with minimal mods, and the problems I was having are no longer present. I unfortunately do not have the two installs that were causing problems (rage quit deletion). I don't know, I must have installed something that was conflicting in some way. I've been under a lot stress with RL things, so my troubleshooting abilities have not been exactly top notch lately, so I must have missed something obvious. I'll report on any further issues if I come across any. I haven't played those solar system modifications, so I had no original intentions to add a config for them. As Kopernicus becomes more popular and stable, and people make more configs for custom planets and such, it will become progressively more difficult to keep up with them all, even with just the popular ones. I chose to do OPM and Trans-Keptunian because I feel those two planet packs bring an experience most comparable to our real solar system but still have that stock feeling. Unfortunately, I just do not have the time to consider making new configs for other planet packs at this time; I barely have time to play in addition to maintaining/improving my two plugin-based mods and I still have some work to do with the OPM/Trans-Keptunian configs (Paul released an updated version of KScale2 that I have yet to make adjustments on my configs for). As for a generic update script you mentioned, like Streetwind mentioned, its often not as simple. The code snippet you have is very much what I have for most of the planets/moons, but there are exceptions since the planet packs need to work together differently in certain places. For example, Paul's original config for Eeloo simply doubles the radius and SMA, but OPM does additional things such as moving Eeloo to be a moon of Sarnus, so there was a conflict I had to resolve (and I admit that my solution probably was not the best for future-proofing since it involves a change to the original KScale2 config, I plan to resolve this). Another example is Trans-Keptunian adjusts its planets to work with OPM, so I had to account for that. If the planet pack simply adds planets and nothing else, the general snippet you provided would work most of the time, you would just have to apply it to each planet. An overlooked problem I quickly found is making sure the planet is of the right mass. If only the mass is provided in the original pack's config, you will need to quadruple the mass to maintain the same surface gravity (g = G * M / r^2); if only the surface gravity (geeASL) is provided, you don't need to do anything; if both mass and surface gravity values are provided, the mass value needs to be deleted like you have in your snippet. I was hoping KScale2's Github repository would be updated to the release so I could fork and do a pull request with my configs, but I may just create my own repo that would install as a separate config pack. If anyone wants to add support to these other planetary packs, once I get it setup, you're more than welcome to help contribute.

The new heating system being all buggy... spending an hour and a half designing a lander for the Mun just to have parts randomly explode from overheating on the launch pad before I even launch. Gets pretty discouraging after a while.

Hmmm... okay. Weird, I've been using a clean install from Steam: I deleted my Steam KSP install when 1.0.4 was released, re-installed through Steam, then ZIP'd that directory up and been using that for my various installations. Also, sandbox on normal settings like you. I'll try again when I get a chance. It may be tomorrow before I can try it out.

Yeah, some of the parts could use a little tweaking with the heat system changes. The nose cone during ascent begins to rapidly overheat as I approach orbital velocity in the upper atmosphere (50-70 km range)... found myself having to burn radially out some to face the nose cone out of the air stream.

I've been messing around a little with NathanKell's info. Below are some values that seemed to work decently so far (was able to survive an interplanetary reentry going almost ~5.7 km/s at atmospheric entry, ablator ran out and heat shield was getting close to overheating, but it worked). @PHYSICSGLOBALS:FOR[KScale2] { // Turbulent convection @turbulentConvectionEnd = 250 @turbulentConvectionMult = 81.25 // Newtonian Convection @newtonianConvectionFactorBase = 6.355 @newtonianConvectionFactorTotal = 3.25 // Hypersonic Convection @convectionFactor = 4.775 @machTemperatureScalar = 17.625 } The values are arbitrary. I basically set the values to be about 3/4 distance between stock and RO values; 1/2 distance, i.e. the average, may work well with 64k. I'm no expert in thermodynamics/aerodynamics, so I wouldn't know if the values scaled linearly or what based on solar system scale size. It may need adjustment, but so far the game seems more playable for me. Stuff not protected with a heat shield do overheat as expected during reentry. Tried doing a rocket launch doing a typical ascent, and no random overheating there. I don't do planes much, so that is one area I have not tested. Edit: I should note that I am using FAR with this setup.

Ah cool. Thanks! I'll give that a shot. Been taking a mini-hiatus from KSP doing some Terraria playing. Been on the fence about doing 64k or KScale2 playthrough (I just cannot do stock scale ). Either way, that information should prove to be useful.

There's a setting in the game menu to use either Kerbin time (6 hour days) or real Earth time (24 hour days) for the in-game time display. Most mods that use times, such as Kerbal Alarm Clock, respect the setting and will display their times accordingly.

If I have time today, I'll give it a shot and hyperedit in some vessels for testing interplanetary.

After testing 1.0.4 with some mods, I've decided to stick with 1.0.2 for now. The heat/aero changes are causing issues with reentry on 2x solar system (KScale2) for me at least. I also have a RSS install that, as of this time, many of the mods haven't been updated... most importantly RO hasn't been updated.

Well, I wanted to give Squad's stock aero a chance, despite using FAR religiously pre-1.0. It was one of those rage quit moments for me last night. Seems like ever since 1.0 was released, I'm always finding some game breaking bug with either stock or some core mod for the selection of mods I'm using with a particular install that forces me to quit that save and try a different selection of mods or hope the next release of KSP fixes said bugs and not introduce new annoying bugs. I'll try FAR out later today when I get a chance. I just want to sit down, play the game, and have fun, which has unfortunately been something lacking for me lately. Edit: Just tried FAR with just the stock solar system (no Kopernicus of any type). Still having the phys. warp issue during reentry, that and that parts are apparently heating too quickly under phys. warp for some people indicates a stock issue for me there. Without any phys. warp, FAR on stock used up about 50 units of ablator for a 600km x 30km reentry. Going to try the same with KScale2 + FAR in a bit. Edit 2: FAR + KScale2. Better than stock aero + KScale2, but tried both 70x30 and 70x40 reentries and ended up with about 30 units of ablator remaining of 200. Edit 3: FAR + KScale2 + MM Config to double ablator. Of the 400 ablator, I end with only 35 remaining. So doubling my ablator amount causes me to burn through 170 more units... I'm assuming its because it increases the mass of the part? Doesn't seem right that it would eat up that much ablator. Conclusion: Physics warp is broken, for me at least, when doing it during reentry. FAR helps a little with a reentry in KScale2, but not by much. Still uses about 120 units more of ablator to reenter compared to stock scale. Doubling the ablator amount causes the ablator resource to deplete faster, almost doubling the amount shed off during reentry.

Just FYI for anyone installing on 1.0.4, I've noticed reentry eats through my ablator resource quickly: for a 30km periapsis from a 72km Kerbin orbit, I was down to 50% ablator at 50km and ran out before splashdown, luckily I had reached max temperature and was cooling off before anything could overheat. A MM config below might be useful for anyone having this problem: @PART [*]:HAS[@RESOURCE[Ablator]] { @RESOURCE[Ablator] { @amount *= 2 @maxAmount *= 2 } } The amount may need some adjustment, I just arbitrarily picked 2. Edit: Observation 1: I noticed that phys warp causes the ablator to run out very rapidly early during reentry, basically in just a matter of 30 seconds or so. Obvervation 2: I tried doubling the ablator above in my save (had to go into my save file and manually double the amounts for my vessels already in orbit). The attempt without any phys warp, the ablator ran out even sooner before doubling the ablator amount (went through 400 ablator by the time I got to 30 km). Grrrrr, I don't know . I don't know if it is some mod conflict (not using DRE) or if it's some stock bug. Thought it might originally have been the fact that I was having a longer reentry with the double scale. I think I'm gonna go back to 1.0.2.

I think the following is what I need to add to the above: .Where(v => v.orbit.closestEncounterLevel == Orbit.EncounterSolutionLevel.NONE) If anyone can confirm this is the appropriate solution, please let me know. Thanks!

I've been writing a plugin that filters out vessels that meet certain criteria. The current code I have is below: FlightGlobals.Vessels.Where(v => v.vesselType == VesselType.Debris) .Where(v => v.orbit.eccentricity < 1.0) .Where(v => v.mainBody.atmosphere) .Where(v => v.orbit.PeA < v.mainBody.atmosphereDepth) .ToList(); Obviously, those with hyperbolic trajectories are already excluded, but I also need to exclude those that have an upcoming SOI transition of any type (e.g. Kerbin -> Mun encounter). Anyone with suggestions on the best way to do this? I see the Orbit class has several attributes that seem relevant to how I would achieve this: activePatch, closestEncounterBody, closestEncounterLevel, closestEncounterPatch, nextPatch, patchEndTransition, patchStartTransition, previousPatch, timeToTransition1, timeToTransition2. I'm just not sure what would be best. Thanks in advanced!

Most people recognize that bugs will be always be present, and whenever you fix something or introduce a new feature, you are likely to create a new set of bugs. It's the nature of software development. But what many of us are complaining about is the fact that there are annoying bugs that have been present for several releases that still have not been fixed, and the fact that new bugs have been introduced because of rushing releases and an apparent lack of general quality assurance/testing. The temperature gauge memory leak, the trailing launch clamps post-launch, the save-breaking heat shields of 1.0.3, and the NullRef log spam with the parachutes in 1.0.4 are all examples issues that should have been easily detected if they had tested the game properly before their respective releases. When I was last working as a web applications developer, my boss would have fired me if I had consistent bug-ridden code like KSP does; now granted I was writing web services for multi-million dollar e-commerce sites in which my code handled pricing and payment transactions, so a screw up by me could have cost that company a lot of money, so I had that type of pressure to test my stuff thoroughly.

Hate to be blunt with a game I love, but when I fire up the latest version (1.0.4), freshly installed without a single mod, and get bombarded with NullRefs in the log (aka. the parachute bug) suggests that Squad doesn't care enough to deliver a quality product anymore. The obvious bugs that slip by their supposed QA/testing into releases are what annoys me the most, that and how we still have an early-access game despite being labeled as a completed product... the game still has several major releases to go before it even stands a chance to be "release worthy".

For the OP, I think there really is no need for a circularize orbit button or whatever. Unless you have something with very low thrust, its easy enough to just point prograde and circularize without the need for a maneuver node. If you need precision and you're off, usually some radial trimming can easily fix your orbit afterwards. As for Precise Node, I personally use it, but I do not think stock needs something as feature rich as it. The GUI for stock maneuver nodes does need some desperate work though; it is often too busy where the nodes are placed on the orbits and it is so easy to misclick and screw up all the work you had put in to fiddle with the node. I think a popup window with only sliders to adjust the maneuver along the 3 axes, a button to add or remove one orbital period, and delete the node would suffice (and maybe a display for your ejection angle as regex suggested).

Kopernicus has come a long way during its development. Sure, it still has some issues to iron out such as those with the auto-complete contracts in career, but it's far from unstable. I've been using some sort of Kopernicus config in all of my playthroughs in 1.0.x KSP so far (OPM standalone, RSS, KScale2 + OPM + Trans-Keptunian) and have not had any issues in sandbox/science modes except one that was quickly fixed due to a small typo in the code. As long as Kopernicus becomes more and more stable, I honestly do not really see a need for a new stock planet. True, it would be nice to have, but I am satisfied with using OPM for the foreseeable future.