Tahvohck
-
Posts
80 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by Tahvohck
-
-
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.
-
ZentroCatson: KIS has very few bugs (only one I can think of at the moment is launchID not getting set when transferring from container to inventory). KIS has not caused any freezing issues here (I haven't had any at all).
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.
-
So.. You shouldn't exactly trust me because I only have 4 posts, but I compiled PlanetShine for 1.0.4 and changed the .version so it'd grab it from my Gist URL. I also replaced the MiniAVC for the latest version I could grab but I think it's the same, anyways.
It'll report with "PlanetShine 1.0.4 Unofficial Build" and in my tests no warnings showed up and the add-on worked correctly.
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.
-
If :FOR[foo] exists anywhere, then all :NEEDS[foo] requirements will be satisfied. (which kinda sucks if you are using :NEEDS to be sure that a mod exists as the mod could be absent but :FOR[foo] will make it seem as though it is present)
More than that though, patch nodes can be ordered, if you need them to occur in a specific order.
The order is
:FIRST
:LEGACY
:BEFORE[Foo]
:FOR[Foo]
:AFTER[Foo]
:FINAL
where Foo equals any mod (including Module Manager)
Legacy doesn't actually need to be defined; any patch that you DONT specify the order in will occur during the :LEGACY pass.
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?
-
I'm attempting to mod a stock engine, and I want it to produce the same amount of electricity the engine does at full throttle. Using ModuleManager, is it possible to capture the rate from ModuleAlternator before it remove ModuleAlternator from the part?
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?
-
MODULE
{
name = ModuleRTAntenna
Mode0OmniRange = 5000000
Mode1OmniRange = 11869095061338
MaxQ = 3000
EnergyCost = 0.001
TRANSMITTER
{
PacketInterval = 0.001
PacketSize = 1.0
PacketResourceCost = 0.001
}
}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?
-
Note it says EC/s, which means 1EC = 1kJ.
*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:
*snip**Realistic battery and solar panel numbers, and usage for RT2 antennae. 1EC/s = 1kW. Solar panels don't produce much, but they're light.
*snip*
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.
-
The license is a the bottom of page it's http://creativecommons.org/licenses/by-nc-sa/4.0/ so your all good thanks.
Well, I seem to be blind! Thanks for pointing that out.
they provide nice functionality on their own for other bits and bobs and c) they look pretty.
)
(Not to put down the amazing work people have done on RO. More to put down my own hodgepodge of mods)
[1.8.x-1.12.x] Module Manager 4.2.3 (July 03th 2023) - Fireworks season
in KSP1 Mod Releases
Posted
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?