Jump to content

etmoonshade

Members
  • Posts

    425
  • Joined

  • Last visited

Everything posted by etmoonshade

  1. I'm curious to see if you verified this. Also, the experiments seem to register the biome you finish them over, not the one you start them over - something else to keep in mind. I had to either learn or re-learn that today. @linuxgurugamer - Minor bug - the "internal" storage for the SkyLab is still set to 200 seeds/20 rocketparts/20 clipboards. Presumably it should be 20/20/20 since you put the density of seeds in line with the other two resources..
  2. In the file under Filter Extensions Default Configs, zzz_RemoteTechAddMissingModuleSPUPassive.cfg, there are the following lines: PARTUPGRADE { name = GD_RT_unmannedTech partIcon = GD.RT.unmannedTech techRequired = unmannedTech entryCost = 2000 cost = 0 // for display only; all parts implementing this will need a PartStatsUpgradeModule with cost = this. title = RT: probe cores remote control basicInfo = #autoLOC_501093 //#autoLOC_501093 = Warning: May contain traces of sentience. manufacturer = #autoLOC_501664 //#autoLOC_501664 = Experimental Engineering Group description = Probe cores are now remote controllable } PARTUPGRADE { name = GD_RT_advUnmanned partIcon = GD.RT.advUnmanned techRequired = advUnmanned entryCost = 4000 cost = 0 // for display only; all parts implementing this will need a PartStatsUpgradeModule with cost = this. title = RT: crew pods remote control basicInfo = #autoLOC_501119 //#autoLOC_501119 = Improvements in remote control technology for a new generation of probe designs. manufacturer = #autoLOC_501667 //#autoLOC_501667 = Integrated Integrals description = Crewable pods are now remote controllable (for unmanned testing) } PART { name = GD_RT_unmannedTech module = Part author = Gordon Dry (used under permission of Allis Tauri) RSSROConfig = true MODEL { model = zFinal_FilterExtensions/RT_Mod/RT_pod_up } TechRequired = HIDDEN entryCost = 2000 cost = 0 mass = 0 category = -1 subcategory = 0 PhysicsSignificance = 0 bulkheadProfiles = srf manufacturer = #autoLOC_501664 //#autoLOC_501664 = Experimental Engineering Group title = RT: probe cores remote control description = Probe cores are now remote controllable } PART { name = GD_RT_advUnmanned module = Part author = Gordon Dry (used under permission of Allis Tauri) RSSROConfig = true MODEL { model = zFinal_FilterExtensions/RT_Mod/RT_pod_up } TechRequired = HIDDEN entryCost = 4000 cost = 0 mass = 0 category = -1 subcategory = 0 PhysicsSignificance = 0 bulkheadProfiles = srf manufacturer = #autoLOC_501667 //#autoLOC_501667 = Integrated Integrals title = RT: crew pods remote control description = Crewable pods are now remote controllable (for unmanned testing) } This is causing the part upgrades to appear even when I don't have RemoteTech installed. I don't think it's precisely a bug (although I found it because I was looking into a bug of some flavor,) but it's definitely strange.
  3. Oddly, I'm starting to think that you can't do this faster with rockets anyway, at least not within the remaining parameters of the challenge. Tsiolkovsky is a harsh master, and I think that (again, with stock parts) you won't be able to build something rocket-powered that simultaneously has enough dV to thrust continually through a full orbit, enough TWR to actually accelerate at any decent speed, and enough wing area to even get off the ground in the first place. Even TweakScale being allowed would probably let me do it, since the biggest problem I'm having is that there aren't any decent Mk3 engines in stock. Of course, stock aero being crap means that you can't really do the coasting thing that the video shows... But yeah, I'm well aware of the formal challenge limitations. I just wanted to see if changing that particular parameter would let me do something similar to the old KSC to ASI runs, as far as flight profile goes. Maybe I'll fiddle a bit and see about posting a challenge for between KSC and Dessert Airfield...
  4. Oddly, I'm finding a speed challenge WITH rockets to be rather difficult as well - I'm basically trying to follow the example in the video I posted, but the rockets available have horribly low Isp so the fuel requirements are disgustingly high. It also doesn't help that stock aero is kinda crap, but I need to get a good long burn first before I worry about that. Of course, it's kind of mutated into something that technically fits the challenge parameters as given, so we'll see. :V
  5. I have yet to finish my own entry for this (I'm trying for speed as well - I find that making a plane that can circumnavigate is relatively easy...) but this whole thing reminds me of the old KSC -> Wideawake runs in my old Orbiter days (not my video, but I ran this run many many times...): If only we could use rockets...
  6. I imagine you could look at the parts for Global Construction and figure out the format to add those workshops/etc. to the existing ones for KPBS. With that said, you'd probably get more traction (and better answers) over on the Global Construction thread.
  7. Yeah, WasteHeat being on there tells me that KSPI-E is mucking around with it somehow. Of course, power in MW in there tells me that KSPI-E is mucking around with it too If you take a look in WarpPlugin\Patches... ... oh, that is terrible practice. @FreeThinker - you really need to move this to the patches directory. :wtc: So. In \WarpPlugin\Parts\Engines\IonEngine, you'll find a PATCH. That patch is what changes the stock ion engine. Edit: I suspect that the following line from KSPI-E 1.25.22.5 is what prevented this from hitting you up until now: @PART[ionEngine]:AFTER[RealismOverhaul] This essentially means "NEEDS[RealismOverhaul]" in MM terms, so it wouldn't apply the patch unless RealismOverhaul was installed. This changed as of 1.25.23 to: @PART[ionEngine]:NEEDS[!RealismOverhaul] Which means that it will apply the patch if RealismOverhaul is NOT installed. My guess is that when you started playing again, you hit the update button on CKAN.
  8. Did you hand-remove the patches before? There are a couple of patches (for ions, but also NFT) that change things in unexpected ways. An update (especially via CKAN) re-adds these patches, much to my continual annoyance.
  9. Does Scatterer have some sort of cache it keeps around? That might cause issues between upgrades, and would explain why the problem disappeared when you reinstalled (presumably ONLY) Scatterer.
  10. I think it's because ModularFlightIntegrator gets compiled with each new version? Okay, maybe I assume that's why. I don't even know what MFI does, but I know the install instructions say to delete the Kopernicus and ModularFlightIntegrator folders before any update.
  11. Oh-ho. Okay, I see how you dealt with truncating the values now. I guess that means nobody needs to answer me in the MM thread now. Yours is certainly more elegant. Is there a particular reason you bring in both Resize and Rescale though? And, for that matter, any insight into the actual exponent? Based on some fiddling I did last night, a cube root multiplier is actually way closer to the truth than a square root multiplier. On 10.625x, I get ~12k for launch dV with a square root, but ~8.3k with a cube root. I ended up getting the following actual values: Body Calculated dV (^0.333) Real dV Kerbin 8354 8450 Mun 10926 11394 Minmus 11498 12121 The big issue is that I haven't tried this with other rescales, but a cube root being SO close makes me think that the post referred to is mistaken somehow.
  12. @severedsolo = And hey, here we go: @WHERE_CAN_I_GO:NEEDS[SigDim2&RESCALE]:LAST[WhereCanIGo] // Needs to be LAST, in case of other planet packs that don't have an inherent rescale, e.g. OPM { @notes = Automatically Generated Rescale @warning = Note - these values may be grossly inaccurate. dvScaleMult = #$@SigmaDimensions/Resize$ @dvScaleMult != 0.5 @BODY,* // This edits all "BODY" entries. { @flybyDV *= #$../dvScaleMult$ //-1 indicates that the task is impossible and will display "N/A" in the UI. @orbitDV *= #$../dvScaleMult$ //Figures should always include DV to get to orbit of the homeworld. (mod will handle removing those itself when needed) @synchronousDV *= #$../dvScaleMult$ //this will replace landDV in the UI if used. Probably only want to use this for the homeworld @landDV *= #$../dvScaleMult$ @returnFromFlybyDV *= #$../dvScaleMult$ //return figures are for the return trip only. They will be added to the figures provided in the previous stage. @returnFromOrbitDV *= #$../dvScaleMult$ @returnFromLandingDV *= #$../dvScaleMult$ } } Only problem I have is the following: https://www.dropbox.com/s/8px537ucaiwsrgq/WCIGBaddvReadings.png?dl=0 Basically, all of my Delta-V values are equivalent to my craft's dV, and none of the values from the config seem to be read. A snip of the modified config after MM gets done with it looks like this - it's definitely inserting the values as expected: UrlConfig { parentUrl = WhereCanIGo/WhereCanIGo.cfg WHERE_CAN_I_GO { notes = Automatically Generated Rescale warning = Note - these values may be grossly inaccurate. colorIfYes = green colorIfMarginal = yellow colorIfNo = magenta dvScaleMult = 3.25960120260132 BODY { name = Kerbin flybyDV = -3.25960120260132 orbitDV = 12386.484569885 synchronousDV = 16020.9399107855 landDV = -3.25960120260132 returnFromFlybyDV = -3.25960120260132 returnFromOrbitDV = 325.960120260132 returnFromLandingDV = -3.25960120260132 requireChutes = true } BODY { name = Mun flybyDV = 15189.7416041222 orbitDV = 16200.2179769286 landDV = 18090.7866744373 returnFromFlybyDV = 0 returnFromOrbitDV = 1010.47637280641 returnFromLandingDV = 2901.04507031518 requireChutes = false } BODY { name = Minmus flybyDV = 16526.1780971887 orbitDV = 17047.7142896049 landDV = 17634.4425060731 returnFromFlybyDV = 0 returnFromOrbitDV = 521.536192416211 returnFromLandingDV = 1108.26440888445 requireChutes = false } Based on some experimentation, it looks like it REALLY doesn't like the long decimals, and that's what causes it to go wonky - making a patch manually from the MM cache, truncating the values, and applying that instead makes it work as expected. So consider that a bug report. With ALL that said... the dV values are WAY too high. Multiplying by the square root of the rescale seems to give values about 2000-3000m/s above what I'd expect. This patch may not be viable after all. I'll do a bit of poking around and see if I can find something more reliable - I'm sure it's something that RESCALE! is doing that I'm not taking into account in some way, shape, or form (or maybe it just needs to be 10.625x minus 1 before I square root it... hmmm) Also, this needs to go in the OP.
  13. I swear, I need to start just waiting 2 minutes instead of editing my posts when dealing with you. :V I'll make sure to complain next time you release a BE release. It is a problem I've had in CKAN before though, even when just upgrading something. I haven't managed to pin down a cause though, so I haven't submitted a log report yet - the logs that CKAN has seem to be fairly sparse as far as reporting what went wrong. >_<
  14. Seems to be working - no NyanCats yet. That was quick - thanks! Edit: Although I'll note that I had to uninstall everything Kopernicus-related first before it'd let me install the BE repo you provided - it wouldn't let me "swap them in place" so to speak.
  15. So, yet another question about "can I do this with MM?" :V I'm looking to do two things: - Set a value to -1 if it's -1 or smaller. Essentially, I need to put a conditional on a key. - Modify multiple nodes under a main node, like so: @MODNODE { @stuff = things @SUBNODE[*] { @things = stuff } } From digging through the MM docs, there doesn't seem to be an obvious way to modify multiple SUBNODE entries in the same way. Is there a non-obvious way? It's mentioned as a feature that's planned, but there aren't any actual examples that point to it being doable. Edit: Okay, I dug through the MM test cases and found that @SUBNODE,* edits all subnodes with that value. Maybe I'll add that into the handbook or wiki. I have now added this to the wiki. I think the answer to the first question, if it's possible, would point towards a solution to the problem I have now - I don't think the negative values will hurt me, but I need to truncate the values down to integers. To be fair, it's probably easier for that to be fixed in the target mod for the patch - but I'm still curious if there's a way to put a conditional on a key anyway.
  16. If this holds true, it should be fairly easy to make a "universal" MM patch for simple rescales (e.g. Sigma Dimensions + RESCALE! mods) I'ma take a crack at this - this looks like a cool mod, but it's currently useless to me since I run 10.625x myself.
  17. Also out of curiosity, would it be possible to CKAN the BE releases? I had to jump through some mildly weird hoops to install anything with a Kopernicus dependency through CKAN in the first place (install Kopernicus 1.9.1, delete directories, install BE in its place,) and while I don't mind manual installation, it is annoying to see that "pending update" checkbox for Kopernicus, tempting me to break things. I'm pretty sure there's some sort of way to do this (that, or MechJeb-DEV has some sort of special handling,) but I couldn't actually tell you how.
  18. I'd suggest checking out the one of the Structural Tubes - I know they specifically aren't (and can't be) affected by TweakScale currently, unless you've installed one of the dev releases. See this screenshot: https://www.dropbox.com/s/78b7jhtl2kjhlrd/screenshot0.png?dl=0 If that shows up in KRnD, I presume there's some sort of gunk that TweakScale left behind that is causing it not to detect other parts. If it doesn't, it very well may be a bug in KRnD, or an install issue. In either case, a log would probably help. Also in either case, testing on a clean install may help, even if it's a pain in the rear.
  19. I think someone just needed an excuse to sell some new textbooks.
  20. Part of allista's mods (Hangar, GC, Configurable Containers, etc.) actually. USI is RoverDude.
  21. Based on the fiddling I did before, it appears that all the experiments are biome-sensitive for whatever reason. Even if it doesn't say so on the science window. :V Did you try running the experiments over the same biome twice? I suggest the poles for a test. Figuring this out really messed with my head, since it certainly doesn't look like the science is biome-sensitive in the results window.
  22. Nope, low priority - it prevents any more bugs*! * from being reported
  23. This is actually really neat, and FWIW, seems to be working well in 1.10.1. For those of us who have neither a dev environment nor coding ability, would it be possible to release something that allows for a simple .cfg that outputs various flight stats in text form? I'm thinking mostly of the orbit view, but without the actual orbit shown - ApA, PeA, orbital speed, maybe current biome/situation - just to name a few. What I REALLY need is just an external MechJeb display...
  24. Bug that intermittently affects the entire point of the game? pfft low severity bring more dv noob What's a critical? Code stabs your cat and then sets your computer on fire?
×
×
  • Create New...