caipi

Nice mods, I like the "shiny" teeth

I am having the same issue. I am playing my career on a private DMP-Server though with a friend at normal mode. We both lose reputation constantly, even though we don't lose any kerbals or crash any buildings etc. It would be nice to know what might cause sudden drops in reputation. I was down to -354 very fast (I only researched a few nodes). E.g. does debris that falls near the KSC (not onto any building, just near the center in general) cause a drop?

Same here. I also love your mod and cannot wait for it to be updated for 1.0.2

Awesome parts! I love the new ones especially (It's been a while since I used your mod). I think I found some bugs though with the modular fuel tanks (I am using MFT 5.4.3): The K-FuelTank 6m has the option to carry either 3375LF and 4125 Ox or if you take the jet fuel, it can only carry 2000LF. This doesn't make much sense because I could just take the rocket version and empty the Oxidizer and still end up with more LF. Also the J-K Adapter can carry 2500 LF in its pure Jet tank. So it is smaller, yet it can carry more fuel. Keep up the awesome work.

Hey Taranis, great mod, I am using it for quite some time now. However I found an issue with your mod and OKS/MKS from Roverdude. I will post the issue in his thread as well. Your config forces every module, that has a command function/module, to include food/oxygen/water/etc. However this creates an issue with the Power Units from the OKS/MKS mod (OKS_PDU and MKS_PDU): Those parts can hold up to two Kerbals and include Enriched Uranium, EC and Depleted Uranium. Your mod causes it to loose those three resources (and adds the lifesupport one's), which causes the power distribution unit to fail due to insufficient resources, which cannot be added to the unit. My current fix is to delete the part which classifies these modules as ModuleCommand. This is a rather dirty fix though and there might be other issues I am not aware of (with this module as well as other modules). Kind regards caipi - - - Updated - - - Ok I found it: Modular Fuel Tanks is responsible. Looks like it thinks there is not enough space for the resources after the TACLS resources have been added via MM. I suspect it calculates the available space only according to the last resources and not the additional initial. Guess I'll have to remove MFT again or I have to add the TACLS resources to the PDUs manually. It should work, I suppose. Apoligies for the fuzz.

So far, all versions (or at least most) have a title, like "Beta than ever" "First Contract" and all those more or less witty phrases. The game itself is still called Kerbal Space Program. Consider it a sub title for the version number.It was just a suggestion and I know, it only works in German. So it's not really applicable, thus it will not happen. But it might still rise to an inofficial version title, as an insider @aqua&Ikaneko: I think you are underestimating the community. A lot of students (University, not school, though the last one might be true as well) are playing the game and I think a lot of people do get it.

I read in the Beyond Beta article that female Kerbals will be added in the RC. So I came up with a nice title for this version: Kerbale und Liebe (literal translation: Kerbals & Love) Unfortunately it only works in German. It is a reference to a well-known German play by Friedrich Schiller (famous German writer) called Kabale und Liebe, which literal translates to Cabals and Love, but its English title is actually Intrigue and Love

I wouldn't release it as long as there is no stable Win 64bit version. The game thrives on its vast modding community. Without 64bit you are limit to a small number of additional parts/mods.

Haha, nice one

^^ Everything noteworthy has been said already, so I just stick with the most important part: "Thank you to all the modders, you guys are awesome!"

Just out of curiosity: Why did you create 4 modules with different science experiments and 6 base science each and not just one module with 24 base science? That would save us the time to do the same tedious experiment four times or put four modules on top of each other. And if you quadruple the mass (maybe the cost as well), then it is also balanced again. I thought the point of this mod is to make the start easier. Don't get me wrong, it is not bothering me. I simply put the four modules on one rocket and go with it and I absolutely love the mod. I am puzzled though why you chose to do it like this. Apologies if this questen has been asked and answered already.

I took the liberty and edited the Patches\MkIVCLS.cfg to be more useable. Please feel free to use it. I don't know if you agree with the cargobay being passable (I think it makes sense though, especially if you have manned ships docked in the bay), but the docking nose should definitely be passable in my opinion. // Mark IV System Connected Living Spaces Support // Requires ModuleManager and CLS to function @PART[mk4crew-1]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[mk4cockpit]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[mk4nose-docking]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[mk4cargo-1]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true surfaceAttachmentsPassable = true } } @PART[mk4cargo-2]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true surfaceAttachmentsPassable = true } } @PART[mk4cargo-tail-1]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true surfaceAttachmentsPassable = true } }

He doesn't necessarily have to use FAR/NEAR. As you can see in my previous post: Nertea put the FAR/NEAR-config files for this mod in the patch directory and if you don't delete them (because you don't need them), then they'll be used as if you are using FAR/NEAR, even if you don't use it. All my MarkIV parts had incorrect temperatures and 0 drag as well as a different max crash speed.

Part clipping doesn't create non-existent attachnodes. I don't see how part clipping would help in any way with the issue at hand.

Hey Nertea, first: I really love this mod! The Mark IV parts are awesome and I enjoy using them. I still have a few comments/criticism and I hope they'll help you: I noticed that the max temperature is set to 1500° and not to 2900°-3600°. This sometimes leads to the fact that I cannot use the full potential of some engines (especially if a part has multiple engines on it, like the MkIV Triple adapter), or else they explode really fast. I am currently testing if I can abuse your parts for some heavy payload carrier rockets ( http://abload.de/img/screenshot7m9f60.png just an initial test which failed because the three hardpoints on the triple adapter cannot be fully utilised). Would you consider rasing the max temperature or does this temperature have a deeper meaning? Ok I found the issue. It seems that the Deadly Reentry Config file you put into the patches directory edited the maxtemp and deleted the drag from all your modules. But I am not using deadly reentry. So I deleted this file and finally got the original values you intended for the non-DRE version. The Cargobays dont have a second "inside" node (like the Mk2 Cargobays) which means I cannot place the 2,5m docking port at the end of the cargo bay. I have to use the 1,25m docking port or have to work with the radial attachment point. Not a big issue, but considering that the cargo bay is made for 2,5m parts, it would be nice to have the option to place the big docking port directly at the wall. Those were my main concerns (so far ). If you have some time and feel like it, I would also love to see a connected-living-space-support It's fairly easy and merely a few lines per affected part. Btw: I never build a single-stage-to-orbit spaceplane as easily and quickly as I did with your parts.

All I'm currently doing is check the add-on release forum and curse every day or second day, look for new updates and mods, read the patch notes (if available), test the mod and then I go on and play something else I am currently just waiting for .9/the beta to come out and to restart the DMP multiplayer mod on my server again. It's good to see that you are still around and plan to update your mod and the list looks nice! I really like it and it makes docking so much more fun and quicker. Keep it up!

Well, as my Grandma always says: Faster than light, no left or right!

Is it TAC-LS-compatible and if so, does it contain food?

Mhm, strange, I am running your mod in Windows (together with a bunch of other mods, most prominently the one's from roverdude) and I am running the 64 bit client without any issues. Did you try using opengl under windows? It really resolved a lot of issues for me and it seems rather stable (at least as stable as the 64 bit version under linux). If you don't know how to use opengl under windows: http://forum.kerbalspaceprogram.com/threads/93045-Windows-and-64bit-client-how-to-avoid-most-bugs-%28opengl-d3d11%29 I know, the game is not as pretty under opengl, but stability is more important and the 64bit client has too much advantages over the 32 bit client in my opinion.

Other mods can utilize it too, like the Debris Refund Mod - it doesn't make sense in sandbox, but you still get the message that you debris has been recovered (or not...). So I don't think it is an accident. I think it was left there on purpose for modders to take advantage of it.

Awesome. Did you try if this is only caused by the jet engines or by the intakes? Or is it caused by either one? Might it be enough to simply place jet engines separately?

@linear: yes right now dx11 is annoying. I am currently using openGL and so far it is running fine with maxed out graphic settings and a stable 60fps framerate. I meant that squad should look for the unity/ksp64/win7 issues in this area to solve it. @wwedeadman: i cannot even start the 64-bit-client/savegame with certain mods. I need to use one of the above mentioned methods. Back to topic: for NVidia users: Do not attempt to activate threaded optimization or changing the maximum pre-rendered frames. Both settings need to be set to the default or you will have issues with the timewarp. btw: thanks to the mod who moved this topic into the right category!

Not a major bug, no, but still pretty annoying with two screens and constantly tabbing out. Also: not really a "fix", is it? ;-) I used to right click so much that I got used to it and used it in other games as well -.-' Damn you, subconscious!

Looking at the first post: If you're already annoyed by this, did you ever tried the mk3-mk2 adapter and putting something on them? They are a few inches apart. You know how ugly that looks? This is the main reason I don't use mk3!

Hey guys, I know that the 64bit version is still considered experimental at this stage and everybody who has used it under windows knows that there are common and annoying bugs. But the 64bit client still offers some advantages over the 32 bit client, especially if you are using a lot of mods. Unfortunately some mods create such heavy issues, that you cannot even launch a savegame with the 64 bit client and the game will crash immediately. I found a few comments in some threads and was starting to experiment with the following options (you need to put them behind your exe file as parameters): -force-opengl (Windows only) Make the game use OpenGL for rendering, even if Direct3D is available. Normally Direct3D is used but OpenGL is used if Direct3D 9.0c is not available. -force-d3d9 (Windows only) Make the game use Direct3D 9 for rendering. This is the default, so normally there's no reason to pass it. -force-d3d11 (Windows only) Make the game use Direct3D 11 for rendering. Using d3d9 doesn't make a difference and it is the default setting. Certain mods seem to create an issue right at the beginning and the game won't start when you try to load/start a savegame. OpenGL seems to avoid most of the bugs and is working so far with most of the mods. Directx11 reduces this bug a lot and it is merely happening occasionally to me. Both options seem much more stable than d3d9 and I get a lot less crashes. It seems that the bugs caused by the unity engine are only or at least mostly tied to Directx9. Unfortunately there are also downsides to the alternatives: opengl is in my opinion not offering the same performance as directx, but it's still currently my favourite option. Dx11 seems to have a few texture glitches though since the game seems to be optimized for dx9 (minor spaces between columns of the right click menu, buttons not perfectly aligned, etc.). Do not attempt to activate threaded-optimization or to set a pre-rendered framerate. Either one will create problems with the timewarp for both the d3d11 and the openGL methods. Maybe squad can focus on dx11 in the future and make it the default rendering method. Until then have fun fiddling around with these options.