Apaseall

Hacienda, Manage Op, Convertor, Prospector turned on, yes. (200%) 260% load. Re OmniStorage in ChuckWagon, Solved, I edited MODULE[WBIResourceDistributor] to include DISTRIBUTION{resourceName = Slag mode = 1} Oddly enough this node was right after the Water node, which caused a problem else where that I solved by editing. Seems like Water messes up stuff. I like the 'is it turned on' ?

I have a resource production chain question. Can someone give me a hand please. I want to make Konkrete. I have a Hacienda configured as a Brew Works. It says I need a bunch of input resources, one of which is Slag. The remaining input resources I have plenty of. I have another Hacienda configured as a Claim Jumper Strip Miner. It says it takes as an input resource Ore and output a whole heap of resources. Slag appears as one of those outputs. However I do not seem to be accumulating any Slag. When I Manage Operations I see the Hacienda is configured as a Claim Jumper, but Slag output is negative number whilst all the other output resources are positive. Am I going about this the right way? As in should I be expecting to obtain my Slag from the Claim Jumper? If so, then why does it give a negative number for Slag? If not, how do I go about getting some Slag? <no rude jokes please>. Thanks. Edit. I have a ChuckWagon configured for OnmiStorage. One of the many resources it is set to hold is Slag. But when I look at the Resource Distribution information, Slag is not listed at all.

I would like to build a certain part. The part is not listed in game. Can someone point me in the right direction to enable me to work out why the part is not listed and thus enable the part to be listed? Many thanks.

Nice to see you posting I completely forgot that during certain stages of flight a SSTO can get very hot. I should have remembered since some of my flawed builds had stuff blowing up!

I had a problem with OmniStorage: The popup which allows us to pick the resources stored appeared as the expected grey box but all the writing was scrunched up along the top of the box. I encountered this problem when I: converted a chuckwagon to OmniStorage. My situation: I have two bases side by side, the first base has one chuckwagon set for OmniStorage which is working fine. When I tried to change a chuckwagon to OmniStorage in the second base the problem occurred. I solved my problem by: editing a save game. I compared the PART nodes for the working chuckwagon with the problem one. I copied certain modules and resource nodes from the working chuckwagon to problem one, i.e. I copied the working chuckwagon, over the problem one whilst NOT overwriting individuality data like part ID's, launch ID etc. Loading the edited save game showed both chuckwagons to be working and I am able to change the resources stored in the second chuckwagon without the problem reappearing. Details: the PART node for second chuckwagon appears to not have had the module OmniStorage applied to in the same way the first one had. If I remember correctly the module OmniStorage was missing and the value for the key pair OmniStorage was blank. My apologies for not making a note of the differences at the time I was editing. Possible contributing factor: the problem chuckwagon in was not manned during the change to OmniStorage. When I changed the working chuckwagon in the first base it was manned. I manned the problem chuckwagon prior to doing my editing, but manning alone did not resolve the issue. Technical notes: EDIT The same problem has appeared when I tried to setup OmniStorage for a third base close to the previous two. This time I made a note of the differences in the PART nodes: Once more I was able to solve the problem by editing the PART nodes. I was able then to reconfigure to OmniStorage.

Sorry to hear my suggestion was not helpful to you. I think those parts are not PathFinder parts, so yup I think you are in a spot of bother there. On a side note, I do not recall using strike through in my post, in fact I am pretty sure I have never used it. Looks like you are not the only one with odd things happening! I do seem to be having joy with my install now, fingers crossed.

@Sresk I would suggest that the mass of the tank may be due to it being an OPT part. To clarify, OPT parts are space plane parts not mere containers. Thus the mass may come from a combination of; the shape required to fit with other parts of the same frame type, structural strength to ensure craft does not rip apart during flight and the need to provide lift. The amount of gas being stored may be worth investigating. However that again may be due to it being an OPT part. AFAIK space plane parts are not designed to be high pressure storage containers. Do you happen to know under what pressure is the gas stored in the container you are comparing to the OPT part? dV from plane engines is very high compared to other engine types. Thus is can be good to use a variety of engines depending on the purpose the OPT parts are being used for. This also changes during flight, as altitude and velocity during flight can change drastically. I try to use the lift provided by the plane parts to offset the loss of dV, as basically the shape of the parts gives you free dV in the vertical direction due to lift. In summary, the containers you are comparing are designed for different purposes. That is not to dispute your findings, but some of the differences you are finding may be covered by the above, although there still could be some room for changes in the values you are interested in.

This is my understanding. The PathFinder download is set for playing in Classic Mode. The download does not presently contain a WBIPlayMode.cfg file which you would find in your /GameData folder. PathFinder uses filename extension renaming of files found in the template folders (i.e. in both PathFinder and WBITools? directories) to leverage ModuleManager to control how PathFinder behaves in different Play Modes. For those of you experiencing behavior that feels odd [KSP ver1.4.5] I would suggest that you ensure that the filename extensions match those expected for the Play Mode found in your WBIPlayMode.cfg file. One way to do this might to be make everything the same as the download, (i.e. check the filename extensions of the templates files) then check that your WBIPlayMode.cfg file is set for Classic Mode. Run KSP. Change Play Mode to the one you want to play with, then immediately restart KSP. Please note, this is my suggestion, it may entail you needing to rebuild part or all of your base, thus I cannot stress enough that you make sure you have very clearly named save games in case you need to revert things. Always keep at least one copy of your saves somewhere safe :)

I like to avoid using :FINAL if I can help it. With some thought, or trial and error I can usually find out a suitable :AFTER[]. Saves the 'race to the end' thing.

Hi everyone, got a new question: I would replace :FINAL with a suitable :AFTER[]

I believe that the state of the template files as downloaded is for Classic Stock Play Mode. If user was playing in another mode before updating their WIB folder, then the Play Modes will not be synced properly. I suggest adding a valid Play Mode to the download, set to Classic would ease many problems that users might have experienced during recent updates.

Fantastic! I think it is a tech lock, which I guess would not show up in the logs. Time to carefully examine the tech tree to see if I can spot a part I have or an upgrade. edit. Doh! Yes it does tell me when I try to launch it.

I think it might be a mod that changed the tech unlock for a part. Problem is nothing appears on screen. The output log is spewing stuff as I was debugging something else. I was hoping that since a message from this mod was displayed, that this mod had a little something up its sleeve. Thanks for the reply.

Just installed this mod. Looks good. I see a notice against a certain craft. It say "This craft has locked parts". Is there an option I can use that will let me know the names of these 'locked parts'?

Erm. I think you might have who wrote what a bit mixed up. My example was merely to show how to make a variable, how to use it as a multiplier and delete it. I did advise examining example parts to determine in which nodes the pieces you wanted to amend are located.

Or in my case, a little sleep Please read my example again, pay attention to @. Without some of those you ain't going to be modifying something that exists. etc. You know to look inside modulemanager.configcache to check the results of any patches right?

On my PC in the place mentioned I only see .Net 3.5.1. It has a blue square box next to it. It expands to show two sub options; Windows Communication Foundation HTTP Activation and Windows Communication Foundation non-HTTP Activation. Both of those are not ticked. I presume that I do not need those sub options. But I am right back to asking 3.5? This does not exist for me. 3.5.1 does. Do I need to download and install .Net 3.5, which I have a download file called detNetFx35setup.exe? I am not sure how sensitive "IT" is to version, i.e. will 3.5.1 produce odd behavior, or is it ok to use any 3.5.x version?

The syntax would be something like: You would need to create the variable in the right place and make sure that you delete it from there also. Also ResourceAmount is not the name you would be changing. What I would do is examine an example part. Locate the Module that contains the value you want to change. Of course this may not be named Module but something like Resource. Then in your code you would drill down to where that value is, put the multiplier just before it, do the multiplication then delete the variable. Here is an example: Although I only included the one part named PAL_Claw, because in reality I made changes to PAL_Claw or PAL_Magnet or PAL_Gripper or PAL_Crane or PAL_Forklift I chose to delete the variable once, rather than inside each part. Hope this helps.

Yes I plan on making and or editing plugins. .Net Framework exists as at least 3.5 and 3.5.1, there is also something about service pack 1? Therefore when you write 3.5 which version do you mean?

Cheers thanks for clearing that one up for me. Simple order then 1 create non-patch node, 2 MM extracts and processes patches. No need to bother with name selection to provide process ordering until we come to MM patch processing. Cool. Thanks for your help.

Hi Here is a detailed suggestion for how you might be able to support Play Modes with ease. As a rather large fan of your work I wish to provide you with as much aid as I can. Previously I did this by merely bringing certain issues to your attention. This is my attempt in providing you with aid in the form of suggestions that have been clearly thought out.

Hmm. So if for example I had b.cfg as a part definition file, which is .cfg, then I would do things in this order: Are you absolutely certain that this is not valid: ?

Oh. Can I get away with: Since b.cfg is a part definition file, it will be creating part whose name = something. The first piece of b.cfg then would be creating a part, the second piece would be amending that part? Hmm. Lots of thoughts come to me here. Irrespective of you answer to the code in this post, I might be able to swing what I am looking for in the use I am aiming at. But would be nice to know if this code IS an option. Oh and blowfish, you are a STAR. My sincerest thanks for sharing your knowledge with me.

My test of update 1.30.1 did not go so well. I had a part that is now not present. This is not terrible for me as I had to rebuild my base and had only included that part as a test. @Angel-125 I am looking into ways to help with Play Mode switching. I will post once I have something that works. Unfortunately I was short on time today.

Thanks. So code would like this: What I am thinking is that b.cfg is the definition file for a part called something. I am trying to add a module to something depending on the value of H. How about I use a :NEEDS that checks the value of #J?