[1.11] RemoteTech v1.9.9 [2020-12-19]

[Nathair]

1 hour ago, Ginlucks said:

consider you have a sat (named sat-far) too far to be reached by ksc, it would be nice that I can send a second sat (sat-messenger) that reach sat-far bring to it a msg: " hey even if we are too far from ksc and we can not comunicate with it at the moment, before launch it told me that you have to modify your trajectory with this commands. I coming back, my trajectory will bring me in a zone reachable by ksc, see you there!"

is it clearer now?

 

Clearer. I just don't see ever doing something like that. The whole point of the exercise is to set up comm links such that you're not sending probes off into the black with no way to control 'em. Sending your commands to your probes by physically sending other probes out to them with individual commands on board is more than a bit on the bizarre side.

[Yamori Yuki]

1 hour ago, Ginlucks said:

 

guys of course I know that if sat1 could reach sat2 and sat2 is linked to ksc sat 1 could be controlled

 

let me explain better:

consider you have a sat (named sat-far) too far to be reached by ksc, it would be nice that I can send a second sat (sat-messenger) that reach sat-far bring to it a msg: " hey even if we are too far from ksc and we can not comunicate with it at the moment, before launch it told me that you have to modify your trajectory with this commands. I coming back, my trajectory will bring me in a zone reachable by ksc, see you there!"

is it clearer now?

 

 

 

4 minutes ago, Nathair said:

Clearer. I just don't see ever doing something like that. The whole point of the exercise is to set up comm links such that you're not sending probes off into the black with no way to control 'em. Sending your commands to your probes by physically sending other probes out to them with individual commands on board is more than a bit on the bizarre side.

I am not aware if something like this being done in the history of our space exploration, but don't take my word on it, I'm no historian.
But this concept seems so perfectly Kerbal, that I'll write it down for later as storing and sending commands further should be possible within the framework we're currently constructing for handling commands in RT2.x.
Still, don't hold your breath

[Yamori Yuki]

7 hours ago, cyberpunkdreams said:

If this really necessary? kOS already does this kind of thing and a lot more, and RealChute lets you arm and set deployment parameters for your chutes.

I agree with @diomedea on this. Not everyone wants to use kOS, mostly because of the "a lot more" part making it a bit intimidating.

As RT already has to handle commands sent to vessels, it seems like a reasonable idea to include simple trigger conditions that will suffice for many, even if it cannot be used to auto land a Falcon 9 first stage.

[Ginlucks]

Just now, Yamori Yuki said:

 

I am not aware if something like this being done in the history of our space exploration, but don't take my word on it, I'm no historian.
But this concept seems so perfectly Kerbal, that I'll write it down for later as storing and sending commands further should be possible within the framework we're currently constructing for handling commands in RT2.x.
Still, don't hold your breath

well, yes it is Kerbal way... doing disaster and then find a way to remediate I am as a child waiting to go to Disneyland,  cant wait

[cyberpunkdreams]

11 minutes ago, Yamori Yuki said:

I agree with @diomedea on this. Not everyone wants to use kOS, mostly because of the "a lot more" part making it a bit intimidating.

As RT already has to handle commands sent to vessels, it seems like a reasonable idea to include simple trigger conditions that will suffice for many, even if it cannot be used to auto land a Falcon 9 first stage.

I get what you mean (and my original reply wasn't intended to be confrontational). I really just meant it from the point of view that the RT devs clearly already have a lot on their plate, so excluding features that are already covered by other mods may help to optimise the development process.

For what it's worth as well, I was very intimidated by kOS initially, but once I bit the bullet I actually found it fairly easy and very fun. There's a mad amount of useful things you can do with it, even if you eschew hard maths and orbital mechanics, plus it fits very well with RT, of course. Automating an atmospheric landing without control is an obvious one and hovering assist for a skycrane (or similar) is another.

[Yamori Yuki]

15 hours ago, cyberpunkdreams said:

I get what you mean (and my original reply wasn't intended to be confrontational). I really just meant it from the point of view that the RT devs clearly already have a lot on their plate, so excluding features that are already covered by other mods may help to optimise the development process.

For what it's worth as well, I was very intimidated by kOS initially, but once I bit the bullet I actually found it fairly easy and very fun. There's a mad amount of useful things you can do with it, even if you eschew hard maths and orbital mechanics, plus it fits very well with RT, of course. Automating an atmospheric landing without control is an obvious one and hovering assist for a skycrane (or similar) is another.

I didn't want to sound that defensive I just meant to explain why bother with conditions on commands and maybe discuss the reasons further.
I myself tried kOS before and I liked the idea. But it required too much learning outside KSP and I just wanted to play the game.
The idea of kOS is cool and it being available is awesome but It's hard to learn kOS by trial and error, unlike the rest ot KSP.
Maybe I'll give it another try sometime.

[Akke_Pakke]

Hi! I was just wondering if there would be any way to only have 1 "connection line" from a craft in map view? By this I mean all the crafts in the map, not just the active one. I have a big network and I would like to see that the sats are connected without all the additional clutter. Thanks in advance.

[doktorstick]

Good afternoon.

When interplanetary probes are traveling, sometimes they fall out of comms connection, especially early on in setting up networks. Is there a way to get a notification when a satellite reconnects its connection? I need to manage a few interplanetary satellites and their dish angle is too narrow at the moment, but when they are further out, they should establish a connection and I can make burn corrections.

Thanks.

P.S. If there isn't a way, mayhaps you can work with the KAC devs to get a new alarm type.

Edited January 22, 2017 by doktorstick

[linuxgurugamer]

@tomek.piotrowski

 

I've written a mod called SelectableDataTransmitter, which is being used in the Octosat mod on two antennas.  This mod allows an antenna to switch between DIRECT and RELAY mode.  It's been brought to my attention that this is not really compatible with RT.  @ICirceI posted a patch which removed it.  Is there any way to have RT be able to use this, or at least emulate it?  ise ethere are two ranges, Mode0DishRange and Mode1DishRange, could these be used for it?

Thanks

[Yamori Yuki]

4 hours ago, linuxgurugamer said:

I've written a mod called SelectableDataTransmitter, which is being used in the Octosat mod on two antennas.  This mod allows an antenna to switch between DIRECT and RELAY mode.  It's been brought to my attention that this is not really compatible with RT.  @ICirceI posted a patch which removed it.  Is there any way to have RT be able to use this, or at least emulate it?  ise ethere are two ranges, Mode0DishRange and Mode1DishRange, could these be used for it?

Thanks

In current versions of RT, there is no distinction between relay and direct antennas, every antenna on every vessel can relay. This comes mostly from the fact that so far RT is independent of CommNet and does not use any part of it. Instances of stock ModuleDataTransmitter are removed by MM patch in RT and CommNet is forced OFF.
The Mode0 and Mode1 ranges are un- and deployed range and the antenna only consumes power when in Mode1. So there's literally nothing to be compatible with.

A CommNet based RT is in the works, but it will be a while before it's released, even for testing.
In it, we plan to include new logic for determining a relay. Instead of an antenna (which never made much sense to me) the probe core will determine relay capabilities of a vessel.

[linuxgurugamer]

3 hours ago, Yamori Yuki said:

In current versions of RT, there is no distinction between relay and direct antennas, every antenna on every vessel can relay. This comes mostly from the fact that so far RT is independent of CommNet and does not use any part of it. Instances of stock ModuleDataTransmitter are removed by MM patch in RT and CommNet is forced OFF.
The Mode0 and Mode1 ranges are un- and deployed range and the antenna only consumes power when in Mode1. So there's literally nothing to be compatible with.

A CommNet based RT is in the works, but it will be a while before it's released, even for testing.
In it, we plan to include new logic for determining a relay. Instead of an antenna (which never made much sense to me) the probe core will determine relay capabilities of a vessel.

Ok, thanks.  So, in the future, would it be possible to have either multiple probe cores (one for relay and one for direct, for example) or an advanced probe core with both capabilities?

[Yamori Yuki]

1 hour ago, linuxgurugamer said:

Ok, thanks.  So, in the future, would it be possible to have either multiple probe cores (one for relay and one for direct, for example) or an advanced probe core with both capabilities?

Relaying should be a feature, not a switch, so a core that can relay will still have all the standard features including proper communication as required to fly it.
This will probably be implemented as a separate part module that will mark the vessel as relay-capable for our modified version of CommNetVessel, so it may allow creation of parts that would serve just as "relay computers".
At least that's the plan. We're still in early stages of RT2.0 development, but unless we hit an unexpected roadblock, it seems this should make it into first release, whenever that happens to be.

Also, in stock CommNet any relay antenna should work as a comms antenna as well, if I'm not mistaken. Haven't played around with that, yet.

Edited January 23, 2017 by Yamori Yuki
typos

[TaxiService]

On 1/22/2017 at 10:37 PM, Akke_Pakke said:

Hi! I was just wondering if there would be any way to only have 1 "connection line" from a craft in map view? By this I mean all the crafts in the map, not just the active one. I have a big network and I would like to see that the sats are connected without all the additional clutter. Thanks in advance.

Is this picture what you are looking for?

I looked up the RT codebase and found that it was trivial to slip in additional connection rules and a new icon button but I need more tests to be sure.

20 hours ago, doktorstick said:

Good afternoon.

When interplanetary probes are traveling, sometimes they fall out of comms connection, especially early on in setting up networks. Is there a way to get a notification when a satellite reconnects its connection? I need to manage a few interplanetary satellites and their dish angle is too narrow at the moment, but when they are further out, they should establish a connection and I can make burn corrections.

Thanks.

P.S. If there isn't a way, mayhaps you can work with the KAC devs to get a new alarm type.

No, the current RT 1.8.x does not have any notification system on connection events (I looked over the codebase and could not find any relevant) and I estimate it is not easy to implement this (edit multiple code places to broadcast upon reconnection). However, I think the stock CommNet has the infrastructure that should allow the easy broadcasting. I could look into this in the RT 2 redevelopment later.

[linuxgurugamer]

8 hours ago, Yamori Yuki said:

Relaying should be a feature, not a switch, so a core that can relay will still have all the standard features including proper communication as required to fly it.
This will probably be implemented as a separate part module that will mark the vessel as relay-capable for our modified version of CommNetVessel, so it may allow creation of parts that would serve just as "relay computers".
At least that's the plan. We're still in early stages of RT2.0 development, but unless we hit an unexpected roadblock, it seems this should make it into first release, whenever that happens to be.

Also, in stock CommNet any relay antenna should work as a comms antenna as well, if I'm not mistaken. Haven't played around with that, yet.

So, would you mind if I took your idea about a part which will add relay capabilities to an antenna and make it for the stock game? 

Also, in stock:

Quote

 

Direct antennas are for transmitting data from a craft back to the KSC and will not relay data from other direct antennas.

relay antennas cannot directly transmit data but form a path for direct antennas to transmit across.

Eg. Direct antenna -> Relay antenna -> Relay antenna -> KSC

 

 

Edited January 23, 2017 by linuxgurugamer

[cyberpunkdreams]

29 minutes ago, linuxgurugamer said:

So, would you mind if I took your idea about a part which will add relay capabilities to an antenna and make it for the stock game? 

I can't answer that question, but just to note, one of the questions on the "future of RT2 questionnaire recently was whether or not antennas can be switched in and out of "relay mode" (to paraphrase). I think that got the thumbs up, so I guess this functionality (or something like it) is in the roadmap. Personally, I really like that idea, whether it's VAB-only functionality, determined by parts (as it is now in stock), done on probe cores or on antennas, etc.

[linuxgurugamer]

1 minute ago, cyberpunkdreams said:

I can't answer that question, but just to note, one of the questions on the "future of RT2 questionnaire recently was whether or not antennas can be switched in and out of "relay mode" (to paraphrase). I think that got the thumbs up, so I guess this functionality (or something like it) is in the roadmap. Personally, I really like that idea, whether it's VAB-only functionality, determined by parts (as it is now in stock), done on probe cores or on antennas, etc.

Ok.  So I'm going to go ahead and move ahead with this.  I already have the code (from the Selectable Module Antenna I wrote), and once I can get someone to make me a couple of parts, I'll be able to have that added.

 

[Nathair]

11 minutes ago, cyberpunkdreams said:

one of the questions on the "future of RT2 questionnaire recently

 

The what now?

[cyberpunkdreams]

4 minutes ago, Nathair said:

The what now?

https://goo.gl/forms/8dZhPYBIZ3HaTju02

[cyberpunkdreams]

Are omni antennas supposed to be able to connect to dishes at much longer than the usual range? Cause my C-16s are showing the usual range (2.5Mm) but seem to be able to connect to dishes and KSC (not other omnis) from Mun and beyond.

[Jarin]

On 1/19/2017 at 11:56 AM, DerekL1963 said:

One obvious solution is to simply not put them in orbits leading or following the Mun...   There's no particular reason a RT bird has to be in that orbit.

The intent is to duplicate the Mun's L5 and L4 points, for relays to and from the back side of the mun. If your orbital period is the same of the Mun (or Minmus), it shouldn't drift in, but this level of precision is basically impossible over the long-term, even with save editing. 

[Errol]

On 23/01/2017 at 1:08 PM, cyberpunkdreams said:

https://goo.gl/forms/8dZhPYBIZ3HaTju02

Is it possible to view the results of that poll without voting again? I've already cast my opinions and don't want to cheat, but voted really early on so I have no idea what the result developed into...

[cyberpunkdreams]

13 minutes ago, Errol said:

Is it possible to view the results of that poll without voting again? I've already cast my opinions and don't want to cheat, but voted really early on so I have no idea what the result developed into...

Only with access to behind the scenes stuff I think... I've just looked for another way, but couldn't find any. However, it is public, so I don't see a problem with granting that access, but I'll wait for an RT dev to say something before granting that.

19 minutes ago, Jarin said:

The intent is to duplicate the Mun's L5 and L4 points, for relays to and from the back side of the mun. If your orbital period is the same of the Mun (or Minmus), it shouldn't drift in, but this level of precision is basically impossible over the long-term, even with save editing. 

Well, I know that it's not modelled the same way as real life, but you do get orbital decay. So you could pretend that that's why the orbits go out and adjust them accordingly now and then. Real satellites have to spend a bit of fuel doing that.

[Jarin]

40 minutes ago, cyberpunkdreams said:

Well, I know that it's not modelled the same way as real life, but you do get orbital decay. So you could pretend that that's why the orbits go out and adjust them accordingly now and then. Real satellites have to spend a bit of fuel doing that.

Yeah, but they typically handle that automatically. I should be able to have X monoprop on the sat or whatever, and have it hold position for Y years without my interference.

[diomedea]

2 hours ago, cyberpunkdreams said:

Well, I know that it's not modelled the same way as real life, but you do get orbital decay. So you could pretend that that's why the orbits go out and adjust them accordingly now and then. Real satellites have to spend a bit of fuel doing that.

 

1 hour ago, Jarin said:

Yeah, but they typically handle that automatically. I should be able to have X monoprop on the sat or whatever, and have it hold position for Y years without my interference.

Please allow me to jump in, though I hope this won't digress any more from RemoteTech as a subject. L4 and L5 lagrangian points are stable (if the major/minor mass ratio is > 24.96; Kerbin-Mun mass ratio = 54.227 therefore the system should be considered stable). As such, a vessel already in a L4 or L5 position won't require any active correction to keep orbiting around that point. Trouble is KSP using only two body gravitation, so lagrangian points can only be "faked in" but won't occur naturally (takes three body gravitation to make those positions stable). It may be considered beyond RemoteTech's scope to automatically correct stock KSP orbital decays, but certainly I'd welcome if it did. At no expense, as it wouldn't require any in reality with those stable L points.

[Jarin]

1 hour ago, diomedea said:

As such, a vessel already in a L4 or L5 position won't require any active correction to keep orbiting around that point.

True. Automatic station-keeping would help with things like geostationary sats as well, though, so that would be my preference.