Jump to content

[0.20] RemoteTech: Relay Network – V 0.5.0.1


JDP

Recommended Posts

Glad to hear it!

The flight computer was a nice idea, but I can imagine it introducing a lot more complexity to the mod then really is needed.

In this way, you still get the uplink requirement, (wich requires some planning and a lot of satelites), but gets rid of the bugginess and complexities of the signal delay/flight computer.

The uplink requirement has, atleast for me always been the main appeal with the RT-mod.

Great choice Cliph, and glad to hear the mod is back in development!

I barely have a clue what kOS is. I've only head of it in name. Bear with me, I haven't kept up since 0.21.

A lite version of RT2 will remove signal delay and maintain just the uplink requirement. Since kOS is (I think?) a local autopilot it should work out of the box.

Again, I'll see when 0.22 comes out. Just thought I'd let everyone know. I should probably make a new thread when I do that release.

Edited by Flanders
Link to comment
Share on other sites

Okay, hello everyone.

With 0.22 around the door I'm thinking of getting back to work on RemoteTech, but I'll probably strip it to a lite version that removes the mechjeb-y flight computer and signal delay. From a game design perspective those two gave me the biggest headache and had me write the most evil hacks.

I'll see what 0.22 brings to the game with the tech trees and science uplink and decide on something then.

Great idea. That's the features I want most from RemoteTech. Signal delay and alike is a bit too much burden if you ask me.

Link to comment
Share on other sites

I'm fine with signal delay for vanilla controls of RT equipped vehicles that have no kerbals on them, but since the concept of mechjeb is that it's a mechanical jeb, it shouldn't need to be delayed (act like a kerbal on board), which would simplify things. Instead of trying to find ways to be compatible with other plugins, maybe just provide a simple API that returns the current delay and implementing delays is up to the other mods' authors to do.

Link to comment
Share on other sites

Cilph, great to hear you're back on the scene!

I would _really_ miss signal delay, for the record.

MJ _isn't_ delayed in RT1: That's why there's the option of "MechJeb Control"

For kOS compatibility, I think you just need to enable the availability of that option if there's a kOS computer on the vessel, and fix the keyboard interaction problem.

(Eliding for now getting kOS to use RT in-network checks)

Link to comment
Share on other sites

I'll probably strip it to a lite version that removes the mechjeb-y flight computer and signal delay

I would _really_ miss signal delay, for the record

Hear hear.

I am not a physicist but an IT engineer, and even my job bumps into this little nugget of physics every week when designing systems. I can handle stripping out line-of-sight or even requiring a minimum antenna strength for a given distance, but being able to control a craft entering Jool SOI as snappily as one orbiting Kerbin is one step too close to arcade. Heck, even a Minmus landing can get entertainingly hairy if you're a bit heavy-handed on the controls (I've noted proper TWR consideration helps more than propagation-delay-elimination here).

I'm not looking for a pixel-perfect simulation, after all Kerbin has insane density, Kerbals have no life support requirement we know of and while reentry heat is pretty, the only thing fatal about this mission phase is the ground itself - but at least the speed of light is present. I'd even handle making that speed different, but eliminating it is a huge loss.

I realise it's all entwined in the code and you'd rather not maintain it, but if path selection and length calculation is already well-implemented (I imagine all the current effort is the new antenna classes/attenuation), perhaps a propagation-delay checkbox for us die-hard masochists to keep punishing ourselves in our own special way?

Link to comment
Share on other sites

Hear hear.

I am not a physicist but an IT engineer, and even my job bumps into this little nugget of physics every week when designing systems. I can handle stripping out line-of-sight or even requiring a minimum antenna strength for a given distance, but being able to control a craft entering Jool SOI as snappily as one orbiting Kerbin is one step too close to arcade. Heck, even a Minmus landing can get entertainingly hairy if you're a bit heavy-handed on the controls (I've noted proper TWR consideration helps more than propagation-delay-elimination here).

I'm not looking for a pixel-perfect simulation, after all Kerbin has insane density, Kerbals have no life support requirement we know of and while reentry heat is pretty, the only thing fatal about this mission phase is the ground itself - but at least the speed of light is present. I'd even handle making that speed different, but eliminating it is a huge loss.

I realise it's all entwined in the code and you'd rather not maintain it, but if path selection and length calculation is already well-implemented (I imagine all the current effort is the new antenna classes/attenuation), perhaps a propagation-delay checkbox for us die-hard masochists to keep punishing ourselves in our own special way?

I can always put in delay in a later release, and make it optional. For now I'd rather have an actual release out of the door rather than spending hours on the proper game design for signal delay and associated flight computer / DCPU-16 integration. The flight computer was so frustrating that it just made me ragequit.

Link to comment
Share on other sites

Cliph, maybe I can suggest a simplified way forward?

Have RT do both the signal connection and delay as originally designed. Then, re-enable the original RT1 autopilot. All it needs to do is point, and give a way to run a pre-planned burn (by time or dV). Finally, integrate RT with the KSP maneuver nodes. The execution of them would be simple. In the map view, or MechJeb, or the Maneuver Node Planner/Editor, or whatever other addon, you setup the maneuver node(s). Once you're done, you then hit "Execute Node" or something similar on the RT autopilot. This then "uploads" the maneuver node to the craft. As long as you remain in contact until the node is uploaded, the craft will be allowed to execute that node. That's all you need. You don't need the rover autopilot (although it'd be nice down the road), you don't need any complex computer. As long as you can point the craft, execute a pre-planned burn, and follow the maneuver nodes, you can fly any mission. Let everyone else deal with flight computers, complex autopilots, and the like.

Edited by CAPFlyer
Link to comment
Share on other sites

As long as you can point the craft, execute a pre-planned burn, and follow the maneuver nodes, you can fly any mission. Let everyone else deal with flight computers, complex autopilots, and the like.

Except land on Tylo.

Link to comment
Share on other sites

Just my 2 krones, but I like the really cool dishes and LoS concept. The signal delay as an option for hard mode would be cool, but only as an option. The difficulty of getting a probe into Jool SOI and still maintain LoS is hard enough :)

Link to comment
Share on other sites

I can always put in delay in a later release, and make it optional. For now I'd rather have an actual release out of the door rather than spending hours on the proper game design for signal delay and associated flight computer / DCPU-16 integration. The flight computer was so frustrating that it just made me ragequit.

I think this sounds like a really smart way to go about development. Getting a lite version done, released and being tested and then adding to it later if you want / can.

Link to comment
Share on other sites

Most important to me is the line of sight requirement. That's what made this mod really interesting; having to carefully arrange constellations of satellites.

Signal delay is nice, but definitely can go if it'll stop the mod as a whole from being released. As a compromise, perhaps let other mods ask RemoteTech what the signal delay for a particular ship is currently? Then we can just go bug our favorite autopilot author to implement compatibility, regardless of if it's MechJeb or kOS or whatever.

Link to comment
Share on other sites

It is nice of you Cilph, it's exactly what we wanted :)

Anyway, concerning kOS, I think that when RT will become that simple, it will be kOS's job to work on RT compatibility by reading its data and blocking itself when no connection is found or implementing delay on commands execution depending on the connection length. Chatterer already reads RT data, and if the new RT makes it simpler to interact with it I see no problem there.

I don't understand why people would want delay without any flight computer (they want something realistic but they don't fly realistically, there is no-one in NASA "flying by wire(less ^^ )" any probe out there. They are programmed to do so.). It will be flight computers' job to implement it.

At least the new RT Cilph is talking about will be the first step for a kOS/RT compatibility, and that's great :)

Link to comment
Share on other sites

At first I was a little sad to see the delay would be gone, but its an understandable choice to get it up and running first.

As for kOS compatibility, if the delay is eventually brought back, I would imagine how it would work is you could set kOS ahead of time to run a certain script, if needed (you could always run the script before leaving Kerbin/remote command station range, and as long as the program can determine where it is/how far from a target/body it is everything is fine). Being as that kOS would be local control the delay would be turned off, but new commands sent to kOS (program uploads, data downloads, new program executions etc) would be on a delay.

One function I could see being useful is the ability of kOS to change satellite targets, though I guess if that's already done in RT there may not be a point for kOS to handle this I guess....hmmmm :)

Well, either way I'll be happy with whatever comes out, being as that line of sight/signal relay is maybe 50-60% of I would want out of RT anyway. :)

Link to comment
Share on other sites

I can always put in delay in a later release, and make it optional. For now I'd rather have an actual release out of the door rather than spending hours on the proper game design for signal delay and associated flight computer / DCPU-16 integration. The flight computer was so frustrating that it just made me ragequit.

I can appreciate you're getting frustrated over functionality that's implemented quite more completely in MJ, so I'm glad that at least is off your plate with no loss to us fans! I must say though, I used the surface lock extensively during launch to run a pattern of attitude holds and get a really efficient launch profile, while MJ seems to go more than a bit crazy and I found yours worked so much better. I'm still in agreement with this decision though (time to plug in my joystick[smile])

Consider this thread CLOSED. I'll make a new one for the next release.

I'm taking the chance to start all mods from the ground up with 0.22 and look forward to developments. Thanks for all your work so far!

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...