Vrana

Not a big fan of merchandising. Especially the purely aesthetic kind. I might go for a mug or a shirt but not for action figurines. Still its nice to see and i reckon me and my opinion are the minority here so good work. That is, IF those things are actually Kerbal figurines.

It greatly depends on your previous skills/education. People with good previous knowledge of physics will have a much easier time with this "game" in general. Others will have to learn things while they play. I think my first Mun orbit attempt was a success(not efficient in any way or form, that took some ingame experience). Landing on it in one peice, however, took quite a bit longer.

I dont like the end of tech tree nodes. Their names do seem to fit some mods very nicely but it means that you need to unlock basicly the whole tree before you get to the mod. In practice this means i could have gone and done a sandbox game to play with the mods parts since there will be no difference, i will have all parts unlocked when i get to the mod parts.

It always confused me when going through the file structure of LLL to see this little ships cfg called the InfilitrationPod... But then at one point images of swarms of little ships rushing towards a capital ship and lacthing to its hull started coming back. And all was good.

Using the mod in an otherwise heavily modded install. Zero problems here.

Any news on volumetric clouds? Ive kinda been waiting for them before instaling the mod. I might be able to hold out a bit more but if they are not close i think ill just go and install it now.

Its the Kerbal Engineer Redux flight computer. It gives various information on your craft (such as remaining dV) and trajectory(orbital inclination for example). It is information you should have but isnt implemented in stock KSP (yet).

Heres another... Many complained the Seekers were nothing but glorified satellites, overdesigned lifeboats and LKO tugs. They prance around Kerbin SOI looking fancy but what have they done for science, asked shortsighted observers. Thus the Seeker IV was built. Weighing in at 140 tonnes, 9 of which are counterweights, and 200 parts, all not counting the launch vehicle. Unlike its predecessors the new ship comes equiped with a full science bay and hydrophonic gardens for long term missions. The lastest Seeker set out to explore orbit around Eeloo and, having done that, prance around looking fancy.

Here is what i did with the new parts so far. A short story in the form of an album about moving heavy rovers and greenhouses to Duna

Love the greenhouse and the buggies. They created the need for a new Duna colony. Also I have been messing around with LLL based SSTOs and i have a small request. LLL components do have a radial Jet engine but no TurboJet. With just basic Jets high altitude flight at requried velocity is just not possible. Id appriciate a TurboJet LLL engine in some future release if you have time for it. Maybe even an LLL SABER? In the meantime I have turned the LLL Jet engine into a FAR Turbo Jet (a bit weaker then stock). In case someone else has similar needs here is an MM conf: @PART[2x1RADJETENG] { @MODULE[ModuleEngines] { @heatProduction = 400 @useEngineResponseTime = True @engineAccelerationSpeed = 0.2 @engineDecelerationSpeed = 0.35 @maxThrust = 200 @atmosphereCurve { @key = 0 1200 @key = 0.3 2500 @key = 1 800 } @velocityCurve { @key,0 = 0 0.7 0 -0.00098 @key,1 = 140 0.63 0 0 @key,2 = 400 0.7 0.00049 0.00049 @key,3 = 900 1 0 0 @key,4 = 1800 0 -0.00098 0 } } }

Guys, i suggest you stop trying to use dishes for geosync or lower sat constelations around Kerbin. It is usually a complete waste of dishes. Geosync is at around 2.8Mm from Kerbin and you have omni antennas with 5Mm range and shortest range dish is 50Mm (if i recall right). Dishes are used for Kerbin->Mun,Minmus or Kerbin->other planet comms. There is nothing inhernetly wrong with using them for comms on your "base" sat network but its a complete waste of their range and you are just making your lives more complicated by needing to target all those dishes instead of having omnis just pick up everything.

Sure there is a way around it... Sacrificing ascent efficiency and saftey is one. For example i recently lifted this monstrosity under FAR and DRE (stock Kerbin settings, not RSS) without fairings. The launch stage(s) was directly under the main tower, an NP 5m stack with 3.5m(or were they also 5m?) liquid fuel boosters which were suppoused to be an asparougus but due to instability i was uanble to stage the first tanks in low atmo. Good thing we were launching it into space and then setting a Mun transfer cause im preety sure my crew wanted to quit and forget about all about my space program after that launch. After about 200 m/s the thing started flailing like mad, any control input on my side before around 25km ment an immidiate loss of control and flip. This includes staging, i had to delay the planned staging until we cleared most of the atmosphere. Im not sure anymore but getting that out of atmo and circularizing around Kerbin probably cost me at least 6km dV. So while its still possible to launch huge unrealistic constructions even without fairings it is certainly unadvisable.

There are, indeed, mods with larger panels. I belive you will find the biggest solar arrays in Kosmos but there might be others. That said. I wouldnt worry about size. Wont be long before you realize less is more in space.

Well.. Then im sorry but i cant help you. You will have to wait for Cliph and do a bug report.

Did you timewarp? If you did and they were not perfectly aligned (extacly the same orbital period down to a second) they will drift. This has nothing to do with RT.

This is a similar situation in a game of mine.... The yellow lines are dish connections. The grey lines are omni conns. The thin grey lines are cone borders. You can see the "seeker III" targeting Kerbin from Mun orbit and getting dish conn from Kerbin sats. You can also see the cone of its dish and you can see antoher cone hitting Kerbin from Eve. So from your screenshot we can see that all your sats are using dish conns. You have 0 omni connections. And we dont see any cones. This means all your sat are targeted directly. Which is ok. But i highly suspect you have some dishes set to target "active vessel" instead of satellites orbiting the Mun. Again, are you sure the dishes on your Kerbin satellites are not set to target active vessel? The behaviour you mention (getting connection only when you switch to satellite) seems to indicate this. I really dont mean to sound condesending but i have to make sure this is not the case... The following ss shows the targeting interface with a dish set to target a ship around Gilly(its greyed out). You should set some dishes on Kerbin sats to target sats around the Mun like this and vice versa and make sure they arent set to target "active vessel". If they are all properly targeted you will have to wait for Cliph to look at your case and then, probably, do a bug report on Github.

Well somehow i missed this, i guess its (too) late. Are you sure the dishes on your sats are not set to target "active vessel"?

You dont need to turn them manually at all. In fact turning the facing of the ship does nothing for the facing of the dish cone. The dish cone turns on its own, even if you are not controlling the ship, if it has a target assigned. Afaik there is no way to turn off cones on dishes without reconfiguring them into omnis. To see where a dish cone is pointing click the second icon from the left ("X") in the small RT interface at the lower right of your map/tracking station screen. The "X" will turn into a small planet after you do this and dish cones will display on your map screen. Can you click this icon and then screenshot and repost the situation you showed before? Seeing cones might make troubleshooting your problem easier. If you really want to you can turn dishes into omnis or ramp up the range on omnis to dish level quite easily by editing the cfg files.

Only thing which comes to mind is... Are you sure the dishes are targeted properly? As in they target other sattelites and not Kerbin/Mun. Anything but the shorest range dish(DTS-M1 at 45 degree) doesnt have enough cone angle to encompass your whole network at that range. So it might gain and lose connection as sattelites fly through the narrow cone of a long range dish. If this is not the case it does sound like a new bug.

Mykill, we just dont have enough information to answer that. Maybe some dish is not targeted properly? Maybe a dish which is targeted properly lost its line-of-sight? Maybe some of your sattelites are running out of electricity? Maybe you are not using the latest version(there was a conn loss issue with planet targeting a few versions ago)? Or maybe you did encounter a new bug in which case you should head over to github and properly report it (include log and/or persistance file). In any event i can see nothing wrong with that screenshot except the wrong position of the flight comp icon over MET/Timewarp interface. But then again your mission time is also positioned wrong which leads me to suspect that the problem is not related (just to) RT.

There is no "cone aim" thing. Just the dish targets which are assigned via a menu as you know. Once they have been assigned the dish automatically turns the cone to face its target. You have a different problem with the connection loss, however from your description i am unsure what it is.

It is missing some probes indeed. Here is a module manager cfg which i THINK contanis everything: @PART[Commtow] { !MODULE[ModuleDataTransmitter] {} @MODULE[ModuleAnimateGeneric] { allowManualControl = false } MODULE { name = ModuleRTAntenna Mode0OmniRange = 0 Mode1OmniRange = 5000000 MaxQ = 3000 EnergyCost = 1.05 DeployFxModules = 0 TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } MODULE { name = ModuleSPUPassive } } @PART[LLLCommPole] { !MODULE[ModuleDataTransmitter] {} @MODULE[ModuleAnimateGeneric] { allowManualControl = false } MODULE { name = ModuleRTAntenna Mode0OmniRange = 0 Mode1OmniRange = 5000000 MaxQ = 3000 EnergyCost = 0.38 DeployFxModules = 0 TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } MODULE { name = ModuleSPUPassive } } @PART[LLLCommPole2] { !MODULE[ModuleDataTransmitter] {} @MODULE[ModuleAnimateGeneric] { allowManualControl = false } MODULE { name = ModuleRTAntenna Mode0OmniRange = 0 Mode1OmniRange = 3000000 MaxQ = 6000 EnergyCost = 0.38 DeployFxModules = 0 TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } MODULE { name = ModuleSPUPassive } } @PART[LLLRadar] { !MODULE[ModuleDataTransmitter] {} @MODULE[ModuleAnimateGeneric] { allowManualControl = false } MODULE { name = ModuleRTAntenna Mode0OmniRange = 0 Mode1OmniRange = 6000000 MaxQ = 3000 EnergyCost = 0.7 DeployFxModules = 0 TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } MODULE { name = ModuleSPUPassive } } @PART[LLLAttchDish] { !MODULE[ModuleDataTransmitter] {} MODULE { name = ModuleRTAntenna Mode0DishRange = 0 Mode1DishRange = 60000000000 EnergyCost = 1.86 DishAngle = 0.04 TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } MODULE { name = ModuleSPUPassive } } @PART[LLLAttchDishSmall] { !MODULE[ModuleDataTransmitter] {} @MODULE[ModuleAnimateGeneric] { allowManualControl = false } MODULE { name = ModuleRTAntenna Mode0DishRange = 0 Mode1DishRange = 50000000 EnergyCost = 1.64 MaxQ = 6000 DishAngle = 45.0 DeployFxModules = 0 ProgressFxModules = 1 TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } MODULE { name = ModuleSPUPassive } } @PART[LLLRotDish] { !MODULE[ModuleDataTransmitter] {} MODULE { name = ModuleRTAntenna Mode0DishRange = 0 Mode1DishRange = 60000000000 EnergyCost = 1.86 DishAngle = 0.04 TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } MODULE { name = ModuleSPUPassive } } @PART[LLLRotDish2-5] { !MODULE[ModuleDataTransmitter] {} MODULE { name = ModuleRTAntenna Mode0DishRange = 0 Mode1DishRange = 350000000000 EnergyCost = 5.70 DishAngle = 0.006 TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } MODULE { name = ModuleSPUPassive } } @PART[BERTY3] { MODULE { name = ModuleSPU } MODULE { name = ModuleRTAntennaPassive TechRequired = unmannedTech OmniRange = 3000 TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } } @PART[PolyRadar] { !MODULE[ModuleDataTransmitter] {} @MODULE[ModuleAnimateGeneric] { allowManualControl = false } MODULE { name = ModuleRTAntenna Mode0OmniRange = 0 Mode1OmniRange = 6000000 MaxQ = 3000 EnergyCost = 0.7 DeployFxModules = 0 TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } MODULE { name = ModuleSPUPassive } } @PART[2x1Probe] { MODULE { name = ModuleSPU } MODULE { name = ModuleRTAntennaPassive TechRequired = unmannedTech OmniRange = 3000 TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } } @PART[BERTYJEB] { MODULE { name = ModuleSPU } MODULE { name = ModuleRTAntennaPassive TechRequired = unmannedTech OmniRange = 3000 TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } } @PART[4x2Probe] { MODULE { name = ModuleSPU } MODULE { name = ModuleRTAntennaPassive TechRequired = unmannedTech OmniRange = 3000 TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } } Tbh i have yet to use LLL probe cores so they havent been tested but they SHOULD work. Comms equipment is fine assuming you like the values i used. Values are mostly a copy paste from various RT2 parts with the exception of making the radars into 6Mm omnis (this makes them the longest rng omnis out there).

Here is a module manager cfg i made for personal use... @PART[IRHingeOpenHalf] { TechRequired = generalConstruction entryCost = 0 } @PART[AdjustableRailHalf] { TechRequired = generalConstruction entryCost = 0 } @PART[IRHingeClosedHalf] { TechRequired = generalConstruction entryCost = 0 } @PART[IRHingeTallHalf] { TechRequired = generalConstruction entryCost = 0 } @PART[TelescopeHalfB] { TechRequired = generalConstruction entryCost = 0 } @PART[TelescopeHalfA] { TechRequired = generalConstruction entryCost = 0 } @PART[TelescopeHalfC] { TechRequired = generalConstruction entryCost = 0 } @PART[IR_RotatronHalf] { TechRequired = generalConstruction entryCost = 0 } @PART[IRHingeTallHalfND] { TechRequired = generalConstruction entryCost = 0 } @PART[IRPistonHalf] { TechRequired = generalConstruction entryCost = 0 } @PART[Gantry] { TechRequired = generalConstruction entryCost = 0 } @PART[GantryVariant] { TechRequired = generalConstruction entryCost = 0 } @PART[AdjustableRail] { TechRequired = advConstruction entryCost = 0 } @PART[IRHingeClosed] { TechRequired = advConstruction entryCost = 0 } @PART[IR_HingeIndustrial] { TechRequired = advConstruction entryCost = 0 } @PART[IRHingeOpen] { TechRequired = advConstruction entryCost = 0 } @PART[IRHingeTall] { TechRequired = advConstruction entryCost = 0 } @PART[IRHingeTallND] { TechRequired = advConstruction entryCost = 0 } @PART[IRPiston] { TechRequired = advConstruction entryCost = 0 } @PART[IR_Rotatron] { TechRequired = advConstruction entryCost = 0 } @PART[TelescopeFullA] { TechRequired = advConstruction entryCost = 0 } @PART[TelescopeFullB] { TechRequired = advConstruction entryCost = 0 } @PART[TelescopeFullC] { TechRequired = advConstruction entryCost = 0 } @PART[GantryLarge] { TechRequired = advConstruction entryCost = 0 } @PART[GantryLargeVariant] { TechRequired = advConstruction entryCost = 0 } @PART[AdjustableRailFourth] { TechRequired = specializedConstruction entryCost = 0 } @PART[IRHingeClosedFourth] { TechRequired = specializedConstruction entryCost = 0 } @PART[IRHingeOpenFourth] { TechRequired = specializedConstruction entryCost = 0 } @PART[IRHingeTallFourth] { TechRequired = specializedConstruction entryCost = 0 } @PART[IRHingeTallFourthND] { TechRequired = specializedConstruction entryCost = 0 } @PART[IRPistonFourth] { TechRequired = specializedConstruction entryCost = 0 } @PART[IR_RotatronFourth] { TechRequired = specializedConstruction entryCost = 0 } @PART[TelescopeFourthA] { TechRequired = specializedConstruction entryCost = 0 } @PART[TelescopeFourthB] { TechRequired = specializedConstruction entryCost = 0 } @PART[TelescopeFourthC] { TechRequired = specializedConstruction entryCost = 0 } @PART[GantrySmall] { TechRequired = specializedConstruction entryCost = 0 } @PART[GantryExtraSmall] { TechRequired = specializedConstruction entryCost = 0 } @PART[GantrySmallVariant] { TechRequired = specializedConstruction entryCost = 0 } @PART[GantryExtraSmallVariant] { TechRequired = specializedConstruction entryCost = 0 } @PART[dockingwasher_std] { TechRequired = specializedConstruction entryCost = 0 } @PART[dockingwasher_free] { TechRequired = specializedConstruction entryCost = 0 } @PART[dockingwasher_sr] { TechRequired = metaMaterials entryCost = 0 } @PART[dockingwasher_freesr] { TechRequired = metaMaterials entryCost = 0 } @PART[IR_HingeIndustrial] { TechRequired = metaMaterials entryCost = 0 } @PART[dockingwasher_jr] { TechRequired = advMetalworks entryCost = 0 } @PART[dockingwasher_freejr] { TechRequired = advMetalworks entryCost = 0 } @PART[IR_Rotatronmk2] { TechRequired = metaMaterials entryCost = 0 } @PART[IR_RotatronVTOL] { TechRequired = hypersonicFlight entryCost = 0 } It puts all the medium (half) parts in general construction, then all full size parts in advanced construction, then all quarter parts (fourth) in specialized construction. Washers come with appropriate size docking ports. Mk II rotatron and Industrial hinge come on Meta Materials (with docking port senior). VOTL rotatron comes on Hypersonic flight (with aerospikes). I decided to sort out parts acording to size rather then function beacuse i find that when i use one IR part i also need some other. For example when i need an adjustable rail, more often then not, i also need a hinge and/or a rotatron. So i wanted the tech tree functional but still with some need for tech progression. Hope you like it. If not, at least you can use the above as a template and save some work on making your own MM cfg for this.

What i would like to see is... The terrein bugs removed. So no more Mohole. But similar terrain features properly implemented. Meaning the addition of new, interesting and hand made holes, caves, canyons, gorges, ravines, pillars, etc. In general planetary terrain is rather bland, I would love to see the proper implementation of interesting terrain features on all bodies.

This sounds related to a known issue. As a workaround try retargeting the dishes on the "big" ship after decoupling or use the "target active ship" option on some dishes. In any case you may want to check out https://github.com/Cilph/RemoteTech2/issues/120