Cilph

The antenna snapping is just based on your velocity and thickness of atmosphere. Only happens when the antenna is deployed. I've removed the feature from the stock antenna on the new parts list we're creating and it's now only on an extra flimsier and longer Communotron 32.

I've forked it on Github and will send a pull request when I get around to finishing integration. Although currently the only things I've changed is making the cpu, assembler, keyboard, monitor public. Having a SerialConnector interface will take care of the second problem. Feel free to do any of the above without me sending a pull request though. EDIT: Just thought of this. Might it not be a good idea to add a second CPU based on the DCPU-16 that Notch's new game uses? It has a lot of tools available.

Just a heads up. With 0.21 confirmed to break saves, RemoteTech 2 will not feature a compatibility patch for older versions. Oh, and I've heard the AIES dishes will be included in stock RT .

The other satellites need their dishes pointed at your unmanned ship. With proper range.

What, you did this knowing the UI is going to be vastly different next version ? If you were easier to contact I'd send you a current alpha.

You could always take KW Rocketry, and install just the fairings.

The signal delay is an abstraction of what happens in the code. What happens in the code is that all commands are stored in a queue and that when the command is allowed to execute, after the signal delay passes, it is popped from the queue and executed. So the earliest a command can execute is after the signal delay. The delay is adjusted to include the signal delay. If you send with a 50 minute delay, and the signal delay is 5 minutes, you're really sending a 45 minute delay. User wishes to send to probe with 5 minutes signal delay, 50 minutes total delay 12:00 PM send message to probe two light minutes away "in 50(really 45) minutes, burn for 5 minutes" 12:05 PM message is received at probe and stored 12:50 PM probe begins burn 12:55 PM probe ends burn

I think congratulations are in order. Could you explain more clearly? What currently happens is that your burn has to wait the signal delay, this is the time it takes for the craft to receive the signal in the first place. The signal itself then can have an extra delay on top of the initial delay, for if you want to delay your burn even further. eg, send the burn in advance instead of exactly <signal delay> seconds before. If your craft does not have a connection at the time the signal is supposed to be received, it will be discarded. Then it waits the extra delay. Then it will burn.

If you have a single, manned vessel with multiple pods and multiple probe bodies, clicking Local Control will do as it says - give you Local Control. Which means control without signal delay and without requiring a signal.

It's much like MechJeb's SmartASS plus throttle control except that it incorporates the signal delay.

If you did a burn with a delay on it, the burn will execute as long as the connection was there when the command was received. It then waits the additional delay to perform the burn. Here's a somewhat older screenshot of how the flight computer works now :3 (GUI is a bit unpolished, I know.)

Currently trying to integrate Progcom into RemoteTech 2, which means the following: Moving the GUI stuff over to the RemoteTech Flight Computer; Signal delay on loading scripts and on any external input; Antenna configuration and network status via the memory map/bus. Unfortunately the majority of the stuff in Progcom is marked internal, so I can't even wrap the cpu . I can play around with InternalsVisibleToAttribute locally, but it's still annoying. That aside, the current implementation for attaching to a serial bus relies on the existence of the ProgCom part. Meaning if I replace the ProgCom part others won't be able to find a serial bus to attach to.

Everything goes in GameData. RemoteTech in a folder. Probe Compatibility in another. Just copy the folder and put it in there, not just the contents.

You could already re-assign targets by switching to a vessel that did have connection. What you couldn't do and can't do, however, is extend an antenna. If you launch up something and it's out of range or you forgot to extend the antenna, you're still screwed without EVA. Of course, config options can fix the problem entirely.

It collapses. There's a button in the corner where if you mouse-over that menu pops up, and disappears once you move the mouse away from it. Progcom integration is planned, I should be coming to that soon. Figaro GPS might be as well.

Formatting in that popup menu is a work in progress. If you have any suggestions, please let me know. In the new version you can reset dishes from the tracking station regardless of whether the satellite has a connection. You will not be able to do this from the map view. Think of it as a punishment that you have to go to the tracking station to fix your screwups. Apart from that you can EVA to configure your dishes.

Yes, that is the tracking station. Yes, those are red dots marking command stations. Yes, that is a mouse-over configuration window in the corner. Coming Soon (probably a week after 0.21)

Mostly, some small bits to the side where you don't have coverage. Most of us just build a ring of satellites.

If your input goes through a tokenizer, parser, forms an abstract syntax tree, and is then output into a second language, you are compiling. Has nothing to do with binary.

"Machine code is just C written in another way." Of course there are varying degrees of difficulty, but java bytecode to java, and .NET CLI to C# are both decompilation. It reverses the compilation process.

Just to put it out there, I'm looking for some volunteers: I've wasted about a week trying to rewrite JDP's flight computer (the non-GUI bits) because I never got the actual control to work. Because of that, I'm looking for someone who can implement a proper control system for the flight computer that can hold an orientation and isn't straight up ripped from MechJeb. The current antennas included with RT could use some work, so I'd like it if someone could design a few antennas and dishes for the plugin that have a nice stock feel to them. Perhaps also help with balancing parameters and such. I'll be on IRC @ #KSPModders if anyone needs me.

Read my posts a few pages back to see what I'm doing.

Not really. Even less with my version that distributes load more evenly.

I couldn't care less about naming conventions. Your code was just genuinely hard to read. As for backwards compatibility, most can be converted with a python script. I'll see if I can supply that. Worst case you have to just reload each sat in cheatmode to turn it back on.