Sandworm

Yes and no. Much of the stuff is standard, but you don't need to be an insider or even a mod developer to see the telltale signs that this isn't normal. Squad is a very strange company. They do not operate as other developers. They do not generate the same material that one would expect from a small developer. That, and little inconsistencies in public statements and/or actions point to a very closed shop dominated by a small group. This isn't the complaint of a customer, this is an observation of someone who works in compliance as a profession and is seeing red flags. That doesn't mean they don't make a fun game. They do. I'm just not sure I would like to be much more engaged with them beyond being a customer.

It's been a long time since I've looked at the in-game achievements, but they are all there in the save files. I'd go the simple route. A save that notes "mun orbit achieved" gets an extra xxx$/month. But the amounts should be achievement-specific so as to allow balanced progression. Ideally, I see a user-editable file with a list of achievements and corresponding funding rewards. That would allow the community to generate custom profiles for alternatively-sized systems (64k/rss) or for those with new planets (opm).

Imho reputation is ok, but I'd rather see bumps in funding tied to the in-game achievement. Reach space, achieve orbit, land on minmus ... each would reward the player with extra monthly cash. This could allow for progression/balance while totally ignoring outside of contracts.

Looking at the 64k cfg, it appears to simply scale all distances between bodies by 6.4x, the size of bodies also by 6.4 and atmospheres by 1.3. No moon or body-specific changes.

It didn't last week. It does now. The cfg for 64k is now only 21 lines and an opm patch is unnecessary. Version 1.2.0.0 for Kerbal Space Program 1.1.2 Released on 2016-05-01 Updated for KSP 1.1.x Now uses Sigma Dimensions to rescale

I thought I would share something amazing. OPM seems to automagically integrate with 64k. Just dropping the unmodified OPM directory in alongside 64k results in all the new planets scaling neatly. I haven't done much playtesting, but no doubt those behind Kopernicus and Sigma Dimensions are doing good things.

Small thing: The cfg for the MSL-1000 puts it in the "electronics" node, but I'm thinking that "electrics" is more likely?

I just tried this for the first time in 64k and it's working seamlessly. It's the little things that make all the difference, like seeing that tiny green thing and knowing it's actually Jool 500,000,000,000m away. Those behind this mod really show how much Squad needs to up it's game.

Try installing the latest version of Kopernicus, not the one that comes with 64k.

I've been doing some early-game experiments around kerbin without issue. The universal storage versions also seem fine.

I just downloaded v 3.2.5. Spacedock said it was 1.1.2 compatible but the EditorExtensionsRedux.version reads that it's meant for KSP1.1.1 (KSP_VERSION_MAX). It works, but I am getting a notice.

Fyi. It seems to work well enough under the latest version of texturereplacer. I'm testing a KSPCR + 64k game and the only issue I'm seeing is with rocket plumes, which is an easy fix (delete the relevant textures). The navball remains stock, but that isn't a gameplay issue imho. Here's a pic just to prove that the skybox is there:

Fyi, KSP 1.1.2 Linux + 64k + Latest ModuleManager + Latest Kopernicus + the heatshield tweeks I shared previously = All working.

No. It means that any changes to flight characteristics of craft moved between 1.0.5 and 1.1.1/2 are probably the result of something other than far. Squad could have made changes to clipping rules/bugs. New phantom forces might exist ... or any number of controller/UI errors might cause instability, all of which have little to do with FAR.

If you look a few posts back, I posted a link with a temp fix for this heating bug. It's been with Kopernicus/64k for a long while. https://www.dropbox.com/s/ll4660khksuo29z/64k_Temp_Fixes_for_KSP1.1.rar?dl=0

92km.

Wales is like hawaii compared to this: http://www.newfoundlandlabrador.com/ I've been to Newfoundland. The colours on that girl don't exist there.

All notebooks run hot virtually all the time. None have "adequate" cooling for continuous high load. They are designed under the assumption that loads will be intermittent, with the thermal mass of the cooling system acting as a buffer. The only time they ever cool down is when the CPU is shut down to save power. That isn't ever going to happen while playing KSP. Now that KSP is accessing more cores, laptops that previously were ok will start to cook. But as other have said, the CPU will protect itself. Be more worried about the batteries catching fire. Frankly, laptops aren't meant for games. It's like trying to streetrace a Jeep. Sure, some fancy garage may be selling "racing" Jeeps but the form factor a very tricky place from which to start.

Will do, once I see another crash. But I have to work today and so cannot play KSP. For now, I can say it was 64-bit ubuntu 12.04 LTS. -Sandworm

I like the parts, but am totally confused about docking. I've docked the Tantares probe/drogue pair easily. They just work. Now I'm trying with the larger pair and cannot get anywhere. Extand, retract, backoff and try again ... I'm just bumping parts. Are these meant to dock with each other? If not, is there a list somewhere showing exactly which go with which? If I am wrong about these two, there is no clear instruction in-game. TDP-MD-350 "Ficcare" Docking Probe + TDD-MD-350 "Imbuto" Docking Drogue **** Edit, might this be the problem. The CFGs for these two parts list them both as "genderFemale= true" Mistake? " title = TDP-M0-350 “Ficcare” Docking Probe [...] { name = ModuleDockingNode referenceAttachNode = top animCaptureOff = false gendered = true genderFemale = true nodeType = size1 } title = TDD-M0-350 “Imbuto” Docking Drogue [...] MODULE { name = ModuleDockingNode referenceAttachNode = top gendered = true genderFemale = true nodeType = size1 } ***** Update 2. I changed the Ficcare to "genderFemale = false" and the parts docked. That fixed the problem on my end. Has anyone else faced this?

I haven;t tried 10x but the version of 64k meant for 1.0.5 is working for me.

(1) A new version of TextureRrplacer for 1.1 is out. Ignore the thread title. Check the github page. (2) KSPRC looks great under 1.1, but a couple things obviously are borked. Visors reflections just aren't there. Not a big issue imho. But I just did a night launch and the smoke/plume textures aren't rendering. It looks like the rocket is climbing up a big pile of confetti. Deleting the various smoke/plume textures from KSPRC solves the issue.

I'm seeing something similar. Random crashes usually when deleting a part. No errors in any logs. The only reason I suspect EER is that it only occurs in the VAB when touching parts. removing EER seems to fix the issue, but I cannot be sure without more testing.

1.0.1 is already out, as of a couple hours ago. fyi. https://github.com/Kopernicus/Kopernicus/releases/tag/release-1-0-1

Ah. OK. I hadn't seen that. Anyway, the files are there if anyone needs them. -Sandworm