magico13

Was this craft built with an older version of KCT and not launched until now? Can you upload the save file too? I'm wondering if something got messed up in the craft info. I don't understand what you mean. Do you mean when you alt-tab out of KSP? There might be a KSP setting to "simulate in background" or something like that, or using a borderless window might work, but otherwise I don't know of anything. I found this short thread which mentions that in the space center scene time will stop if you alt-tab, but not in flight or the tracking station. - - - Updated - - - Sorry, I must have missed this post earlier. When you open the KCT settings in-game and have the option to change the max warp, what does it say? If the thing you're trying to warp to is completing fairly soon then it won't go to the max warp. I've made a note on GitHub to take a look at the warp down code. I wonder if KAC switched to using the Stock "Warp To" system, or if they just rewrote that code. Either way, I'll try to get warping to take minimal time for the next update.

I bookmarked that thread last night actually, and NathanKell and I frequently chat on IRC As for orientation, if I can get the center of drag as well, then I can assume the vessel is oriented parallel to the vector between the center of mass and the center of drag. For uncontrolled vessels that's the most likely orientation, and for "properly" designed rockets and planes that's also pretty likely. I've looked through some of the documentation on the drag cube system, but I'm not 100% sure on how to get what I need from it. There's still the issue of the ratio of "amount of effort required to implement" to "gameplay advantages", and there are still many other projects that I'm working on that have a higher ratio. For instance, last night I wrote some code to calculate the estimated terminal velocity of every stage on a ship in the VAB separately and figured out how to highlight the parts green, yellow, and red depending on if they'll land below the velocity cutoffs. So that will make constructing vessels that can be recovered automatically much, much simpler. Powered recovery requires a probe core/pilot kerbal and engines with fuel and a thrust to weight ratio greater than one. Parachutes are optional and make it require less fuel. Non-powered recovery requires parachutes, no probe core or anything else is required, nor do they have to be deployed (exception: if you drop the stage below 5km, set them to deploy at 0.5 pressure and stage them with the decoupler. If you drop them between 5km and 10km you might want to do the same. Above 10km you don't need to deploy them. The reason for this is because you might not leave physics range before they hit the ground if you drop them very low, but once you get to 10km you're probably moving fast enough that they won't hit the ground before unloading)

I think I've seen the specific error that's breaking things for you before. I believe the issue is solved by going into the VAB before trying to launch a vessel (at least once per KSP session, but you shouldn't have to do it every time). I'm not 100% positive about that though. Try it, and if it doesn't help then I'll take a look again. [EXC 19:06:34.165] ArgumentNullException: FacilityName is not a valid Space Center Facility name! Parameter name: pSystemFacility EditorEnumExtensions.GetFacility (.SpaceCenterFacility pSystemFacility) FlightDriver.Start ()

Deployed parachutes would be detrimental to the overall horizontal distance you can travel. The way you'd reduce distance would be to thrust as soon as possible to alter the trajectory toward the KSC, overshoot to account for atmospheric drag, then suicide burn/deploy chutes when near the ground (< 1km). You're welcome to take a look at the code on Github if you want to try to make sense of any of it. Most of the "work" is done in RecoveryItem.cs. Terminal velocity is only calculated for craft with parachutes. In pre-1.0 atmosphere it was also calculated, since that didn't depend on orientation. These stages are typically uncontrolled, so I can't make any assumptions about orientation of the vessel (the two I'd even consider are "forward" or "the last one", both of which aren't correct most of the time). The real problem with calculating the terminal velocity is that I don't know the coefficient of drag (Cd in the formula) and I haven't figured out how to calculate it for a particular vessel. But we run into the orientation problem again, as Cd is orientation dependent. Airbrakes can't be included in calculations until I figure out how to get a reasonable Cd for a vessel. Wings can't really be included until I can get Cd and Cl (coefficient of lift). It's not the calculation of the formulas that are giving me problems, they're all very simple, it's getting the vessel dependent values from the game and in a way that makes sense in a totally generalized manner (every stage is treated identically) so that I can use them in the formulas. And yes, powered landing requires a point of control (otherwise how would it orient itself properly and know when to fire the engines?). By default it requires a probe core with SAS capabilities or a Pilot kerbal. Basically, it requires SAS to work. There's a way to disable that requirement so that any kerbal or probe core will be enough, but a point of control is always required. And about 300 m/s of atmospheric delta-v (if you add parachutes that goes waaay down).

Let's see if I can answer everything sufficiently This mod only activates when a vessel/stage/thing is destroyed by KSP for being unloaded in the atmosphere. The conditions for that are roughly: >22.5km away from the active vessel, <23km altitude on Kerbin, not landed. Once the vessel is destroyed, StageRecovery checks if it has enough parachutes to land slowly and/or an engine with fuel and some sort of pilot to try to land with engines. If it can be recovered, SR "recovers" it. The recovery is a custom written one, so it sometimes has problems with things such as contracts. If the thing you drop doesn't leave physics range or you focus on it, StageRecovery won't do anything with it. This mod is compatible with Kerbal Konstructs, but will only allow recovery on Kerbin or Earth (if using RSS). With RSS there may be issues with the distance calculation not using the appropriate launch site. With Kerbal Konstructs the closest open launch site should be the one used for distance calculations. Yes, this does powered recovery. I, and nobody else, is sure why Scott said it doesn't, because it has clearly said that it does have it since long before he made that video. Check the first post for the requirements for that. Always trust the official sources more than an unofficial thing mentioned by a youtuber. Last I checked this is compatible with FMRS as I explicitly added support for it. The way it works might seem a bit quirky, but I don't believe SIT89 has been active lately so I can't make them work together any better until he's back. Here's a rough guide for how it works: if FMRS is disabled, StageRecovery will try to recover it (overrides all the things I'm about to mention); if it has a probe core or a kerbal, FMRS gets to recover it; if it has a RealChutes parachute then FMRS gets to recover it; if it has a Stock parachute then StageRecovery gets to recover it; if it has no parachutes or kerbals or probe cores then StageRecovery will politely tell you that it was destroyed because nothing could recover that Currently powered recover just assumes the fuel is used to stop safely (and inefficiently, a manual landing is more efficient) and doesn't adjust the distance. I have been thinking about using any extra fuel to try to reduce the distance as well, but haven't come up with any solid plans for how to do that. Part of the issue is that SR just uses the position at destruction and doesn't calculate the final landing position (the atmosphere makes things tricky), which would be a prerequisite for trying to adjust that final position. Gliding recovery would be not too hard if I knew the coefficient of drag and the coefficient of lift for the vessel, since then you can compute the glide slope and plug in the altitude and get a rough estimate for how far you can go, but I don't know how to access those variables for a particular vessel and they're dependent on the orientation. It boils down to "these additions are a lot of work for only marginal gameplay gains", so they're low priority. I have other projects that have better gameplay returns for the same amount of work, so those get prioritized first. Thank you for the link though. I'll bookmark that for later.

Nope, speed only ever affects the speed %, and distance only ever affects the distance %. There may have been some discussion about gliding recovery, where with enough wings you could glide some distance back (and thus reduce the distance %) but that isn't implemented since I don't know an easy way to calculate the coefficient of drag and the coefficient of lift on a vessel, especially one that isn't physically loaded into the game. Parachutes will not ever reduce the distance %, but wings and engines might in the future (but do not currently). Hopefully that clears things up a bit

I'd guess those are multipliers applied to transactions using VesselRecovery as their TransactionReason, with minValue being at the lowest strategy level and maxValue at the highest.

Speed and distance are both factored separately. Distance can only go up to 98%, which is what you'd get from manually landing at KSC (the runway and launchpad are exceptions and are handled differently). No amount of parachutes can improve the distance measure. I have never tested the Recovery Transponders strategy, so I'm not sure if SR works properly with it. Assuming it just modifies transactions with the TransactionReason of VesselRecovery, then SR should automatically work it. If it modifies the actual recovery code, then SR doesn't support it because SR has a custom recovery.

Hmm, I was a little afraid that sort of issue might happen. StageRecovery doesn't use the normal recovery mechanics and isn't able to prevent the death of a Kerbal, it brings them back to life after the game kills them. I'm not sure if there's a way I can get around that problem. I have an idea, but it will require changing a non-trivial portion of the StageRecovery recovery mechanics. I might be able to prevent them from dying by recovering them separate from the rest of the craft, prior to the craft's destruction, which should fix that issue.

Kerbal Alarm Clock integration already exists, I just haven't fully fleshed it out yet. If you have KAC installed and you have the setting to create alarms enabled then the next thing to finish will have an alarm automatically generated (while in the Space Center scene at least). You can't change the settings for what triggers an alarm creation (construction, reconditioning, etc), or what it does about timewarp (it currently reduces warp down to 1x). KCT was one of the first mods to use the KAC API when it was created, and I pushed for it's creation since I started working on KCT A button to set an alarm for any ship (perhaps auto-updating if build rates change) and finer control over the alarm creation are two things I should add soon.

A color change is (probably) doable, but not necessarily useful if you always keep something in storage. What do you think about putting the number of completed builds in parenthesis after the name (ie, "VAB (2)"), perhaps with an added color change if a vessel is rolling out/is on the pad (yellow and green).

I believe loans are being handled as normal Invoices, in which case you don't pay them off separately. Negative numbers in the payment field currently are implemented as "Pay the maximum possible". We should add the option to pay off some of the remaining balance on a loan above and beyond the required payment, so I'll make sure that's included somewhere. Loans will likely have their own GUI in addition to the main BROKE GUI.

I wasn't even aware loans were implemented yet (I haven't worked on that code at all), nor am I aware of how to even take out a loan. That doesn't sound intentional though, so hopefully jkortech sees this and can confirm. Consider loans to be very WIP at the moment.

The eternal question Apparently the answer is no. Enneract, the author of CrewQueue has added code into KCT a few times to add support, but then declared it not working how he'd like. The code is there, I think it's set to run, I have no idea if it does anything though. I've asked on the thread about what I need to do to add support (2 weeks ago), but haven't gotten a response yet. I'd like to add support, but I have no idea what I'd need to do. I might try to do it anyway even if I don't hear anything back soon.

I do agree that RealChute can be a bit complex for basic things, so I can understand why you'd elect not to use it. I won't ever not use it because I like setting up my chutes to work perfectly for the payload and thus save on mass, cost, and guesswork. Everybody has their own playstyles and preferences though, which is why I like the KSP modding community: options for everyone! I've opened an issue on GitHub to remind me to look into adding support for TweakScaled parachutes. Skimming through the code I'm not 100% sure why they aren't already being supported, so I'll need to do some research into how TweakScaled parachutes actually work.

I can certainly try to add that, but I personally recommend RealChutes when you want any sort of custom parachutes. SR works better with RealChutes than it does with Stock chutes, and you can easily configure them to require a small number of chutes. I'll look into if I can get the total parachute area of tweakscaled chutes though, as that's what SR looks at for estimating the terminal velocity. With RealChute SR doesn't have to estimate anything, so that's why that works better.

It's not as nice since they added Kerbal classes since you generally want to pick a specific class, rather than a random mix of them. There's been some talk of trying to get it to balance one of each class in each part, but non-trivial effort for a fairly trivial problem.

Like I said, my best guess is a part that's somehow messed up, but otherwise the log wasn't telling me anything specific enough to know what the cause was Testing all those mods would require up to 16 or so individual checks, which I agree is quite a bit, but is certainly faster than a linear search! Hopefully reverting fixes it. Feel free to send me more logs if you want me to check them for anything. 1. Yep! If you've already switched to flight then just revert to the VAB and it will roll back time to when it's sitting on the pad but not physically on the launchpad. When it's in that state (post rollout but pre-launch) you have three ways to roll it back: roll out something else, hold the Mod key (alt in Windows) and the "Launch" button turns into "Roll Back", or press the "*" button and choose the roll back option. If you're feeling particularly dangerous and it's physically on the pad you can recover to the inventory by opening the KCT window in the flight scene and selecting the VAB or SPH tab. That last method isn't advised except for when necessary because it can go wrong, especially if any parts have been broken. 2. When you press the "Launch" button and there is space for crew you should be presented with the Crew Select GUI. If you see Jeb there you have three ways to get him out: clear all parts, clear just that part, click the big "Remove" button near his name. After removing a Kerbal, press the "Add" button (takes the place of the "Remove" button when the seat is empty) to select which kerbal you want to put there instead. Alternatively you can do what I've seen someone do because they didn't realize there was a button that let you select the crew member for that seat: turn on random filling and keep clearing/filling until it gives you the crew you want

Crowd-source the descriptions We're a group, not a list! We can do group things! I've been considering writing up a website that always shows the latest group, with the ability to submit descriptions for members who don't have one yet (which are then reviewed before they're accepted), just for fun. For keeping it here on the forum I'd recommend setting up a spreadsheet through Google Docs with three columns: the group member who needs a description, the person who has volunteered to write a description, and the description. If no one has volunteered, people can write their own names down, and when they have a description written they just paste it in. Then all you have to do is copy the name and description into the Descriptions file. Definitely set up the spreadsheet so that anyone can write to it, I think we're all pretty responsible here. I still might write up that website, it'd be fun

It should be set up so that if you leave the window open when you leave the space center, it will be open when you come back. It might also depend on if it's open in the tracking station and/or flight, I'd have to double check (I think the state is synced in the tracking station, but it shouldn't be in flight). Otherwise if you click on the launchpad or the runway it should open up the KCT window to the VAB/SPH tab automatically, if you don't want to use the button (or can't find it because the list is too long). I think those two properties combined should make it a little easier, but if you'd still like I can add an "Always open in Space Center" option @MisterFister, I'm not quite sure what to tell you. The error appears to be in the Research and Development part of KSP, which is pretty unusual. It seems you've got a corrupt part, maybe? It definitely appears part related, but that's not an issue I've seen before. It also appears to be messing up the contracts system. Cacteye is always mentioned right after the error, but the error isn't telling me about any mods or parts in particular. You might need to do a binary search of your mods to figure out the culprit (but keep KCT in there each time to check if you still get the error message. Alternatively open the log and search for "ProtoScenarioModule.Load" (w/o quotes). If you see that, the error's still there.

Where this mod is designed to excel is for things that happen periodically in time, such as every quarter or year. You, or someone else, could certainly set up a Funding Modifier that's used alongside a part mod or alongside a plugin where you give up resources and in exchange you get funds every quarter. If you want just a plain exchange, it might be simpler just to write a mod that gives you X funds for every Y fuel you sell (with some modifier M), ignoring any periodic time elements. I might be able to write up a very basic modlet for that, if you'd like. Something I've been considering writing up for BROKE (as an optional FM) is a full stock market where you can buy and sell shares of each of the major Corporations and/or resources. The more Rockomax parts you use without blowing them up, the more their shares go up, but if you blow up a few rockets that use those parts then shares drop. Each quarter you receive dividends, and you can always buy low and sell high to make some cash. Daily fluctuations would probably be random. Could be fun to come up with some "events" that happen randomly to cause jumps (up or down) in share price.

Beta 2 is now available, and this one includes actual gameplay! Included with the B.R.O.K.E. download are two modules that johnqevil has ported over from the original Kerbanomics: Payroll and ReputationFunding. The first, Payroll, adds a configurable daily salary based on a Kerbal's level. ReputationFunding provides funds each quarter based on the total reputation of the player. Both can be configured in-game or even disabled in-game. To completely disable them, just remove the .dlls from the GameData/BROKE/Modules directory. It appears that you have to click the "pay" button to receive the money each quarter. That will likely change in the future, in addition to options to automatically pay any debts. For now, it doesn't appear we've added a penalty for not paying your Kerbals their salary, but in the future they will quit if you don't pay them! If you have questions, or wish to contribute (bug reports or even entire Funding Modifiers) please don't hesitate to post here in the forum or on one of the two GitHub repos we're using. We're currently deciding on a roadmap to 1.0, so expect some more work in the near future.

I started a GitHub issue for this. I'm not sure how easy it would be to do, but I'd like to see if I can get timers on/near the nodes in the R&D GUI and maybe add some additional buttons when you select a node to cancel research/change priority/etc. I could also add timers for nodes that aren't unlocked to show how long they should take. It might have to wait until after 1.1, since all the GUI things are being redone and I don't want to have to implement all that and then redo it in a month or two I've thought about putting the ship out on the launchpad when you rollout, or at least when it says "on the pad". With the new multiple launchpads feature (I need to finish that still. It works, but I noticed an issue with loading existing saves that I haven't taken a look at yet) that might be more difficult to do. I have no idea how I'd actually implement that, but the SpawnVessel code from Contract Configurator might work for it. I'll add it on GitHub, cause it would be really cool to do, but a bit of a logistical problem.

Correct, that's what I mean by the manual method. Some results are just that it doesn't work at all when you press the button. Other times you can't do anything in the editor. When I was testing with something that started as two docked parts that I undocked, the part I undocked magically reappeared as docked despite the fact that it was still in orbit. When that happens just Alt-F9 to load the backup it made.

It makes a quicksave before it attempts to do anything, so it's safe to try, but it's pretty buggy. You can also back up your save beforehand manually just to be sure. I've only done tests with small craft and even then it can sometimes have weird results. You might try the manual method with hyperedit and save file manipulation if Re3 doesn't work.