steddyj

Eh, this started itching in my brain again this afternoon. I posted in the Procedural Parts thread to see if my assumption that costMultiplier cannot be defined outside of the TankContentSwitcher module is correct. If that holds true, then I see two options for providing some level of balance Remove the MFT config for procedural parts in SETI, and meaning the cost for having procedural size is a bit less freedom in the contents (but this provides less support for other fuel mods, unless otherwise also defined in config for additional tank content modes) Allow the use of MFT for procedural parts, but accept that they will cost more than other parts in the mod

Hey guys, I was hoping someone here might be able to point me in the right direction of a solution (or confirm my suspicion that this cannot currently be resolved) of an issue I've been working on regarding Procedural Parts, Modular Fuel Tanks, and the SETI Rebalance mod. I first noticed that the three didn't play nice together when I was creating negative weight liquid fuel tanks, which is cool, but at the time I was not trying to create a TARDIS. I was able to trace this down to the fact that SETI makes some MM config changes to Procedural Parts, and this was not properly removing the TankContentSwitcher module from the parts when MFT was installed, causing a conflict resulting in bigger-on-the-inside-edness. Again cool, if you're a time lord. The easy fix is to modify the SETI config to either ignore the included new config or remove TankContentSwitcher if MFT is installed, which I started to work on but either would negate what the SETI config is doing, which is really just to modify the cost to be in line with the changes the mod makes across the core of the game. Which leads me to my question: Is it possible to define the costMultiplier variable outside of the TankContentSwitcher module? Obviously this cost equation is done outside of the module itself, but I've been unable to find anywhere else that references it. I'm assuming the calculation occurs within a function in the dll, and it defaults to 1 if not passed an argument to otherwise define it, but I was hoping there may be some other way to set this. Otherwise, it appears that the three mods are not fully compatible in combination, or for that matter any other use case that involves modifying the costMultiplier as well as providing alternate options for defining tank contents.

Well, honestly I stopped looking into this because I decided to try out Configurable Containers instead, and it doesn't cause the same issues, although I think that's just by chance. That said, I had hit a brick wall before deciding to switch mods. The balance changes you are trying to make are to reduce the cost structure of Procedural Parts, but from what I can tell that variable can only be defined within the TankContentSwitcher module, although the cost calculation obviously happens elsewhere. If you're using either Modular Fuel Tanks or Configurable Containers, the trade off is that you're going to have to pay full price for your procedural tanks. I resigned myself to this issue, so I stopped digging into it further in order to get back to playing and it seems a little unclear who is currently maintaining Procedural Parts, other than just getting it pushed to new versions.

So I've figured out the problem, but I'll probably work on the actual solution tomorrow. Short version, the TankContentSwitcher component of Procedural Parts does not directly play nice with ModuleFuelTanks. The MFT config included with Procedural parts actually disables the TankContentSwitcher module, then adds ModuleFuelTanks in to replace it. The SETI Rebalance config then adds the TankContentSwitcher module back in. So, at face value the fix is to remove the rebalance config.... except that it seems to make some cost adjustments. I'm pretty sure that ModuleManager has syntax to allow you to only make changes if a particular mod is or isn't installed. Actually, I know it can account for requiring a mod, I'm not sure if it can say "only do this if this mod ISN'T installed" (but I think that it does.) I'm going to dig through the documentation later and see if I can't re-adjust the procedural parts rebalance config to make sure this won't be an issue for anyone else, as well as making an MFT-compatible rebalance config that will still provide the same benefits.

I'm running into a bit of an issue and I'm hoping someone might be able to help me solve it. I started a new playthrough for 1.2 using a variety of mods, the most important for this conversation being SETI, Modular Fuel Tanks and Procedural parts. I've also used the Janitors Closet mod to prune out all parts that can be replaced by a procedural to keep my part counts down. I just unlocked some LFO tanks and engines, which means my only tank option is the procedural tank, and I was very surprised when I found my simple rocket hat a 19 TWR. I was more surprised when that TWR went *UP* when I added another tank. Looking at the tank stats, I found that there are two weight displays on the tank, and one of them shows a negative value. I've been picking this apart for the past several hours. Removing MFT solves the issue, so it's some interaction with that mod. I've been reviewing both the stock PP configs and the MFT, and everything looks good there. So I searched my install for any other configs that alter the proceduralTankLiquid part, which led me to the configs in SETI-Rebalance. Removing/renaming that config file also fixes the issue, and I notice that the tank actually shows as a very different part with and without this config. I want to keep as much of the SETI functionality in place for this playthrough, and the config seems to add some config I like to the tank, so I don't want to just leave it out. I can't see anything obviously wrong with the config file, though. I've installed SETI via CKAN, if anyone was wondering. EDIT: I noticed that there were also two type selectors, as you can see in the image above. I went back and pruned out the MFT config file in the procedural parts directory, and this has the tank working properly. The two must not be playing nice together, although I'm still not sure why. There were no other issues with any of the other procedural parts. Second EDIT: Belay that, now I can select a tank type as usual, but not use MFT. Seems I still need to figure out a MFT-friendly config for this tank if I want it to work 'right'

It MAY have also been a good idea to get his name right. Just sayin....

Yeah... so I'm an idiot. Like I said, I've been away a while. The functionality of the vertical snap used to be a toggle used when placing the part. I seem to recall it changing right before I stopped really playing a few years ago. Anyway, I see how the tool works now and I'm all good. Thanks for the help.

Very fair point, I just returned to KSP after a long sabbatical and I installed an insane amount of mods, I really need to trim that down. So I made a clean copy of KSP from Steam - I always run KSP as a copy of the main clean install. New clean install, new CKAN install, only this mod installed... still having the same issue. Vert/Horiz snaps do not work, nor does the Strut/Fuel tool. New log: https://www.dropbox.com/s/0dqwvlnwf6zuxku/output_log2.txt?dl=0 I checked the debug console as I was testing, and I didn't see it generating any log entries, not sure what might be causing this.

Sorry, it's been a few days since I've had time to try to play. Before launching KSP I did a fresh reinstall from CKAN, manually removing the folder and remaining config file before the reinstall. The log is at https://www.dropbox.com/s/5uh29zme2h1alpc/output_log.txt?dl=0 Thanks for the help.

I can't seem to get Vertical/Horizontal snap to work at all. I've tried remapping the buttons and reinstalling the mod and no luck. I don't even get the text popping up saying vertical snap is enabled, it just does nothing. I can't seem to find anyone else having this issue, any ideas? Thanks.

I came to report the same issue, I haven't been able to find a fix for this myself. I first noticed it trying to launch a sounding rocket from the runway and could not get it to fly straight, but it worked fine launching from the pad so I figured it was an intended side effect of launching rockets from the runway. Now I'm trying to launch a plane and I have those same gauges. When I try to move I veer to the left until it causes me to crash. Seems to happen regardless of craft or configuration, and persists across game files. Also tried a clean install of ksp and ro and had the same issue.

Word of advice for those increasing the storage space on your kOS modules: I created a ModuleManager config to add kOS to all of my probe cores with a significantly larger storage space (50000 if I recall correctly) and I quickly found that my battery was disappearing at an alarming rate. Through some trial I found that it was the kOS module that was doing this. Power needs scale directlywith the storage space, kOS was consuming 2 EC per sec. Since this is coded in the plugin, I could not override it and ended up putting in a generator module to counteract it. I'm all for kOS requiring power, and I can see the logic behind more storage potentially requiring more power, but this scale seems to need some tweaking.

Yeah, I was being lazy. For some reason I've never like using throwaway vars, probably an old happen from learning in C when they had to be declared at the top of your function. Honestly you're probably going to have to add in both a full stop and an exit with a return code. Sometimes an error will just need to terminate its own instance, and sometimes it'll be a fatal error requiring everything to halt. I would recommend adding both, or a method which could handle either case.

Sinza - I ran into this the other day. The issue is that you're assuming (as I was the other day) that SHIP:PARTSDUBBED("liquidEngine2") will return an instance of a Part structure, when instead it's a List structure. You'll see this when you PRINT mainengine., it will say it's a LIST of (probably) one item. If you only expect one return from that output, you can set main engine to the first output of the PARTSDUBBED command like like this: SET mainengine TO SHIP:PARTSDUBBED("liquidEngine2")[0]. I swear there's also example code in the documentation that shows this including how to add error checking, but I'll be damned if I can find it right now. Here's what I used in my satellite deployment script. IF ship:partstagged("payload_dcplr"):LENGTH = 0 { PRINT "Payload decoupler could not be identified. Manual abort required". Print "Hit CTRL+C to abort deployment". set x to 1. Wait until x = 0. } ELSE IF ship:partstagged("payload_dcplr"):LENGTH > 1 { PRINT "Multiple Payload decouplers identified. Manual abort required". Print "Hit CTRL+C to abort deployment". set x to 1. Wait until x = 0. } ELSE set deploy_device to ship:partstagged("payload_dcplr")[0]. set deploy_ctrl to deploy_device:getmodule("ModuleDecouple"). Since I'm tossing this code up anyway, does anyone know of a command to abort an executing script? The only thing documented in the Flow COntrol section of the docs is BREAK, which only works in loops. EXIT and ABORT didn't seem to do anything, so I set up the infinite loops prompting a manual abort shown. EDIT: I found the doc I was looking for, it's the Ship Parts and Modules doc: http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_parts_and_modules/index.html

Hooray for the new version, if I knew that .15 was so close to being released I wouldn't have bugged you so much over the past few days. However, I have something new to bug you for. I'm not sure if this is intentional, but I cannot seem to use the new list operators with lists generated by the list parts command. New lists created with list() work fine, as does say list targets. If I do something like list parts in foo, I get an error using the operators like foo:length. Since I can't copy from the terminal, please excuse any typos. I get the same error when trying to manipulate lists from other part functions like GetPartsTagged(). Are parts lists a special type of list? I'm trying to check the number of fields returned for error-checking in my script.

I must be doing a poor job of explaining myself, because that's the second time someone has asked why I'm trying to target multiple objects. I am not. I'm trying to target my lifter, which has no command core, after I decouple my satellite from it. The purpose is for a deployment script that will make sure it's far enough away before deploying antennas and solar panels to ensure they do not collide with the lifter. The lifter is now called "SHIPNAME Debris", along with my discharged fairings and the docking clamps back at KSC. When I try to set target to "SHIPNAME Debris" I end up targeting the first instance of an orbital with that name that appears in list targets. If I use a for loop (quoted earlier) to iterate through the output of list targets to find the one I want, I cannot simply set the target to that orbital, because set target appears to only accept a string of a valid ship name. If I use orbital:name it's just the same "SHIPNAME debris" string and gets me back to step one. I don't see any unique values in the orbital structure, which is odd. I'm pretty sure that ksp itself uses a unique I'd code, I'm not sure why it's not exposed in the structure. My guess is because the original developer had no idea just how far this mod could go, and painted himself in a corner much in the same way as the changes you are making in .15 have shown. By requiring only the name string for setting a target, it's like trying to describe to someone which specific slice of pizza you want by saying "give me pizza" and nothing else. Unless I'm completely missing something here, which is entirely possible.

Regarding targeting - got it, I'll keep that in mind if I'm scripting to deploy from the live craft. In this case, the lifter is dumb, deployment occurs on a suborbital trajectory and the lifter will return to key in ballistically. All control is on the satellite, so that should not be an issue here. Regarding selecting the correct object. I get what you're saying, but I already have the right object in my variable when I try to set it to the target. Using a parts list instead of target lists may make the script more elegant, and honestly I'll probably recode that way for future use. It still won't solve my issue, however, because I would still be identifying the object, trying to set the target to its name, and failing because there are multiple objects of the same name. However, I think see the solution that you're trying to present. Don't target, once I have it identified I can use this:distance rather than trying to target, which will actually work better in this case. Now my question is more academic, though. I'd still like to know how you can set a target when presenting multiple objects of the same name? Is there currently a way, or do you need to make sure that you never forget to rename your comm satellites?

Ouch: I appreciate the help. I'm not sure what gave you the impression that I'm trying to set multiple targets, perhaps because I don't have a break in the target code I posted. It's not very elegant (yet, its a POC script) but the IF statement will only be true to the lifter debris, and I've debugged it to confirm that it is indeed trying to target the correct object. Using this:name instead of this:vesselname did correct the error that I was experiencing when trying to set the target, however the result is still the same. I end up targeting the first object of the name that appears in LIST TARGETS even though my target code is executing against the correct instance since ORBITAL:NAME is not required to be unique. Is there a value in the structure which is used to uniquely identifying an orbital which can be used to set the target? Alternatively, were you suggesting I target a specific part on the lifter?

After watching kOS for a while now I've finally decided to take the plunge, in part because I've been very impressed by the recent progress of the mod. While the documentation is leaps and bounds from what it was the last time I thought about adding kOS to my modlist, I'm still getting a bit stuck on a few things. For my first useful script I wanted to have something that will deploy a satellite for me after the lifter has coasted out of atmo. I'm using RT, and the antenna on the satellite would face into the lifter if deployed before the payload is decoupled. Functionally this would work fine, but it was a good excuse to give kOS a try. So I have my basic script working fine, it decouples the satellite, fires RCS forward a few bursts, waits a few seconds, then hits an AG deploying comms and solar panels. Now I'm trying to refine it a bit, I'd like it to make sure it gets at least 10m or so from the lifter before deploying. Logically I have this all worked out - target the lifter, get the distance, is it far enough? ok deploy. The issue I'm running into is how to set the target specifically to the lifter, since it's named "Vessel Debris" along with the fairings I just jettisoned and the launch clamps back at the KSC, which is what I end up with if I try to target it by name. I tried the following script: list targets in targs. for this in targs { if this:distance < 100 { set target to this. } } and I get "Vessel 'SHIP("Vessel Debris")' not found" I figured maybe I need to set target to this:vesselname and that just gets me back to a docking clamp. What am I missing here? Is there a unique identifier that can be queried in the orbital structure that will help me make sure I'm setting the right target? Thanks for the help, and sorry for the wall of text.

Yeah, this turned out to be my issue. I had tried to change this setting last night, but after I saw the immediate changes to the resource options I thought it didn't fix it. When I tried it tonight I noticed it made the remove button appear in the Roster menu. Thanks for the help!

I don't seem to be getting the option to change crew while still on the pad. Am I missing something? I am using CLS, if that makes a difference.

Yeah my issues with Spherical tanks were the empties. I deleted those from the cfg files. I'll have to search on the Kethane converter issue. Thanks for the help!

So I've been having an issue with this and I haven't been able to figure it out. Some of the mods I use are not picking up the modifications. For instance, I can set values for tanks from KW, but not Spherical tanks. Also the modifications to the Kethane converter are not working. I have the cfg files for these mods but I can't figure out why some of them wont load.