jinks

This is probably the wrong topic, but since MKS contains the PDUs it's the only good place I can come up with. @RoverDude, several years ago (2014) in the Alcubierre Drive thread you alluded to *maybe* doing something with beamed power, has there ever come something of that? Right now the only option for beamed power in KSP is KSPi, which comes with a lot of baggage. I'm looking for something simpler and "more Kerbal". All I want is a reason to dump some solar satellites in a low orbit and have them them be useful. So, just as an open-ended question, how hard would it be to slap together the PDU code with the CommNet relay/LOS features of stock and have a *simple* beamed power system that can move EC from near Kerbol to my drones near Eeloo? Is this something that fits with USI suite, or should I rather pose that question towards @Nertea and his Near Future line of mods? (I kinda feel guilty throwing just another mod idea your way, so don't feel obligated to even think about it. )

Nah, I'm good. Just making sure I'm not mission something obvious. I'll inform HR to act accordingly. Time to do some field testing... I's a bit vague, but sure. Edit: #1362

I'm still trying to wrap my head around the whole Logistics process... There's a few questions that have come up: It seems I need to include a "dummy" logistics part on an unmanned miner in order to make it interact with PL. So far I've seen the MPU (expensive, light) and the Duna and Tundra logistics parts (heavy, Duna's cheaper) work for this. Are there any other parts to tie in a remote miner to the PL system? Do Quartermasters have the same range extension feature as pilots, or do they fulfil only other logistics duties? "Remote" power: The microwave transceiver only lists a range on the sending side. Do I need a microwave transceiver on the power rig and a normal PDU on the receivers or do I need microwave on both ends? I'm definitely having a blast planning out my first outpost and trying to make it fully self-sustaining. Bases actually having a purpose is so much more fun. Also, something of a bug/inconveniece that has been mentioned before, but nothing came of it: If I try to use one of the switchable miners there are several large pauses involved. Once when picking the part from the list, once when attaching it to a ship (pause increases for more symmetry parts) and once when clicking deploy in the field (not on start drilling, though). KSP just freezes for about 20 seconds and one CPU core gets pegged at 100%. The pause seems to be a bit shorter on the MEU-100 vs the MEU-500 and strip miners. I can reproduce the problem with only the USI suite and CRP present on a test install. My best guess by observation is hat "something" gets thrown into a serious loop when trying to enumerate all those drills. There is absolutely nothing at that point in either the KSP.log or Player.log.

I think I have an incompatibility to report. FuseBox does not recognize any solar panel power generation (in the VAB/SPH) at all, and I'm reasonably certain that the culprit is Kopernicus. I have Kopernicus installed as a dependecy of another (biome) mod. Now, Kopernicus has the ability to add additional suns to the game, and to that effect it overrides every solar panel with its own module which AmpYear reports as KopernicusSolarPanel, to (presumably) set the tracking to the correct sun. -- FuseBox power generation info works fine in flight, it's solely an editor issue. EDIT: Ugh, should have checked Github first. There's already a PR. - Now to set up a dev env for the dozens of dependencies... Also, while I'm here, a feature request: Could you add a "Blind Load" feature to FuseBox? Something with a slider and/or edit box where we can set a manual value for modules that FuseBox does not recognize. Maybe also a "Blind Generation" feature for the opposite. Or just allow negative load numbers.

You can safely get rid of TreeLoader, it's abandoned software and TechManager is currently (0.90) the only tech tree manager that actually works. FreeThinker's KSPI Extended is properly integrated with the Communty Tech Tree (CTT), which is probably the one you should use if you want to have a lot of mods play together properly.

Looking through the configs for 0.7.18, just so I get this straight: If I have only KSPI, I get no WarpDrive at all any more. (Since it can't load the USI models defined in the new part.cfgs) If I have KSPI and USI WarpDrive and not NFT-E, I get the KSPI WarDrive but not the USI WarpDrive. If I have KSPI and USI WarpDrive and NFT-E, I get both WarpDrives but with wildly different requirements (GW vs EC) (assuming CTT as TechTree of course.) Correct?

Interesting, now I'm thoroughly confused. This seems to contradict what the code says. Does altitude play a role? My B9 sabre overheats at roughly 20km up and 1200-1500 m/s with a similar configuration, but I'm generally not a plane person so this might be for entirely different reasons. (Does FAR affect these things? Thinner air? Faster terminal velocity?) Edit: I replicated your "plane" configuration (used a MK2 Particle Bed reactor), and it reliably overheats at roughly 1350m/s. What am I doing wrong?

That's what it does in ModuleSabreHeating, but have a look at that little prc.isFunctional(). That part is defined in FNModulePreecooler.cs in OnStart() and yes, it still only works for stack-attached intakes.

Quick question since I'm feeling in a plane-y mood: What's the current deal with air precoolers? Last time I checked (which was probably around 0.23) precoolers checked only their attach nodes for intakes which severely limited plane construction and made radial intakes utterly useless. This behaviour was hardcoded in the plugin. Is this still the case? Also which parts are actually recognized as precoolers? Northstar, a few pages back you mentioned some new ISRU processed you'd like to add but can't because the KSPI ISRU stuff is all plugin code. Can those processes be added via REGO converter modules? Regolith might not (yet) be capable enough to handle the finer details of resource extraction you need, but conversion is usually based on fixed ratios which it handles just fine (it even handles catalysts in the sense that they need to be present with a certain amount but are not consumed). Using Regolith for conversion processes where possible (maybe even switching over some already existing ones) increases compatibility with other mods, gets rid of custom code and is a lot easier to manage than the current ISRU modules (all you need is simple MM configs). Does this include Boris' KSPI-Fix?

Interesting... I didn't think that you could even get OpenGL this wrong, it's lot like transparency is some hardly understood new development. Way to go Unity/nVidia Since there's loads of other transparent things that work just fine in KSP I'm quite sure that it can be worked around - at least it's way more likely to get Squad doing something about it than nVidia

It looked to me like the values you are going to implement would make gameplay without upscaled Kerbin so easy/boring that it wouldn't be worth the bother anymore. I can live with a higly powerful system that comes somewhat late in the tech tree, I can't live with something that turns the late game essentially into hyperedit with infinite fuel attached. As long as can't slap 10 parts in the VAB together and have a ship that can do 10 grand tours without thinking about it I'm fine. You said multiple times that you prefer to play with 6.4x scale Kerbin (which is one possible configuration of RSS) and with Real Fuels (which one of the few required mods for RO), I shorthanded that to "RSS/RO". While your own config may be more elaborate and fine-tuned than the "off-the-shelf" configs you're using the same building blocks. As long as it doesn't feel "cheaty" I'm quite fine with that. (And yes, I'm quite aware that where to draw the line to "cheaty" is a matter of taste.) I'm already playing with FAR, mostly because I wanted to stop myself from just sticking ridiculous contraptions on top of a few orange tanks and launch them into space. (As a side note, I'm not that happy about 1.0 stock fairings being procedural, I always liked the limitations of KW fairings.) RSS, even the 6.4x scale is just not my cup of tea. First it messes with terrain in a way that irks me aesthetically, second, in my mind it forces a huge increase in part count for no apparent "gain" and my PC is already taxed enough with my builds as it is. RF sounds actually quite interesting, but I'm a bit wary of the added complexity. Being able to play with fuel densitities and having to take fuel densities into account are 2 entirely different beasts. You're right, I mostly stick to the low-tech KSPI parts anyway because they are powerful enough for 80% of use-cases. KSPI has had quite a rocky history so far. When Fractal went away for the first time Wave took up the mantle wit KSPI-Lite which started out really well and with some nice improvements but then he threw out the baby with the bathwater by axing over half of the mod entirely. When I saw your efforts on KSPI-E I feared that you would go to the other extreme and "replace the bathwater with rocket fuel" in an effort to keep the baby warm so to speak. It would seem I panicked a bit and overreacted, sorry for that. Aside: The Regolith issue. A few pages back you said that Regolith can't entirely replace ORS/ORSX because it's missing some essential features. Have you actually talked with RoverDude about this? It seems to me that he intends Regolith to be a successor to and superset of ORSX. If you need dynamic readjustment of parameters which ORSX has and Regolith doesn't it might be possible that he's willing to implement those features.

That looks to me like users will have the choice between either a seriously nerfed KSPI (to get in line with NF) or a serioudly overpowered KSPI (to get in line with RSS/RO). Where's the middle ground? I always found NF to be quite underwhelming in terms of power/price it offered, while the "old" KSPI hit a sweet spot for me. You got seriously powerful system as a very late game option and it's MegaJoule mechanic made it mostly self contained. (The GW of power didn't really come into play since it sidestepped the Ec mechanic.) You paid for all this power in gameplay (AM harvesting, lots of science) instead of partcount (bad, causes slowdowns) or weight (translates to partcount). The changes you and Northstar1989 are implementing make KSPI-E seriously overpowered to the point of being cheaty in stock KSP while KSPI-NF seems to "drag down" KSPI to NF's performance level (or slightly above). And now to something completely different: Boris-Barboris' KSPI for 0.90 came together with a TweakScale Fix that has since been pulled by the mods. So far I worked around this by removing TweakScale configs for all the air intakes. What's the situation right now? (My save is still on KSPI-E 0.6.1) If I reinstall KSPI-0.90 and over that KSPI-E do I need to do something to TweakScale? Has the problem been fixed?

Northstar1989, FreeThinker, while I greatly appreciate the work you are doing on KSPI, please reconsider the direction you are taking this mod. With Fractal_UK and Boris-Barboris both not actively working on KSPI you are essentially the only game in town for this mod. The changes you are implementing base all values off of real-world mechanics without considering the gameplay at all. From my perspective it almost looks like you are holding KSPI hostage to force people into RSS/RO. While RSS/RO might be very interesting for realism oriented players, it is still a fringe community inside KSP and the target audience for KSPI is quite a bit larger than that. Especially considering that RSS/RO has the potential to break a lot of other mods or require extensive work to ensure compatibility. In my opinion an extensive mod like KSPI should work from the assumption that it's the only active mod (including necessary dependencies ofc) in an otherwise stock KSP install. Balance the mod against stock KSP and deal with rebalancing mods vie MM-patches, configs, etc. Please don't take this mod away from the greater KSP community.

No, as the title says I'm using Linux. No mode-forcing or anything. (emphsis mine)This would mean that OS X and Linux are 2nd-class citizens.

Hey all, I have a visual glitch with the new gizmos from 0.90. The "scale" part on the insides of the rings/arrows appears to have no transparency and instead shows the bright pink texture indicative of a color/chromakey overlay. Mods or no mods makes no difference. The screenshot is from a complete re-install (Steam version). Screenshot: Has anybody an idea what might be causing this? My GPU is a nVidia 560, using latest proprietary drivers. 32/64 bit version makes no difference either.

Finally got my dev environment back. - I pushed a new release with agises' changes at GitHub. @agises: Since you're doing more work than me anyway, I went ahead and gave you write access to the repo

I finally got around to make an official new version for 0.90. (OP updated accordingly.) I went a bit of a different route than ObsessedWithKSP's MM config. The probes are a bit more spread out and have different capabilities. I'm not quite sure it'll remain this way... have to test more. In some way I like that there's at least a bit of difference in the probes, on the other hand now it's not purely an aesthetic choice any more which probe to use. We'll see how this pans out over time I guess. For now enjoy your shiny BOMPs

I'd suggest going even one step further and making it a requirement to support CTT only per ModuleManager. Have a mod's part.cfg files reference only stock nodes and then rearrange them into the CTT per MM config. That way whatever happens with CTT players can be sure that their chosen mods will continue to work no matter what. Pressing high-tech mods into the stock tree isn't pretty and there will be a lot of shoehorning, but having fallbacks is a good thing. This would have the CTT depend on MM, but I doubt that's really a big burden on players. Setting up a modded install without MM is essentially impossible these days anyway.

It's no different than any other MM cfg. Every part.cfg defines where it should appear in the tree, this cfg just changes those lines. Put then content into InterstellarTreeFix.cfg and stick it somewhere into the GameData directory (I put it in the Interstellar directory). Make sure to get rid of any TreeLoader.dll that's still hanging around.

Here's my MM config I use for KSPI Lite. It's loosely based on the one from the KSPI tree. Use at your own risk! @PART[AMIReactor] { @TechRequired = specializedElectrics @MODULE[FNFusionReactor] { @upgradeTechReq = experimentalElectrics } } @PART[AntimatterCollector] { @TechRequired = advScienceTech } @PART[AntimatterReactor] { @TechRequired = advScienceTech @MODULE[FNAntimatterReactor] { @upgradeTechReq = experimentalScience } } @PART[AntimatterTank] { @TechRequired = advScienceTech } @PART[FissionReactor] { @MODULE[FNNuclearReactor] { @upgradeTechReq = metaMaterials } } @PART[FusionReactor] { @TechRequired = metaMaterials @MODULE[FNFusionReactor] { @upgradeTechReq = nanolathing } } @PART[PFissionReactor] { @MODULE[FNNuclearReactor] { @upgradeTechReq = metaMaterials } } @PART[*WarpDrive] { @TechRequired = experimentalScience } @PART[PlasmaDrive] { @MODULE[ModuleEngines] { @upgradeTechReq = experimentalScience } } @PART[*MPD] { @MODULE[ElectricEngineControllerFX] { @upgradeTechReq = experimentalScience } } @PART[ThermalTurbojet*] { @MODULE[FNNozzleController] { @upgradeTechReq = hypersonicFlight } } @PART[Vista] { @TechRequired = experimentalElectrics }

I guess KSP doesn't really care. Considering how old these configs are, the tiny amount of maintenance required is quite astonishing. Anyway... fixed in the 0.25 version. I also tweaked the cost end entryCost a bit to be closer to SQUAD probes. Have fun with the new version. (OP links updated)

Hi all, seems I haven't been getting notifications for KSP threads in quite a while. I've been out of the KSP loop for a while now, but I'm not dead yet Since Jarcikon hasn't been around either I guess I'll just rebuild it for .24 finally and pop up a new thread soon. (Hopefully around the weekend.) Any better naming suggestions than "Targetron Redux"? Or should I just keep "Targetron"?

So, Addle and I arrived at the same offsets, and I haven't seen any issues with them so far. Sal? Can you update the post at the top?

I put a fixed version up on GitHub. (Pull request to MachXXV sent.)

If MikeAeronautLZ's signature from here (01 00 00 00 b8 01 00 00 00 c3 41 56 41 55 49) holds up, the new offsets are 0099F587 and 0099F58C. Can someone who actually knows what he/she is doing double check that?