remotetechnologiesgroup / remotetech Goto Github PK

Original issue at Cilph/RemoteTech2#243.

AJMansfield wrote:

Could you add the ability for a command stations (or probes) that are out-of-range of KSC to receive science transmissions and re-transmit them once KSC is back in range?

Original issue at Cilph/RemoteTech2#244.

Pezmc wrote:

Mainly dishes often loose the vessel they are focussing on "unknown vessel" and "active ship" targeting doesn't work.

Original issue at Cilph/RemoteTech2#201.

Peppe-KSP wrote:

Decouple or undock a satellite. If you stay in physics range you can switch to that satellite and activate anything you like with action groups, but cannot activate/control anything with mouse or movement keys.

Original issue at Cilph/RemoteTech2#231.

Starstrider42 wrote:

It might be worth considering making a 90-100Gm antenna, which would work for Jool but not Eeloo, but which could be used as a cone at closer ranges than either of the current giga-dishes

Original issue at Cilph/RemoteTech2#207.

Cilph wrote:

Mode 1: Target planets. Has the cone of vision (dish parameter).
Mode 2: Target satellites. Currently it's very static and does not use the cone of vision in any way. I intend on changing this to function like above.
Mode 3: Groups. You can subscribe a number of satellites to a group, such as "LKO Sats", and you will be able to target everything in that group at once.

Original issue at Cilph/RemoteTech2#164.

BigD145 wrote:

This has occurred in a couple situations, but the root cause seems to be when coming out of high warp and physics kicks in or when loading a vehicle from the KSP tracking station or switching active vessels and physics kicks in. So far it has only happened when there are active long range (350Gm, 400Gm, or 60Gm) antennas connecting two vessels that are in two different SOI's (Kerbin/Jool and Jool/Sun).

Original issue at Cilph/RemoteTech2#153.

Original issue at Cilph/RemoteTech2#240.

TerrorBite wrote:

The EXEC instruction should take the throttle slider into account, and set the throttle to that value when executing the maveuver node (with consequent increase in time before cutting off the throttle).

Original issue at Cilph/RemoteTech2#219.

bk2w wrote:

At each node in the search, the algorithm was saving the cost from the starting node plus the heuristic to the goal. Once the goal is reached, the total cost is calculated as the cost to reach the goal from the start (current.Cost, which is at the actual sum of distances) plus each of the cost+heuristics along the path. Thus the reported total cost is dramatically larger than the actual cost. At the end of the search, current.Cost holds the correct cost.

Original issue at Cilph/RemoteTech2#56.

jonathan-ng wrote:

Whenever a probe core is on a ship, the stage indicator is always purple. This is possibly related to Issue #52, which seems to affect all decouplers, including stock.

Cilph wrote:

Intended behaviour is for the staging lock to work entirely client-side, without time delay. It would prevent transmission of a staging control signal. However the intercepting of the staging signal might cause the stage indicator to light up. I'll have a look at that.

The RemoteTech map GUI -- the toolbar at the bottom right, plus the button on the middle right to display a list of vessels, plus the flight computer window -- does not disappear when using F2 to hide all GUI elements. Only a cosmetic bug, but quite annoying if you want clean screenshots.

This bug was found using v1.3.3 + Community Hotfix, and appeared with both KSP 0.23 and 0.23.5.

Original issues at Cilph/RemoteTech2#208 and Cilph/RemoteTech2#220.

macdjord wrote:

In previous version of RemoteTech, it was possible to activate, deactivate, or retarget an antenna even if you had no connection. This was a very useful feature...

I therefore propose that this ability be restored. Due to its unrealism, it should be optional, perhaps controlled via an option in the config file like signal delay is.

Original issues at Cilph/RemoteTech2#173, Cilph/RemoteTech2#183.

May be rendered obsolete by #27.

kaufman-bryce wrote:

The feature to target the active vessel is quite nice, but could be made much more powerful if that option caused the dish to aim at the planet the active vessel is orbiting as well. Alternatively, a separate option to target active body.

HoneyFox wrote:

The idea is simple, i would like to use some pseudo-codes:
if ( activeVessel.MainBody == dishIterated.Vessel.MainBody )
fallback to "ActiveVessel" logic // P2P connection logic
else
dishIterated.setTarget( ActiveVessel.MainBody ) // Cone-angle check logic

Original issue at Cilph/RemoteTech2#163.

HoneyFox wrote:

I made a maneuver of circularization at the estimated Ap position after the aero-brake with delay of 356h00m00s, time to the aero-braking Pe is about 355h30m00s. I assumed that the period of the orbit after aero-brake would be around 60 minutes so I added 30min.
I fast-forwarded and then started the aero-brake, and after that, time-to-Ap is roughly 30 minutes, but I checked the flight computer, only to find there's still 90 minutes left there.

HoneyFox wrote:

And I also encountered similar issue in other situations: one of them was a probe orbiting Minmus and I planned a burn with delay of around 9 minutes but the delay got an error of more than 1 minute, there was no SOI change in this case nor was there power supply issue because solar panels have been extended and the orbit plane's normal was pointing towards the sun.

It would be helpful if the flight computer icon would change to indicate the following two states:

• There are actions scheduled in the computer queue, or the computer is holding attitude.
• Manual delay is non-zero.

The second, in particular, is a very frustrating mistake to make ("Why isn't the ship responding to my commands? Why is the flight queue full of the action group I'm trying to use? Ohhh..."), so it should have a prominent icon.

Original issue at Cilph/RemoteTech2#215.

Cilph wrote:

Proposition: mouse-over / click on a satellite in map view to either open the targeting menu or give a summary of distance and connections.

Original issue at Cilph/RemoteTech2#181.

krenshala wrote:

I'm not sure if there is an easy way to do this, but it might be worthwhile to have RT disable itself in the tutorial scenarios to prevent causing issues for those trying to complete them.

Original issue at Cilph/RemoteTech2#175.

tal2410 wrote:

When I undock two vessels, only one of them remains controllable. Both have a connection (green icon: and omni line in map view), electric charge, command pod, antennas...

Sometimes, the vessel without a connection can still change attitude if SAS was left disabled, but everything else is unavailable (SAS, RCS, thrust, action group).

Original issue at Cilph/RemoteTech2#239.

mrthehud wrote:

When you schedule a command for days in the future (mid course correction when Kerbin is behind Kerbol), and then time accelerate, the ship power drops to 0 when at full time warp (8th warp arrow) and the flight computer clock seems to stop. Warping at 1 less than full (7th arrow) seems to prevent the vehicle power draining fully.

Original issue at Cilph/RemoteTech2#205.

tntristan12 wrote:

I am trying to get the computer to orient my ship surface prograde (though this seems to happen regardless of what commands I'm trying to give it), and the ship completely loses control and starts spinning in random directions (note, I'm saying "spinning" not "wobbling", as the ship is holding completely rigid), and never actually settles on the heading I'm trying to give it.

Actually, in that case it seemed to cause the issue when MechJeb was in control, but I have a craft that is demonstrating this same behavior regardless of whether or not I'm controlling from the MechJeb case or not.

SodaPopinski wrote:

In order to make this bug happen, you need to change the "Control from Here" from the probe core to something else. That usually does it. You may need to set it back to the original probe core. I haven't tested it with 2 probe cores, but it happens when I control from a docking port, and switch back. I removed all other mods, and this still happens.

Another display issue I've noticed, but this one has gameplay effects. When you add a sequence of actions to the flight queue, they are not always listed in order of execution. Maneuver node EXEC commands, in particular, are always at the bottom of the queue. This makes it hard for the player to visualize the execution sequence, and allows for possible mistakes.

This bug was found using v1.3.3 + Community Hotfix, and appeared with both KSP 0.23 and 0.23.5. It partially motivates #26.

Original issues at Cilph/RemoteTech2#139, Cilph/RemoteTech2#242.

Lexif wrote:

From a gameplay perspective, it feels like an artificial restriction to me. I'm supposed to imagine I control a probe from mission control, so I should be able to switch the target of dishes on other probes without jumping through hoops, right? Switching vessels works too, but it is quite slow and awkward.

cerebrate wrote:

Dishes should be retargetable from Tracking Station ...when there's a connection from Mission Control to the satellite, ship, etc., that they're attached to. As mission control guy in charge of communications, I shouldn't have to spend the extra time to switch in and out of complete control of the ship just to retask one antenna.

Original issues at Cilph/RemoteTech2#120, Cilph/RemoteTech2#134, Cilph/RemoteTech2#233.

Not to be confused with the active relay "bug", as this issue also affects omnidirectional antennas.

Vranir wrote:

Notice on "untitled" ship and "test2" that not only do the dishes lose connection but also no connection is established on omni antennas between the separated stacks.

Cilph wrote:

Definitely seeing something here. My rewrite of the log system definitely shows that both Com Stn I and Test 2 have the correct connection to one another, but there is no link being made despite the distance being more than valid.

Techjar wrote:

If I go back to the space center then go to the tracking station, it works for a moment then freezes. The freeze does not happen if I don't decouple the rover, however.

Resender wrote:

Well the conclusion is when dealing with the dishes,they have to be paired up.
If the pair gets broken up,by one directing to a new target but the other still pointing at the partner the freeze happens if the distance is long enough.

rpayne88 wrote:

When I track the booster, it doesn't have a connection, yet the CM a mere 50m away does have a connection to the ground. I've even changed the antenna range to 10Mm and it still doesn't connect.

Original issue at Cilph/RemoteTech2#196.

krenshala wrote:

the Flight Computer (RT2v1.3.3 pulled from Spaceport) seems to be doing only a portion of the intended burn, whether I am using an Xm/s [burn] instruction or setting a maneuver node and pressing [exec]. In all cases I've tested so far the burn is at most about 30% of the intended duration.

Cilph wrote:

Someone made a fix for this a long while ago. There just hasnt been a new release yet.

Original issue at Cilph/RemoteTech2#222.

Grunf911 wrote:

The issue i reported is of pure display nature (not technically a bug) It's that the in the Flight Computer queue you will not see the remaining ETA time until the Materials bay will fire (unlike if you choose burn it would say signal 3m + delay 7m).

Original issues at Cilph/RemoteTech2#187, Cilph/RemoteTech2#189.

This bug was supposed to have been fixed by the community hotfix. Unfortunately, reports of its demise seem to have been exaggerated:

Zardizz wrote:

Yeah I am also experiencing this with the updated DLL.

Xiong wrote:

I, too, have been running the "community hotfix":
http://www.mediafire.com/download/dncc8qu44t30a90/RemoteTech2_2014.01.08.22.30.zip

I had not seen the issue described here previously but I just now caught something looking like it: lots of ugly UI issues, Space Center does not show; and when I quit and restarted, my station (with RT2 parts on, of course) had been duplicated -- exact superimposed duplicate leading to instant self-destruct. Resolved this by reloading and simply terminating all but the first duplicate station.

Original issue at Cilph/RemoteTech2#210.

krenshala wrote:

Just ran into a problem with the flight comp not properly orienting the craft based on the maneuver node as it should (screenshot). In the screenshot provided i set a manuver node on the opposite side of the orbit (Trans Munar Insertion burn), programmed the flight computer when to do the burn and clicked "Node". The craft swung around like it should to point in the correct direction ... almost.

Original issue at Cilph/RemoteTech2#223.

morden96 wrote:

Debris items are currently displayed in the antenna configuration list. This can be very distracting. While it is possible that debris may have active antennas (ie it was manually changed to debris), it is unlikely. I recommend filtering out or providing the option of filtering out debris from the antenna configuration list to reduce the clutter.

Original issues at Cilph/RemoteTech2#198, Cilph/RemoteTech2#211, and Cilph/RemoteTech2#212.

xu-cheng wrote:

It would be great to allow the player disables the RemoteTech sometimes without removing the whole mod.

Also since this mod is a hard mode plugin. Maybe also let player choose turning it on or off in 'create new game' phase.

xZise wrote:

I would like to have the possibility to deactivate at least two RT features without having to reload/restart the game:

• Deactivate the “speed limit”
• Deactivate checking if the craft has a connection

Cilph wrote:

Ability to configure everything from the config file ingame and allow it to adjust settings without requiring a reboot.

Original issue at Cilph/RemoteTech2#216.

mellon85 wrote:

It would be great if the flight computer would "remember" the action to be taken even when there is a ship change. The actions would then be executed only if the ship is the target at the time they should be executed, and maybe dropped in case the focus arrives too late?

Original issues at Cilph/RemoteTech2#100, Cilph/RemoteTech2#199, Cilph/RemoteTech2#214.

NathanKell wrote:

I would also suggest a "last leg: current/max" indicator, as usually what really matters when looking at the range indicator is "how far away can I get from the last relay" not "how long is the path?" IMO that's even more important than total path length.

xldenis wrote:

It would be useful to have a quick view of the distance between various ships so that it is easy to establish whether or not you can connect to a ship before accidentally losing connection and losing your ship. This has been happening to me while setting up a geo sync network, I've been setting up the satellites at 120 degree angles to replace my first network, but the 5MM omnis I have been using are just barely out of too far from each other to make the connection. If I could have seen the distance between the ships I could have quickly figured out the problem and solved it.

Cilph wrote:

List the distance to a satellite in the target selection menu.

Original issue at Cilph/RemoteTech2#206.

NJC2 wrote:

I would like to be able to set up the command queue in the flight computer before transmitting it to the craft to be executed. If I need to set multiple commands to go off in a specific order at specific times, I'd like to set all of that up, be able to double check it, then transmit the command queue to the craft when I'm ready.

Original issue at Cilph/RemoteTech2#228.

Starstrider42 wrote:

Unlike commands given with a user-specified delay, where the flight computer subtracts off the signal delay (i.e., requesting a 3-minute delay with a 30-second time lag will cause the probe to carry out the command 2.5 minutes after getting the signal), the node execution is always pushed back from the planned maneuver node by an amount equal to the signal delay.

Original issues at Cilph/RemoteTech2#173, Cilph/RemoteTech2#200.

krenshala wrote:

Also of note, targetting a specific bodies does not establish communication with the active vessel when outside that bodies SoI, even if the active vessel is inside the LoS angle. As an example, I set up a comm array with three dishes targetting the Mun, then sent a manned orbiter to the Mun on a free return trajectory. While on the line between the Mun and Kerbin, but outside the Mun's SoI, there was no communication despite being at the focus of three different satellites targetting the Mun. Comms immediately picked up as soon as the craft reached the Mun's SoI.

maxdreamland wrote:

I stumbled upon a scenario where the function "isTargetingPlanet()" in RangeModelExtensions does not provide the correct return value.

the function asumes that a potentially targeted satelite has to orbit the targeted planet. only after this is checked it is tested if the satelite is inside the DishAngle ("vision cone"). This is not always sufficient.

Original issue at Cilph/RemoteTech2#213.

jdmj wrote:

1. Expanding satellite list. LMB on satellite opens another list with antenna characteristics where you can change dish targets (kinda like RT1). Maybe with FC buttons for satellites in physical range (use case: orienting space station prior to docking without switching to it).
2. Expanding "cheat/debug" list of options (also suggest removing visibility check override from "Infinite EVA fuel").

Original issue at Cilph/RemoteTech2#174.

aoighost wrote:

One thing that would be interesting to have implemented would be loss of contact with the craft during reentry.

Original issue at Cilph/RemoteTech2#246.

VasVadum wrote:

http://steamcommunity.com/sharedfiles/filedetails/?id=263283991
My satellite basically wiggs the f out so badly that in under 3 seconds of sitting on the launchpad, the entire thing snaps into pieces and goes flying through the air, and that's before I even turn my engines on.

VasVadum wrote:

Anyway, I tried with other dishes and they work. I'm now using the one that folds up and closes.

Original issue at Cilph/RemoteTech2#218.

Cilph wrote:

Resolves the issue of installing RT2 in the wrong location.

I'd like to rebase feature/refactor off the current master and then extract the partially refactored codebase, so that the history makes more sense. Any objection to rewriting history on an as-of-yet unused branch?

MechJeb has a clever system where they use dummy parts to let upgrades (in their case, of MechJeb capabilities) appear in the tech tree. This provides players with feedback on how their technology is getting upgraded.

We might want to do something similar with the 3 km omnis unlocked by Unmanned Tech. Currently, the only way to know when the integrated antenna becomes available is to read the config files, or ask somebody who has.

Original issue at Cilph/RemoteTech2#185.

RedAV8R wrote:

However now, as it exists, every satellite/object that is now within that specified range of the GPS constellation also has comms. While it may be possible IRL, I don't think that is the normal way of doing things. Adding some sort of type to omni's would allow basically networks of objects only talking with like objects.

Original issue at Cilph/RemoteTech2#217.

Original issue at Cilph/RemoteTech2#140.

Original issue at Cilph/RemoteTech2#159.

Original issue at Cilph/RemoteTech2#221.

Cilph wrote:

As I don't have any time myself I'm leaving this issue open until someone (most likely eggrobin) figures out the maths required. There's no rush, but I have a lot of different stuff to do before 0.24 comes out in about a month.

Original issue at Cilph/RemoteTech2#195.

Original issue at Cilph/RemoteTech2#226.

Grunf911 wrote:

Could it be possible to add some sort of RCS translation controls (the ones that are keybinded to I,J,K,L, H, and N respectively) to Flight computer
(so we could queue them as regular burns - whether to use sec for duration or m/s is less important)

Original issue at Cilph/RemoteTech2#192.

rottielover wrote:

I'm having an issue where the green link line will disappear in map view, but this is purely visual, as I still have a connection and full control of my craft. Sometimes turning the link display off and back on fixes it but not always.

krenshala wrote:

Just for reference, Cilph, I've also see this happen with 0.23. The other manifestation of it is the active network being displayed, but not properly rotated with the camera while in the map view. It behaves almost like one of the rendering transforms has an inverted sign, but only on one axis. And only when the bug happens.

Original issue at Cilph/RemoteTech2#194.

Original issue at Cilph/RemoteTech2#125.

sarbian wrote:

Can you add short range radio to EVA Kerbal so we can transmit EVA report and samples without having to get back inside the ship.

tyrope wrote:

Instead of draining power from the ship, I'd add enough electricity in the EVA suits for a few communications, that way you're more accurately simulating a radio battery.