Shurikeeen Posted March 6, 2015 Share Posted March 6, 2015 RC-001S 1m probe core says it has 2km always active omni but it does not seem to work Link to comment Share on other sites More sharing options...
futrtrubl Posted March 7, 2015 Share Posted March 7, 2015 RC-001S 1m probe core says it has 2km always active omni but it does not seem to workIn what way does it not seem to work? Link to comment Share on other sites More sharing options...
palker Posted March 8, 2015 Share Posted March 8, 2015 Power consumption seems a bit excessive. I built a comms satellite with 2440 powers 1 omni 2 DTS-M1 dishes and when i turn them all at once the satellite dies after 25 minutes without power. The bloody thing looks like it is made from batteries and it still could not survive a single night on kerbin. Link to comment Share on other sites More sharing options...
WuphonsReach Posted March 8, 2015 Share Posted March 8, 2015 Power consumption seems a bit excessive. I built a comms satellite with 2440 powers 1 omni 2 DTS-M1 dishes and when i turn them all at once the satellite dies after 25 minutes without power. The bloody thing looks like it is made from batteries and it still could not survive a single night on kerbin.DP-10 is 0.01/sComm-16 is 0.13/sComm-32 is 0.60/sDTS-M1 is 0.82/sI'll assume (1) DP-10 + (1) Comm-16 + (2) DTS-M1 which is 1.78/s. So 2440 power / 1.78 = 1371 seconds (22.8 minutes).For something parked on the surface of Kerbin with a six hour day, plan on 3.5 hours (12600 seconds) of darkness. That's a worst-case number and might only matter if you are in a valley. So 12600 x 1.78 = 22428 battery required to last through the night.For satellites in orbit, the dark period calculation is driven by orbital altitude + gravity + radius. Higher orbits around a particular planetoid have longer dark periods.3000 km orbits (worst-case dark periods, rounded up):Moho = 2200sEve = 950sKerbin = 1250sMun = 2850sMinmus = 5000sDuna = 2150sDres = 3350sJool = 2350s (too far out for solar)Eeloo = 2800s (too far out for solar)Dres has the lowest gravity/ratio so has the longest dark periods for a particular orbit altitude around a major planet. Plus solar cells have a lower insolation value at that range from Kerbol. Link to comment Share on other sites More sharing options...
DrDam Posted March 9, 2015 Share Posted March 9, 2015 (edited) Hi all,I'm test RemoteTech since last friday, and I found it very cool, but I have many interrogations for optimize my network.First, I'm in carreer mode and I have just "Communotron 16", "Comms DTS-M1" and "Reflectron KR-7" antena, and I try to "consolidating" my "basic network" before more distant missionsI have a orbit with 4 satellites ( forming my "always-connection-source") actually, each target-configuration are :- 1 KR-7 targeting KSC - 1 KR-7 targeting the "next" satellite in the orbite - 1 KR-7 targeting the "previous" satellite in the orbite- 1 KR-7 "free".Reading connection-rules I don't know if my architecture is good.And The next question, if I launch a new satellite to a more distant orbit, what are the "good" antena-configuration to use for using my "ring" like a relay ? ( I imaging that are "targeting kerbin" with the hope that I intercepte connection of my "ring") And the same question for a lower orbiteThanksPS : May I have adding remoteTech-contract and restart my carreer ? DrDam Edited March 9, 2015 by DrDam Link to comment Share on other sites More sharing options...
hab136 Posted March 9, 2015 Share Posted March 9, 2015 Is it possible to make RT deactivate antennas temporarily when a vessel is out of electric power? It sucks to completely lose a probe because you turned on one too many antennas while you're in the outer system with insufficient solar power.Smart Parts will let you detect when your electricity is running low, then fire an action group. That action group could turn off everything and expand all solar panels; it could also trigger a timer Smart Part which would then re-enable all your antennas after a few minutes so that you can regain control once it's charged up.Alternatively, lock the electricity in your probe core (right-click on the probe core, click green triangle next to ElectricCharge bar so it turns red), and call it a reserve battery. Then if you're ever out of battery, just re-enable that battery and quickly fix the situation (since probe cores normally have 10 ElectricCharge and it will go fast). You could of course do the same thing with a larger battery. Link to comment Share on other sites More sharing options...
Drew Kerman Posted March 9, 2015 Share Posted March 9, 2015 Smart Parts will let you detect when your electricity is running low...Wait are you saying you can stick a Staging Controller on a battery?? OMG that makes perfect sense but thanks to how they are described in the game (and in the mod thread) I never thought to use them for anything but fuel. And yet EC is indeed a "resource" as far as the game is concerned. *bangs head against desk repeatedly* Link to comment Share on other sites More sharing options...
WuphonsReach Posted March 9, 2015 Share Posted March 9, 2015 I have a orbit with 4 satellites ( forming my "always-connection-source") actually, each target-configuration are :- 1 KR-7 targeting KSC - 1 KR-7 targeting the "next" satellite in the orbite - 1 KR-7 targeting the "previous" satellite in the orbite- 1 KR-7 "free".That's indeed one option, but you don't specify what orbital altitude you are using.The minimalist low Kerbin orbit (LKO) network consists of (4) satellites at 776km altitude (with orbital periods set to within 1/5th second of exactly 90 minutes). Each satellite has a Comm-16 and is 90 degrees apart. The omni-directional nature of the Comm-16 ensures that each satellite will automatically link to its neighbor and one of the four is always in view of KSC. All vessels launched would need to have at least a Comm-16.A slightly less minimalist four-sat configuration is to add a pair of DTS-M1 to each satellite and point them at Mun and Minmus. Plus a KR-7 that points at "active vessel".Another method is to put (8) Comm-16 satellites at 267km (45 minute) orbits. Or (6) Comm-16 satellites at 450km (60 minute orbit). The advantage of sats at these altitudes is that they are useful for giving a connection to a launch which only had a DP-10 active (500km range) where you forgot to deploy the longer range antennas.When it comes to Remote Tech "mesh" networks using the omnidirectional antennas around Kerbin, the "more the merrier". I usually have (8) at 267km, (6) at 450km and (4) at 776km. Plus a bunch of others at random orbital altitudes / inclinations between 100km and 500km. Anything that goes up with a battery, probe core and Comm-16 ends up as a spare LKO mesh node once I'm done with it (such as third stages).Eventually, I start shipping up satellites with Comm-32 at various altitudes between 100km and 3500km. Which fills in the network a bit more and gives my LKO mesh a very large footprint....You should also setup a pair of satellites in KEO above the KSC. These should have (1) Comm-16 and (4) DTS-M1 antennas. One points at KSC, one points at Mun, one points at Minmus and one points at "Active Vessel". Position them above KSC, about 2Mm apart (30-40 degrees) with an orbital period of exactly 6 hours (2869.75km orbital altitude).All future launches going to Kerbin/Mun/Minmus should have 1 or 2 DTS-M1 antennas that point at one or both of the KEO "active vessel" sats.Once you have the KR-14 unlocked, put up two more sats at KEO with (1) KR-14 and (3) DTS-M1. The KR-14 points at "active vessel" and the DTS-M1 triplet points at KSC/Mun/Minmus. Leave the old KEO sats in place as redundant links back to KSC. The KR-14 will reach Duna/Dres/Eve/Moho.Then you unlock the GX-128 and you put up yet another pair of sats at KEO with the Comm-32, a pair of DTS-M1 (Mun/Minmus) and the GX-128 pointing at "Active Vessel". That gives you something which can reach Jool and Eeloo orbits....There are dozens of ways to setup sat networks - you'll learn with trial and error. The important bit is that if you want A and B to talk to each other, A must have an antenna that has the range to reach B and B must have an antenna with the range to reach back to A. If they are directional antennas, then both A and B must have antennas pointing at each other. Link to comment Share on other sites More sharing options...
O Nerd Posted March 9, 2015 Share Posted March 9, 2015 (edited) Hey guys, I have a doubt about the Root range model. From what I understood, each 2 antennas, say, with a 10 km range, it will sum up at a 10 km range. If I double them 2, will that be 20 km?EDIT: Sorry, just found the information i was looking for. Edited March 10, 2015 by O Nerd Link to comment Share on other sites More sharing options...
Enceos Posted March 10, 2015 Share Posted March 10, 2015 (edited) Hello guys, can anyone tell me please where can I grab a version of RemoteTech that works with action queuing from Action Groups Extended? I think it's 1.7.0 Edited March 10, 2015 by Enceos Link to comment Share on other sites More sharing options...
undercoveryankee Posted March 10, 2015 Share Posted March 10, 2015 Hello guys, can anyone tell me please where can I grab a version of RemoteTech that works with action queuing from Action Groups Extended? I think it's 1.7.01.7 is still in pre-release. You can get pre-release builds from https://github.com/RemoteTechnologiesGroup/RemoteTech/releases , but they have not been tested as thoroughly as 1.6.3 and may contain bees. Link to comment Share on other sites More sharing options...
Enceos Posted March 10, 2015 Share Posted March 10, 2015 1.7 is still in pre-release. You can get pre-release builds from https://github.com/RemoteTechnologiesGroup/RemoteTech/releases , but they have not been tested as thoroughly as 1.6.3 and may contain bees.If only I could disable the debugging. All those pre-release versions have debugging enabled which generates an immense amount of log entries in the output_log.txt Link to comment Share on other sites More sharing options...
spookydonut Posted March 11, 2015 Share Posted March 11, 2015 (edited) I created a pull request: https://github.com/RemoteTechnologiesGroup/RemoteTech/pull/363It adds a config option to enable network only mode, where unconnected, powered, unmanned ships can still be controlled.For people who like building networks but not the loss of control.https://www./?fu6ubbn6e4qbtrd .dll only for testing, distributing under gpl2 same as RT Edited March 11, 2015 by spookydonut Link to comment Share on other sites More sharing options...
DrDam Posted March 11, 2015 Share Posted March 11, 2015 @WuphonsReach : thanks for your advices ... my "orbital ring" are on line .... Link to comment Share on other sites More sharing options...
tntristan12 Posted March 11, 2015 Share Posted March 11, 2015 I just set up my Rhodium satellite network! I increased the range of the Reflectron from 500km to 560km in the .cfg file which allowed me to place 45 satellites in 5 polar orbits spaced evenly around Kerbin. Using just the omnidirectional antennae each satellite can maintain a constant link with adjacent satellites on their own orbit, or satellites passing by in either adjacent orbital plane. Each sat is at 200km in altitude.The end result is that I have full network coverage of every point in space from the surface of Kerbin all the way out to an altitude of about 500km. At 500km, I have a trio of mid-range signal boosters in an equatorial orbit (spaced out by 120 degrees each). Each booster contains four monodirectional antennae: one pointed at the Mun, one to Minmus, one to the active vessel, and one which I intend to point to the final piece in my communications array: a long-range comm station that will boost the signal out to interplanetary ranges! Link to comment Share on other sites More sharing options...
aggressorblue Posted March 11, 2015 Share Posted March 11, 2015 Hey guys, need some help with sat placement:In reading across the tutorial here:http://remotetechnologiesgroup.github.io/RemoteTech/tutorials/c16network/This paragraph has me confused:The second and third satellites are the hardest, because you need to synchronize them both with your previous satellite(s) and with Kerbin’s rotation. Launch each satellite into low Kerbin orbit. Use the map view to select the previous satellite in the network as the target. Set a maneuver node that reaches an apoapsis of 777 km; a rendezvous marker should appear, telling you how far your satellite will be from the target at apoapsis. Adjust the maneuver node’s position until this distance is close to 1947 km. It doesn’t have to be exact.I'm not following the bold text bit. How does one adjust the node so that the distance from the target will change at the aposis? I mean, I know that I can set the Apsis by dragging the pro grade icon, but that just changes the alt of the aposis, not the distance from the target it is. Link to comment Share on other sites More sharing options...
futrtrubl Posted March 11, 2015 Share Posted March 11, 2015 Hey guys, need some help with sat placement:In reading across the tutorial here:http://remotetechnologiesgroup.github.io/RemoteTech/tutorials/c16network/This paragraph has me confused:The second and third satellites are the hardest, because you need to synchronize them both with your previous satellite(s) and with Kerbin’s rotation. Launch each satellite into low Kerbin orbit. Use the map view to select the previous satellite in the network as the target. Set a maneuver node that reaches an apoapsis of 777 km; a rendezvous marker should appear, telling you how far your satellite will be from the target at apoapsis. Adjust the maneuver node’s position until this distance is close to 1947 km. It doesn’t have to be exact.I'm not following the bold text bit. How does one adjust the node so that the distance from the target will change at the aposis? I mean, I know that I can set the Apsis by dragging the pro grade icon, but that just changes the alt of the aposis, not the distance from the target it is.You can physically drag the maneuver node itself backwards and forwards on the orbit. Link to comment Share on other sites More sharing options...
aggressorblue Posted March 11, 2015 Share Posted March 11, 2015 (edited) You can physically drag the maneuver node itself backwards and forwards on the orbit.EDIT: Yup, that worked, for some reason it wouldn't let me do that last night when I playing. Today clicking the node and dragging worked fine.Odd....Thanks! Edited March 11, 2015 by aggressorblue Link to comment Share on other sites More sharing options...
khearn Posted March 11, 2015 Share Posted March 11, 2015 Move your mouse over the node and watch for the center circle to get brighter, then left-drag it. Disclaimer: The above is from memory, I'm at work and can't confirm it, but I think that's right. I know the center circle is what brightens and is what gets dragged. Link to comment Share on other sites More sharing options...
firefrog Posted March 12, 2015 Share Posted March 12, 2015 Howdy folks,I'd need a little help with some kind of bug I found: I launched a Probe with a Computer Core from Interstellar mod. Now this one seems not to be implemented with RT and is missing some marker saying it is unmanned. Is it possible to fiddle in the .cfg of either the part itself or inside one of RT's config files, marking which pods are locally controlled and which ones are not? I already compared the .cfg of the Computer Core with a stock one (which is regarded as not-locally controlled), but could not find the sweet spot. Any ideas?Cheersff Link to comment Share on other sites More sharing options...
freakneek Posted March 12, 2015 Share Posted March 12, 2015 (edited) Sorry if this has been posted before but i cbf going through x number of posts. Concerning the kso mechjeb ive ran into some issues where it stays under local control. I like to use it on most my craft espically my comsats, its smaller and less ugly. After some digging around in mechjeb 2 (where the kso mechjeb part files are), and the remotetech folders i found a file called: RemoteTech_MechJeb.cfg in the remotetech folder it looks like this... //Support for MechJeb probe core// Original config by Cilph@PART[mumech_MJ2_AR202]:HAS[!MODULE[ModuleSPU]]:AFTER[MechJeb2]:NEEDS[RemoteTech]{ // Append tag to the existing part name @title ^= :$: (ModuleSPU): MODULE { name = ModuleSPU }}So i opened it with my trusty notepad++ i added this code to it...@PART[mechjebkso]:HAS[!MODULE[ModuleSPU]]:AFTER[MechJeb2]:NEEDS[RemoteTech]{ // Append tag to the existing part name @title ^= :$: (ModuleSPU): MODULE { name = ModuleSPU }} So now it looks like...// Support for MechJeb probe core// Original config by Cilph@PART[mumech_MJ2_AR202]:HAS[!MODULE[ModuleSPU]]:AFTER[MechJeb2]:NEEDS[RemoteTech]{ // Append tag to the existing part name @title ^= :$: (ModuleSPU): MODULE { name = ModuleSPU }}//Support for KSO MechJeb //Added in by freakneek@PART[mechjebkso]:HAS[!MODULE[ModuleSPU]]:AFTER[MechJeb2]:NEEDS[RemoteTech]{ // Append tag to the existing part name @title ^= :$: (ModuleSPU): MODULE { name = ModuleSPU }}Saved it as the same name (RemoteTech_MechJeb.cfg) and tested....KABOOM! it now has RemoteTech support and works.Hope this helps people who use the kso mechjeb. Could this be added in the next release? It would be my first contribution to ksp since i started 2 years ago.Thanks for the great mod and plugin and i hope my spoiler tags work im posting on my mobile phone :-p Edited March 12, 2015 by freakneek edited spoiler tags Link to comment Share on other sites More sharing options...
syngts Posted March 12, 2015 Share Posted March 12, 2015 Hello guys!I seem to have run in some issue with Remote Tech. I set up 3 satellites in Keosync orbit and they worked fine until I docked another ship to the one above the KSC. Now, the other 2 get no connection from it and the antenna that used to connect them to the first one shows Unknown target as the target. Is there any way to prevent/fix this without editing the save file? Thank you! Link to comment Share on other sites More sharing options...
WuphonsReach Posted March 12, 2015 Share Posted March 12, 2015 Hello guys!I seem to have run in some issue with Remote Tech. I set up 3 satellites in Keosync orbit and they worked fine until I docked another ship to the one above the KSC. Now, the other 2 get no connection from it and the antenna that used to connect them to the first one shows Unknown target as the target. Is there any way to prevent/fix this without editing the save file? Thank you!When you dock (2) vessels together, their IDs both get changed (they might get the old IDs back after you undock).So... don't do that You can get away with it on vessels with omnidirectional (Comm-16 / Comm-32) links or on vessels that are linked because each side is around a different orbital body and their directional antennas point at the other orbital body. (i.e. vessels around Mun/Kerbin, pointing at Kerbin or the Mun) Link to comment Share on other sites More sharing options...
syngts Posted March 13, 2015 Share Posted March 13, 2015 Well thanks for the reply. Kinda hoped there'd be a fix for this, but i figured a quick workaround would be to always keep a satellite in low orbit to reset the connections..takes a while but it works Link to comment Share on other sites More sharing options...
firefrog Posted March 13, 2015 Share Posted March 13, 2015 Sorry if this has been posted before but i cbf going through x number of posts. Concerning the kso mechjeb ive ran into some issues where it stays under local control. I like to use it on most my craft espically my comsats, its smaller and less ugly. After some digging around in mechjeb 2 (where the kso mechjeb part files are), and the remotetech folders i found a file called: RemoteTech_MechJeb.cfg in the remotetech folder it looks like this... //Support for MechJeb probe core// Original config by Cilph@PART[mumech_MJ2_AR202]:HAS[!MODULE[ModuleSPU]]:AFTER[MechJeb2]:NEEDS[RemoteTech]{ // Append tag to the existing part name @title ^= :$: (ModuleSPU): MODULE { name = ModuleSPU }}So i opened it with my trusty notepad++ i added this code to it...@PART[mechjebkso]:HAS[!MODULE[ModuleSPU]]:AFTER[MechJeb2]:NEEDS[RemoteTech]{ // Append tag to the existing part name @title ^= :$: (ModuleSPU): MODULE { name = ModuleSPU }} So now it looks like...// Support for MechJeb probe core// Original config by Cilph@PART[mumech_MJ2_AR202]:HAS[!MODULE[ModuleSPU]]:AFTER[MechJeb2]:NEEDS[RemoteTech]{ // Append tag to the existing part name @title ^= :$: (ModuleSPU): MODULE { name = ModuleSPU }}//Support for KSO MechJeb //Added in by freakneek@PART[mechjebkso]:HAS[!MODULE[ModuleSPU]]:AFTER[MechJeb2]:NEEDS[RemoteTech]{ // Append tag to the existing part name @title ^= :$: (ModuleSPU): MODULE { name = ModuleSPU }}Saved it as the same name (RemoteTech_MechJeb.cfg) and tested....KABOOM! it now has RemoteTech support and works.Hope this helps people who use the kso mechjeb. Could this be added in the next release? It would be my first contribution to ksp since i started 2 years ago.Thanks for the great mod and plugin and i hope my spoiler tags work im posting on my mobile phone :-pSo what exactly does this change do? And if it does what I think it does (marking the part as remote-controlled device?), can I just take that "name = ModuleSPU"-part for my Computer Core?/edit: and what part would I need to take? What about the @PART and @title lines, or would the Module {...} stuff suffice? Link to comment Share on other sites More sharing options...
Recommended Posts