magico13

Hmm, that definitely would pose a problem since right now you'd have to define the number of ignitions as a constant for all of them, which isn't what you want. You could omit the ignitions so that the number still decreases each time and require the player to manually replace the engines when they get too low, but that's got it's own problems as well. I'm not sure what a good solution would be and it's a specific enough situation that I either don't want to spend too much time focusing on it, or I want something generic enough so it can be used for other things as well. I'll need to think about how to solve this problem. It's either allowing contextual replacements (parts with name "x" get this module replaced with "y" template) or maybe something with module manager. I don't know if I could easily make it affect construction time with how the formulas work right now. I don't want to hard code in an "ignitions" variable, but that does make me really want to have a way for other mods to define variables and their values. At worst I then could create a .dll that integrates RealFuels and KCT and just adds that in to the EffectiveCost Formula. The formula would have to be modified to actually use that variable. That'd be a pretty major refactoring to get working from the KCT side... I have tentative plans to rewrite KCT, so that's something I will keep in mind for that for sure. I'm not sure it'll make it into this incarnation of it. I'm writing up an issue on the MagiCore github for it, since if I can implement it there then it can automatically apply to all my mods. I think I could actually do that easier than getting KCT to do it, since I can just have it raise an event that sends along the variable dictionary and lets the listeners add their own variables. That's definitely a worthwhile solution.

How midwest are we talking? I live in Ohio, but spent two years in Illinois working on a Masters, so I'm already somewhat midwest I'm still trying to figure out where I'm gonna go for the solar eclipse this year and am thinking southern Illinois so I can visit some friends on the way there who are still working on their PhDs at the school I went to.

As many of you may know, I've been working on modding and KCT in particular for the better part of three years. While there was a certain degree of responsibility to the community to create and update mods, I always created mods that I wanted to play with in my own games. Having not played much, if at all, since 0.90 I felt no compulsion to work on mods except for the community. It was something I poured literally thousands of hours into with no expectation of getting anything in return. That's not changing, I'm still going to be making mods because I find enjoyment in it, and I'm taking time to just play my own save every now and then to help me stay involved. However, if you feel that my modding efforts are something you want to contribute to while giving me additional incentive to pour my evening and weekends into making mods, and you've got some spare change you don't mind parting with, I've started a Patreon! I'll never earn enough making mods to pay my bills, that's what my full time job is for, but at the very least it can help offset some of the time I spend working on mods. My mods will always remain free and this is purely voluntary. If nobody contributes, that's fine, I'll still keep making mods I like to play with and releasing them for you all! Click the image to go to my patreon page. If you decide to become a patron, thank you! And if you have any ideas for goals or rewards, please let me know!

Well, I've made a Patreon now. If you have ideas for rewards or goals then let me know. The current ones are subject to change. For anyone who does contribute, thank you in advance! http://www.patreon.com/magico13 Day later edit but I don't want to double post: I just made a build because of a WIP update to MagiCore that I'd be wary of using with any other mods that reference MagiCore (of released things that's currently just Sensible Screenshot and Dated QuickSaves I think). They shouldn't have been affected since the methods they use weren't modified, but it's something to be aware of. The reason for this change is that if you've got a mod and you want to add your own variables to any formulas, there's now an event called onMCVariableReplacing that sends an identifier for the formula (like "KCT_BUILD_RATE") and a dictionary that you can add your variables and their values to. Then after the event has finished the replacement occurs, so another mod could easily add new variables or change existing ones if they wanted, without referencing KCT's assemblies at all. Combine that with a Preset and another mod could conceivably completely override KCT's own processing of pretty much everything without ever referencing KCT in code. Which is pretty awesome.

There's almost zero chance it'll be for 1.2.2 (unless they sneakily snuck the required API calls in). Best chance of supporting old versions would be a 1.2.3, but that's just extra work. 1.3 (or possibly later) is almost certainly going to be required.

Looks like it's going to be more than contracts. I'm guessing it'll be something closer to Mission Controller, perhaps more like the original one which was a bunch of missions (and a mission builder) and didn't involve contracts since they didn't exist yet. I'm hoping it'll be like Mission Controller on steroids.

From a purely hypothetical perspective at this point, how do you all feel about Patreon? I know other modders have had some success with it (linuxgurugamer and RoverDude to name some that I know of). It's never enough to actually cover bills, but it's a solid commitment tying me to supporting and improving my mods (other than "because I want to play with them") and would help justify spending entire evenings and weekends on modding. I'd want to do something fun with it too, like have a stretch goal of having monthly live streams or something like that. Or like with CKAN where different levels get you different things, like access to the lolcommits. I have no idea what I'd actually do for those though, so if you have ideas let me know. At this point I'm just gauging opinions by you all. There's certainly less of an audience here than the other threads, but anyone reading this is also likely more involved with mods than in a release thread.

I'll do you one better. Don't actually grab a bunch of files from here, but here's a mirror of the whole dump hosted on my personal server. Browsing is fine, but don't download the whole thing. It may take a little while before they're all there since it's copying from a different directory in the background. Edit: It occurred to me that I probably shouldn't make this link publicly available due to potential license issues. I'll PM it if you didn't save it. You should probably edit it out of your quote of this post.

Here's the link to the dev thread. Mostly ignore the text, it hasn't been updated in a while. The files themselves are hosted on my build server. If I remember correctly, the KerbalStuff dump is sorted by author, then by mod name, as a bunch of folders. With every build they uploaded. I don't remember if it was everything, or only things that allowed redistribution.

You could always get it close and then hyperedit (or manually edit the save file) it into perfection. I wouldn't call that cheating personally. I recommend not hyperediting the active vessel, since with physics running on the vessel it won't stay perfect, but unloaded vessels should remain virtually perfectly placed as long as you never load them. Even if you do, the changes to the orbit would be minor, but over a large time they'd get messed up.

KCT's presence in this list is an interesting subject. Technically, the last official release is for 1.1.3 and there isn't a full release for 1.2.x, though there is a "beta" build with missing features for 1.2.2. That exists for a few reasons, namely that I had a few things I wanted to do for 1.2 before release, I had to cut out a bunch of core functionality due to KSP changes, and I had completely lost interest in KSP and modding (haven't not seriously played since 0.90 or so) so I was basically gone. I'm actually back now and am actively working on a few things, including two new mods and updating KCT. At this point I don't plan on updating KCT officially to 1.2 with 1.3 being so close (I also really want to get the part inventory back in). I also might completely rewrite it in the next few months. I guess what I'm trying to say is that I don't really care if KCT is on this list, I'm just unsure of if it should be on the list. If it meets your criteria then feel free to keep it on, I just wanted to make it clear that I am actively working on it and supporting the "beta" build again. I believe I also have the KerbalStuff contents saved as well. There was a period of time where it was all up as a torrent so I made sure to grab it since nobody knew what was going to happen for a little while.

StageRecovery has been officially updated and the links on the OP have been changed to point back to the build server instead of dropbox links. As a result, you don't have to grab the old release and pop the new .dll in, instead you can just grab that and it will have the latest MagiCore and all the required files. I merged in the PR from a while back that removes a bunch of simulation related code, but haven't made any changes myself yet. I'm going to look at Custom Barn Kit tonight. Edit: @Streetwind, @thunder175 Would either of you be willing to test out the latest build (#5 or later, from here) with Custom Barnkit? From my testing it doesn't appear to break everything horribly anymore, but I think the last tier isn't getting the right model for some reason, but it could just be that my CB config isn't correct since I've not used it before. Preferably test with and without having KSC build times active and in a save you don't care about (a new one or a copy)

I pushed out an update based on the last pre-release. It should greatly improve Kerbal recovery (since they actually show up as recovered) and should work nicely with the new version of FMRS. I highly recommend checking FMRS out if you want more control over recovery!

Tree Toppler has a "Disable Costs" option that can be used to unlock individual nodes. It's be more clicking since you still have to click the nodes, but doesn't require spending any science. For nodes that you aren't able to unlock through the Stock buttons, Tree Toppler adds a "Force Unlock" button in the top right when a node is selected that allows you to force it unlocked. You could just use that and unlock the next node after you've unlocked however many parts you feel is appropriate.

Unfortunately I bought KSP on June 8th, 2013 (and then again on May 7th, 2014) so I won't be getting this for free. It sounds interesting though and if it's done well then it could be cool. It'll be interesting to see what happens from the mod supporting front if the code paths between base game and DLC game diverge at all.

Hey, if you get a chance and are up for it I've got a pre-release I'd love for you to try out that should fix this issue. Check out this post:

Anyone feeling particularly bored and want to test a few things for StageRecovery? Two main areas need to be tested: Integration with FMRS and kerbal recovery (both through pre-recovery and old-style post-recovery). It's also a test to make sure the build server is producing functional builds, since for a while it was making builds that wouldn't actually load despite compiling, Get build #14 (or later) from the build server (just download the StageRecovery.zip file under "Last Successful Artifacts"). As always, I'll need logs. If you don't know what logs, check this post. The wrong logs probably don't help and snippets pulled out of logs really don't help either. FMRS testing: If FMRS isn't installed, SR should work as normal. If FMRS is installed but not armed, SR should work as normal. If FMRS is armed, handling parachutes, and hasn't deferred to SR, then SR shouldn't do anything at all. If FMRS is armed, handling chutes, but has deferred to SR, then SR will handle chute only stages and FMRS will handle kerbal/probes. FMRS armed, not handling chutes (deferred doesn't matter), then SR handles chutes and FMRS gets kerbals/probes. Outside of flight scene, SR should handle everything. Kerbal recovery testing: Both pre-recovery (where the kerbals are recovered before the stage is destroyed, by SR guessing that the stage will be deleted) and normal SR styled recovery (where the kerbals are recovered after the OnVesselDestroyed event is fired, when everything else is handled). Whether Pre-recovery is enabled is now a setting you can change in-game. Ensure that any kerbals recovered by SR appear in the Astronaut Complex as available and have the flight added to their flight log (they get XP as expected). I'm curious if contracts will still fail (like tourist ones). Probably, but if someone tests it then let me know the results (ideally with and without pre-recovery active). Some notes about pre-recovery. Below 25km altitude it's basically the same as regular recovery. It's still worth testing there but it isn't as big of a deal. The best point to test it with is dropping something suborbital from 30+km altitude while still continuing on so the stage unloads above 25km. That will cause it to get added to the watch list, then SR will wait for it to just about be destroyed and pull out the kerbals, then when destroyed it associates the kerbals and either recovers them or lets them die. Contracts might not fail here, since the kerbals never actually die. With post-recovery the kerbals are killed and then resurrected when the stage is processed, which will fail contracts but has the kerbals available at least. Btw, pre-recovery has been active for a while now. The option to turn it off is new though. It sometimes has issues with firing at the wrong time and just randomly stealing kerbals out of ships and killing them. Naughty kraken.

He didn't miss the point, he's just trying to explain that what you're asking for is based on a misconception of how you think StageRecovery works. Put simply, StageRecovery never, ever, destroys anything. Ever. (Ok, the one exception is launch clamps). StageRecovery is entirely reactive (except for recovering crew) in that it does NOTHING until KSP deletes the vessel from the game. If StageRecovery pops up a message about a stage, that means that KSP has already destroyed it (you can check the logs, they'll say the stage was destroyed even with StageRecovery). All SR does is intercept that event from KSP and check the vessel, if it seems reasonable that it could have landed then SR pretends it did and gives you back the funds, science, and crew that were on it and returns it back to KSP which happily continues to delete it from the game. For KSP to delete it, it just has to be below about 25km altitude and 25km away from the active vessel. Anything meeting that criteria is gone forever, whether SR is installed (or active) or not. If you could choose to turn SR off for a particular vessel, rather than on a per-save basis as you can now, all it would do is still cause the vessel to be destroyed by KSP but you wouldn't be told anything about it. It would just cease to exist. FMRS is really cool though and might be what you're asking for. It uses weird save file splicing to let you jump back to when you decouple something so that you can fly it down, then merge that save into your primary save so that it's like they all happened at once. But with FMRS you have to fly everything down yourself, which is boring for parachute based things. SR saves time with approximations, FMRS allows for realism and precision at the expense of tedium. Personally, the best bet is a combination of the two. Which is what I'm working on right now. FMRS recently had some options put in to defer parachute only stages to SR, which I am reworking SR to behave properly with. That way you can have any of the following combinations: 1. FMRS turned on and stages with probes/kerbals on them. FMRS handles everything and you can fly them all down manually. 2. FMRS turned on and stages with just parachutes and chutes not deferred to SR. Same as above, FMRS handles everything. 3. FMRS turned on and stages with parachutes deferred to SR. FMRS handles anything with probes/kerbals, SR handles parachute-only stages. 4. FMRS turned off. FMRS handles nothing at all, SR handles everything including probes/kerbals. FMRS can be enabled/disabled on a per flight basis, so you can easily swap between letting SR handle things when you don't care that much and just want to save time, or handling everything yourself when it matters if you've landed back at the launch pad with your kickass kOS program. Edit: That FMRS stuff is now in a pre-release that can be gotten from this post:

That might have been why it was infinite. Except that based on what you're reporting I'm not sure it would work correctly anyway.

As @Loren Pechtel mentions, if you don't want something to get recovered, just don't make it recoverable. If it's got no chutes and no fuel+a probe core, then it won't get recovered. For a comparison with SpaceX, it's the difference between leaving fuel left in the first stage for a landing or using it all up for an expendable launch (like the one tonight will be).

It is intended. The rollout and reconditioning are both linked (they're internally the same thing) and reconditioning of the pad takes less time for the more basic launch pads. It's reasonable that the facilities to put a rocket vertical are simpler at a more basic pad and require less time. If you want to disable that, just remove the "/ (3-[L])" from the reconditioning formula. In fact, that's probably why the rollout goes to infinity, since a 4th level launchpad will have [L] = 3 and you're dividing by zero. But it sounds like Custom Barnkit is completely incompatible with KCT right now. I'll try to look into it, but it'll be a while from now.

As of right now it specifically checks for the regexKSP.KSCLoader class. I could have sworn there was a version of KSC Switcher for 1.1 at least, maybe not updated by Regex though. If there's a new mod that does the same thing I should be able to update KCT to use it fairly easily.

The intent in the original message was for additional launchpads at the existing KSC, not at different locations. Kerbal Konstructs would just be used to load in the models (if new ones had to be made) and make them functional launch sites. Funny that you mention KSC Switcher though, KCT is compatible with it already! Each KSC is treated as independent with regards to build queues, vessels stored, and upgrades spent, so you could have multiple launch sites each building things at once, and could have one specialize in planes while another specializes in rockets. There's a general setting in KCT to switch between each KSC having it's own full set of upgrade points (ie, if you have 20 upgrades earned then each KSC can allocate 20 upgrades) or for them to all share a pool (so one KSC might spend 15 of those upgrades leaving only 5 left for another KSC). KCT was part of RP-0, which is the career mode version of Realism Overhaul, which uses KSC Switcher.

Sorry, I meant "can we" as in "can the moderators/the rule" be explicit in what is required in the document. Section 3A in the WIP rules is pretty explicit already, so my concern is unfounded. I just want to make sure it's clear what is required, and that what is required is sufficient with regards to attribution and ability to find the correct mod and version. E: I see though that you're saying that mod authors could amend 3A to include additional provisions when including their mod in a mod pack. I agree with that idea. E2: I just had another thought and don't want to double post. While having an open license that allows redistribution doesn't prevent the modder from having their mod redistributed (for obvious reasons), it doesn't imply that the modder must provide support. That's something modders provide for free and is often explicitly indicated in the license that no support is required to be given. I'm just thinking out loud about whether modders can (and the associated "whether they will") detect if their mod was installed with a mod pack and refuse to support users of that pack. Frankly, from an informational support perspective it would just be nice to see if they installed it through a mod pack so that I can see if that pack is somehow causing extra problems. But I think back to the mods that were created to stop certain functions of other mods, or authors refusing to support their mod if it was installed with CKAN (the first is questionable, the latter is definitely within their right as they can refuse support for any reason) and I worry about another divide where even though something is technically permitted, if it's unwanted then people will develop means to fight it. I am on the fence as to whether I like the idea of mods detecting if they're installed in a pack (perhaps by checking that document that we're requiring), whether the rules should explicitly require that document to exist in the install in a specific spot to make it a well defined process for modders to check this, or if we should somehow discourage preferential treatment by how the mod is installed. Maybe a good solution is that the rules for reporting a bug include reporting 1) if the mod was installed through a pack, 2) if from a pack, include the name and version of the pack, and optionally 3) a link to where the pack is hosted (the forum thread if hosted here). Of course mod authors could require this even if it's not part of the general bug reporting guidelines since, like previously mentioned, support is at our discretion. The only problem is that most people don't follow those guidelines (or even read them) and any additional guidelines mentioned in a mod's OP are ignored even more often. Personally, if my mod is added to a pack and starts getting more support requests I likely would start checking for that file just for my own data collection purposes.

Your concern is that outdated mods don't work in newer versions of KSP, but I present a counter concern of newer mods don't work in older versions of KSP. I'm fine with the pack having an intended version that is publicly visible. I am also fine with the mod list being in spoiler tags just so the OP isn't huge. It's still publicly visible and credited. Can we be explicit in what is required in the document that is included with the pack, and maybe require that the document is in the root of the archive (or one folder down if the root is just a single named folder other than GameData, like "My Awesome Pack").