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.

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.

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.

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?

Bingo. Thank you.

Please note, the texture for kerbin is currently incorrect. It is, for some reason, using the 'earth' texture, that RSS itself uses. I am not sure if this is intentional; I presume when creating the DDS files, this snuck through? I have tried removing the entire install, and re-applying the latest version. edit: however, if the intention is to change kerbin to be earth, but leave all the remaining planets and moons as per stock names, can you please update the changelog to reflect this.

Not 100% certain, but think the memory leak is back, enabling the editor leaks at a pretty constant rate of 3-4mb / sec. I'm able to exhaust beyond ~3.6Gb and crash KSP in less than a couple minutes of enabling editing. Also, I removed Kerbal Construction Time and the lag disappeared, so this may have been a culprit.

Good point. Interesting is one way to put it; low part count (dozens, not hundreds) and I had quite bad lag, stutter until I selected another part. Moving the camera created multi-second delays as the view refreshed. I also had to wait several seconds, stretching out to 15 seconds at times, when attempting to select another part in the part list before it would release the editor. As soon as the editor released it was fine. It felt like the part was updating every tick until I reset focus on something else. So it's highly plausible something else is interacting/ updating whilst editor is active; I am not sure, however that there are many other mods that would interact with the parts, beyond FAR. I can attempt a process-of-elimination by shifting mods out in sequence to narrow cause, if of benefit. Mod list here: http://pastebin.com/jM85zSzj

Fantastic, started a Buran build yesterday, and these were the features I missed the most; not having a thicker wing root potential. Buran is 5.5m wide, thus the wings disappeared a bit and I lamented not having a thicker chord. You seem to have solved that conundrum. At present the maximum dimension (width of root/ tip) is 16 meters. Is this likely to be the limit going forward, or are you considering increasing potential span? Right now there is (considerable) lag when modifying properties, but I prefer that to constant OOM crashing, editor takes a bit to get used to, but I think it's probably the least offensive option you could have chosen, given what appears to be a moderate degree of memory leak in the current release of KSP and Unity version used.

I see Gregrox misquoted me to make a point. Great. The thing is, I think the revamp is fantastic. He made me sound like an ungrateful arse. So, thanks for that. Whether or not the 'poodle' name is silly or not, doesn't change the fact that that is the name people are familiar with; yes we can change it. And we can re-add the gimbal back to the mainsail as well. I can do all manner of things to parts to change them around. Crank open the file, type-type oh look problem solved. Except that's actually the answer to a different question. Just because I can, however, doesn't either mean I should, nor does it invalidate a view point. It does, however, create decision points; do I hack a file to revert behaviour? Is that in the spirit of the mod, or the stock aspect of the part? How do I justify this to a bunch of people watching? Am I going to want to keep re-hacking files every time I update? What happens if nearly every part might need to be reverted in some fashion to match stock? So whilst "just edit the file" might be a valid response; it doesn't scale, raises mod versus stock questions - and isn't really a long term solution as the mod progresses. I didn't really have an issues with the poodle rename (whether or not it's a silly name, isn't in question. It's silly. But so is half of kerbal); it was only as the the new poodle joined the part list, that the confusion really kicked in. So perhaps some thought into handling part name changes, for example careful consideration of reusing nomenclature, to reduce confusion is a possible future enhancement to request. And not having to repeat myself repeatedly about the repeated need to repeat that the service engine is the poodle, but the poodle is a nuke. That'd be pretty swell. Related: removal of the gimbal from the mainsail was sneaky and underhanded. Discovered that mid flight because I appear to have not read the small piece of text that said it had been removed. Well played. I really wanted to use this mod because the rework of the models is fantastic. And thank you for lining up ingress/ egress and ladders with angle snap; kudos for finding a look and feel that allows the revamp to 'fit' with a pretty broad part ecosystem. But as the revamp continues a lot of parts are seeing changes that really bare no resemblance to 'stock' equivalent. That's not a bad thing. Quite the contrary. However (there is always a but..) changes to core parts such as removing the gimbal from the mainsail (a nerf) attachment node to the aerospike (buff) are going to be divisive. So anyone wanting to replace parts for better models with a bit more logical thinking behind them, now also have to consider the tradeoff in core functionality changes. And either edit parts to replace stock behaviours, don't and accept the core changes, or simply remove the mod if it's too much change. This was the point I was trying to make (that the revamp will now be something that requires additional thought) before Gregrox went off on his caps-lock adventure. Looking forward to where this mod goes, for sure.

These wings are brilliant; cautiously optimistic memory issues are fixed now, they were pretty bad. Is it too forward of me, as to inquire what priority you are placing on heat shield support, or rather, mechanics to work with Deadly Re-Entry, bac9?

Is it me, or does the batch file disable/ remove the (blue) stack separators?

That sounds like a survey mission. Doesn't matter who you take - it's simply the location name, "Bill's Ascent". There are many many more contracts now, including many more contract types. If you look in Mission Control you should be able to see location markers. I won't spoil what may be offered to you going forward.

Actually in 0.25 if you performed a contract that exceeds another's goals (e.g. a higher altitude before a lower) and did not select it, it always disappeared then too. You only notice it now, perhaps, because of the enforced initial limit. tl;dr - always important to check contracts as you start various launches, or advantageous sequencing can be lost.

It is the onload event; it was enough force to break a strut and ram a SSRB into the pad, starting a chain reaction. Ship experienced 4G on physics load and accelerated to 125m/s; which are a bit above potential freefall. Launch clamps with a vehicle suspended will stop any sudden G causing part collision with the pad. I should imagine the above is some combination of weight and or part load interacting and causing the physics engine to believe there's a collision occurring (the debug log would have recorded activity even if the post flight log showed zero issue). This isn't a bug I don't think; so much as a consequence of the slightly random nature of the violence that occurs during physics load. We've all seen craft bounce slightly when switching to landed vehicles, for example. It's not a consistent thing. I may never see another pad explosion again. If nothing else, launch clamps now have an absolute and vital purpose; beyond any potential bugs.

No fuel remaining? Colonisation is go.

Awesome. Last thing - is there a way to externally signal the process to stop? I notice it doesn't react well to a simple 'kill' which should signal a clean shutdown request to the process. If I want to run this thing constantly, within 'screen' (so I can reconnect to the server console) then there's no easy way to politely ask it to shutdown (for example, to backup the universe and or update).

I've noticed some serious lag trying to select the runway and then a craft. Long enough that the game is in danger of crashing. Dev version. Is this expected?

Awesome. This will be very helpful. Have streamed once already; DMP is pretty impressive. Few bugs but a great deal of fun.