[DISCUSSION] RemoteTech 2 Lite development

[Nostromo]

Played around a bit with it, I'm liking the UI icons. I'll get more thorough later tomorrow. I think a few of the previous antennas are missing though. Don't quite remember.

[Fail-o-matic]

Played around a bit with it, I'm liking the UI icons. I'll get more thorough later tomorrow. I think a few of the previous antennas are missing though. Don't quite remember.

The white 50GM is MIA as is the smaller half dish- the 2 that would auto-track. Played around with it a bit and liked the integration into the pods so no more forgetting parts. Could not contact a satellite orbiting Duna using the big dish on both(Duna and Kerbin sat's) Whats with the different colored lines? Just started using the previous version and this came out. Looking forward to more!

[Cilph]

The white 50GM is MIA as is the smaller half dish- the 2 that would auto-track. Played around with it a bit and liked the integration into the pods so no more forgetting parts. Could not contact a satellite orbiting Duna using the big dish on both(Duna and Kerbin sat's) Whats with the different colored lines? Just started using the previous version and this came out. Looking forward to more!

White 50GM should not be missing. It's in there. Two dishes activated and contacting each other from Duna should work. Yellow line for dish connections. Gray for omni. Lime for active.

EDIT: Oh, you meant the tracking ones. You do know the other RT2 was never officially released and abandoned?

Edited November 2, 2013 by Cilph

[Fail-o-matic]

White 50GM should not be missing. It's in there. Two dishes activated and contacting each other from Duna should work. Yellow line for dish connections. Gray for omni. Lime for active.

EDIT: Oh, you meant the tracking ones. You do know the other RT2 was never officially released and abandoned?

No, did not know that. I just thought the tracking ones were more 'real' since we cant keep craft pointed where they are supposed to be(and look cool too)

As far as targeting goes, if in the same SOI, you target the satellite, if going planet to planet, you target the planet, right?

[Cilph]

No, did not know that. I just thought the tracking ones were more 'real' since we cant keep craft pointed where they are supposed to be(and look cool too)

As far as targeting goes, if in the same SOI, you target the satellite, if going planet to planet, you target the planet, right?

The planet thingy uses a cone of vision. If it's not in the cone, or occluded by a planet. No connection. Direct targeting might work better.

[Cilph]

http://forum.kerbalspaceprogram.com/threads/56399-0-22-Remote-Tech-2-Build-those-satellite-networks%21

[Deejay2000]

I can't tell you how long I've been waiting for this moment... Well, I actually can tell you...

[Ralathon]

It seems to work quite well, although I have encountered a few bugs so far:

The Comms DTS-M1 dish maintains connection regardless of orientation:

This is the only craft I have and as you can see I can upload science just fine. I'm uncertain if other dishes share this bug but once I unlock them I'll test it out (playing career mode here).

Loss of control. I'm uncertain what causes this bug, but several times my manned ships became unresponsive. Switching vessels seems to fix it however. I understand this is not very helpful, but maybe someone does know what's causing it.

Inability to que science transmissions. It seems that if you try to rapidly send a whole bunch of science reports it will not que them and only sends the first. So you need to take it slow when sending science.

Other than that, great to see this back into action! I always loved playing with Remotetech and this makes career mode much more challenging.

[Cilph]

Hah. They do not take physical orientation into account when sending.

[Rotary]

Bloody awesome!! This mod adds so much more to KSP, please include the the delay as soon as possible, it really creates the need for remote manned stations to land probes

[Cilph]

Bloody awesome!! This mod adds so much more to KSP, please include the the delay as soon as possible, it really creates the need for remote manned stations to land probes

Automation! The goal was to create a need for automation!

[Rotary]

Automation! The goal was to create a need for automation!

For automation you need a Flight Computer.. And I wouldn't call having to set up a satellite-network before being reasonably able to get a bot to enter the mun's orbit 'automation', but hell, I'm probably missing the point!

[Cilph]

For automation you need a Flight Computer.. And I wouldn't call having to set up a satellite-network before being reasonably able to get a bot to enter the mun's orbit 'automation', but hell, I'm probably missing the point!

Signal Delay at the mun is like a millisecond. Nothing to worry about. I signed up for the project to make automated scriptable Duna skycranes possible =D.

[Dexter9313]

I will try everything with kOS tonight as no-one seems to have tested it. Great work on your coding speed though ! Concerning future features, are you planning to add them core or optional ? (Like signal delays, hypothetical flight computer, etc...)

[Cilph]

I will try everything with kOS tonight as no-one seems to have tested it. Great work on your coding speed though ! Concerning future features, are you planning to add them core or optional ? (Like signal delays, hypothetical flight computer, etc...)

The intended goal for kOS would be to have it work while there's no connection. Currently all autopilots will lose input when there is no connection.

[Cilph]

Here's a nice Quality of Life improvement: assigning a GUID for the current active vessel and adding it to the target lists. Allows unloaded satellites to always point a dish at whatever your current vessel is.

[Dexter9313]

Concerning kOS, I tested it last night, and there are pretty much the same problems as before... I think the way you block controls will always lead to problems. (For example, in the kOS editor, when I press the 't' key on my keyboard, it is sent to kOS so it displays 't' as intended but it toggles SAS as well !) I remapped every ship-control keys somewhere else but still I think it doesn't solve the problem and my key-mapping isn't really convenient now.

I think the only way to get out of this is to have an option like "Block commands on connection loss". If it is unchecked, you don't touch the key events at all so that everything would work as before. Then kOS could do something like blocking controls on unmanned ships or whatever. But anyway, please leave a choice, it's just a matter of if()else{} here. ^^

Another way I thought of would be to play with the "no-battery" state in-game that blocks everything in a clean way.

[NathanKell]

Yeah, you can put input control locks on instead of intercepting keys. The problem is you still need to intercept keys for signal delay.

[Cilph]

What are the requirements for external mod support, eg stuff like Chatterer, before I go work on that? Ill add a part event that will hand back an info dump and possibly takes requests for setting and getting other data.

Aside form the obvious list of connections, total delay, etc, what do people want?

[Dexter9313]

I am not really sure as I don't develop mods, but I think there are two easy things to do which will make everything work, but are maybe not very beautiful.

1-Do what you said : provide information to any other mod requesting for that. These mods will then be able to implement some things by themselves (like controls blocking).

For details, I think anything could possibly be useful like : is there a line of sight connection ? What is its length ? Should controls be blocked right now ? etc...

2-Make every feature optional. If a mod needs a feature shut, it will be easy to do so.

kOS for example would need command blocking shut so that key events are not duplicated anymore, and it could use your data to block the controls itself ("if RemoteTechFound() && remoteTech.shouldControlsBeBlocked() then block()" in kOS code) ! Obviously I provided pseudo-code here, members shouldn't be named that long.

For you it's just a matter of conditions (if we can block controls, then handle controls; else don't touch them !), it would require a bit of configuration for users (knowing they have to shut things down) but it would be documented and at least it will work. If someone finds a more elegant solution it could be better but I think mine is not that bad. What do you think ?

The very best would be to talk directly to the kOS major developer, he could tell you what he needs exactly.

Edited November 4, 2013 by Dexter9313

[Donziboy2]

So does the RemoteTech2 on github work or am I just spinning my wheels in vain?

[razark]

I'd suggest checking the release thread:

http://forum.kerbalspaceprogram.com/threads/56399-0-22-Remote-Tech-2-v1-1-0-November-7-Build-those-satellite-networks!

[Cilph]

So does the RemoteTech2 on github work or am I just spinning my wheels in vain?

There's an official release thread and zip on spaceport. Weee.

[Donziboy2]

OK, well when I did a Google search I found an older thread, then this thread and was like now what....

[Atheu]

there is an incompatibility with KAS, messes up staging and messes up the HUD.