Jump to content

Now-defunct-thread-that-should-not-appear-in-google-search.

Cilph

By Cilph
in KSP1 Mod Releases

 Share

Recommended Posts

Miximix

Miximix

Posted
Posted

Hello guys! I'm not sure if this question was asked before, but i am using realism overhaul and RSS and i'm slightly confused on how to make a working relay network with new launchpad position. I'm used to launch from the equator, but now launchpad is at cape canaveral so i can't figure out how to create a proper relay network. Maybe there is a way to change launch position to New Guinea (second remote tech location), which is approximately at the equator? I appreciate any help!

Link to comment
Share on other sites
Mecripp

Mecripp

Posted
Posted
Hello guys! I'm not sure if this question was asked before, but i am using realism overhaul and RSS and i'm slightly confused on how to make a working relay network with new launchpad position. I'm used to launch from the equator, but now launchpad is at cape canaveral so i can't figure out how to create a proper relay network. Maybe there is a way to change launch position to New Guinea (second remote tech location), which is approximately at the equator? I appreciate any help!

This should set RT2 to all of them just copy it over to your RT2 folder and override and make a backup first.https://www.dropbox.com/s/qsz0s1hrognvy9q/RemoteTech_Settings.cfg

Link to comment
Share on other sites
Mecripp

Mecripp

Posted
Posted (edited)

Yes it will make a ground station at every 1.

Edit What you mean in RSS ? in RT2 they will always be on so you will have alot of connections from kerbin to your network.

Edit form RSS at the tracking station there you pick what launch sight you want.

Edit It may have been the Map view sorry don't use RSS all the time.

Edited by Mecripp2
Link to comment
Share on other sites
Alewx

Alewx

Posted
Posted
Probably not. RemoteTech was going to be placed under new management, but both the old and new managers seem to have vanished. Odds are that, by the time we have everything polished and ready for a release, 0.24 will be available.

I will Keep playing with 23.5 as Long as RT2 is working.

Link to comment
Share on other sites
Shivaran

Shivaran

Posted
Posted

Hey guys,

Anyone else has problems to get two dishes to connect while not in the same SOI?

It's been a while since I played KSP and hadn't done an unmanned interplanetary mission since 23.5

This mod is really one of my favorite mods. It would really be a shame for it to fall into oblivion.

Too bad my coding skills are practically nonexistent or I would gladly contribute...

Link to comment
Share on other sites
Frederf

Frederf

Posted
Posted

If memory serves to connect two SOIs you aim the antenna-dish at the other SOI and effectively target every thing in it simultaneously. So from a craft in Duna SOI you aim at Eve SOI and the craft in Eve SOI you aim at Duna SOI and both craft are linked.

Link to comment
Share on other sites
Grunf911

Grunf911

Posted
Posted

I think it depends on the cone of the antenna. The most powerful ones have such narrow cone that you have to point them directly to the craft rather than planet and it's SOI.

Link to comment
Share on other sites
marce

marce

Posted
Posted
Probably not. RemoteTech was going to be placed under new management, but both the old and new managers seem to have vanished. Odds are that, by the time we have everything polished and ready for a release, 0.24 will be available.

Which isn't that bad after all since 0.24 already got its feet wet in experimentals once :)

Link to comment
Share on other sites
Shivaran

Shivaran

Posted
Posted
I think it depends on the cone of the antenna. The most powerful ones have such narrow cone that you have to point them directly to the craft rather than planet and it's SOI.

It works for other people then.

I'll have to tinker with my install.

Link to comment
Share on other sites
marce

marce

Posted
Posted

Could someone please help me to understand the flight computer? I watched some tutorial videos but it doesn’t work out for me… :(

Mission: execute a burn at the periapsis to increase apoapsis, about 180dV

What I tried so far:

  1. Create the maneuver node
  2. Align vessel to the node

    2. Either with MJ or
    3. By clicking node button at the flight computer which starts to use RCS at an insane rate and slooooowly aligns the vessel

    4. Prepare flight computer
      1. By clicking kill rot or (continues to drain RCS non-stop)
      2. Clicking off or
      3. Keeping it on node (continues to drain RCS non-stop)

[*]Press exec on the flight computer, maneuver now planned

[*]Wait/warp until node is reached, at this time the vessel is usually slightly off the exact node direction

[*]Burn is started correctly

[*]At the end of the burn the maneuver node starts to move away fast and faster as usual, that’s the time when MJ would reduce throttle and correct. The flight computer keeps burning at max.

[*]Now, since the vessel is moving in the wrong direction because it is not aligned with the maneuver node any more, the dV needed to complete the maneuver increases again. Therefore the flight computer keeps burning at max increasing the needed dV even more. It continues to do that until

  1. Fuel is out
  2. It’s back in control range and I can shut down everything

This happens at almost every maneuver, maybe an orbit change of about ~4dV works every now and then.

What I’m doing wrong here? Any advice?

In any case: if it is somehow possible I’d love to have RT only delaying commands to MJ instead of bringing its own flight computer in the next version, since we already have a very well working autopilotish system and the RT authors could save time utilizing it. No?

Thanks in advance!

Link to comment
Share on other sites
erendrake

erendrake

Posted
Posted

In any case: if it is somehow possible I’d love to have RT only delaying commands to MJ instead of bringing its own flight computer in the next version, since we already have a very well working autopilotish system and the RT authors could save time utilizing it. No?

Thanks in advance!

I believe the idea was not to have an autopilot like mechjeb do the work for you when out of communication range. Cliph and I talked a lot about interop between kOS and RemoteTech and I believe using kOS would be more in keeping with the idea of RemoteTech making the game more realistic.

Link to comment
Share on other sites
marce

marce

Posted
Posted
I believe the idea was not to have an autopilot like mechjeb do the work for you when out of communication range. Cliph and I talked a lot about interop between kOS and RemoteTech and I believe using kOS would be more in keeping with the idea of RemoteTech making the game more realistic.

Oh I'm not talking about stuff like landing/docking or other complex operations. I only want a reliable way to execute at least one maneuver node and thought it may be easier to accomplish that way.

If you are going with kOS I'm happy too as long as it works (which it does not for me at the moment).

Link to comment
Share on other sites
Mecripp

Mecripp

Posted
Posted
I believe the idea was not to have an autopilot like mechjeb do the work for you when out of communication range. Cliph and I talked a lot about interop between kOS and RemoteTech and I believe using kOS would be more in keeping with the idea of RemoteTech making the game more realistic.

Not every one wants to use KOS and a fight computer is a flight computer MJ , KOS , and all the rest.

Link to comment
Share on other sites
Starstrider42

Starstrider42

Posted
Posted (edited)
  1. Create the maneuver node
  2. Align vessel to the node

    2. Either with MJ or
    3. By clicking node button at the flight computer which starts to use RCS at an insane rate and slooooowly aligns the vessel

    4. Prepare flight computer
      1. By clicking kill rot or (continues to drain RCS non-stop)
      2. Clicking off or
      3. Keeping it on node (continues to drain RCS non-stop)

[*]Press exec on the flight computer, maneuver now planned

[*]Wait/warp until node is reached, at this time the vessel is usually slightly off the exact node direction

[*]Burn is started correctly

[*]At the end of the burn the maneuver node starts to move away fast and faster as usual, that’s the time when MJ would reduce throttle and correct. The flight computer keeps burning at max.

[*]Now, since the vessel is moving in the wrong direction because it is not aligned with the maneuver node any more, the dV needed to complete the maneuver increases again. Therefore the flight computer keeps burning at max increasing the needed dV even more. It continues to do that until

  1. Fuel is out
  2. It’s back in control range and I can shut down everything

This happens at almost every maneuver, maybe an orbit change of about ~4dV works every now and then.

What I’m doing wrong here? Any advice?

Well, first bit of advice is to not use RCS, especially during the actual burn. RT2 is, as you've noticed, fairly aggressive in its attitude corrections. You should have no sustainability problems if you use reaction wheels.

The second problem sounds like a bug. Unlike MJ, RT2 does *not* wait for some specific delta-V criterion to be satisfied -- it calculates a burn duration, then burns for that amount of time. So the only way to get the behavior you're seeing is if RT2 overestimates the burn length.

What engines are you using? Are you using throttle limiter (which RT2 doesn't recognize yet, it will in the next version)? Is it an unusually light/heavy ship?

Also, the flight computer should display the expected burn time in the action queue. How does that compare to the desired burn duration?

Edited by Starstrider42
Link to comment
Share on other sites
marce

marce

Posted
Posted (edited)
Well, first bit of advice is to not use RCS, especially during the actual burn. RT2 is, as you've noticed, fairly aggressive in its attitude corrections. You should have no sustainability problems if you use reaction wheels.

Alright, can do that!

The second problem sounds like a bug. Unlike MJ, RT2 does *not* wait for some specific delta-V criterion to be satisfied -- it calculates a burn duration, then burns for that amount of time. So the only way to get the behavior you're seeing is if RT2 overestimates the burn length.

What engines are you using? Are you using throttle limiter (which RT2 doesn't recognize yet, it will in the next version)? Is it an unusually light/heavy ship?

Also, the flight computer should display the expected burn time in the action queue. How does that compare to the desired burn duration?

Actually it's a very very simple ship since I'm currently trying to get my very first RT comsat into orbit. I also avoided RO/RSS for the moment, so everything is quite stockalike with the exception of some procedural tanks.

The ships has about 25t (first stage still has some fuel left, the probe itself is ~2t I think). Currently the stock Skipper engine of the first stage is in use.

No throttle limiter in use.

I tried to enter all data manually: 30s before node turn prograde, 5s before node start burning 181.2m/s at full throttle. The vessel stayed at prograde perfectly fine during the burn, but again, it simply didn't cut off the engines but kept burning forever :(

Here is a screenshot of my (over-winged) test vessel with vessel info, node info at the navball and my manual flight computer settings (RCS now turned off, different time settings then before but everything else is the same):

SXi2dSG.jpg

And after getting the dV needed down to 0 it just keeps burning forever resulting in ever increasing dV indicator at the navball:

lsaMKd6.jpg

From KSP.log (the burn messages at the end are going on forever until I killed KSP actually there are no further messages but it continues to hold the prograde direction and stays throttled up):

[LOG 18:53:28.618] Mode: Hold OBT Prograde
Signal delay: 0.00s + 0.04s
[LOG 18:53:28.618] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.61s
[LOG 18:53:28.635] Mode: Hold OBT Prograde
Signal delay: 0.00s + 0.02s
[LOG 18:53:28.636] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.59s
[LOG 18:53:28.646] Mode: Hold OBT Prograde
Signal delay: 0.00s + 0.01s
[LOG 18:53:28.647] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.57s
[LOG 18:53:28.664] Mode: Hold OBT Prograde

[LOG 18:53:28.665] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.55s
[LOG 18:53:28.682] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.54s
[LOG 18:53:28.699] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.52s
[LOG 18:53:28.716] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.51s
[LOG 18:53:28.726] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.49s
[LOG 18:53:28.747] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.47s
[LOG 18:53:28.765] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.46s
[LOG 18:53:28.783] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.44s
[LOG 18:53:28.800] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.42s
[LOG 18:53:28.817] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.41s
[LOG 18:53:28.828] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.39s
[LOG 18:53:28.848] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.37s
[LOG 18:53:28.866] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.36s
[LOG 18:53:28.883] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.34s
[LOG 18:53:28.901] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.32s
[LOG 18:53:28.918] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.31s
[LOG 18:53:28.935] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.29s
[LOG 18:53:28.973] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.27s
[LOG 18:53:28.990] Burn 100.00 %, 181.20m/s
Signal delay: 0.00s + 19.24s

Update: It works when I'm entering a burn time (in seconds), it simply does not count down m/s! Any ideas what I'm doing wrong when entering m/s? Or can I somehow determine the burn time based on thrust, mass and dV needed? That would work for me until the new release hopefully fixes what I suppose to be a bug since I've seen someone entering m/s values in one video.

Update 2: And I know why! Since I don't know where the src for the "community patch" dll is I quickly fired up dotPeek and looked at the burn command.

else if (this.DeltaV > 0.0)
        {
          fcs.mainThrottle = this.Throttle;
          this.DeltaV -= (double) this.Throttle * FlightCore.GetTotalThrust(f.Vessel) / (double) f.Vessel.GetTotalMass() * (double) TimeWarp.deltaTime;
        }

This would be quite fine, if not FlightCore would be looking for ModuleEngines

public static double GetTotalThrust(Vessel v)
    {
      double num = 0.0;
      foreach (ModuleEngines moduleEngines in Enumerable.SelectMany<Part, ModuleEngines>((IEnumerable<Part>) v.parts, (Func<Part, IEnumerable<ModuleEngines>>) (p => (IEnumerable<ModuleEngines>) p.FindModulesImplementing<ModuleEngines>())))
      {
        if (moduleEngines.EngineIgnited)
          num += (double) moduleEngines.maxThrust;
      }
      return num;
    }

while Hotrockets changed my engines to ModuleEngineFX and so we multiply by 0 resulting in an everlasting burn.

Conculsion: I would happily compile it myself wiith that fixed if someone could point me to the source in question (I know about Cilphs GitHub repo but I don't think that's the one with the community patch)?

Update 3: never mind, I simply decompiled the whole project and patched it back together. Bug fixed, flight computer working as intended (rough attitude control but it does what it should do).

Thanks for your help!

Edited by marce
bug fixed
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...