Jognt

Ahh, now I understand what you're trying to achieve with that patch you mentioned in the ModuleManager thread! Looking good! Let me know if you hit a snag with MM patching it. It should be rather straightforward, but then again, everything is straight forward once you know where to go. Edit: Just a heads-up: CityLight.cfg is either missing a node definition or it has duplicate curly braces. @EVE_CITY_LIGHTS:LAST[JNSQ] { { OBJECT { body = Kerbin cityLightsMaterial { _CityOverlayDetailScale = 50 _CityOverlayTex { value = JNSQ/JNSQ_Textures/EVE/Textures/CityLights } _CityDarkOverlayDetailTex { value = JNSQ/JNSQ_Textures/EVE/Textures/night } _CityLightOverlayDetailTex { value = JNSQ/JNSQ_Textures/EVE/Textures/day } } } } }

I did not encounter the tank amounts resetting though the PAW lines being duplicated is caused by Stock KSP modifying PAW entries recently (1.7-ish), mods like Snark's SimpleFuelSwitch had to update for it too. The only difference I noticed besides crossfeed suddenly no longer working was in the savefile itself where the end node of the USII core 'lost' its connected part and had it set to -1 or whatever the default/unconnected is. The tank (B) that was attached to it suddenly had its parent set to the tank below (C) that which had the tank above it (B) as its parent. In other words, they formed a circle reference. This breakage in the tree structure is most likely what caused the crossfeed problem. (Technically the parts were no longer connected to the main vessel, which is why it does work when " Resource transfer obeys crossfeed rules" is disabled because then it'll just flow through the whole vessel regardless of connections)

Could you share one of your complete patches and note what your goal is? That would make it easier to help than just repeating the syntax that is out there. Things to check: Execute the patch at the right time, properly target valid nodes and values, make sure every node deletion has {} after it and that every value deletion has a dummy value after it.

It appears you’re asking a few things, I’ll try and go over them. :AFTER[JNSQ] will cause your patch to run in JNSQ’s ‘after’ round if it is present. It will not run if JNSQ is not present and it will run before LAST[JNSQ]. !EVE_CLOUDS {} will remove the top-level node If it exists when it runs. Note the curly braces. The same applies to the 3rd one you listed. @ad_astra:AFTER[jnsq] would run whatever comes next only if JNSQ is present, and it will again run in JNSQ’s AFTER round. You can see the order of patching in the log file and you can confirm correct results by checking the ModuleManager.configcache file. Now whether or not these things are the way to go for what you’re trying to achieve is another story. Why not just remove the EVE configs for JNSQ if you wish to use your own? I admit that the MM documentation is scattered around the forums and wikis but digging around and asking about unknowns should help. Considering your post I’m curious as to what you’d like to achieve. That way it’s easier to know what sort of patch you are looking for.

If you click the BV controller it should give you the option to change the rotation vector. This helps BV determine what “up” is for your rover. I’m not 100% on the details, but if you try the options there should be one that works. Edit: They look kinda cute and helpless on the 2nd image btw.

Ok I just got some weird looks as I suddenly burst out laughing while on a break outside. Edit: I wonder what Bill & co come up with!

This bug is caused by something other than the crossfeed system itself. The crossfeed problem is just a symptom of it. I'm not sure whether the devs have reproduced it (or if my bug report was sufficient to understand it), so @Paul Kingtiger -> If you could use more info/details on this bug, let me know. Wobble? I did notice the 2.5m core inducing thrust torque, most likely the west-west-north node is off by a fraction. (or the east-east-south node)

I recommend changing “ABS rate” to “ABS interval” as it should be a bit more intuitive in its meaning.

@maja maybe the code from Landing Height can help?

You’re the best!

Sounds like this bug: https://bitbucket.org/uvs2/universalstorage2/issues/41/bug-fuelcrossfeed-not-working-due-to-cores I’m not sure what the underlying problem is, but I’m guessing it isn’t a no-brainer. Fyi, it’ll work if you disable “Resource transfer obeys Crossfeed rules” in the difficulty settings, though I admit it’s more a workaround than a fix.

If your goal is just to use this mod; the author updated it so you should be good to go. @Flupster pardon my repeating this. X science works fine with orbital science if I replace all dmscienceanimate modules with his generic (CKAN) version. Is there a specific problem preventing it from working with the regular dmscienceanimate module?

Especially the output log and if possible a save from just before you switched to the rover would be nice. I haven’t played for a while but I remember I wasn’t having this problem back when you first mentioned it. @maja the code mentions handing over vessel stabilization when another stabilization mod is present, maybe it’s a hand-off problem with another mod? Logs/save may tell. Edit: the logs are from the last session, so as long as you don’t start KSP again the log should have all the bits from when it went wrong.

*shakes magic crystal 8-ball* ”Maybe!”

Awesome!

Perhaps it’s due to this mod playing a sound when science is available?

Yup, can confirm. Just setting the agent should do the trick.

Same, I figured it was intended behavior! Thanks for the update/fix!

It’s highly unlikely that it works in 1.8. If it does, then that itself would be a bug. Unless you recompiled it yourself and updated the required bits for 1.8 yourself, in which case it may work for you but that says nothing about the officially distributed build. I’m missing the actual question here..?

This mod makes it possible for other mods to modify stuff. Don’t worry, if you install this with strategia you’ll get what you ordered.

Wait.. when/how would that fail/nullref? Tech speak appreciated.

You don’t need this mod on the new KSP 1.8 update. I recommend you pick up the experiments and place them back down again. Should also fix anything that broke while editing the save.

This is the BetterBurnTime thread, I’m assuming you wanted to comment in the BetterTimeWarp thread. To answer your question though: yes, I have to select warps every scene.

Enjoy your vacation!

Because leaving it in reduces the cash the cow generates. In other words, I’m just saying that I am not buying KSP2. I never thought that game publishers would be the ones to convince me to give up gaming.