krenshala

Not sure if it was the case 5 years ago or not, but now its 1. Select the vessel 2. Bring up teh vessel info panel 3. Double click the name on that info panel Then you can change the name and the type, even if its (effectively) abandoned hardware from a rescue mission you've already completed.

Just fired up 1.10 with the prerelease4 and latest OPM version, and at least in the tracking station i'm also seeing the 90 shadow being off on the gas giants (but not the rings around them), except for Jool (which has the shadow facing correctly). BTW, thank you all for reviving the one mod required to load the two mods (Kop + OPM) I was missing. edit - hemeac's comment makes me wonder about Eeloo ...

Now i'm curious what Isp and thrust they have. Things look really nice so far.

Just as an FYI for other folks, I added the config fix from @R-T-B, but didn't bother changing my video settings (win10 with a 1080gtx, as it might matter) and the planet no longer looks to be covered in snow when I start up the game. This means forcing d3d12/opengl may not be needed by everyone. edit: Of course, then I get into the game and have no water still, so I guess forcing the other display options are still needed.

Just posted a new issue on GITHub for it only displaying one alarm (non-minimized) with a scrollbar no matter how many the settings say to display (currently set to 5, but it was at 15 when I started troubleshooting it again today). v3.10.0.0 on 1.6.1, but I saw the same behavior on 1.6.0 with this version.

I have experienced this since 1.0.4, but only if I had the Kerbal EVA before launching the vessel. If the crew didn't get out (say, for some EVA reports while flying at Kerbin's Shores just before launch) then it would properly register. On that same note, the contract would complete for me if, on the second rocket flight, I did not do an EVA. I haven't tested whether it still happens in 1.0.5, however, as my habit became to lob Jeb ASAP, then have Val get the EVA reports from the launchpad prior to her flight in the second vessel. I'll check it after work tomorrow (need to sleep now ... darn day job) if nobody else has before hand.

I love the idea of this mod, and as with the others I'm interested in using it with KCT. I'll be using it without KCT for now, but thought I would see if you had made any progress on getting the two to work together.

I have been experiencing a CTD since installing Scatterer (0.151) that only appears to happen when recovering a vessel after a (sub)orbital flight. Everything appears fine, and my memory footprint is under the 32bit limit (~3.3G on a 16G system, though I'm running 32bit KSP), but when I click the "Recover Vessel" button above the altimeter the screen goes black as normal, thinks for a few seconds and then *bam*, I'm at the desktop. When reloading the game, everything is fine and I can recover the ship, but the next launch has the same problem. Going through the output_log, there are about a dozen null reference exceptions that appear to be part of trying to tear down the scene for transition to the space center view. NullReferenceException: Object reference not set to an instance of an object at scatterer.SkyNode.UpdateNode () [0x00000] in <filename unknown>:0 at scatterer.Manager.Update () [0x00000] in <filename unknown>:0 at scatterer.Core.Update () [0x00000] in <filename unknown>:0 This has happened more than once, and with difference ship designs. I had two in a row this happened with, so I then removed Scatterer from game-data after the second crash. On the next mission (nearly identical suborbital flight over the Peninsula of Shame, using the same craft) the vessel was recovered without the CTD happening. I've done two more flights since without Scatterer or the problem. If you need more info please let me know and I can make the full crash report available. I have a number of mods installed (I've a list available) but my first step (removing Scatterer) seems to have removed the problem, so it looks to me like something with the scene transition isn't quite right.

As far as I'm aware, the Remote Tech flight computer just points the vessel in the specified direction using whatever RCS/SAS options are available (if any). It is not an SAS itself, just a type of directional/orientation autopilot. My experience with using it is that when you come out of warp it immediately applies the appropriate torque to face in the specified direction in the same way the stock "auto" pilot holds orientation. I haven't tested how PR and RT work together currently, however, so I don't know (yet) how they interact. I hope to fix that this week, assuming I can get the time to play enough to get a comms network in place. And, to add to the rest of the folks -- Thank you again for keeping this mod alive. I'm happy to be one of the 10,000+ people to have downloaded it from KerbalStuff, as this mod's feature was the first one I looked for back in 0.18 (and didn't find back then, or at all until you took over the mod a few months ago).

I'm curious as well, because I haven't seen any problems with my (admittedly limited) game in KSP 1.0.2 using 0.4.3.

Yay! The mods I've been waiting on (RT2 and FAR) are both available now! Thank you RT team for your work on this! Assuming you added RT2 to an in-progress game, did you 'research' the new parts in already researched tech nodes? Other than an improper installation, its the only thing I can think of that might be causing it.

It appears to in the Sandbox game I just created. I'm treating it as "works, but might still have problems" right now.

Ferram, thank you again for such a wonderful mod. Make sure to take a break from listening to us mere users next week.

Thats what I was thinking, but wanted to verify. Thank you.

I've noticed that the Mk16 parachute gets ripped off now at speeds and altitudes that it readily survived on 0.24. Is this a change to KSP itself, or a difference in how FAR (and/or Deadly Reentry) calculates the forces? As an example, my go-to chute setting was to have it deploy at 0.08 atmospheres and fully deploy at 350m. With 0.25 and the mods I have installed the chute gets ripped off even if I change the initial deployment to 0.25 atmospheres. I know the chutes are still working as I've done some other things that have slowed the capsule down enough to allow the chute to survive deployment, though I haven't nailed down what the critical speed threshold is yet. No complaints, I'm just trying to understand the new performance I'm seeing.

Nathan, I'll just blame it all on a misunderstanding exacerbated by the phrasing I used. Regardless, I'm glad to see your usual rapid updating. DRE is one of my 'must have' mods now that I've gotten used to it.

Dude! Chill. I wasn't blaming you for it, I was trying to provide info on what specifically happened to me when I got the problem. The facts are that it was the only change I made and the problem appeared after the change. In my 30 years of troubleshooting experience a change that was made is, 49 times out of 50, the root cause of the problem ("No, Mr Techsupport guy, I didn't make any changes. When the problem happened I was using the software just after installing the driver update I didn't mention until now. Of course, it can't be the driver ...") Since it clearly matters so much to you that you think I'm accusing you of breaking things, I decided to revert back to 4.8 to see what happens. I ran a mission just now using DRE 4.8 and the TT-18A between stages 4 and 5 decoupled as expected (74km up, level "flight", free-fall). I reverted back to the launch pad, shutdown the game swapped back to DRE 5.0 and launched again with the same ascent profile, and checking the same TT-18A at the same point in the flight. Once again, the problem ONLY appears when DRE 5.0 is installed. So, while the problem may also randomly happen in all x64 games, it CONSISTENTLY happens in my game when I have DRE 5 installed and DOES NOT happen when DRE 4.8 is installed. edit: Reading the post above mine, I decided to try the same test with DRE as the only mod installed. I closed the game again. Moved all the mods except DRE 5.0 and MM 2.2.0 (came with 5.0) to another directory (outside the KSP directory structure), started a sandbox game and build a rocket similar to what I tested above. With 5.0 the TT-18As has zero force. I then reverted the flight to the launch pad (as I did above), shut down the game and switched back to DRE 4.8 again. Interestingly enough, with both TT-18A separations, it also had the problem (zero force). So, this tells me that the difference between DRE 4.8 and 5.0 more than likely isn't the cause, despite initial appearances. This, of course, makes me wonder why I didn't experience the problem before I installed DRE 5.0. The mods I removed were KER 0.6.2.5, FAR 0.14, Kethane 0.8.8, Kerbal Alarm Clock 2.7.7, TAC Life Support 0.9.0.9 pre3, and RT2 1.4.0 (built for 0.23.5). I wonder if something in one of those mods removes the problem with DRE 4.8 but not with DRE 5.0?

NathanKell, Just wanted to pass on that I upgraded from 4.8 to 5.0 today (both running in 0.24) and I started getting the bug where decouplers didn't provide any force. I launched two separate kerbal rescue missions today. Both used the same vessel (three Mk1 capsules each with their own engine and parachute). The first, when I was still using 4.8, worked as expected: popped the decoupler and the reentry vehicle drifted away from the ship at about 0.7 m/s. With the second, after seeing you had updated DRE and my installing v5.0, behaved much differently. The decoupler made the appropriate noises and visuals, but the reentry vehicle did not move at all. After switching to the now separate vehicle, I had it roll in place and that caused it to move away from the mothership as expected. I saw in another thread something about decouplers not behaving correctly in x64, but I was not having this problem until I did the DRE v5 update (from v4.8). I made no other changes to KSP today so I know for sure its something that changed in the 4.8 to 5.0 changes.

x64 here, using the same version of TAC LS, and i'm not seeing the lag problem you are referring to.

Tons of it. *twitches a bit*

Not sure if this has been mentioned before, but the background color for both the big and small maps tends to blend in with the black and white initial scan, which can make identifying spots that haven't been uncovered difficult some times (more so on the small map than the large). Would it be possible to select a background color with a greater contrast to the possible filled in map colors or, if not too difficult, two or three options to pick from in the settings config? This also has the benefit of providing options for those with different color perception than the norm.

A big thing to help avoid getting tagged as spamming is in DNS to have your PTR set to match the hostname (A record) for the server (I do DNS changes all the time for folks that have space in the datacenter I work at). Having a properly set up SPF entry also helps, as that verifies via a DNS entry what servers are authorized to send email for the domain, and quite a few places use (lack of) SPF as part of the spam determination process. Most of this, of course, can wait until a more solid determination of what domain is going to be used for ReplacePort (still my preferred name, by the way ).

It looks to me to be entirely in Gerinia, though it is pretty damn close to the Dachland border. Very nice map. All that is missing now are the names of the various seas around Kerbin.

This is probably getting a bit ahead of things, as a rating system is at best a second pass item in my opinion (have to get the site hosting things to rate before you bother actually rating them) but I wanted to share my thoughts. I think my suggestion works best if everyone has to log in to download, however, that does require a bit of extra back end work as well as adding a (low) barrier to entry for folks that "just want to download <mod>". It should be able to mostly work based on GET data, though one point requires a login, and another two would (in my opinion) work best if login was required. Anyway, to the meat of the post. A simple additive system for (mostly) auto-magically rating hosted mods they look at with minimal effort by site users. Basically, site use drives the majority of the ratings. * If a connection/user views the mod, +1 star * If a connection/user dowloads the mod, +1 star * If a connection/user (possibly user only) recommends the mod (via checkbox), +1 star [mutually exclusive with the below line] * If a connection/user (possibly user only) indicates the mod has a problem (via checkbox), -1 star [mutually exclusive with the above line] * If a user marks the mod to notify on updates, +1 star This leads to an automatic rating from zero (0) to four (4) stars, where the end user has, at most, two mutually exclusive checkboxes ("I recommend this!" and "This has problems!") with the rest of the ratings coming from how they use the site itself. Examples: If you view a mod but don't download it, this feature marks it as a "1 Star" mod for you. If you download the mod and mark it to notify you of updates, it would be marked as a "3 Star" mod (1 view, 1 download, 1 watching). Combining the above with metadata about views of the mod entry and a mods relative worth is pretty clear. "300 views, 2 Stars" means a decent group of people have looked at it, but not many are watching and/or recommending it. "2 views, 4 Stars" means its new; it might be good, it might not. "2300 views, 3.5 Stars" mean lots of folks are downloading it and most are watching and/or recommending it; probably a good thing to look into. This should be a relatively simple system to implement: views of the mod page, download links on the page clicked, and whether or not zero or one of the two user checkboxes are selected summed, then stored to generate an average rating. Not having worked on a site this large, I'm not sure if the results should be cached and updated in the background, or calculated "live", but even cached it should still be useful and relatively low in system resource costs. Obviously, this isn't a perfect system. Spiders could taint the data (lots of 1 Star "reviews" added as they spider through the individual mod pages), but this can be worked around in at least a couple of ways. It may only work if everyone has to log in, which may turn enough users away to make it worthless, but I'm really not sure if that would be the case. There are probably at least two other things I've overlooked, but if I don't throw it out there it could just as easily have been the Ultimate Method nobody else thought of. Feel free to (constructively) critize, comment or stick on the back burner for ReplacePort 0.5 or whatever. By the way, I'm partial to the name DeepSpacePort, though ReplacePort is catchy.

AdmTigerclaw, your setup looks a lot like mine, only I used five instead of six for that outer ring. My basic setup is a ring of 5 (or 6) sats, equidistant from each other on orbits synched to the tenth of a second (thank you, Kerbal Engineer Redux!). Those sats have a semi-major axis of 1,584,953.3m (orbital period of 3 hours 0.0003 seconds). Each sat is at least one basic omni (2.5Mm range) and a 90Mm dish for Mun/Minmus comms. Early versions used smaller dishes to interconnect the sats to the ones before and after in line, but I've found the omnis work better for that. I have found that if you take the time to get the orbital period synched to at least half a second of each other then even long periods of time warp lead to very little drift due to rounding errors. Of course, I haven't done much long duration spaceflight yet, so it may make more of a difference once I do.