Cilph

Guilt-tripping me are you now? Fine, I'll get some work in tonight. Don't hit me. joking

Ah, but it's definitely related: that shuttle has a cargo bay for satellite deployment =D.

It'll have to wait because I'm thoroughly enjoying my first KSP missions in months. MONTHS I TELL YE. http://i.imgur.com/OdOmIIu.jpg

You could mimic Active Vessel with the new group system though. Active Vessel was made for endpoints in static satellite networks. You could simply have them all point at a single group and have your crafts subscribe to that group. The group system would be more tolerant to decoupling. Setting a satellite's group would store (I say this because I haven't implemented it) the group data in all the signal processors on the craft. Ergo, group data is preserved on decoupling. Still need to think of how to propagate group information on docking, but not a biggy.

Should I just remove Active Vessel or what?

RT2 has a lot of glitches with 0.23, but I don't think errors in routing was ever one of them. Well, aside from docking/decoupling issues that should be fixed now on my local version. Again. For the fifth or so time. I swear that bug keeps popping up.

Nowadays it's the MultipleAntennaMultiplier and RangeModelType.

Relevant code: https://github.com/Cilph/RemoteTech2/blob/master/src/RemoteTech2/RangeModel/RangeModelRoot.cs , but yes, roughly what you're saying.

RangeModel = Root in the cfg file, by NathanKell

I think I'll be playing KSP tonight for the first time in three months. We modders barely if ever get to play KSP anymore .

Planets use a Guid/PID derived/generated from their name. It's a bit of a hocus pocus. Might make them settable in the config file.

Never going to happen.

Thought about it, and if the current hotfix works, I see no point in doing it myself. I just don't have the time. It annoys me that the 0.23 release turned out to be such a disaster, but the 0.24 release will make up for it.

No ETA. Probably around 0.24. There's stuff I want to implement and even less time to work. For example I started rewriting the core routing logic today to increase performance. I'm not sure how to handle crafts that are both unmanned but contain no RT2 support such as signal processor modules in the probe bodies or antennas, so behaviour there might be a bit finnicky. The "RTLock*" is visible because I intercept all calls and execute them myself. You should definitely be able to stage an unmanned craft where RT2 functionality is integrated, so let me know if that isn't working. The staging light should be activated at all times since I'm technically locking it.

The antennas consume ElectricCharge per second, so that would make stock consumption more like Amperes.

Sheesh, it was an oversight. Never thought people would bring that up so often. It's on the/a list.

"Anything in range" is a cone of 0.5 degrees on a range from Kerbin to Duna. Most dishes are balanced to have a cone with the width of Kerbin-Mun at max range, giving some use to the cheaper/worse dishes in lower ranges. As for your comment on Option 3: the way I proposed is the easiest way to implement it, just by adding the edges to the network graph and having the pathfinder sort it out. Limiting it to one connection brings up a load of other issues related to priority.

You mean 0.75 units/s on the first available solar panel. I've already halved the consumption twice (quartered? quadr-alved?)

https://github.com/Cilph/RemoteTech2/issues?state=open I stopped paying attention to bug reports on the forums weeks ago. I have enough trouble memorizing what to do as is.

It works like Mode 1 (planet targeting), but focused on a satellite instead of a planet. It will form a connection with anything in the cone that is pointing back at it.

They aren't options. All three will be usable. What do you think about the trio? Does it cover all use cases?

Okay, here's the idea for dish targeting: Mode 1: Target planets. Has the cone of vision (dish parameter), anything in the cone connects as if the dish were an omni. Mode 2: Target satellites. Currently it's very static and does not use the cone of vision in any way. I intend on changing this to function like above. This way it won't matter what you point at, behaviour is identical. Mode 3: Groups. You can subscribe a number of satellites to a group, such as "LKO Sats", and you will be able to target everything in that group at once. For performance reasons, this would NOT have a cone of vision. OPINIONS? EDIT: Memos of a rambling fool: Revise targeting; Exception-robustness; Debug menu / configuration menu / satellite fixer Refactoring Eggs Crisps Find some sort of agile board to track my current issues Delete half the issues on GitHub.

It's intended for the 'testing team' to have something to work with.

Well then, another thing to add to my list of test cases. I'll be writing up an excel sheet of a 100 or so (hopefully) features and tests that must pass before a new version goes out the door.

I added that feature in the 0.23 version. On the right side of the screen is a focus switcher, a list of all satellites you can switch focus to. This changes the configuration box in the bottom right.