Mikeloeven

if your using tweak scale for this than it should apply a modifier to engine thrust based on the new size. For sharing images use tinypic.com its a easy upload and doesn't require an account. though personally if your demonstrating a bug a youtube video is worth a thousand pics

I suggest adding launch clamps if it doesn't already have them than using the move tool to offset the rocket above the pad. Its possible that the collision geometry of the part doesn't match the visuals a slight vertical offset should solve the issue

Exactly but without the need for a bulky probe core

Personally I still want to see a simple method of designating FMRS points and the transponder will inevitably have other uses as well

Would it be possible to add a stage transponder? One of the issues that I've had with FMRS is my recoverable stages require full physics simulation to land successfully but do not require user input thus adding probe cores to each and every stage is not really viable. My proposal is a small physicsless surface mount transponder which serves to designate FMRS stages and create a FMRS save point when seperated. The main issue here is SR's reentry calculations result in upper stages being destroyed durring reentry dispite shielding and aerodynamics to keep a retrograde allignment thus the need for FMRS saves on these unguided stages to allow full physics simulation on reentry

I would suggest making another pull request minus the conflicting file that way the other changes can get merged quickly while we are comparing the NFT configs. edit: Looks like a major difference is that I made entries for each part while eberkain used wildcards in the part names. I didn't know you could do that and if it works his file will be lot smaller and more efficient than what I was doing. though you might want to consider using comment regions to keep support for notepad++'s folding in comments function It really does make it easier to jump to a specific group of parts by collapsing the file.

@AccidentalDisassembly That error may have been my fault, sorry. I double checked the config files before making the pull request but that one seems to have slipped by. Thanks for Catching that. Also those comments you redid were something i came up with designed to work with notepad ++'s folding in comments feature for custom language definitions. They allow code collapse and make it easy to jump to specific sections. If you use notepad ++ try using this language definition edit: Fixed and Pull Request Submitted

I agree and disagree I agree in the fact that options for balancing should be available however restrictions imposed by hard-coding in the mod would also defeat part of the purpose of the mod

I mean it's hard enough maintaining a stable connection when my kerbals keep using the transmitter dishes to microwave their snacks and cause temporary blackouts

Is there an early alpha available of any RT 2.X builds or is it still in the planning phase?

For the most part targeting things outside of kerbins SOE is easier than keeping a low orbit ship connected to a relay say. The fact that omnis dont seem to properly connect to dishes tho seems to be the biggest problem but auto hopping between relays for a dish would definitely help

Feature Request: Omni to Dish Connections and automatic signal acquisition / Re-targeting of Dish Antennas There are two relativity large issues I keep running into when working with Remote tech. Both of which seem to be most prevalent dealing with connections between KSO relays and LKO craft. The first issue is that Omnidirectional Antennas do not connect to dish antennas. If a dish antenna on a KSO satellite is pointed at Kerbin and a craft with an omni-directional antenna is within that cone and the relay is within transmit range of the craft there is no reason why it cannot link with the relay network. The second issue is also a problem with craft in LKO but also causes problems elsewhere. That is that lack of a spacecraft or probe's ability to search for signals and automatically re-target an antenna. while a probe outside kerbin's SOE is easier to target craft that are in LKO can only target a specific relay satellite with no ability to hop between relays when it passes out of range. I would assume most probes and satellites have mechanisms available to dynamically re-target their antennas I would imagine the only need for manually targeted antennas would be static connections between relays and setting up beams orientated at a specific target in the solar system. Essentially the mod needs a method of allowing ships and probes to perform automatic signal acquisition so that their dish's can be set to automatically search for and target the strongest signal they can find with the ability to hop between relays as needed. The main problem with the mod in it's current state is the excessive amount of micromanagement.

@sarbian Any chance of updating the OP with that link cause i didn't even know that site existed?

Than you launch KSP and suddenly all your documents are encrypted

That seems sketchy its not a KSP affiliated site