PatriotBob

Also linking certain variables to sensors would be cool. Sensors could be distributed across the tree making tech progression via program complexity not just because the CPU goes faster.

I just noticed two things.. 1) No logarithmic functions 2) Can't return anything from the RUN command. The first is annoying because a few physics equations use them, but the second... I die a little on the inside when I can't clean up my code... it's too long... need functions... CODE SHOULD NOT LOOK LIKE THIS! *tears*

Welp, started ripping out mods in desperation. It was Remote Tech. Having access to the source on most mods is both wonderful and terribly frightening at the same time...

If I type "LIST." It never freezes. "LIST VOLUMES.", "SWITCH TO 0.", "COPY [Filename] TO 0." These all freeze the terminal. Regardless of trying "SWITCH TO 1." First or not.

This doesn't seem to really help. They're already on volume 1, it's the local volume. Problem only really occurs when accessing the archive. I'm guessing the terminal lack of responsiveness is related to https://github.com/Nivekk/KOS/issues/113 so I'm guessing kOS is throwing a null ref when I try to access the archive. So the question is, why?

Ok, I'll give that a try. i'm guess that fix was the pull request that initializes the HardDisk before calling initCPU(). I really love this mod, but I hate the syntax sooooooooo much.

:| Ok great. The terminal is back, still don't have access to the archive. Still locks up if I try.

Ok, maybe I'm just dumb here. But I can't get the archive to work for the life of me. Using the COPY TO, LIST VOLUMES, or SWITCH TO commands just causes the terminal to hang. Listing the volumes gets as far as putting up the header and stuff but no volumes are listed. I have the folder at <KSP DIR>/Plugins/PluginData/Archive/ but still just hangs... Any suggestions?

Silly me, I was looking for a proper license in the repository. While that's great that it has a fairly permissive license, forking projects is only worthwhile if the original is no longer being maintained. Otherwise it fragments the community and helps no one. Another problem with taking over maintaining the project is that as far as 2.0 is concerned only JDP/Cilph know the project's current state. What needs to be done, what direction it is going in, etc. The project would suffer greatly unless the two current maintainers stayed on, minimally in a management role, until the burden of knowledge is handled. All in all not a lot of good options. :/ Unless they state being open to pull requests, so they don't have to do as much but still maintain authority over the project and the code quality Because I don't see a fork working out well anytime in the near future.

From my understanding RT 2.0 was a complete rewrite of the original to try to escape the technical debt associated with the original codebase. As much as I would like to say we could discuss putting a generic "auto-pilot interface" that RT could use and change the associated mod implementation... (MJ, RT, kOS, etc) I don't think that's going to work as well as it might seem. RT uses little more than a queue of commands with a possible delay. MechJeb does... well... everything. From node planing, execution to time warp modification and landing. kOS can do anything between RT and MechJeb (and beyond). They all go about "auto-pilot" in fundamentally different ways. About the next best thing, would be looking at adding connectivity and delay information to a module and having MJ/kOS integrate the delay on their end. Any way we could try to inject a delay or loss of control into them through RT may work for some cases, but for each new feature added to other mods will then force RT to update to take that into account. A code maintenance nightmare. The best thing RT can do is make the delay and connection information available for easy integration with other mods and then community pressure to have MJ, kOS, etc integrate with RT. But no other developer is going to integrate with a mod that essentially isn't maintained, like RT is. The last release is still 0.5, any 0.21.1 compatibility is community made, and 2.0 has halted and the developer has stated it may resume "later". Is JDP the primary developer or Cilph?

Well I mean that's a mighty fine spreadsheet and all. I just find it a bit overkill. The orbital adjustments can be done in a matter of seconds with any calculator. About the only thing I that makes it difficult is knowing the gravitational parameter for all the celestial bodies. I find I benefit more by knowing a few equations and using those on the fly than switching to a spreadsheet. (Probably influenced by my game's hatred of Alt+Tab) Being able to work out orbital adjustments, convert deltaV to burn durations and a few other things is a huge benefit if I need to do something in the next 30 seconds. But maybe I'm just old fashioned.

My go-to method of satellites networks (All math for Kerbin): Take a ship up with 4+n satellites, so lets say 6. Circularize your orbit at GSO altitude (2868.750km) @1009.018 m/s. At this point you release the first satellite. Then burn retrograde and lower your periapsis to 2074.746km. (If my math is correct) This should give you an orbital period of 5 hours. (GSO orbital period is 6 hours. 6 satellites should be 1 hour apart.) Do a full orbit and circularize at apoapsis to 2868.750km and set velocity to 1009.018 m/s. You should be 1 hour behind your previous satellite. Drop another satellite and repeat. You can do this with any number of satellites you're just going to change the transition orbital period/periapsis to adjust. 4 satellites == 4 1/2 hours == 1658.031km 5 satellites == 4 hours 48 min == 1909.807km 372 satellites == 5 hours 59 min 1.93 seconds == 2856.313km

See now I have to go dive back in to licensing again... I don't like GPL and it's viral nature, but it might work for a mod. Maybe CDDL? Really all I want to see from a mod creators is that they change the license to something that allows it to be forked before they stop maintaining it. Now I have to go poke around mod creation... anyone have any ideas for a mod?

Is there any news for the RT2 development? There hasn't been a commit in 3 weeks and pull requests seem to be not welcome at the moment. Kinda sad to be stuck to between not having RT1 for .21.1 and RT2 being in it's unfinished state. This mod is amazing and it really feels lacking to use KSP with out it. Edit: Guess my post is redundant, didn't see the above post.

Ooooh... My stations will appreciate the reduction on writhing until they break apart. After all I need to build massive command modules for RT2.

From my understanding most of the UI is still not functioning as intended. The only thing that I've gotten to work on the flight computer is a burn w/o direction change. I hear that the artificial delay works, although I haven't been able to get it to, regardless of pressing 'enter' all over the place. Fair warning though, the burn only takes a duration. So if you're looking to burn for a specified delta v, you'll have to crunch that conversion yourself. But I've been away from home for 2 weeks, so things could have changed. (Ugh, need to post more... this whole probation thing sucks)

Couldn't you also put a manned command module between the probe and Kerbin? That is the designed method of reducing signal delay is it not? Or is that not functioning in RT2 yet...

Oh, maths! I know mech jeb does everything for you, and that's half the reason I don't like it. A fair amount of KSP's enjoyment comes from piloting things my self. The most fun I've had has been flying missions IVA. I've seen people do it but most of them run the missions before hand and memorize burn times/target velocities. I'd much rather have the tools in hand, in this case maths, to design the ship in VAB knowing each stage's delta v. (Thanks Kerbal Engineer) And have all the math I need on hand to plot my burns exactly. I really like the info that MechJeb provides and I think some of it should be available to us by default. But I think MechJeb goes a step too far in to having the game play it self. Thanks again for the details, I'll likely add this to my collection.

I'd be really interested in the math behind this. If you don't mind sharing that is. Or would be so kind as to point me in the direction to work it out my self?