dreadicon

So, had these around for about a month, was encouraged to share them by some friendly fellow modders. It's just some syntax highlighting language settings for use with Module Manager files in Notepad++. Please give any feedback, and/or feel free to make your own highlighting based on this. INSTRUCTIONS Download the xml Notepad++ language config file from here: https://drive.google.com/file/d/0B2WmuS1jXmpXMl82WTl5QnRXclE/view Just save it, then in Notepad++ go to Language -> User Defined Language -> Import... then select the downloaded file. Finally, restart Notepad++, load up the MM file, and then go to Language -> Module Manager (near the bottom) Note that because MM doesnt use a unique file extension, you will have to select the syntax highlighting each time you open a new file. There is also no intellisense/auto-complete either, as Notepad++ custom syntax highlighting is quite basic currently (without diving into manual XML tweaking, and even then) LICENSE If relevant/needed, license is EPL: https://www.eclipse.org/legal/epl-v10.html Think of it like a compromise between LGPL and BSD/Apache. Basically, you can make derivative works, and do as you wish, with the caveat that changes are offered upstream, and copyleft only kicks in when the source is made available. For purposes here, I am making a single addendum as follows: 'available in source code form' refers to when the creator of the derivative work allows for further derivative works of any kind, not when the source is available. (otherwise this is basically just LGPL due to the work being inherently in source code form) Let me know if the license is a moot point, or violates anything! A PM to me with the new language file would suffice for the upstream requirement.

There's no problem with pointing out things that need fixed/updated or even suggestions, as long as you understand that as this is one of many things in my life, I will get to it in my own time if I can, but there is no guarantee it will ever be fixed/updated, much less when. You can be rather pushy, and I encourage you as I did in another thread to be more humble and appreciative to modders in general, but the information itself is appreciated. I receive email updates from it daily, and just to be sure I don't miss anything, check this thread every now and then anyhow. If I don't reply, I'm probably busy with wife, health, job, local friends, family, another hobby, or some recent obsession with another game or field of science. Most of my posts here are lofty aspirations and the things I would do if I had the time and energy my job consumes. Sometimes I find time, sometimes I don't. Usually I have partial work or progress on a task, but get stuck and/or loose motivation at some point. Sometimes I come back to it, sometimes I don't. But anyone wanting to continue my work in any of these aspirations is free to PM me and ask to pick up where I left off; I would always be happy to discuss things and pass on what I know. So long and short; I am still here and fiddling with mods and code. KSPI-RF config has minor issues, but is much better than before for now. TACLS-RF-KSPI is still a WIP. I am not currently working on either config, though that does not mean I won't some time in the near or far future. I have been looking into some other mods to try and help them out as they are floundering a bit, such as Kopernicus, Procedural Dynamics, and Real Heat. Each has different hangups, but I am toying with them, trying to solve problems and improve them. Feel free to report things; if/when I get back to working on the configs, this information will be helpful. As always, suggestions and bug reports are welcome, but I make no guarantees as to if/when updates and progress will happen. Unless someone was to pay me enough to quit my job, that's the best I can offer! lol.

Sounds good. I started poking at the PQSMods again. I am not quite sure how to handle them, as a handfull seem to be implemented already in 2 or 3 locations, so any dynamic loading system would have to have exceptions built in to ignore them. Things get more complicated when you consider if it's an update, no-update, or an overwrite system. Because the loading is dynamic, I also don't see how I could leverage the node extensions that Kopernicus uses, and may instead have to use just stock node functions. It's kinda a mess... But I will try! PQS full configs support, imho, are the last requisite feature before Kopernicus is usable for practical purposes.

rofl, 'years? bah, I'll just comment out a line here and.....done.' Overhaul looking as amazing as ever. Really glad to see development back in full steam again inspired me to head back over to Kopernicus and give PQS a second try (i'm not a major dev for it, just trying to help the real devs while they are busy). Soon as the blue haze is gone, I'll be using the overhaul all the time, personally. It's amazing!

So, couple things; first, the black streaks are consistent with my experience. There is supposedly another command line option which helps with this, but I cannot recall what it is, nor can I verify that it works. Second, I tried loading up KSP with the DX11 option last night a couple times, and LOD fails to initialize. Gives the same message I get when I run in OpenGL. However, with DX9 or no command line option, LOD initializes normally. Will double check my setup this evening. Tried with and without EVE, ATM, and Texture Replacer. Windows 7 64-bit. KSP x86. @Bit Fiddler, shouldn't have to do anything special concerning DX9. KSP on windows launches in DX9 mode by default. If you don't have the full libraries you may have to install them (as per the OP), but usually that's not an issue.

Interesting, I will have to check this out later. iirc, there was some issue with LOD on DX11, but my memory could be faulty. If that is the case, then yeah, this just has to be made compatible with dds files/ddsloader directly. A side note, DX11 is known to have some minor glitches, and isn't quite as lightweight on RAM as OpenGL, but it's still an order of magnitude better than DX9 for memory usage concerning graphics.

correction: dream of this and ddsloader working together on directX 11 and/or OpenGL with stock dx9, ddsloader just speeds up load times and reduces the space on your disk; there is no sizable benefit to RAM use over ATM (for this or for ddsloader) without directX 11/OpenGL, unfortunately. None the less, it's a great step forward for KSP for those who are not running more than a few modpacks and a step in the right direction for KSP optimization in general.

The plane parts look awesome! Have you considered giving them small lift values? Not enough to get them off the ground wingless or anything, but planes with shaped bodies like these often have a small degree of lift from their own shape alone. Just a thought Will have to check it out later!

Hey, just wanted to drop by and mention a couple things: First, thanks for accepting my pull request. I am happy that my work seems to have been of use! Second, take your time with the next update; I would like to state that I noticed some of the configs I submitted could use some tweaking. They are definitely much better than nothing, or even the previous configs, but MM is displaying (far as I can tell harmless) errors on them; specifically the config for KSPI, and a couple engine configs got added to Raptor's configs appropriately, and should probably be removed from the KSPI-RF config. Which leads me to... Third, between an upswing in work and recent oral surgery, I have been out of development for a few weeks, and do not know when I will be able to continue updating the configs. I have not had the time to find the problems in the configs mostly; if someone could identify where they error or at least which part fails to be updated in the game (for those who don't know MM), and let me know in my thread or via PM, I will be much more likely to find enough time to fix the configs. I apologize for the lack of support for the configs I provided. Finally, Northstar, while I appreciated the feedback provided at times for my modding endeavors, please do not push an issue with mod devs. This is our hobby, not our obligation. If a modder don't answer your post regarding a change to their mod, it's likely not because they missed your comment, but because they are either undecided on the subject and want to think it over, or are too busy spending their free time modding to engage in debate and discussion when the decision is ultimately theirs how they build and manage their mod. Once you have added your voice, give the modder a few months if they don't respond before following up. I do not speak for any other modders, but having been a part of several modding communities for some time, this is how they tend to feel. I apologize if I have offended you or any other modders in this statement; if so, please accept my humblest apologies. -Dreadicon

W00t! You added partial support for RetroFuture! Thanks so much for it! I know maintaining/expanding a mod is no small task ( I've done it before myself). So I appreciate any and all work I can't wait to go try out the new AJE parts!

I just wanted to drop by this thread as well and give a real heartfelt thanks for rescuing my KSP dreams. I recently hit the point where even ATM plus -force-OpenGL mode were not enough to prevent memory crashes. But once I used Lilleman's conversion tool on the entire gamedata folder, using -force-opengl pulled my memory use down to 2.3 GB! My RAM worries are completely gone! At least, compared to the 3.7 GB I was hitting before, which insta-crashes once I try to go into the VAB/SPH. (Before anyone says this is impossible, I have done tests. For whatever reason, dx9 gains no RAM benefit from pre-converting textures to dds, but dx10, dx11, and openGL all display a massive reduction in RAM usage, on the order of about 35% for me)

Regarding the idea of Jet Engines as their own parts, this sounds like a great idea to me personally. It would be a step towards modular/procedural engines, as you now have 3 parts of an engine to choose: intake, engine, and nozel. Even if the Nozel does little to nothing generally, it's still a factor in the overall implementation of the craft.

BahamutoD's "B Dynamics Pack", found here: http://forum.kerbalspaceprogram.com/threads/82341-24-2-B-Dynamics-Retracting-vectoring-engines-etc-v1-1-1-%28Aug-11%29 The engines are beautiful and sleek, even if there are only 2 jet engines in it. Concerning the X-51's technical specifications and performance (theoretical and otherwise): (starting at slide 10) https://www.aiaa.org/uploadedFiles/About-AIAA/Press_Room/Key_Speeches-Reports-and-Presentations/RMutzman_and__JMurphy_X-51_Development_2011.pdf I know it's not exactly a clean data sheet, and definitely still in prototype phases, but those are the real-world test results from the X-51A (a second flight has been made seince, but I could not find good data on it). This is a whitepaper by Lockheed from 1987 that has more information about propfan engines than I think anyone would ever want: http://cafefoundation.org/v2/pdf_tech/Noise.Technologies/NASA.1987.Prop.Noise.PropFan.pdf And a much more recent and performance-oriented document from 2010: http://dspace.mit.edu/bitstream/handle/1721.1/58080/639280401.pdf?sequence=1 Let me know if you need more info, and I can go digging. Or if it's just not feasible at this time to implement (too much work/time/effort). And thanks for at least considering these engines!

hey! thanks for the idea of using the 747 as a reference! And the picture provides a great reference for fuel contents! After re-checking my numbers, I am not sure where I was going wrong. But the numbers all make sense now. I am having trouble tracking down the volume of the 747's wing itself though (not the fuel capacity). I could theoretically just base it off the weight, but.....not preferable.

Just wanted to drop back in and inquire briefly if Hypersonic engines are being considered, and to give a big motion of support for utilizing engines from more mods, such as Retro Future and BahamutoD's pack. The two shortfallings I have encountered so far functionally are the lack of propfans and SCRAM jet engines, despite real world statistics being available for both. And graphically, the mod could really use some variety....

I apologize if this has been mentioned prior, but what in the name of all that is kerbal is the black magic equation used to divine the volume of a given tank by it's dimensions? closest I have come up with is cubic meters * 1000(liter conv) * 0.25. ish. Is this right? is there a logic to it? Am I seeking that which does not and cannot exist? I only ask because I am getting close to finishing fuel-filled Procedural Wings, and now that I am getting down to the nitty gritty of exact maths, I find myself perplexed. Another question, which tank(s) would be most appropriate for a wet wing? Or if none of the existing tanks are, could someone with more knowledge of real life wet wings give some suggestions for a tank config? (utilized space, mass per liter, etc) Thanks for a great mod as always! And to anyone who can lend some advice/comments! EDIT: disregard about the black magic; I was tripping over the numbers somewhere. Maths all work out now!

I love the idea in general, as previously stated. I also think that a UI could be a good addition; Life Support/generators could use a common interface anyhow, and such an implementation would be easy for someone else to utilize as an RPM module. Another idea would be to make the core and shroud one part, and have each part attached 'registered' with the core-shroud combo. In this case, each core comes with a togglable shroud. the right click menu then shows the 4-8 nodes, and you has a toggle for each. Shroud/no-shroud could work as a toggle just as it is now, except the toggle is on the core rather than the wedges. As always, amazing work all around!

So, it was my mistake about satellite icons. What i was seeing was, in fact, the landing site icons from Kerbal Konstructs. They are replaced by SNES glitch screen patterns Not a biggie though. Don't worry about dx11, I just included it for completeness. I am using OpenGL for all examples going forward (because dx9 gains no benefit from this RAM wise, far as I can tell) I do want to point out, however, for whatever reason, there is a very, very clear RAM usage reduction resulting from this mod for me when running as OpenGL or DirectX 11. It reduced my RAM usage by about 1.3 GB over OpenGL + ATM alone. I am guessing it has to do with how dx9 keeps all textures backed in system RAM, with no alternative option. But that's just a wild guess. Concerning the missing textures, I will get you a screenshot when I get home from work. Basically, the parts are 'invisible'. their tiles show up in the editor, they have stats, if selected they have nodes with which to attach them, but the models and their textures don't show up at all. I will also have to do some control testing on this to make sure it's not some other mod. Off the top of my head, the Poodle and Skipper engines were affected, along with most of the rest of them. Again, will do proper research this afternoon; the least I could do to repay is to offer good, well-researched feedback. I can also confirm that ATM 'works', in so much as it doesn't crash the game, or make anything worse. I believe ATM does also reduce memory use for some things like EVE which cannot pre-convert to dds, but I don't have numbers to back that up. An odd side effect seems to have been a massive speedup in my framerates overall (in-atmosphere flight still laggy, but that's just FAR). When in orbit or parked on the ground, or in the VAB/SPH, I can get double previous framerates (though lag spikes still abound, but that's not new). My load times are moderately improved, but load times were never my main concern. Finally, I just wanted to thank you again for all your work on this (and, of course, sarbian for DDS Loader). This obliterated my RAM troubles when using OpenGL like no other method could. I had RAM to burn after this (which I promptly used on EVE and visual enhancement packs)

So, I can confirm that, at least with OpenGL or directX 11, this does something no other mod has been able to do. It makes my arrangement of mods playable. 'nuff said. Not saying this will work for everyone, but it worked for me. some stats: Directx9(Vanilla): crash @ ~50% progress (out of memory) Directx9 + ATM: crash @ ~80% progress (out of memory) Directx9 + ATM + LoD: crash @ ~90% progress (out of memory) OpenGL + ATM: loads @ 3.6 GB, crashes on VAB/SPH (out of memory) DirectX11 + ATM: Crash @ ~90% progress (out of memory) DirectX9 + Full DDS conversion: Crash @ ~80% (out of memory) DirectX11 + Full DDS conversion: Loads @ 2.6 GB; Runs generally stable with some texture artifacts (black or missing textures, mostly in stock assets). Peaks at 3.0 GB usage while running. OpenGL +Full DDS conversion: Loads @ 2.3 GB; Runs generally stable with sparse texture artifacts (mostly things like toolbar icons or PartCatalogue icons). Peaks at around 2.6 GB My GameData folder before conversion was 2.6 GB. After DDS application, it is 1.7 GB. Definitely some glitches and oddities to work out here and there, but this is wonderful news for me and my KSP endeavors! Edit: after more thorough investigation, looks like almost all the squad engines and about 4 of the tanks are broken by the conversion to DDS format. Looks like this is because, for whatever reason, Squad decided to put the textures in entirely different folders than the configs and models/meshes. perhaps some MM configs or an exemption could fix this? Will play with solutions as I have time. Just thought I would give a heads up. Also, the stock satellite/orbital icons seem to be broken, as do some mod icons for the toolbars as mentioned prior.

Hey Faark, here's the log file you asked for, along with an updated KSP log file (this is with default options + ThumbnailCompress, as this makes it the furthest in the load; up to 254-ish out of 1500 or so): https://drive.google.com/file/d/0B2WmuS1jXmpXbnAtdXN6cEh6NXM/view?usp=sharing https://drive.google.com/file/d/0B2WmuS1jXmpXMks0TzNRZUZYbjA/view?usp=sharing KSP doesn't seem to be running out of RAM, at 3.2-ish GB it is below the threshold of imminent doom. Also of note, I have had to remove B9 aerospace and MKS/Karbonite to pull the ram usage down to where it makes it to the main menu without crashing. I am hoping that once initially loaded and cached, I can add mods back. If not, at least I am providing testing and feedback! lol I really appreciate all the work you are doing on this; it's no small task! Edit: if the issue really does stem from dx9 and dx10/11 fixes it, you could always try to implement dx11 support, and see if that helps. you can currently open the game in dx11 mode with -force-d3d11 command line option. Just a thought if that might be easier. Edit2: looks like this may be the case. dx11 crashed just before finalized loading on my fully modded copy at 3.7 GB, while OpenGL managed to scrape by at 3.6 GB just before loading, then successfully loading. dx9 crashes half way through, not even making it close. So from what I can tell, dx11 saves almost as much ram as OpenGL. LoD is clearly not working with it, however.

Getting crashes right after load. Attaching logs. Not sure what is causing it; may be the sheer quantity of mods, but this number of mods is what just barely broke the RAM limit using ATM +OpenGL, so I was hoping ATM +LoD could work better... I've tried both with the new texture options on and off; same results. Nuked the LoadOnDemand folder in between just to be sure. I appreciate the work on this none the less! https://drive.google.com/file/d/0B2WmuS1jXmpXdjFiMnhKRFF2b2s/view?usp=sharing

Really glad to see work continuing on this. I still can't wait to try it out!

I am still standing by on the PQS Mod details. If I could just get some simple documentation on how it's implemented, I could handle the rest and just submit a pull request. But as it is, the code has been too difficult for me to follow confidently.

I see. I will have to look into fixing this. I just had a wisdom tooth removed, so it may take me between 3-7 days, but seeing as this isn't an edge case, I should do something about it. I have a couple ideas on how to fix it already, but it may take a few days before I can write them up confidently.

@Northstar1989 Have you seen any in-game flaws with the new configs? I examined the KSPI code carefully, and I removed any MM configs that were obsolete. There are no longer any ATMOSPHERIC_RESOURCE_DEFINITION modules in KSPI that refer to Oxidizer, so I simply removed them. I will probably add one for oxidizer some time just to be safe, but unless you've seen it actually cause issues, I am going to assume my assessment is correct. This is the current resource definition folder for KSPI: https://github.com/FractalUK/KSPInterstellar/tree/master/GameData/WarpPlugin/PlanetResourceData I covered everything there, and duplicated the resources in oceanic for atmospheric, and vice versa. Methane's name definition doesnt change, so there is nothing that I need to do there. What I am writing here is a conversion script, not a tweaking script to add stuff that isn't in KSPI. Therefore, if KSPI doesnt add methane to planets, my script wouldnt add it anyhow even if I put in the script for it like i had the other items. The Vista and Aluminum hybrid are both in the config I submitted for the core Real Fuels already with the rest of my configs last week. Kell doesn't mind pull requests, but I doubt he wants them constantly to fix minor issues that no one has even confirmed exist outside theory. the Vista and Hybrid are both fixed, unless Kell removed them. Also, the copy on my thread is not fully up to date, as it is intended for a different use (standalone) and I was focused on getting the one for Real Fuels proper done with. I will update the copy in my thread soon as Kell pushes the configs he pulled in to a release. Here's what the configs would be for Oxidizer and LqdFuel if needed. Methane needs no configs for Real Fuels in terms of planetary resources. @ATMOSPHERIC_RESOURCE_DEFINITION [*]:HAS[#resourceName[Oxidizer]]:NEEDS[WarpPlugin&RealFuels]:AFTER[WarpPlugin] { @resourceName = LqdOxygen } @OCEANIC_RESOURCE_DEFINITION [*]:HAS[#resourceName[Oxidizer]]:NEEDS[WarpPlugin&RealFuels]:AFTER[WarpPlugin] { @resourceName = LqdOxygen } @ATMOSPHERIC_RESOURCE_DEFINITION [*]:HAS[#resourceName[LqdFuel]]:NEEDS[WarpPlugin&RealFuels]:AFTER[WarpPlugin] { @resourceName = LqdHydrogen } @OCEANIC_RESOURCE_DEFINITION [*]:HAS[#resourceName[LqdFuel]]:NEEDS[WarpPlugin&RealFuels]:AFTER[WarpPlugin] { @resourceName = LqdHydrogen } Regarding electrolysis, you've provided sufficient evidence, than I very much appreciate it. I will add configs for it at some point, for some mod, weather it's TACLS, US, or KSPI. Finally, Nitrogen, IIRC, actually does have one very important use in modern spacecraft: offgassing replacement. Apparently nitrogen is very difficult to prevent from leaking into space, so replenishing the cabin supply is still a use