thunder175
-
Posts
121 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by thunder175
-
-
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.
Quote[EXC 21:50:29.959] NullReferenceException: Object reference not set to an instance of an object
KerbalConstructionTime.KCT_GUI.DrawBuildListWindow (Int32 windowID)
UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID)
UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, Int32 instanceID, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) -
@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.
-
21 minutes ago, Beale said:
It should be compatible with pretty much anything, as long as the standard rollout game event is being called.
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?
-
3 hours ago, Rory Yammomoto said:
I did.
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
bravegood 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.
-
45 minutes ago, akron said:
Looks awesome! I'm glad to see that solar panel in use more despite its low clearance. That's a lot of batteries for a relay commsat
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.
-
1 hour ago, cyberpunkdreams said:
Well, I've got something proper weird going on then! It's just this probe core that behaves this way for me. It's always been this way, across multiple career games and mod set-ups. I don't even really want it to be honest, as it does feel weird...
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?
Spoiler@PART[ca_vor_core]:AFTER[CoatlAerospace]:NEEDS[RemoteTech]
{
%MODULE[ModuleSPU] {
}
%MODULE[ModuleRTAntennaPassive] {
%TechRequired = unmannedTech
%OmniRange = 3000
%TRANSMITTER {
%PacketInterval = 0.3
%PacketSize = 2
%PacketResourceCost = 15.0
}
}
} -
3 hours ago, magico13 said:
I don't believe there's anything hard coded, but that doesn't mean there won't potentially be incompatibilities. There might be an assumption that there are three levels in there since (for whatever reason) building levels are given as a float between 0 and 1 and I need them as an integer, so I multiply. That would potentially affect any formulas that use the building level, and has a (lesser) possibility to affect the checking of restrictions (vessel size/mass, etc). I'd love to know whether or not it works properly since I'd like it to be general and not care about specific levels.
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.
-
7 hours ago, RocketRyleigh said:
From what I understand, this might not be necessary at this scale, but I like consistency; what settings for Atmosphere rescale and atmoTopLayer would be best for a "realistic" upper atmosphere (more gradual increase from space) and overall atmosphere height at 3.2x scale?
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.
Spoiler@Kopernicus:FINAL
{
@Body[Kerbin]
{
@Properties
{
%rotationPeriod = 86164
%initialRotation = 254.595 //sets midnight local time to KSC
// %timewarpAltitudeLimits = 0 90000 90000 90000 150000 300000 600000 900000
@timewarpAltitudeLimits,0[*, ] *= 0.46875
}
@Orbit
{
%inclination = 1.31
%eccentricity = 0.0167
%longitudeOfAscendingNode = 0
%argumentOfPeriapsis = 0
}
}
} -
@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!
-
@Sigma88 I started a new game running a 6.4/6.4 after playing 3.2/6.4 for a long time. I have found it annoying that the time warp limits are getting scaled as well. For example, at 6.4x the lower end limit for time warp goes to 192km! This was occurring at 3.2x but I didn't find it as annoying since it was raising the time warp limit to only 96km, and I have raised the top layer of the atmosphere to approximately 90km. I manually went thru all the files from github to make sure I have the most current versions and it appears I do. Is this behavior normal as the mod is currently written? I tried to force time warp limits manually in my extra MM patch by adding a time warp limit entry, but it didn't respect that entry and I'm still limited to 1x time below 192km. Is there a way to limit or change the time warp settings another way so they its not a raw multiplication of the configs found in \Configs\Bodies\Templates? Or am I doing missing something simple?
[1.8-1.12] Ferram Aerospace Research Continued: v0.16.0.5 "Mader" 03/04/22
in KSP1 Mod Releases
Posted
Any resolution to this?