NathanKell

@R-T-B Yep the EC generation is all in post. The rest of the calculation is setting the angle and determining LOS (Solar Panel also overrides the LOS step to do some raycasts, but it only establishes what the blocking part is, it doesn't generate EC). Happy to help!

@R-T-B can you subclass from solar panel and then override PostCalculateTracking. Set a flag before you call CalculateTracking, and in PostCalculateTracking() only call base() if the flag isn't set, then after your call, set the flag back to false. Hacky, but should prevent EC generation when you call CalculateTracking but still do so when the module does its own thing. (to be clear, EC generation is done in PostCalculateTracking)

@OhioBob great to see you again as well! I've been pretty much detached from all things Kerbal for the last year and a half, and mostly-detached for a couple years before that. Things are well though! Hope same for you? So...I went digging a bit and saw this in physics.cfg: solarLuminosityAtHome = 1360 // Solar flux in W/m^2 at the orbital altitude of the homeworld First, I screwed that up, it should be irradiance. But anyway, that reminded me that solar panels actually hijack the flight integrator's thermo code (which has to calculate solar flux at the vessel's current orbital altitude over the sun) and I htink *that* code uses raycasting in scaled space, which is liable to have float precision issues. So that might be the cause of your offset. (I believe I did test this that in orbit of kerbin the solar flux is reported to be 1360W/cm^2 so I don't think there's an alt/sma mixup after all.) That it lines up with alt/SMA I can't explain. But that allows me to answer your question about extinction. I think I hacked it (hah, surprise). Something like estimate the mass of air light will be traveling through (well, one scale-height's worth, IIRC), and then get a relative factor comparing atmospheric density at sea level on your current body vs on Kerbin, and multiplying the reciprocal of that with a "how much gets to ground on Earth, cough Kerbin" factor set, like solar luminosity (ehh, irradiance) in physics globals. I don't recall the specific numbers, sorry. It's all about taking straight up to the sun through Kerbin's atmosphere as a baseline and then trying to figure out how much extra air there would be based on solar angle and extra atmospheric density / higher scale height. Did find something that reminded me of what site I used to set up the temperature curves. The data points I used were: 4k 1.2x; 300k 1x; 1200k 0.134x; 1900k 0.02x; 2500+k 0.01x

@Arrowstar @OhioBob That...sounds about like what I wrote there, yes. I have no idea if it's been changed since. It's taking the dot product of the panel's up vector and the ship->Kerbol vector, dividing by (alt/ref_SMA)^2, and that's the output. If the raycast from the panel's suncatcher transform hits any collider on its way to the sun, the panel is counted as "in shadow" and provides no charge. However there's also two other aspects involved, it's coming back to me now. First, the panel's temperature. There's a floatcurve in the PART config that determines a multiplier at a given temperature in K. Evaluate it as you would any other floatcurve. EDIT: Uh, if it's not there, you probably have to empirically determine it, I might've set default values in code. Or ask a friendly current dev. Second (although IIRC stock doesn't use this, only RO) there's a multiplier based on mission time to support panel degradation. If there's no mention in the cfg file, assume it's not used in stock.

Yeah, I did some work to make the previously internal-only Kerbal Part (code-side) work like other PARTs. That is it would pull its PartModules from cfg and support adding/removing PartModules and changing PartModule values in cfg. But there was a whole lot bound up in the prefab, linking the asset and the Part, such that only the gameplay side is really easily moddable. Me and @Porkjet had a dream at one point to put real humans in, but we never got to it before we moved on. Man, takes me back.

@FreeThinker density. @Arrowstar flux is (calculated external temp - skin temp) x coefficient x the global convection constant and yields watts per square meter. That is then multiplied by exposed skin area and applied to the skin thermal mass. All constants are in Physics.cfg

@FreeThinker Nope, barking up the wrong tree. Heating is proportional to sqrt(rho) * v^3, not rho * v^2 (the latter being dynamic pressure). What's actually related to dynamic pressure is those cool swirly visual FX you see. @Arrowstar sure thing. So, in the simple case (let's assume nothing is occluded), then the hypersonic convective coefficient is: 1E-07 * MachConvectionFactor * (density ^ MachConvectionDensityExponent) * (velocity ^ MachConvectionVelocityExponent) EDIT: Oh, right, and the sqrt is ignored if density >= 1, so it's really (if density > 1, density, else sqrt(density)). Uh, since MachConvectionDensityExponent is presumably still 0.5, unless y'all changed it while I've been gone. HOWEVER. Two caveats. First, if you get too low while going too fast, we have a "pseudo-Reynolds number" that punishes you for doing so. If that gets too high, your convective coefficient spikes because you're in turbulent flow. Second, occlusion does weird things--the above math is only valid for the frontmost part, and behind that you're inside the shock cone and both area presented to the heating, and the effective shock temperature, get decreased. (And by "some work" I presume you mean "done wrote it" -- again, unless it's been rewritten since. ) If you want the entire thing all the way down, there's some general multipliers too, like the general convective constant, the part's convection multiplier, the part's exposed surface area, etc. Oh, and the above yields watts (like any sane formula would) and we convert to kW because KSP masses (and thus thermal masses) are in tonnes. ARGH, hopefully last edit: don't forget radiative heat. I've talked only about convection, above, but for fast reentries the radiation really matters too. We lerp between the full shock temperature and space background radiation based on a "density thermal lerp" calculation that involves the atmosphere's adiabatic index and the mach. That's fairly complex, and has some empirically-determined piece-wise bits.

You have perfect timing, @Bornholio! By reversed, you mean how the mission and expiration stupids are reversed? That's correct because the expiration should decrease the stupider the kerbal, and the mission training time should increase the stupider the kerbal. Both feed into lerps of (min, max, stupid) which linearly interpolate between the given min and max values based on the input stupid value (where 0 results in min and 1 results in max). Unless I misunderstand what you mean.

@linuxgurugamer hmm. @rsparkyc did the updates to 1.2. Not sure his plans for 1.3.

@coolguy8445 There can't be a standalone because we just use models and then rescale and repurpose them. What you probably should do is (either yourself or with others) make a mod that sanifies KSP electrics. For the parts with their KSP purposes, not "this little piggie is now a Surveyor probe core, and this little piggie is Mariner" and so forth. @Wallygator I...have no idea what you mean. They're fine in RO, that's what I mean. If you have a problem with stock, you might want to talk about it somewhere other than the thread for the not-stockiest of mods.

@coolguy8445 the issue isn't the solar panels (they're sane for their mass, albeit not their size), or the batteries (I mean, they have hilariously low capacity but whatever)--the issue is the consumers. They're all over the map. Pods use *no* EC, for example, unless they're torqueing, but probes use a lot...but then so do lightbulbs! You'll need to handle that, which has to be done on a part-by-part basis, for EC to make sense.

Yep, happily @soundnfury is working on a UI for maintenance. For retirements...what do you suggest? Should we just not have the retirement popups? Certainly you'd want one when you hire a crew member, I'd think, unless you want to manually look at the tooltip, and certainly you'd want one when someone retires?

Guilty as charged, yes.

There is indeed a catastrophic bug with RealFuels right now.

How to get support for modded installs For help with stock versions of KSP, please check the Stock Support Forum First, you should follow these troubleshooting steps Following these steps resolves ~90% of all mod-related issues, which allows you to get back to playing and allows modders to spend more time focusing on the ~10% of issues that require their attention. Make sure all your addons are up to date. Bugs get fixed all the time, and there's nothing worse for halting development of features / fixing of bugs in a mod than for a modder to be made to think a bug they have already fixed has returned. Please: make sure your mods are up-to-date. Make sure you have all your addons installed correctly. Addons need to be installed exactly as they tell you to in their readme or opening post; if they don't say how, then follow this simple guide: Find out if there is a GameData folder inside the archive. If there is one folder at the root of the archive, look inside it, and so forth. If there is a GameData folder somewhere in the archive, take all the stuff inside the GameData folder in the archive and extract to (your KSP folder)/GameData/ If not, then you should probably extract all the stuff in the root of the archive to (your KSP folder)/GameData/ -- but note that some mods (like Universal Storage) have the folders you should extract into GameData inside a containing folder; in that case you should extract the folders inside the containing folder into GameData. Check the stock help sticky and stock known issues sticky: you might be running up against a known issue in KSP itself. Self Help, Reporting Guide. Check to see if the issue was already reported. Search the mod's thread (using the "search in thread" option) and search this forum (using the “search this forum" option) to see if the issue was already reported. If the mod has an issue tracker (see below), check to see if the issue was already reported there. Reporting an Issue after you have followed the troubleshooting steps To report an issue, please follow the following instructions. An issue report should contain the log, a set of reproduction steps, and be done in a clean environment with a list of the mod(s). If you don't follow these instructions, modders will ask you to do so before providing help, and that just slows everyone down. Note that a number of mods maintain their own issue trackers. If a modder mentions (for example in the opening post for the mod, or the readme) that you should post your issue on their issue tracker (for example the issue tracker on Github) please do that rather than posting your issue here, but follow the same steps. The Logs When KSP crashes it will general a folder with files with details surrounding the crash. Usually a window will pop up ingame asking you to send this information to the developers, along with the name of the folder. You can find this folder in the KSP install directory. If KSP doesn't crash, start KSP and cause the problem. Quit KSP and find the output_log.txt (not the KSP.log) at the location below: KSP versions 1.3.1 and below: Windows: KSP_win\KSP_Data\output_log.txt -OR- KSP_win64\KSP_x64_DATA\output_log.txt (depending on which used) - In case you installed KSP into a Windows protected directory (C:\Users, C:\Program Files or C:\Windows\ and their subfolders) the output log file may be stored in the folder called C:\Users\[username]\Appdata, this folder is usually hidden so you should enable the view hidden folders option (more information). Note that for the demo you should find the output_log.txt file located in the KSP_Data folder. - Steam users should right click KSP in Steam, click on Properties, then in the Properties box, click Local Files, then Browse Local Files. Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs/Unity/Player.log Linux: The log is written to /home/user/.config/unity3d/Squad/Kerbal Space Program/Player.log KSP versions 1.4.0 through 1.7.3: Windows: C:\Users\<username>\AppData\LocalLow\Squad\Kerbal Space Program\output_log.txt - This folder is usually hidden so you should enable the view hidden folders option (more information). Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs/Unity/Player.log Linux: The log is written to ~/.config/unity3d/Squad/Kerbal Space Program/Player.log KSP versions 1.8.0 and above: Windows: C:\Users\<username>\AppData\LocalLow\Squad\Kerbal Space Program\Player.log - This folder is usually hidden so you should enable the view hidden folders option (more information). Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs/Unity/Player.log Linux: The log is written to ~/.config/unity3d/Squad/Kerbal Space Program/Player.log You can upload these files to any file sharing site (such as Dropbox, Pastebin or File2web). These sites will give you a link you can include in your posts to share your files. NOTE: These logs are not the same as KSP.log, which lacks valuable data. Do not upload KSP.log; do upload output_log.txt / Player.log The Reproduction Steps These are essentially a recipe on how to cause the bug. If you don't include reproduction steps, the modder won't be able to reproduce the bug, and then can't fix it. The more detailed you make this, the better. Leave nothing out. Leaving out details can make bugs impossible to reproduce, and thus, impossible to fix. The gold standard for reproduction steps is an unedited video of you causing the bug. Clean Environment If the issue stems from one mod, try to replicate it with only that mod and its hard dependencies in a clean KSP install. If the issue stems from the use of several different mods (for instance, Procedural Wings are still producing lift underneath a Procedural Fairing while FAR is installed) then get a clean install of KSP and install only the mods (and their dependencies, if applicable) in question. This may seem like an extreme measure, but it ensures that only those mods (or the stock game) is to blame. Despite how complicated it may seem, it is actually quite simple to do (even for Steam users), as you can simply copy your install directory elsewhere as needed. It's especially useful since interaction bugs are some of the hardest to nail down; something that appears to be a bug in one mod might actually be caused by something else. Regardless of how many mods are installed, you should include a list of all mods installed with their version numbers; a screenshot of your GameData directory is not sufficient, as it does not include version information and some directory structures may hide what mods are installed. Obviously, this is easier if you reproduce the issue with fewer mods. Example Issue Reports Note that this report has narrowed the problem down to the minimal number of mods (DRE Continued and its dependency, Module Manager) and the minimal craft necessary to cause the problem.

@Tristonwilson12 do I understand correctly that right now RealKSC uses a mesh terrain item? Or do you have a mapdecal? If your terrain is from a mesh, I highly recommend replacing the mapdecal's blank heightmap with an actual Canaveral heightmap to let PQS handle all the terrain natively. MapDecal is notionally for having local heightmaps that override the global heightmap, but all it's used for on Earth right now (and Kerbin one presumes) is to flatten things.

@Crzyrndm sorry to see that but I get how life goes. Bestest best wishes! As to pwings, DYJ let me update the license when I took over, and I believe it was to CC-BY-NC (and possibly -SA as well).

@ufindbatman ah I can help there! KSP *always* runs in DX9 mode in Windows unless you force DX11 mode. You can also force OpenGL mode. On Mac and Linux of course you can only ever run OpenGL mode no matter what arguments you pass to the executable. Best wishes to you!

So, finally trying this out. However, it looks like the default KSC position is well clear of anything interesting and, worse yet, for me it looks like the main heightmap is interfering with the RealKSC terrain. Has anyone tried replacing the heightmap that the MapDecal uses with a real Canaveral heightmap?

Hadn't heard of this until now, which is bad. I'm wondering--why is there a DX11 requirement? Just to lower system RAM usage, or does something actually depend on it?

@Alcentar awesome!

@Sigma88 for some reason, sometimes it creates the log in %appdata% ( search under that for output_log.txt ). @OhioBob hit windows+R and type in %appdata% and hit enter. Then hit ctrl-F and type output_log.txt and hit enter. That should find it. I hope. (In particular, it's in the Kerbal Space Program folder in Roaming appdata. I *think*. It's been a while since I've seen that happen.)

@Tyko as of 1.1 you can write your own date/time formatter, so as I said if mods are smart and use KSP's own date/time formatting, then you can have whatever days you like. RSS takes advantage of this to add months and have proper (1951+) year display. https://github.com/KSP-RO/RSSTimeFormatter

@Alcentar the NK-33 and RD-275 are fixed! Awesome! But there's still an issue: while the actual vernier models on the RD-108 move correctly, the thrust transforms don't seem to be parented to the right verniers at all. Do test it ingame and try to roll, and see what happens: the exhausts don't move correctly in sync with the verniers, and no roll control is provided--the exhausts splay in and out instead of going side-to-side.

@Tyko I'm confused. KSP itself supports either 6h or 24h time, and RSS just sets the gamesetting during load. There isn't some way to set KSP to allow arbitrary time formats that way, unless (a) you replace DateTimeFormatter, and (b) all the mods you care about properly use it to format dates.