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

My version checker said there is a version 1.2.4 available but the download on the OP shows 1.2.3 was there a typo in a config file somewhere that triggered this alert ?

Does anyone have information on the free_square and stack_square types. I cant find any info on these but they appear in several config files and seem to be used mostly for solar panels

Is there any way to make collapsible regions in the config files. I tried using empty brackets but module manager doesn't seem to be able to parse the files when they are formatted that way. Is there any symbol i can safely use as a opening and closing mark for code collapsing that will not interfere with module managers ability to read the config files When your writing patches for something like Tweak Scale you generally end up with hundreds of parts to patch and it would be nice to have collapsible regions of code under section comments for sanity sake If this doesn't exist consider this a feature request for a @REGION node which acts as a organization container for part nodes like this // Patches for Parts of type A @REGION { @PART[] { } @PART[] { } } // Patches for Parts of Type B @REGION { @PART[] { } }

I am not sure if this is related to the accuracy bugs but once i started going to mun or minmus I found a major bug where the mod will throw a hissy fit when trajectories become hyperbolic and have no end point Basically this causes a huge framerate loss and frequent client crashes when plotting hohmann or interplanetary courses It got to the point where I have to uninstall the mod any time I am flying a mission that leaves kerbin orbit and reinstalling the mod once i get into orbit around the target.

I haven't tried modding ksp yet so i dont know if the game supports this but if ksp has support for generic lists you could use that so groups can be added and removed dynamically

Do you have a 1.2.2 build ?

The simplest solution is often correct i would guess he is probably using the main fork that does not support 1.2.2 @Knezz for 1.2.2 you need RangeMachine's unofficial release. The link is in the OP. delete the texture replacer folder and try reinstalling using that version

I was referring to big hairstyles such as seen in anime that would require a mesh. But that looks like the next step in development, implementation custom mesh support

Is this only for textures or can you replace head and suit meshes as well ? Just curious because I have seen a lot of packs but I haven't seen drastic alterations to space suits or hairstyles.

Does anyone have TweakScale configs for the USI mods?