micha

I just recompiled this mod for KSP1.8.x, given that there hasn't been any activity. Hope I'm not stepping on any toes. Apart from tweaking the project files, rather surprisingly everything appears to still work I but haven't tested in detail. I only use the resource transfer features, not the roster management. Can download the compiled version from GitHub (https://github.com/mwerle/ShipManifest/releases/tag/6.0.0.1_mw) or people can clone and recompile themselves. NB. I changed the major version number not because there are new features, but because it's not backwards-compatible with earlier versions of KSP. Edit: Oops, sorry, missed @leatherneck6017's comment. Although, and please don't take this the wrong way, personally I'd want to know what went into the personal recompile so would want to see the source instead of just a binary download from dropbox.. If you have any personal patches for this mod, it'd be great if you could share them.

So I love Engine Plates. Not so much for the additional engines that can be mounted, but rather the very neat interstage fairings they provide. Quite apart from actually mounting engines, they've proved quite useful in creating a small cargo bay for mounting probe cores and stuff between stages, for example, to create a "smart" booster which can be deorbited (and possibly recovered). Just can't do that with standard Decouplers, and even for normal stage separation they don't have the same neat fairings when engine sizes don't match the tank sizes - I've never understood why those fairings match the engine size and not the tanks! So having just brought my reusable Mun Lander to the orbiting Mun Station, I rudely discovered that there's no way to refuel the Lander! I had "cleverly" used an Engine Plate to mount a probe core and use the EP's shroud to hide it and all its paraphernalia (batteries etc). But with no cross-feed, once the Lander is empty, that's it(*). Well, doh! (*) I guess I could try to bring up a fuel line and mount it with KIS...

I don't see a credible source stating it was an "over"pressure test. SpaceX put out an official statement that the systems would be pressurised to the max. Ok, I guess one could read that as "max possible", I read that as "max spec". (Pressure vessels are generally rated slightly above spec to give some leeway). Regardless, you'd think they'd Reconfigure the safety valve to the target test pressure, not just disable it. Have alternative additional safety systems (burst discs etc) to prevent a RUD in the event that there was a problem with the pressure test itself (ie, the test delivered more pressure than planned) Have slowly ramped up pressure-tests until they were reasonably confident an over-pressure test would not compromise the integrity It all points to the tank itself having either been damaged/stressed during building/moving of the prototype, or not having been fully tested to spec prior to installation meaning there was no way to know whether it was actually built to the spec.

Doubt that's true - revisions are bugfixes. 90% of mods even work fine across minor version number updates (ie 1.6 -> 1.7). 1.8 was a bit special because they changed the version of Unity; really that ought to have been a major version number change (1.x -> 2.0) but I can see why they wouldn't do that... And 99% of mods work across patch updates (1.8.0 -> 1.8.1, 1.8.2, etc) So from a modding perspective, unless an API your mod uses or the specific feature it interacts with in the game is known to be buggy, there's no reason to wait for patch updates before updating and releasing.

Apologies for the misunderstanding; I wasn't meaning for the pull request to be used verbatim. It was my way of documenting my proposed changes. I **know** you are doing this as a hobby and a public service to the community, as are most modders, and that you don't need more unnecessary work. I was part-way through your suggestion of writing a document, but I'll consider writing a script instead. Peace.

I made the changes with an eye to be applicable to all of your mods. I just used StageRecovery as a full example for your consideration. The pull request is fairly small and the changes should be self-explanatory enough to hopefully be self-documenting. Thank you for considering. EDIT: PS. I answered your points re my pull request in the pull request itself

THIS!! Also, I've created a pull-request for StageRecoveryMod for your consideration which has some tweaks to your build environment to make it more generic. Eg, use of $(DevEnvDir) instead of hard-coding the full path to Visual Studio, and generally making your scripts a little bit more generic by removing hard-coded paths. I appreciate you are managing a lot of adopted mods so of course the environment has to first and foremost be easy to use for yourself, but by adopting a few small changes it might make it easier for others to help out with minor contributions and thus reduce your workload a little.

Docking Port Alignment Indicator.

THANK YOU! I've been seeing dozens of similar issues all over the place and haven't figured out how to fix it despite spending quite some time with Mr Google.

Great script, thanks for sharing! My personal approach to Step #5 though is to set a "KSP_Dir" variable in a project file (or props, or project.user) and use that to reference the Assemblies. Of course that is pointed at my current "KSP_Dev" directory, never at my Steam install or play-through install. This way I ensure whatever version I'm testing was also the version I used to compile, and there's no need to keep the Assemblies in multiple locations and remember to keep them in sync. With this approach all another developer (or myself on another machine which has a different directory layout) has to do is update that one variable and all assemblies are referenced correctly. If using the .user file approach (which shouldn't be committed to GIT) it's also very easy for multiple developers to work on a project without constantly having issues with spurious updates to the project files. Horses for courses Thank you!!!

Because there are some minor issues which I know how to fix and I'd like to create pull requests for those.

G'day, Has anybody had success compiling this mod on Windows using Visual Studio? I've had a play around and can't work out how to compile the "ScanAssets" project, all I get is "incompatible project" when I try to load the solution. Google has not helped apart from making me strongly suspect that it's a MonoDevelop project. Unfortunately I can't find a binary release of MonoDevelop for Windows, and I'm not compiling that from scratch!

Yes, if Blizzy's toolbar is installed, DPAI will default to using it instead of the Stock Launcher. There's an option to force using the Stock Launcher instead. You can either use the in-game settings to change which toolbar to use (requires a restart), or you can edit the settings file using a text editor before starting the game.

I installed it last night using CKAN (MUCH easier to manage mods; I highly recommend you use this instead) and it worked just fine for me. Attaching the "KSP.log" file is pretty much the first step when asking for help with a mod which appears to be not working as intended. It gives valuable information about whether the mod got loaded, which version, and any potential errors. Next, please tell us exactly how you installed it - if you did it manually perhaps you accidentally copied it to the wrong location.

If we're talking mods (not stock, which was the OP's suggestion), there's also HGR (Home Grown Rockets) which adds a nice set of Soyuz-like parts for the 1.875m stack size. unfortunately the current maintainer is against CKAN so it doesn't get as much exposure as it should get. Just one minor correction: Soyuz has the vast majority of all actual human spaceflight to date...

No it doesn't. MH has some Vostok/Voskhod parts (not even a full set) and no Soyuz at all. Even worse, in the early game when you unlock them and would use them you don't have fairings which are practically essential. No idea how new players are supposed to use them. I expect they get frustrated trying to launch and then just ignore them. Later in the game they're mostly outclassed. It would be nice to have some kerbalised equivalents of the Russian parts in stock to complement the American Mercury/Gemini/Apollo parts.

Running into each other later on : basically different species/societies started off geographically separated (whether same planet/different continents or other barriers, or different planets in the same solar system). In the former case, given our history, I'd guess humans would attempt to subjugate/exploit/exterminate, just as the European civilisations did globally in our own history against our own species, assuming the humans were the first to develop the technology to travel to other continents. Conversely if they were the first to reach humans, it's difficult to say. Probably heavily dependent on their approach to us. Most civilisations have been cautious but curious about visitors. Then again, if the civilisations arose on the same continent but encountered each other later, there might be a more gentle interaction; probably still lots of wars, but also trade and cultural exchanges which would eventually result in a society similar to our modern one, just instead of the differences being limited to minor racial differences it would be multiple species along with racial differences within each species. Perhaps that might make the merged society more tolerant, rather than less? In the latter case (interplanetary contact) I would hope to guess contact would be friendly - it would take technology on par to our current civilisation to reach other planets and mostly we've started to respect other cultures now; at least in cases when there are no economic pressures. Case in point the tribe on that Indian island is being actively protected, whereas the natives in the Amazon are still being driven away/killed by local farmers with only lackluster governmental protection. I'd strongly suspect that if we had detected not only life, but a civilisation on another planet by now we'd have rapidly continued to advance our technology sufficiently to be routinely able to travel there and back instead of stagnating in LEO. If they would be at a similar level to us technologically we'd probably have established long-range communication before and have had significant cultural exchange prior to a physical meeting. If they had not yet reached our level of civilisation I'd strongly suspect we'd practice a no-interference policy.

Did humans evolve together with the non-human species (ie, typical fantasy setting)? In that case, no different to how humans generally treat others who are different (skin colour, cultural background, political leanings, etc). Ie, a significant proportion of the population has zero issues, and a significant proportion of the population are just <self-redacted>. Assuming the non-humans are new on the scene (eg, future alien contact), I guess the same: most people would be ok, but a large proportion would not be. It would also heavily depend on the context of the initial contact - was it friendly or due to competing for a resource? Perhaps if the contact is some ways off in the future there is a slim hope that our society has become more tolerant but looking at the current state of things, it's not looking great. The problem with these questions is that there is no thing as "we" to encompass everybody; there is enough personal variation between members of our society that there will be a huge multitude of responses.

Stone tools and tech is not limited to species which have formed societies; critically, societies in which members can communicate complex ideas. Looking at Earth, humans are preying on pretty much everything; even if we don't actively eat the animals, we destroy their habitats. We are now starting to realise that animals can also have significant levels of "intelligence" and display human traits such as empathy and sorrow etc. So what makes a creature "intelligent"? Having progressed beyond stone tools to forming cooperative societies? In your example, let's say instead of stone-age, the predator-and-prey species have each managed to evolve beyond that and each has started to realise that the other is intelligent, and perhaps have even managed to work out some way of communicating with each other. For this to happen there must be some way for the bulk of the prey species to be safe from the predator species such as geographic separation, otherwise I doubt the pressure of predation would allow their society to progress that far. However, given they have, I'd like to think that eventually the predators would stop preying on the prey species and feed themselves using alternative sources. Even our species is starting to show some limited respect for our environment and we have (mostly) stopped killing some animals which we consider to have above-average levels of intelligence although there are plenty more we continue to prey on which have proven significant levels of intelligence (eg, octopus). The other point is that necessarily the prey species would have to _significantly_ outnumber the predator species, which means if both species get as far as tool use (even just stone tools), the prey species would quickly be able to fend off the predators at that point (natural weapons becoming less effective compared to artificial ones) which would either result in the predators dying off or necessarily having to turn to other sources of food. Which again means that by the time the species evolve further they would no longer be in a predator-prey relationship. And the prey species would likely evolve their technologies and societies significantly faster than the predator species, again due to numbers, making it more likely that in future the predator species is on the backfoot.

This actually makes a lot of sense; a lot of simpler stuff could be done via scripting and should expand the modding community significantly. As long as we still have access to a feature-rich API for the more complex stuff that's cool.

No Linux version and no *comprehensive* modding support would be the two main deal breakers for me. I read somewhere that modding is going to limited to some scripting language; that's going to really turn me off if true.

Oh, and as to what I think about it? Bloody stupid, of course. There's lots of things governments can and should be doing. But forcing us to put passwords on our Wifi is not one of them. As far as I know (correct me if I'm wrong) there's not even a law requiring you to put locks on your doors.

What he means is that the State would like you to be responsible for anything that happened on your network. Ie, say you have unsecured wifi and you pirate some piece of software, or hack into a bank, or any one of a hundred other illegal activities. If the police then knocks on your door and says hey, you're nicked for doing xyz, you can just say, wasn't me, guv, musta been a neighbour or someone using my wifi. Basically you can easily disown responsibility for any actions done via your network to persons unknown. Whereas if you have secured wifi, the assumption is that nobody can break into it which means they can prosecute you (or someone you gave the password to) for doing xyz. Which is, of course, fallacious, since no technology is ever foolproof and an attacker could link into your network in other ways. It just shuts the easiest and most obvious hole.

Cheers. Discovered while testing that I've partially broken Kemini during a recent refactor - it's just not visible because I also accidentally released with testing enabled lol. As for KEES, it was always @N3h3mia's intention to remove the hard dependency on KIS. Not sure if there's some way I can use the new Surface Experiments from Breaking Ground to reimplement KEES.

NEOS 0.8.2 seems to mostly still work with KSP1.8.0. The big breakage is KEES as that relies on KIS, which will take a little while to get sorted. Details from @IgorZ here.