Raptor831

The master branch on the repo has the tank "fixes" if you want to test them. I think they'll work, but we'll see. As for RPM, I don't know why it would have a problem with Stockalike. If you remove Stockalike, RPM works properly?

I really want to say there has to be something that lets you know what kind of tank you're using, but I don't recall. Adding it to the right-click menu shouldn't be too hard though. IIRC from the last time I messed with plugins, it should be a variable you can access and display in that menu.

Thanks for the tip! Didn't realize that was there.

Went back 10 pages and couldn't find this. Say we have a Module like this: MODULE { name = MyModule value = foo,1;bar,2 } How do I test for "value contains 'foo'", and then alter 'foo'? I'm sure it can be done, but I can't find any of the regex stuff in any docs, and I can't quite figure it out from looking at other examples I know of.

Sweet! Yeah, in the VAB/SPH there's no visual signal that I remember to tell you. I just end up remembering that Default tanks contain these fuels, Cryo tanks contain the (insulated) tag on a lot of fuels, ServiceModule has ElectricCharge, etc. You can alter the tanks though, and all of that is done within the ModuleFuelTanks. For example, from B9: (comments mine) //-- snip --// MODULE { name = ModuleFuelTanks volume = 182 // type here can be Default, ServiceModule, Fuselage, Cryogenic, Balloon, BalloonCryo, and some others. B9 created special ones type = B9_Rocket // add as many of these as you want, they'll be available in-game to switch. typeAvailable = B9_Rocket typeAvailable = B9_ServiceModule } //-- snip --// You can do this with MM quite easily. So, for example, to add a Cryogenic tank to a particular part that already has a MFT: @PART[some_part_name] { @MODULE[ModuleFuelTanks] { typeAvailable = Default typeAvailable = Cryogenic } } Normal MM rules apply, so be aware of what node you're dealing with so you don't overwrite something important. In this case, you'd be adding two new typeAvailable tags, which may or may not already exist. You have been warned.

Good to hear. I'm going to see if I can have two sets of tanks (or at least merge them), though. Overwriting the LS tanks bugs me, since it's all so precise. EDIT: Updated the repo with a new release, also should now keep the old MFTs if they exist.

I only added it within the last week. Should be in v2.1.x. If you've got that, then it's obviously not working. I'll double check. You can drop a line over on the Stockalike thread if there's anything else you notice for that. Should just be changing "type = Default" to "type = Cryogenic" in the config. There should be a config (found here) that changes any ModuleEngine* to kerosene/LOX if it hasn't been touched by another config. This is supposed to include jets. I don't know of any reason why they shouldn't pick up any props. Does FS use a different engine module?

Correct. (10char)

@FreeThinker: It'd be really helpful for NathanKell and the rest if you submit a pull request for the edits you suggested. That way all they need to do is review it and accept it. @Northstar1989: The new tanks probably just haven't been set up by anyone yet, since they are still new. There's a catch-all fuel tank file in the Stockalike download now, which will convert any tanks still using stock resources to it's RF tank type. It's not perfect, but it does in a pinch. For the insulated tanks, you can write a MM config to add a Cryogenic tank instead of Default. That will make it insulated. Boiloff still happens, IIRC, but it's much less. And as for the hybrid engine/tank/heatshield (what kind of black magic is this!? ) those should probably be engine config territory. I'll add that part to my list for Stockalike. @Starwaster: Stockalike doesn't touch FS engines specifically, but anything that uses LiquidFuel and IntakeAir should get converted to Kerosene/IntakeAir just to make things work in RF. Jets and props are kind of special anyways. AJE pretty much hits them all now, so I leave it to that mod personally.

Ugh. Well, it helps if the syntax is right. Or at least close. And maybe the right Module. Sheesh, that was a boneheaded bug added by myself. You can see the changes on GitHub, but I was nowhere close to the right syntax! It should create the fuel tanks now instead of nuking any MonoProp it finds. Let me know if that works!

These are all essentially a 32-bit Unity problem. 32-bit Unity can only get ~3.5-3.8 GB RAM no matter if you have 4GB or 32GB RAM installed on your machine. It also matters not which graphics card you use (at least I don't think so). The psychedelic colors are basically "corrupted" textures in RAM or VRAM. Really, the only way around it is to reduce texture quality until you don't crash (or it becomes infrequent enough to not be an issue). You can do this by lowering the texture quality in KSP settings, using Active Texture Management, or both (which is what I have to do). Or, if you're feeling really adventurous, install Linux somewhere and use the KSP x64 Linux version and enjoy utilizing more RAM.

It removes the fuel tanks on purpose, because that's what changes the mass. If the pod has MonoPropellant it should turn it into a Service Module tank with the appropriate volume, but it'll leave it alone otherwise. EDIT: Release is up with these fixes (plus some extras thanks to Tellion). Also, do note that if you still have Mono_to_Hydrazine.cfg in your /GameData/RealFuels/ folder, you should delete it. I don't believe it'll mess anything up, but it's been replaced with a different file. Merging folders will not overwrite it.

Actually, the main module is SXT Heavy Orbital Habitat x2. There is a skin similar for PP from the FreedomTex pack. Smaller unit is FusTek, truss is the Speedy's Hex Truss System with a Procedural tank clipped inside. There's some AIES antennas on there, and KW for the RCS thrusters. NearFutureSolar for the panels (with some Tweakscale help), and some B9 omni lights.

Ok, I've made a change to the Fuel_Conversion.cfg file. It should prevent any pods from being change to near-zero mass. I had TACLS installed, which had placed MFTs in the pods already which kept this from happening. Let me know if it fixes the error. You can download the single file here: https://raw.githubusercontent.com/Raptor831/RFStockalike/master/GameData/RealFuels/Fuel_Conversions.cfg Or just download the whole repo if you'd rather. Once I confirm that this goes away for you all, I'll make a proper release.

Thought this would be appreciated here. First module of Freedom, done in 6.4x size Kerbin RSS. Still making tweaks, but it's the same general idea. Getting that into orbit is taking some doing though. 30 tons, or thereabouts. Launcher is currently inspired by the Saturn Multibody. I've got a few Apollo Block III+, Block IV, and Block V versions as well. If you'd like to see any, I'll post some screenshots of those as well. Making this stuff in KSP is a lot of fun, I have to say! And enjoying the new chapters coming out as well for ETS!

Ah, yes, that probably should be looked at. I don't play with the Engine Ignitor mod (yet) so the restarts tend to slip past... Thanks for the reminder.

Ok all, the configs are updated to a new version. OP is updated, and there's a pull request submitted on CKAN's side to update the name within that app. If you've been using the updates from the repo, the only big difference is that I updated ModuleRCSFX to v3.5. If you haven't updated since v2.0.6, there's a lot of file changes, which are mostly organizational. The new generator causes a few calculations to be slightly different, but nothing that's way out of whack. Generally, nothing about your current flights should change (since most of the engine data is persistent). Can't guarantee it, as always, so make backups if Jeb needs to come home. Let me know if you find any other issues/bugs/oddities.

Just gotten to checking the configs. Looks solid! Good job.

Ah, I see what you mean now. That could be a problem. I'll take care of that as soon as I can.

Are you doing the tanks, the engines, or both? EDIT: Both, I see from the Tantares thread. If you'd like, I can include the engine/RCS pieces here (so the engines are all in one place). I don't usually play with Tantares, so I had to guess at what would be appropriate for the config.

The conversion rates are pre-computed to volume units (liters in this case), so they should respect conservation of mass and such. At least based on the "fact" that Karbonite is CH4NO2 (which is arbitrary anyway...). If you check out the XLS document on the repo, you'll see the calculations going on to get from liters to mass, do reactions, then mass to liters. The formatting might not be a bad idea. If it doesn't make using the XLS a big pain, I'll adjust that.

That should be doable. When I push the next update, I'll be sure to push an update to the CKAN directory as well.

...because that's definitely the biome map for RSS Earth! Yeah, I'd install RSS fresh, get 6.4x and overwrite everything, and make sure that you remove the .obj files from RealSolarSystem/Plugins/PluginData. 6.4x will need to regenerate those (and it will take a bit of time to do so). I probably should include those in the release at this point, since the newest RSS caches those on disk again.

Well, phooey. Thanks for figuring that out. Admittedly, I haven't messed with Karbonite in a while, so I've unfortunately been slack with testing. But, I did update my generator, so it should be corrected now. The removal of the stock modules was failing because the case was wrong on the specific tag. (it was using "converterName" instead of "ConverterName") Other than that, you were spot on. Also, @karamazovnew, thanks for your posting as well. Should have referred back to yours and I would have done this right the first time! In any case, new release (v0.1.4), OP is updated. As always, give me a shout if there are any more errors.

Hooray! I was hoping someone would take up the "NearFuels" idea again. RealFuels proper has a lot of fuels and it's a big turn off to some people. You can do this via the engine configs. It's a bit of a roundabout way, but each CONFIG node can be restricted to tech level. If you can do this on all configs with the same mixture, that's done. I do that with the Stockalike configs for some engines. I'd be on the side of choice-over-realism. You don't have a crazy amount of mixtures that would be required for any one engine. Basically 5 for "normal" engines (kerolox, hydrolox, UDMH/NTO, methalox, hydrazine). 6 if you added UDMH as a monopropellant mix. RCS would have three mixtures if you went there. NTRs have one, possibly two if you add a trimodal-type engine (i.e. NTR with afterburner!). If you're really fancy you can probably do this with one generic MM config, at least if MM can handle it. As to your MonoPropellant problem, I'd just change the densities to match what you need. It's pretty easy to do a MM config to globally adjust the amount of a resource, so you can scale your density change to your resource change. For example, in my RF configs for Karbonite, I scale karbonite's mass down 1/5th, but increase the amount of resources in each karbonite-carrying part by 5x. Ends up with the same mass anyway. I'm not sure specifically how your math would end up. Alternatively, we're dealing with little green people in a game. If anyone is going to be upset with hydrazine or UDMH not being exactly the right stats, then they should be playing full-on Real Fuels anyway. In short, make the gameplay work the way you want, and fudge the numbers to get it that way. In any case, good luck!