Styrr

Is there already a fix for the vanishing space center and the copying of ships in sight?

Indeed the behavior changed. When looking at the last setup with 8 RCS blocks the one nearer to the CoM uses more thrust than the one at the bottom. It does not however apply thrust in the inverse direction to really counter the introduced rotation. Nor does it use the up down thrust to counter the rotation.

Hello everyone. I'm an absolute newbie in KSP modding and have a question regarding the module development. I sometimes come into certain issues with RCS: When they are not placed in the correct distance to the CoM the behaviour gets rather annoying. I know of the RCS Build Aid and the PWB Fuel Balancer mod which allow me to place the RCS in optimal places and help by keeping the CoM as desired by shifting fuel loads. However, this leads to designs where I have to place the RCS units near to other components in my spacecraft. When turning off SAS my experiments show that for rotational controls the CoM position of the is taken into account. However, for translational commands this doesn't seem to be the case. Here are some examples on the behavior: Yaw Motion using the RCS works nicely and takes CoM into account (here i request yaw): Translational motion (right) does not take CoM into account and introduces heavy rotation (here i request translation to the right): Translational motion (right) with SAS turned on starts as above without taking CoM into account and starts to counter the introduced rotation by thrust in opposite direction. The up/down thrusters are only marginally used. This is on the one hand meaningful since the lever is small for those and they are not very efficient. However, it would be much better to use them anyway instead of thrusting in the opposite direction, cancelling the the desired translational motion completely Translational motion to the right (blue arrow) with a different setup where you can see the SAS result (the actual SAS thrust in white), where the pink arrows show (qualitatively) how you could control the craft in a more effective way. My request in this thread is twofold: On the one hand I'd like some feedback if my thoughts are correct or if I made a mistake in my conclusions. On the other hand I'd like to ask - given my thoughts were correct - whether there are mods trying to tackle this? And: If I knew how to mod, would it be possible to somehow get between the controls and the RCS actions?

Thx. It seems to be possible with the fuel balancer mod: http://forum.kerbalspaceprogram.com/threads/42624-0-23-PWB-Fuel-Balancer-v0-0-5 @m4v: Sure. Makes sense to keep that separated.

Maybe it's already possible and I just can't figure out how to do it. But when I'm not in VAB but in space with my ship, I can't figure out how to show the Centre of Mass marker.

Yes, sorry. Center of Mass makes more sense for spacecraft Edit: And another question/suggestion. I'm using TeakableEverything where I can adjust the thrust limits for RCS in the VBA. The RCS Build Aid does not respond to changing those thrust limits. Would it be theoretically possible to take this influence into account?

This mod helped me really much! It took me ages to adjust rcs and thruster places before! Since it is a similar topic: I'm constructing a large interplanetary spacecraft in orbit by docking. What I'm missing here would be a possibility to show the current COG of the currently assembled ship to see where I need to attach stuff to get it stable. Would something like this be possible to add for your mod / or does there already exist something like that which I just didn't find yet?

I really like the idea of KAS struts which have to be attached EVA in space. However, I experiency major wobble even though I used plenty of struts to connect my docked parts (a feeled little to no benefit vs only dockign ports). Is this a bug / is there any possibility to increase the struts' strength?

You have to take the cone angles into account. The 88-88 has a cone angle of only 0.06 deg. When being at the distance of Mun and pointing on Kerbin it is highly unlikely that a satellite is within this cone. For such small distances the KR-7 is absolutely sufficient in terms of range and has a cone of 25 deg which means for short distances the area which the dishes cone is covering is sufficiently large. EDIT: Of course you also have to make sure some dish within the cone is pointing back to your probe.

The connection lines are messed up for me as well sometimes plus the other issues I described. I've fallen back to the version I mentioned in my last post for now. Didn't encounter any problems with that version yet. If it's helpful I could try to recreate the bug and provide a safe file for the new version of RT2.

I've got some issues with the newest version. Frequently when I return to Space Port, all the Buildings are gone and I have a void display as if I was flying over Kerbin. I can recover my save if I install the old version given in the link below: The Space Port then works again with the "corrupted" save file. When I check the flights in progress I see that one craft got duplicated multiple times (same name). I can delete the duplicates and proceed as nothing would've happened and install the newest RT2 version again. I can not reproduce the issue deterministically, but it happends rather frequently. I was deploying 4 CommSats and it happened twice. Anyone with similar issues or a suggestion what the problem might be?

Thank you very much Kaa253! Sorry for posting in the wrong thread, I thought it was B9 related, since it only happened with this mod. Might have been because the other mods are smaller. Now I know where to look.

You've got a point here. Though, in my opinion probe missions are not significantly easier to do in KSP (especially with RemoteTech2). Since we don't have to cope with radiation, food/oxygen supply, isolation etc. for our Kerbals, there is nothing that makes a manned mission or a haul back more difficult besides to bring with you a little more deltav for return. So it's a players decission to do unmanned first to have a realistic storyline. This is perfect for sandbox mode. However, for career where the goal is to provide a certain frame, the game machanics should give you the reason to act so. The main reason I dislike the introduction of the handling of transmissions is the redundancy. E.g I can do 1 probed and 1 manned mission to get the same science as for the manned mission solely. So why bother with probes? This may of course be legitimate when cost is introduced and probe missions are cheaper than manned missions.

True. That's why unmanned and manned science missions should differ. As in .22 e.g. where we had to land a manned mission to acquire Surface Samples (minus the fact that you could spam surface sample info back - but since you were manned anyway you'd haul it back). This is one science example where the current implementation makes sense. We can send photos and first simple analysis regarding this sample via transmission and haul it back for a complete analysis. For the science lab jr and the goo this might be similar. However, the containers might already have included plenty of equipment to analyze the stuff. I think in terms of realism you can find arguments in both directions. However, in terms of gameplay, the unmanned missions are rendered senseless since you have to do plenty of probe missions to get a bit of science, then do a manned mission anyway to acquire the remains. Why should you do that when you can acquire the same amount by a single manned mission, which is not even harder than a unmanned mission. So there is absolutely no reason for unmanned misions right now. Be it realistic or not, it's not ideal balancing/game design in my view.

Did anyone manage to get this running in Linux 64bit? Whenever I include B9 it CTDs when loading the B9 files while startup.

Hi ZeroTolerance, there is a post adressing the issues you mention in Inoperability and Diminishing Returns for Science Transmission: http://forum.kerbalspaceprogram.com/threads/62786-A-change-in-how-science-works-in-relation-to-transmitting-and-returning I agree with both your main points. I also loved to builed the RemoteTech2 satellite networks and now I don't see a sense in it since I'm only doing manned missions. Probes are pointless in .23. I also agree to your second point. However, I think it would also be OK to have an additional science module fitting for 2.5m parts, where you could do more sufisticated science.

I 100% agree with Moonfrog. I started a new career with .23 and I find myself only doing manned missions. There is no reason now to use probes (at least in the early phase when I stay in the Kerbin system). Using probes would just lead to grinding because you would have to repeat the mission again to do the manned mission. With .22 I would work with many probes but still had the incentive for manned missions due to surface samples, EVA reports and crew reports. Now unmanned just doesnt matter anymore since there is no gain which you can't get by manned missions. I also didn't create a satellite network with RemoteTech2 yet though it was plenty of fun in .22. With only manned missions it isn't required anymore. Therefore I prefer either the old system or the suggested separation of manned and unmanned missions. While I understand the concerns of some people mentioning that there is no science a probe could do, a manned mission couldn't, I have to disagree slightly. Specifically long term missions (like you can currently do with ScanSat) are typical probe missions. Also, one could think of other experiments which are typical for probes. I'm sure we would find plenty. So there is absolutely no reason to not allow the unmanned missions to regain some value. Only if there is science you can gain exclusively by manned/unmanned missions there is motivation to do both. This may change when cost is introduced, but nevertheless I would love to do both for science's sake.