thecoshman

I see what you are saying, but when you are talking about the distances the planets are at, targeting a ship, or the body it is orbiting/on is not really any different. Let's say you have a relay network around Duna, say for satellites all with a dish down to the surface, one to the AV and one back to kerbin. Around kerbin you have ring, each with a dish pointing to kerbin, and a dish pointing at AV. When controlling a rover on Duna, those satellites around kerbin will target it, as it is the AV, this means they will be pointing towards Duna, and thus will be able to establish a connection with the ring of satellites around Duna, which can relay back down to your rover.

Personally, I think the correct thing for RT2 itself to do is cut all engines if the vehicle loses connection. What would be really nice is tight integration with kOS. KOS is a mode that let's your write small scripts, such as 'launch to orbit' scripts, that will be executed on your probe (or manned vessel). It would be nice if there was some way of letting kOS scripts run even if the vessel has no comms connection. Of course the script would have to be started before connection is lost. This does still have the slight issue of what happens if there is a bug in your script that stops it from ever ending, and it keeps the throttle held high and thus unable to change from the vessel... for the sake of game play, might need a way to kill a script... but this is a kOS issue really...

Is this mod compatible .23? According to the mod index it is for .21? If it is just a case of needing tech tree integration, that's fine, but do these parts work fine with .23?

So, is the recommended way of getting this mod via the Wolf Pack?

Well, the way I figure it, if you turn off all the dishes on your satellite, you actively chose to do that whilst directly controlling it. If that means you have now closed the final communication channel, so be it. The last thing the satellite was told was that it should no longer communicate. However, it is very easy for you to render a satellite inoperable by doing something to some other satellite, or just passing through a black spot for those few satellites it is set to communicate with. In which case, for me at least, I would like to still be able to tell this now connectionless satellite where to point to to try to get that connection back, and I would rationalise it as saying it is a tiny boot strap program on the satellite but it is easier for the mod to simulate it via having me tell it where to connect to. Now I realise there are some who feel even that is too 'cheaty'. The way I see, there are a few options for how to handle satellites that have no active connection. Tough luck, maybe you should have left that small omni-directional antenna activated Allow 'dead' satellites to have targets set for ACTIVE dishes - this simulates a program running that sweeps for a connection Allow 'dead' satellites to have targets set for ACTIVE dishes - but also impose a distance based delay until the connection actually works again representing the time it takes for the signal to be found Allow 'dead' satellites to have targets set for ANY dish - this simulates a program running that sweeps for a connection Allow 'dead' satellites to have targets set for ANY dish - but also impose a distance based delay until the connection actually works again representing the time it takes for the signal to be found Have a 'dead' satellite automatically sweep for a connection with ACTIVE dishes Have a 'dead' satellite automatically sweep for a connection with ALL dishes Allow dishes to be controlled via EVA, in which case both target can be set and dishes activated Now, I like to think we can start to discuss these possibilities, so if you do want to refer to the options I have presented here, please link back to this post (rather than quoting) so people can see some context. Personally, I think option 8 (allowing EVAs) should be added any way (It might even be, I'm not sure). I can see the appeal of options 1 for most players, it is the most stringent way of dealing with the situation. Options 4, 5 and 7 all allows dishes to be activated, which I think is a bit too much, especially when you consider the last thing you told that satellite was to stop listening for commands. I think 6 is nice ideas from a players point of view, but implementation wise would be too much. So yes, option 2 or 3 is where my money is at, I think that the delay imposed by option 3 would be a PITA to have to deal with, but it would be a fair punishment for not planning things out properly.

Yes, I agree that you should not be able to activate dishes unless you have control over a probe. I only think you should be able to set the target manually. If you want to have something account for the time the probe would take, perhaps once you set a target, it takes time to actually establish that connection, based on the distance of the connection. This can roughly account for the fact that as you get further away, the area the target would be in becomes smaller and smaller, so you sort of account for it having to sweep for the connection.

Thanks man, that fixed it! Seems you need a default 'Texture.*' for the parts vOv Well, the models are just fine, but the default textures are terible yes (sorry TaranisElsu) I suggest you also get the textures that jfjohny5 has made:

Simple really, let us manually choose a target for a dish even if it is not under control. This allows us the player to act as the automatic program that cycles through all possible connections to find a path home. Best of all, this functionality already exists in the mod.

hmm... for some reason jfjojny5 the convertors are not loading there textures... just stark white staring back at me.

really? I've always been able to do this too. Personally, I like it. It makes sense to me for probes to keep switching targets until they get a signal. Please ~~add it back~~ keep it in as a proper feature

jfjohny5! Those are beautiful!

Hmm... this seems to be giving me chronically low FPS when in the VAB... I don't get any of the mod icons showing up either, and it asks me where to place the bar each time I enter VAB.

hmm... it could be six... To be honest, never made use of that feature

nice! Any comment regarding the multi-colour 'life support' containers?

They are done members of the community. Look back through the posts, you should find a link to them. Personally as nice as those models are, I like to think Kerbals would put some covers on things.

Assuming this latest version (the .23 preview version) hasn't changed anything, you need a ship with three Kerbals in to be able to control probes. Other wise, you will need a full chain of links all the way back to KSC. Either way, I am sure you can not transmit data part way back to Kerbin, you either report to KSC or carry it home. Personally, I prefer it this way. KSP is a game first and for most. Fun will should always come first over 100% realism. I think it is good that you do not start the tech tree with a the ability to control probes directly, well you do, but you would have to have three of the one man pods.

Got to say, this slight detail is a bit of a turn off for me. It makes the texture a bit too busy for my liking. May I suggest you go for either a very bright white, or something like brown, or maybe purple? I also feel this might need some more details... regex's had some nice 'connection points' maybe something like that could be added back in? Also, one thing I did with my HexCan textures was have the symbols on three sides (alternating) just makes it a bit easier to have the symbols aligned so that they are facing out and easy to see.

Hibernation module is rather self explanatory, let a kerbal survive of nothing but electricity (to power the module) whilst he is in hibernation. Maybe impose some sort of time delay or limit on the time a guy can be in hibernation perhaps. What exactly do you propose a greenhouse module would do? There is already a CO2->O2 convertor... would it basically be one of those, but slower and not requiring electricity? It would surely have to also require water, no? I guess maybe it could use some of the waste to sustain itself too, might need to fudge over exactly how that works though.

Yeah I spent most of today working on mine too, but I am very bad with GIMP. One thing I did just notice, VAB was rather laggy, are those textures the same size as they normally are? It could be anything else though.

Well when you're beat, you're beat. Got to admit, you hands down did a better job than me all round. It's nice to see that we had the same idea though, but you really did pull it off so much nicer than me.

Think I'll throw my attempt at HexCan textures. These are based off regex's inline cans. They are rather clean looking. I may edit them to make the color more apparent, and maybe add a bit of 'noise' to make them look a bit more lived in. Welp, here they are. Tell me what you think. In terms of licence, creative commons I guess. Do as you wish! Please give me a mention if you use them in some other work, but you are under no obligation. If you have any suggestions for improvements, let me know and I will see what I can do. In terms of installing, replace the existing 'Texture.*' with these. EDIT well, balls to that. Please do not use these textures, jfjohny5 has me beat. If you ask me for any improvement to mine, I will just point you to his.

lol, nope I didn't want to install it if it didn't have support for this. Will give it a go then. Thanks.

I know people are after .23 compatability more than features, but is it possible to have the auto categorization work based on mod pack? I noticed you had something like that in a image on your leading post. Is it also possible to allow mods to have data in their part cfg files that your mod can pick up on? This would allow for something like the Kethan pack to mark all his parts as 'Kethane', maybe mark the scanners as 'Scanners' too.

I think I will just pip in a confirm that as far as I can tell, TACLS is working 99% perfectly in .23. The only problem so far is the cosmetic issue with the parts in VAB/SPH. The life support containers (the air/water/food mixtures) have a graphical bug. When you hover over the items, they start to zoom in until the clip through the screen. Changing pages wil reset the items back to their normal view. It is only whilst you hover over the item that they zoom in, so if you hover for a short period you can have the screen filled with a very big version of the part. You can still select the item just fine to use it though, so this really is just a cosmetic issue.

Yeah, does indeed look like Remote Tech is not happy about .23 I don't think is module manager it self... unless remote tech is using something special in there, as FAR uses the same module manager just fine. At least for now, I can do stuff with live kerbals and when an update lets me, I can start using remote tech again.