Tahvohck

Answering my own question, in case anyone has the same one later and googles this, it seems the node-copy operator only works when editing an already-existing node? If that's wrong someone please let me know, but the end result is that to do something like that make sure the node exists, then patch in the sub-node. Moving on from that, two new questions: 1) Is there a syntax to copy a value from a different node, similar to how the node-copy can browse the whole ConfigNode tree looking for the node to copy, and if there is, 2) is it possible to copy all values with the same name by using the ,* index?

Can anyone tell me why this isn't working? I'm trying to use MM to condense certain repetitive bits of my code, plus make it so I don't accidentally forget to change a section. TahvMFDConfig { topKey1 = value1 topKey2 = value2 CONTEXTREDIRECT { name = ID1 nodeKey1 = value1 nodeKey2 = value2 } CONTEXTREDIRECT { name = ID2 nodeKey1 = value1 nodeKey2 = value2 } } %PROP:AFTER[TAHVOHCKMFD] { MODULE { PAGE { #@TahvMFDConfig/CONTEXTREDIRECT[ID1] {} } } } Basically for each PAGE in this config for RPM I want them to have the same redirects and I don't want to accidentally miss a page if I change something. I'm ending up with nothing listed in any of the TAHVOHCKMFD passes, though: [LOG 21:10:55.024] [ModuleManager] :BEFORE[TAHVOHCKMFD] pass [LOG 21:10:55.048] [ModuleManager] :FOR[TAHVOHCKMFD] pass [LOG 21:10:55.053] [ModuleManager] :AFTER[TAHVOHCKMFD] pass [LOG 21:10:55.060] [ModuleManager] :BEFORE[TRIGGERTECH] pass

Hum. Okay. More advanced one it is, then. Also, it would be great if it turned out I don't actually need all the initial filters. I wanted this one to modify the KAS & KIS node via modulemanager but that wasn't working either, so that's why I'm completely recreating it. EDIT: Whoops. Nevermind, now I understand what you were saying about needing subcategories. { name = KAS and KIS Compatible icon = KAS colour = #FFF0F0F0 all = true FILTER { CHECK { type = folder value = KIS, KAS, KISFunParts } } FILTER { name = evaToolsBomb CHECK { type = moduleName value = ModuleKISItemBomb } } FILTER { name = evaToolsAttachers CHECK { type = moduleName value = ModuleKISItemAttachTool } } FILTER { name = evaToolsPropellant CHECK { type = moduleName value = ModuleKISItemEvaPropellant } } FILTER { name = KISInventories CHECK { type = moduleName value = ModuleKISInventory } } SUBCATEGORY { name = Fun Parts icon = R&D_node_icon_start FILTER { name = funFilter CHECK { type = folder value = KISFunParts } } } SUBCATEGORY { name = EVA tools icon = R&D_node_icon_precisionengineering FILTER { name = evaToolsBomb CHECK { type = moduleName value = ModuleKISItemBomb } } FILTER { name = evaToolsAttachers CHECK { type = moduleName value = ModuleKISItemAttachTool } } FILTER { name = evaToolsPropellant CHECK { type = moduleName value = ModuleKISItemEvaPropellant } } } SUBCATEGORY { name = Containers icon = R&D_node_icon_composites FILTER { name = KISInventories CHECK { type = moduleName value = ModuleKISInventory } } } }CATEGORY

Thanks, that's nice and easy. Moving on, can you tell me why this isn't loading? Obviously this is a test case, but my more complex example isn't working either so I wanted to use the simplest possible thing. CATEGORY { name = Literally Nothing icon = SPD colour = #FFF0F0F0 all = true }

Is there any way to add NOT checks to filters? I'd like to make it so, for example, the "Electrical/Power Storage" category doesn't have things that also make power in it.

I've had my game freeze a small handful of times when dragging parts too quickly in the editor (causing me to accidentally let go of the mouse button very shortly after clicking), specifically when trying to add things to inventories. Not commonly, but it's happened.

Double-post. Whoops.

Any idea if the recompile was actually needed? I don't think it's been throwing any errors for me, but having things most up-to-date is always good.

When you do the update to v1.2, can you also update the CKAN data for the KIS fun parts if you're the one handling that? You have to manually install it, despite CKAN being aware of it. Not the worst problem, but mildly bothersome.

Hmm. I thought it might be something like that. It looks like it's both a sequencer and a...needs-satisfier or whatever you want to call it? Weird. Actually wait, does it actually have to be a mod that exists, or can it be any tag? And I was aware of BEFORE, AFTER, and FINAL, but not FIRST and LEGACY... FIRST would be the opposite of FINAL, I'd assume, but is there anything special about LEGACY?

Is there a way/is there a plan to make items only stack up to a certain amount? I see the stackable parameter, but I'd like to make wrenches and the like stack up to a small maximum, so that a tiny part isn't taking up a huge amount of slot space.

What does the :FOR (colon FOR, to make this more searchable later) directive do, exactly? I've seen references for it, and there's a mention in the documentation on github, but it's not explained very well. Does it just mean that any node with :FOR[foo] will be found later with a :NEEDS[foo] directive?

Using the LV-T30 "Reliant" as an example: @PART[liquidEngine] { %MODULE[ModuleMyAlternator] { capturedRate = #$../MODULE[ModuleAlternator]/RESOURCE[ElectricCharge]/rate$ } -MODULE[ModuleAlternator] {} } Some notes: I'm using the edit-or-create syntax with the "%" instead of just defining it. This is a personal preference of mine, you can just as easily do @PART[liquidEngine] { MODULE { name = ModuleMyAlternator capturedRate = #$../MODULE[ModuleAlternator]/RESOURCE[ElectricCharge]/rate$ } -MODULE[ModuleAlternator] {} } Make sure you do it in that order, so that you grab it before you delete it. What this is doing is saying "capturedRate equals [go up one level (to the PART node), select node MODULE[ModuleAlternator], select node RESOURCE[ElectricCharge], select value of 'rate']".

Certain things are working on it, other variables have been depreciated. Once RPM 0.21 drops, the PFD orb will stop working. I'm working on my own custom config for the monitor--based on Hyomoto's but mostly different--but it's going painstakingly slow because I don't have much time to work on it. If anyone is interested in seeing this come into the 1.0 age/seeing what I'm working on, I'll upload the repo instead of keeping it local to my computer.

*chuckle* Fair point! In case it hasn't been said enough, thanks for the great work you're doing on this. It's incredibly useful.

Were you aware you left it firing on button_A as well as flight -> landing -> btn4?

No need, just tested it myself and it works like a charm. Attached the patched file. Uploaded the file, since apparently I can't attach here. Worth noting that I fixed a typo in the overlay URL, "Hyomoto" vs "Hymoto". Was keeping the scanline overlay from loading.

I suspect this will work, though I haven't tested it yet: @PROP[HyomotoMFD]:Final { @MODULE[RasterPropMonitor] { PAGE { //button = button_A name = KSF_NAV_HSI textureOverlayURL = Hymoto/MFD/images/genericOverlay disableSwitchingTo = btn1, btn2, btn3, btn4, btn5, btn6, btn7, btn8, btn9, btn10, up, down, enter, escape, home BACKGROUNDHANDLER { name = KSF_MLS method = DrawMLS buttonClickMethod = ButtonProcessor } PAGEHANDLER { name = KSF_MLS method = pageAuthor } CONTEXTREDIRECT { redirect = home, menuDefault redirect = btn1, flightDisplay } } @PAGE[flightDisplay] { @CONTEXTREDIRECT { redirect = btn1, KSF_NAV_HSI } } } } Basically: remove the activation button from your page, on your page add a redirect to the Hyomoto flight display, and on his flight display add a redirect on button 1 to yours. EDIT: Although it occurs to me that if we're adding it to toggle on any of the screens, "flightLanding" probably makes more sense.

Just curious, why'd you assign this to button A on Hyomoto's MFD instead of a toggle on (flight screen) button 1 (so you toggle gimbal/ILS instead of flight/ILS)? Any reason in particular?

Why in the world does RO give the mechjeb module a 11.87 Tm transmit range? That's... a ridiculous distance for such a tiny antenna, isn't it?

*facepalm* Done in by missing a single character yet again. Thanks for pointing that out!

I've been eying this on and off for a while, and I'm sure I'll have it installed within a few weeks when I finally stop resisting, but I have a question: Wouldn't it make more sense to use Joules, or Watt-hours, or even really Coulombs? Wattage is a rate, and it doesn't mean anything without the amount of time it's applied over. To say that you have 2 kW stored on your ship means nothing, 2 kWh or 7.2 kJ means quite a bit. Now, without looking at the actual configs, I couldn't say whether or not this actually matters, since Watts tend to translate into Watt-hours pretty well, given that 1 Wh is literally 1 Watt applied for 1 hour, but I'm a stickler for correct units.

Awesome! I'm especially happy to hear we have 6-hour day support now. Whoof. Looking at that chart, I'm impressed you can keep up with it. I'd need more borders around each table to keep track of it all.

Alright, so I'm looking to seriously integrate this into my game but... I've run into a snag. In a way, the same snag I ran into last time I tried to plug in a life support mod (Ioncross back then). I'm going to be using the Universal containers because a) it's listed on the front page (even though it's not technically supported yet) they provide nice functionality on their own for other bits and bobs and c) they look pretty. Here's the snag though. Universal Containers is designed with real-world values in mind, in most cases in terms of kg/L (well, metric tons/L in the raws, but let's ignore the specifics for a little). TACLS is balanced for, as far as I can tell, simplification: 1 unit equals the amount of a resource used per day. (With the exception of electricity consumption, which I'd really appreciate a unit for: 2400 EU per day is a bit absurdly high at first glance, though I haven't done any of the math. Getting an idea of what that's supposed to represent would very much help). Now, this wouldn't be so much a problem... if UC wasn't aggressive about its stance and didn't use ModuleManager to patch values for density. And if it didn't assume things like liquid oxygen in its tanks. End result: one UC wedge of O2 is something like *checks* 46234 Kerbal-days of O2. Which ends up weighing something like 83 kg structure + 66 kg O2 = 149 kg. Which is... quite a bit OP, no? Now... I happen to like dealing with real-world values. So I'm making a MM patch myself to bring as much as I can in line. But I'm wondering how much effort was put into the balance in the first place, so I know what I'm throwing a monkey wrench into. (The actual snag by the way, roughly, is that the moment you add life support to the game, balance becomes stupidly paramount and finicky and dependent on personal taste, and that last one ruined Ioncross for me enough that I started making my own. Never finished, but... ) PS: I can't wait till I finally start using Realism Overhaul and get to make all of those things play nice together all over again either... or more accurately, get it to play nice with the things I have already. Balancing is hard, you guys. (Not to put down the amazing work people have done on RO. More to put down my own hodgepodge of mods) Edit for the millionth time, and not a typo this time: Y'all might get a kick out of this. Just don't be eating when you read it.

Well, I seem to be blind! Thanks for pointing that out.