Ruedii

Well the problem is that earth is significantly larger than Kerbin, so it takes a lot more power to get things into orbit. You absolutely need a minimum of 2 additional stages to get even small satellites into orbit. While SSTOs are quite easy in the fantasy world of Kerbin, on earth they are near impossible.

Thanks for the fast fix. I didn't notice the issue, but I'm sure other people ran into it.

No, and in fact I just read the API documentation a few days ago. I'm just really familiar with what causes problems in object oriented code. (Sort of a natural with object oriented and prototype-oriented code). BTW, there is a switch to hide and unhide stage icons, while it also isn't used in-flight anywhere, it is far more likely to be safe, as it retains the staging order objects were placed in. You probably should see about using that. This way you aren't destroying and creating objects dynamically in-flight, which always slows stuff down. Simply hiding and unhiding always works better than creating and destroying. I also noted you were not assigning staging order to objects before creating the icon. That might be the issue. Recent compiler changes in Unity made null and void no longer equal zero in a lot of objects, and I noticed that KSP had a unity version release. Still, the easiest way to deal with this is just assign a deactivated staging icon to every single part in the game during game loading (all the way back at the loading screen before the title screen.)

EXACTLY! Also (when using the same fuel) a smaller radius booster of the same length will create the same amount of thrust for a shorter amount of time. Yeah for science! It's perfect for that massive off the pad TWR that is so Kerbal! Furthermore, thinner, means less drag! However, yes, why not both?! 1.8 sized would be perfect for attaching to the sides of our behemoth rockets.

The thing is that the Chetah contains Size 1.5, and Size 1 bulkhead modes. It's mode without a base mount is a Size1 and with a base mount is size 1.5. It thus has two shroud nodes at the bottom as well. The upper one is a Size 1, the lower one is a Size 1.5

I'm going to look deeper into your exact issue, though. I found the documentation, and I'm going to RTFM when I get home this afternoon. I'm already running late. However, I highly recommend moving to a behavior that doesn't create and destroy staging icons inflight, if only for the sake of optimization. The create routine for stage icons wasn't intended to be run on a frequent basis, and thus will likely lag you a lot. It seems that a null comparison is fine in C# to detect the instance of an object. I personally don't like that method of doing things, but I didn't create the programming language.

Well, staging icons weren't really designed to be added and removed dynamically, and thus should not be considered an operation to do safely. Running part.stackIcon.CreateIcon while the game is inflight is an unsafe operation. The game pauses to avoid unsafe behavior when handling part detach and part destruction removal of staging icons, and resetting the staging order when docking. Pausing the game frequently is not something I would recommend. The way I would recommend fixing the issue is just doing it in a manner more inline with standard KSP behavior. You should instead take parachutes as a model for behavior. You should have the icon attached to the base tree of the part from KSP's startup. (This can be inserted by your module). For any state indicator you should change to color of the icon. You should never have to remove or add an icon add an icon. The icon should be added in the parent object that attaches in automatically to every BDArmory object with the specified capability. It should be attached automatically before vessel-load and only be removed when the part is removed from the craft, and KSP automatically removes icons for destroyed and detached parts, so you shouldn't have to worry about this. In other words, this code shouldn't be necessary at all, because your mod should be written so that the icon exist attached to the part at least from the VAB, if not from game startup.

A few quick sanity checks first before you pester the KSP devs: This is an issue with DLLs? This appears to be an issue with porting to Win64 architecture (i.e. changes to the INT and Pointer typings). Are you ALWAYS handing ints and int32? Are you moving an Int32 to an Int and back to an Int32? Are you moving a pointer into an Integer of any sort? While Int32 should be type-compatible with Int and Long, there are options in the compile template in Win64 to override this standard. This results in various issues. They are not type compatible with Pointers. Simply put, never cross types. If it's a pointer, ALWAYS use a pointer, if it's an Int, ALWAYS use an Int, if it's a Long, ALWAYS use a Long, and if it's an INT32 always use an INT32. NEVER assume they are compatible even if they traditionally are. I hope that helps. If not, default to the devs.

It's already not mandated, but everyone supports it in any gaming class drivers. Many drivers only support the Direct3D 9.5 subset which removes some of the bloat from older versions of D3D. Technically if I was Squad I would use SLang/SPIR for in-house shaders (this is an intermediary code level that can be converted to HLSL, GLSL and Vulkan SPIR-V), and limit myself to relying on extensions supported directly by Direct3D 10, 9, GLSL 3.1 Core and Vulkan on the fallback shaders. This means not relying on any of the bloat in Dx9. For optional shaders, I would, of course support more advanced extensions. I would auto-detect the use of Dx10/11 or Dx9 context handling. This would allow continued support for the few people using Windows XP and related Windows Enterprise versions. I would also support OpenGL on Windows and add Vulkan support as soon as it's available in Unity. As a note, SLang/SPIR is the absolutely highest compatibility intermediary language now. It is a simplified HLSL language made to compile more directly into GLSL Source and GLSL/ARB Bytecode (for OpenGL) as well as compile nicely into other modern shader bytecodes, It removes all the bloat of HLSL (same bloat removed in SM4/SM5 for Dx Level 10/11) and can be directly compiled into most modern Intermediary languages such as those used on the PS4, Vulkan and in D3D 12. SPIR-V is an extension of this that has been Reoptimized for vulkan. It doesn't translate as well into GLSL/ARB Since D3D 12 context support is still very limited (and buggy) in Unity3D as is Windows Vulkan and Linux Vulkan using extensions specifically for them, and using their better context and texture management will have to wait. (As a note Unity is exploring using a Vulkan to Metal stack on mac, which would make Vulkan a very good intermediary for all Desktop platforms. Vulkan is already close enough to Metal that Vulkan shaders can be transcompiled ahead of time to Metal so long as they don't use a handful of unsupported extensions.)

Most such appliances will be moving to RISC V or ARM according to the developers who make them. The RISC V is a very small instruction set computer recently developed with a completely open architecture down to and including the entire silicon layout (to transistor) of the benchmark template CPU core provided in the design manuals. It has an incredibly small instruction set with reserved space for special use instructions for modified versions. It was made by a group who's backers are the who's who of the computing world for everything from desktop to mobile to IoT. ARM is of course the platform from which most phones use, and is the current go-to processor for a high processing speed lightweight low power SoC. Some still run on 16 bit and 8bit pre-intel CPUs. (Often 16/8bit hybrid architectures similar to the 8086, including the 80186) There is a high reliability version of the TI TMS9989 CPU that is incredibly popular in military airplane design. It is a high-reliability 8bit variant of the TMS99000 CPU with differential voltage lines for prevention of glitching and other errors. Considering that the TMS99000 line is the highest performance CPU of it's (it's era being the late 70s, and exceeding the arithmetic performance of an early 80386SX or late 80286) It is particularly adept at handling lightweight bytecode interpreters which make it extremely high performance. 16bit/32bit hybrid MIPS specialty chips are also widely used. Some even use the even smaller 4bit LPC external bus to reduce pin count and simplify board design. Your router probably has an MIPS processor in it, and if you have a RealTek network chip or sound chip on your motherboard (which you probably have both) you no doubt have a MIPS specialty processor with a 4bit LPC bus connection to your chipset.

If your refresh rate is 40hz or higher, absolutely not. If your refresh rate is around 30hz or 20hz (like on some low-end mobile displays) then higher frame rates have an advantage due to physics being synced to frame rate.

I'd much rather have an 0.625m one.

I doubt there are too many more computing platforms out there. PC, Mac and Linux cover that. Mobile Android and ChromeOS are no where near ready in compute capability. Companion apps might be able to be developed, but Squad still has a lot to get done before then: Remastering all the old parts, adding new missions to Making History, as well as new parameters to the mission maker (which feels a little incomplete at this point in time by my book, which is why I haven't made any making history missions yet to publish to SteamWorks and *** malicious site we no longer use ***.)

Putting multiple ones in the same contract would be good, but they shouldn't be required to be returned in the same ship (but no rule against it.) The pay and gained reputation should diminish with repeated missions of the same basic difficulty (especially reputation gains.) The more difficult the mission, the more reputation and pay earned. In fact, a difficulty level of "Routine" needs to be added for missions that is just a dash and no stars. Missions like that grant very little to no reputation (0-2 points), little to no science and have funds low enough that hard players will find it near impossible to gain funds by doing the missions. Rescuing tourists or other Kerbals not to be added to the roster would be great. It would provide another way to provide for more rescue missions without disrupting balance. Honestly, I think there should be more rescue missions anyway. I don't think highly eccentric or insanely high altitude ideal, but allowing the orbits to have appoapsis up to the 500km-1Mm range would make it fun. Maximum eccentricity should be around 0.5, which is fairly eccentric. There should also be some inclination (a range of 15 degrees in either direction from zero) to make things more interesting as well. This range would be within reasonable manned operation range. Similarly there should be rescue missions from the Mun and Minmus quit frequently once you get to the point where you have made it there. A bigger variety of contracts with a bigger variety of rewards across the board is needed, especially in rescue operations.

Currently there are already sliders in the SPH/VAB. I think it would be nice, though if you could change the fuel level outside of SPH/VAB if in specified areas (Launch pad, or within a certain range of fueling tanks and buildings). Returning fuel to KSC grants you funds (unless launch site fuel storage is implemented) while drawing fuel costs funds (see mentioned about fuel storage). Obviously you can't fuel/refuel solid rockets this way, because they are Adding quick transfer buttons in this manner to pump fuel to or from tanks from the rest of the tanks on the ship as well. Pumping fuel should take electricity, but not much when you consider the efficiency of the very small motors Kerbals use in things like reaction wheels. I would recommend something like 0.001 unit of EC per a unit of fuel transfered this should be turned off in easy mode. (Resource transfers cost electricity).

Does this mean that the Linux version will FINALLY launch in 64bit by default? Unity3D already has built in converters. There is no need. Direct3D 11 also doesn't add that much in all honestly. HLSL is used in Direct3D 9 as well. SLang is now the preferred high level shader language.

The main design that would use this is a size 1.5 tanker. My current designs on these use the shortest downscale part on the docking port to look nice. The smaller ones use a similar aft end and a Terrier engine while the larger ones use a cheetah. It would also work well for a size 1.5 tug of similar design.

On the size 1.5 covered docking port, why not just make it a size 1 docking port with size 1.5 shroud over it. Likewise the bare docking port for size 1.5 bulkhead ends should be a size 1 with an extra large shroud around the side to cover the endcap. As a note, I was having various weird issues with the parts. The biggest was a bad offset on the attachment nodes, but also a bunch of other weird stuff. It is also overwriting the Color Coded canisters patches on 1.25m parts. Could you change the module manager behavior to fix that?

Magnetic Plasma Deflection was how I always thought impulse drive would work on Star Trek. (They are never clear on it, but they imply it's a function of the deflector field, which would imply either magnetic plasma deflection, magnetic trace-mater deflection, or both. Most likely both.) The deflector shields in star-trek are the secondary weaker shields that are used to deflect common stray matter and radiation around the ship. They also prevent several of the nasty effects of FTL travel where light and other light speed particles build up on the nose of the ship. It would make sense that such technology would be usable for base propulsion. I never thought we were so close to such technology, though.

They can eventually be heated into plasma, as can anything. It's just not an effective use of them as they are incredibly stable and thus have very high temperatures. There are far better materials to do this to. I'm not sure if they are resonant enough to any microwave band to use microwave radiation for this purpose or if other heating methods would be necessary. In theory, if heated enough under pressure their carbon bonds would break down and convert into pure carbon plasma. This could theoretically be done on the output shaft of a mass driver device for a secondary expansion engine, but it would take a lot of energy for little game. Still, they are one of the few materials that can be highly ionized or be given heavy ionic bias in their solid state. This gives them the ability to be used in an ion drive without being turned to plasma. This gives all sorts of trade-offs because it is a zero-expansion ionic mass driver engine.

So basically you are proposing using buoyancy as a catapult launch mechanism. I'm not sure how much speed you could gain like that, or if it would be sufficient to overcome the added launch cost.

It seems to be really messing up as of the latest revision. Either that or I accidentally deleted a module manager patch. As of some parts to add: 1.8m docking port, 1.8m shielded docking port, 1.8m inline docking port, 1.8m inflatable docking port, and 1.8m radial attachment node. Optionally, you should through in Mk.2 1.8m inline docking port and Mk3 inline docking ports ( 1.25, 1.8 and 2.5)

The reskinned 1.25m tanks interact badly with Color Coded Canisters. Might I suggest having the module manager script deactivate them if Color Coded Canisters is installed. I suspect some other mods also interfere considering part replacement tends to do that.

I'm more talking about things like burning towards a planet to reenter the atmosphere.

Most nuclear jet engines were actually boiler engines. They used the heat of the nuclear reactor to boil a liquid fuel (usually methanol) far above flash point then injected it into the combustion chamber for insane Delta-V and thrust while sipping fuel and requiring little oxygen. They could actual run on no oxygen by simply using the methanol as a heat medium, but they lost efficiency doing that. While there were some that just used heated compressed air, those had abysmal thrust and efficiency.