kofeyh

Aww jeah. Top effort brosif. Having just experienced colliding with clamps for the eleventieth time again yesterday, this humble idiot thanks you.

Youen, you're not permitted to distribute the individual unity files. So your link might get removed by a mod.

Sorry, but no, it's a universal bug. Just because you do not see an event, doesn't mean the event doesn't occur. It Does. I have had the FASA launch clamps spawn mid flight. I have both seen them spawn, as well as collided with. Having said that, it's not a reason to pull the clamps, as it seems to occur to any, including stock. Which suggests it's either core code, or another mod.

Sorry? PS4 updates games pretty much as steam does. Either in the background, if it's asleep (or running) and will automatically update if you attempt to run a title if it has been completely powered off. The argument that updates have to be tightened up for console, is silly. It's based on assumption. The only negative for a rapid update cycle is the impact on a mod community that will sometimes have to recompile mod code, even if KSP had a 2 line fix applied in source requiring absolutely no changes in mod code. This is "better update cycle, because they are all different" argument redundant on any platform, however, that doesn't support third party addons; in any case the argument that fixing issues in rapid succession is automatically somehow bad, is flawed. Rather it is the knock on effect that is likely more relevant to people, either mod's or game-save impact. The only issue I have is the notion that "only update if you experience the bug" is an unfortunate choice of phrasing. No the new version should be used because that is now the current release, that people will expect mod's to run on. Optional updates should die in a fire. Either release an update and everyone (that can) shifts to it, because it addresses a critical issue (which this does?) or save for additional fixes in the pipeline.

That will come later. People forget that KSP isn't currently owned by everyone who will ever own it. Equally one should expect responses from established reviewers who may have spent just a few hours in the game. To me, that is equally important. Because it will capture not only (to be fair) partly biased articles that are clouded to some degree by nostalgia, but a gamer's first experiences and how they translate from being entirely unaware of how the Kerbal's work, to having some kind of success. Not everyone that may play KSP tomorrow, has the game in their collection, today. As for the reviewer's penchant for using Minecraft as a comparison; it's entirely different yes, however some core mechanics are similar, in that it's a form of lego-like construction and exploration. - - - Updated - - - It's a result. A metric. Made up. From arbitrary values. Be it a percentage, a number, a fraction or a picture of three people holding up signs. Looking for logic, in the illogical, expecting statistically relevant data from a single persons review, is a fairly pointless exercise. However, the human race, as a whole, seems a bit pre-occupied and indeed is entirely geared to 'put things in boxes'. So they can define, quantify and most importantly 'rate' or 'value' something. Because that is how we are taught to look at the world. Ironically this box preoccupation has little to do with science and logic. Thus, a number is invented, in order to quantify. Whether it's scientifically valid, is almost never a consideration. People generally don't care. Something that gets ninety percent or so, must be good, right? I doubt you'll find many will question much beyond that.

Yay. This is a consequence of everyone in the history of ever constantly repeating "just fly to 10k and turn 45º and she'll be right". NOPEH. There is an entire generation of KSP players who launch rockets in a manner that has zero relevance to actual flight and have very bad habits. This really wasn't covered overly well in the release. Sadly. But - Aero absolutely now acts more like the real-deal. It isn't the real deal however or you'd find it much more challenging. But, much like an actual rocket launch, the ascent is best handled by ensuring you have a positive ascent rate once clear of the pad, and slowly banking in the desired orbital direction in ~5º (degree) increments. Anything more than about 10º (degrees) of attack angle (i.e. you stand on the controls to do that ridiculous 45% turn in space at 10km) then you'll have a bad day. Folks will have habits that may need to be relearned. But at least the game now follows a more logical pattern in that respect. Good luck!

This is why I like you and your mod. Neither wish to cause my machine to cry itself into a memory leaking stupor.

This is really the thing I am most interested in. Fixes. Sadly it's also the least discussed part of any update, outside of HarvesteR occasionally expanding on a topic. Yes it might sound dull, in some ways it is dull. It's also equally exciting, rather critical and is also the single biggest factor (having the most direct impact) on my enjoyment of KSP. There is a mod for almost anything. But fixing core issues? There's only so much that can be done. Aerodynamics and engine changes are great. As are other features. Some quite welcome and arguably well overdue. And that's awesome. Really awesome. But at this point? Honestly? It's all about the fixes.

Yeah, however the mod initially touted being pretty low-friction due to reusing textures. Those days are long gone I think. And yes, the stock parts are already removed. But in an RSS 6.4 install, with DRE, FAR and what not, every little bit helps.

Ore. Yes, that will work fine. I was concerned it might gain some awkward non-relevant name that has no reference to anything actually existing (leading to mass confusion when speaking of game mechanics to people whom have yet to obtain KSP, for example). Never mind the translation issues. Ore is a generic term, used to described "unrefined solid material". This doesn't mean the valuable constituents have to actually be a solid. Mercury, for example is extracted from a source ore, which vaporises under heat, and is cooled (condensed) to become a liquid metal (queue Terminators theme). All sorts of complex molecules, some of which quite like to burn can become trapped within rock and ore. The concept that you could mine ore, crush and extract valuable propellants or materials to form propellent certainly isn't a new one. At least two or three mars missions (including from NASA) are based on the concept of using raw materials located in-situ to make propellant. Not sure they're pounding on rocks; but extracting valuable resources from solid ore is certainly very well established and has been for eons, just considering our own history. The biggest advantage, is that Ore can contain such a wide array of components. It's non-specific meaning the source 'ore' could be used for mods to extract just about anything you could think of. So it's actually quite a sensible choice. I sense RoverDude's rather logical hand in the naming process, just quietly.

Is it fair to say that the Revamp is now using quite a few new textures and not just re-using stock? I am at the point where memory consumption is a driving factor in continuing to use (what are admittedly gorgeous) revamped parts. I was about to update again but I think I'm at the crossroads where this is not longer a stock revamp - it's a full replacement and extension. I am already on an aggressive pruning expedition to reduce the stupid amount of memory KSP needs to function with an expanded part count. The new engines look fantastic, but don't look to use the existing textures (which are admittedly generic and dirty) at all. Adding dozens of new parts is going to break my install.

Possibly? It's such a vague statement it's hard to know what it means. I'm hopeful that it improves things. It's just not entirely clear how GC is being improved. So it reads more like little tweaks to reduce CPU load. My point was I hope that doesn't mean virtual removal as there isn't a huge amount done now.

It's not so much "doing something silly with GC", it's that there is virtually no GC. Assuming the removal of collection from a game (that does not actively unload textures) is a good thing, isn't actually a good thing. This is a very bad thing unless it's being sorted out elsewhere. Because at present the game currently has some bad memory leaks; without improved memory management, I foresee that that behaviour might actually get worse. I think most people who encounter this in 0.90 would rather there WAS some degree of clean up. Try doing a number of scene changes and watch the memory usage. It's not.. optimal. - - - Updated - - - True. But it's one thing to reduce garbage collection when you are reasonably efficiently loading and unloading assets. It's a little different if there isn't a lot of optimisation; or, well, really any unloading to speak of. KSP just keeps on allocating memory until it hits the 32bit address limit and crashes. There's no consideration yet, as I understand it, to dynamically load or unload assets in-game. I'm not going misconstrue what Mu or HarvesteR have said, all the same. If loading and unloading is more efficient and is doing at least some clean-up - great. If they're just removing it to address 'stuttering', then that's a little different. Nothing is really being said about optimisation of the game and texture management beyond a further discussion about DDS formatted assets. Which suggests 1.0 certainly won't be unloading much of anything.

Cool. Good news on the SOI changes. Slowing down to a crawl to transition across orbit changes just to make sure you maybe actually pop out at the right place gets frustrating. This will also hopefully put to bed the long standing issue of blitzing through multiple orbit changes (for example a SOI change to a planet, that also includes it's moon and missing either one in some kind cosmic flyby joke). Not so hot on the reduction in garbage collection however; memory is something KSP is fast running low on. It's annoying but without clean up and now the reduction in scene changes - what does that do to overall memory use and release? Has any efficiency been sought to improve the release of memory? People seem to not want GC, but it's actually important to long term stability and the game's memory footprint.

You've heard of parallel development, yes? It's where multiple people with differing skill sets work on differing aspects. This is a good thing. Bleating about fixing in-game asset quality is pointless when there is a maximum ceiling of ~3.5GB of ram before Unity 32bit will crash. It has no method to cope memory access violations and will terminate. Lots of corrected and gorgeous graphics would be great. Apart from the engine not coping with the "load everything always" model of texture management and crapping itself. As it is, that ceiling is so close the developer is considering the stock use DDS texture formatting to actually cope with the (increased yet again) ridiculous numbers and amount of in-game of textures. This means 1.0 is likely to have a considerable footprint increase. Yes I'd like to see some better textures. So would most people. However such finesse usually occurs towards the end of the build cycle once the actual mechanics and frameworks are stable; right now core functionality is broken in some not-great ways; and the animation and graphics guys can't really do much about that, hey. Dan working on in-game assets is happening anyway. I believe he's involved with work on the female kerbal? So your constant requests for people to do your bidding is actually occurring. Just perhaps not on the things you personally "give a crap" about. By the way those things that mean "diddly squat" to you? - they help increase the source material available for prospective new players who are pondering the game. More people entering the community means more funding which means more likelihood that Squad will bother to continue development - for example do that texture work you want to have happen. So that? That's important for the longevity of KSP. edit: so many typos

So what happens if you just have the minimum mods installed; that is FAR and Procedural Parts? At this stage you have several mods loaded; this won't help debugging. KJR is a known source of nullrefs for various reasons (not to mention other odd behaviour). I would (as recommended earlier) literally strip back to absolute minimum.

Have you tried simply removing all mods, apart from bac9 wings an FAR? Remove every possible other cause and check then. Nothing special about the version you use?

Oh you get them alright, but at present the big one won't (generally) affect you unless you increase the games memory footprint (eg extend via mods). There is at least one (possibly two?) major memory leaks in KSP 0.90. Work with any tweakable part for any extended period of time and you can see the game's memory footprint grow at quite a considerable rate. There is also still a major decoupler bug that at certain speeds decouplers experience phantom forces. Nullref's also occur in stock. So there is a bit going on, even if you don't always see it. I will be quite keen to see if these long standing issues are resolved, more so that any of the added content. I honestly don't give a monkey's if the game is missing some features when it hits 1.0 - as long as it is stable then it'll gain far better reviews that something that has all the bells and whistles people seem to want for 1.0, but is an unstable mess.

The largest fairing base is 3.75m; given the way the fairings have been described, I'd anticipate a functional limit on the procedural portion, given it's not dynamic in the same sense that the mod is.

People are getting hung up on Unity 5.0 (a major revision) as being the holy grail for KSP, just as much as doom-saying 1.0 is "it". Both are inaccurate assumptive statements. Unity 5 introduces some new features, yes; however it's not going to "solve" anything. The game itself relies on loading everything always (which isn't scalable) and getting a stable version operational on 64 bit (on the Microsoft Windows platform) at all is clearly not going to be a "five minute hack" type effort, based on recent attempts. Lastly Squad would be setting itself up for financial suicide by stopping at version 1.0; it's still not quite there yet. But then a lot of AAA games ship at version 1.0 supposedly being complete and being nothing of the sort, indeed at time severely short on features compared to KSP. Not suggesting for a moment that I agree with the timing. Or that the game is "complete". But then "complete" is entirely subjective depending on who you ask; if they keep on just rolling out alphas and betas then eventually people are just going to argue it's been in development too long. I am not HarvesteR so what I think on the matter doesn't rate highly (nor should it, probably). It's very easy to arm-chair quarter-back the decisions into tin-foil-hat territory, frankly; which does a disservice and sidetracks genuine debate.

As I covered above, there is never a "good time". KSP has had a very (very) long alpha cycle, you could argue a number of the recent updates could easily have been listed as beta. Regardless, continuing that train of thought falls down to semantics; which isn't related to the topic. Which is apparently it's march and things happened at squad. Presumably if that keeps happening, we're going to see progress.

Developers have to pull the trigger at some point. No-one will ever agree when that "should" be. There is almost never, it seems, a "good time" to do so. Squad could iterate on the concept for another two years, easily. But at some point - if you want to release - the pin has to be pulled. Games that languish in development hell forever, seldom recover. History is replete with ample example.

The changes being incorporated for 1.0, are long overdue; and would be welcomed regardless of whether it was a major/ minor version. That and the work is stepping into areas that have been well trodden from a modification perspective. I would suggest if you're going to release a thing, it's logical it would be as feature complete as possible for the first 'gold' version. This is also quite probably the single longest development cycle i've seen in a long time; there is a massive percentage shift in how much is being tested, before it even hits experimental. So yes, there are a few changes, but it doesn't require sarcasm to comprehend that that (the massively extended development cycle) is actually a vast improvement over very fast, infrequent 'burst' development cycles that have occurred before, leading to some quite unstable builds.

Thank you. Just.. thank you. Job done. A bit sad that the fairing bases are fixed sizes (this is going to limit them considerably, for larger builds) but I suspect I understand the reasons. Leveraging the tweakable code to have a single base that can confirm to additional sizes may have been a different approach; I don't know if you considered that? I imagine, again, there were reasons. If I had a child (which is best not to contemplate) I'd probably name it after you (this is why it was best not to contemplate). This along with the aerodynamics changes resolves so many outstanding "...?" questions around why things do, or do not do. Thank you, sir.

Squad hasn't ever not been 'pretty set' to do as it sees fit. To quote regex - "dude, it's squad." Whilst input is sometimes sought, it's still their baby to grow as they see fit. Unity 5 has been delayed more often than the second coming of cthulhu; that and I cannot even begin to fathom why people are so dead-set that the 1.0 version should run on unity 5.0, which is almost certainly going to be a veritable bug fest; lets release the game to the world as gold, on a major engine version release. I'm sure that will end well. Better to give the engine a chance to stabilize first, sort out the loose ends, clean up longstanding bugs and memory issues, then commence to migrate code across when you know it's mostly 'done'. We've had quite enough game breaking bugs, so I am far more pleased that the focus has been to 'finish' a lot more of what was started, and a big bug cleanup done, than embracing a world of pain that 5.0 is almost certain to bring with it, early on.