micha

@rockowwc: I did not change the TechRequired for the ESC1 so afaik it was always supposed to be in the same node as the ESC2. However, feel free to suggest changes; specifically, which node do you think the ESC1 should be in now? But I don't think there's not much point having the ESC1 in an earlier tech-node unless the Experiments and Labs are also available earlier.

I've made an UNOFFICIAL EXPERIMENTAL build of this mod for KSP 1.x while N3h3mia is away, for testing purposes. This build also uses KIS instead of KAS (although may not work as designed; I've only done rudimentary testing). If people want to try it out, the thread with the download link is here. If you do try it out, DO NOT raise bug reports directly to N3h3mia nor to this thread; raise any issues or comments in the unofficial build thread, and I will collate them for N3h3mia on his return.

I've made an UNOFFICIAL EXPERIMENTAL build of this mod for KSP 1.x while N3h3mia is away, for testing purposes. If people want to try it out, the thread with the download link is here. If you do try it out, DO NOT raise bug reports directly to N3h3mia nor to this thread; raise any issues or comments in the unofficial build thread, and I will collate them for N3h3mia on his return.

I've made an UNOFFICIAL EXPERIMENTAL build of this mod for KSP 1.x while N3h3mia is away, for testing purposes. If people want to try it out, the thread with the download link is here. If you do try it out, DO NOT raise bug reports directly to N3h3mia nor to this thread; raise any issues or comments in the unofficial build thread, and I will collate them for N3h3mia on his return.

I've made an UNOFFICIAL EXPERIMENTAL build of this mod for KSP 1.x while N3h3mia is away, for testing purposes. If people want to try it out, the thread with the download link is here. If you do try it out, DO NOT raise bug reports directly to N3h3mia nor to this thread; raise any issues or comments in the unofficial build thread, and I will collate them for N3h3mia on his return.

Nehemiah Engineering Orbital Science Development Thread This is Micha's development thread for the Nehemiah Engineering Orbital Science mod collection originally by @N3h3mia. This thread will continue until such a time as Nehemiah is able to resume work on his mods. Please use this thread to discuss ongoing development, raising bugs, and testing pre-releases. The release thread is probably better to discuss the current stable release and general gameplay questions. I hugely appreciate people testing these builds and posting any bugs, feature requests, balance suggestions, or contributions in this thread. The pre-release builds are only available via Github. Releases on GitHub (KSP1.7) Link to last KSP1.2.x Version Resources @N3h3mia's Original Thread - contains original mod information, video tutorials, and more. Micha's Release Thread - contains current release information (duplicated here) Source Code on GitHub Version History From 0.7b3 onwards, only major changes are listed here. For a more detailed set of changes, please see the Changelog on Github.

Found a bug (I think): Kerbals can "carry" multiple items (ie, not in their inventory). I have a set of items configured as ModuleKISItemEvaTweaker: Dragging an item into a Kerbal's inventory makes the Kerbal carry it, as expected, however, adding a second one of these items only pops up a warning that the equipment slot is already used, but still adds the item to the Kerbal's inventory. I'd expect the second item to fail being added, or are there some additional settings I'm missing? Thanks.

Just a huge shout-out to Squad for getting quite a large set of bug-fixes out in under a week! Muchas gracias, hopefully you can go on a well-earned siesta now!

Yeah, Kerbals definitely need the ability to multi-class. Especially early in the game before you get access to the bigger command pods. And there needs to be a way to gain higher-level Kerbals without doing a tour of Jool just to fix a set of lander legs.

Sorry; right - in that case I'm all for getting something similar to AntennaRange into the stock game.

Yep, had this happen too while trying to climb/jump back into my pod. All of a sudden *poof* and Valentina was gone.

The AntennaRange mod I linked to above does exactly what you guys are asking for..

Hi, sorry if this has been asked before (no, I haven't read through the entire thread), but just wondering about ModuleKISPartMount and the allowedPartName parameter. Wouldn't it make more sense to have an allowedPartType? That way when adding a new part, it only has to specify what type(s) it is, and all mounts which support that type can mount it. Currently one has to create a new part, as well as editing all mounts onto which it can be mounted. Just a thought.

AntennaRange

Thanks for a preview of your plans, DMagic, very much looking forward to seeing the next version(s) of SCANsat! This has been a "must-have" mod for me as it adds so much to the early exploration of the game universe. Specifically I'm excited about your "Future Mode" plans, replacing the stock resource overlay with the slowly-revealing SCANsat one. You write that you will have to suppress the stock display and generate your own overlays, so presumably the stock resource overlay cannot be modded to just display partial data, but retain the rest of their functionality?

So basically, someone pressed SPACE too early?

I -have- used the entire scanning system. I -still- find the initial top-level scan silly. Sorry, but that's my own personal take on it. I would prefer that first scan to have a SCANsat-like mechanic, it can -stay- a high-level-rough-guestimate, that is completely NOT the point that everybody is (or at least I am) talking about. You're the one that seems to equate SCANsat scan == detailed info. We're absolutely not talking about the detail level of the data, we're purely talking about the actual physical in-game mechanic of HOW to get the data, not WHAT the data is. Anyway, I'm done with this discussion. It's obvious there's a basic disconnect between how different people want things to work and there's nothing wrong with either approach; it's purely down to personal preference. The mere fact that ISRU has made it into the stock game at all is AWESOME so thank you very much for your contributions, RoverDude It really is a great addition, and this quibble over one part of the mechanics isn't worth getting our knickers in a knot over. Since it appears to be possible for modders to modify the stock system I'm happy to wait and see what, if anything, the SCANsat author comes up with.

Umm, yes, we realize there's more to it than the high-level InstaScan. But regardless, we'd still like the high-level scan to be more SCANsat-like than the current stock behaviour.. Having the more detailed local scans is great, and I'm not advocating to get rid of those at all. Uh, sorry? Not everybody enjoys the game in the same ways. No one way is necessarily "better", just different. As long as the stock behaviour can be modded, it's all good.

Great, thanks Uh.. so does this mean that a modded-scanner can, or cannot, modify the stock resource overlay? That is, could a hypothetical mod display a partial scan of a body using the stock map view overlay?

No it most definitely is not! (IMHO). Haven't played Kethane, so can't comment on that, but SCANSat is one of the few mods to actually give a use to satellite probes, and provides a great start-game when exploring a new body. The mid-game is the detail-scanning, and the end-game is the actual resource gathering (whether it's ISRU, science from different biomes, or landing at anomalies). It was an absolutely brilliant game-progression in combination with Karbonite and taught a lot about setting up scanning orbits which are both efficient as well as covering the planet. With the stock scanning mechanic, there is no start-game. Just attach the scanner to your mission pod, polar orbit, BANG, dunnit, now straight off and perform the detail scans on the same mission, possibly even landing and starting to mine, all in one go. With a SCANSat-like mechanic, you'd FIRST send a probe off to scan your target, then while it's doing that, design, build, and launch your detail-scanner/mining-rig/science-lander missions. By the time you get the actual mission launched and on it's way to the destination, your low-res scan is done. And for the people that just want to send a single mission, time-warp completes the scans in a couple of minutes anyway. Sorry, RD, but some people would prefer not to have the Insta-scan, no matter how you justify it. Not saying it's a bad solution, but it's not for everyone, and it would be awesome if modders could override it.

Thanks for keeping this mod going!

@RoverDude - I'd like to come back to my original question, which unfortunately got overlooked by the Insta-scan controversy. Is it possible for a modder to replace the stock Insta-Scan with a different scanning mechanic? For me personally I'd quite like the stock resource scan to be integratable into SCANsat (even if the resulting map is still at the same rough resolution as the stock one until the player performs the detailed scans). That is, can a mod modify/prevent the game from displaying the resource level overlays until a scanner has actually scanned the terrain? Thanks.

So why not also have "full unattended scanning" ? Either a game process takes in-game time or it doesn't (whether or not the player time-warps past to reduce the impact on player time). Currently one part of ISRU takes no time, and the other part takes time - just, IMHO, inconsistent. EDIT: Ah.. should've read r_rolo1's post before replying; basically what he said. EDIT2: I'm in the camp that's happy to wait for background processes to complete. I'd be rather unhappy having to watch while some process worked though (even if time-warped).

@RoverDude: Wrt scanning - will it be possible for SCANSat to override and replace the stock "Insta-Scan" and perform background scans like it does with Karbonite? Yes, people could always timewarp, but they could also run other missions until the scans were complete. Your explanation of getting the player to do the difficult stuff (getting the scanner into a polar orbit) and cutting out the boring stuff (waiting for the scan to complete) could also be applied to mining itself - the difficult part is landing the mining rig on a decent concentration, the boring bit is waiting for the extraction. So why speed up one aspect (scanning) but not the other (mining)? Seems a bit inconsistent to me. In either case; great stuff getting ISRU into the stock game!

First thing to reach orbit (and space) was my stock-career 3rd launch, with Val in the pod. Survived (*mostly) re-entry without heatshield. No pics unfortunately - only had a quick half-hour to play around. (*) Goo pods strapped to the outside cannae take the heat!