Rodhern

Hello. I have uploaded Kapoin ver. 0.1.0.4 to Github. This release is all about playing nice with the KRASH simulation mod. To test if Kapoin and KRASH play nice a new contract is included. It is a silly little contract named 'Supersonic Simulation' that you are offered if you have KRASH installed. To complete the contract you launch a KRASH simulation session and fly a crewed plane (or rocket) at the specified speed and altitude until the green tick mark appears, then when the simulation is ended and you are back at the space center you wait for the data to download.

Hello @timmers_uk and I have arranged that I will update the Spacedock.info listing with the latest release from my Github Keepfit fork. Could someone (looking at @Kerbas_ad_astra) try out the Github release before I update the Spacedock listing. Also if you could run the download through an anti-virus scanner for good measure.

I believe some people have blaimed Scatterer.

It is worth a try. In which folder locations do you have CLSInterfaces dlls in your install? What happens if you download an 'extra' and put it in GameData/KeepFit ?

Hi Kerbas ad Astra. Thank you for making the observation. I did ask about what to do with the CLSInterfaces.dll in the CLS thread, but it seemed no one was able to offer a suggestion, and so I decided to just keep the file in as it was already there. I just now tried to remove the file from GameData to see what happens. Keepfit fails to load if there isn't a CLSInterfaces.dll to be found. That means, it is probably not the best answer to remove the file either. For now I will put a notice on the latest Github release that you may need to delete CLSInterfaces.dll. - Rodhern

If you share the craft file and the mod requirement list, there is probably a chance someone is tempted to nit-pick your design. It might be worth a try.

For me it is mostly a matter of being uncertain if the effort would actually be appreciated enough that bugs/features are fixed/improved. It is a result of the peculiar information strategy Squad chose some time back. Sure, it is better now than it was; I guess it just takes more time to restore the enthusiasm.

Or maybe KAS. (A klaw sounds good too).

Are you asking about attributes? Attributes inherit from System.Attribute (as described in the link you gave above), and are just classes. The difference is that they are often used in a bit of a different way from other classes.

Attributes are more or less used to give KSP information about your mod (dotnet classes). One that is often used is KSPAddon, e.g. [ KSPAddon (KSPAddon.Startup.TrackingStation, false) ] that way KSP knows that you want that class 'created'/'loaded'/'started' every time the player goes to the tracking station, and that the class can 'unload' when the player exits the tracking station. The attributes are discovered by KSP/Unity/Mono by something called "reflection". Something about Unity can make it quite a bit more confusing than it ought to be. Some classes are found by reflection due to their inheritance, some methods are identified by reflection due to the name, and some are found by reflection due to their attributes (e.g. KSPField and KSPAddon). Look at the first few posts of this thread - there are good explanations there.

Does your craft have non-stock parts. If it is stock only maybe you could upload it, so that we may see if the craft is bugged in e.g. my install too, or whoever grabs the craft file first.

Something similar happened to me in one of the dev-builds, but only after a revert. Do you see it at first launch too?

I am sure someone will give a better answer shortly. In the meanwhile, if you are launching from the KSC with just the one Swivel as propulsion, the limiting factor is going to be the weight that a Swivel can lift off the ground. Not much more than 16 tonnes - including fuel, rocket parts, the engine itself, payload and all.

Just out of curiosity, could you post a screen shot of the problem? (I can't remember experiencing such a problem).

My advise is kind of stupid, but I am going to give it anyway. After the uninstall, reboot, then remove the (now almost empty) KSP folder. If it still requires admin privileges to delete at this point maybe you can have someone help you delete the folder (?). Only then reinstall via Steam.

I didn't want to write a long sequence of formulas - most of the time they are just a nuisance to people. Most readers skip them; some do the math themselves (because it is fun), and almost nobody runs through the entire thing in their head . I will try to explain the main point a little better below. Yups, the result is an approximation, but at the same time kind of a worst case upper bound. Let us pretend we are in a low circular orbit with speed v0. Also let us assume that the SOI is really really large (like e.g. 100 Gm). By EpicSpaceTroll139's post, the worst case budget is almost the same as v0, because of the assumption that rSOI is a really big number, and the speed in an orbit that wide is really slow (almost zero). The best case budget, used in the delta-v maps, is to increase the speed at the periapsis so that we get the apoapsis to reach rSOI. Again, because rSOI is a really big number, so is the semi-major axis length, and we are left with just the v1 = sqrt(μ*(2/r0)) part of the speed equation. That is, v1 = sqrt(2) * v0. So if the SOI is really large, then we might end up with close to 2.41 as the factor. As you have already shown with examples, if the SOI has a more modest size, we seem to be better off. And indeed your examples show that it is by a non-trivial margin. An interesting exercise none the less.

I think the predictable constant you might be looking for is 2.41, as in 1/(sqrt(2)-1) = 1+sqrt(2) .

Lots of wing surface. That's my two cents worth on the topic.

Hi, here are some assorted progress comments and a question or two. Please feel free to comment. FAR (Ferram Aerospace Research) I have copied my update of the in-editor stability derivatives panel to (a fork of) the development build code. If you use the development build of FAR for KSP 1.3, you may get my update from Github. You 'install' the update by extracting the files (the dll and the localization files) on top of the existing ones. Edit: The update has been (merged and) reuploaded as an update for FAR version 0.15.9 "Liebe" (untested). A word of warning: There are some issues in the development build installed in my game. E.g. if I launch a rocket, then revert and fly the same launch again, the second time the fins are ripped off due to stress. It may be a bug in the development build of FAR, or Tweak Scale, or my update to FAR, or one of my other installed mods, or, well, may be caused by just about a thousand other possible issues. Also, you may notice from the release date that the update does not include the changes to the development build made by Ferram4 today (2017-08-21). If you are curious please try out the update, and see which stability derivative interpretation you like best. If you manage to create a (reasonably simple) craft where the 'classic' interpretation makes more sense than my 'alternative' one, let me know — maybe a good example is all that is needed, so that I may figure out where my intuition is falling short. Keep Fit It is more or less the premise that if you play Kapoin you are using KCT. KCT makes sure that there is some meaning to "time passing". The more or less obvious counterpart for crew time passing is life support mods. To me, the life support mods are a bit too serious, and take away some of the Kerbal cartoonish feel of the game. An excellent compromise is KeepFit. I have compiled a version for KSP 1.3. The mod is starting to show some signs of wear, but IMO it is still a cool and fun plugin for KSP. The compiled version is available on Github. Kapoin, persisted data There is no new (or proper) version of Kapoin yet. At the moment the problem is that some of the Kapoin career data is reset when Unity signals that (a new) game state is created. Apparently that is not the time to clear the data variables. The problems are further compounded when KRASH (the recommended simulation mod for KCT) is introduced to the mod mix. Kapoin, tech tree (Module Manager) The default layout of the KSP tech tree has lead many players to tweak the tech tree. I too have tweaked the tech tree, and I have committed a Module Manager patch with the tweaks to the Kapoin repository. The idea of these tweaks is to not move the parts around too much, but group them a little more aggressively, so that for instance all of the early control surfaces are in the same node. It probably makes the game a little more difficult, but I think it makes the tech tree unlock choices a little more meaningful, now that you do not get 'a little of each' in a single tech node. The config patch is here — just rename it to .cfg if you want to use it. Kapoin, rewards I have a game play balance question for you guys. One of the early milestones is to build up the Kerbal Space Center. Something along the lines of say requiring at least one upgrade to the tracking station, mission control, the runway, the administration building and the astronaut complex, and expand the crew roster to at least a dozen of Kadets. A fairly natural reward for such a milestone is a number KCT upgrade points. What would be an appropriate number (for a moderate difficulty career game)? It must be enough that it feels like the reward for a milestone, but yet not silly overpowered.

My Mk1 Command Pod has 'Reaction Wheels' mode options "Normal", "SAS only" and "Pilot only". In addition to this I have a 'Toggle Torque' option that can set "Reaction Wheels: Disabled". Why don't I just have modes "Normal", "SAS only", "Pilot only" and "Off"? Do you ever use any other 'mode combination' than those four?

Also just curious; what mechanism would decide the "warp factor"? (if it is done manually only, you might as well warp outside of the editor).

Thank you for the mod; it is a nice addition to FAR. I had anticipated that the wind would not change game play by much, seeing that most kerbal airplanes are fast. My thought was that if a plane travels say 90 m/s then you would probably not notice an 8 m/s crosswind. I was wrong. The wind brakes the perfect landing performance symmetry of your typical airplane quite nicely.

I have uploaded a build for KSP 1.3 to Github.

Seems to work well for me too, as far as I can tell.

If you are on Steam try revalidating the game files. If you have mods, try temporarily removing them. I haven't noticed any major change to stock aero in 1.3.