[DISCUSSION] RemoteTech 2 Lite development

[Cilph]

RemoteTech 2 will be a lighter version of what I had planned originally. The signal delay and the flight computer will be removed at first release until I decide to implement the latter. I'd rather not implement signal delay without the flight computer, and I need to work out a better system for that.

That said, 0.22 is out and brings research to the table.

Current issues up for discussion:

• How do we handle information transmission in RemoteTech?
  Proposal: Research transmission is only possible if there is link to KSC. If the craft is connected to a Command Station, that means the Command Station needs a link back to KSC.
  Pros: Easily implemented, can store a list of connections instead of the minimum cost for a craft.
  Cons: Think of some for me.
  

Feel free to bring up any other points for discussion.

[Dexter9313]

I can't find any great con... but one little : you can't differ research transmission. Here's a scenario : you are doing stuff on the Mun's surface and gathering some scientific informations but on the other side from Kerbin so that there is no line of sight were you settled. There is no communication network yet but an orbiting Command Station which passes above the site from times to times. It would be great to be able to transmit science to this CS then wait for it to be in line of sight from KSC and then transmit everything you have gathered on the "dark side" of the Mun to KSC.

By playing the update, I know there is some sort of data storage in the ships, so I think it would be great to be able to transfer the stored data from a vessel to another (maybe with the rule "only to Command Stations", something to think about).

[TomatoSoup]

If you intend to have Remote Command parts, it could cause a mistake where the research is returned without actually being able to reach KSC? Other than this, which is just another line of code (loop through entities in chain, check if KSC is there), this sounds like a great idea. Especially now that the communotrons and stuff actually have uses.

[Cilph]

If you intend to have Remote Command parts, it could cause a mistake where the research is returned without actually being able to reach KSC? Other than this, which is just another line of code (loop through entities in chain, check if KSC is there), this sounds like a great idea. Especially now that the communotrons and stuff actually have uses.

Read closely. I'm saying exactly that.

I can't find any great con... but one little : you can't differ research transmission. Here's a scenario : you are doing stuff on the Mun's surface and gathering some scientific informations but on the other side from Kerbin so that there is no line of sight were you settled. There is no communication network yet but an orbiting Command Station which passes above the site from times to times. It would be great to be able to transmit science to this CS then wait for it to be in line of sight from KSC and then transmit everything you have gathered on the "dark side" of the Mun to KSC.

By playing the update, I know there is some sort of data storage in the ships, so I think it would be great to be able to transfer the stored data from a vessel to another (maybe with the rule "only to Command Stations", something to think about).

This could work.

[NathanKell]

Both those sound right.

Any remote science lab would still have to transmit its own data back to KSC anyway.

[Dexter9313]

Both those sound right.

Any remote science lab would still have to transmit its own data back to KSC anyway.

Yes, it doesn't make sense to earn science which leads to better parts assembled at KSC if KSC has no clue what is going on in outer-space research.

Also, I would like to raise another point for discussion which is compatibility with other mods, as it is my main reason to be interested in the new RT developement to be honest.

I love kOS and RT and they couldn't work well together (I think we could say that for a few others), everybody already knows that, but I just would like to be sure that the new RT will allow easy integration from other mods, as Chatterer already does.

By that I mean a clear and simple interface to work on like : float pathDistance(); bool manoeuvrable(); Vessel* connectedToCommandStation() [could return NULL if none];

Those are pseudo-code or even just concepts has I don't know C# well and the KSP SDK even less, but you get the idea. I think you already know that RT will likely be used along other mods and as it is a great modification of the gameplay, it needs to be easy to integrate to another gameplay mod in my opinion. Maybe it was planned or maybe it was already featured in the previous version, I don't know so I want to be sure.

Cheers.

Edited October 16, 2013 by Dexter9313

[Cilph]

Yes, it doesn't make sense to earn science which leads to better parts assembled at KSC if KSC has no clue what is going on in outer-space research.

Also, I would like to raise another point for discussion which is compatibility with other mods, as it is my main reason to be interested in the new RT developement to be honest.

I love kOS and RT and they couldn't work well together (I think we could say that for a few others), everybody already knows that, but I just would like to be sure that the new RT will allow easy integration from other mods, as Chatterer already does.

By that I mean a clear and simple interface to work on like : float pathDistance(); bool manoeuvrable(); Vessel* connectedToCommandStation() [could return NULL if none];

Those are pseudo-code or even just concepts has I don't know C# well and the KSP SDK even less, but you get the idea. I think you already know that RT will likely be used along other mods and as it is a great modification of the gameplay, it needs to be easy to integrate to another gameplay mod in my opinion. Maybe it was planned or maybe it was already featured in the previous version, I don't know so I want to be sure.

Cheers.

There are multiple ways of handling this. The first is that I let other plugins link to RemoteTech and request data via the Satellite/Antenna/NetworkManagers I have to read out any data they need. Con is this requires linking against the assembly. Pro is that it gives full control.

A second option is to implement an event that can be dynamically called with Unity along with a ConfigNode or Dictionary to be populated. This gives less control but would allow some interaction without linking.

I say, why not have both ?

[Mokmo]

I am actually glad RT is getting some ideas out for the new science system.

I think transmission should be done a bit like the stock antennas: Requiring a quantified burst of energy to transmit a packet back home. If it has line of transmission, it'll travel the whole path. If not, a good fallback solution is the nearest command center. Which would then need to be made active to re-send the reports back to kerbin. And requiring the kind of energy for the size of the packet to send.

I'm not sure how the science is managed by the game, but i guess storing a report in a command center then sending an identical one directly to KSC would not be a way to pump extra science points.

[Dexter9313]

There are multiple ways of handling this. The first is that I let other plugins link to RemoteTech and request data via the Satellite/Antenna/NetworkManagers I have to read out any data they need. Con is this requires linking against the assembly. Pro is that it gives full control.

A second option is to implement an event that can be dynamically called with Unity along with a ConfigNode or Dictionary to be populated. This gives less control but would allow some interaction without linking.

I say, why not have both ?

If both possible are then both let be. ^^

I think most of the already existing mods will focus on the second way though, but if you don't lose much time doing both, then feel free to do so.

For example with kOS, the mod could only need to know :

1° if RemoteTech is installed

2° if so, if we have control over the vessel through KSC/CS connection to execute the command lines entered

3° the length of the connection path to implement a delay itself on when to execute the command line (a bit like you did on your own autopilot)

If you think those informations will be easy to access to regarding the second method (the first one would require kOS to be RT-dependant), then I think you get what I meant anyway. By the way, sorry to focus on kOS but it is easier to demonstrate with it.

Edited October 16, 2013 by Dexter9313

[BruteMan]

I just wanted to add my support for this great mod and thank you for coming back to it.

Playing KSP for the past month this mod added what i was desiring to keep my interest up a realistic reason and path to go toward. Adding remote-tech just to force me to think about setting up communication networks to communicate in space added that bit of a challenge and drive to work towards first before being able to just fly here or just fly there etc.

Now I cant speak on the whole delay debate in the other thread and i really don't know .22 well enough yet to offer anything there but I am glad this project is being continued cause just flying out to the mun standing on the dark side should not let me control / communicate without a network like your mod requires. Kudos to you!.

[Camacha]

I understand that you do not want to implement delay without a flight computer. I do feel, however, that this is part of the attraction of Remote Tech. It would probably be ridiculous to create a flight computer when something like kOS is around, so maybe delay could be togglable and/or detecting whether kOS is installed or not. If you would go the config route it would be ideal to be able to adjust the delay times too, so everything can be tweaked to be as realistic as possible or desired.

As mentioned above, relay sending via orbiting probes that do not have a continuous direct line of sight would be pretty neat, regardless of whether delay is implemented or not.

Finally, I am very glad that this project is going again. From the first time I saw this existed it felt as a natural and necessary mod. KSP just is not complete without it. Keep up the good work and - also very important - do not forget to have some fun along the way

Edited October 17, 2013 by Camacha

[BioSehnsucht]

Can you not simply allow research to be buffered on any craft in comm range that has capability to store data in the first place? I.e. A does research, sends to B which is dumb relay sat which has a link to C which is a vessel with science gear, which can then store it. Once it's transmitted, it should be removed from A and only be on C (to prevent duping). Then when C comes in radio contact (via network or direct) with KSC (or again another craft...) it can send... etc.

Might need a way to select a comm target for data other than KSC ..

[brienne]

I see 3 concepts linked to Remotech:

-Time delay

-Energy: you use radio, you need energy.

-Bandwith: the farer you are, the less bandwith you get, the more time you need to exchange datas.

RT could add another idea: computer memory

-> Points A,B,C.

I collect 0.22 science at A and record it on a HDD.

Drive is full! Need to empty it to continue.

I want to send those datas from A to C, using B as a relay.

I transfer datas from A to B. I can continue science at A, my HDD is now empty. And need to transfer datas form B to C (it will take time).

You get the idea^^

Hope it helps.

Edited October 17, 2013 by brienne

[Dexter9313]

Can you not simply allow research to be buffered on any craft in comm range that has capability to store data in the first place? I.e. A does research, sends to B which is dumb relay sat which has a link to C which is a vessel with science gear, which can then store it. Once it's transmitted, it should be removed from A and only be on C (to prevent duping). Then when C comes in radio contact (via network or direct) with KSC (or again another craft...) it can send... etc.

Might need a way to select a comm target for data other than KSC ..

I think there need to be a type of vessel that can store data anyway. It might be Command Station if we want to keep it simple, or a third type of RT pods. I don't know if the game already implements data storage limits, then RT wouldn't have to handle this and could transmit any data to any vessel.

I see 3 concepts linked to Remotech:

-Time delay

-Energy: you use radio, you need energy.

-Bandwith: the farer you are, the less bandwith you get, the more time you need to exchange datas.

RT could add another idea: computer memory

-> Points A,B,C.

I collect 0.22 science at A and record it on a HDD.

Drive is full! Need to empty it to continue.

I want to send those datas from A to C, using B as a relay.

I transfer datas from A to B. I can continue science at A, my HDD is now empty. And need to transfer datas form B to C (it will take time).

You get the idea^^

Hope it helps.

I agree with everything you said but we have to be precise on what we should expect time delay to be (and as I said, I don't know if KSP already has a storage limit on their HDDs).

I think the only time delay that could be compatibility-viable would be on research transmission. Their could be an Optional GUI window which could manage data storage between vessels and add a delay for every transmission. I believe it has to be optional actually, as it is a bit beside the purpose of RT I think, which core has to be as simple as possible in case another mod implements data transmission better for example and the user wants to use this other mod to do that.

He would only have to install the core RT without the data transmission and he could install the other mod.

RT needs to be modular as it changes things in a deep way, so incompatibilities are around the corner; and choice between mods is always better.

I see the new RT as a collection of modules related to data transmission (maybe including an optional simple flight computer). This way the user could always choose to replace an RT-module by a better third-party mod. In any game I played, I hated mods which did everything in a non-modular way because sometimes I loved some parts and hated some other, but I couldn't replace these bad parts with another mod. I like the UNIX way of thinking : small programs which do one small task and do it well. Mods should be designed like this. This way the user can choose every aspect of his game and developing/debugging has never been so easy. So now we need to define for RT what should be core and what shouldn't; then what modules could we add.

I'll give you my opinion on this : RT-core should strictly be :

1° establishing connection with KSC or Command Station

2° blocking vessel commands and dish pointing if no connection is set (like if there were no power anymore, not by blocking keyboard entries)

and that's all.

I know it seems something is missing, but don't worry you could use modules for whatever is. It is only my opinion though, so please add some more ideas or correct me.

Time delay on controls would be a module for example. As would be scientific data routing, which by default would behave as KSP-stock.

Edited October 17, 2013 by Dexter9313

[NeoSky]

I apologize in advance for my bad English. I decided to show how I would create transfer data for this mod

[lipatden]

^ ^

| |

| |

Wow!

That is a lot of detail (seriously, very impressive), and is going to need a lot of work to implement all of it (I presume firmware is upgradeable to increase compression and error correction codes?). Seriously, that's huge...

[Cilph]

@NeoSky: Some day, maybe. I can't simulate energy consumption in unloaded vessels and this is a very complicated system even without that.

How do we handle science transmission on manned capsules?

Currently, satellites are only recognised as such when they have a signal processor onboard, which manned capsules currently do not have. Without being marked a satellite and having the equivalent of a signal processor, it can not participate in routing. This would disallow transmitting in early game without the Stayputnik.

Proposal #1: Add a passive signal processor to antennas that allow them to become a satellite, take part in routing, and send data, but only when it is the active vessel and otherwise controllable.

Proposal #2: Move the Stayputnik to Basic Rocketry and require a probe for science transmissions.

Proposal #3: Move antennas to Stayputnik tier or later.

Edited October 17, 2013 by Cilph

[Bobhendly]

That sounds good.. There is a void in my game now, Satellites..

[CAPFlyer]

Satellites should be, at least in the basic, early in the progression. Remember, we were sending up satellites before people. The amount of science they could do was very limited due to bandwidth and power restrictions, but even Sputnik gave a lot of useful information just with its little beep being tracked that allowed some initial mapping of the Earth's gravity well by noting changes in speed as it orbited. Some Amateur Radio operators also were able to map some of the ionosphere and even magnetosphere by measuring the variations in the signal strength and frequency on each orbit.

[Cilph]

I decided to go with requiring a direct feed to KSC for science transmissions. No storing on space stations for now. Kerbals haven't invented multi-Mit harddrives suitable for space yet. Maybe they will eventually. I think we found a nice tech tree addition.

[Dexter9313]

Good idea, enabling harddrives in the techtree would be nice !

[NathanKell]

Why would one ever not have even crewed craft be nodes?

I suggest proposal #0: just add SPUs to pods.

[Feldynn]

As someone that's quite new to this mod I'm very interested in the basic concept of having to set up proper satellite comms networks, especially now with the introduction of "Science" and the need to transmit that data across the solar system. I only briefly played with the old version and really liked the way the satellites link to KSC but I was wondering about the whole "signal delay" aspect and found this discussion, if it were possible with the new post 0.22 versions to have the delay as an optional feature that would be perfect for me.

I understand that others do want and enjoy that added sense of realism the delay brings though so I wouldn't want to see it removed entirely (options make everyone happy IMO), who knows I may come to enjoy it myself further down the line too but right now I'm just interested in the basic comms network side of things. However the development of this mod proceeds though it is still an amazing mod that brings a lot to KSP, kudos to all those involved in it's creation / development!

[TomatoSoup]

Adding the passive signal processor (contingent on having Kerbals aboard the vessel and being the active vessel) seems like the best solution to me. Moving antennas to Stayputnik tier would make early game research a chore. And it's just inelegant to always require a stayputnik (or equivalent) to report back to base.

[JumpsterG]

Why would one ever not have even crewed craft be nodes?

I suggest proposal #0: just add SPUs to pods.

While I prefer this also, I can see fun in the fact that not every ship or probe needs to be designed to act as a relay since that would require additional electronics (or some other suitable fluff). Some players would also like the option to use both limited probes (uncontrollable when not in contact) and stock probes (behave normally) in their game.

The best of all worlds would be to let the player choose from a number of settings:

-Relays are designated SPUs only OR all pods with antennas/dishes

-Contact required to control vessel OR unlimited control (a loss of contact does not result in loss of control)

-Science transmission limited (contact chain including KSC, contact chain including Command SPU or KSC), or unlimited (even out of contact, as per stock)

-signal delay OR no signal delay (if/when delay is added in)

The only things universal to all users is the line of sight requirement, antenna/dish ranges, comm or no-comm status indication, and pretty lines on the map view (Love these!). The rest make the game harder/easier or more/less realistic but are optional in my opinion and could be implemented any number of ways.

Edited October 17, 2013 by JumpsterG
Prettied up the post