Alshain

Well it's because it uses staging to jettison it, where as the other engine shrouds just attach themselves to the decoupler and jettison when the decoupler does. I'm not sure I can solve that problem, but I can exclude it from my patch and include the other shrouded engines. I'm testing it now. Ok, so this patch works for every engine except the NERV, Rapier, and Panther. // Add staging control to engines // Author: Alshain @PART[*]:HAS[@MODULE[ModuleEngines*],!MODULE[ModuleJettison],!MODULE[MultiModeEngine]]:FINAL { @MODULE[ModuleEngines*] { stagingEnableText = Engine: Enable Staging stagingDisableText = Engine: Disable Staging stagingToggleEnabledEditor = true } } @PART[*]:HAS[@MODULE[ModuleEngines*],@MODULE[ModuleJettison]:HAS[#isFairing[True]]],@PART[turboFanSize2]:FINAL { @MODULE[ModuleEngines*] { stagingEnableText = Engine: Enable Staging stagingDisableText = Engine: Disable Staging stagingToggleEnabledEditor = true } @MODULE[ModuleJettison] { stagingEnabled = False } }

Yes we did, but he did get what he needed. Same here but it definitely breaks the LV-N shrouds. That appears to be the only one.

@sebi.zzr It doesn't work for MultiMode engines as well I updated the patch in my database thread, but here is the patch. // Add staging control to engines // Author: Alshain @PART[*]:HAS[@MODULE[ModuleEngines*],!MODULE[ModuleJettison],!MODULE[MultiModeEngine]]:FINAL { @MODULE[ModuleEngines*] { stagingEnableText = Engine: Enable Staging stagingDisableText = Engine: Disable Staging stagingToggleEnabledEditor = true } } The problem with setting staging to false on the shroud is then I don't think the shroud will function correctly. Not a problem if you don't use it I suppose. My patch simply doesn't add the staging toggle to those engines. I haven't tried it specifically, but I think the patch you listed might produce errors. You need to add ModuleJettison to your HAS line as not all engines have it. EDIT: After some testing, it seems it will work on everything but the LV-N, which needs staging to discard it's shroud through staging. The others rely on decouplers. So I could further refine that patch to include more engines using your jettison staging disable and just ignore the LV-N specifically.

@WillThe84th See, that's just the problem though. It's not difficulty, it's tedium. It's kind of like the Hard Difficulty option we have now... it doesn't actually make it harder, it just adds pointless grind. Life support is the same, it's not hard... it's boring.

The Engine staging patch has been updated, you can now toggle staging on all engines! Special thanks to @sebi.zzr and @Xyphos for working with me on figuring it out!

I think I just realized what it is. The engines it doesn't work on have the possibility of an automatic shroud. That's the only thing I can see that they have in common. All the engines can be disabled as long as they do not have a shroud option when the patch is active.

Interesting. It must have been fixed since I last tested it. You can see in my database thread above that I had discussed it with NathanKell back in 1.1.2, and it was definitely not working. Maybe he got it fixed that quickly. EDIT: Ok, so it's working on the Spider engines which is really strange since they do use ModuleEngines and do not appear to use ModuleEnginesFX (The Twitch engine does use FX). However, it's still not working on all engines. It doesn't work on the Rhino and Mainsail for example. I'm not sure what the difference is, there are others too. I thought it was the FX module, but it must be something else.

But not all engines have adopted it yet.

My testing has shown that doesn't work on ModuleEngines. There is some conflict that prevents it from being removed from staging on any engine that doesn't use ModuleEnginesFX. It adds the button to the tweakables but it isn't functional. The threads a few months old but for the parachutes (and everything stageable except ModuleEngines) I have patches listed here allow you to disable them.

I didn't mean the NCS Adapter was meant to be a tail, I meant it matched with the tail. (NCS actually stands for "Nose Cone System") They can be paired and cause the same visual separation. Texture markings to denote any function is a silly idea. I know it's done already but that doesn't mean it has to. Textures are for one thing, appearances. The detailing on this part as well as the wings and the tails prevents your craft from looking like a sheet of paper which is visually unflattering. I do wish the detail coloring was a bit more consistent though. I know there is a mod for that, but 3 different shades of grey is a bit irritating to match.

You could add a license file to the zip files, I think drop box would leave the links the same. Your mod was made LONG before the rule was put in place, but new mods today are required to have that anyway.

That's the best reasoning I've heard so far, but really I think this black band is made to match other pieces like the tails.

I don't like pop-ups, but I also don't like the 1/2 second (seems like) yellow text that you can't read because UI or mods are in the way. What I would like to see is a persistent notification screen. A sort of e-mail like interface where new messages are highlighted and old messages are archived.

In most countries the copyrights will not expire until everyone here is long dead. If Disney continues to have it's way, in the US it won't ever expire. Keep waiting on the sale, it will come back around. You don't want to buy it till after the next patch anyway, its not in a very good state at the moment.

I'm not saying it's a bad idea, it's just I think it would be very hard to implement and probably not worth the developer time for a few edge cases.

It doesn't make my planes look ugly. It's detail, it breaks up the monotony of a solid color.

So other than your opinion of it's looks why wouldn't it be there? I think it looks great the way it is.

Why wouldn't it be there? Why does it need to be removed?

Ok, well everything I mentioned could cause that but since you are being rude, you are on your own.

It can do both. The specification for C# does not require any specific runtime, however it can also use runtimes like Mono or .NET.

Sorry, but you opened with a very technical question It's one possibility, it honestly could be a lot of things. Visual effects like engine smoke and such can cause lag spikes as well. Part count can cause physics lag. What are your system specs?

It is, however the great power of memory managed and garbage collected languages means you don't have to do it yourself. This makes it hard to fragment the heap, and memory is released to the system. However it is cpu intensive. There are also exceptions where the garbage collector can not access that can cause heap fragmentation. The only one I know offhand is the Read and Write buffers on a socket. Typically you want to pool socket objects rather than make new ones.

The reference compiler for C# (called 'Roslyn') is written in C# and bootstrapped from previous versions of itself. So, no it's not written in C. The project is open source. The earliest version was likely compiled using a compiler written in C or C++ but bear in mind at the time of use it is machine language. That's what a compiler does after all. So the language of the compiler originally compiling a compiler for a new language is irrelevant, it's all machine language in the end. (if you completely understood that last sentence, kudos to you!)

They aren't looking to reduce RAM usage, they are looking to reduce the amount of garbage collection and other processes. This can mean reduced RAM usage as a byproduct, but it can actually mean more RAM usage as well. Programmers have the ability to choose when their program requests memory from the system. We call this "Scope". It used to be taught that variables should be declared (storage space requested) in as narrow a scope as possible. This meant that the moment that function or subroutine terminated the memory would be freed. However, in modern languages it can often be the other way around with garbage collection. We have lots of memory but GC is slow, so the idea now is to declare frequently used variables (like loop incrementers which are used all the time) at a higher scope so they do not get turned over to garbage collection, however that also means they allocated persistently in memory. Therefore, more RAM usage. It's kind of like the computer programming version of recycling. Instead of making a new variable (or worse, instantiating a new object), we reset the existing one and use it again. You do have to be careful, though, that two subroutines are not using the same variable at the same time. People who moved from ANSI C and C++ to C# really have to fight the urge to declare variables at a narrow scope

File Fragmentation was only an issue on traditional HDD. Fragmentation in itself meant the files were stored in such a way on the drive that the swing arm inside the drive had to move further out to access the data, or worse, had to move in for part of it and out for the rest. This would increase seek time. On SSD, fragmentation will not cause this issue because it is accessed directly like RAM and in fact fragmentation (of sorts) is beneficial to the life of the Solid State chips. Solid state has a limited amount of writes and erases (but not reads) so modern operating systems (or possibly the drive itself, I'm not entirely sure) automatically use a technique called wear leveling. This causes data to be written across all storage locations of the drive evenly, because if you wrote to the same location on one of the chips over and over again that would wear out that chip quickly while the rest of the chips on the drive were intact but unusable due to the exhausted chip. Wear leveling in itself is a form of purposeful and targeted fragmentation. Using wear leveling, your drive will probably last longer than you really need it to since you will probably want a bigger one eventually. Furthermore, attempting to defragment an SSD will actually cause more wear and and thus can harm your drive. So, back to the page file. Setting it's size to be fixed doesn't matter on an SSD. The drive and/or OS will wear level anyway so you are actually using the whole drive for the page file at some point. You just can't see it, it happens behind the scenes and the OS presents it as if it were the same storage space the whole time, even though it isn't. Furthermore, the drives are so blazing fast that it's read/write processes take no time at all. There is some argument that a page file on an SSD is a bad thing because they are written and erased so many times compared to traditional file storage for programs and such. However with wear leveling in place it likely will not matter. Your drive is going to outlast your need for it or some other piece of the circuitry will fail before the solid state chips do.