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

[TaxiService]

On 1/17/2017 at 6:50 AM, doktorstick said:

OK, I'll give it a try. It still reads as a finicky solution. Right now I'm playing in custom harder mode and have resorted to save scumming and then turning on the cheat of allowing me to control probes out of comms and disabling it again once past the problem.

A very naive solution would be to turn off thrusters if the maneuver "needed" delta-V increases, even if it was a configuration option.

 

On 1/17/2017 at 4:24 PM, Ginlucks said:

Hi all,  I would report some problems:

1- sometimes flight computer execute a wrong manouvre,  it starts to alternate prograde and retrograde directions or executes a burn in prograde direction for a longer time than I setted up.  

2- when I set a burn it happens that the  timer for starting that is not more sync with time of the game,  so  it starts to burn later than I planned

3- question: is it possible to queue a second node? 

Thanks for reporting the flight computer issues. Unfortunately, most of the issues seem to be tied to the astrophysics maths buried inside the flight computer, that we (RT team) are yet to get familiar with. But don't worry as the rebuilt flight computer of RT 2.x under development is to piggyback the stock's autopilot functions (combined SAS and autopilot in KSP 1.1) instead of depending on the hard-written maths.

 

1 hour ago, Garlik said:

Hi guys,

Haven't tested RT since some time, is the old 'bug' of RT flight computer not being able to hold prograde/retrograde/... correctly finally solved? Last time I was using RT I remember it beeing almost impossible for me to control a probe because of that. Love RT though and would love to come back to it

Not sure how old is the bug but it is not present in the latest RT 1.8.4. I tested the flight computer thoroughly (apart from the minor glitches due to the sub-optimized maths inside the computer)

Edited January 18, 2017 by TaxiService

[Nathair]

What would be the formula for calculating range if I'm using the root model, a multiple anntena modifier and an antenna range modifier between two vessels each with multiple antennae?

For example, if I have two Communotron 16s and two Reflectron DP-10s on one sat and four Communotron 16s on t'other with a multiple modifier of 0.2 and a range modifier of 0.5... how is the range calculated?

[TaxiService]

31 minutes ago, Nathair said:

What would be the formula for calculating range if I'm using the root model, a multiple anntena modifier and an antenna range modifier between two vessels each with multiple antennae?

For example, if I have two Communotron 16s and two Reflectron DP-10s on one sat and four Communotron 16s on t'other with a multiple modifier of 0.2 and a range modifier of 0.5... how is the range calculated?

According to the online RT manual, this formula is min(r1, r2) + sqrt(r1 * r2).

[Nathair]

2 minutes ago, TaxiService said:

According to the online RT manual, this formula is min(r1, r2) + sqrt(r1 * r2).

Sure, for a single antenna talking to another single antenna.

[TaxiService]

2 minutes ago, Nathair said:

Sure, for a single antenna talking to another single antenna.

Sorry for reading your post incorrectly. I believe that each (dish-type) antenna on the vessel is still acting independently so the formula still applies when checking each antenna of two vessels. As far as I can see in the codebase, RemoteTech doesn't stack up the ranges of multiple antennas on a vessel into a single range.

[Nathair]

Just now, TaxiService said:

As far as I can see in the codebase, RemoteTech doesn't stack up the ranges of multiple antennas on a vessel into a single range.

1

It is supposed to if you set the MultipleAntennaMultiplier to non-zero. To quote the manual "This setting lets multiple omnidirectional antennas on the same craft act as a single, slightly larger antenna."

[TaxiService]

13 minutes ago, Nathair said:

It is supposed to if you set the MultipleAntennaMultiplier to non-zero. To quote the manual "This setting lets multiple omnidirectional antennas on the same craft act as a single, slightly larger antenna."

Wow, I am an idiot. Here're the code snapshots:

/// <summary>Returns the bonus from having multiple antennas</summary>
/// <returns>The boost to all omni antenna ranges, if MultipleAntennaMultiplier is enabled;
/// otherwise zero.</returns>
private static double GetMultipleAntennaBonus(IEnumerable<IAntenna> omniList, double maxOmni) {
  	if (RTSettings.Instance.MultipleAntennaMultiplier > 0.0) {
		double total = omniList.Sum(a => a.Omni);
		return (total - maxOmni) * RTSettings.Instance.MultipleAntennaMultiplier;
  	} else {
		return 0.0;
  	}
}

On given list of omni antennas and the max omni range of one vessel, this GetMultipleAntennaBonus function returns the double value (sum of every omni range but the max range and multiple it) to add to the given value of an omni antenna. Does this answer your query?

Edited January 18, 2017 by TaxiService

[Nathair]

19 minutes ago, TaxiService said:

On given list of omni antennas and the max omni range of one vessel, this GetMultipleAntennaBonus function returns the double value (sum of every omni range but the max range) to add to the given value of an omni antenna. Does this answer your query?

 

4

OK, so you're saying it takes the longest antenna range, adds a bonus of all the lesser antenna ranges added together and then multiplied by the multiple antenna factor, multiplies all that by the overall range multiplier, then plugs that number into the root range calculator?

So from the example above (multiple bonus of 0.2 and global range modifier of 0.5) with two '16s (range:A) and two DP-10s (range:B) on one sat it would lump them together as (A+((A+B+B)*0.2))*0.5 and then that becomes the r1 in the root formula min(r1, r2) + sqrt(r1 * r2). The second sat with four '16s would then be (A+((A+A+A)*.02))*0.5 and that's r2. Is that it?

 

Edited January 18, 2017 by Nathair

[TaxiService]

26 minutes ago, Nathair said:

OK, so you're saying it takes the longest antenna range, adds a bonus of all the lesser antenna ranges added together and then multiplied by the multiple antenna factor, multiplies all that by the overall range multiplier, then plugs that number into the root range calculator?

So from the example above (multiple bonus of 0.2 and global range modifier of 0.5) with two '16s (range:A) and two DP-10s (range:B) on one sat it would lump them together as (A+((A+B+B)*0.2))*0.5 and then that becomes the r1 in the root forumla min(r1, r2) + sqrt(r1 * r2). The second sat with four '16s would then be (A+((A+A+A)*.02))*0.5 and that's r2. Is that it?

 

The RemoteTech codebase indicates that:

1) At the beginning of a scene (flight or tracking station), the base range of an omni antenna, A_b, is multiplied by the range modifier of 0.5 so this antenna's final range A is A_b*0.5.

2) RemoteTech computes the bonus omni range on one sat (2 '16s and 2 DP-10s): (A+B+B)*0.2. Similarly, the bonus range on the other sat (4 '16s) is (A+A+A)*0.2. Then, when checking the possible connection between each antenna combination of these two sats, r1 = A_i + ((A+B+B)*0.2) and r2 = A_j + ((A+A+A)*0.2), where A_i is an omni antenna of one sat and A_j is an omni antenna of the other sat. I say combination because the codebase (link) compares every antenna of one sat against every antenna of the other sat, rather than picking the longest-range antenna of each vessel.

Edited January 18, 2017 by TaxiService
Updated

[Nathair]

Simple enough, thanks.

[Ginlucks]

4 hours ago, TaxiService said:

 

Thanks for reporting the flight computer issues. Unfortunately, most of the issues seem to be tied to the astrophysics maths buried inside the flight computer, that we (RT team) are yet to get familiar with. But don't worry as the rebuilt flight computer of RT 2.x under development is to piggyback the stock's autopilot functions (combined SAS and autopilot in KSP 1.1) instead of depending on the hard-written maths.

Well,  I cant wait for new version!  Mod is incredibile but at current time it is frustating use it. Do you think new version will be relase within a couple of week? 

Thx 

[neitsa]

10 minutes ago, Ginlucks said:

Do you think new version will be relase within a couple of week?

The only thing I can say for sure is that it will not be ready in a few weeks (not even in Q1 2017)

We are rebuilding RT from the ground up and we try to take cautious steps for nearly everything (discussing the idea, modeling the ideas in terms of code [classes or interfaces], how to implement it correctly, can it be used outside of RT or on its own, does it integrate well with other components, is it fast enough, etc.). It just takes time and we don't want to rush.

We don't have a clear view on when it will be released though.

 

 

 

[Ginlucks]

15 hours ago, neitsa said:

The only thing I can say for sure is that it will not be ready in a few weeks (not even in Q1 2017)

We are rebuilding RT from the ground up and we try to take cautious steps for nearly everything (discussing the idea, modeling the ideas in terms of code [classes or interfaces], how to implement it correctly, can it be used outside of RT or on its own, does it integrate well with other components, is it fast enough, etc.). It just takes time and we don't want to rush.

We don't have a clear view on when it will be released though.

 

 

 

Well, good luck so and thank you for your work!

If I can I would suggest a feature for next release: it would be nice if a probe or vessel could store a command to send then to another probe. This would permit to send instructions and pilot the second probe even when both have not a link with command centre!

[Varsi]

1 hour ago, Ginlucks said:

Well, good luck so and thank you for your work!

If I can I would suggest a feature for next release: it would be nice if a probe or vessel could store a command to send then to another probe. This would permit to send instructions and pilot the second probe even when both have not a link with command centre!

If the probes have link between them and either of them does have link to command center then they both are controllable.

[neitsa]

2 hours ago, Ginlucks said:

If I can I would suggest a feature for next release: it would be nice if a probe or vessel could store a command to send then to another probe. This would permit to send instructions and pilot the second probe even when both have not a link with command centre!

AS @Varsi said, I can't think of any scenario in which you could transmit from a vessel to another one: if the first vessel is not connected  to KSC that would mean that the second vessel is also not connected to KSC.

KSC <--> VesselA <--> VesselB

VesselA could transmit commands to VesselB, but VesselB is already connected to KSC (through A).

VesselA <--> VesselB

If you remove control from KSC, VesselA can't be controlled, thus it cannot transmit anything to VesselB (which is itself not controllable).

But one possible way though would be to add a specific planned command for VesselA with a condition [*] : If vesselA is within antenna reach of VesselB, transmit commands (commands in a specific buffer for ex.).

I don't know if it would be be useful though...

Not related to commands, but one thing that was discussed is issue #43 where vessels could transmit science to other vessels. We will implement it as there are some scenarios where that would be quite useful.

[*] we are working on conditional and planned commands for RT Flight Computer, like "Do x if condition is TRUE | FALSE", e.g.: Deploy parachutes IF altitude < 20 km AND surface_velocity < 300 m/s

Edited January 19, 2017 by neitsa

[diomedea]

40 minutes ago, neitsa said:

[*] we are working on conditional and planned commands for RT Flight Computer, like "Do x if condition is TRUE | FALSE", e.g.: Deploy parachutes IF altitude < 20 km AND surface_velocity < 300 m/s

Great . Conditional commands are a must have with probes, signal delay and occlusion. Hope conditions are to include something alike "IF (time to periapsis (or apoapsis, AN, DN) = predicted burn duration / 2) {DO burn}" and "IF (apoapsis (or periapsis, inclination) < set_value) {DO stop burn}".

[cyberpunkdreams]

56 minutes ago, diomedea said:

Great . Conditional commands are a must have with probes, signal delay and occlusion. Hope conditions are to include something alike "IF (time to periapsis (or apoapsis, AN, DN) = predicted burn duration / 2) {DO burn}" and "IF (apoapsis (or periapsis, inclination) < set_value) {DO stop burn}".

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.

[diomedea]

5 minutes 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.

Yes, is necessary for everybody who doesn't want to use kOS.

[SilentWindOfDoom]

Dealing with orbital drift?

While I love RT and using it in combination with KSP-I remote-power networks I have in the past always ended up canning the whole thing because of orbital drift. Even after I took to hyperEdit or save-editing directly and making sure not to focus or get in physics range I would find satellites drifting regardless.

Satellites in typical orbits, say synchronous ones around Kerbin would be fairly stable but for some reason satellites that I have leading or following the Mun or Minmus would end up getting eaten or flying off after encountering said moon.

I read the latest update might have fixed random drift somewhat? How do you maintain an ever expanding network of satellites over the course of years and years and deal with orbital drift? I've not found a way and it makes me quit ksp every time in frustration.

Edited January 19, 2017 by SilentWindOfDoom

[neitsa]

8 minutes ago, SilentWindOfDoom said:

I read the latest update might have fixed random drift somewhat?

Yep, but I don't know if it prevents drift for synchronous orbits though (especially with high time warps).

9 minutes ago, SilentWindOfDoom said:

How do you maintain an ever expanding network of satellites over the course of years and years and deal with orbital drift?

I always have modified the SMA (semimajor axis) of the satellites manually in the save file. This is cumbersome but I haven't fond a better way

There was a feature request for RT (namely issue #115) where RT would automatically set the SMA for a group of sats (under certain circumstances). We haven't discussed it, but if you have an opinion about this issue, we would be glad to hear it.

I haven't a precise idea on how we could / should implement it, but my preference goes over pjf comment. We have a plan for RT where we would allow various group of sats, so we could had this option within a group to set the SMA of all sats in the group to the same value...

[Nathair]

1 minute ago, neitsa said:

I always have modified the SMA (semimajor axis) of the satellites manually in the save file. This is cumbersome but I haven't fond a better way

 

 

I was typing exactly this when your response was posted.

Since station keeping isn't really an option a way to automate synching the SMAs once the sats were up would be handy. Perhaps only available if they were all within a margin of synchronization already?

[diomedea]

41 minutes ago, SilentWindOfDoom said:

Dealing with orbital drift? ...

 

Is it still that bad even after the improvements to reduce orbital drift introduced in KSP 1.1.3 (of course, having Orbital drift compensation on in KSP settings)? I would certainly like to see recent examples of orbital drift reported, of course without add-ons that could introduce themselves physical forces or otherwise modify orbits (to include any kind of kraken device). While automatic correction of SMA in a future RT version would definitely eliminate the issue, data from players careful to orbital dynamics could turn useful to further improve the stock game.

[SilentWindOfDoom]

2 hours ago, neitsa said:

Yep, but I don't know if it prevents drift for synchronous orbits though (especially with high time warps).

I always have modified the SMA (semimajor axis) of the satellites manually in the save file. This is cumbersome but I haven't fond a better way

There was a feature request for RT (namely issue #115) where RT would automatically set the SMA for a group of sats (under certain circumstances). We haven't discussed it, but if you have an opinion about this issue, we would be glad to hear it.

I haven't a precise idea on how we could / should implement it, but my preference goes over pjf comment. We have a plan for RT where we would allow various group of sats, so we could had this option within a group to set the SMA of all sats in the group to the same value...

On the face of it it seems like a pretty good solution. You fly one sat up to a given orbit, create a group for it, which inherits the SMA of the sat and will serve as a SMA snap point for other sats (and the original) once they get "close enough" and are set to snap to it. To clarify there will be no "master sat" but just a group that copies the SMA from the first one, but doesn't inherit any changes from it afterwards, correct? That would keep the SMA from drifting on load/unload of the first sat, but also make it impossible to ruin your entire group if something happens to it.

It would be nice if there was a provision to alter the "Group SMA" after creation, but I feel that might be open to exploitation and increase complexity too much. One can always nuke the group and create a new one on an altered sat.

Would it be possible to initiate a group with orbital bodies? I like having my sats lead and trail behind moons for cheap, "good enough" coverage. It would also make "Kerbol orbitals" less of a suicidal proposition if you can park it somewhere along the orbit of a planet.

I'm all for it, especially if the mod is separate from RT itself because the KSP-I sats suffer from the same problems. Would it help if I posted this in the Github thread? The thread there is a bit dusty.

1 hour ago, diomedea said:

 

Is it still that bad even after the improvements to reduce orbital drift introduced in KSP 1.1.3 (of course, having Orbital drift compensation on in KSP settings)? I would certainly like to see recent examples of orbital drift reported, of course without add-ons that could introduce themselves physical forces or otherwise modify orbits (to include any kind of kraken device). While automatic correction of SMA in a future RT version would definitely eliminate the issue, data from players careful to orbital dynamics could turn useful to further improve the stock game.

I honestly don't know. Spotting that option lead me to reconsider my RT-less career and post here to see what the current status of orbital drift was in the game before i went out and set it up. I'll definitely keep an eye out to see how KSP handles orbits now and report any findings.

[Ginlucks]

6 hours ago, neitsa said:

AS @Varsi said, I can't think of any scenario in which you could transmit from a vessel to another one: if the first vessel is not connected  to KSC that would mean that the second vessel is also not connected to KSC.

KSC <--> VesselA <--> VesselB

VesselA could transmit commands to VesselB, but VesselB is already connected to KSC (through A).

VesselA <--> VesselB

If you remove control from KSC, VesselA can't be controlled, thus it cannot transmit anything to VesselB (which is itself not controllable).

But one possible way though would be to add a specific planned command for VesselA with a condition [*] : If vesselA is within antenna reach of VesselB, transmit commands (commands in a specific buffer for ex.).

I don't know if it would be be useful though...

Not related to commands, but one thing that was discussed is issue #43 where vessels could transmit science to other vessels. We will implement it as there are some scenarios where that would be quite useful.

[*] we are working on conditional and planned commands for RT Flight Computer, like "Do x if condition is TRUE | FALSE", e.g.: Deploy parachutes IF altitude < 20 km AND surface_velocity < 300 m/s

 

7 hours ago, Varsi said:

If the probes have link between them and either of them does have link to command center then they both are controllable.

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?

 

 

[DerekL1963]

4 hours ago, SilentWindOfDoom said:

Satellites in typical orbits, say synchronous ones around Kerbin would be fairly stable but for some reason satellites that I have leading or following the Mun or Minmus would end up getting eaten or flying off after encountering said moon.

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.