thunder175

Coming back to KSP after a long hiatus, glad to see RT still going strong. I have to admit however that I keep going back and forth with the current RT version and the stock CommNet with the constellation mod given the ability for spectrum allocations to differentiate the networks. Hoping RT2.x comes in the not too distant future. One of the issues I'm currently having is when running MandatoryRCS. Instead of tweaking the PID's further, can you allow a user configurable value for inertia and RCS burn much like MechJeb? In the MechJeb attitude settings I have use inertia and stop time set to 0.2 to greatly reduce the RCS usage at the cost of slower slewing. The current version of the flight computer burns the RCS thrusters expecting a stockish torque wheel (I'm guessing) to slow it down and it blows right past the commanded position, and burns thru hydrazine freakishly fast. I guess I can always reduce the RCS thrust down to a minimal thrust limiter level, but I'd rather the system be smart enough to pulse the RCS to get the craft spinning, then pulse again to stop, thus minimizing the RCS usage when running MandatoryRCS even if I have to sit there and wait a minute or two.

Any resolution to this?

Using the experimental build #20181103.6 on a 1.5.1 modded install, I'm getting the following log spam and and the VAB build list isn't working. Interesting enough, it does display the SPH and R&D menus.

@Beale Any updates to the problems reported by the last two posts? I'm having the same issues with the most current version and 1.3.1. Interestingly enough, if I remember where I left off and edit the file manually after closing KSP, the sequencing starts again as would be expected. It appears that the plug in is not writing any new data to the file, although it is updating the last modified time stamp.

I've seen some odd behavior in my current save. For some reason the VAB assembly queues is only showing two rates, instead of multiple. Apparently its lost the additional queues. On the upgrades tab in KCT, it looks like I should be seeing the additional rates listed but they are blank. Is this an after effect of CustomBarnKit meddling?

Was RemoteTech compatibility ever integrated into the baseline? If not, any chance to add a requirement for a valid connection to mission control via RT?

Just following up from an earlier post. I love this mod with KCT on a new career save. It's really helping keeping the clutter down in the craft files since I'm using a block buy mentality in my spacecraft design. Definitely recommend using the name outside the brackets to differentiate between craft in the KCT construction queue. I know there was a desire to keep this mod lightweight and simple, but I offer a suggestion to expand the mod with a GUI for true program management. Would be great to have a log per program showing all vehicles, with launch date, cost, etc. That would finally eliminate the need for a separate Excel spreadsheet for the truly OCD.

A feature enhancement I'd like to see if possible would be an option to disable the circularization burn after reaching the programmed Ap. Alternatively, how about at least be able to set the coasting time before executing the next node? Very annoying that the craft immediately turns to the circularization burn node and burns up monopropellant if I am not quick enough to shut down the RCS or puts solar panels out of position or optimal charging. Even more elegant solution and feature enhancement I'd like to see for RT users would be to automatically add the circularization burn node to the RemoteTech Flight Computer.

I just tested this with KCT and indeed it does work with a catch. Since KCT basically saves the spacecraft in the persistence file until its ready to launch, the name is still bracketed in the KCT assembly queue. In other words, if you have [ComSat] and click build a couple times, you'll have multiple [ComSat] being built in the construction queue with no numbering. When you roll out to the pad and then hit the KCT launch button, the vehicle is then name appropriately as ComSat 1, ComSat 2, etc. I think this will be especially useful for block production when the design changes slightly. The one thing I would ask is that for those of us adding to existing saves, there doesn't appear a way to get ProjectManager caught up with our current numbering scheme. Does the plugin store the current sequence number somewhere? Or asking another way, is there a way to manually increment the number sequence to start at a higher number? I track everything manually in my own Excel file and would like to utilize this in my ongoing save.

Is this compatible with Kerbal Construction Time?

Then remove it if you don't want all the Saturn parts rescaled to 6.375m/4.25m. The current iteration of the rescale patch only applies to the Saturn components, not Skylab. If you want to use the rescale patch, then I recommend using Procedural Fairings to create an interstage to interface the S-IVB 4.25m to Skylab's 3.75m base. Only other option is to wait for someone to add the Skylab components to the saturn_rescale.cfg file. I'm looking at it now and I'm not brave good enough with the MM patches to try to make it work, so I'll defer to the design team.

@Rory Yammomoto By chance you didn't install Saturn_rescale.cfg in your Game Data folder somewhere did you? This looks like the Saturn parts have been rescaled to 4.25m in accordance with the patch in the extras folder.

Seeing the wonderful Commnet Constellation mod has me really looking forward to RT 2.0. I did have a question and/or feature request regarding the ground stations on future implementation of the constellation mod and posting here as it is more applicable to the future version of RT. Any chance we can segment the ground stations by frequency as well as the satellites? Would also be nice to be able to have the color picker work for ground stations dots as well to visually differentiate between ground segment networks. Cumbersome to change the raw RGB value in the MM patch. Not sure if this is already planned. If not and you like it I can submit as an issue on Github for tracking. Also from the other thread I definitely like option 2. Allow us to set frequency by individual antenna for cross-banding solutions.

@magico13 I've noticed something over the past couple days that I want to report. I have three launch pads. The first (default) is still Level 2. My other two pads are Level 3. I like keeping one pad level 2 for lighter launchers. Usually on initial load, the VAB timers are only rolling for the first two entries in the construction queue, everything else is awaiting construction. When I change pads using the buttons, the other queue'd items begins constructions again (up to 4) and all is well. I haven't tried or verified this behavior in a fresh save. When I downloaded your latest dev build you recommended a few posts up, I started noticing this behavior. I'll see if I can get some screenshots next time it happens.

I was experimenting with RSS the other day since I was going to use KSP+RSS for some visualizations and graphics for a project since STK is just plain ugly. I tried out the US Probes pack here. I was looking at all the fully built probes and was fascinated by the TDRS models specifically. Earlier in the thread I posted my simplistic but functional Barquetta based "TDRS" using the small BDB folding antenna's. So my question is this: is it possible to place on your roadmap some new designs for folding and expanding antenna like TDRS A-G and K-M after the conclusion of your current efforts? I've always thought a variety realistic but still Kerbal-style folding antenna have been lacking. I know we got some options by other modders, but I think you are the man for the job with your distinct style and attention to detail, as well being able to seamlessly integrate with your existing series of buses. I think that it might be in scope of the Probes Plus since there could be a variety of uses depending on the configuration. For most of my antenna needs I'm using a mixture of Probes Plus, BDB, and even Contares (antenna only). Thanks for your consideration and as always the wonderful work you do.

@magico13 I reverted back to my changes in CustomBarnKit that were causing the issues, and after installing the new version of KCT with my current (backed up) save all seems to be working fine. The only significant changes to my custombarnkit config were adding levels to the astronaut complex and mission control. So I can't comment on @Streetwind issue with the launchpad.

You know I've thought that for a long time. A few different mods, including AmpYear, are saying max darnkess at 6.4x Kerbin (3840km) at GKO is ~58 minutes. I've even ran this thru the SMAD worksheet. So I've always had to pack my comm birds with batteries to last me an hour. On the small size of the Barquetta they start to add up quick, even with small and efficient antenna assemblies. In my universe my Kerbin has a slight inclination but not enough to avoid the daily eclipse. So I just pack my comm birds with batteries. Looks odd but it gets the job done for continuous comms.

Sometimes its just the simple things in KSP that make it all worthwhile... My take on Coatl small form factor "TDRS" for RemoteTech launch support, parked in perfect 6.4x GKO.

I'm guessing its an addon core from a mod? It might not have an MM patch for RT compatibility. Make sure there is an entry for it that looks like the below, which I had to add manually for the latest Github beta version of Coatl due to there not being an entry for RT compatibility with the Vorona core. EDIT: I just saw your post about this being on the stock QBE. Do you have any other mods that could be overwriting MM patches for probe cores?

I can confirm weirdness ensues on building upgrades with additional levels. I added two more levels to mission control and the astronauts complex, and when the timer hit zero after upgrading them from level 1 to level 2 (of 5), I saw "building already upgraded" on the screen and my funds started spinning upwards. I had to edit my persistence file to get it back to normal. So current KCT does not like upgrading buildings modified with additional levels as far as I can tell.

Before we got the atmoTopLayer setting, I always had atmosphere = 1.2857 which gave me 89.999km atmosphere for my 3.2x Kerbin. After finding some other posts on here (check the RealisticAtmosphere thread) I settled on atmosphere 1.14 and atmoTopLayer 1.153. With those settings, the atmospheric boundary is at just over 92km which I feel is 'right' for a 6.4x Kerbin. You'll get some drag but at those settings you won't start glowing and slowing until much deeper in the atmosphere. The biggest benefit to that is that you don't hit a wall of atmosphere. Ultimately its up to you what feels 'right' because in reality at low altitudes you'll be getting serious drag force effects. I like those settings since if you dip a satellite below 92km it won't immediately explode due to overheating but will have induced drag force causing a change in the semi-major axis.

@RocketRyleigh A while back in this thread we ran the calculations for 3.2x and 6.4x rescaling and RemoteTech with root modeling. After running the numbers I think it was 2.17 and 4.34 respectively to get comparable level of antenna performance to stock. See this post here: Edit: Be sure to scroll up and down from the linked post. Should just be plug and chug depending on your rescale.

Just following up on my problem above. Apparently it was HyperEdit causing my time warp refactor issue. I moved HyperEdit out of my GameData folder after creating new MM patches for my planet orbit edits and the time warp limits were being refactored appropriately.

@Sigma88 I did as you suggested, but instead put the entry right into my own Kerbin patch file for a few other setting changes that I use. Restarted KSP and I'm still stuck at 1x below 192km. I've double and triple checked files and I can't seem to find a conflict anywhere else. I also been going thru all my other mods to see if there is a conflicting entry somewhere, but I can find it.

@Sigma88 I don't know if that is happening correctly at the moment. This is occurring on Kerbin. My atmosphere rescale is set to 1.14, with rescale and resize at 6.4. So looking at the config templates and taking your reply into account it should be multiply time warp limit 30000x1.14=34.2km. Instead it appears to be multiplying 30000x6.4=192km. Looking at the config file again, the only thing I can think of is that its treating Kerbin as an !Atmosphere planet. As always appreciate the prompt response and help!