Sokar408

repeaters? And about the polar orbits. I'd like to have 2 sats in highly eliptical orbites, on the same plane, but with one having its periapsis near the north pole, and its apoapsis over the southern, and vice versa. However I can't come up with a formular to calculate this, and I don't know what to look for. Could you help me out?

Alright I'm getting closer, but I'm still afraid of messing something up. The only thing in the part.cfg's that says anything about node_stack is this: // --- asset parameters --- MODEL { model = KWRocketry/Parts/FairingBases/KWExpandedFairingBase/KW_Fairing_BaseExpanded scale = 0.4, 0.4, 0.4 } scale = 0.5 // --- node definitions --- // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 1 node_stack_top = 0.0, 0.217, 0.0, 0.0, 1.0, 0.0 node_stack_top = 0.0, 0.588, 0.0, 0.0, 1.0, 0.0 node_stack_connect1 = 2.4, 2.051, 0.0, 0.0, 1.0, 0.0, 0 node_stack_connect2 = -2.4, 2.051, 0.0, 0.0, 1.0, 0.0, 0 node_stack_connect3 = 2.4, 4.851, 0.0, 0.0, 1.0, 0.0, 0 node_stack_connect4 = -2.4, 4.851, 0.0, 0.0, 1.0, 0.0, 0 node_stack_connect5 = 2.4, 7.651, 0.0, 0.0, 1.0, 0.0, 0 node_stack_connect6 = -2.4, 7.651, 0.0, 0.0, 1.0, 0.0, 0 node_stack_connect7 = 2.4, 10.451, 0.0, 0.0, 1.0, 0.0, 0 node_stack_connect8 = -2.4, 10.451, 0.0, 0.0, 1.0, 0.0, 0 // --- FX definitions ---

I do not understand that at all. This is how the "Model" section looks like in one of the parts: // --- asset parameters --- MODEL { model = KWRocketry/Parts/FairingBases/KWExpandedFairingBase/KW_Fairing_BaseExpanded scale = 0.4, 0.4, 0.4 } scale = 0.5 // --- node definitions --- Can you give an example?

I think the problem is no one has stepped forward to help, not his unwillingness to accept it

This is correct. Interstellar adds its own tech tree. However it doesn't prevent parts from being added, neither through its part.cfg nor by any other means. Like I said I have tried adding it through a cfg file, with the code listed above. I have used that to add many other items to the tech tree with no problems. I have also gone into the injected tree.cfg and added the parts one at a time, and again it didn't work.

What mod is that cockpit from?

Considering I have this problem as well, I'd much appreciate knowing how to fix it. I also have another problem with the fairings where it looks like the fairing sides is smaller, noticable because of a slight, but very noticable crack between the sides. Also the 3.75 meter fairing seems to wobble sometimes, another thing that wasn't there pre 0.23.5

As far as I can see they are tied together. If the SMA is the same, the orbital time is the same. This could be wrong, considering I already placed the sats in the correct positions, with the correct orbital period, BEFORE I adjusted the SMA.

I have a problem in career mode. For some reason the parts are not showing up in the tech tree. I have tried adding them with a cfg file, pretty much placing them where they are suppose to be according to their part.cfg: // -------------------- Procedural Fairings -------------------- // @PART[KzProcFairingBase0_625] { @TechRequired=precisionEngineering @entryCost=0 } @PART[KzProcFairingBaseRing0_625] { @TechRequired=precisionEngineering @entryCost=0 } @PART[KzProcFairingBase1_25] { @TechRequired=flightControl @entryCost=0 } @PART[KzProcFairingBaseRing1_25] { @TechRequired=flightControl @entryCost=0 } @PART[KzProcFairingSide1] { @TechRequired=flightControl @entryCost=0 } @PART[KzProcFairingSide2] { @TechRequired=flightControl @entryCost=0 } @PART[KzProcFairingBaseRing2_5] { @TechRequired=aerodynamicSystems @entryCost=0 } @PART[KzProcFairingBase2_5] { @TechRequired=aerodynamicSystems @entryCost=0 } @PART[KzProcFairingBase3_75] { @TechRequired=heavyAerodynamics @entryCost=0 } @PART[KzProcFairingBase5] { @TechRequired=heavyAerodynamics @entryCost=0 } @PART[KzProcFairingBaseRing3_75] { @TechRequired=heavyAerodynamics @entryCost=0 } @PART[KzProcFairingBaseRing5] { @TechRequired=heavyAerodynamics @entryCost=0 } @PART[KzProcFairingFuselage1] { @TechRequired=advConstruction @entryCost=0 } @PART[KzProcFairingFuselage2] { @TechRequired=advConstruction @entryCost=0 } @PART[KzInterstageAdapter] { @TechRequired=advConstruction @entryCost=0 } That didn't work. Then I tried adding them in the save folders tree.cfg. Again no luck. Anyone got an idea of whats going wrong?

Alright! So I have done some testing now, and it turns out to be quite interesting. I made specific satellites that would barely accelerator with a single Ion Drive, put them up in a grid of 4, and start correcting their orbital timing. I did this by, as previously suggested, I chose an orbital time of 55 mins, 44.1 sec, at an altitude of about 400 km. The way I would do it, would be to speed up and as soon as the orbital time hit .1, I'd stop. Using this method I warped time at max, from a different vessel to insure they orbited on rails. After 2 years the sat positions was so off they no longer ranged all the way around the planet Kerbin. I then tried to use the Semi-Major Axis, going for the exact same one on each. Again I used the speeding method as mentioned, but instead did it to get the SMA as close to each other as possible. This time after 5 years, the grid was still almost Identical. This suggests to me that the SMA, for some reason, is far more important then orbital timing, as it far more accurate. That is not to say orbital period isn't essential, it is, but you can get that far more accurate by using the SMA as measuring tool.

Has anyone made better arrangement of the fairings? Considering that playing with FAR makes fairing just about a necessary, its a bit redundant to not have access to any fairings until a node of 160 science. Also is there a way to create restrictions on the fairings? (except for self imposed ones ofc)

Is there any plans on adding food growth/production parts? Naturally I'm assuming it'll be a little more cumbersome then the filter parts, but it would be nice to have, as it would add another reason to build stations

Is this an official patch? (i ask because i haven't followed this mod, so I don't know if you are the new maintainer)

I won't be the first to test this (have had several saves break due to "early usage", and I am not a competent save editor), but I definitely like what I see, and like you I'm everyone agrees with, it is something that is needed to eliminate the rendezvous with the Tracking Station. Will definitely keep an eye on this one, and hopefully it'll live good bit longer then haystack

Haystack v3?

How is RemoteTech2 and Mechjeb compatibility these days? I seem to recall that they didn't play well together last time i tried it

Damn but thanks for clearing that up My memory is so bad I couldn't remember if I actually made the post O.o Thanks for cleaning up after me

My approach to this is relaying on Omni-Antenna. Sure you can't use them in Geo-Stationary orbits, but considering that 1 antenna can talk to all others in range, it doesn't really matter. I tend to make a low-mid altitude grid of 4-6 satellites, this way you can have your geo sats talk to those sats using antenna, and there by bypass A LOT of dishes

I have module manager, but for some reason the following is not working: @PART[solarPanels5]:Final { @TechRequired=start @entryCost=0 } I assume it has something to do with it already being placed, since when I delete it from the tree.cfg in my save file, the above does work. However I hate changing things like that, and would like to know if there is a way of doing that does not require me to customize several files

Haven't the changes made to the Ion Engine made this harder though. I tend to use as small probes as possible (Considering they always end up just being huge batteries so they don't run out of power. Speaking of that, does remotetech actually manage this, when the vessel is not active?)

Much appreciated!

Wauw I never thought of doing it that way! Like I said I usually do Separate launches, and use cos relation calculation: a^2 = b^2 + c^2 - 2bc * cos(A) Lets say I want 4 satellites equally spaced, at an altitude of 100.000 meters, I know that b = 100.000 and c = 100.000. Since there is going to be 4 satellites, and a circle (the orbital plane) has 360 degrades, then I simply take 360/4 (number of satellites) = 90 degrades = A Now you simply plug and play to find the distances each satellite needs to have between each other to be equally spaced. Needless to say your method is a lot more practical. Anyway on the matter of the post. So you simply use orbital time? Like I said I always get inconsistent readouts on VOID/KER/MechJeb. I don't get enough decimals to get the precious needed to stave off drift between the satellites. How do you get around this?

So I'm trying to bring some satellites into as stable an orbit as possible, for minimal maintenance. My usual method is to use cosinus relations so calculate spacing (trigonometry! ), then I bring the satellites into position one by one, and insure that they have the same orbital period. This works to some degrade, but it seems that after a good year or two in the game, they get very visible out of position. I have tried to use to use semi-major and semi-minor axis as that seemed to get more precious numbers. This worked a bit better, but still isn't as permanent as I'd want. So I'm asking here, has any RemoteTech2/satellite enthusiast/math person figured a better way of getting satellites to stay in position?

Nevermind, it does work. I just had to remove the parts from the tree.cfg in my career save folder first.

I have ModuleManager ofc. I have tried this: @PART[solarPanels5] { TechRequired=start entryCost=0 } @PART[batteryPack] { TechRequired=start entryCost=0 } But to no avail. Please help