Ippo

Weird: In Dx11, popupwindow doesn't work for me, that's why I said you need OpenGL. Oh well, even better then

I think that it takes the folder "<zipfile>/GameData/Kerbice Group" and just places it (and all its contents) into GameData. The end result should therefore be <KSP>/GameData/Kerbice Group/AMEG .

Protip: if you use OpenGL, you can run the game in borderless windowed mode. This is awesome: you can switch to other programs and ksp will run (and load) in the background. Unfortunately not ever graphics card seems to have good performance with OpenGL... worth a shot.

Oh hai, I see you were talking about me Having created a ton of work for pjf had some experience with CKAN, and agreeing with Justin that the quick start was a little barren, I tried to make some improvements to it. Could you please take a look at it and tell me if it's better now? Also, if a native english speaker could give it a quick grammar-check I'd be happier

Update: the Wiki is now online!

I am currently in the process of writing the wiki, so I answered you in the FAQ (which is still a little barren right now, but bear with me )

Hi, unfortunately it's not as easy as adding an option, I'd need to change a lot of stuff around. I want to have multiple failure modes in the future, but it's not a trivial task. Well, the whole concept of this mod is to be the opposite of player-friendly Also, if we want to go for realism an engine failure should actually just mean an explosion most of the times.

Today I was in room A, I had to pick up an object in room B, another one in room C, and then bring them both to room A: also, there is a corridor that connects them in that order (A, B, C). I was about to pick up object B on the way to room C, but then decided against when I realized it would have been a huge waste of delta v. I was already in room C when the realization struck me. P.S: posted at 4 am, after 3 hours straight making my own apollo program in 64k.

And this is why I'm NEVER playing career game again in my life.

You can write a MM patch to edit the values to whatever you like: @PART[ the part you want ] { @MODULE[ModuleEnginesReliability] { @MTBF = something @LifeTime = something } } I'm not going to provide customized config files for a while, at least until we move to beta (sometimes I have the feeling that people are ignoring the "alpha" in the title ), so no, I won't support this in Alpha 5, sorry. In the long run, I plan to write custom config files (right now each engine is *literally* the same, reliability-wise...), but first there's still a lot of coding that needs to be done, sorry

That's all that matters

Sorry... not really convinced about it, to me it seems it only adds complexity with no real benefit for the gameplay :/

Well, to each his own I guess I will object to your statement that the chance of failure is 100%: it is only for time approaching infinity, which of course you can't do, and in fact a lot of LKO and Mun missions are so short that more often than not I come back without a problem. But I digress While I don't really understand why you'd want such a model, I'm afraid that it just can't be implemented in my framework without rewriting pretty much all of it... sorry (Still, DangIt is free software so feel free to fork it, or to find someone who will for you )

It is a FAR issue that I have no control over. I have submitted a patch to ferram4, who has accepted it: therefore it should be fixed with the next release of FAR. I'd have to check. In general, all (and only) the ion engines have been buffed, so the ion engines from Near Future will be buffed, but if there are other engines that don't use Xenon, they are untouched.

Eheh, no problem In its current state there is no API for others to interact with it, but for your particular case it's just a matter of adding a couple of lines I think. Let me know when you get to implement it and we'll find a solution

We can surely work something out

Well, mainly because the scope changed I want a system to provide an API to use perks, like DangIt is doing right now. Now, technically it could be built on top of CrewFiles, but it would cause me to duplicate a lot of boilerplate code and it doesn't really sound like a good idea to me.

Hi, all the data is stored inside the save file, therefore it is always in sync with the game. If you load a previous save, you also load the corresponding database: so unless KCT uses some weird method to revert the simulations, it shouldn't pose any problem P.S: Let me also add that this mod is getting deprecated in the near future. The upcoming Open Perk System will also include everything that CrewFiles does right now... if I ever find any time to work on that, that is

Mmm, interesting, but how could it be justified? I have to say it, I am more of a realism player: I can't really see an obvious reason for this mechanic. I'm not saying no, I'm just wandering why cost should decrease over time

Oh god, I had just finished setting up 6.4x, why are you doing this to me

All this beer analogies are just making me thirsty. To clarify my previous posts: - if the license allows it, you have already authorized the fork. - you can, of course, not approve the new fork (ferram, for example, doesn't) - common courtesy should apply both ways: with this I mean that (obviously) who decides to fork should try to respect the original author's wishes, if possible; the author should also try to be considerate with the wishes of the forker, especially after he has given him permission to go ahead (which is exactly what ferram did). And now I think I'm just gonna leave this thread because I re-read my post about 20 times and it still doesn't read like I'd like it to, I don't think I can explain myself and not sound like a mule

You can follow the development here, if you are curious. I'll be working on other stuff first though, so the next update is not going to be ready soon...

Sure, it just strikes me as very odd that someone would choose a license that allows forks and then refuse to let others fork. I mean, they already given you written permission to do so, refusing it later is just bipolar.

Don't worry for the colliders, they are inactive for parts on the same ship unless you mod it. Also, triggering the animation should be a lot easier than finding the correct part that you need to open...

IMHO, there can't be an "unauthorized" fork if the license allows it. The license states what I can do with your stuff, and if the license allows me to fork, then you have already given me explicit and written permission to fork your work. So yeah, if you are not comfortable with some uses that are allowed by your license, maybe you should choose another license... just my 2 cents.