Farix

So no overhaul of the 1.25m engines? That's rather unfortunate because I looking forward to properly paring them up on those 1.875m engine plates.

That really depends on Porkjet's contract. It could very be that he was a freelance artist and thus SQUAD purchased the copyrights to his artwork peacemeal rather then as work-for-hire. Or he could have some artwork as work-for-hire and other works as a freelancer with the part overhaul in the latter category. Other explanations could be that SQUAD just didn't like his redesigns or there were personnel conflicts and SQUAD refuses to use any of his work that wasn't already in-game as a consequence. Remember that Porkjet left at around the same time as 7 other developers, so there were likely some bad feelings. But Occam's Razor suggests that the simplest reason, copyrights, is the most likely answer.

Will we see the stock vessels redesigned to use the revamped parts in 1.5?

There are probably some legal issues with that. It really depends on if Porkjet's part overhaul falls within the "work for hire" framework or if it was a project he did on his own.

That's rather unfortunate, but shouldn't console development have some diversity? Look at Minecraft on the PS4 and Xbox 1. They get updates, although a little bit later, and although one version of the Xbox 1 version has stopped being developed, their development team has told everyone and even released a new version! I wish squad was more like this. Apples and kumquats. Minecraft is a highly successful product, and because of that it is well worth Microsoft's time and effort to update it to attract new players. However, if Minecraft wasn't successful on the consoles, I highly doubt the console versions would see any regular updates. In fact, the whole reason Microsoft purchase Minecraft was because of its success on the consoles.

My guess is that the ROI of the console port wasn't worth the effort. You do realize that a game can be a financial success on one platform but a failure on another? That is pretty standard for most console games. Once the game is shipped, that is the end of its development cycle and the company, in this case BlitWorks, moves on to the next project.

I'm guessing next week will be the 1.25m engines. Loving the art pass of the older sock parts so far, though the RT-10 "Hammer" could do with one less yellow stripe. However, this art pas has been long overdue.

It means that the art team's work does not affect the progress of the dev team to fixing bugs. And if the art team is not actively working on anything, then they are a financial drain on the company. So they could either continue to do their art and modeling work, or Squad could just fire them as "unneeded". But if they did the latter, they will need to hire a new art team when it comes time to add new art assets into the game. And that would be a larger financial drain than if they simply kept the old team on staff. Your basic argument came down to complaining that Squad was focused on "revamped art assets" rather than "fixing bugs." The two, however, have no relationship to one another. You cannot simply reassign the art team to program development and expect bug fixes to come faster.

What is the art team to do? Sit on their hands and do nothing because you "demand it"? Do you want Squad to fire the art team simply because you think that will allow the programmers to concentrate on fixing bugs? News Flash: The art team cannot do anything about fixing bugs, but they still need to earn their keep.

FYI, NMM is getting a huge overhaul as the developer of Mod Organizer has now take over and is building a new mod manager from the ground up.

That is because the version file uses KSP_VERSION instead of KSP_VERSION_MIN and KSP_VERSION_MAX. A lot of other mods are also throwing warnings for the same reason.

I'm not sure what you mean, unless it's because the overhauled parts are less powerful than their stock counterparts. Or that the Mk1 Command Pod needs the ModuleDataTransmitter code added to it. Or is it the Valiant and Pug engines? Valiant is just too underpowered to be of much use and while the Pug is a good orbital engine do to it's light weight, its low thrust doesn't leave much room for error. However, that is besides the point. If someone is using these parts with the UBM tech tree, a command pod will be available in the very first node defeating the entire purpose of the tech tree. PorkJet's overhauls didn't touch the stock parts. They are entirely new parts.

Field a bug report to Infernal Robotics: https://github.com/MagicSmokeIndustries/InfernalRobotics/issues/128

If you happen to be using PorkJet's Parts Overhaul in this tech tree, then you are going to end up with a command pod in the very first node and engines and tanks not matching their stock counterparts.

So what exactly is broken other than not having entries on the new biomes?

Any known issues with running the current v0.3.1 with KSP 1.2.0 + Kopernicus v1.2.0-3?

I would actually prefer to download just the SVE texture and config files while downloading the other mods separately. It makes it much easier to upgrade the individual components and adapt for future version of KSP.

I was able EVA from the default part, but I also noticed that the textures are completely different form the ones that are available. Could this have been a old version of the part that wasn't completely removed?

Is the latest release v7.4.1? Because that was the version I was using when I encountered the problem. Anyways, I had already failed the mission so I wouldn't be able to test the part in that situation again.

Apparently, Contract Configurator breaks ScanSat (prevents scanners from activating). When I reported the problem on GitHub, @nightingale blames it on @blizzy78's Toolbar, even though the toolbar wasn't installed. https://github.com/jrossignol/ContractConfigurator/issues/590

It's always a good idea to have multiple ways to download a mod, least we have another KerbalStuff. I also know that some of us prefer not to use or support SpaceDock. Since there is a GitHub repository for the source code and they have more robust servers to begin with, why not add releases there as well?

I don't think RealPlume, RealPlumeStock, or SmokeScreen even touches the command pods in any way. But delete \RealPlume-Stock\PartOverhauls to see if the problems continues.

Is it possible to allow EVA from this part? Or at least prevent it from being used in rescue missions?

Is there an alternative download, like Curse or GitHub? SpaceDock is proving to be completely unreliable.

Hmm. Isn't Real Plum suppose to produce a smoke trail in atmo or is that part currently broken in SmokeScreen?