Raptor831

The :FOR[] is intended to be used by mods to define when their configs will "run". If you look at the logs, you can see MM going through each pass and telling you which edits were made when. The folders are kind of a default :FOR in MM (if I'm understanding it correctly). Regardless, you can use NEEDS on and folder name, DLL name, or defined FOR pass. It wouldn't hurt to use a FOR[MyModFolder] just to be explicit, but I believe you are correct. And, glad it got fixed! Also, yes, the Apollo astronauts drank the water that is the byproduct of the fuel cell. The water was also part of the cooling system, IIRC. That's why losing the O2 tank was so devastating for Apollo 13; it knocked out the power, breathable O2 supply, and the H2O supply (and by extension the cooling system) with 1 explosion. (ref: http://en.wikipedia.org/wiki/Apollo_Command/Service_Module#Electrical_power_system) You should check out Paul Kingtiger's Universal Storage, which adds a realistic fuel cell in wedge format. Paired with KAS, it's a great modular life support/power system for both single missions and stations. It's also got some nice math to back up its numbers, in case you were ever looking for that sort of thing. EDIT I just updated the repo with new configs (again). They should be the same as before, but with the proper thrust values for hydrolox and methalox and anything else that should not be the same thrust as kerolox. This should fix the bug that lurkoholic mentioned. As always, let me know if you find bugs. If this one is clean, I'm going to try and add RCS to the webapp, and once that is fixed I'm hoping we'll be ready for a new release.

N2O can be pressurized to 48 atm, according to the article here: http://www.astronautix.com/props/n2osolid.htm Which means, you can set a utilization of 48 (I believe) in the tank definition and you'll get accurate stored volume. Not sure off the top of my head if this is already set in any RF tank definitions, so you might check that. As for the ratios, you'll just have to work with it. There's nothing wrong with having those kinds of ratios, unless there's some weird floating-point errors that I'm unaware of for the smaller side. But as far as the idea goes, it doesn't matter what numbers you put in the ratio, it just uses what you tell it.

Couple of points: Hypergolic engines matter more than the fuels. There are hypergolic launch-stage engines that are only designed to light once, so the reusability factor depends more on the engine config, which is paid with the engine costs really. Frankly, I'd assume balloon tanks were cheaper than regular, since they have less structure to worry about. But I don't know, so maybe someone else who knows can chime in? I'd also leave LH2 in the service tanks. The Apollo SM had LH2 and LOX as part of the fuel cell that kept it powered. The tank types are more about what kinds of tanks can be housed inside, so I'd be for keeping them a little more open to whatever the player wants to put in them.

The :NEEDS[sDHI] should work so long as SDHI is installed to the default /GameData/SDHI/ folder. AFAIK, MM uses the folder names as well as .DLL names in the NEEDS/BEFORE/AFTER spots. FOR is just a way to add arbitrary runs. I just tested again on my install and it seems to be working, with resources pre-filled (including EC and Hydrazine). Pic: Most recent version of RF, TACLS, and the latest repo version of Stockalike. Ablative from DRE/Stock Revamp should work as advertised as well. If it still doesn't work, post a link to your log file. I'll run through that and see if I can track it down.

@Konnor: I can't see anything wrong with the CONFIG, it looks good to me. The ratio in the CONFIG nodes are in volume units (in RF's case, liters). Which requires a bit of math to get from the mass ratios you find in most documentation (i.e. the 6.5 oxidizer:fuel you found), but you have all you need within the resource definition (i.e. density). Though, you might want to make an entirely new part config for your repurposed engine, since that kind of engine will have wildly different Isp from the Orbital-type that the LV909 is. That way you won't have to use really odd Isp multipliers (which just feel like an oddity waiting to happen for me). If you want to mess around with it (or just to have a place to verify some math), you can punch in some configs here: http://bit.ly/rfstockalike It's for the Stockalike pack, but it's based on realistic numbers so any RF config should come out alright.

@lurkoholic: Ok, figured out what I did. I fixed the SDHI issue a while ago, came back to that file and added a check that I thought would help. Turns out it broke it. Reverted that change back, and all should be good now. @karamazovnew: You could shorten up your definition, if you wanted to just catch all tank definitions. Try this: @TANK_DEFINITION[*]:NEEDS[RealFuels]:AFTER[RealFuels] { %baseCost = 10 } Same idea goes for the TANK nodes.

FSMeshSwitcher you can leave alone (as it simply changes the mesh/texture). To get varied fuel loads, you'd probably have to create new tank types and set each TANK within that to use different utilization numbers. It'd be a bit of work to get working. Probably your best bet is to clone the Default tank from RF, change the name to OPTDefault (or whatever), and then multiply the TANK utilization numbers by a scaling fraction (i.e. @utilization *= 0.5).

The stock module does work with multiple fuels. It just doesn't use multiple thrust transforms/vectors. If you have a 4-way RCS block it only uses one axis. NathanKell mentioned this a while ago; he knows more about it than I. There may be things I am not remembering. But either way, Haze-Zero, posting the config would help to eliminate any other errors.

ModuleRCSFX does exactly what you want. http://forum.kerbalspaceprogram.com/threads/92290-0-90-ModuleRCSFX-v3-5-19-Jan-15?highlight=ModuleRCSFX The one-direction issue is a known bug with ModuleRCS, so they fixed that with this mod (and some other things). EDIT: Changed the link for the thread, thanks sarbian. Google search failed me.

You can't multiple volumes on a tank, but you can have multiple tank types available. Check the B9 Aerospace configs for Real Fuels (it's bundled in the mod), and you'll see some examples.

Ok, I'll double-check my SDHI part of the config tonight. Probably something I tweaked that broke it.

Argh. I thought I fixed these things. Which means that all of the updates I just pushed have to be redone. What's worse is that I don't know what I changed to make it work again. But it is working (just tested the app). As for SDHI, I thought I fixed that too. It's in the Fuel_Conversions.cfg file. If you remove that file, does SDHI work again? Also, does it work without Stock Revamp? I don't have that one installed, so there may be a conflict with that as well. Really, if you have some time, I'd need to know which of the following combos work with Stockalike: SDHI + Revamp + TACLS, SDHI + TACLS, and Revamp + TACLS. That way I can at least figure out where to begin beating up the code. This Conversions file is a royal pain to make sure it works!

I'm pretty sure that the cost of tanks (procedural or otherwise) are only for the dry tank. Can't say for sure, since I generally play in sandbox, but I'm fairly sure the game calculates the cost of the fuel onboard as separate from the tanks. Tweakscale tends to do odd things if you don't pay attention. I'd bet it's pulling a defined number for cost somewhere (probably in the part's config) and Tweakscale isn't realizing you've changed the number. I only understand TS on a basic level, so take that evaluation with a large grain of salt.

Cool. Helium does actually get used for RCS (or it will shortly). UH25 I thought was used somewhere, probably either in KOSMOS or Bobcats Soviet engines. But yeah, there's a few posts about the sheer number of fuels, and the fuels that no rocket should ever use (I'm looking at you fluorine/chlorine!). Thanks for the catch. Fixed on the repo.

Ok, just pushed a rather large update to the repo. If anyone has some time, download the newest files from the repo and let me know how they work for you. You shouldn't notice anything different, so if you don't see anything different about the setup that's a good thing. It's dealing with some housekeeping and the flow mode stuff mentioned above. Also, lurkaholic made some configs for the Sea Dragon 2 mod. Which is probably one of the most kerbal rockets ever designed in real life. Thanks again!

Don't worry about doing the SRB curves for existing just yet. I'm planning on a mass-upgrade (scripts are fun!) once I settle on some nice defaults. Then if needed we can go through each and tweak as needed. The crossfeed stuff is part of the "housekeeping" I was referring to. It changes more about RealFuels than Stockalike, honestly. I just need to make sure I define the flow mode in the engine configs to make sure it's working properly. Which is complete for the generator. The only one's we'll need to figure out are the oddballs or one-offs (like the dual-mode SpaceY engines) and anything that is in the configs but not in the webapp. I think I have a list based on past commits, so hopefully that'll be easy enough. But, no worries about the crossfeed/flow mode stuff. If anyone else has some insight/suggestions on SRB curves, feel free to chime in. I'd rather have as much feedback upfront I can before I make sweeping changes. Do note that the thrust curve additions (or the flow mode changes) shouldn't affect any craft in flight, it should only affect new flights. So, let me know if you all have any ideas.

Yeah, RCS is what I've been working on today. There's a button there to set up a standard RCS setup, which you should start from. It'll get all the standard mixtures set up, and give you good starting values. You can do wacky things still, but RCS "engines" are a bit different than normal rocket engines. There are also some housekeeping-type changes coming down the way, which I needed to add to the webapp. Shouldn't affect anything directly yet. But, the error is technically "working as intended". The app assumes you have a "Solid" tank with a volume specified. It's not apparent on the front end (my fault, I'll see if I can throw up a notice or something), but once you add a MFT tank to the config it'll work. It's a divide-by-zero error, because % Case is dry mass / wet mass, and wet mass needs a "tank" volume. If you have no volume, it throws an error on that function and stops the rest of the calculations. Jet technically doesn't work at all yet. I probably should just remove it, but it was in the original XLS so I decided to have the framework there. Honestly, you'd be better off using Advanced Jet Engines. It's like Real Fuels is to rocket engines, AJE is to jets/SABREs; it takes care of all the configs and works with RF out of the box.

The app itself should be working. If you have trouble with the webapp, let me know. I'm on it currently doing some testing, and it's giving configs properly. Once in KSP it's a bit different, but if you're getting errors with them in-game, let me know as well. For the SRBs, I don't have anything set in stone. I was thinking essentially for the Solid type (i.e. launch types) motors to do the Decreasing Dip, Steady Dip, and Steady curves. For the Solid+ type (i.e. vacuum) I was thinking the Decreasing, Steady, and Pulse curves. Sepratrons and their like should probably have the Pulse and Steady curves. Essentially, the curves that would be the most useful to the SRB. Don't know what the increasing curve would be useful for; maybe some sounding rockets or something, but definitely nothing manned. I'm open to ideas about it, since I haven't actually done any heavy lifting to put them in.

@SpaceHungryMan: 1) Percentage Case is the percent of the SRB mass that is the case, i.e. the "tank" holding in the pressure/exhaust and forcing it in the right direction. And yes, the idea is to keep the Goal % Case and the % Case roughly the same. Basically, that keeps SRBs grounded in some reality so we don't get 1 ton dry mass SRBs that push 20 MN of thrust! 2) Steady Dip and Decreasing Dip have a "dip" in the thrust curve. It's not specifically for max-Q, but it tends to work out that way. The curves are all at this link: http://www.braeunig.us/space/pics/fig1-14.gif Thrust is vertical axis, time is horizontal axis. 3) Don't worry about the dedicated tank for now. It was at one point for parts like SRBs, the Gemini Transfer Stage from FASA, and any other part that had an engine and tank together. The assumption was that you would obviously be using the tank for the engine, so it automatically fills the tank. It caused problems (not sure if it was RF code or somewhere else), so NathanKell removed the option. I left it in the webapp as a placeholder (it's also in the XLS), but currently it does nothing. And double check your configs from today if you've created any. I've been doing work on it all day, so there may be odd things and/or errors in anything you've pulled down today.

I've pushed a new release for Stockalike. The dev version was adding a few too many features that weren't fixed properly in the last release, so I just decided to make sure all of the new fixes and updated engines were released. If you're using CKAN, the update should push soon (I think within a day). The update is really just getting the Fuel_Conversions.cfg to work properly, adding some new engines, and upgrading some other engines. Let me know, as always, if something needs work!

I've pushed a new release for the Stockalike configs. Grab that from the repo (should be v2.1.3) and see if that works. If you have any more issues with it, stop by the Stockalike thread (link here) and let me know what's up.

I play mostly in sandbox. Career is a bit too grindy for me. Once you get to 6.4x scale and above it becomes more of an engineering/design challenge (which I like better than grind). I hope they make the launchpad weight limit a mod-able number, otherwise larger scale stuff just doesn't work for career. I mean, 7.5 km dV in stock gets you to Jool's SOI. In 64K it gets you only to orbit. Full RSS, just an expensive lawn dart.

Technically, yes, I could globally apply all curves to all solids. But it just seems like overkill to me. The payload assist motors don't need a dip in thrust for max-Q, and sepratrons (and their siblings) don't really need a curve (though the pulse curve might be useful). Plus, they need to be added to a CONFIG node, which requires a config for each curve you want. Having 7 configs for each SRB might be a bit much. Delta-V won't really be changed by a thrust curve. You'll lose maybe 1% of the total when the thrust drops to minimal. Honestly, your effective delta-V goes up if you use the appropriate curves on launch because you don't waste as much dV fighting drag. What will probably happen is that Solid-type will get certain curves, and Solid Plus-type will get another set. And maybe sepratrons will get a third set. Maybe this weekend I'll get it fixed, since the snowstorms might finally be over!

I haven't gotten to implement the curves on all of the existing solid motors. There's actually quite a lot in the set, and there are quite a few that I'm not planning on a curve for (i.e. Sepratrons, et al). I was thinking of "defaulting" the current SRBs to the stock "curve", the shuttle-type curve, and the "steady" curve. Most of the other curves would be application specific, and we can fix any solids that need them one by one. Though, if anyone has feedback on that, let me know. Made my note in that thread. As such, the default flowmode for all RF resources right now is STACK_PRIORITY_FLOW, correct? So if I were to set up defaults for engines, I would assume it would be that. RCS should be STAGE_PRIORITY_SEARCH for crossfeed purposes anyway. I was also thinking of doing this in a global MM config to catch all ModuleEngineConfigs nodes and just making sure all PROPELLANT nodes have the proper flowmode. You see any pitfalls with that? I can't think of a single engine that wouldn't use STACK or any reason not to globally define that, but just making sure I'm not missing anything.

For RF Stockalike, I probably won't touch the costs, since I'm already scaling Stockalike engine costs to stock anyway. That said, I probably would want the flowmode to remain like it is currently in RF. So, yeah, I'll "sign off" on updating the Stockalike portion to contain any flowmode changes needed.