Starwaster

Members
  • Content count

    7826
  • Joined

  • Last visited

Community Reputation

2262 Excellent

4 Followers

About Starwaster

Recent Profile Visitors

4577 profile views
  1. @MacLuky Don't do anything that will result in float values for part cost. (not sure about entryCost, that might also be bad, I forget) cost has to be an integer. If the part loader tries to parse a float when it expects an integer it will throw exceptions and smash the parts list in the VAB. You will have missing parts.
  2. @Pappystein First part of that patch: That MATERIAL node isn't going to do any good sitting there by itself in a PART node Second, you've got a bunch of #$/../ scattered around. You MIGHT get lucky and have that work, I honestly don't know how Module Manager will interpret it but basically what you're saying is start at the root level and then go UP. (or UP twice in some cases). MM might just interpret going up from root to be the same as staying in the root level but frankly it's a logical impossibility and if the logic ever gets rewritten to be more strict then your patch will suddenly stop working and the cause won't be immediately apparent. You're better off just saying #$/mass$ or #$/MODULE[modulename]/stuff$ and those will always work.
  3. Deadly Reentry isn't doing any IB specific patching so any patching done to it would be from the same generic patching that all parts get. And it would be getting done at runtime except for a very brief period when I temporarily switched to doing config based. (but again, as part of a blanket patch. So if there were a problem of the nature he describes then it would be every part and it would be so widespread that someone would have reported it long ago)
  4. Why not just snap the existing RTG in place? Do you need a FUR themed one? What would that look like and why? An RTG is an RTG... Its most likely configuration is going to be cylindrical with radiator fins... a Stirling version might appear different or might not.
  5. The insulation value seen in the part description info isn't really right either because it's using the old skin-internal factor and I switched over to using heatConductivity which affects ALL heat conduction including skin-internal. That's how RF determines what kinds of insulation it has and how to handle the conduction and boiloff. The changes went into each mod simultaneously except that the heat pump part info code didn't get updated (it's kind of tricky because it still has the capacity to change BOTH conduction fields) and the part configs didn't change from their test configs. I updated the config files in the repository. The patch file StockRadiatorDuplication.cfg goes in the MM_Configs folder and the other in the Parts/zzz_radiator.SWHP folder (just right click and save links as) https://raw.githubusercontent.com/Starwaster/HeatPump/master/GameData/000_HeatPump/MM_Configs/StockRadiatorDuplication.cfg https://raw.githubusercontent.com/Starwaster/HeatPump/master/GameData/000_HeatPump/Parts/zzz_radiator.SWHP/part.cfg You may notice the configs have a commented out RO line - just ignore that for now. It'll matter later when I fix the electric cost which is too low
  6. Doesn't matter; I see what the problem was. The radiator files that went into production are the wrong ones... they were basically a control version to test radiator performance without insulation (well it does matter; you may need your output_log.txt file some day: it's in KSP_x64_Data or KSP_Data depending on if you're in 64 bit mode or not - unless you're using Linux or Mac. Then it's player.log)
  7. Probably better do the log file too. And a probable cause of your Alt+F12 issue is some nvidia thing binding to those keys. Someone posted about that previously... the fix was to rebind them but I forget which nvidia thing was doing it. I think the workaround was pressing Shift+Alt+F12 or Cntrl+Alt+F12
  8. @wb99999999 Ok let's take a look at your ModuleManager.ConfigCache file. Please put that somewhere I can download it And where is all that other thermal data coming from? I don't recognize that
  9. You need to enable boiloff debugging too. Make a patch file (cfg file, name it something like enableboiloffdebugging.cfg) and paste the following into it: @RFSETTINGS { %debugBoilOff = True } That will give you some additional information on boiloff in the tank's action menu: wall temperature (THIS is temperature being used in the boiloff equation. It has to be higher than the resource being boiled) heat penetration (how much heat flux actually being applied to the resource by RF boiloff code) boiloff loss (how much mass is being lost as a result of RF boiloff code) For RF to be responsible for boiloff then all of the following have to be true The wall temperature has to be higher than the resources boiling temperature A value representing heat penetration has to be present. If condition 1 is false then heat penetration will be BLANK boiloff loss has to have a value. If condition 1 is false then this value will be BLANK
  10. If internal temp is at 19K then it's not possible that RF is applying boiloff. I had to go refresh my memory as to how things were working and basically, mounting a Heat Pump part on a tank part forces it to use the internal temp if it wasn't already doing so before. The only other way that I can see this happening is through analytic mode (high time warp, i.e. over 100x) which you didn't say was when this was happening, but it would still only be possible for RF to apply boiloff if internal temp were higher than 20.15K. So, analytic mode or not, if it's at 19K then RF can't apply boiloff. (or in the case of LOX, 90K)
  11. It can use either depending on whether the RF tank is a cryogenic type or not. Default tanks use the skin and Cryogenic tanks use the internal. Using the internal temperature allows for the simulation of multiple conduction zones, with the skin then becoming the MLI layers and the internal being the tank or spray on insulation layers. Cooling then gets applied in between those layers. The actual deciding factor is whether or not the tank part has a different skin-internal conduction factor from the default values with the boiloff equations and cooling equations using either skin or internal as appropriate. If you're still getting boiloff then you probably have some third party mod applying its own boiloff. There are at least two other mods that have their own proprietary boiloff schemes and neither of them look at the actual temperature of the part so neither of them would benefit from Heat Pump (or even stock radiator) and have their own 'cooling' scheme to negate boiloff. If you have RF installed then you should disable any third party boiloff since there's nothing I can do to mitigate that. I will leave open the possibility that Heat Pump isn't properly compensating for parts using the skin temperature and investigate that to make sure it's working as it should. AFAIK though that part does work properly on HP side
  12. The gimbal issue has been discussed before; not sure if in this thread or not. This thread is pretty defunct as developer is absent. I've taken responsibility for maintenance and bug fixes for which I created a thread (below) and I have done some work on the gimbal issue. (deleted previous quick fix) As a temporary measure, download this: (right click the link and select save link as) https://raw.githubusercontent.com/Starwaster/ProceduralParts/master/GameData/ProceduralParts/Parts/ZOtherMods/RFSRB.cfg And copy it over the existing file in GameData/ProceduralParts/Parts/ZOtherMods/RFSRB.cfg That will patch all Procedural SRB parts both RF and non-RF versions.
  13. Yeah probably, and I've done some preliminary changes that would help facilitate such a thing. Basically it would be the base or root of the nozzle. Currently nozzles/bells are single meshes and for reasons that I am *still* not entirely clear on are the source of the current issue where gimbals don't properly work on both axes. What I've found is that if the hierarchy is changed to some sort of root->gimbal->bell->thrust transform then it works. (currently it's just bell->thrust transform with the bell also doubling as the gimbal) So if I change things to a multi mesh/transform model then it works properly and the root could actually be some sort of skirt mesh. The downside is that it requires some code changes so that things scale/translate properly. (there is a cheaper easier way out which was to use the thrust transform as the gimbal so I've been waffling as to whether to go through with the other changes)
  14. @Jim DiGriz Would you be willing to share a scan of that document?
  15. Yes but you can't copy and paste them onto an adjacent computer / tablet.... (I should know, I tried once in a moment of stupefaction wherein it seemed logical to me that I should have been able to do so... I sat there for several seconds looking from one to the other wondering why it wasn't possible yet)