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