magico13

I decided to try out coming up with a basic implementation of this. Definitely not working in a stable manner, but the linked code is a proof of concept. If you don't mind too much, I'm considering trying to make this idea into a "physical ground scatter" mod where physical ground scatter could happen, like icebergs in water, or rocks in the desert. Ideally it'd be easily modable so people could add their own scatter based on planet, biome, latitude, etc. The code below will take whatever craft file is in GameData/PhysicalScatter/iceberg.craft and will spawn it directly below the active vessel when it's over water and below 1km. It spawns quite a few of them (up to 100) and doesn't seem to be removing them properly. Like I said, very much a buggy proof of concept. Note that it takes a craft file, not a part file. It's got code that's basically a direct copy of the code from Contract Configurator. I had to make a few changes, but not too many. Since everything needs licenses, this will be under the MIT license, per Contract Configurator. link

Pretty much every mod you've got is throwing errors, but it looks like it started with Extraplanetary Launchpads. Was this after a launch using KCT (probably, it goes from SpaceCenter to Flight)? I might have to test out that configuration to see if the logged error in EL is happening every time, and if it's just a "visual" error or actually the cause of something bigger. Hmm. This does seem to be an issue, so thank you for taking the time to look into it. I don't often get to play KSP, so balancing things is always a bit of a challenge (and I frequently play with some settings disabled or tweaked anyway). I can see how the in-game ways of speeding things up can actually make the problem worse. Rollout and reconditioning are both halves of the same total time. A single BP value is calculated for each vessel and rollout becomes x% of that while reconditioning becomes (100-x)%. 50% then would make them take equal amounts of time, but as each vessel will have a different mass it's not guaranteed that rolling out immediately after launch will line up perfectly, but they will be closer. You could reduce the total amount of time that way, yes. The max reconditioning time is 96 hours at 1 BP/s, correct (16 Kerbin days, ONLY 4 Earth days, which isn't actually much when you think about it, but Kerbal time is weird). All of the VAB rates are added together to give the total rate, so two rates of 1 BP/s each will reduce that time to 8 Kerbin days. Tweaking the BP to mass ratio, or even the reconditioning formula itself, might be the best solution at the moment. Separate launchpads will also help when I get around to that, since you'll be able to avoid reconditioning on one pad by just using another pad. I'm personally OK with having to wait a little bit for the pad to finish, but it's possible you might be waiting for quite a bit longer than is reasonable. While I might get a backlog of vessels waiting to launch, it forces me to play around in the SPH to come up with alternative solutions. In a previous save I finally learned how to make an SSTO just to do LKO missions, saving the VAB for bigger missions, and I found myself using my SSTO more often than the VAB. The balance could still use tweaking though. At the very least, it's better now than when it was twice as much time per ton and there was no maximum (50 day reconditionings were not unheard of). If you find some settings that feel more appropriate, send them my way and I'll consider using them for the default settings.

If you'd like, I can try to throw something together. I've been thinking of trying to do something else that's related, so I could eventually work this into something bigger.

My suggestion would be to look at Contract Configurator's code for placing vessels at specific locations. The hardest part would be to ensure they only spawn in water, but if you only spawn them within, say, physics range of the active vessel then you can probably poll the PQS system and check if the terrain height is less than 0. You can quite easily check latitude and primary body. It actually shouldn't be very difficult or require much code. Pseudo code: During FixedUpdate() randomly decide whether you should try to spawn an iceberg. Check that the active vessel's mainBody is Kerbin (compare names, for instance), and perhaps that the active vessel's altitude is < 2km or so. If not, cancel. Pick a random location within a few km of the active vessel (add a random offset to the lat/lon of the active vessel). Check the terrain height at that location. If < 0, spawn iceberg (using the Contract Configurator code). Else, cancel (or pick a new spot). Repeat until you hit some internal limit of how many icebergs to spawn. To avoid issues with having a bunch of icebergs in the save file, I'd add a listener for the vessel unload event and destroy the iceberg rather than save it to persistence. You'll need to test it a bunch, but it shouldn't be too difficult to implement. Edit: Just to specifically address the concerns of the above poster, here is (one way) of handling the issues they present: Only spawns in water -Check the land height is less than 0 Only spawns on Kerbin -check that the active vessel's mainBody is Kerbin Only spawns up north-ish -Check the active vessel latitude. Make sure the absolute value is greater than ~70 degrees (assuming you want north and south) Spawns on the surface -Set the iceberg's altitude to 0. Might need a slight offset. Testing will make that clear. Matches velocities with Kerbin -Set the vessel situation to landed or, better, splashed down. Orbits aren't calculated for those. E2: If it wasn't clear, you'll very likely need a plugin for this.

Note that HoloDeck's feature set is currently quite limited. It's based on Kerbal Construction Time's simulation feature (and will eventually replace it), but if you want more features you can look at KCT. You can disable all the time requirements for building things in the KCT settings by disabling build times, if you just want to use the simulation feature. Link is in my signature.

The VAB/SPH crew select has never worked. Partly because any time I tried to get info from it, or to set info in it, it's been a giant pain. But more importantly, because there's a decent chance that whoever you assign when you start building a vessel might be on a different mission by the time you go to launch. KCT's crew selection finds the first crew carrying part and fills it by taking the people from the top of the crew list. If you turn on the random crew selection setting it will give you random Kerbals that you have hired instead (but you can still select them manually). Basically, the crew selection in the editor doesn't do anything with KCT, except in the case of simulations (since that uses the same function that the launch button does in the vanilla game).

Those pictures are a bit out of date, so what you describe isn't too far from what you should be seeing. Let me see if I can help. The window in flight will just list recovered/destroyed until something is actually recovered or destroyed, then clicking on the button will list all of the recovered/destroyed stages. Clicking again on a stage in the list will bring up the parts/crew/etc tabs. KSP 1.0 increased the physics range, so it's possible that the stages you're dropping are hitting the ground before they would go out of physics range. Try either deploying the chutes when you decouple, or decoupling at a higher altitude. You need to get 22.5km away from them before they hit the ground in order for StageRecovery to kick in (that's when KSP deletes them). In the VAB/SPH clicking the SR button will cause a message to appear in the stock messaging system (where contract completion messages go). There isn't a SR specific GUI in the editor. If you still need help, let me know and I'll try my best to help you

Not right now. I've been thinking of ways to do that though, since it'd be convenient. Might make my own GUI because it'd be easier to have all the features I want but my GUI skills aren't all that great

I have no idea actually. A mod (could have been KCT, could a have been something else) apparently tried to do something based on the last editor that was used. You actually can do that in stock, clicking on the launchpad or runway normally let's you launch without going into an editor (with KCT installed it starts a simulation). I'll try to double check to make sure it's not KCT causing the issue, but if the issue happens again and you haven't entered an editor that session, try to do so in the future

It's hard to tell what initially caused the error, but if you've launched there without error before then it might just be a one time thing. If it keeps happening, let me know and I'll look into it more. That message pops up whenever anything prevents KCT from loading it's data (during the OnLoad event). Usually it's from another mod encountering an error, which prevents all other mods from loading properly. FMRS logged a similar error, Kerbal Alarm Clock logged an error early on in the scene change, but the one that sticks out most is below (along with some other log entries that were nearby). I can't tell which mod caused it, but it looks like it might be because you didn't go into any editors first (VAB/SPH). Loading ship from file: /media/SteamLinux/SteamLibrary/steamapps/common/Kerbal Space Program/KSP_Data/../saves/SETI/Ships/temp.craft RemoteTech: Loading Flightcomputer from persistent! KIS Spare Parts loaded! ArgumentNullException: FacilityName is not a valid Space Center Facility name! Parameter name: pSystemFacility at EditorEnumExtensions.GetFacility (.SpaceCenterFacility pSystemFacility) [0x00000] in <filename unknown>:0 at FlightDriver.Start () [0x00000] in <filename unknown>:0 Activating BetterBuoyancy EVA Watcher [BetterTimeWarp]: Set time warp rates to 1, 5, 10, 50, 100, 1000, 10000, 100000, [BetterTimeWarp]: Set time warp rates to 1, 2, 3, 4,

Before this turns into another one of those threads, I'll kindly point out that a LOT of people (usually mod authors) are against this idea, for a multitude of reasons which basically boil down to "it's a nightmare for mod authors to provide support". Most people are cool with the idea of mod lists, though. In fact, both KerbalStuff and CKAN support the creation of mod lists. See here for KerbalStuff (I'm not positive if there's a place that actually explains this anywhere) and here for CKAN. I would suggest including one or both in your final lists to make things easier for people to find and install. No need to create a separate zip, everything is always up to date, and mod authors won't have any issues with you. Other than that, I'm all for people creating mod lists. Helps bring awareness to some mods that might not otherwise get noticed, and can create games with totally different play styles.

I know that feeling, I spend way more time working on KCT than I do playing KSP I occasionally take some time off from it just to play and get a sense of how things work and what needs rebalanced, but usually if I've got time I'm going to spend on KSP things, it's on updating this mod.

Awesome! It hasn't been pushed into the official release yet, since I don't make official releases very frequently unless I've got several important bug fixes or sizable new features. I'm halfway through a new feature, but depending on if I get any time to work on it this weekend it might still be a few weeks. I also want to add a few more TestFlight related things before I do a full release

The link worked fine So, where the crash occurred was after KCT would have recovered the ship. It's definitely possible they're related, but the log unfortunately doesn't really say anything that I can comprehend (usually it just lists errors [which I can generally read], crashes to desktop are pretty rare for reasons other than hitting the memory limit, and the memory limit wasn't the issue here). I'd just load it back up (maybe backup the save first) and see if anything got messed up. If it happens again under the same circumstances, let me know and I'll look into it more. Might have just been a one-time fluke. So, you actually have a few options. I'll list them from least likely to be what you're looking for, to most: 1) Adjust the rollout/recon. split to keep the total time constant but move more of it into rolling out the vessel rather than fixing the pad. 2) Lower the Max Reconditioning setting (under Time Settings in the KCT settings menu) to reduce the maximum amount of time that reconditioning can take. 3) Or, under the clearly labelled "Launchpad reconditioning" setting in the Time Settings, increase the mass listed there. By default it should be something like 86400 BP per 50 tons. Increase that to 100 tons to halve the reconditioning time. Set it to 25 to double it. Etc. In-game ways of reducing reconditioning times: 1) Use a smaller rocket. Reconditioning is directly related to mass. The more massive the rocket, the longer the reconditioning time. Using the smallest rocket needed will keep the time short. 2) Upgrade your VAB rates. The rate at which reconditioning completes is all of the VAB rates added together. So a single fast rate of 2 BP/s means reconditioning will complete at 2 BP/s. Two rates of 1.5 BP/s means reconditioning will complete at 3 BP/s. Hope that helps!

Send the log my way anyway and I'll take a look at it in the morning. There's a pretty good chance it's KCT related, since that recovery code can cause some interesting problems (but I haven't seen a crash to desktop from it yet). I generally advise quick saving before using it (in fact, I think I'm going to make KCT make a quick save before it runs that code in the future). Hopefully your save is still good (it probably is). I wrapped that code in try-catch blocks last update to prevent any errors from disrupting things too much.

No problem. I like discussing ideas for how to handle procedural parts because I'm not 100% sold on the current method. It still allows for flexibility, but doesn't really promote any sort of standardization. A hybrid system where you can recover procedural parts as-is and use identical ones like you would with the normal inventory, but then also break them into procedural scrap to make other parts (with a longer time requirement). So you could recover a 1.25 by 5 meter fuel tank and then use it as a 1.25 by 5 meter fuel tank for 1/100 of the "effective cost", or you could scrap it and turn it into a 1.25 by 2.5 meter fuel tank for 1/10 of the "effective cost". It'd require a rework of the inventory system, which I've actually got a working model that I can use as a base. Agreed. When I get the chance, I'll look into it more. The worst for me is when you start a probe in orbit (maybe just to test if there's an unreasonable amount of torque from a non-central center of mass, or maybe to test a landing script) and it doesn't spawn within signal range. Then, since you can't open the solar panels, the battery dies and the whole thing was a waste. Had that happen a number of times Regarding special features of simulations, in the dev versions of KCT you can disable part failures from the TestFlight mod (and re-enable them later if you want). I'll be doing a bit more with TestFlight when I get the chance, like letting you keep some of the flight data from simulations, since KCT makes it hard to actually test things without building them first.

The plan is to spend funds and/or science to purchase additional pads, which start with the level 1 launchpad restrictions and can be upgraded for the same funds amounts as normal launchpad upgrades. I might remove or reduce reconditioning requirements for lower tier launchpads (they're simpler to fix). So it might be beneficial to have a low tier launchpad for small launches. Also, then I can physically change the launchpad to the right tier when you launch

Reconditioning is directly related to vessel mass (but does max out at some point), so using the smallest launcher necessary does result in a smaller amount of reconditioning time I'm glad you're having fun with time constraints and are enjoying the extra planning required! I find myself freaking out when a transfer is coming up in 200 days but I have other missions I need to complete before I can afford to launch for the transfer (because if those go wrong I might not have time to send a rescue and build the ship for the IP mission). And once I get the needed funds, I build the ship well in advance so I can make edits if necessary (I'll even run another simulation or two, just to make sure I'm not forgetting anything). In stock KSP, by 200 days you've already completed the tech tree, have millions of funds, and have walked on every inch of Mun and Minmus. With KCT in 200 days I've made it to space twice I'm glad that others actually find that fun, and it's not just me Also, you gave me the last Rep I needed to get a Light Green bar

I forgot to include the license in the StageRecovery download (coulda sworn I had put it in there!) when they went through and started cracking down on that. The infraction itself has long, long passed, but that new tab will always haunt me! The notification tab is always a fun adventure when it's lit up! I generally know if it's a PM (those get sent to my email as well), but sometimes I won't have checked my email and it's a fun surprise. I like when people send me funny things that have happened (in KSP or in the forums, like me forgetting to change something in an OP that was no longer relevant), or are asking for help setting up something using my mods (like special challenges), or just want to say thanks (rep is always appreciated). I only ever once got "hate mail" and that was from someone who thought my April Fool's prank was real. Even then, they were quite respectful. Overall, the notifications are always a good thing!

I can add that as an option, but it'll still probably cause issues with the extended antenna. What I really want to do is add the ability to turn RemoteTech signal requirements on and off in a simulation. Then you can do stuff around Eeloo without worrying about signal, or can try manually landing your lander, or can just extend your antenna manually once the orbit has been set. I've looked into the API a bit, but haven't discovered any easy way of doing it. Might just ignore the API all together and make changes on the actual RemoteTech instance loaded into the game. That's not too far from how it's implemented now actually. Build Points aren't set per part directly. They're dependent on whether the part is in the inventory, how many times it's been used in a build, and an interaction of several settings. What is constant, at least in default KCT, is that the BP is based on the cost of the part. So PP are broken up by cost. 1 funds of a procedural part is 100 "parts" in the inventory. So when you recover something worth 1000 funds, you get 100,000 "parts" for that specific procedural part. When you build something that costs 500 funds, 50,000 parts are taken out to build it. If you build something worth 1500 funds then the whole 100,000 parts are taken out (and are built quickly) but 50,000 isn't covered by the inventory and you pay full build times for them. Because procedural parts are extremely flexible (and, from a roleplay standpoint they require retooling and rebuilding each time), they're only 1/3 as effective as normal parts (they only get 1/3 of the InventoryEffect, or they get 1/10 and after the square root it becomes 1/3 less time. I don't recall off hand). But that's still a pretty huge reduction in time. And they get the BuildEffect applied normally to them (which is nice because they'll be used in almost every build). The formula that controls how Procedural Part BP values are calculated is actually one of the ones exposed for editing. You can't change how Procedural Parts are added/removed from the inventory, but you can change how their BPs are calculated if you want to make them stronger/weaker compared to normal parts, and if you want them to be mass based or cost based (but the inventory is cost based always).

It sounds like a configuration issue in KW Rocketry. Try recovering a part that isn't a fuel tank or an engine. They're likely still using the old propulsion category for fuel tanks and engines, which hasn't existed since 0.25. If you look in the save file you'll likely see them listed in the storage. They just don't show up in the GUI because it doesn't have the deprecated Propulsion category. Unfortunately, not right now. I should add a way to do that through the KCT_Formula.cfg since a few other people have asked for it. In the meantime, you can just unlock them one at a time if you really want.

12 until my first light green

If you wait some unknown time to update, I'm only 12 points away. Who knows how long that will be Edit: It will apparently be two days! Hello light green!

Already exists! Open up the KCT window while landed on Kerbin, choose VAB or SPH as appropriate and then the big Recover to Storage button. Quick save first though, as the method it uses to convert a vessel to a craft has been known to have weird issues in the past.

Unfortunately you might be right. I can't think of why there would be an issue with the 64bit version, but weirder things have happened :/ What parts specifically and from what mods? If the stock parts are going into the inventory when recovered by StageRecovery, then mod parts should too. They aren't treated any differently. Unless they're procedural parts, which are treated differently. Logs would possibly help, but you also haven't given me anything specific to work from. If anyone else notices issues with parts being recovered by StageRecovery, please let me know! I'm (obviously) in a pretty good position to sort them out. Darn, I thought I had taken care of issues like that. I'll play around with it and see what I can do. I thought everything was being sanitized properly on exit, but I guess not :/