magico13

Editor Time isn't used by more than a handful of people as far as I know, so there just hasn't been any pressure to work on it. If there's anything that really bugs you about it or any features you really wish it had just let me know. I usually try to prioritize working on things that people mention since I don't have time to work on every little thing I think of

Yep! Although it may not be working properly with the 1.2 version of KCT, I have a modlet called Editor Time that makes time still pass in the editor. It's super basic right now in that you define a multiplier in the config (1 second of real time is 10 seconds game time, for instance) and you can't change the multiplier in game (to time warp or pause while in the editor). Also, things like Kerbal Alarm Clock won't function in the editor, so you could miss an important event. I have ways to fix all those problems, I've just been working on other things instead. If you want to check it out, there's a link to the modlets in my signature.

Here's my personal stance, as a modder firstly and a player secondly. With CKAN and it's ability to make install lists, SpaceDock and it's ability to search (or similarly Curse), and the fact that pretty much every mod has a thread here on the forum, I see no reason for mod packs to exist. I fully support the idea of mod lists with links to each mod's forum thread and additional configs or installation recommendations provided by the list maker. If they want the players following the lists to use specific versions with known compatibility, then they can just mention that in their list. It's less work for the list maker and modders don't need to worry as much about random outdated versions existing somewhere they don't have control over, which is better for the players as well. Look at Realism Overhaul and/or RP-0. Those are basically "mod packs" in that it's a whole set of mods with huge amounts of config changes to make everything work a specific way. It uses CKAN to make it reasonable to install and players can get fixes for individual mods without having to set up the whole thing all over again. As a modder whose mod was in RP-0, I've actually added extra functionality at the request of those creating and using RP-0 and am happy to help diagnose any issues people encounter. In short, mod lists = awesome and mod packs = unnecessary.

Right, I remember this issue. I know why it happens, but not how to fix it yet. I'm working on something else right now but I'll try to swap over to this soon. If you're interested, the why is that the "Assignment Verification" checks are failing because the kerbals are still technically assigned somewhere, but in some parts of the code they've been set back to available. When it fails the game just goes "Well, I'm getting conflicting reports so they clearly exist nowhere!" That verification is a rather new thing and means that I need to fully update their status so the checks pass. As of right now, I don't know the correct way to do that, but I also haven't spent a whole lot of time debugging it yet. Regarding FMRS, LGG and I just talked and I'm going to make sure that SR still works alongside his update to FMRS. There's a chance that we'll have a bit more compatibility between the two as well, so that SR can recover anything uncontrolled (previously RealChutes were still handled by FMRS even if there was no probe core) while FMRS handles controlled vessels.

FAR uses a slimmed down version of RealChutes for all parachutes, so it's possible it didn't convert over appropriately. Do the LETech parachutes actually work better than the stock chutes when FAR is installed? If the chutes aren't converted at all then if you're combining the "stock" (converted to RealChuteLite) and LETech chutes then SR might only look at the "stock" ones and ignore the LETech ones completely.

StageRecovery only activates on stages that are about to be destroyed by KSP because they're outside of physics range. That means it won't do anything on stages that are still loaded (within 22.5km of the active stage). In your video you don't go far enough away from the dropped stage for it to unload, so you'd have to have those parachutes deploy on their own and you'd have to recover that manually. Instead try a craft that has two stages of boosters (preferably the next size up so you can get definitely get far enough away) and you should see that the first stage is recovered by StageRecovery. Let me know if you're still having problems. For stages like that where they're close to the ground and might hit before being unloaded, try setting the deployment pressure to 0.4 or 0.5 on the parachutes and staging them when you drop the stage so that they'll deploy on their way down. If you've got one (or can get one easily) I'd like to see a log of this. As mentioned a little higher up on this page, StageRecovery's method of using heat shields is very, very approximated and pretty arbitrary.

Hmm. I may look into that but it'd be an after-release kind of thing. A lot of work for a "nice to have" rather than a "need to have" when the current system is plenty functional, just not as cool. It's something that someone else could try to add in as well post-release. Edit: The build server is back up and running (mostly)! It's only got MagiCore fully working and the Modlets half-working (their GameData folders aren't in source control yet, so I can't autogenerate .zips yet). Adding in StageRecovery, KCT, and anything else will be trivial now since I can just copy an existing project. The hard part was getting the first builds running (building .NET projects on Linux is always an adventure). What this means is that any time I push code to GitHub, it'll automatically get built into a .dll that can be downloaded and installed. For full releases I typically have it be automatically packaged in a .zip file with a full GameData structure, but for small dev builds it's usually just the .dll (I may change that this time around). Not every build is really useable since I may make breaking changes between builds, but I will frequently tell testers to grab a specific build and it makes full releases much simpler and safer (multiple times I've released an update with the wrong versions of the .dlls in it...) Not having the build server has kinda sucked, so I'm really happy to have it running again. It'll make dev builds much, much easier to manage and I won't have to manually copy them over to dropbox and rename them so they have unique names.

I know I'm supposed to be working on this and/or ScrapYard, but for as a fun project to try to get me back into modding and KSP more I've been working on a rewrite of the simulation code from KCT as a separate mod. That effort finally reached the point where it actually sort of functions, although the UI is basically nonexistent and there's no real gameplay yet. I apparently forgot how difficult it is to get something to actually work: I spent the past two days trying to get it to load the backup file and change scenes... Expect more news on that at the end of the weekend. Assuming this effort has the effect that I'm hoping for of making me want to mod some more, and doesn't instead make me so frustrated that I don't want to look at code anymore, then I might try to get ScrapYard to a beta version ASAP (with KCT integration) and then move to a potential rewrite of KCT after that. IF, and it's a big IF, I attempt to rewrite KCT then I'm going to try to knock it out in about 4 to 6 weeks, with weekly progress reports and a publicly visible progress tracker so that you can all yell at me if I slack off. If I could time the KCT rewrite with 1.3 release that would be awesome. That's probably 4 to 6 weeks from now though (based on pre-release being in 2 weeks), and ScrapYard should be a higher priority.

Unrelated to probably all of the discussion, any chance we can get an .stl of that "Winner Kerman" trophy cause I'd love to try to 3D print that...

I thought KSP already had support for VR headsets, or maybe that was only by mod. Either way, KSP is only 3rd person because we frequently choose to play that way. You can fly entirely from the cockpit (I know, I have a 40 episode youtube series where any crewed missions had to be flown that way) and there are mods to make EVAs fully first person. I haven't used VR myself yet, but I imagine having the standard 3rd person camera would be a fine stopgap in scenes where there isn't first person until full controls were developed. I imagine vessel creation could be pretty nice with full VR support since it already uses a lego-like system where things snap together, but you could zoom in and have precise control over things. Really though, for flying it would be awesome.

Agreed, but out of scope for this. It'd require so much extra infrastructure for something that's basically just a visual thing. It would be cool to utilize Kerbal Konstructs for it, but I don't think that's something I'll do myself since there are many other things that are higher priority. I've definitely thought about it in the past though, and working with Kerbal Konstructs would probably be the best/easiest way to do it.

There's a dev version for 1.2 that's exactly that. The only reason I never fully released it was because there were a few things I wanted to fix up in it first, and then I got distracted by other things and haven't gotten back to it. I'm trying to get back into KSP again since I want to get back to modding, as it's hard to sit down and make mods for a game you don't play.

That search is actually what the tool I wrote uses to generate the list. Previously the list was updated manually. I believe @Endersmens is currently busy with things and I haven't worked on the tool at all in a while, so I'm not sure if it's still working. I've uploaded the code I wrote to GitHub in case anyone else wants to run it or update it themselves.

Yeah, the approximation that SR does is based on the drag cubes but is for whatever reason really off. It hasn't been right since 1.1.0 when I could still use the old aerodynamics for calculations. All calculations are done at sea level. I adapted the new one from RCS Build Aid so if they have their parachute calculator working in 1.2.2 then I'll have to look back at it to see where I'm going wrong. I don't know why real chute is off since I use the equation that I got from their code. They may have changed it recently, it used to be exact.

Yeah, at this point me working on anything to get back into it is a good sign. I put in a bit of work over the weekend on the part inventory but there's still a lot to go. I figured last night I'd try to port over KCT's old simulation code to remind me of how KSP mods are structured and since it's already written it'd be a quick way for me to finish something and get that good feeling when you finish something that can help keep you going on other, bigger, stuff. The part inventory is frustrating me a bit since I can make it work without KCT much easier than I can with KCT. Especially because I'm trying to make it so you don't have to use the part inventory, so no hard dependencies. The biggest issue is with how they remove parts from the inventory. A KCT ship does it when added to the build list, but without KCT it has to happen at rollout. At rollout I need to verify that KCT (or another mod) hasn't already processed it. The issue is that KCT assigns an id to a ship when it gets added to the build list, and KSP assigns an id to a ship when it's added to the world, but 1) those ids aren't linked in any way, 2) I don't think I can get KSP's id until the ship is loaded, and 3) it doesn't matter because I don't have the whole ship during the OnVesselRollout event anyway so I can't get either id easily. So I'm having them talk through a module applied to the root part where I can put an id for the vessel. It's goofy and I haven't tested it yet. I'm also adding in the individual part tracker, but haven't made the general part tracker. Or a way to actually take parts out of the inventory (the parts are a lot more specific than before and you have to take fully fledged parts out, not just parts by the same name). Lot's of hurdles still. The core is there though and technically works, but it isn't tied into anything and while functional, is not "playable". Btw, I just wanted to say that KRASH is still going to be the one recommended by KCT even if I port the old code over to a modlet. That's just something I'm doing for fun. I've been using KRASH on my playthrough and have liked it so far, though I haven't done anything crazy with it. Personally the funds counter going up continuously adds a bit of anxiety, though I can add a strict max if I'm worried about it. In some ways I still like the pay before method that KCT used to use, even though it would end up being more costly, but that might just be because I'm still used to that. I like the presentation a lot though, from what I've used.

I don't believe there's anything hard coded, but that doesn't mean there won't potentially be incompatibilities. There might be an assumption that there are three levels in there since (for whatever reason) building levels are given as a float between 0 and 1 and I need them as an integer, so I multiply. That would potentially affect any formulas that use the building level, and has a (lesser) possibility to affect the checking of restrictions (vessel size/mass, etc). I'd love to know whether or not it works properly since I'd like it to be general and not care about specific levels.

I've been wanting to port it over to a modlet anyway, so I started doing that tonight. It's like, maybe, a third of the way there. Without any systems to build off of it's a bit more complicated to set up. It's a little beyond a regular modlet since it will involve saving to the save file, a config file, and depends on MagiCore, but it will be almost identical to KCT's old simulations since it's a fork. Except I'm planning on using the contract configurator style of spawning vessels automatically in the right orbits instead of moving them like HyperEdit, which means antenna won't get ripped off if they're extended. I'd like to make it so you can restart a simulation with different orbital parameters in case you chose bad ones without having to pay all over again, for when you are testing with communication networks, but getting it working at all is higher priority. Edit: Actually, I just had an idea. It'd be a deviation from the regular KCT model but would solve the "I just bought a year worth of simulation time and forgot an antenna" issue. Instead of purchasing simulation time for a particular vessel and if you don't use it all it's wasted, why not instead purchase "Supercomputer Time" and each vessel has a Complexity, where a more Complex vessel requires more Supercomputer Time per unit of time inside the simulation. Then you purchase Supercomputer Time and can allocate it however you want (a bunch of smaller vessels, a big vessel for a short time, a small vessel for a really long time, etc). If you forgot an antenna, it's no big deal since you can just revert and only use up a small amount of time. Note that this is pretty similar to how actual simulations are performed, except that issues aren't always noticed right away

The simulation system was removed because KRASH does it better and then I have less to maintain. Similarly, KCT used to have a parachute based recovery system for the inventory which got forked into StageRecovery. StageRecovery got to the point that KCT's version was just crappy in comparison so I removed KCT's and just use StageRecovery for that ancillary feature. 1.2 added a change to parts that wasn't going to be able to be handled by the previous part inventory: part upgrades. That, combined with the handful of hacks that I made to get other mods supported (TweakScale, Procedural Parts), made it so the part inventory really just needed to be rewritten to handle all of these situations and more.

The whole system is just a very rough approximation, but I'd set the DRMaxVelocity setting to the point where you think stages would start to have a chance of burning up (that's all the setting is). Keep in mind that no atmospheric drag is modelled on ships outside of physics range, but speed increases due to gravity still happen, so it's fair to boost it a bit. For stock it's 2000 m/s, which is just under orbital velocity. Since stages are processed in stock at 24km altitude (about a third of the way into the atmosphere), a nearly orbital stage will come in at around 2200 m/s and have a chance of failure, but anything dropped in atmosphere should be fine. Something dropped in from a Munar orbit would be closer to 3 or 4 km/s and would either need heatshields (they only add protection up to an additional 50% of the DRMaxVelocity, so 3km/s for stock) or manual aerobraking passes to drop them to a lower speed. You mention that 6500 m/s is about a tipping point, so either that or maybe 7000 (since no atmospheric drag is applied) is a good value to raise that setting to. As always, if it's something you truly care about recovering, do it manually.

Well, the good news is that A) KSP is a single player game so you don't have to use those features if you don't like them, KSP is about personal goals and challenges after all, and B) you already can disable them, just change the settings to turn them both off. Personally I just never use either of them, they were just things people wanted to have the option of doing and the default Preset has everything active by default so that people can experience any aspect of the mod without having to go into the settings screen. If your concern is for a publicly available challenge where you want everyone to use the same settings, or you're just interested in how unbelievably configurable KCT is, I highly recommend reading (or at least skimming) the three pages on the wiki discussing Presets, starting with the Overview page, then the internals page, and finally about the math parser and built in functions. In general in the past I've tried my hardest not to remove anything from KCT but instead to add community requested features as options. This allows for continuously increasing numbers of play styles to suit any type of player, from the casual "I just want to not launch 20 ships and land on the Mun and still have it be day one" to the hardcore "I want to precisely match the evolution of rocketry from the 1960s until now (aka RP-0)" I will admit that I haven't seriously played KSP since around 0.90 so I'm not sure how balanced things really are anymore. That's also why this mod has been ridiculously stagnant. Btw, you'll want to set ResearchFormula = "-1" and UpgradeScienceFormula = "-1" to turn those features off completely. Then either just save, or save it as a new Preset so you can use it in other saves or back it up for later (or sharing. Everybody loves sharing!)

Should be the same as before. But without the inventory, build times when editing might still be a bit off.

It is quite buggy sometimes and doesn't always reset things that should be reset (though that can be fixed by adding some things to a config file, there's a tutorial on github). It works best with stock parts and can be basically useless with things like procedural parts. KSP doesn't really support going from a fully loaded vessel back into a craft file, so things can get pretty weird.

The recover to storage option still exists, which should allow airplanes to turn around really fast. Just make sure to edit them so they don't point straight up on the runway.

Well that's certainly weird. I haven't actually gone through the log yet but I'll try to do that tonight. The SPH and the VAB are the exact same thing so I'm not surprised it's doing it in both

You're only seeing that in the VAB? Hmm. That's the function that updates build progress as time passes. In the VAB it checks the time a different way (since my EditorTime modlet allows time passage in the VAB/SPH) so that could at least partially explain why that's happening. If you get a chance to test it in a new save I'd be curious if it happens with no ships in the build queue and with just one (or a few) ships in the build queue. I am wondering if it is somehow specific to a craft that's queued up, if it happens for any craft, or if it is totally independent of any crafts in the queue.