Communications range

[Timtower]

Is there a way to modify the communications range? Can't download my land script from an orbit around the moon anymore Preferably without having to compile it myself, went wrong before

[Dunbaratu]

Perhaps there should be a config option to disable the range check for people who don't want it?

[Timtower]

@Dunbaratu That would be very nice to see, didn't had this issue a couple versions before, update also broke my transfer script but that should be a fix on my side

[erendrake]

I would rather follow the base game. If antenna don't have range in KSP I dont think we should enforce arbitrary and non configurable ranges. If users want this kind of behavior, we can simply encourage them to use RemoteTech.

[Timtower]

@erendrake Could you rephrase that? I read it as: if people want range on antenna's then they should install RemoteTech, But the code forces me to put antenna's on my ships

[erendrake]

@Timtower I am remarking about how this feature is working today in kOS.

Right now we do a pretty poor job of documenting how the range check works, its not user configurable, its really just a crappy feature that RemoteTech does so much better that i feel like removing it entirely.

If the base game antenna had explicit ranges in their config we would respect them in our code. since they dont i would rather behave in a more stock fashion. Also this feature likely kills anyone using most of the realism mods from using kOS.

[Timtower]

@erendrake I would go with the infinite range method unless the user also has RemoteTech, I just want to build, code, fly, crash, code again, crash again etc etc etc. I don't feel like extending my antennas to copy the script to my ship.

[erendrake]

@Timtower having said all of this, i would strongly encourage you try RemoteTech. Its a great mod and adds a lot of flavor to KSP and kOS :)

[Timtower]

@erendrake I am using loads of unmanned stuff though, not really something that is easy with RemoteTech installed. And I am pretty bad at KSP, mostly playing it for the building and crashing. Adding RemoteTech would only be in my way ( making relay stations isn't exactly a funny task, certainly not outside of the Kerbin influence ( only been there once before to get science, out, science, back in, land ) )

[baloan]

I would rather follow the base game. If antenna don't have range in KSP I dont think we should enforce arbitrary and non configurable ranges. If users want this kind of behavior, we can simply encourage them to use RemoteTech.

I second this motion and propose to go beyond. I'd like to see the kOS storage move from the ship's VAB file to the Plugins\kOS\storage directory. So when I do switch to 0. I have access to all files in Plugins\kOS\storage0, switch to 1. ... - you get my drift. This allows to manage script sets for different missions. The storage limit would disappear, and rightly so, today's rockets have more storage than the ones in the Apollo era. Remote Tech brings back the restrictions. I like that approach.

[teleksterling]

As a mere non-contributer, I also second (third?) this motion. I play with RT2, but thinking about someone who doesn't I suspect that wouldn't expect to have new range restrictions imposed by kOS that aren't present in the base game for manually piloting a probe craft. (I'm actually a bit rusty - are there range restrictions in stock?)

Handballing the range and antenna behaviour to RT2 and then focusing this teams efforts on integrating with that through APIs seems like a sensible way to go, IMHO.

One of these days I'll find the time to download the repo and make a contribution... :smiley_cat:

[erendrake]

I have been thinking about it a bit more. I think i might still require an antenna to be extended to contact the archive. just as the base game needs an antenna deployed for sending science.

[teleksterling]

just as the base game needs an antenna deployed for sending science.

Ah, so that's how it works in the stock game.. Yeah, that sounds sensible to me.

[Dunbaratu]

The base game does not require an antenna extended to transmit science. The game causes the antenna to be extended when you transmit science if it's not already extended. Frustratingly, it then automatically retracts the antenna after transmitting science, even if the antenna was not retracted to begin with. This is annoying because it means we can't really have a rule that requires the antenna be extended in order to talk to the CPU on the vessel, because the moment someone transmits science from the vessel, the vessel would then be lost forever, being unable to extend the antenna again because we can't talk to it to get it to extend the antenna. I wish the stock game didn't auto-retract the antenna after transmitting science, but unfortunately it does, which then makes it hard for mods to require an extended antenna to contact the craft.

[pjf]

I'm just about to install KOS; so I'm commenting from a position of ignorance here, but +1 on requiring a RemoteTech connection (if RT is installed), or always allowing script changes if not.

Also, a huge thank you. KOS looks amazing; as someone who automates much of my life, I'm looking forward to automating probe re-entry as well.:)

[SolarLiner]

One can run a check for the antennas every 10 seconds (for example), assuming you can do that in kOS. This also can be dine within, the module: automatically extend the antenna, remembering its start position. Also, that is a bug to be reported on KSP. On Jun 3, 2014 7:23 AM, "Steven Mading" notifications@github.com wrote:

The base game does not require an antenna extended to transmit science. The game causes the antenna to be extended when you transmit science if it's not already extended. Frustratingly, it then automatically retracts the antenna after transmitting science, even if the antenna was not retracted to begin with. This is annoying because it means we can't really have a rule that requires the antenna be extended in order to talk to the CPU on the vessel, because the moment someone transmits science from the vessel, the vessel would then be lost forever, being unable to extend the antenna again because we can't talk to it to get it to extend the antenna. I wish the stock game didn't auto-retract the antenna after transmitting science, but unfortunately it does, which then makes it hard for mods to require an extended antenna to contact the craft.

— Reply to this email directly or view it on GitHub https://github.com/KSP-KOS/KOS/issues/130#issuecomment-44921281.

[futrtrubl]

I see 3 options for stock.

1. Scrap range altogether. Justification is that if the user wanted to play realistically they would put antennas on anyway and if they didn't want to put on antennas anyway then the range mechanic just gets in the way of their fun. This simplifies RT2 integration since nothing needs to be done, if it has control it's within range.
2. As long as a ship has a part with ModuleDataTransmitter allow it to send/recieve no matter where or what. You could actually tie in with that science system to make it deploy the antenna automatically whenever data is moved and have it cost electric charge. This would get around the problem of antennas not having ranges and allow 3rd party antennas to work too.
3. Add your own range module to the parts. I would scrap the current range calculation system as it isn't realistic and doesn't add to gameplay. Just use the range of the longest antenna. Stock ranges could be about 5-6Mm for the long antenna, everything within Kerbin's SoI and a bit more for the small dish, and then everything in Kerbol's SoI for the large dish. Having a new module allows you to add a default range to any 3rd party antenna that has a ModuleDataTransmitter via module manager and allows others to write MM cfgs for those 3rd party parts.

Remote tech integration. Any option has to get around RT2's delay for local programs. Edit: Yes, I had forgotten the other pretty important thing, allowing local programs to have control when RT2 says you have no control.

1. Is easiest, other than above nothing needs to be done to make it work together.
2. Instead of ModuleDataTransmitter you would have to look for RT2's ModuleRTAntenna since it removes ModuleDataTransmitter from parts.
3. If RT2 is present disable your own system. Now you have to worry about whether it's actually in range of the space center or it just has local control. Of course you could just ignore that and say that if it's under local control then the Kerbals are just typing it out from memory instead of downloading it from the archive.

Edward

[SolarLiner]

I'd choose the 2nd, because it fits the vanilla logic more. If one wants to play with antenna realism, one installs RT2, and it just happens that kOS supports RT2 natively. On Jun 3, 2014 9:18 PM, "futrtrubl" notifications@github.com wrote:

I see 3 options for stock.

1. Scrap range altogether. Justification is that if the user wanted to play realistically they would put antennas on anyway and if they didn't want to put on antennas anyway then the range mechanic just gets in the way of their fun. This simplifies RT2 integration since nothing needs to be done, if it has control it's within range.
2. As long as a ship has a part with ModuleDataTransmitter allow it to send/recieve no matter where or what. You could actually tie in with that science system to make it deploy the antenna automatically whenever data is moved and have it cost electric charge. This would get around the problem of antennas not having ranges and allow 3rd party antennas to work too.
3. Add your own range module to the parts. I would scrap the current range calculation system as it isn't realistic and doesn't add to gameplay. Just use the range of the longest antenna. Stock ranges could be about 5-6Mm for the long antenna, everything within Kerbin's SoI and a bit more for the small dish, and then everything in Kerbol's SoI for the large dish. Having a new module allows you to add a default range to any 3rd party antenna that has a ModuleDataTransmitter via module manager and allows others to write MM cfgs for those 3rd party parts.

Remote tech integration. Any option has to get around RT2's delay for local programs.

1. Is easiest, other than delay nothing needs to be done to make it work together.
2. Instead of ModuleDataTransmitter you would have to look for RT2's ModuleRTAntenna since it removes ModuleDataTransmitter from parts.
3. If RT2 is present disable your own system. Now you have to worry about whether it's actually in range of the space center or it just has local control. Of course you could just ignore that and say that if it's under local control then the Kerbals are just typing it out from memory instead of downloading it from the archive.

Edward

— Reply to this email directly or view it on GitHub https://github.com/KSP-KOS/KOS/issues/130#issuecomment-45008178.

[pjf]

Does kOS support RT2 natively? I saw some hooks in the code and config files, but I wasn't sure if they were complete yet.

Does RT2 expose an API which allows one to check if science can be transmitted? If so, then that's a perfectly good check for "we can reach mission command" (or a suitably large control centre that acts as mission command). We can use that to determine if new programs can be uploaded, volume zero accessed, etc. This is a better check than simply do we have control (which may just mean that Jeb is looking out the capsule window with awe).

For non-RT2 behaviour, I have no opinions except that a "disable range checks" be popped in a config file (if not already there).

[Dunbaratu]

1. Scrap range altogether. Justification is that if the user wanted to play realistically they would put antennas on anyway and if they didn't want to put on antennas anyway then the range mechanic just gets in the way of their fun. This simplifies RT2 integration since nothing needs to be done, if it has control it's within range.

The problem with this is that one of the purposes of kOS is supposed to be that it allows a craft to operate autonomously (running your pre-prepped program while you can't talk to it) even when out of range. The big problem with RT2 integration has been that when RT2 tries to prevent user control of the craft because it's out of range, instead of locking it out at the level of the user-input to the craft, it locks it at a deeper level than that, preventing other mods like kOS from controlling the craft as well.

In other words, because the craft is out of range, the software on the craft gets disabled as if it was the user trying to manually control the craft, which isn't logical and interferes a bit with the purpose of kOS.

[pjf]

@Dunbaratu: Oh. What you've described (controlling the craft when out of range) is exactly my use case. Dang. :/

[erendrake]

RemoteTech has an API that lets you "Sanction" another addon's control. Once you do that it is executed as local commands with no delay or connection issues.

The problem up to now has been the bugs in RemoteTech and no active development made expanding and improving the API impossible. Now that there is a team i plan to get in there and make it much more robust.

If you want to turn on the Beta integration we have today, its in the kOS config file.

[pjf]

@erendrake : Sweet! I'm already testing the release candidates for RemoteTech, so I'll flip the kOS boolean and see what happens. You rock!

[Timtower]

Whoo, started a revolution :D But as long as it works then I am okay with everything