JDP

I'm afraid I don't have a complete understanding, but somethings I do know. objects in mapView are positioned in ScaledSpace and there are in fact different cameras used. For the flight GUI, there's also a third camera as far as I've been able to discern. The three cameras you're looking for are: FlightCamera.fetch.mainCamera; ScaledCamera.Instance.camera; ScreenSafeUI.referenceCam; Whether ScaledSpace is actually a whole other scene, I don't know. Others might be of more use to you there. Maybe you'll be able to gleam the rest of your answers from the source of the hullcam mod.

Read the OP. A remote command module allows a vessel to function as a command station (providing it has enough crew). This allows you to set up remote command stations to minimize signal delay. Just try flying a mission to Eeloo with a signal path going all the way back to Kerbin and you'll get an idea of how difficult it can be to maneuver under heavy signal delays. The flight computer goes a long way to make things easier, but stuff like landing is almost impossible unless you have near instant controls (or are landing on a planet where you can use parachutes).

When in map view, you can change the name of the vessel from the menu in the bottom-right.

I assume you're using ModuleLight. Are you remembering to name your light transform in the cfg

Small dev update: work progresses on the TDRS style folding dish. I'm having to learn armature animation pretty much as I go. so work progresses in test iterations, where I pretty much start from scratch each cycle. Here's the current dish (iteration 4), implemented and roughly animated in Unity: I'm still not completely satisfied, so I suspect I'll be going on to iteration 5, and maybe even 6 after that. There are some mesh errors I'll need to adress, and I'll probably redo the entire rig with vertex weighting favoring the bones that fold inwards to get rid of the stretchy effect.

in RT1 you can access the module settings by pressing <modifier key> + f11 in-flight. From there you can reset window positions.

I prefer to do all animations within Unity, utilizing transform hierarchy to attain complex and precise animations using simple position and rotation animations. The level of hierarchy control you have within unity also allows me to make sure animations don't conflict with programmatic transform modifications like tracking dishes or the advanced thrust vectoring fins on the AeroProbe. In the case above, I simply threw together a quick animation in blender to show the rig in action. I'm right now testing how rigs work within Unity, but don't expect any dev videos of it until I've made a proper part to animate. As I said above, it's going to take quite some work to get the rig working correctly. For it to look right, I'll need some very precise vertex weighting. And of course I'll need to model the part first. That can take a bit of time too, since I do most of my modeling in Rhinoceros (a NURBS modeling program especially well suited for making mechanical models). Here's the steps I go through whenever I make a part: Model part in Rhino. Convert model from NURBS to mesh within Rhino and export to .obj [*]Import into blender. Refine and tweak mesh. Generate UV maps. Apply edge split and export to .fbx or directly through .blend [*]Import into Unity recalculate normals. Setup transform hierarchy. Make animation(s). make texture(s) and setup material(s). [*]Export to .mu and test in-game. [*]??? [*]Profit.

An inflatable dish would probably need to be done with a scale animation. The problem with scale animations is that they tend to fall into the uncanny valley and look just wrong. Take the inflatable habitats on the old HOME module for example. To me their inflate animations look terrible. And if Bobcat couldn't make scale animations work, I certainly wont be able to. On another note. I did a small test on a "taco" style dish: Of course this is just a quick mockup using a very low-poly dish model. For a full-sized dish, it's going to be hell to properly group and weight each vertex. Which I'll have to do by hand. Just this low-poly model had 64 vertices that needed proper weighting. But it is doable, and possibly even with using only 8 bones per dish (16 might be needed for a more detailed folding animation). Another great thing I've found out is that Its now possible to animate the rig directly in Unity. That's going to make it much much easier to set up the part with a proper hierarchy. With this realization, I might be scrapping the clamshell design and going for a single or twin taco design (am I the only one getting hungry for seafood and/or mexican food from all this talk?).

I've seen the "taco" folding mechanism around before and agree on the immense coolness of it. I've just always stayed clear of trying to implement it, since it would require an armature animation. Maybe I'll do a bit of experimentations and see if I can get it to look proper within Unity without needing too many bones per vertex and cumbersome collider workarounds. That's always been an issue for me when working with armature animations and Unity.

not a chance . this one will blow apart in a million pieces if you even try to deorbit it (or opening it while traveling at speed within an atmosphere).

A quick dev update: I've been thinking a bit about removing the old MI class dish from RT1. Currently it's the last remnant of the old RT1 parts in RT2. With the change in design of both the UI and parts bundled with RemoteTech, the old dish kind of looks out-of-place. There's also the issue of the massive amounts of armatures and materials used in the making of it, that makes it a somewhat CPU and GPU intensive part. Not wanting to scrap it in favor of a plain ol' boring static dish, I set forth on creating something new in stead. When making giant dishes, there's always a challenge in how to pack the damn thing during launch. It's very hard to do without rigging up the model with massive amounts of armatures, or doing a scale animation that almost always looks cheap and breaks immersion. For this dish, I've experimented with a clamshell mechanic in lieu of going overboard with complex armatures yet again. The novel thing to this dish is the fairing that protects it during ascent. The fairing is an actual component of the dish model itself, much like the fairings found on stock engines. You can have an early look of both the new dish, and the fairing functionality in this little dev video:

Indeed there is. In RT2 you can input a custom delay by typing it in the lover-right corner field of the queue window of the flight computer. Regarding getting into orbit, you're going to have to use the flight computer pretty extensively. Here's a guide I made, showcasing the CAPFLYER method of attaining orbit. It's made in RT1, but the method would stay the same in RT2, just note that maneuver node integration is yet to be added in RT2:

Just be aware that most of the old RT1 parts are gone in RT2. So if you want to one day update to RT2, you will loose most of your vessels using RT1 parts, unless you manually re-add them with the correct RT2 modules in their config files. Or you use the current RT2 parts and modify their config files to use the old RT1 plugin. Another thing. When RT2 finally goes live, I'd love to see it used in lets plays. It might get the word out about RemoteTech and serve as inspiration and explanation to players. So I'd love to feature a couple of lp's on the front page of this thread

Since stock KSP has an abundance of great looking probe bodies, they are all SPUs now, ModuleManager makes sure of that. Only one of the bodies have Remote Command functionality; the stock large stacking body. You can always see what type an SPU is by looking at the part information in the VAB/SPH. And by the way. The crew requirement is currently 6 kerbals, not 3. This might be tweaked further in the future. But don't expect it to be lowered. It's become far to easy to cram a single ship full of kerbals, and with the advantages they provide, I'd want it to be a real challenge to set up command stations.

Massive update to the rover computer. In need of testing. I've just uploaded what I've been working on the last couple of days. The rover computer is now back and better than ever. Here's the commit message: -Added keep heading mode. -Added drive to target mode. After punching in your desired numbers, simply press return to send the command. In case of target mode, you can input coordinates by holding <modifier key> and left clicking where you want the rover to drive to. This works both in flight and in map view. If you want to immediately send the drive command, hold <modifier key> and click the right mouse button where you want to drive. I've had a lot of fun commanding my little wheeled minions around KSC. Now comes the testing process. Feel free to grab the latest test release from the github page and take it for a spin. Note that there are still some backend bugs with the relay network which Cilph is currently hacking away at. As always. Remember that this is still a test build, and I would only recommend you install it to help in the development of RT2. Regarding tutorials and guides: Until we are fairly certain that the plugin is finalized, we aren't likely to spend too much time on writing up howto's. In the mean time, feel free to lean on each other, and of course Cilph and myself. Just don't expect us to have too much time to correspond with you right now . When RT2 is released, I plan on making a small series of howto videos. I'd like RT2 to be a bit more documented than RT1, and I get the feeling that videos would be the way to go to best show the plugin in action.

I'm still brewing on the idea of rkman mode. Up until now I've never been able to add it, since it makes the game positively unplayable from a UI standpoint. With the addition of more detailed relay rendering, where all possible connections can be shown, and coloured to reflect signal strength, it might be possible to enable the mode without it being impossible to keep track of effective ranges in-game. It's probably not going to happen in the initial release though. Our focus right now is getting the default mode working and adding GUI and flightcomputer features. Cilph is hard at work at an aerial flight computer, to better control AeroProbes and I'm currently in charge of the rover computer. In the currently available build it's got the same features as the old RT1 rover computer, but I'm working at adding 2 more modes: "keep heading" and "drive to location". I've got the frontend mostly done, complete with a point-and-click interface for selecting target coordinates simply by clicking on the intended target in either flight- or mapview. It's going to be pretty neat . land-based relays are very time consuming to do. It has been done though, but due to the curvature of Kerbing, you'll have to set up relay stations every few km. I'm not likely to ever add any hardcoded relay stations, since I'd want the entire relay network to be an achievement.

This has been possible for quite some time in RemoteTech 1 (you can open the flight computer of multiple vessels at once) and is supported by the backend of RemoteTech 2. We just have yet to implement an interface for it. For now, you can actually get multiple flight computers open at once by simply not closing them when switching vessel focus. Each flight computer will control the vessel from which you opened it. How are they broken? Apart from some bugs having to do with the network itself they work just fine on my end.

For now you can use a crewed vehicle and get rid of the signal delay via local control.

You're talking about the ESC-EXP antenna. Which is already in there. If you want a litthe longer range on your deployed antennae, I'd want it to be a bit more difficult to launch them. There are not really any tutorials on RT2 yet, as new as it is. You can find some info on RT1 though floating about the wiki. I've also made a small intro video a while back. You should be able to find it either in this thread or on the youtubes. I plan to make a complete suite of tutorial videos on RT2 after release.

The only thing ModuleManager does is, in a sence, patch the PartLoader to work as mu intended: complete with the ability to modify other config files. Nothing is downloaded and nothing is written to harddisk. nope. no debug menu. we recommend you only install the playtest version of RT2 if you want to test it, and not in your main worlds. When playing your main world, simply delete or move the RemoteTech2 folder from GameData. And thanks for testing by the way *GlaDos voice*

check the bugtracker (and the last couple of pages of other people asking the same thing ). It's just in there for testing purposes. It'll be removed soon.

Now that the old probe compatibility pack will be merged with the main addon, ModuleManager certainly is needed. It also allows for a much cleaner config setup that will make it easier for you to tweak and change RemoteTech variables at will, without having to dig through subfolders and multiple config files with a lot of irrelevant variables. Hopefully the devs will one day fix the PartLoader to work as intended (complete with all the functionality currently added by ModuleManager). By that time, we won't need to bundle ModuleManager with RemoteTech.

If you're gonna use the playtest version for more than playtesting, you're gonna have a bad time All RemoteTech specific modules are handled by ModuleManager now, even the parts that come bundled with RemoteTech. This means that ModuleManager is needed for RemoteTech to work. If you want the stock parts to remain completely stock, all you have to do is delete RemoteTech_Squad.cfg and ModuleManager wont change any of the stock parts. that description was only meant for another file that was uploaded at the same time. it doesn't apply to ModuleManager.dll.

or you could simply toggle the actionGroup for the entire vessel. There's no need to iterate through all parts and all PartModules: //toggle the break group of all parts & PartModules on the vessel vessel.ActionGroups.ToggleGroup(KSPActionGroup.Brakes); //set the break group of all parts & PartModules on the vessel bool brakes = false; vessel.ActionGroups.SetGroup(KSPActionGroup.Brakes, brakes);

Yep. It's just for testing the signal delay mechanic and will be removed before RT2 is released.