Starstrider42

Only if you also have a probe core on board.

Ok, bug confirmed when I download https://dl.dropboxusercontent.com/u/80983870/RemoteTech_Settings.cfg. Very curious. EDIT: Unfortunately, the problem is a side effect of the map view icon upgrade. I'll see if I can put a fix in the code. For now, though, there's an easy workaround: open the RemoteTech_Settings.cfg file in a text editor, and find the line near the beginning that begins with "MapFilter". Replace "Planet" with "Cone" and you should be good.

Which are "the" RSS configs? I don't see them on the FASA page. I just load the .sln file in the Xamarin GUI. The build script is intended for use by the Travis build pipeline. ... okay, I think I see your point about RemoteTech-specific stuff. The DLLs can be found in your KSP_Data/Manged directory, yes. Assembly-CSharp.dll and UnityEngine.dll should be the only ones you need.

Good catch. A fix will be up soon.

Custom Asteroids 1.1.0 is compatible with KSP 0.25.

And version 1.1.0 is now 100% KSP 0.25 compatible. Probably. Only new feature in this version is that feedback from bad asteroid configs can appear in-game instead of just in the logs (yes, this can be turned off if you find it too annoying). This should make things easier for players writing their own asteroid packs.

Hmm... well, I'm sorry to say that I can't reproduce the error with a KSP 0.25 + fresh RemoteTech 1.5.0 + fresh FASA 4.98 install. The FASAApollo_SM_Dish loads fine for me, and I don't have any trouble creating a ship and experimenting with the antennas on the pad.

Gah. Of course the one feature we didn't test carefully would have a horrible bug. Fortunately, I think I know what the problem might be. I'll keep you posted.

I don't think we have any requirements that are specific to RemoteTech. Have you tried looking at e.g. http://wiki.kerbalspaceprogram.com/wiki/Plugins? I use Xamarin myself and haven't run into any problems. It will be created in the RemoteTech folder after you've started KSP once. Generic instructions for ground stations can be found at http://remotetechnologiesgroup.github.io/RemoteTech/modders/ground/; if you need RSS-specific information (like what coordinates to use) you're better off asking on the RSS thread.

Quick update: Custom Asteroids for 0.25 seems to be working fine, but I want to run a few more tests (I've jumped two KSP versions, after all). If all goes well it will be out tomorrow.

No. Module names are all the same. The only name changes are renaming the folder to RemoteTech, renaming the plugin to RemoteTech.dll, and removing the Textures folder (texture assets are now stored in the DLL).

I'm pleased to announce that RemoteTech 1.5.0 is compatible with KSP 0.25.

Hi all, We've just released version 1.5.0 of RemoteTech, in all its 0.25-compatible glory. Pick it up on KerbalStuff or GitHub. One VERY IMPORTANT change: in this version we're changing the folder name to RemoteTech, and changing the internal organization of the folder as well. You must delete your RemoteTech2 folder before installing this mod. Seriously. We, the members of the Remote Technologies Group, will be Not Amusedâ„¢ if we get a bug report that turns out to be because you had two RemoteTech installs at once. As usual, we didn't manage to push through all the fixes (or even most of the fixes) that I was hoping for in this release. However, Peppie23 and I have both been hard at work making improvements, so expect RT 1.5.1 to be much more user-friendly -- and to be coming much sooner than a month from now.

KSPTOT Connect 1.1.7 is reported to work with KSP 0.25 (http://forum.kerbalspaceprogram.com/threads/36476?p=1459075#post1459075).

This post (http://forum.kerbalspaceprogram.com/threads/83305?p=1447900#post1447900) sounds like it might be the same problem you're having. Basically, there's a bug where having both an active vessel connection and a planet-based connection to the same target seems to cancel out??? I'm working on making cones more consistent at the moment; I'll see if this bug still exists when I'm done.

Sorry about the controversy. To follow up on that, we agreed to rename the folders, DLL and everything to RemoteTech. That should be the most robust solution in the long term. (But I'm warning everybody right now: please remove your RemoteTech2 folder before installing the next update, which will be released Soon, or the recent dev builds.) For your new question, as far as I know the TRANSMITTER node is equivalent to the normal ModuleDataTransmitter, except for checking if there's a connection. Cilph told me at one point that the all-identical values were placeholders and that they weren't chosen for any particular reason, so you should be fine changing them. That said, I did try custom values in my previous (0.23-0.23.5) career save. While they had the intended effect, I had a hard time getting something that was both plausible and balanced. I wish you better luck.

Ok then, reporting things a little more properly (but from memory, so please excuse the vague bits): I'm using standard DRE shields, no RO shields or personal tweaks. I have stock-sized Kerbin. The only DRE setting I've changed is gToleranceMult. I am playing with FAR, default settings there too. Re-entry from circular 100 km orbit (this was in a Kerbal Construction Time simulation, so it was in fact exactly 100 km and perfectly circular). Tried varying periapsis between 0 and 30 km; you can work out the velocity from that. Ship is a Mk I command pod, with ablative tweaked to zero, stacked on top of a Science Jr. module, which is on top of a 1.25m heat shield (full ablative of course ). The craft is aerodynamically stable at the altitudes and speeds of interest, and can point retrograde throughout the hot phase. For either flight path, as soon as I enter Kerbin's atmosphere (i.e., at 67-68 km) the heat shield temperature jumps from -50 C or so to 300 C within a few seconds. This is the part that makes me go "that can't possibly be right"; everything later in this post is just extra calibration. For either flight path, the heat shield temperature levels out at about 640 C, though at the cost of ever faster ablation as I descend. Radially mounted equipment on the science module tends to burn up, radially mounted equipment on the Mk I pod gets through unscathed. For a 30 km periapsis, I run out of ablative at ~40 km altitude (ablating at a little over 3 units/s) and a surface speed of about 2000(?) m/s. Heat shield temperature post-ablative peaks at around 1300 C, hot enough to trigger the overheat warning on the staging panel (great new feature, by the way) but not hot enough to actually endanger the craft. For a 0 km periapsis, I run out at 35 km(?) and 18-1900 m/s. Heat shield temperature peaks at around 1200 C; the overheat warning only shows up for a second. I can try to get more precise numbers this evening, if needed.

No, those are accumulated points of G stress (set by crewGPower and crewGMin?). Anybody can survive 10 G's if it only lasts a second.

Are there any known mod windows where the keypresses don't pass through? We might see how they avoided the bug and copy it for RemoteTech.

I've asked for something similar for Atmospheric Trajectories. The kind of prediction you're asking for is more in the scope of that mod than of DRE.

Yeah, the main benefit I see at the moment would be different composition classes, allowing either separate science or integration with e.g. resource mining mods. For your other two questions, 1. I really wanted this (forget KBOs, most of the near-Kerbin asteroids are smaller than anything we can reliably detect with current technology) but it appears to be hardcoded into KSP at the moment. It *might* still be possible to override the KSP-selected size, but no promises. 2. I would like comet tails, but I have no idea how easy or hard it would be, so that's very definitely an "eventually" goal. Thanks for the AK reference, I'll see if they've done it.

Ah. Now there's a detail that I'd missed. So it basically happens on any stock + RT game on Linux? Log confirms that my original hunch was incorrect. Though there's something going on with your ModuleManager install: I've seen that in a few other peoples' logs, have no idea what it is. Maybe ask on the MM thread. Edit: I think I know enough to write a issue on it. It's now posted here.

Yes, it works with days and hours. Days are currently hardcoded Earth days; I've put up an issue for it and it should be easy to fix.

Holy crap. I think I'll have to ask you to do some testing on your end. I can't vouch for ART, Cool Rockets, Docking Port Alignment, EditorExtensions (sounds invasive; could that be messing with the GUI behavior?), Enhanced NavBall, Exp Pack, FTT, Interstellar, KJR, KPlus, KSAEA, KW Rocketry, PreciseNode, Rebalance, Texture Compressor, Transfer Window Planner, or Universal Storage. You might try seeing if the bug disappears if you delete some of those mods; it's usually easiest if you make a copy of your entire KSP folder, then do any experiments on the copy. An easier alternative that just occurred to me: if you post (on Gist, pastebin, Dropbox etc.) your KSP_Data/output_log.txt file, I can try to see if there's a graphics error happening somewhere else. KSP tends to react very badly if an error occurs inside a mod's drawing code, so it could be that another mod's getting something wrong in a menu or window or something and that's messing with things when RemoteTech tries to draw its windows. One question: what are the round numbers in front of each mod?

Not dead. I'm waiting for the 0.25 release before I put out an update. I have not been able to confirm any new issues specific to 0.24; the people who said they had infinite spawning in 64-bit have not gotten back to me. As far as new features goes, I've been experimenting the last few days with adding individual asteroid data (which offers a lot of possibilities for asteroid mining, science, etc.), but so far those experiments have been pretty fruitless. KSP *really* doesn't like modders mucking around with vessels that haven't been loaded in physics range yet.