Wallygator

Exactly.

Buy on Mac, get hdmi cable, turn down graphics settings or buy cooling base, use charger.

That is the coolest thing I've seen in awhile! only thing better than that rover is the sheer joy you express when it deploys well done, very well done indeed!!!

Considering the OPer indicated that 2 computers were available, then the only logical answer is to run both builds simultaneously! Badum tish! seriously though, why is this a question? Run the build that was built for the machine in question. Regardless of memory.

Wonderful... just wonderful! Bookmarked!

However, the topic is valid, as a more up-to-date demo is always a good thing. Especially as 1.2 is on the horizon. This thread might be a good reminder for our dev team to consider it - or at least feed back on their thoughts regarding when and what regarding an update to the demo. Not sure a lock is appropriate, but if it happens... whatever...

Its also very nice that KSP runs on a wide range of CPU and graphics platforms. NMS not so much. Procedural elements might be a nice addition but nothing critical to add at the moment. I'll keep my Kerbals for now... running just fine on their OSX operating system and their little intel graphics chipset.

Very Nice, and well done!

This is still a valid question and should not be considered a necro. As it stands, there is likely no point to Kerbal stats. However, we have yet to see any plans or architecture relating to stats that would make me change my mind - not to say there are none

Condolences to Mrs. Kerman.

I've tried everything sensible to get a fuel cell in RO to operate. Regardless how it is attached a LH2 LO tank (tried various tank types), my command pod electric runs to zero, the fuel cell electric runs to zero and the LO LH2 tanks just sit there - and no electric generation occurs. Can anyone provide a step by step procedure to utilise a fuel cell in RO that works? Any help is much appreciated - I'm scratching my head in frustration.

And you can make the command pod (that's on its side) hop around in its own by cycling decent mode on and off. Untill the battery runs out that is. Wondering what can be done with that on Deimos. It was in utility.cfg and another .cfg file as well. Can't remember the second one at the moment as I am away from my non-handheld computer. After deleting all port references in both files I'm now back to the standard RO docking port models and the remaining revamp parts. Perfect! Thanks again!!

Excellent. I shall give it a try. Much appreciated! Thank you! Isn't the offset required for descent mode to operate properly?

Thank you. May I ask how you did that?

OK so i tested VSR against a stock KSP install and I see the same texture issues. In a stock install the textures appear very very dark grey - in my RO install they appear completely black. I played with the legacy shader settings and the graphics settings but it makes no difference either way. Are there any OSX players out there seeing the same thing? Windows? Am I the only one?

Thanks anyway. At least you made an attempt! I appreciate that. Now... Anyone else?

Yes, but these are not the textures I seek Seriously, I have my graphics setting on maximum across the board but that should have nothing to do with only the docking port textures looking like crap. Many other thoughts?

Anyone seen this behaviour? Only the docking ports appear black and without texture (two examples shown at high noon) The lights on the ports work fine, and the ports appear to function properly - they're just missing texture in the flight screen. And this seems to apply ONLY the the docking ports OSX here - install via CKAN with RO, etc. I suppose I should try it on a base ksp install. Maybe later after work.

Seems to me we are talking cross-purposes on this (and apologies as now this is diverting away from the original poster's question (back to that in a minute...) 1) I get everything you say above and have no reason to disagree - facts are facts - assuming they are. 2) My personal opinion is that the user functionality and display approach (in the VAB/SPH) for the KER UI (not the computational engine) might benefit from further design thought - or user configurability similar (but obviously not the same) to the flight and map interface. Additionally, if the KER engine has to make so many assumptions, then perhaps the user could be allowed to input certain specifics about the vehicle being designed in a manner (via structured input) so that the KER engine might better calculate the performance --> Give the user more control if possible. Also, I;m not convinced it requires more "Columns", but definitely an efficient information display approach. 3) These are my early morning pre-coffee thoughts - not requirements. ;-) Now back to @MickB's initial post... and the very very sad news that there is no escaping it (or Kerbin for that matter), a poodle is basically just an air circulator at sea level. Sorry. If there was ever a truer moment for the "MOAR boosters" meme it's now.

except that the real plume config is still not correct... ;-) But that is another story.

I love you. Even if my icon face doesn't mean it.

Fair enough. It just means (to me) that the UI for KER could sustain a bit more structured use case analysis. EDIT: Regardless... it works for me, maybe not so much for others.

FIXED! With the seconds ago update to Vens Stock Revamp Thank you @NathanKell QUESTION: So what changed specifically on the AJ10-137 config? just out of curiosity..

it would be nice if there were an additional column or two in the KER display such that you would not have to click that atmo button (or so that button would not have to exist).

if you can get the CKAN screen up and running there is selection to specify the exact directory where your ksp installation is located. First diagnostic step would be to verify that value is set correctly. I've had similar issues and it was because I had multiple installs and my CKAN settings were not consistent - it was my own user issue (AKA fault).