[1.1] RemoteTech v1.6.10 [2016-04-12]

[Errol]

I think you should try colonizing another body with TAC installed and setting yourself a goal to not loose a single kerbonaut in the adventure. I've played a lot too, that's fine, I still like the sense of accomplishment I get when I complete a mission with RT and the rest of the mods.

Honestly though, get TAC. Without TAC, yeah, the game's balance is a little messed up, because kerbals are immortal. When the stakes are higher, I send probes first, just like in RL.

Also, all the probes were never intended to all be able to do all the nav functions. They just never implemented much of that till now.

Now that .9 is out, and a ton of mods have matured a whole lot, I'm ok with starting over grinding again. It's a good refresher course on piloting anyway.

EDIT: Didn't feel like posting again, but I endorse the next post.

Edited January 9, 2015 by Errol

[NihilRex]

As far as Flight Computer VS New SAS functions - In a real space program, you have interns and stuff who can be told to have the 6 directions ready at all times. There is a whole backend of people to run plotting tables, keep up running calculations, etc.

I see that as a primary reason to use probes early, simply because the control center can do things pilots cannot do nearly as quickly.

[Nitrous Oxide]

As far as Flight Computer VS New SAS functions - In a real space program, you have interns and stuff who can be told to have the 6 directions ready at all times. There is a whole backend of people to run plotting tables, keep up running calculations, etc.

I see that as a primary reason to use probes early, simply because the control center can do things pilots cannot do nearly as quickly.

Yes, exactly. The new SAS takes away from realism more than contributing to it in the case of probes... which is why I adamantly insist these changes don't affect the flight computer. I just like this mod too much as is to see it adopt some terrible design decision that Squad will probably end up changing more in the future themselves (or that someone will make another mod for). Heck, I wonder if I could write something with MM that upgrades probe cores as you unlock better tech...

For example, you've unlocked the OKTO2 and want to launch a satellite using the Stayputnik design (ya know, for visuals more than anything, where's the fun in my satellite design being restricted?)... it doesn't make any sense in my mind that your engineers and programmers can't figure out a way to get the new software into the old probe design... it seems like a very rushed decision by Squad (they probably were more focused on the actual Pilot skill) to fit the probes with the new SAS rules. It makes sense that you start with the lowest tech, but it's silly that your probe designs are literally unable to be adapted to new technology... uh... aren't they just cases with a bunch of circuitry? Couldn't one simply... replace the circuitry? Why when I have a full tech tree would my engineers build a Stayputnik without SAS? What possible reason could they have?

[Errol]

So then why did no one ever bother to design something new after the real sputnik design? I think it makes sense that older technology is just that, older technology. I must agree, I think that completely restricting the flight computer to the same standard as the SAS isn't a good idea, but I do think that having some sort of progression in the level of direct control that is possible is something that would enhance the experience while still maintaining a high level of abstraction to maintain playability. One possibility that comes to mind is something linking to KSC building upgrades rather then probe core SAS. Fewer levels involved, and it doesn't have to be just things like holding on nodes. MAybe that's the first level, then you get delayed commands, then you get queued commands. Or something. Just a thought.

Another thing that popped into my head on this discussion is that I like the idea that different probe cores have different levels of SAS because it's what would represent local control vs. direct control from KSC through RT. The point is if you "send an SAS hold node command" through RT to a probe and signal is subsequently lost, the probe is continue to hold that heading; whereas if you are holding a heading with the flight computer and loose signal the vessel will become adrift. I can think of some cases immediately where this would be relevant and that is aerobraking to enter orbit and for landing purposes. I'm not sure how this works works currently in RT, but it would make upgrade to probe hardware and software more useful. Especially if you are running a failure mod like DangIt! and there is the potential for antennas to break and batteries to short circuit.

[Gribbleshnibit8]

Is it possible to modify the settings file using MM? I'd prefer to keep my changes of adding more ground stations separate. I've made the file, and it shows up as all merging correctly in the MM cache file, but in game I don't get the added ground stations.

[Subcidal]

Is it possible to modify the settings file using MM? I'd prefer to keep my changes of adding more ground stations separate. I've made the file, and it shows up as all merging correctly in the MM cache file, but in game I don't get the added ground stations.

Make sure their above the ground, or the little red dot doesn't show. No idea if the signal goes through or not.

[Gribbleshnibit8]

Make sure they're above the ground, or the little red dot doesn't show. No idea if the signal goes through or not.

I made the config back for 23.5 and it worked then, as a direct edit of the settings file. I've tried several MM variations, as well as getting the file from Kerbin Side and testing it, neither of which worked, still only the KSC dot. Not running anything that should be affecting Kerbin size so they should be above the surface just fine.

[Peppie23]

Last changes for v1.6:

Bugfixes

- Keystrokes will no longer go through if the input is focused (fix for linux user)

- Fixed the thrown Exception if you have no ActiveVessel on the tracking station (reported by Tellion)

Contributors

- We removed the dependency to the task extensions

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

Download: https://github.com/RemoteTechnologiesGroup/RemoteTech/releases/tag/build-1.6.0-198

Thanks for testing

[JoseEduardo]

Can you give me some more informations please. The ksp log and screenshots would help me to find this issue.

sorry for the late reply, but i was only able to replicate it today

here's a pic of it, it happens everytime i have a target

i'm using 1.5.2 btw

[JDP]

sorry for the late reply, but i was only able to replicate it today ...

it happens everytime i have a target

i'm using 1.5.2 btw

It seems like you are using MechJeb and MechJeb is trying to set a target. That command is then sent to the RT flight computer which cannot act on it because you are out of power. Aparently this causes a loop where MechJeb constantly tries setting a target, which is rejected by the flight computer. That's my best guess anyway.

Try adding a couple of batteries to give your flight computer enough power while on ascent.

Edit: disregard. I just read your previous post. There could be some incompatability between RT and MechJeb here. You'll need to post a link to the output log. That will give some insight into what exactly is happening.

If there is a compatability issue here, then disabling the flight computer will not solve it. since this still seems to be a possible issue with the command queue, which is a core aspect of RT. No command queue, no signal delay.

Of course the easiest solution would be to remove MechJeb

Edited January 11, 2015 by JDP

[Mecripp]

JDP can your MicroSat and AeroProbe be post ?

EDIT- And shared here and used for other mod too ?

EDIT- Have them both working but one of the AeroProbe wings don't look right but it works all the same and thanks for a great mod and to all those that helped and helps.

Edited January 11, 2015 by Mecripp2

[JoseEduardo]

that also happens when mechjeb is off, in the pic it just happened that the same error happened with the ascent path, but i was experiencing it before when i targeted my space station, way before launching... that also happened with another station, an Almaz station, back in 0.25, and i only found out the issue when the station was in moho already (it had power though)

the main issue is that it was preventing me from time warping, i was able to circumvent that by messing with the settings, but the error still occurs... i'll try to reproduce it again and i'll post the log

- - - Updated - - -

here's the log: https://dl.dropboxusercontent.com/u/58212317/output_log%20%283%29.txt

these error messages kept showing when i target anything:

MissingFieldException: Field '.Part.uid' not found.
  at InternalProp.OnUpdate () [0x00000] in <filename unknown>:0 

  at InternalModel.OnUpdate () [0x00000] in <filename unknown>:0 

  at Part.InternalOnUpdate () [0x00000] in <filename unknown>:0 

  at Part.Update () [0x00000] in <filename unknown>:0

and here's a few pics showing that mechjeb was off and both vessels had power

[Frohike]

can I create and execute multiple node with the flight computer?

I'm looking for the same. Is there a way to add multiple successive Noes to the Flight Computer?

e.g. it would be especially useful for the second and third LKO Remote Satellite when you have to make two node burns, one from a low parking orbit to the proper altitude and the second node to circularize.

[Tellion]

Keystrokes going trough is unfortunately still a thing (on my install that is). Ubuntu 64bit.

Good luck with and big thanks for your efforts of getting it sorted out!

[Peppie23]

Keystrokes going trough is unfortunately still a thing (on my install that is). Ubuntu 64bit.

Good luck with and big thanks for your efforts of getting it sorted out!

yea unfortunately still present :/ https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/197#issuecomment-69450633

I removed this fix from our final release log. We need a bit more time for this issue.

I'm looking for the same. Is there a way to add multiple successive Noes to the Flight Computer?

e.g. it would be especially useful for the second and third LKO Remote Satellite when you have to make two node burns, one from a low parking orbit to the proper altitude and the second node to circularize.

It's on our feature list. https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/73

[JDP]

JDP can your MicroSat and AeroProbe be post(ed) ?

Sure they can. I've kept them fairly updated from time to time myself. You can grab them from my github repo if you like. I've just updated them to be 0.90 compatible and added MM support so that they will work both with RT installed and not.

Please note though that RT doesn't handle the animations very well, so for now you'll have to make due with antennae not physically extending while using RT.

Of course if any of you know what I'm missing (the animation handling of RT2 is, I must admit, fairly beyond me) feel free to do a pull request.

[Mecripp]

Sure they can. I've kept them fairly updated from time to time myself. You can grab them from my github repo if you like. I've just updated them to be 0.90 compatible and added MM support so that they will work both with RT installed and not.

Please note though that RT doesn't handle the animations very well, so for now you'll have to make due with antennae not physically extending while using RT.

Of course if any of you know what I'm missing (the animation handling of RT2 is, I must admit, fairly beyond me) feel free to do a pull request.

Thanks and, I changed the animations to the Firespitter plugin to get them to work like they did the only real problem was the miring of the 1 wing with the AeroProbe one has the blackside up but works .

EDIT- If anyone liked the RT1, MicroSat & AeroProbe got it 2 ways one uses ModuleAnimateGeneric but some of the parts don't work right best can remember https://dl.dropboxusercontent.com/u/72893034/RemoteTech1_Parts_.90.zip and this one all works but you need the Firespitter plugin https://dl.dropboxusercontent.com/u/72893034/RemoteTech1_2_Parts_FS_.90.zip have fun.

EDIT- Or you can grab it from JDP github repo

Edited January 11, 2015 by Mecripp2

[fangflight]

Does this work with 0.90?

[Errol]

Ok, so some thoughts from someone who is definitely not an expert on any of this, nor a person who allows himself to use pencil, paper or calculator whilst he games.

I'm wondering why there is such an emphasis on setting up a keosynchronous orbit for your relay sats. At least for a four sat net. I figured, meh, long as there's always one sat over mission control who cares if they keep trading places? I can see two places it can cause issues now, if they do drift relative to eachother it's a much bigger problem to deal with because now not only is there a large gap, but it passes over mission control over time. Also, if a sat goes down for any reason, then it's region becomes a dead zone, which also will pass over mission control eventually. Now I'm not bringing this point up in vain. I'm not usually one for success, being a man planning to build a tiny house on a trailer but what if some one were to simply spam LKO with sat relays for example? Perhaps a sim of future space traffic? Anyway, my point is, should there still be a penalty for not achieve the afore mentioned pedestalled keosync orbit? I mean, if it were feasible for some reason that you could have so many sats in orbit that it wouldn't matter what altitude they were at, and you were willing to launch 'em all cause you're an enterprising young kerbal, should there be a reason this network does not function as well as a keosync network?

My thoughts are yes. I feel like constantly having to re-route signals from one sat to the next should cause a significant increase in signal delay. It should be possible to mitigated through some sort of upgrade later on in the tech tree, and immediately in sandbox of course. Some sort of "komputer assisted automatic routing unit" or some jazz like that. Anyway, yea, my two cents...

[RainDreamer]

KEO is good for ensuring constant coverage over an area of Kerbin, for easier ground control of planes and other craft, and as the RT2 tutorial says, its longer orbital period means it will desync much later. However, it also admit that this is mostly for role playing and extra challenge due to dish can be pointed anywhere instantly, along with instant rerouting.

But there is also a reason now for aiming for KEO - contracts! Contracts may require you to put satellite around KEO, and pay you for it. It might pay enough that you will make a profit too.

[Ghost Works]

First off, love the mod in every way, it really makes ksp a whole new ball game. For that THANK YOU!

Secondly, I'm having some trouble with transmitting/receiving, im using the 400gm antenna to set up my satnav network, but the 3 satellites don't want to connect to each other... any ideas?

[bdito]

First off, love the mod in every way, it really makes ksp a whole new ball game. For that THANK YOU!

Secondly, I'm having some trouble with transmitting/receiving, im using the 400gm antenna to set up my satnav network, but the 3 satellites don't want to connect to each other... any ideas?

How are you connecting them? ARe you pointing them at a planet, specific satellites or the active vessel? The cone on those are quite tiny so pointing them at planets can be troublesome. I only use them when going beyond Duna.

[WuphonsReach]

A KEO satellite (3-4 DTS-M1) should only cost about 25-30k launch. Typical keosynchronous contract should pay out 50-60k, so it's easy to get paid to put up your KEOs. The first two KEOs link to:

- KSC

- Active Vessel

- Mun ("cone" connection to another SoI)

- Minimus ("cone" connection to another SoI)

Once you get into the 40/60/400Gm dishes - you need to go point-to-point between satellites and not "cone" mode connections to the other planet's SOI. I generally put up (2) KEOs with (3) 60Gm dishes (for Dres + "active vessel") and (6 or 8) 40Gm dishes (for Moho/Eve/Duna). Those link bi-directional to smaller satellites that provide local DTS-M1 coverage of their orbital bodies.

[Ghost Works]

im putting their targets as the ksc, should they be targeting something else? As of right now im just setting up my network, so these first three are going to be the ones that will transit mit any future probe mission, in and out of, the kerbins soi

Edited January 12, 2015 by Ghost Works

[bdito]

How far out are they? Do they also have Omni antennas?

If they're pointing at the KSC they won't be able to connect to it when it's on the other side of the planet.

Basically you should have sats orbiting Kerbin with a few antennas each. They should have omni's that connect to each other and the KSC (you can't direct them, they'll connect to multiple other omni's and do it automatically if they're within range. I'd suggest the Communitron 32 because it's range is the largest onmi antenna), and long-range antenna's which point outward planets or vessels.

Edited January 12, 2015 by bdito