[DISCUSSION] RemoteTech 2 Lite development

[brienne]

Any idea about delay to finish first version of your mod?

Actually, i wait for it before going back to KSP :]

[Dexter9313]

Any idea about delay to finish first version of your mod?

Actually, i wait for it before going back to KSP :]

Lol, this is exactly my situation as well, I can't play without RT or kOS xD The game has no point in my opinion without those. I have barely tried 0.22.

[Cilph]

Any idea about delay to finish first version of your mod?

Actually, i wait for it before going back to KSP :]

Don't push me. Just go play 0.22 without RemoteTech :/

[kalor]

I like this idea a lot. And hopefully you do get this done in the near future (not pushing, just sayin!)... it would save me a lot of work trying to figure out why KSP wont let me add the old RemoteTech antannae to the tree.

A suggestion that I might make (don't know if this has been discussed/debated elsewhere or not, so forgive me if it has) would be to possibly alter the weight and size of some of the modules in RT. I personally would make the Remote Command modules heavier, at least, if not bigger and heavier, than the Remote Control modules. The main reason being that a circuit to simply relay incoming data is much simpler than a circuit to relay incoming data as well as send/recieve instructions to/from other vessels.

Thanks for the great mod, and I for one am looking forwards to the next version!

[NathanKell]

Don't push me. Just go play 0.22 without RemoteTech :/

Or with RT1, which still works fine.

[Dexter9313]

Don't push me. Just go play 0.22 without RemoteTech :/

Use the time you need, don't worry. ^^

[lipatden]

Don't push me. Just go play 0.22 without RemoteTech :/

After a year of building launchers with Engineer readouts, aerodynamic shrouds from KW then Procedural fairings, 3m parts from KW (with even bigger engines), Alarm Clocks to schedule activities and not overshoot warps, MJ to handle docking and manoeuvre nodes, ISA MapSat to spot topography and plan landings, and of course FAR to give me some real atmospherics and fluid dynamics....

Running a 0.22 in career mode, using only stock parts, guessing dV on each build, docking by hand, eyeballing landing sites, laughing at the ridiculously bulgy vehicles exposed to supersonic slipstreams and frantically jiggling nodes to get that orbits all lined up as my barely competent craft hurtles forwards at kilometers per second so I can just get enough science to unlock that next cool part are enough of a challenge, and almost a new game.

The last thing I need on top of all that is "Out of Contact"! So yeah, I am more than happy to wait as this update is tweaked properly and adds a decent, rounded experience to all comms scenarios.

I do have one concern though: With RT1 ranges are fixed (or perhaps 2x weakest if mismatched antennae are aligned), but I understand RT2 is doing a power-based calculation. This is a bit of a problem; I know that e.g. when I am over 50Mm for a particular configuration I lose contact as shown in the part description, but now I will need to keep a bunch of lookups for each antenna combination to figure out the maximum range, since they're not available anywhere in the UI. Couple this with the Field-of-View (a certain number of planetary radii at maximum range) and the chances of losing signal contact are much higher with no way to recover (e.g. once an hour point to a known location if no signal is active).

I foresee many frozen hulks drifting through the Kerbol system in the coming weeks, desperately listening for the faintest echoes of stray photons that show home still cares...

Edited October 21, 2013 by lipatden
yucky grammer, some more kudos

[WARDCAT]

First , apologize for my bad English . after this, I will describe some ideas that I think would make this mod the best mod of all time and the most profitable.

1 transmission protocol to implement a simple, but real . for example , 16 -bit code identifying the ship, which sent the communication .

date of shipment, date of receipt . Instead of sending and reception. time elapsed between shipment and arrival. and finally , the transmitted data.

This would enable the use this mod to implement as a satellite to take photographs and send through the satellite network reception taking the game in a window . can see the received data and logging data transmission .

to this, you can add, signal delay , signal interference , signal loss for several reasons: lack of satellite coverage , radiation , solar activity, etc. .

you could also implement a voice chat service that uses this protocol and is affected by all the above , giving the mod , application, and uncommon depth .

needless to say I have no idea of ​​the difficulty of a project like this.

however I think it would be possible , having seen the level moding of this community.

a greeting.

Antonio Perez .

[Cilph]

I do have one concern though: With RT1 ranges are fixed (or perhaps 2x weakest if mismatched antennae are aligned), but I understand RT2 is doing a power-based calculation. This is a bit of a problem; I know that e.g. when I am over 50Mm for a particular configuration I lose contact as shown in the part description, but now I will need to keep a bunch of lookups for each antenna combination to figure out the maximum range, since they're not available anywhere in the UI. Couple this with the Field-of-View (a certain number of planetary radii at maximum range) and the chances of losing signal contact are much higher with no way to recover (e.g. once an hour point to a known location if no signal is active).

But I'm going to be using the simple RT1 range system for now...The cone of vision thing only applies to the lazy planet targeting.

[SteamTrout]

Would it be possible to add some build-in short-range antenna for probe bodies (thinking no more than 5km transmission range in full LoS). Basically it's for making service probes and RCS tugs so they don't require extra parts.

[Cilph]

Would it be possible to add some build-in short-range antenna for probe bodies (thinking no more than 5km transmission range in full LoS). Basically it's for making service probes and RCS tugs so they don't require extra parts.

Theoretically, perfectly possible. You just slap an animation-less ModuleRTAntenna on a probe body. I won't be doing that in the mod though. However I will be adding them to launch clamps. The small RT1 dipole will make a return and you can easily put that on a probe body.

[kalor]

I like a couple of the above ideas, namely the 16-bit transponder code, with the Transmission identifiers in place. Another thought I had, and, well, I'm not a radio technician or anything like that, but wouldnt we need a transmitter and a receiver to send and receive? I know it would add a part count increase, but some situations could arise from including both that could require repairs... ie, damaged transmitter on landing. You could send instructions all day, and the craft would carry them out, but wouldnt send data back... requiring a manned (or automated) mission to repair the system, if it is vital enough. Mind you, its currently only really possible to have damage if you try to dock or land and smack something, but.. yeah

@SteamTrout: I just added all the RT1 parts to the tech tree so I have looked at the part files... that would actually be really easy to do, if you wanted to do it yourself, or, if the modder wants to add them

Another feature that the 16-bit transponder could add, (not sure how possible...) is to not update craft names until they receive a transponder signal, either manually or automatically, from the craft. So you could SEE your massive space station there 200 meters away, but unless you, say, "request ID", and the station transmits a transponder code that you receive, it would remain an "unknown craft". Just a thought

[SteamTrout]

I won't be doing that in the mod though.

May I ask why? I mean technically it would make sense for probes to have some very short range built-in communication ability.

I'm not trying to be pushy or anything, after all it IS easy to add myself. Just being curious.

[Demon_82]

I like a couple of the above ideas, namely the 16-bit transponder code, with the Transmission identifiers in place. Another thought I had, and, well, I'm not a radio technician or anything like that, but wouldnt we need a transmitter and a receiver to send and receive? I know it would add a part count increase, but some situations could arise from including both that could require repairs... ie, damaged transmitter on landing. You could send instructions all day, and the craft would carry them out, but wouldnt send data back... requiring a manned (or automated) mission to repair the system, if it is vital enough. Mind you, its currently only really possible to have damage if you try to dock or land and smack something, but.. yeah

@SteamTrout: I just added all the RT1 parts to the tech tree so I have looked at the part files... that would actually be really easy to do, if you wanted to do it yourself, or, if the modder wants to add them

Another feature that the 16-bit transponder could add, (not sure how possible...) is to not update craft names until they receive a transponder signal, either manually or automatically, from the craft. So you could SEE your massive space station there 200 meters away, but unless you, say, "request ID", and the station transmits a transponder code that you receive, it would remain an "unknown craft". Just a thought

I'm neither a radio technician, but I did work at an aerospace equipment manufacturer so I have Heard closely about satellite radio equipment. Most of the time they don't build a separated transmitter and receiver, but a single transponder / transceiver equipment part for bidirectional communication on each band, unless it's a special communication band only used for transmitting or receiving. And it's hard to damage only one of the boards inside the part, unless it's a localized electrical failure, they are protected by the same metal box.

Also your last suggestion reminds me the working way of a IFF transponder (noy only military, but civil aircraft units are called "Identify Friend or Foe" also, I guess who's the enemy there xD ), that units send their ID automatically to other units that request it, but usually that other units also request ID automatically, so it should just a matter of distance (and available power) to get the ships names. Of course the IFF unit can be toogled on or off.

[kalor]

I'm neither a radio technician, but I did work at an aerospace equipment manufacturer so I have Heard closely about satellite radio equipment. Most of the time they don't build a separated transmitter and receiver, but a single transponder / transceiver equipment part for bidirectional communication on each band, unless it's a special communication band only used for transmitting or receiving. And it's hard to damage only one of the boards inside the part, unless it's a localized electrical failure, they are protected by the same metal box.

Also your last suggestion reminds me the working way of a IFF transponder (noy only military, but civil aircraft units are called "Identify Friend or Foe" also, I guess who's the enemy there xD ), that units send their ID automatically to other units that request it, but usually that other units also request ID automatically, so it should just a matter of distance (and available power) to get the ships names. Of course the IFF unit can be toogled on or off.

Fair enough, on both parts The IFF is exactly what I had in mind, and the reason I suggest it is, though again, certainly not an expert, is that I would imagine spacecraft may not constantly use IFF transponders for the reason of power consumption and availability. Again, hardly an issue we usually deal with here, as most of the Kerbal engineers here seem to overbuild... a bit

For all that, I am all for having more things to do, from ID'ing spacecraft to (as a new suggestion) remotely requesting that docking ports with covers or shields be opened... I've had a couple rather embarassing moments of forgetting to open the shield on craft A, and nose bumping it out of its orbit (albeit slightly) with craft B while trying to switch to open the ports The ability to request the dock be opened would be handy... but hardly needed.

[Ralathon]

In regards to RT development. I strongly suggest you keep it as simplistic as possible Cilph.

Unmanned craft cannot be controlled when they aren't connected to a base/crewed capsule.

Craft cannot send science data when they aren't connected to the KSC.

No light speed lag.

No fancy mathematics for the antenna and dishes, just a simple addition of ranges.

No flight computers or anything, just make sure kOS or Mechjeb ignore the "cannot be controlled" restriction.

I think implementing really fancy things like different data encryptions, fancy gain mathematics for ranges or reentry interference just alienate the audience.

Sure, hardcore realists would be delighted. But they're just a small core of the wider audience, most of whom aren't interested in that kind of stuff and are just looking for some extra challenge. It's just a lot of work with very little payoff.

[WARDCAT]

I think, you do not need a system for sending sequential type id.

rather, it would send a single request to a reception slot, hence the request code would be analyzed by the cpu, and would be established as a priority, "in case of multiple requests" and would put in a queue for execution.

In the case of delay, you should not complicate too much, you could implement in two ways.

the first: this is the simplest, is to calculate the distance between transmitter and receiver and make a loop of delay or waiting to activate the signal at the receiver.

the second is more elaborate, as it would treat the signal as an object in space, this object will be released at the speed of light and travel to the receiver. on arrival, this signal will behave like any regular transmission, creating a petition in the appropriate slot.

sorry for my bad englih.

[lipatden]

But I'm going to be using the simple RT1 range system for now...The cone of vision thing only applies to the lazy planet targeting.

That's still a problem. If I've just exited Kerbin's SOI on the way to e.g. Jool, and target Kerbin, if the (kerbin-orbiting) relay sat isn't within the cone of the Jool-range dish it won't get signal. This is likely, since the cone is some planetary radii wide at maximum range - Just outside K's SOI I'm nowhere near that distance. So do I need to pack an intermediate antenna to handle medium-range comms too, or perhaps double up on the max-range comms to target two relays directly (two for occlusion tolerance) instead of the orbited body?

Sorry for the barrage of questions, and appreciate this isn't in yet, just looking for corner cases.

[lipatden]

In regards to RT development. I strongly suggest you keep it as simplistic as possible Cilph.

Agreed, except for one thing that has been chimed in on:

No light speed lag.

This is achievable now by making the default light speed insanely high to reduce lag to a handful of milliseconds (ie unnoticable to humans), and a code change to hide the delay value display in the UI if it is not above 5ms (ie imperceptible and of no consequential impact)? I'm not aware of any user or game mechanic that would be affected by 5ms.

That way no disruptive code changes are needed to check whether the user has enabled SOL-lag, while hardcore users will be the ones opting in by editing the .cfg to implement a more "realistic" lag. Maybe altering the UI as described is a disruptive change, in which case I appreciate there are tradeoffs to be made and since this is no longer a headline feature (apparently) it will fade away, but worth a short investigation I hope?

[Cilph]

Signal Delay / Control blocking is back in with a few minor bugs that need fixing. I might add the attitude control flight computer back in and release with signal delay after all.

That's still a problem. If I've just exited Kerbin's SOI on the way to e.g. Jool, and target Kerbin, if the (kerbin-orbiting) relay sat isn't within the cone of the Jool-range dish it won't get signal. This is likely, since the cone is some planetary radii wide at maximum range - Just outside K's SOI I'm nowhere near that distance. So do I need to pack an intermediate antenna to handle medium-range comms too, or perhaps double up on the max-range comms to target two relays directly (two for occlusion tolerance) instead of the orbited body?

Sorry for the barrage of questions, and appreciate this isn't in yet, just looking for corner cases.

You can still target individual satellites without this cone.

[techno65535]

Something I'd like to see, and would go along well with the earlier post with probe bodies having short-ranged antennas for robotic tugs and such, is for a short-ranged R/C type controller that can be controlled by any manned craft within range. That is, within one hop, it doesn't matter the number of kerbals in the craft the R/C craft can be controlled. While not much of an issue while there's no time-delay would be useful for say a station in Jool orbit that just had a new part delivered and it's got to send it's robotic RCS tugs out to move it into proper position and the station doesn't have the 3/6/9/however many kerbals are needed for a secondary command node.

[Azivegu]

Not really sure where to put this, but anything communications wise is remotetech for all I know. What if there was a quantum telecommunication device? Say it has 90 to 100% data transmission, but is really slow and gobbles up power like there is no tomorrow? You might be asking: "well whats the purpose for that?" The benefit of it would be instantaneous transmission. It would take a lot of science to unlock it as well

[betaking]

My only problem I have is that I can't rely on the stock attenae for ascent and guidence in orbit. It falls off on ascent due to stupid things regarding max Q (which fairings do nothing against).

[kalor]

My only problem I have is that I can't rely on the stock attenae for ascent and guidence in orbit. It falls off on ascent due to stupid things regarding max Q (which fairings do nothing against).

I currently added the RT1 parts to the tech tree, and added the RT functionality to the stock ones, and have used all of the ones I have unlocked in career thus far, with no issue during launch. I use the first stock antennae for orbital functions, and the dipole for sub-orbit, and works just fine. The only problem I've had so far with the stock antenna is deploying at 1K m/s is generally bad for it >.> Consider using the dipole antenna if you are experiencing that issue, and switch to something more powerful once you are spaceborne.

[Cilph]

My only problem I have is that I can't rely on the stock attenae for ascent and guidence in orbit. It falls off on ascent due to stupid things regarding max Q (which fairings do nothing against).

That's the point of the dipole antennas or non-folding dishes.