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

[cyberpunkdreams]

1 hour ago, gunt3rgam3r said:

I'm sure this has been asked elsewhere, sorry for the double post.  What is the preferred setup for remote tech with regard to comnet?  Should you play with comnet selected on, or off?

If you change the various settings like there dsn percentage, does that affect remote tech at all?

Does remote tech use the comnet ground stations for kerbin?

Thx for maintaining this great mod.

At the moment you have to turn comm net off completely. None of its settings have any impact. In the next version of RT it'll be fully integrated though.

[Toonu]

Hello, I've heard before some months about Remote Tech 2 with incorporated (now) stock features of new antennas and dishes and also SCANsat instead of kerbin mapping (KerbNet I guess its named?). Is it still true, because I haven't been monitoring this mod for half year.

[SwissSpace93]

When i use a joystick, to control yaw pitch and roll, but without signal delay.

 

here is the Link to my Github Issue:

https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/742

[Errol]

On 04/02/2018 at 2:19 PM, Toonu said:

Hello, I've heard before some months about Remote Tech 2 with incorporated (now) stock features of new antennas and dishes and also SCANsat instead of kerbin mapping (KerbNet I guess its named?). Is it still true, because I haven't been monitoring this mod for half year.

Check the post immediately above yours.

Also, it is common courtesy to spend a little bit of your time to check back through the last few pages of a thread before posting a question, incase it was just answered. There is also a very useful search function in the upper right part of ever page on the site, which automatically searches within the thread you are currently viewing.

Lurk moar.

[Elouda]

On 2/3/2018 at 8:54 AM, TaxiService said:

Thanks for your log and screenshots.

I unsuccessfully tried to reproduce this issue on my side with RT only. On launch clamps, the control is always remote control. In another scenario of a probe rocket with manned pod attached to get the local control in first place, my engine never got shut down upon releasing clamps  and then dropping pod.

Can you try again with a stock engine instead? I am wondering if another mod or modded part is messing with throttle control.

I have this same issue present with RT 1.8.9 or 1.8.8, but not with 1.8.7. It seems to be an issue when using Realism Overhaul (possibly also with other mods that limit engine ignitions?), because it seems that after 1.8.7, RT will briefly zero the throttle when staging launch clamps, which is causing resulting in the need for an extra ignition, and subsequent failure when this isnt available.

Interestingly if the RT flightcomputer has a 'burn' running when the clamps are released, this does not happen. Also, cancelling the burn on the flight computer will also kill the engine (again due to ignitions) even if throttle is left at max (even when clamps were not involved at all).

Happy to provide more details to help track this down if needed.

EDIT: Problem would seem to be connected the changes made to FlightComputer/FlightComputer.cs on Aug 11, 2017 to fix issue #734. Commenting out line 376 and recompiling 1.8.9 seems to resolve the issue for me.

Edited February 7, 2018 by Elouda

[TaxiService]

21 hours ago, Elouda said:

I have this same issue present with RT 1.8.9 or 1.8.8, but not with 1.8.7. It seems to be an issue when using Realism Overhaul (possibly also with other mods that limit engine ignitions?), because it seems that after 1.8.7, RT will briefly zero the throttle when staging launch clamps, which is causing resulting in the need for an extra ignition, and subsequent failure when this isnt available.

Interestingly if the RT flightcomputer has a 'burn' running when the clamps are released, this does not happen. Also, cancelling the burn on the flight computer will also kill the engine (again due to ignitions) even if throttle is left at max (even when clamps were not involved at all).

Happy to provide more details to help track this down if needed.

EDIT: Problem would seem to be connected the changes made to FlightComputer/FlightComputer.cs on Aug 11, 2017 to fix issue #734. Commenting out line 376 and recompiling 1.8.9 seems to resolve the issue for me.

How did you fix the 1.8.9v FlightComputer.cs? The line 376 of 1.8.7v is shifted by later code changes and I would like to know where you commented out in the 1.8.9 codebase.

Also, I want to test the combination of RO and RT since you confirmed 5ardaukar's suspicion. Do you know where can I find latest Realism Overhual version for KSP 1.3.1? All I can see is RO v11 for KSP 1.2.2. If not, I go download and recompile for 1.3.1.

Thanks.

Edited February 8, 2018 by TaxiService

[Elouda]

23 hours ago, TaxiService said:

How did you fix the 1.8.9v FlightComputer.cs? The line 376 of 1.8.7v is shifted by later code changes and I would like to know where you commented out in the 1.8.9 codebase.

Also, I want to test the combination of RO and RT since you confirmed 5ardaukar's suspicion. Do you know where can I find latest Realism Overhual version for KSP 1.3.1? All I can see is RO v11 for KSP 1.2.2. If not, I go download and recompile for 1.3.1.

Thanks.

I downloaded the develop branch from https://github.com/RemoteTechnologiesGroup/RemoteTech/archive/develop.zip

The line seems to be moved to 373 on that, my bad. That is what I commented out and recompiled (this is all locally, not on git).

Latest RO for 1.3.1 is at https://github.com/KSP-RO/RealismOverhaul/tree/dev

I am also using RP-1 (dev branch of RP-0) and RSS and dependencies. I can upload and PM you a gamedata folder if this will help.

EDIT: Also, it seems turning signal delay off solves it on the official builds.

Edited February 9, 2018 by Elouda

[LAND ASAP]

9 hours ago, Elouda said:

I downloaded the develop branch from https://github.com/RemoteTechnologiesGroup/RemoteTech/archive/develop.zip

The line seems to be moved to 373 on that, my bad. That is what I commented out and recompiled (this is all locally, not on git).

Latest RO for 1.3.1 is at https://github.com/KSP-RO/RealismOverhaul/tree/dev

I am also using RP-1 (dev branch of RP-0) and RSS and dependencies. I can upload and PM you a gamedata folder if this will help.

Haha!

Since the there is still no stable update of RO for 1.3.1, I think it might be a heavy work to download all the dependencies manually.

 Still in 1.2.2 with RO, but there are so many amazing updates which are only available for 1.3.1.

 Looking foreword to the stable release.

[5ardaukar]

On 8.2.2018 at 3:20 PM, TaxiService said:

How did you fix the 1.8.9v FlightComputer.cs? The line 376 of 1.8.7v is shifted by later code changes and I would like to know where you commented out in the 1.8.9 codebase.

Also, I want to test the combination of RO and RT since you confirmed 5ardaukar's suspicion. Do you know where can I find latest Realism Overhual version for KSP 1.3.1? All I can see is RO v11 for KSP 1.2.2. If not, I go download and recompile for 1.3.1.

Thanks.

 

I am really thankfull for your efforts Taxiservice, because RT is one of my must have mods for immersion and realism... And as Elouda said the short "throttle cut off" also happens when cancelling a burn. Thing is, because of the limitied ignittions in RO this issue sometimes kills your "whole flight".

Another (really minor) "bug" i found in your latest version is: in earlier versions (with activated flightcomputer) a delayed response of rcs thrusters occured when i hit the corresponding keys (in most cases H & N) - used this to counteract ullage, now

with activated flightcomputer no response to the key input, therefore with activated SAS: no delay in in RCS-response at all... ;-)

Wish you a nice weekend and a big thank you...

[TaxiService]

23 hours ago, Elouda said:

I downloaded the develop branch from https://github.com/RemoteTechnologiesGroup/RemoteTech/archive/develop.zip

The line seems to be moved to 373 on that, my bad. That is what I commented out and recompiled (this is all locally, not on git).

Latest RO for 1.3.1 is at https://github.com/KSP-RO/RealismOverhaul/tree/dev

I am also using RP-1 (dev branch of RP-0) and RSS and dependencies. I can upload and PM you a gamedata folder if this will help.

EDIT: Also, it seems turning signal delay off solves it on the official builds.

This line?

//nullify throttle
autopilotfs.State.mainThrottle = 0f;

Looking at the RO's dependencies, I think it is better and faster to receive your gamedata folder (minus RP-1 if you think unnecessary) if you are okay with uploading the big size.

 

9 minutes ago, 5ardaukar said:

Another (really minor) "bug" i found in your latest version is: in earlier versions (with activated flightcomputer) a delayed response of rcs thrusters occured when i hit the corresponding keys (in most cases H & N) - used this to counteract ullage, now

with activated flightcomputer no response to the key input, therefore with activated SAS: no delay in in RCS-response at all... ;-)

What do you mean by "activated flightcomputer"? The stock SAS on (Key T)? If so, I know why it happened because I miss out some inputs like the joystick feedback.

[5ardaukar]

i´ll try to be more precise...

in earlier versions, i programmed flight computer (deactivated SAS of course) for example:

execute manouver node in 4m30s...

then i set the delay to 4mins...

and hold down the "H" key 30 secs to give the craft a small push to fight the ullage....

So the craft (while "steering" to manouver node prograde) accelerated a little in the last 30secs before the manouver was executed...

this doesn´t work anymore.... hitting the "H" key seems now to be ignored...

No great deal, cause there are other ways to handle ullage... Just  to let u know...

[TaxiService]

On 2/9/2018 at 11:40 PM, 5ardaukar said:

i´ll try to be more precise...

in earlier versions, i programmed flight computer (deactivated SAS of course) for example:

execute manouver node in 4m30s...

then i set the delay to 4mins...

and hold down the "H" key 30 secs to give the craft a small push to fight the ullage....

So the craft (while "steering" to manouver node prograde) accelerated a little in the last 30secs before the manouver was executed...

this doesn´t work anymore.... hitting the "H" key seems now to be ignored...

No great deal, cause there are other ways to handle ullage... Just  to let u know...

Yup, possibly not warrant an investigation for this bug type yet.

But it is my first time of hearing this scenario of ullage. Why do you need to fire ullage motors to accelerate little before the start of maneuver burning?

 

[danielboro]

3 hours ago, TaxiService said:

Yup, possibly not warrant an investigation for this bug type yet.

But it is my first time of hearing this scenario of ullage. Why do you need to fire ullage motors to accelerate little before the start of maneuver burning?

 

RSS/RO
the main motors need to be under G force for the fule to flow in the correct direction
to be in a stable state

Edited February 11, 2018 by danielboro

[TaxiService]

2 hours ago, danielboro said:

RSS/RO
the main motors need to be under G force for the fule to flow in the correct direction
to be in a stable state

Oh right, I forgot about RO. Thanks for informing me!

[Spike88]

I ended up giving up and reverting to stock commnet, but using a 2.5x rescale with remote tech kept leading to my rockets losing connection at 70KM. I tried using the 2.5 multiplier in the options, to no avail.

[TaxiService]

@Elouda @5ardaukar

I manage to reproduce the zero-throttle bug with re-compiled RO mod. It seems your launch clamp has ModuleCommand (RO is not responsible) that sets RT control state to Local Control at the beginning, as shown below.

Once I stage the clamp (and drop the pod instantly), the RT control state is switched to Delay seconds, causing the throttle bug.

I will log this bug in Github and analyse and fix the transition from Local Control to Remote Control.

Edit: I fixed it and made new build. Can go and test out on your side to see if it is resolved.

Edited February 18, 2018 by TaxiService

[danielboro]

i need help understanding way i dont have a connection
EC is 1010/1010 
solar is not out do to new install (wen installing Copernicus solar fix all solar get back in)

[Warp11]

On 15.1.2018 at 3:39 PM, Ketatrypt said:

I am having an issue with RCS, and engines with RemoteTech. RCS, and engine throttle ignore the signal, both connection, and delay. I can control both without any signal to the probe.

...

I figured it out - it was mechjeb... dunno why I even had that installed.. Hope deleting mechjeb hasn't broken anything else lol

Is there any solution for those of us who really want to use mechjeb for other crafts on the install or for attitude holding but still want their steering inputs delayed properly? Any settings on MechJeb I can change? I also recall scott manley using mechjeb in his lunar landing video and he definitely had signal delay.

EDIT: So I looked around a bit more and it seems you fixed this issue in a later release. I'm still using the RO 1.2.2 install though. I tried playing with the current Remote Tech version but the game crashes while loading. Can the fix for the delay be implemented into a version that is compatible with 1.2.2 RO? Maybe change a few lines somewhere or sth?

EDIT 2: So I uninstalled MechJeb and now it works but with the obvious downside of having no MechJeb for dV stats and everything. So the question remains if there is a way to get both to work.

Thank you!

Edited February 20, 2018 by Warp11

[TaxiService]

On 2/19/2018 at 8:15 AM, danielboro said:

i need help understanding way i dont have a connection
EC is 1010/1010 
solar is not out do to new install (wen installing Copernicus solar fix all solar get back in)

 

If I read your screenshot correctly, your probe was trying to connect to Mission Control whose max range is only 75Mm. That 75Mm is only enough to cover both Mun and Minmus. You need a commsat with a long-range antenna in Kerbin's SOI to connect to your probe.

23 hours ago, Warp11 said:

Is there any solution for those of us who really want to use mechjeb for other crafts on the install or for attitude holding but still want their steering inputs delayed properly? Any settings on MechJeb I can change? I also recall scott manley using mechjeb in his lunar landing video and he definitely had signal delay.

EDIT: So I looked around a bit more and it seems you fixed this issue in a later release. I'm still using the RO 1.2.2 install though. I tried playing with the current Remote Tech version but the game crashes while loading. Can the fix for the delay be implemented into a version that is compatible with 1.2.2 RO? Maybe change a few lines somewhere or sth?

EDIT 2: So I uninstalled MechJeb and now it works but with the obvious downside of having no MechJeb for dV stats and everything. So the question remains if there is a way to get both to work.

Thank you!

Why don't we just skip this and go straight to this point. I am too lazy to cherry-pick some newer fixes into a new RT for 1.2.2.

Since KSP 1.3 is KSP 1.2.2 with extra languages, I just re-compiled the latest codebase (RT 1.8.9 plus few new fixes).

Here's the unofficial release RT 1.8.9.122 for KSP 1.2.2.

Enjoy!

(It should work fine. I tested on 1.2.2 quick)

Edited February 21, 2018 by TaxiService

[sebam1975]

Hello, I am new to the forum.
After installing the Remote Tech I lost the connection signal.
Attachment captures.

Is there a way to reestablish it?
Thank you.

[Warp11]

23 hours ago, TaxiService said:

Why don't we just skip this and go straight to this point. I am too lazy to cherry-pick some newer fixes into a new RT for 1.2.2.

Since KSP 1.3 is KSP 1.2.2 with extra languages, I just re-compiled the latest codebase (RT 1.8.9 plus few new fixes)

Thanks a lot for your quick fix! It's still not working with MechJeb but a couple other annoying bugs have gone away. Thank you!

[TaxiService]

21 hours ago, sebam1975 said:

Hello, I am new to the forum.
After installing the Remote Tech I lost the connection signal.
Attachment captures.

Is there a way to reestablish it?
Thank you.

This comm bar is belonged to stock CommNet. RemoteTech 1.x is not compatible with CommNet and thus disables it to run its own infrastructure.

On Github page, you can find the detailed manual link to learn about RT mechanisms.

With this said, may I know your KSP and RT versions plus output_log.txt in KSP_x64 folder?

 

19 hours ago, Warp11 said:

Thanks a lot for your quick fix! It's still not working with MechJeb but a couple other annoying bugs have gone away. Thank you!

If I recall right, MechJeb and RT are fighting with each other over the same KSP's flight controls. Hence they are not compatible with each other.

I think I need to play with MJ and RT to see how it happens. I never use MJ before so I appreciate this if you can give some quick reproduce steps to use MJ interface/trigger the fighting.

I can't guarantee this can be fixed though.

Thanks.

Edit: Found how signal delay is ignored on the combination MJ and RT. If a MJ part (pod or box) is attached to the vessel, it acts as an independent command source, completely bypassing the signal delay. If the vessel is without MJ part, signal delay is in effect. I am messing with MJ at this moment to see if more MJ-RT issues can be found.

Edited February 23, 2018 by TaxiService

[sebam1975]

10 hours ago, TaxiService said:

This comm bar is belonged to stock CommNet. RemoteTech 1.x is not compatible with CommNet and thus disables it to run its own infrastructure.

On Github page, you can find the detailed manual link to learn about RT mechanisms.

With this said, may I know your KSP and RT versions plus output_log.txt in KSP_x64 folder?

Thanks for your quick reply.

I'm using KSP 1.3.1.1891 and RT version 1.8.9. (I think).

Here is my log. https://we.tl/nLNlH24diB

Thanks again.

[TaxiService]

3 hours ago, sebam1975 said:

Thanks for your quick reply.

I'm using KSP 1.3.1.1891 and RT version 1.8.9. (I think).

Here is my log. https://we.tl/nLNlH24diB

Thanks again.

I see nothing RT issue in your log, other than the ModuleManager exceptions (you got bunch of ModuleManager versions with 3.0.1 being latest).

In referring to your screenshot, I notice the RT delay window is not displayed as it should per my own picture below. CommNet bar is disabled and hidden.

It seems your RT is somehow turned off. Can you check RemoteTech_Settings.cfg in your save folder to see if RT is enabled and CommNet is disabled?

RemoteTechSettings
{
	RemoteTechEnabled = True
	CommNetEnabled = False
	...
}

 

Edited February 23, 2018 by TaxiService

[sebam1975]

12 minutes ago, TaxiService said:

It seems your RT is somehow turned off. Can you check RemoteTech_Settings.cfg in your save folder to see if RT is enabled and CommNet is disabled?

RemoteTechSettings
{
	RemoteTechEnabled = True
	CommNetEnabled = False
	...
}

 

Yes, it is shown as in your capture.
Do I have to enable both?
Something strange is that if I start a new game, in the first launch I see the commNet bar and the next one is hidden.
Once again thanks for your help and speed reply