Raptor831

@blowfish Sheesh... Yeah, I was planning on putting out a new version when I was sure it was good with 1.1.2 and RF v11. Guess that means now. EDIT: Updated the release and edited the OP.

If you just want ignitions on a stock engine, you'd almost be better off writing a plugin specifically for that. Or you could fork HoneyFox's code (like RF did) and go that route. There's too much going on in RF to undo everything to get down to ignitions. At least in a reasonable fashion. You could just remove the Stockalike configs and roll your own ignition configs. Just take the parts and add ignitions as desired. It'd look like this: @PART[partName] { @MODULE[ModuleEngine*] { @name = ModuleEnginesRF %ignitions = 4 IGNITOR_RESOURCE { name = ElectricCharge amount = 0.5 } } } But you'd need one for each engine. And I'm also not sure of any other "side effects" that would cause, so use at your own risk.

You're right, you didn't suggest that about the driver. Apologies, I read that too quickly. And thanks for the additional insight. Coding is hard, and I don't envy the people writing these drivers. I'm a web developer by day and that can be crazy enough! And yes, you're right, some sparkly lines in the SPH aren't game breaking. (And especially with my outdated hardware! Really have got to upgrade some day...) Still, if it can be fixed I'd love to see that. Did some research on my own about that ATI driver, and it seems to be a sketchy thing at best. Theres a Chrome bug report (https://bugs.chromium.org/p/chromium/issues/detail?id=543324) with similar results. So, is everyone else experiencing the "sparkles" have a Mac with an AMD card?

Well, I would update the driver except for the fact that Apple doesn't do it that way. Their card drivers come in from their OS updates, and they've specifically said they're not updating any old cards to OpenGL 3.x. Sometimes Apple kills me... Never had problems with it before in KSP, though. But Unity 5 might have finally crossed that line. It's odd that nothing else is goofing up though; I'd imagine that if it was an OpenGL 2.x issue there would be more wrong than lines on the ground...

@sal_vager Set the rendering to "Fastest" and it didn't work. I *think* I set the -force-glcore flag for the .app, but I'm not 100% sure of how to do that anyway. (If you have a link to instructions, I can re-test and make sure) In any case, here's a imgur gallery of what I see: The "sparkles" change as the camera moves, and if I set the light pixel cascades (I've forgotten the actual label at the moment) to 0 the sparkles stop, but the lines are just simply black. Player.log here: https://www.dropbox.com/s/zdu0q2kborns0ya/Player.log?dl=0

@SirusKing @blowfish Ok, digging through the log I'm finding these things acting on the SABRE medium in this order: AJE patch for RSS (line 4293) Normal AJE patch (line 4294) DRE patch (line 4596) The !AJE Stockalike patch (line 6972 from B9_modularEngines.cfg) The other Stockalike patch (line 6974 from B9_SABRE.cfg) RealPlume patch (line 7531) #4 confuses me the most, since I thought that :NEEDS[!AJE,RealFuels] would mean if AJE isn't found and RealFuels is found (i.e. logical AND). I think that's what's messing it up, since that'll nuke things in the AJE patches for sure. You could try removing that file and seeing if it works as advertised then. Re-generating the MM cache with your edits removed, SirusKing, would be helpful, just to see what the actual mods are doing. Also, FYI, usually when modders ask for logs it's the output_log.txt file. In my case, I can infer from either, since I only need notices. Anyone who needs information on an exception won't be helped there. EDIT: Corrected after reading output_log.txt

Can you share your MM cache and log?

I'm running OS X 10.11.4, so I don't think it's OS version specifically. My bet is it's an OpenGL shader thing. For me, if you rotate the view in the SPH the sparkling gets better/worse depending on the angle. It's some lighting thing or shader issue, I swear. Unity 5 had new shaders, IIRC, so it's entirely possible they missed one.

Ok, Real Fuels 11.0 is out. I'm going to start testing with the current version of the configs on 1.1.2. Please test things out, if you can, using the repo version (i.e. download the .zip and not a release). If you find trouble and want to post, make sure you let me know exactly what engines are not working, exactly what is not working, and preferably be able to replicate it with the minimal mods installed (i.e. RF, Stockalike, single part pack). MM cache, logs, and screenshots also help tremendously. Once I get at least a few confirmations outside of myself, I'll update the thread to indicate we're good on RF v11/KSP v1.1.2. Then we can add new goodies. EDIT: Initial tests for me indicate everything should be working fine (or at least as it was before).

@NathanKell Thanks for the hard work, both here and on KSP in general. Now I'm off to try everything out in 64-bit glory!

I can add that to the list, certainly.

@Svm420 Thanks a ton, friend. I had no idea that was down. It should be back up now. Apparently there was a software issue with the CMS which I had to fix.

Have this problem as well, but iMac 2011. Did some testing and it seems that setting the pixel light count to 1 or 0 in the graphical settings "fixes" the issue. No more glittering lines in the SPH, but a wee bit dark. It's also on the bug tracker here: http://bugs.kerbalspaceprogram.com/issues/7644 I'm guessing an OpenGL issue or some shader specific to the SPH got tweaked with the update. I can provide logs if needed, but I don't see any errors popping up. Doesn't really stop me from using the SPH though. However, my CPU usage triples from the space center view and I'm thinking long exposure to that flickering is going to give me headaches.

:taps mic: This thing still on? I'm watching Real Fuels for their 1.1 update to make sure these are still good. I assume it'll be fine as long as RF doesn't change much. @TeeGee @davidy12 I can add those to the "Please add these" list. But @blowfish is right, there's no way I can support every mod on my own, even if I'm fully active around here. There is a tool to create configs found here: http://bit.ly/rfstockalike You can make use of that to roll your own config sets, and you can submit engines there and submit a PR on the repo if you want them included. If you do want to submit some, just make sure they mostly stack up with the other engines.

Ok, for the "missing" plumes, you need SmokeScreen too, which I thought was a requirement of RealPlume. You do need RealPlume, but you probably shouldn't use a config set other than the ones provided in this mod's download. Svm420, as mentioned, did all of those to match the Stockalike engines and their "natural" fuel mixtures. You can use other configs to fill out the ones that weren't included, but it gets harder to troubleshoot the less "stock" your install is. We've gone over the plume issue before, but to recap: SolverEngines (which RealFuels is now based on) extends the ModuleEngineFX type of engine. Some older engines (like the LV909) never had MEFX built for them by Squad. And some older mod engines have the same issue. If you have engines such as these installed with RF/Stockalike installed and do not have RealPlume or HotRockets installed, the effects will go away. There's not a lot I can do about that, either, since this mod depends on RealFuels. And even then, there are 300+ engines in my "database" that would need attention if we were to make RealPlume a dependency. That's just too much for 1 person to have to build and test. They all would need to be checked in-game for plume positioning, since RealPlume only provides FX and default settings that won't necessarily work in every case. @Svm420 has done a great service by offering his time and effort to make a bunch of them. But if anyone else would like to take the time and fill out anything still missing, it'd certainly help a lot. I'll take the time again to thank the contributors to this mod. They are quite numerous now, so I can't list everyone by memory. But, there is an incomplete list on GitHub: https://github.com/Raptor831/RFStockalike/graphs/contributors I'd be quite a bit overwhelmed if it wasn't for everyone's help.

Honestly, I've done most of the "balancing" (if you can call it that) on 64K-sized stuff. Personally, I think it fits the best with that; that's what I use in my installs.

NathanKell is right. To explain a bit further, spinning up turbopumps to feed fuel into a combustion chamber is a non-trivial operation. You still need something to start them, and whatever means you do use you have to carry with you (i.e. it's a limited quantity). This applies to most non-orbital engines. Orbital engines and RCS systems that use hypergolics don't have that problem, which is why they have effectively "unlimited" ignitions. Even that isn't unlimited, because burning engines need to get rid of heat and suffer wear on moving parts. Therefore, engines are designed with X number of restarts in mind, or X seconds of operational use (ex: Merlin engines on the F9 first stage - 3 starts, so many seconds, etc). Because RCS is generally open a valve to release pressurized gas, it doesn't have as many points of failure; which means more "restarts". IIRC, the SM engine on Apollo was very restartable, but it wouldn't just restart forever. So, a lot of restarts. A hypergolic launch engine still has to push massive amounts of propellant/fuel through the engine to lift things, even if you don't need a starter "spark". TL;DR: Engine parts still wear out and need some kind of starting mechanism to start up turbopumps even with hypergolics.

Good to know. Thanks!

Mostly because you generally only want/need 1 of the resources. Also, how do you describe the process in a little tooltip? It was simpler to say "Make me LOX" or "Make me LH2". Yeah, there are places where just splitting it into LH2/LOX would be useful, but for almost any other combination, you can't get the whole mixture from one reaction. Also, in reality you aren't going to have one converter that can do all sorts of conversions. Each converter should be a processor of a single reaction, so you're not gonna get MMH/NTO from a magic box. And especially not in the ratios you want, since each engine in RF has it's own specific mass ratio. So, I figured it was simpler to just pick the resources you want to make individually.

The rate just was how much conversion was done in 1 second of game-time. It was really just to limit the amount of stuff going in/coming out of the converter. Doubtful RealISRU will pick up Karbonite. But really, it's more or less adding the right resources and amounts to each end. Doing the configs is the easy part. (Never liked chemistry in school!) I honestly don't know what the "new" syntax is for the converters/generators, so I can't say exactly how hard. But essentially it's doing chem/math and then making the same part over and over for each conversion. Edit: Heck, looking at KwirkyJ's stuff, the work might be even easier, since the conversionRate was dropped from Regolith back in the day. Might want to start there.

I just pulled a fresh copy of KSP, Kopernicus, and 64K and it seemed to work for me. At least Kerbin loaded up fine and in the tracking station nothing looked out of place at first glance. Anything specific that breaks? Also, post up some logs if it doesn't work. Not going to promise miracles, but I might be able to at least get it working...

Yeah, confirm I get this too at fullscreen. Unless the game resolution matches the system resolution, in which case all looks fine. Was starting to think my graphics card was failing... iMac 27" late 2009, ATI Radeon HD 4850 512 MB

Well, I have to say the new forums are pretty good, IMO. Thanks KasperVid (and everyone) for the hard work.

@ebigunso OP is updated. Thanks for the reminder. @DarthVader Just added that to the repo. Direct link: https://github.com/Raptor831/RFStockalike/blob/master/GameData/RealFuels-Stockalike/Stockalike_LazTek.cfg

Ullage will be affected however RF pressure-fed engines are supposed to be affected. ;-) Meaning, it'll probably still need to have the fuel settled. So I've heard, the Apollo SPS needed that even though it was pressure-fed and used hypergolic fuels. So it's not totally unrealistic. I forget how I traced that particular error down. The fuel_conversion.cfg changes all the pod monoprop/electricity stores to ServiceModule tanks, but chokes on that particular pod since SDHI/TACLS change the defaults (it gets rid of the resources, which is what that error is saying it can't find). I'll have to go looking for that one again... :-/ The :FINAL problems come in when mod authors use them to nuke some part of a config or make last second changes to it, and then another person needs to do something only after that has run. It's not really possible to do without some more MM shenanigans, which ends up being this untraceable mess. It's safer for mods to use :FOR[ModName], :BEFORE, or :AFTER since other mods/users can make use of the built-in ordering MM provides. If you're just doing some homebrew MM configs to adjust things (i.e., I put MechJeb into all command pods via MM), then :FINAL isn't as bad. In my example, it'd probably be better to run that right after the MechJeb pass. But no one's adding MJ modules in my mod stack, it doesn't conflict with anything.