Wolf Baginski

I have been digging in this. It's very definitely browser-specific, and it's not a side effect of local scaling settings. The Thumbnails appear to be vertically enlarged and overlap. Mozilla Firefox works. Since I run Linux, I can't test any Microsoft products, but it appears to be Chrome/Chromium code that is messing up, and not every version of that engine. I don't have a way of adding images to my posts here which is compatible with my local security rules.

I am not sure if this is what brought around the changes I saw today, that can be summarised as an icon-only mod-listing display with no names. The problem is that some mods have good icons, which are part of their brand, and some very much don't. Not being able to see mod names at this level is, frankly, confusing. I wouldn't be surprised that downloading the mod-specific page for every mod to get that info is going to put a lot more load on the server. I suppose we can all make new icons which work with this wordless interface, but it is a long way from working. I saw two cases of images-with-useful-text being used with most of the text being cropped from the icon, and three uses of an anonymous, low-contrast, placeholder icon. Kerbal Space Program may be rocket science, but running a website isn't.

I have not tried this with 1.9.x versions of KSP, I have had a few distractions. But the Spacedock link still works. I think I shall wait for @-ctn- to do something, Would a visually-compatible fuel-tank extension for the MAV stage be worthwhile? You can bung in a 2.5m tank, but it looks wrong.

It's a pretty simple Module Manager .cfg file and the only trap in it is the very old version of Module Manager which is included. You do have to use the correct version of Module Manager for your KSP version. It duplicates the standard MechJebCore settings found in the usual MechJeb add-on part. There is a MM .cfg in the Parts sub-folder of recent MechJeb versions which duplicates the function, so you don't really need it, and the timing of the two versions is different so you end up making the same change twice, which just slows loading by a very little.

I wonder how the ratios look between the 1.0 level downloads and the current version, how many are "new" people, making payments and how many are upgrades. That's the sort of thing that a plain total-sales figure can hide, and KSP is different from many games in that it isn't a fixed end point. How many times can you play through Doom or Tomb Raider or Minesweeper? Maybe KSP is more akin to Flight Simulator. A quick check suggested one version had sales of a couple of million, but I didn't find any more than that. I would say that, yes, KSP is in a niche market, but it's not trivial.

Yep, Firespitter is a mod, mostly centred on aviation, with a .dll that a lot of other mods have used over the years. The last version I have is for KSP 1.7.x and the .dll in that is file-dated 2018. So I'd not go out of the sandbox with it in KSP1.8.1 The way these things work, if a mod has Firespitter as a dependency, and includes the .dll, you'll see a Firespitter sub-folder in Game Data, and if somebody hasn't done that they have been a very naughty modder. I don't know when a new Firespitter version will come out, and the aerodynamics problems in KSP1.8.0 will have delayed any release. This week has seen a bunch of widely-used mods see their first KSP1.8.x release, they're not aviation centred. We'll have to wait a bit longer, I think, if we're into the aviation side of things.

There are just so many slightly different translations of this, and it's not really limited to any religion, but that's from the norse hvamal Cattle die, And kinsmen die, And so must one die oneself. But there is one thing I know which never dies, And that is the fame of a dead man’s deeds. Works for Jeb, for every Kerbal, and for all the programmers and modders who have given us so much. The urge to travel is old and deep, but I am told I must stick to English. Thanne longen folk to goon on pilgrimages And palmeres for to seken straunge strondes To ferne halwes, kowthe in sondry londes; And specially from every shires ende Of Engelond, to Caunterbury they wende,

Deyr fé, deyja frændr, deyr sjalfr it sama, ek veit einn, at aldrei deyr: dómr um dauðan hvern.

I am going to stay in Sandbox mode, might try landing something on the Mun, but I don't feel I can trust launch/reentry until after the bugfixes. I am not sure why heat/drag changed, it's not all bad, but capsules come in hot and fast, and stock parachutes suddenly feel inadequate.

I've done tests, and parts from a lot of old mods are working fine. Now updated part-switching mods are appearing, and Module Manager is running, I've run some very old, DLL-free, mods without problems There are enough bugs to make me hesitate about moving from the sandbox. Most significant is a drag/heating change. Even stock parts are coming in fast and hot.

The file is the drag cube settings for parts, a sort of pre-loaded cache. I am not sure how the data is generated for a new part, and I am not sure that this workaround can be relied on for anything more than a stock game. On what I have seen of the results of this change, stock parachutes, at default settings, barely have time to slow the capsule to a safe landing speed when the fully open. Drag/Heating is one of those things in KSP where the smaller planets lead to distortions. How does a planet as small as Kerbin have the surface pressure and gravity that it does? . We might have a better atmosphere for planes, but this is Kerbal _Space_ Program, and that side is feeling badly wrong.

A later comment recommends deleting the "version =" line. I shall rename the v1.8.0 version to PartDatabase.cfg.original before copying over and editing the file from 1.7.3 Best check the bug comments before you do. Workarounds may change. The v1.7.3 file doesn't have a "version =" line when it's new It gets added when the file is modified It seems to make a difference, but the capsule still came down very fast and hot.

Tiny buggette in the 1.24.0 version. The Snacks.version file contains the following. "KSP_VERSION_MIN":{ "MAJOR":1, "MINOR":8, "PATCH":99 }, Looking at other .version files you've put out today they all use KSP_VERSION_MAX while this one triggers a version warning.

Some of it may be features rather than bugs: drag is lower and heating higher. There are some definite, and acknowledged, bugs, things like more heating on the right-hand wing than on the left. What I do see on ascent looks wrong, but manageable. I am hesitating about moving out of sandbox mode. The new SRBs are effectively moving some large and small SRBs from being Mod-available to stock: not identical but extending the range of options in similar ways. When I tried using them, it was very easy in v1.8.0 to go too fast, too low.

No need to run a list, but a lot of Mods have popped up on SpaceDock in v1.8.0 versions. We now have things like improved life support options. the sorts of stuff I routinely use, as well as several general-utility Mods. Not everything appears on SpaceDock, MechJeb is one notable exception, but we're past the stage of being limited to stock KSP. I now have mods such as Snacks! and M.O.L.E available, giving new options and problems, while RealPlume has appeared for visual enhancement. I've also tested older mods. I ran a launch with some relatively ancient parts, including a command pod from the old B9 pack, tanks and engines from Modular Rocket Systems, and with the Community Resource Pack installed The bug(s)/feature(s) around drag and re-entry heating are holding me back from moving out of sandbox mode. Right now, it's as much "Moar 'chutes!" as "Moar Boosters!"

There's a table in this Wiki page Atmosphere for Terminal Velocity, and it has definitely increased in v1.8.0, roughly 10% higher at 10,000 m. Is that significant? The maths makes my brain hurt, but drag is proportional to v² and density. I have checked. The .cfg for parachutes haven't changed

I suspect the drag changes are leading to a need for more parachutes to land a capsule. No-parachute descent speeds look higher, the reefed parachute descent speed looks high, the g-spike when the chute fully opens is way into the red, and the final descent speed looks to have doubled.

With all the talk of excessive reentry heating, maybe it's time for a mod to allow orbital popcorn delivery? I know we have spam in a can in real world spaceflight...

If you check the .cfg you may see this. // heatConductivity = 0.06 // half default It looks like that was the same in previous versions but it might be worth de-commenting that setting. It is used on the Shuttle Delta Wing Part. I also see these settings on the Corvus capsule. maxTemp = 1400 heatConductivity = 0.1 // 5/6ths default skinMaxTemp = 2400 skinInternalConductionMult = 0.625 maxTemp is lower than normal for wings, but those values are worth testing, I think. skinMaxTemp is already pretty high, about 500 degrees above the usual temperature quoted for the Space Shuttle, but it looks like the skin could be allowed to get much hotter than the interior without triggering explosions. I know, it feels like cheating to modify a stock part but (hand-wave) that could be how you can add a heat-shield layer to a wing.

Dev 900 is looking good, though some of the changes to v1.8.0 might need slight changes to ascent profiles and landing/re-entry planning. There's been a report of one bug affecting re-entry heating, and the differences I have seen may be more to do with creft-specific effects anyway, so I reckon I need to adjust the settings a little rather than expect a change to the defaults from Sarbian. Reports rather than personal experience, but the margins on re-entry may be tighter. The g-loading when parachutes open is scary-high: again, not really an issue for Sarbian.

That sort of thing can be very dependent on the operating system and how you installed KSP. I use Linux Mint, and I have had problems like that, which I take as a signal I need to run an fsck and reboot. Windows is different, but it does have a "portable" download in zip format which is worth having a copy of, even if you install with the .exe One thing I do is install a new KSP version to its own folder, with its own specific launcher, rather than overwriting anything. So I can always go back to the v1.7.3 game I have running. It's maybe easier to do that in Linux than in Windows, but KSP seems to be pretty good about sticking to its own bit of the file system.

I've already mentioned this in the very old original thread, where I'd also posted a couple of details of changes to the .cfg files that help reliable operations. The very old Phoenix Industries Ascent Vehicle, which is based on the movie "The Martian", still works in v1.8.0. There have been no obvious changes from the version I had working in v1.7.0 As noted in the old thread, the Base section stalls the loading process if Community Resource Pack isn't present. With stock engines it doesn't quite carry enough fuel to achieve Kerbin orbit. There are all sorts of things, such as language support, which aren't in this mod, but I reckon it's a good basic test. If this works, any old mod that doesn't depend on an external .dll is worth a try, if you like it. Whether it uses a .dll or not, I would be cautious over anything which uses an animation

I just did a test flight with the latest KSP 1.8.0 and it works, no real changes in behaviour, still seems to depend on Community Resource Pack for the Base section to complete loading. And it can still be found on SpaceDock at Phoenix Industries Ascent Vehicle As you can see above, I suggested a few changes to the config files and the node naming for the multiple engine mounts. I'd tested a couple of other old mods and it looks that anything that doesn't use an add-on .dll for some function is likely to work.

I just tried the latest Dev build of MechJeb, and it looks to have fixed that bug. Some of the general KSP changes might need slightly different ascent profiles, or slightly different boosters.

I ran several times without Mods before I went looking for updates. I think that any new KSP version, you should install to a new folder, because it's such a pain trying to find the problem if you just throw everything at the new version. I hope that at least I am a different sort of idiot.