hab136 Posted November 29, 2017 Share Posted November 29, 2017 7 hours ago, Wyzard said: I tried out the new release with my Minmus base (where I originally encountered the problem), but now the base's reactor overheats (instead of the ISRU): When I visited the base after not having loaded it in a few (in-game) days, the reactor overheated very rapidly and melted down within seconds. RadUsage was changing constantly, decreasing (surprisingly), but at the earliest I was able to catch it, it was using 465992 out of a RadCap of 600000. (RadCap is pretty big because I'd put enough radiators on this base to work around the problem in 0.9.7.) I went back to NFE 0.9.7, loaded a save from before the reactor overheated, and visited the base just to let it do its catch-up. Then I re-upgraded to 0.9.8 and opened the base again (after just a few seconds of in-game time). This time the reactor overheated more slowly, around 2 degrees per second, but still fast enough to melt down within a few minutes. RadUsage was just 350, which is too low. (The reactor on this base is an MKS "Duna" PDU, modded by NFElectricalUSIReactors.cfg. Its "required cooling" is 2500kW, but I'm running it at 25% so I think it really needs 625kW.) For comparison, in 0.9.7, the reactor's RadUsage holds steady at about 8108, even during catch-up. I'll try to do some more testing later. Me too. Ever since upgrading to 1.3.1 (from 1.1.3) my ISRUs have been overheating but still working, reaching 1500/1000 K, even on my one base without a reactor. After upgrading to NFE 0.9.8 today, reactors on bases with drills instantly meltdown on loading, showing temps like 41,000 K / 900 K. Reactors on orbital stations (no drills or ISRU) work fine. I reverted to NFE 0.9.7 so I can continue to play. Quote Link to comment Share on other sites More sharing options...
Nertea Posted November 29, 2017 Author Share Posted November 29, 2017 (edited) I guess that would indeed make it worse considering I fixed the bug that caused reactors to consume 50x the reactor. That would expose this bug for sure. Perhaps it's time to summon the @RoverDude to shed some light on this behaviour and how I can work around it. If you're around, dear sir, I point you to: this post. Edited November 29, 2017 by Nertea Quote Link to comment Share on other sites More sharing options...
RoverDude Posted November 30, 2017 Share Posted November 30, 2017 @Nertea - if you (or anyone) can get me a stock save that can replicate this, I can take a look. Quote Link to comment Share on other sites More sharing options...
Nertea Posted November 30, 2017 Author Share Posted November 30, 2017 2 minutes ago, RoverDude said: @Nertea - if you (or anyone) can get me a stock save that can replicate this, I can take a look. I'll give it a shot, but I'm not 100% sure it'll show up in stock, because the behaviour of the converters will naturally decrease their production as they move towards higher temperatures. I'll get back to you a bit later. Quote Link to comment Share on other sites More sharing options...
RoverDude Posted November 30, 2017 Share Posted November 30, 2017 (edited) 4 minutes ago, Nertea said: I'll give it a shot, but I'm not 100% sure it'll show up in stock, because the behaviour of the converters will naturally decrease their production as they move towards higher temperatures. I'll get back to you a bit later. I'll take stock part modules with an alternate config Asking because it is a lot easier for me to debug KSP without mods. Also eliminates the possibility of a mod interfering. You can also toss me info on exactly what kind of behavior you're looking to accomplish, there may be a way of sorting it in a different way. (i.e. if you have a config we can slap on a drill or an RTG or something, that helps). Edited November 30, 2017 by RoverDude Quote Link to comment Share on other sites More sharing options...
Nertea Posted November 30, 2017 Author Share Posted November 30, 2017 50 minutes ago, RoverDude said: I'll take stock part modules with an alternate config Asking because it is a lot easier for me to debug KSP without mods. Also eliminates the possibility of a mod interfering. You can also toss me info on exactly what kind of behavior you're looking to accomplish, there may be a way of sorting it in a different way. (i.e. if you have a config we can slap on a drill or an RTG or something, that helps). Turns out it's fairly easy to reproduce with stock if you know what you're looking for. PMed you a save. Quote Link to comment Share on other sites More sharing options...
dlrk Posted December 5, 2017 Share Posted December 5, 2017 Hey, @Nertea , I've got a small suggestion, I hope you don't mind. Would it be possible to get a version of the LT-POD that has ablative shielding, or a higher heat tolerance? Keeps burning off in reentry Quote Link to comment Share on other sites More sharing options...
WuphonsReach Posted December 9, 2017 Share Posted December 9, 2017 How difficult is it to add the kOS RPM screen to the Mk3-9 OCP and the PPD-1 HCM? I love the IVAs in those two cabins, but wish I had the kOS screens to play with. Quote Link to comment Share on other sites More sharing options...
OldSedan Posted December 12, 2017 Share Posted December 12, 2017 On 11/29/2017 at 7:20 AM, Nertea said: So in every test that I have done, in isolation the reactors perform exactly as they should. Ignoring the debug values and going by adding up core transfer numbers, any combinations of reactors work just fine. I have to conclude that (again) there's a critical bug in stock to work around. Here's some testing of my own. This base has enough radiators deployed to run the reactor at full power (800 kW) plus 4 drills at regular power or 2 drills at max power (200kW) 1) The reactor is enabled, nothing is enabled. Perfect stability, perfect radUsage (800kW expected, 799.98 kW used) 2) A single drill is enabled (+50kW, up to +100kW). The reactor immediately overheats and and its radUsage has dropped by ~175 kW, suggesting a lack of radiators on the base 3) 4 more small radiators are deployed, + 200 kW radiation capacity. The overheat slows, but radUsage is still 738 so the reactor will overheat. 4) I can stabilize the reactor by increasing the capacity by another 50 kW. So that one drill is using something like 350 kW of cooling. By this we can conclude that any stock BaseConverter module is somehow requesting far, far more radiator capacity than it needs, even though the debug does not show it. This makes absolutely no sense. Hey, sorry to bother you; I finally upgraded to 1.3.1 and ran smack into this issue with some off-world mining bases I'd set up with MKS and NF parts. I understand it's being worked on and I appreciate all your hard work! For the moment could you suggest any workaround? Would rolling back to an earlier version of NFE avoid this bug? Thanks! Quote Link to comment Share on other sites More sharing options...
Frag2000 Posted December 12, 2017 Share Posted December 12, 2017 Hi guys, I just downloaded NearFutureElectrical / NearFutureSolar update ... just want you guys to know that keeping that mod updated is really appreciated! This thing is the best. Good work!!! Quote Link to comment Share on other sites More sharing options...
Nertea Posted December 12, 2017 Author Share Posted December 12, 2017 On 12/5/2017 at 11:01 AM, dlrk said: Hey, @Nertea , I've got a small suggestion, I hope you don't mind. Would it be possible to get a version of the LT-POD that has ablative shielding, or a higher heat tolerance? Keeps burning off in reentry Uh, I can look into it. Can you make a github issue? I've very busy and don't have much mod time. 17 hours ago, OldSedan said: Hey, sorry to bother you; I finally upgraded to 1.3.1 and ran smack into this issue with some off-world mining bases I'd set up with MKS and NF parts. I understand it's being worked on and I appreciate all your hard work! For the moment could you suggest any workaround? Would rolling back to an earlier version of NFE avoid this bug? Thanks! You can revert to the previous version (0.9.7) if you have the issue. The bug in that version will hide the stock bug a little better. On 12/9/2017 at 7:12 AM, WuphonsReach said: How difficult is it to add the kOS RPM screen to the Mk3-9 OCP and the PPD-1 HCM? I love the IVAs in those two cabins, but wish I had the kOS screens to play with. Not sure, suggest you have a check in the files to see what would be required. Quote Link to comment Share on other sites More sharing options...
Nertea Posted December 15, 2017 Author Share Posted December 15, 2017 NF Spacecraft 0.7.5 Updated B9PartSwitch to 2.1.0 Updated NFProps to 0.2.1 Added Simplified Chinese translation Updates to Russian translation Some IVA fixes Increased skin max temp of LT-POD legs to 2800K, increased emissive constant to 0.9 Added RPM support back to the mod Courtesy of Dragon01 Requires the installation of ASET Props and Raster Prop Monitor Quote Link to comment Share on other sites More sharing options...
Saltshaker Posted December 15, 2017 Share Posted December 15, 2017 1 hour ago, Nertea said: NF Spacecraft 0.7.5 Updated B9PartSwitch to 2.1.0 Updated NFProps to 0.2.1 Added Simplified Chinese translation Updates to Russian translation Some IVA fixes Increased skin max temp of LT-POD legs to 2800K, increased emissive constant to 0.9 Added RPM support back to the mod Courtesy of Dragon01 Requires the installation of ASET Props and Raster Prop Monitor Will any of the other NearFuture/your other mods have compatibility with ModuleManager 3.0.1? (or do they already and should I just re-download?) Quote Link to comment Share on other sites More sharing options...
Nertea Posted December 15, 2017 Author Share Posted December 15, 2017 20 minutes ago, Saltshaker said: Will any of the other NearFuture/your other mods have compatibility with ModuleManager 3.0.1? (or do they already and should I just re-download?) I'm not aware of any problems - report them if you find any. Quote Link to comment Share on other sites More sharing options...
maja Posted December 16, 2017 Share Posted December 16, 2017 8 hours ago, Saltshaker said: Will any of the other NearFuture/your other mods have compatibility with ModuleManager 3.0.1? (or do they already and should I just re-download?) I compared MM's dumps of applied changes for Near Future, MkVI system, Kerbal Atomics and Cryo Engines from MM 2.8.1 and 3.0.1 and there wasn't any difference. Quote Link to comment Share on other sites More sharing options...
WuphonsReach Posted December 16, 2017 Share Posted December 16, 2017 Looking at and thinking about the RPM screen on the NF capsules (I may have misspoke asking about a kOS RPM screen, that's something different). When piloting from IVA, I really like to have a physical navball, gauges for altitude, ascent/descent speed, plus indicator lights/buttons for lights/sas/rcs/brakes/gear/etc, and some MFD (glass cockpit) displays (up to six is always nice). Mk4 (7-kerbal capsule): With only one (slightly rectangular) screen for each of the two upper pilot seats, it could be done but is not ideal. I'd suggest killing off the array of twelve toggle switches to the outboard side of each main screen and putting in a smaller square screen in that space. Then a pair of MFDs (glass cockpit devices from RPM) could be placed in that area. Use of IndicatorPanelRPM along with buttons like JSIStockSquareButtonLight and JSIStockSquareButtonSAS around it (with the operation buttons in the same sequence as the indicator panel lights for ease of use) would be useful. That indicator panel could maybe go on the forward bulkhead, removing some of those toggle switches. The lower pilot seat for landing has a different layout. It does have IndicatorPanelRPM, but no JSIStockSquare buttons to be operated around it. The left-hand panel could possibly hold three MFDs (replacing the docking mode screen along with most of the buttons/switches). (Note, I'm looking at how BDDB does its RPM support. Mostly you need position/rotation values, and IDs on the things you want to remove.) PPD-1 HCM (6-kerbal capsule) Far closer to using MFDs, with three screens already within the pilot's view. The indicator lights on the right-hand side of the panel would be nicer if there were buttons arranged around it in the same pattern relating to functions like SAS/RCS/gear/etc. Mk3-9 OCP (2-kerbal capsule) Each seat has a large rectangular screen, plus a medium sized square screen location that could be used for MFDs. Could possibly even pack four MFDs into the area where the current main screen is located. The buttons between the indicator light panel in the center console could be changed to JSI buttons for operating RCS/SAS/etc. Quote Link to comment Share on other sites More sharing options...
Jimbodiah Posted December 17, 2017 Share Posted December 17, 2017 (edited) NFP meets TexturesUnlimited Edited December 17, 2017 by Jimbodiah Quote Link to comment Share on other sites More sharing options...
Sudragon Posted December 17, 2017 Share Posted December 17, 2017 (edited) On 17/12/2017 at 11:22 AM, Jimbodiah said: NFP meets TexturesUnlimited Oh my. Is this going to be a patch release? Separate set? Edited December 18, 2017 by Sudragon Quote Link to comment Share on other sites More sharing options...
Streetwind Posted December 18, 2017 Share Posted December 18, 2017 Yeah, how does that work? Are those wholly new textures to support PBR, or is that a shader preset config, or something else? I'm totally clueless about this stuff Quote Link to comment Share on other sites More sharing options...
WuphonsReach Posted December 18, 2017 Share Posted December 18, 2017 On 11/29/2017 at 4:51 PM, hab136 said: Me too. Ever since upgrading to 1.3.1 (from 1.1.3) my ISRUs have been overheating but still working, reaching 1500/1000 K, even on my one base without a reactor. After upgrading to NFE 0.9.8 today, reactors on bases with drills instantly meltdown on loading, showing temps like 41,000 K / 900 K. Reactors on orbital stations (no drills or ISRU) work fine. I reverted to NFE 0.9.7 so I can continue to play. Wonder if I use MKS PDUs to send power using the microwave link to the vessels with drill heads -- would that get around the meltdown issue? Quote Link to comment Share on other sites More sharing options...
Nergal8617 Posted December 18, 2017 Share Posted December 18, 2017 3 hours ago, WuphonsReach said: Wonder if I use MKS PDUs to send power using the microwave link to the vessels with drill heads -- would that get around the meltdown issue? As long as you have enough cooling for the reactor it should. MKS drills tend to use up a lot of cooling so separating them could be helpful, just make sure to have lots of battery available both on the reactor and on the drilling rig or you are going to end up starved for EC due to the way the power transfer works. Quote Link to comment Share on other sites More sharing options...
Nertea Posted December 19, 2017 Author Share Posted December 19, 2017 Meh, I'm trying to make some kind of balancing hack to work around this, but it's hard. I can force the reactors to take way too much capacity (bye bye drills) quite easily (eg, the state in 0.9.7) but I'm trying to find some kind of balance that will... restore balance. Quote Link to comment Share on other sites More sharing options...
Shadowmage Posted December 19, 2017 Share Posted December 19, 2017 On 12/18/2017 at 2:37 AM, Streetwind said: Yeah, how does that work? Are those wholly new textures to support PBR, or is that a shader preset config, or something else? I'm totally clueless about this stuff I believe what @Jimbodiah posted is simply a config file (module-manager patch) that works with TU plugin and shaders to set the part models to use PBR shaders while still using the current textures (use existing diffuse and specular values, set metallic value through config file). On 12/17/2017 at 2:47 AM, Sudragon said: Is this going to be a patch release? Separate set? Likely will be available 'soon' through the TexturesUnlimited thread/repository as a stand-alone 'mod-integrations' set of patches/configs. Still working out the details on how to distribute/release them all. To be clear -- none of this work was done or endorsed by @Nertea, so please don't bug him about it; it was done by another forum user at his own volition ( @Jimbodiah ). Future discussion of it should likely be taken to the TexturesUnlimited thread so as to not further derail or clutter the NF threads. Feel free to post questions/support stuff there. Quote Link to comment Share on other sites More sharing options...
Nertea Posted December 19, 2017 Author Share Posted December 19, 2017 (edited) Yes @Shadowmage is exactly right. Though I would like to support TU at some point, the collection of mods contains something like 900 textures. Assuming about half of these are support files (emissives, normal maps), that leaves about 450 textures that would need to be restructured to create proper PBR versions of the context. That's a hideously large amount of work, and it's a project that I wouldn't want to half-ass just by creating metallic masks for things. Edited December 19, 2017 by Nertea Quote Link to comment Share on other sites More sharing options...
Jimbodiah Posted December 20, 2017 Share Posted December 20, 2017 (edited) Hah, chill. It was just a user-made (me) patch using TU to get the metal finish and make it look nicer. No doubt more modders will eventually use TU or, god help, KSP adds this themselves. RIght now it's just easy to do, so people like @Electrocutor have already started making patches for stock parts, and since I use NF mods in all my saves ofcourse HAD to do it for my NF mods Just showing off, nothing implied, and don't bug Nertea about it. Edited December 20, 2017 by Jimbodiah Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.