[1.1] RemoteTech v1.6.10 [2016-04-12]

[Pirsig]

:FOR is basically defining a patch name, because if it doesn't exist, it creates it, so a wildcard would not be acceptable I don't think.

[undercoveryankee]

Not to butt in but ( :for[RemoteTech*] ) wouldn't that fix your example Starstrider42 for not wanting to change doesn't a wildcard work ?

EDIT- just incase you rename the dll RemoteTech3 or RemoteTech9 what ever ?

There are no wildcards in pass names for two reasons that I can think of:

1. If there's more than one pass that matches the wildcard, how do you decide which of the candidate passes gets the wildcard patch?
   
2. A :FOR clause naming a pass that doesn't otherwise exist is enough to create that pass group. What do you call the newly created pass group if the :FOR that created it has a wildcard?
   

[RedAV8R]

@starstrider42: This is going to be somewhat biased, but why not leave RemoteTech MM patches as :FIRST rather than a :FOR[whatever]?

The bias comes from RealismOverhaul now having to change the way it's modifies RT2 stuff. It'll get done, but is going to take some work. Seems like a mod such as RT2 would want to have it make changes before everybody else makes their changes, rather than the other way around.

[Pirsig]

So yeah, wildcard is not a solution, but I really think that in general that issue is not a real problem. it would take less than five mins to run through every config with a text replacer and change all instances of "RemoteTech2" to "RemoteTech3" or whatever.

[Pirsig]

@starstrider42: This is going to be somewhat biased, but why not leave RemoteTech MM patches as :FIRST rather than a :FOR[whatever]?

The bias comes from RealismOverhaul now having to change the way it's modifies RT2 stuff. It'll get done, but is going to take some work. Seems like a mod such as RT2 would want to have it make changes before everybody else makes their changes, rather than the other way around.

I believe the idea is to keep as much out of :FIRST and :FINAL as possible. If a patch doesn't NEED to run there it probably shouldn't.

[erendrake]

I believe the idea is to keep as much out of :FIRST and :FINAL as possible. If a patch doesn't NEED to run there it probably shouldn't.

Agreed, if the cfgs are for RemoteTech, they should be in :FOR[RemoteTech]

I think the dll name should be changed to RemoteTech, version doesnt need to be in the title.

[Tadeáš]

Sorry, but we need more detail than that. Are you using 64-bit KSP (which is pretty unstable, with or without mods) or 32-bit (which should work)? Can you upload a copy of your KSP_Data/output_log.txt or KSP_x64_Data/output_log.txt to a site like Gist or pastebin so we can check for error messages?

Well, if you're getting a "no connection" error, that would suggest that the mod is correctly installed, at least.

What antennas are you using? Are you using RSS?

Yes, I use Real Solar System mod and I used both stock and RemoteTech2 antennas. I just attach them to probe core and then I try to launch them with clamp. On launchpad with clamp it shows "Local control", but after separation of clamp I don´t have any connection even when I activate antennas.

[Mecripp]

Yes, I use Real Solar System mod and I used both stock and RemoteTech2 antennas. I just attach them to probe core and then I try to launch them with clamp. On launchpad with clamp it shows "Local control", but after separation of clamp I don´t have any connection even when I activate antennas.

Did you get the RSS RT2 setting files from somewhere ?

EDIT- There is a readme file to help with install https://dl.dropboxusercontent.com/u/72893034/RT2_RSS.zip

Edited September 29, 2014 by Mecripp2

[RedAV8R]

I believe the idea is to keep as much out of :FIRST and :FINAL as possible. If a patch doesn't NEED to run there it probably shouldn't.

Keeping things out of :FINAL I get, no need for it. At the same time though I don't see a see a reason why something can't be in :FIRST.

[Pirsig]

Keeping things out of :FINAL I get, no need for it. At the same time though I don't see a see a reason why something can't be in :FIRST.

Say someone needs their config to run before RT2, for whatever reason, now they have to run actually run before :FIRST which I'm not even sure you can do, never tried. The only other way then to guarantee you'd go before RT2, as I understand it, is to start doing things like naming your config 000_whatever.cfg to make sure it runs before RT2's do in the first pass. There's less cases where it'd be necessary to do, but it's the same reason for keeping things out of :FINAL really.

EDIT: Also, without conditionals in pass names expected order is incredibly important.

Edited September 29, 2014 by Pirsig
additional thoughts

[RedAV8R]

Say someone needs their config to run before RT2, for whatever reason, now they have to run actually run before :FIRST which I'm not even sure you can do, never tried. The only other way then to guarantee you'd go before RT2, as I understand it, is to start doing things like naming your config 000_whatever.cfg to make sure it runs before RT2's do in the first pass. There's less cases where it'd be necessary to do, but it's the same reason for keeping things out of :FINAL really.

EDIT: Also, without conditionals in pass names expected order is incredibly important.

Great point, just :FINAL in reverse I suppose. Guess I've got more work to do when released. I do completely agree with the :FOR[*] issue. One of two things should happen. Either the *.dll removing the version number in it's name, thus becoming RemoteTech.dll OR RT2's MM files being changed to :FOR[RemoteTech2] to match the *.dll.

As it stands the decision of :FOR will cause MM to make 2 passes involving RT2. One :FOR[RemoteTech2] and then later after all *.dll matching :FOR's have been done it will make another :FOR[RemoteTech] pass which actually changes things. Confusing, unfriendly, and unnecessary.

[Starstrider42]

Wow, I definitely did not expect to trigger a huge discussion.

I don't really get what the complaint could be, but whatever. As for the the :FOR's, perhaps I should clarify what I mean by proper association. Obviously it will work fine if you call it RemoteTech, you could have a different pass name on every config if you wanted. That doesn't fit with the naming conventions defined by MM though. That means that someone has to actually go look at your configs to find out some are running in first and some are running in RemoteTech, neither of which are the expected RemoteTech2 pass (to match the dll and folder name). It doesn't break anything to do it your way, but it's not friendly to other modders either.

In my experience, it's easier to look at what name is used in a mod's included config files than it is to figure out which DLL is the "main" one for a mod, especially if there are no DLLs or multiple DLLs from bundled mods (granted, neither of those applies to RT, but seeing it in other mods encourages certain config-writing habits).

If some patches are running in :FIRST, please point to specific examples. I made a point of changing each and every patch to use :FOR, and nobody found anything missing before it got merged.

I think the ModuleManager developers do recommend using your folder/plugin name as your :FOR pass, so other patch authors don't have to read your config files to know what pass you're running in. If you would like to keep a uniform pass name between versions that might have different folder/plugin names, that makes sense too, but I would recommend that it be pretty prominent in any "for mod authors" documentation.

That's a good point. I started writing up the for modders documentation this weekend, and I'll make sure the :FOR convention (whichever it ends up being) is up at the very top.

So yeah, wildcard is not a solution, but I really think that in general that issue is not a real problem. it would take less than five mins to run through every config with a text replacer and change all instances of "RemoteTech2" to "RemoteTech3" or whatever.

Except somebody needs to realize that their configs are broken, and make the changes, and release them. There are plenty of widely used but rarely updated mods out there. And not so out there. Better to make a system that's robust to changes in the modding scene from the very beginning.

Seems like a mod such as RT2 would want to have it make changes before everybody else makes their changes, rather than the other way around.

As far as I know, there are no mods that RT needs to appear before/after. The only conflict I can think of is if somebody were to use MM to add a ModuleDataTransmitter to another mod's antenna, and I don't really see that happening.

One of two things should happen. Either the *.dll removing the version number in it's name, thus becoming RemoteTech.dll OR RT2's MM files being changed to :FOR[RemoteTech2] to match the *.dll.

I agree that renaming RemoteTech2.dll to RemoteTech.dll would simplify things a lot. I'll bring up the possibility with the dev team, though I suspect it might meet some resistance from people who want there to be no confusion with JDP's original RemoteTech.

Edited September 29, 2014 by Starstrider42

[RedAV8R]

@starstrider42:

While it may be easy to read other configs, I won't disagree. I do believe that at least the main folder name of the mod and the :FOR[*] should be the same, that's an even easier thing to see.

While I know of nothing that mods RT before, I know at least RealismOverhaul modifies a lot of what RT touches afterwards. With the :FOR[RemoteTech*] tag, because of naming conventions, "Rem" comes after "Rea" and so therefore, we will have to specifically make new configs for parts touched by RemoteTech with AFTER:[RemoteTech*] in order make changes to distances/power/etc. If that's the way it is, so be it, we'll make the changes. I'm still in the boat of leave things alone.

[Superfluous J]

I'm convinced this is my fault because I've never used this mod before, but I can't figure out what I'm doing wrong or if the mod isn't working the way it's supposed to, or if I'm just expecting something different than there is.

I've got a ship just outside of Kerbin's SOI (I sent it there to test communications). It's robotic and has a Communotron 32 and a Reflectron KR-7 (pointed at mission control). I have satellites in LKO that give full coverage to KSC. They can all talk to KSC at all times. In particular, 2 of them are orbiting at 1,000km on opposite sides, and they each have KR-14s, pointed at the Active Vessel. At no time do I see cones in my map view like I've seen in YouTube videos where people use this mod.

My ship that is now just outside of Kerbin's SOI was fine until somewhere on the way out - I expect when the 32 went out of range. From that point on it's dead. I double checked the satellites and they are set to point at the current vessel (they weren't, but I set them, does that matter?) and I still can't talk to the probe.

I'm at a loss. If I can't get dishes to work this save is essentially torpedoed, as RT2 was a cornerstone mod. Any ideas?

[lodestar]

I've got a ship just outside of Kerbin's SOI (I sent it there to test communications). It's robotic and has a Communotron 32 and a Reflectron KR-7 (pointed at mission control). I have satellites in LKO that give full coverage to KSC.

Antennas must be pointing at each other for a link to be established. Your problem seems to be that you are pointing the KR-7 at mission control, but expecting the signal to be relayed by the satellites. That won't work. You should get it to work if you point the KR-7 at Kerbin, so you should link with the visible satellite, or you can point the KR-7 at one of the satellites, and it will work half the time.

At no time do I see cones in my map view like I've seen in YouTube videos where people use this mod.

Cones are shown when you point a dish at planets and moons. A ship within the cone and in the SOI of the body gets the signal.

[J3ansley]

I've got a ship just outside of Kerbin's SOI (I sent it there to test communications). It's robotic and has a Communotron 32 and a Reflectron KR-7 (pointed at mission control). I have satellites in LKO that give full coverage to KSC. They can all talk to KSC at all times. In particular, 2 of them are orbiting at 1,000km on opposite sides, and they each have KR-14s, pointed at the Active Vessel.

What Lodestar said. Your reflectron KR-7 Probe should point to "Kerbin" so as to pick up any satellites in that SOI that are within the angle of the cone. The satellites that you have as acting relays should either point to "current Vessel", the Reflectron Probe, or in this case "Kerbol" (sun). The Sun setting isn't very good I don't think as the SOI area is significantly larger than any area the relay probe cones will provide.

Personally, I favor setting the Probe vessel focus on Kerbin and 2 of my relays around Kerbin to that probe.

[Superfluous J]

Oh. I thought the cone would work at all times regardless of where I aimed it, and it would just center on KSC instead of centering on Kerbin's center.

Oh well, the ship wasn't that expensive anyway and working out kinks like this is exactly why I did this instead of waiting for my Duna launch window.

Thanks, you both get some rep!

[AetherGoddess]

What Lodestar said. Your reflectron KR-7 Probe should point to "Kerbin" so as to pick up any satellites in that SOI that are within the angle of the cone. The satellites that you have as acting relays should either point to "current Vessel", the Reflectron Probe, or in this case "Kerbol" (sun). The Sun setting isn't very good I don't think as the SOI area is significantly larger than any area the relay probe cones will provide.

Personally, I favor setting the Probe vessel focus on Kerbin and 2 of my relays around Kerbin to that probe.

so I've had to deal with this pretty extensively recently, as i upgraded from stock communications to RT2 in the middle of a late game, and had to deploy a lot of networks quickly, and I've come to some general guidance that might help:

1. Create a relay network for the KSC: an ideal relay network is at Kerbo-synchronous height (2,868.75 km for stock), but can be anywhere provided the orbits are close enough to each other that they stay roughly equidistant from each other. I find half-synchronous height (1,508 km) is useful, because you can use the long extending omni (CommTech EXP-VR-2T) to communicate across the whole orbit.
   
2. 3 satellites are the minimum, but i find 4 is easier, esp if you have shorter antennas.
   
3. Each element in the relay network should have at least three, but preferably 4, antenna. one large omni for local communication, and a large dish for active vessel. if your network is large or sparse, you might add two small dishes to connect to the previous and next satellites in the network.
   
4. For each satellite, point one dish at the KSC, one at the next satellite in orbital order, one at the previous, and if possible, one at the active vessel. omnis with good range are best for the other satellites and KSC downlink, since omnis will support multiple connections over short ranges, but a big long range dish like the Reflectron GX-128 is best for the active vessel.
   
5. each sat should be 360/N degrees away from the others. 360/3=120 deg for 3 sat networks , 360/4=90 deg for 4 sats, 360/5 = 72 deg for 5, etc.
   
6. When positioning satellites, target the next or previous satellite in the network, and raise your apoapsis until it just touches the orbit, and look at position of the next intersect. if you are starting from a lower circular orbit, like a standard 100 km parking orbit, you can drag the maneuver around your current orbit till it lines up.
   
7. Alternatively, you can set a maneuver node at the AP where your current orbit intersects the target orbit and adjust the periapsis (with prograde and retrograde) until the "target position at intersect" is at the right angle. burn this maneuver and orbit around till your in the right position, and circularize into your final orbit. This is a great trick for deploying multiple sats from one craft, since you can release a sat, target it, lower your PE till the positioning is right, burn, orbit, and re-circularize to release the next.
   
8. When you are ready to connect to other planets or muns (or if you need to add more satellites for active vessel because you didn't have enough dishes before), add two more satellites to the KSC network, orbiting opposite each other.
   
9. they will be added to the relay network in-between other sats, but don't move any other sats around. this is where omni's for in-network relay helps, because otherwise you need to repoint 4 dishes per added satellite.
   
10. these new relay satellites should have a longer range dish pointed at the target mun or planet (or vessel).
    
11. Set up a 3 or 4 comsat network orbiting the target body, with one omni for local communication, two antenna (omnis or dishes) for network relay, and one longer range dish pointed at kerbin, not KSC, so they also hit the relay network.
    
12. any vessels that want to use the relay network just need to point to Kerbin and use the Active vessel uplinks, or point to a local relay and use the local communication omni.
    

Two fun things to watch:

, and

.

ONE MORE THING: if you use ScanSAT, communications satellites make great mapping satellites. set them up in a polar orbit and watch the map collect.

Edited September 30, 2014 by AetherGoddess
Edits for omnis confirmed

[Superfluous J]

3. Each element in the relay network should have at least three, but preferably 4, antenna.

4. For each satellite, point (or just count for omnis) one antenna at the KSC, one at the next satellite in orbital order, one at the previous, and if possible, one at the active vessel. omnis with good range are best for the other satellites and KSC downlink, but a big long range dish like the Reflectron GX-128 is best for the active vessel.

I don't see a way to "point" the omnidirectional antennae and I don't see any reason to have more than one. My current network only has 1 antenna and one dish and it seems to work fine. Am I going to have blackouts because I don't have enough antennae?

Edited September 30, 2014 by 5thHorseman

[undercoveryankee]

I don't see a way to "point" the omnidirectional antennae and I don't see any reason to have more than one. My current network only has 1 antenna and one dish and it seems to work fine. Am I going to have blackouts because I don't have enough antennae?

No, in the default settings, there are no advantages to multiple omni antennas. One omni of the longest range you want to use is all you need. Some of the alternate range models give you a range benefit from having several, but someone who uses those can go into more detail. You're fine with one omni.

[AetherGoddess]

I don't see a way to "point" the omnidirectional antennae and I don't see any reason to have more than one. My current network only has 1 antenna and one dish and it seems to work fine. Am I going to have blackouts because I don't have enough antennae?

That's weird, all of my networks required multi omnis to have multiple concurrent connections. Maybe i missed something, but i thought you needed an omni to talk to the upstream relay, and a seperate to talk to the downstream target. i might be mistaken; Please let me know, some of those antenna are expensive.

[komodo]

That's weird, all of my networks required multi omnis to have multiple concurrent connections. Maybe i missed something, but i thought you needed an omni to talk to the upstream relay, and a seperate to talk to the downstream target. i might be mistaken; Please let me know, some of those antenna are expensive.

...No, I think one should "do it all" as it were. An omni, at least on my networks will link to any/all stations within the signal sphere.

[Superfluous J]

That's weird, all of my networks required multi omnis to have multiple concurrent connections. Maybe i missed something, but i thought you needed an omni to talk to the upstream relay, and a seperate to talk to the downstream target. i might be mistaken; Please let me know, some of those antenna are expensive.

Here's a little pic of my burgeoning network over Kerbin. There are 6 total satellites. The 4 inner ones have a single Comm16 and a single KR-7 each, and the 2 outer ones have a single Comm32 and a single KR-14 each. The blue orbit is the current vessel, it's actually the probe I lost contact with. It can be ignored. You can see that there are multiple communication lines between each satellite and they all seem to be connecting fine even though each only has 2 total comms devices, and one of them is aimed at "active vessel". The entire network is communicating with itself via just 7 antennae - one on each satellite and one at KSC.

[AetherGoddess]

http://pulpaudio.com/ksp/network.jpg

Here's a little pic of my burgeoning network over Kerbin. [...]

Fixed. and i can make my next network out of much simpler comms

[Pirsig]

In my experience, it's easier to look at what name is used in a mod's included config files than it is to figure out which DLL is the "main" one for a mod, especially if there are no DLLs or multiple DLLs from bundled mods (granted, neither of those applies to RT, but seeing it in other mods encourages certain config-writing habits).

If a mod doesn't have a .dll file they're supposed to match their folder name, since MM also makes pass names based on that. This would seem like a good solution for the few mods with multiple .dlls as well. Why should this be yet another mod that doesn't follow the defined naming conventions? MM has defined naming conventions for this, we should follow them.

If some patches are running in :FIRST, please point to specific examples. I made a point of changing each and every patch to use :FOR, and nobody found anything missing before it got merged.

At least on the master branch that's on git right now, everything that's not the new FASA configs runs in :FIRST because they don't have any :FOR statement at all.

Except somebody needs to realize that their configs are broken, and make the changes, and release them. There are plenty of widely used but rarely updated mods out there. And not so out there. Better to make a system that's robust to changes in the modding scene from the very beginning.

This is a mildly valid point, but in my opinion strengthens the argument of renaming the .dll and folder to RemoteTech. I also don't personally think that doing something solely for the benefit of mods that don't keep themselves up to date is the best idea.

As far as I know, there are no mods that RT needs to appear before/after. The only conflict I can think of is if somebody were to use MM to add a ModuleDataTransmitter to another mod's antenna, and I don't really see that happening.

That's not the point, what if someone finds a reason to? I totally admit the likelihood is low, but why make it harder if someone does want to when there's no reason for it?

I agree that renaming RemoteTech2.dll to RemoteTech.dll would simplify things a lot. I'll bring up the possibility with the dev team, though I suspect it might meet some resistance from people who want there to be no confusion with JDP's original RemoteTech.

Kind of figured this was the case and that's why I wasn't personally suggesting a .dll rename. That being said, I also think the chance for confusion is low considering JDP's has been out of dev since .20 and states it clearly on the forum thread. You can also keep the Forum thread name and such as Remote Tech 2 with the .dll/folder still being RemoteTech.