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

[Gordon Dry]

 

[TaxiService]

22 hours ago, nickicool said:

Thank you very much for the answer! As you say - may be unsupported mod - in folder no patch file for mod this probe. I can't say exactly what mod - versions two: ResearchBodies or Tarsier Space Technology - they complement each other. Probe in my vessel - the telescope TB-75. Patch for these mods do not have RemoteTech. It's hard to add?

This my log file https://yadi.sk/d/AvtWphLu3KxFVS

Also, time start vessel in Tracking Station is blink between orange and green color, about every 2 seconds for each color. Other vessels so no - only green, without blinking. Screenshot https://yadi.sk/i/JMe7iVO13KxEZ2

Thanks for your log! This telescope part is belonged to the ResearchBodies mod and has the invisible manned capability (this is why you got local control). But it doesn't look like this mod supports RT, sorry.

This orange and green color has nothing to do with RT. It is KSP's indication about your computer performance (blinking orange means moderate/heavy CPU load).

 

14 hours ago, Grease1991 said:

Is there still plans to include the experimental ideas of CommNet Constellation or make that mod compatible with RT? 

We have a branch on RT 2.0, which has this constellation/frequency idea in its proposal (eg #187). So it will be eventually included ;-).

[nickicool]

I very like RT mod, but have one problem. The flight computer of RemoteTech is not available (a yellow icon and does not open), if  I used the crew command pods. I have problems with my hands and coordinating movements. The flight computer helped me execute maneuver nodes, I can't do them yourself very precisely.

Is it possible to include in the cfg file support the flight computer for a manned command pods? not for release - just for me. I'll add / remove some lines in the file, if you'll show me. And now, solution to this problem is only one for me yet - add probe to each manned command pod.

[KerbMav]

@nickicool I cannot say for sure, but I would try to add

MODULE[ModuleSPU] {}

to the command pods by putting this into a new config file somewhere in gamedata

@PART[*]:HAS[@MODULE[ModuleCommand,#CrewCapacity[>0]]]
{
MODULE[ModuleSPU] {}
}

This should target all command pods and exclude the probe cores (which are already handled by RT).

As I said, I am not sure that ModuleSPU will do the trick, but it is the only thing RT adds to stock parts that is not the antenna stuff.

But still, maybe try this in a new safe and backup your persistent file!

 

Edit: An after thought - I am not sure if this makes the flight computer - or control at all - unavailable without a connection back to KSC. So another test would be to cheat-menu a pod into an orbit around Eeloo and see what works and what doesn't.

Edited July 14, 2017 by KerbMav

[TaxiService]

@nickicool@KerbMav

You miss out one more square bracket at the end:

@PART[*]:HAS[@MODULE[ModuleCommand,#CrewCapacity[>0]]]

Nevertheless, it doesn't work in my RT tests. It seems there are both design separation and guard in the codebase.

As far as I can see, there is one workaround to have Flight Computer available for manned vessels is to attach a probe core to the vessel. It will act like a local computer to use in absence of working connection, as shown below.

 

[KerbMav]

7 minutes ago, TaxiService said:

 

 

Fixed. Thanks.

So, what if we make every pod also behave like a probe?

[TaxiService]

Just now, KerbMav said:

Fixed. Thanks.

So, what if we make every pod also behave like a probe?

That's the thing. I observed manned pods are given ModuleSPUPassive (lacking Flight Computer) while probe cores get ModuleSPU (with Flight Computer). In my quick check, I can't find any obvious code that assigns ModuleSPUPassive to manned pods. 

[KerbMav]

@TaxiService I thought more along the lines of making the pod like a probe and giving it:

MODULE
	{
		name = ModuleCommand
		minimumCrew = 0
		RESOURCE
		{
			name = ElectricCharge
			rate = 0.025
		}
		hasHibernation = True
	}

 

[Voodoo8648]

I'm noticing a problem where a probe will spin wildly out of control as it chasing after the Prograde Maneuver Node indicator when automatically executing a maneuver using RT's Flight Computer. 

Upon initial burn of the node, the probe will jump many degrees off of prograde and takes several seconds to re-acquire node's prograde... Upon the end of the burn, the Node indicator will start to move across the Navball and the probe will chase after it placing it into a spin. The Throttle will slow down and speed up during this dance. There is more than sufficient Reaction Wheel for SAS stability. 

For a comparison, the exact same probe will perfectly execute the exact same maneuver using Mech Jeb. No jumping around, no spinning while using MechJeb.   

 

[KerbMav]

@Voodoo8648 Had the same problem and was told to lower the thrust of the engine(s) - sometimes the TWR is to high for the autopilot to handle it seems.

[Voodoo8648]

Problem with Node Execution using RT Flight computer

@KerbMav Please see the above video... Decreasing the engine's thrust output somewhat helps, but the entire maneuver execution is still very sloppy. 

EDIT: 

I've literally tried for the past 2 day trying to raise the Apogee using the flight computer and it just doesn't work. Now, it won't even turn towards the Node's Prograde correctly... it just spins out of control when it comes time to point toward node, and sometimes won't even attempt to point toward node at all.

Edited July 18, 2017 by Voodoo8648

[occ]

Is there a dish that could let me transmit science back from a planet orbiting another star, like one from galactic neighborhood?

[strudo76]

Don't know if this is a bug or limitation of RT/KSP.

I have a probe I sent to an early RemoteTech based mission to get science from the Mun. I have no comms network anywhere near the Mun, so I've done nearly all of the mission using the flight computer to gather data. Since I want to collect both high and low science data, I have included a science box.

Using the manual delay system, I have scheduled my experiments to run once they enter the Muns SOI. I was intending to schedule collecting the science in the science box so I could use the experiments again near the low space peri. The problem arises because unless there is a collected science experiment on the vessel, the option to collect science doesn't show. It's easy enough to work around by just collecting some dummy science to click the button, but it would be nice if this wasn't required.

This is my first attempt at this so I don't even know if it will work as I think it does.

[KerbMav]

Just throwing this in here:

I took a science reading and transfered it to my space station via DMagics Science Relay mod - data was received at the station, but science was also logged into the R&D. (see screenshot)

https://www.dropbox.com/sh/5yj1va3wzmsa88w/AACdDChlmPN6ZW1j4j2xPxtaa?dl=0

Files with 2 ... are the newest.

Over there he said, "RT does something with science data, I believe in an attempt to get around problems with sending partial science data to the R&D center, this uses an aspect of science data in a way that isn't intended and basically breaks Science Relay. If you want them to work together tell the RT people to get around the partial data problem in a way that doesn't use the ScienceData.triggered flag in a way that isn't intended."

[Voodoo8648]

9 hours ago, strudo76 said:

 I have no comms network anywhere near the Mun, so I've done nearly all of the mission using the flight computer to gather data. 

I have a question for you: When your flight computer executes pre-planned maneuvers, does your craft start flipping around trying to chase after the node's prograde towards the end of the burn? Or is it a clean engine cutoff at the end and the ship doesn't move? If it is a clean burn, what is your TWR toward the end of the burn?

Reason I'm asking is because anytime I use the flight computer, my ship starts flipping around chasing after the maneuver node and continues firing the engines and ruins the maneuver and I think there is a bug with the RT flight computer.

[strudo76]

9 hours ago, Voodoo8648 said:

I have a question for you: When your flight computer executes pre-planned maneuvers, does your craft start flipping around trying to chase after the node's prograde towards the end of the burn? Or is it a clean engine cutoff at the end and the ship doesn't move? If it is a clean burn, what is your TWR toward the end of the burn?

Reason I'm asking is because anytime I use the flight computer, my ship starts flipping around chasing after the maneuver node and continues firing the engines and ruins the maneuver and I think there is a bug with the RT flight computer.

Sometimes it suits the burn exactly, others it does as you describe. Haven't really tried to see what the differences are between the two though. I have better luck with a craft that has engine gimble though, so figured it was something like moving off the node during the burn, and not having enough control to correct properly.

Something I have noticed though is sometimes the track maneuver node function misses the node by a long way. Like half a hemisphere on the nav ball. Dunno why, but that obviously stuffs things up unless I manually correct.

[cyberpunkdreams]

22 minutes ago, strudo76 said:

Sometimes it suits the burn exactly, others it does as you describe. Haven't really tried to see what the differences are between the two though. I have better luck with a craft that has engine gimble though, so figured it was something like moving off the node during the burn, and not having enough control to correct properly.

Something I have noticed though is sometimes the track maneuver node function misses the node by a long way. Like half a hemisphere on the nav ball. Dunno why, but that obviously stuffs things up unless I manually correct.

This is something that comes up a lot. The node drifting as you approach it is a bug/quirk of KSP. To stop RT trying to follow it, just reduce your TWR by a lot before the burn starts. You'll notice that MechJeb does this automatically as the node approaches to get around this problem. That might be a nice feature for the future of RT too.

[crapstar]

Hi all,

Is Remotetech2 still being worked on?

Thanks

[Voodoo8648]

1 hour ago, strudo76 said:

Dunno why, but that obviously stuffs things up unless I manually correct.

Right, and you can't manually correct if you don't have signal. I have found the Flight Computer to be almost useless.... which really sucks.

By the way, the problem is not lack of gimbaled engines... I think It's a bug in the flight computer... a problem in the coding. I find that it help to lock the gimbal.. but it still doesn't solve the problem

[Kerbart]

55 minutes ago, Voodoo8648 said:

Right, and you can't manually correct if you don't have signal. I have found the Flight Computer to be almost useless.... which really sucks.

By the way, the problem is not lack of gimbaled engines... I think It's a bug in the flight computer... a problem in the coding. I find that it help to lock the gimbal.. but it still doesn't solve the problem

While losing out on accuracy, I mitigate the problem by setting the flight computer to pro/retrograde. It's not as accurate as setting the F/C to the node, but you do bypass the extremely annoying spinning problem.

[KerbMav]

On 23.7.2017 at 10:37 AM, KerbMav said:

data was received at the station, but science was also logged into the R&D

On second thought - we actually like this strange behaviour, makes for less clickityclick, and also makes sense that the station keeps a copy before passing it on to the R&D.

5 hours ago, Kerbart said:

While losing out on accuracy, I mitigate the problem by setting the flight computer to pro/retrograde. It's not as accurate as setting the F/C to the node, but you do bypass the extremely annoying spinning problem.

At least works for nodes that only change one vector.

[strudo76]

Here's the problem I was referring to earlier

Clearly, that hasn't tracked to the orbital retrograde marker, which can be seen at the top border of the nav ball. This happens with both manned crafts and probes. And it also happens with manoeuvre nodes. This is a problem when programming the flight computer for out of contact commands. If I'm in comms range, I can manually move the craft to the correct attitude, if not, then the mission is pretty much a bust.

I'm not going to say it's Remote Tech causing this though, as if I turn the flight computer off and use the standard SAS, it will point to the same spot, missing the node by a long shot. The only reason I mention it here is that I didn't observe this behaviour before playing with Remote Tech. I'm more hoping that someone else has seen a similar behaviour in their games and can tell me what's going on. Whether it's some mod conflict or what I have no idea. I'm using almost 80 mods according to KSP-AVC, so a conflict is certainly possible, but it just seems so random. Sometimes it will track correctly, other times it's out like this.

Any thoughts?

Thanks.

 

EDIT: It should be noted that I have RCS on the top of this craft only, and RCS is enabled. I also use a custom MM patch to set reaction wheel pitch and yaw to 0, so only roll remains, and I scale the roll torque down by a factor of 5, so it's not very strong. Pitch and Yaw from reaction wheels just seems too outlandish for me. Could it be that Remote Tech isn't handling the unexpected zero valued pitch and yaw ability of the reaction wheels? Guess there is only one way to find out....

Edited July 24, 2017 by strudo76

[TaxiService]

Hi,

We are aware of this issue of node chasing. This usually happens when the TWR of your vessel is too high and the vessel starts to chase the node point around, trying to archive the zero dV fruitlessly. One or two improvements on the maneuver node execution were already in the develop branch to terminate instantly when the lowest point of dV is reached (rather than trying to reach the zero point). 

The other issue of excessive/little torque may be related to the experimental PID codes in RT (see this issue for interested). This outdated PID handles the torque workings, and in turn controls the pitch, roll and yaw of your vessel but it does poorly nowadays. We plan to attempt to separate and update this outdated codes with the latest codes from either kOS or MJ soon.

On 7/23/2017 at 2:26 PM, strudo76 said:

Don't know if this is a bug or limitation of RT/KSP.

I have a probe I sent to an early RemoteTech based mission to get science from the Mun. I have no comms network anywhere near the Mun, so I've done nearly all of the mission using the flight computer to gather data. Since I want to collect both high and low science data, I have included a science box.

Using the manual delay system, I have scheduled my experiments to run once they enter the Muns SOI. I was intending to schedule collecting the science in the science box so I could use the experiments again near the low space peri. The problem arises because unless there is a collected science experiment on the vessel, the option to collect science doesn't show. It's easy enough to work around by just collecting some dummy science to click the button, but it would be nice if this wasn't required.

This is my first attempt at this so I don't even know if it will work as I think it does.

On 7/23/2017 at 4:37 PM, KerbMav said:

Just throwing this in here:

I took a science reading and transfered it to my space station via DMagics Science Relay mod - data was received at the station, but science was also logged into the R&D. (see screenshot)

https://www.dropbox.com/sh/5yj1va3wzmsa88w/AACdDChlmPN6ZW1j4j2xPxtaa?dl=0

Files with 2 ... are the newest.

Over there he said, "RT does something with science data, I believe in an attempt to get around problems with sending partial science data to the R&D center, this uses an aspect of science data in a way that isn't intended and basically breaks Science Relay. If you want them to work together tell the RT people to get around the partial data problem in a way that doesn't use the ScienceData.triggered flag in a way that isn't intended."

Frankly, I have little experience with the RT's science experiment handling now. This is the first time I hear of this kind of problem and am not sure how I should analyse and decide how to proceed. Maybe down the road, I might take a close look at this.

[cyberpunkdreams]

2 hours ago, strudo76 said:

Here's the problem I was referring to earlier

Clearly, that hasn't tracked to the orbital retrograde marker, which can be seen at the top border of the nav ball. This happens with both manned crafts and probes. And it also happens with manoeuvre nodes. This is a problem when programming the flight computer for out of contact commands. If I'm in comms range, I can manually move the craft to the correct attitude, if not, then the mission is pretty much a bust.

I'm not going to say it's Remote Tech causing this though, as if I turn the flight computer off and use the standard SAS, it will point to the same spot, missing the node by a long shot. The only reason I mention it here is that I didn't observe this behaviour before playing with Remote Tech. I'm more hoping that someone else has seen a similar behaviour in their games and can tell me what's going on. Whether it's some mod conflict or what I have no idea. I'm using almost 80 mods according to KSP-AVC, so a conflict is certainly possible, but it just seems so random. Sometimes it will track correctly, other times it's out like this.

Any thoughts?

Thanks.

 

EDIT: It should be noted that I have RCS on the top of this craft only, and RCS is enabled. I also use a custom MM patch to set reaction wheel pitch and yaw to 0, so only roll remains, and I scale the roll torque down by a factor of 5, so it's not very strong. Pitch and Yaw from reaction wheels just seems too outlandish for me. Could it be that Remote Tech isn't handling the unexpected zero valued pitch and yaw ability of the reaction wheels? Guess there is only one way to find out....

Yes, this is clearly a separate problem than the node chasing, seeing as the vessel's pointing in the wrong direction in the first place! I doubt that's an RT problem -- more likely a problem with the vessel's configuration, or something like that? E.g. it's being controlled from the wrong part?

For what it's worth, RT should be able to control any ship that you can control with SAS or manually (within reason). It's also the case that KSP's reaction wheels are overpowered for sure, in terms of torque, but in reality they do actually provide torque in all three axes. There are a few mods for tweaking reaction wheels though, if you're interested.

[KerbMav]

54 minutes ago, TaxiService said:

Frankly, I have little experience with the RT's science experiment handling now. This is the first time I hear of this kind of problem and am not sure how I should analyse and decide how to proceed. Maybe down the road, I might take a close look at this.

It is far from urgent. Over at the Science Relay thread we are almost happy now that it is the way it is.

Only test remains if this also happens should the target vessel to which an experiment is transmitted has no connection to Kerbin, cause that would be "cheating".