Jump to content

MaxRebo

Members
 View Profile  See their activity

  • Posts

    203

  • Joined

  • Last visited

 Content Type 

Everything posted by MaxRebo

  1. MaxRebo
    You can do exactly that. In fact, I've been playing with it for 2 days now. So far I experienced nothing out of the ordinary to report though. In other words, it seems to be extremely stable already.
  2. MaxRebo
    @FunnelVortex Still, saying DRE is unrealistic is quite the provocative statement in hindsight. Let's take shared responsibility
  3. MaxRebo
    Seeing as no one quoted or mentioned you, I figured I'd do it instead and refer you to the two answers above (I missed plenty replies like that myself). For further understanding it helps to remind yourself that Kerbin has much much lower mass than Earth (1/113th it was I think - would be easy enough to calculate from its gravitational parameter). Gravity as you put it is merely a function of how far away from the center you are. I refrained from posting some math earlier in the discussion because I didn't want to derail the thread any further and (IMO) sufficient informal answers had been given - it seems that backfired. Sorry for starting this ferram and anyone monitoring this topic for FAR updates...
  4. MaxRebo
    No one was disputing that
  5. MaxRebo
    @msnbcorp The thing about Deadly Reentry is that it's not realistic. It scales up reentry effects to ridiculous magnitudes so that the experience is similar to what you would get if Kerbin were Earth sized. IRL a mere 2k m/s don't result in the amounts of plasma being created that would actually ablate a heat shield. IMO stock hits a good middle ground here (I wish they would have just made Kerbin Earth-sized in the first place though).
  6. MaxRebo
    You convinced me, I'm not going to go around telling people to prune stuff anymore. Not without a disclaimer that they probably shouldn't follow my advice anyway
  7. MaxRebo
    @scorpianz1525 Not really difficult, no. But extremely tedious if for some reason or another you can't use the newest version of Visual Studio. I wish more mods would use a GNU-style build system - and I say this as an almost exclusively Windows user... I for one am going to wait If you never used Visual Studio before than that most likely also means that there is nothing stopping you from using it, so just go grab the most recent version of VS Community and give it a go. In many cases it's as simple as double-clicking the solution file (.sln) and hitting Ctrl+Shif+B.
  8. MaxRebo
    I've been wondering about that actually. Do assets become invisible when they're never referenced in a config node? Or is Unity registering everything it finds lying around in the folders KSP tells it to look in for stuff? If a mod just references stock assets in its cfg it shouldn't be a problem either way since then they are referenced in a config node. But it might make a difference if you're pruning mainly to save on memory - in that case MM patches wouldn't do any good and you'd have to start renaming file extensions of stuff. It's something I wanted to investigate but never got around to... The only instance I can think of where MM prunes might be an issue is when mods want to make a modified copy of a stock part (say, a CLS-enabled fuel tank). But that a) can be easily worked around by making the prune :FINAL and b) they kind of inherit the undesirability of their parent part... but I certainly do acknowledge after all this talking about it that it's not something you should carelessly advice unsavvy players to do.
  9. MaxRebo
    Why do you even want it? Just place the AR202 part that comes with MJ in your plane's cargobay or something. That's what I did when I was still using MechJeb (kOS is the far superior autopilot mod gameplay-wise)
  10. MaxRebo
    @Wolf BaginskiI'm not entirely sure what you're trying to tell me here. I want the stock tanks gone (and most non-aircraft fuel tanks from all other mods for that matter) because I don't want parts that I never intent to use clutter up the tech tree and part catalog, for reasons of usability and immersion. None of textures or other assets disappear from the game so I don't see where there can possibly be a problem. Not that I've ever seen a mod reusing the - sorry for being blunt - butt-ugly stock tank textures... (also I'm a MSc in computer science specializing in CG and visualization so I'm pretty familiar with uv mapping...)
  11. MaxRebo
    ^ exactly.
  12. MaxRebo
    What exactly is supposed to happen if you do? I've been pruning stock tanks in favor of procedurals for some time now and I've yet to experience any negative side effects...
  13. MaxRebo
    (1) It always has a public dev "build", it's called its github repository. Since the B9 part pack itself doesn't come with any plugins, the sources are all cfg files, i.e. directly usable in KSP without any compilation. However, the two part modules used by B9 (B9PartSwitch, B9AnimationModules) have their own repository each, so for a complete dev version of B9 you have to get them from there and not from the B9Aerospace repo where the parts are. Fortunately, @blowfish is kind enough have git track the build artifacts along with the source code, so you'll always have up-to-date plugin dlls for every new commit, even when no development "release" has been published. (2) Take a look here
  14. MaxRebo
    @Benji13 I just realized it's not entirely functionally equivalent. B9's Mk2 cockpits are all 1-seaters. Depending on your mileage that might be an issue.
  15. MaxRebo
    B9 provides a full set of functionally equivalent parts (to stock Mk2) - right down to their cross section. So you could just prune all stock Mk2 parts from your install and use B9 as their replacement if that's what you want. You could do that by renaming all stock Mk2 .cfg files to .bak files (I advice against it), or write a small MM patch (the preferred way) that does something like this -PART[mk2Cockpit_Inline]:AFTER[Squad] { } -PART[mk2Cockpit_Standard]:AFTER[Squad] { } -PART[mk2DroneCore]:AFTER[Squad] { } -PART[mk2_1m_Bicoupler]:AFTER[Squad] { } -PART[mk2_1m_AdapterLong]:AFTER[Squad] { } -PART[mk2SpacePlaneAdapter]:AFTER[Squad] { } -PART[mk2Fuselage]:AFTER[Squad] { } -PART[mk2FuselageLongLFO]:AFTER[Squad] { } -PART[mk2FuselageShortLiquid]:AFTER[Squad] { } -PART[mk2FuselageShortLFO]:AFTER[Squad] { } -PART[mk2FuselageShortMono]:AFTER[Squad] { } This is such a small thing that it's not worth maintaining a mod for IMO.
  16. MaxRebo
    It's a close one between FAR and Principia. As usual with physics simulations, the underlying math is almost guaranteed to be differential equations. In practice, this means that there's most likely lots of numerical integration over t going on. Lots and lots and lots of numerical integration over t.
  17. MaxRebo
    We're closer than you think. Theoretical computer science is already closing in on that (symbolic execution, deviant behavior, etc), with a few practical implementations already yielding impressive results. The tools are there, they're just not in widespread use, especially not in the gaming industry. I think it's very likely that in the not so distant future, programs will bootstrap themselves away from human fallibility. And it won't even need explicit AGI for that to happen (but then again, what exactly is sentience? Consciousness might after all just be an emergent phenomenon that just happens once system complexity / intraconnectivity reaches some order of magnitude...) /topic It seems B9AnimationModules has received a non-dev 1.2 update a few hours ago. "Official" B9 (pre-)release might be just around the corner.
  18. MaxRebo
    In other words, none. Many modders don't push their commits to github (not even to dev branches) until they've mostly completed whatever they were currently working on, so its use for tracking progress is rather limited.
  19. MaxRebo
    Make it a Tweakable? Anyway, great work so far. I hope it won't take AKI Surface Experiment Pack too long to hop onto the bandwagon - it looks like this has the potential to vastly improve the extremely wonky physics of that mod's connectors...
  20. MaxRebo
    Is there a way to set ISP and max thrust of procedural SRBs according to tech level like TECHLIMIT nodes do for dimensions and tank volume? I want to replace as many non-procedural parts as possible/sensible for my next career playthrough, but the procedural SRBs are waaaay too OP early on. I guess one could consider the silly visuals of having a giant engine bell on a tiny tank to be a quasi-limit on thrust, but that still leaves ISP. I can just move the initial part unlock way high up the tech tree (and retain the various non-procedural SRBs up to that point), but I'd rather not do that if it can be helped...
  21. MaxRebo
    Only thing this does is to allow changes made to the TechTree config node and its RDNode children via ModuleManager to take precedence over the last-minute override by Yonge Tech Tree. As you quoted correctly yourself: ETT makes use of specifically those additions (specifically, the Unlocks node). Disabling this options will do nothing to make the actual unlocks editable via Module Manager - it will enable Module Manager to edit all other aspects of the tree but the actual unlocks, if only because the Unlocks node is laid out in a way that Module Manager can't alter by way of the nature of its principle of operation. If we started specifying the unlocks the classical way (i.e. on a per-part basis), then we wouldn't even need to disable this feature in order to enable MM patches for the unlocks, as those are actually independent of the TechTree config node's final form, even if this form was the result of Yonge Tech Tree doing its magic. It would however be necessary to disable it if users should be able to alter the structure of the tree via MM, that is tech node names, costs, positions and connections. Though it would probably be sensible to disable this feature anyway - per-part MM patches in all likelihood end up being incompatible with any tech tree other than the one they were intended for. ------ I am absolutely determined to create that tool. It won't be until December though The good news is that from the investigation I already did into the editor source code, I also found out that it would be trivial to build that capability into the editor directly. For example by adding an additional export button to the menu bar that reads "Save Tree (per-mod MM patches)" or something like that. I'll get back to you when I start working on this little project
  22. MaxRebo
    You most likely used it extensively without even realizing. That's how streamlined a feature it was... First thing you'll likely notice when it's gone next release is that repeat builds will take quite a bit longer, especially if you also made heavy use of StageRecovery. @magico13If it's not too much of a hassle, could you take another look at the stored-craft-disappearing-in-roof issue we discussed here (#124) way back when? Recovering to storage could reasonably cover at least the most common use case of the inventory. Only if it's not also broken in 1.2 of course. If it is... well just forget I asked
  23. MaxRebo
    Yeah, if I decided to go with "hard-coded" changes I'd definitely use the editor, but in the end manual is manual. I think I'll wait until at least the MKS and WBI support is up-to-date and decide then if I want to invest the work. Right now I'm half-tempted to write an un-Yonge tool for automatically generating "classical" MM patches from a Yonge tech tree. If only I had the time... oh well, maybe next year.
  24. MaxRebo
    Is there a way to alter the Unlocks block of an RDNode via ModuleManager? I'd have to make several dozen changes to make the tree even remotely reasonable for my sensibilities, but maintaining those as manual edits whenever there's an update to ETT seems completely unsustainable. The only way I know of to precisely select one of several duplicate values (like the many "part =" entries in an Unlocks block) for editing or removing is by specifying an index, which is just as unsustainable as not using MM at all. I guess it probably can't be done and in that case it'd be back to Community Tech Tree for me, but I figured I'd try asking anyway...
  25. MaxRebo
    You can't. It's basically just a recompile, and never worked (see the KCT dev thread). The current code base is fundamentally broken for KSP 1.2 and Magico will have to rewrite lots of it. I wouldn't expect a working version any time soon.
×
×
  • Create New...