Wheffle

I haven't been on this part of the forum too much lately, but geez, I'm seeing a ton of hate for Squad! That's really a huge shame. I think there's definitely potential for KSP on console. I really don't even think controls will be a huge issue. Also, maybe I'm alone on this, but I actually trust Squad not to commit to something until they've thought about it and they think it's a good idea. Apparently they believe it will run well enough. I haven't looked into PS4 hardware but comparing raw clock speed is naive sometimes. Unity by nature ports well (they somehow stuffed the entire XCOM games onto tablets through Unity), and they're hiring another team to do the porting, so even worst case scenario it won't affect PC players or current development. Chill dudes!

Thank you for taking time to thoroughly explain! It's been a learning experience. Now that I understand a little better I'll make some changes and see what happens.

Thanks for the replies! Really super appreciated. Forgive me, I'm still a little bit lost. The changes remain when you launch the vessel, revert to launch or focus a vessel from the tracking station, as well as when you load the ship from a file in the VAB. What's happening different that only happens specifically on revert to VAB? In other words, if ModuleProceduralFairing's fields become non-persistent again (and ignore saved persistent values) every time the part is instantiated, then my code shouldn't work on launch or in any of those other circumstances, because I'm setting them to persistent in the OnStart() method which is running after ModuleProceduralFairing does its thing (I think). Maybe I'm not understanding the exact order in which modules load and perform their OnStart()/OnAwake()/OnLoad() methods?

You know, that could have something to do with it, but I'm not sure. All I'm doing is setting fields (which already exist) in ModuleProceduralFairing to persistent and hoping the dev's code behind the module does the rest. So far it works as expected in every tested case except revert to VAB. Does auto save have some kind of issue with persistent fields? //pretty much what's going on pf = getProceduralFairingModule(); pf.Fields["fieldNameHere"].isPersistent = true;

Oh MAN I'm glad someone came up with clamshell fairing breakaways. I've been MIA for a while with medical problems, so I haven't been able to look into it. Regardless I'm not well versed in Unity and from what I can see in the source code xEvilReeperx is quite the ninja. I like the idea of adding texture options. I will definitely look into it. I've spent some time trying to figure out why "Revert to VAB" forces the tweakables back to their defaults with no luck so far, and it's driving me nuts. I might shelve it and move on, though, seeing as how there is a reliable workaround.

Still no luck finding out what's going on here. Although manually re-loading the vessel after a revert-to-VAB is a reliable work-around, I'm still haunted by the apparent secret code that gets fired (or not fired) specifically with revert-to-VAB. I would assume all it does it change the scene to the editor and then load the autosaved vessel, but in that case you'd think manually re-loading the vessel wouldn't help anything. I'm not well versed in this, so any insight would be appreciated. Otherwise I think I'm going to shelve this unsolved mystery.

Oh SNAP! I'm SO glad you did this. I really wanted to get clamshell style breakaways working, but I've had some medical problems and haven't had time to really take a look. Looks like I'm off the hook!

Thanks! I don't currently have any concrete plans for adding more overlays, but I have been experimenting with modifying overlay textures and importing my own. I've run into a few weird hitches having to do with unfamiliarity with Unity, but who knows! If it gets asked for enough and I feel like it's a good fit, there's no reason it won't happen in the future.

I keep hearing everyone talk about how "time warping isn't fun" or "you've added 5 seconds to gameplay, congrats". I don't really understand this because by the same logic a thousand parts of KSP could be stripped down or streamlined that would remove the need to time warp, "shove a couple of solar panels on" or any other number of apparently mundane and overly realistic tasks that drag gameplay down. Electric charge just makes you slap on a few extra parts, why not get rid of it? Why is oxidizer a thing, why not just have one resource called fuel? We can pretend it's the right kind of fuel for a given craft. Why should I have to time warp at all? Maybe the game could just calculate my ship's delta-v and teleport me into the SOI of where I wanted to go. Waiting for launch windows is just time warping anyway, it's a waste. Why should I have to biome hop for science? Let's just build a lander that could theoretically cover lots of biomes, not do it, say we did and instantly get the science. Let's just remove night-time on Kerbin altogether because no one launches at night, and clicking "warp to morning" is not fun and "adds nothing to gameplay". I know a lot of people don't care about the instant orbital survey, but whether you think a more realistic approach would just add 5 seconds of tedium or not, I can't shake the feeling that it just doesn't match with the rest of the game. One of these things is not like the other. It doesn't present a problem or task with multiple design solutions, it simply feels like a "go here and do this" quest from an MMO. Kill ten wolves, get into a polar orbit, and then I will give you the legendary Map of Oregoth which you seek. Anyway, I already spoke my mind earlier I guess. I suppose it's unlikely that anyone will change their mind about it here. Mmmmm looking good! EDIT And for the record, I disliked how kethane scanning worked. The lack of background scanning sucked, and the tiny sector it would scan at one time was painful. Like I said in my earlier post, I feel like a possibly unrealistically wide "spotlight" approach that revealed large areas at a time would add a huge sense of discovery without adding a lot of tedium (plus background scanning, obviously).

Nah, time warp doesn't cheapen time. Lack of life support or maintenance costs do. But time is still important in KSP the way I see it, with transfer windows and such being a thing. If you play with many simultaneous missions time becomes even more important (I luv me some kerbal alarm clock...) With that same logic I suppose they should just do away with electric charge altogether.

I haven't really voiced my opinion on the matter on the forums yet, but I guess this thread is as good as any. KSP is a balance between realism and simplification for gameplay's sake, but I feel like they missed that balance this time. To me, the current resource scanning system (the initial survey portion with the M700) seems inconsistent and doesn't teach the player anything, removing the hands-on discovery that made me fall in love with this game. Why do I have to be in a polar orbit? Because the thingy said so. The current system limits choice. Sometimes I'm only interested in scanning for resources along the equator, but I'm forced into a polar orbit with my scanner regardless. It also don't take into account any logistic challenges that come real-time scanning, like maintaining electric charge or coordinating time frames with your other missions. I'm not saying I want SCANsat to be stock, but it would be nice to have some semblance of real-world orbital scanning mechanics. Personally I'd rather the scanner have an unrealistically huge FOV to make the process quicker and simpler but still show players why a polar orbit is needed to map the whole planet. That seems more consistent with the rest of KSP's design philosophy. But that's just my opinion! I guess I should be thankful in the end; the M700's behavior pushed me to try my hand at modding and I'm having a blast.

Well, i actually set ModuleProceduralFairing's own fields to persistant. I guess there might be code somewhere that only fires on Revert to VAB that doesn't expect those to be persistant, but that sounds weird to me. You didn't misread, i just didnt clarify

I've got a mod that allows you to tweak some of the fields in ModuleProceduralFairing. It also sets these fields to persistent so that on vehicle load those changes will, well, persist. When you load a vessel in the VAB, everything's fine. When you fly, return to the space center, and load from the tracking station, everything's fine. When you revert to launch, everything's fine. ... When you revert to VAB, all the fields revert to their default values. Is it normal for persistent values to act weird when reverting to VAB/SPH, or could this be a mysterious quirk with ModuleProceduralFairing?

Thanks for all the support! It's been a lot of fun putting this together, and it's been fun playing with it. I'm glad others are getting some enjoyment out of it also. To tell you the truth, getting the biome overlay working was stinking easy with the new stock resource overlay system. The KSP team did a great job making it general-purpose and easy to hook into. I expect ScanSat is taking longer because, among other countless reasons (that mod is CRAZY complex and very impressive), they aren't going to be displaying a full overlay all the time. They have to chop it up to only reveal what portions of the planet you've scanned. Me, I'm just yanking the biome map texture from the framework (which it hands over freely) and throwing it at the overlay system (which it happily accepts). Hmmm... it would be interesting to limit planet detail a bit at least until you've entered its SOI at least once. I'll toy with that idea a bit. As far as decoupling the biome overlay unlock with the resource overlay unlock, I'm not sure that'll be a huge priority just yet. My goal was to extend the stock orbital surveyor as seamlessly as I could, and decoupling those overlay unlocks would mean separating one or both from the stock "this-planet-has-been-scanned" system, which would complicated things a bit. I'll keep it in mind, though. I love the near future technology packs. I also have zero experience with modeling and part creation. I'm just a simple programmer. I get the feeling everyone has wildly different ideas for what is "realistic enough" for them, which is why I left it configurable. Again, I haven't tried it at very high numbers (5+), so I encourage you to try it and report back if there's anything wonky with it. I might change the default value in the future based on continued feedback.

Thanks for all the support! I just finished a decently involved update for another mod of mine, so I'll probably dig into this one again and see what else I can come up with as far as customization options and improvements, as well as getting rid of some annoyances. Yeah, I doubt that KW uses the stock fairing module. But, even if they did, my mod wouldn't affect that by default. Currently I'm inserting my own module manually into the stock fairing parts (with ModuleManager) that accesses the stock fairing module indirectly. I haven't checked out KW's proc fairings at all, but in the long-shot unlikely case they actually did use the stock module, a simple MM config that added my module to the KW fairing parts would hook in just fine.

Shameless promotion: If the way the orbital surveyor works really bugs you, I made a mod that tweaks the surveyor to make it take longer to scan, as well as provide a biome overlay toggle along side the resource overlay toggle for planets that have been scanned. The "scan progress" runs in the background so you can set your orbit up and then go do other things.

Updated to 1.2 It shouldn't break previous saves, but I can't promise anything. Just make sure to clear out all of the old files before installing the new ones. Biome overlay is now available! (without using the cheat menu!)

Working on an update.

I'm thinking about incorporating something like that into one of my current mods, an unlockable option to show the biome map after a body has been scanned by the orbital surveyor. I'm poking around to see if I can shove it into the knowledge base menu somehow instead of putting it in an app toolbar button. Edit Got a biome overlay button working, accessed through both the orbital surveyor's context menu and a toolbar button. Check out my Orbital Survey Plus mod.

Thank you! I automatically assumed the resource map functions were all specialized for resources, I didn't realize you could just throw it a texture. That is... extremely handy.

Sorry if I wasn't clear; I meant accessing the function through code in a plugin, similar to toggling the aerodynamic force arrows and heat overlay through the FlightGlobals class (iirc). I've rummaged through several static and non-static classes relating to flight mode, map mode and celestial bodies but I can't find anything that controls the biome overlay.

I actually think proc fairings look and behave a lot better than stock fairings, but I really love the level of customization the stock fairings offer, plus the exploded view that allows you to access parts underneath is beyond awesome. And being stock, the guarantee that they play nice with other systems is a plus. I've also heard a lot of people complaining about the way stock behaves with regard to inline fairings, but personally it's never been a problem for any of my vessels with inline fairings. My plugin alleviates some of the aesthetic issues a bit when compared to proc fairings. I'm hoping that given time I'll be able to find a way to get the sections to stick together on deployment, eliminating the "grenade" effect that everyone hates so much (i.e. a fairing tweaked with Divisions=2 will fall away in just two pieces like a clam shell). I'm fairly new to modding, though, so nobody hold their breath.

Does anyone know where to access the debug menu's biome overlay? I've been poking around for quite a bit with no luck.

Just went on a screenshot frenzy. Hopefully they are helpful.

Ha! Niche market I guess? I tend towards using the stock option whenever available for whatever reason, so I threw together this plugin for my own sake at least.