Cilph

Originally before RT2 was released it had its own fork of Progcom to allow for remote landing procedures. However this is such a pain to maintain that I decided to just leave that to other plugins. And then kOS was developed. =D.

Get better at the game. Low priority. Very hard to implement for what I feel makes you lazy. We had a system for this but I left this out with RT2. "Dunar-class", "Kerbol-class", and so on. No-no-no. Nodes are the only automation you'll get. I wanted to rely on kOS integration for landings. There is support for multiple stations, just no way to place them from inside the game. Besides, your low orbit network should be used for this. ---- You are aware that RT2 is simultaneously supposed to make the game harder, right? Not just fancier. Predicting contact loss is part of the gameplay.

Not something I'd include in RT, but if you'd like to develop stockalike antennas, feel free to. Here's a quick list I could use: Retractable whip antenna for rovers. Physics! Replacement for the AIES extending omni. Replacement for the 500km AIES dipole. Replacement for the AIES gigadish. More variety.

Discussion on the topic of beyond-the-horizon comms: https://github.com/Cilph/RemoteTech2/issues/221 Please participate.

It's on the list, and I just came back from my 'break' a week ago.

I will 100% make sure all of these critical bugs are gone with the 0.24 release.

It's being removed because the Group system can emulate its behaviour anyway.

You should be able to search for the EZGUI implementation behind it in some expensive obscure lookup through Unity itself and set the dirty flag to force a redraw.

Yeah, sorry, but even Scott Manley will have to wait for 0.24. I wasted yesterday coming up with a new GUI for the antenna listing that included distances. It's tricky getting it to work with the limited Unity GUI capabilities while looking good. I'm a perfectionist when it comes to margins. Does anyone want to contribute with some UI design sketches =D?

Someone already proposed a fix for that ^.

Tylo landings are still something I want to make possible in the future. kOS has a new maintainer, so perhaps soon?

It is. But what if you intended to point at the other half ? The system has no way of knowing. When you split a vessel in two, the one with the root part retains the original name and identifier. (RT exclusively uses identifiers, not letter names). The other half is created as a new vessel. Signal Processors on that decoupled part unregister themselves with their old vessel and onto their new vessel. Targeting an individual signal processor or dish would solve the issue, but that would make the targeting such a mess, wouldn't it? Since targeting will now nearly always use cones (except groups), you will have plenty of time to switch targets without losing connection.

RT points at the GUID identifier assigned to a vessel. (128-bit random number). Decoupling/undocking create a new vessel while the original vessel loses parts. The question is which half contains the root part . I could fire a RenameEvent that forces all dishes targeting a now defunct vessel id to point at the new one. (for docking). But decoupling is more difficult and requires user interaction (picking which of the two to point at).

Just a headsup, I'll be removing RT2 from SpacePort come 0.24 and host it elsewhere. SpacePort is a mess.

Well that came out of nowhere. . Impressive.

No, he was right. Dishes would connect to every sat in the group simultaneously. Pathfinding would find the route most suited for your controlled vessel, so it's not completely unrealistic given that you can only control one vessel or cluster of nearby vessels at once. I can however limit the size of groups. Connecting to only one in the group would bring up issues regarding priority that I'd rather avoid.

The current system is basically O(n^2) (every satellite checks every other satellite). This flexibility allows NathanKell's range model to work, omni connections require it, and cones do as well. I did however rewrite it to just check every combination of two satellites and not every permutation - saves half the load, which is spread over 50 physics frames anyway. FYI, a cone check is a dot product and a comparison. Not an awful much, but this is Unity we're talking about.

(or just point directly at Mission Control)

Good to see you've released your project Beastofchicken! My only complaint is the non-stock coloring on the scoop, but I will definitely be using these in the future. Some feature suggestions: - Have the scoop be reusable, but make a one-time version that can't be transmitted and has to be recovered. Neat for probes. - Inverse Kinematics on the scoop if that isn't already implemented. - As mentioned, better stock-like texturing, and keep it a neutral gray.

99% of network issues relate to Active Vessel. There needs to be a better way to diagnose such problems before the functionality can remain.

Yeah, definitely getting rid of Active Vessel targeting until there is a mouse-over overview of a satellite on the map. I've tried making that but the stock game made it impossible for me . Maybe some day.

I've got something hilarious to share. The apartment I've been in for the past month is for sale - I'm merely renting it in the mean time. No one saw this coming but last week someone decided to buy this place and he didn't even bother haggling. They want me out within six weeks. Looks like I'll be moving again by the end of February. Horribly confused at this point. Who wants to bet 0.24 coincides with mid-March?

There is. Check the Github. It's a bunch of static functions that you can easily dynamically assign to delegates. PM for requests.

So, I have an extra copy of KSP sitting in my steam inventory. Think I should do some sort of competition, or perhaps give it away based on quality contribution? Building contest?

I catch your drift. However with the cone of vision now also applying to regular targets this will be unnecessary. You'll most likely have your mothership in range so it would keep having a signal.