[1.2] Procedural Fairings 3.20 (November 8)

[Spartan-S63]

A little off topic: Since KSP x64 also has a memory leak .. uses about twice the amount of ram with less mods than X86 does ... I consider it as dead and stick to X86.

Is that memory leak confirmed? Because if Squad used 64 bit data types in the 64 bit version of the game, everything checks out because the data types are larger in size. The rule of thumb is that a 64 bit program will almost always use more RAM than the 32 bit counterpart because of the technical details of 32 vs 64 bit memory addressing.

[Motokid600]

So how are people bypassing zero decouple force? Is there a way to attatch sepatrons to the fairings?

[Shiv]

I've just been shaking them off. Rumor has it that seperatrons do attach though (perhaps at the base) but I've not tried it myself.

[chrt]

So how are people bypassing zero decouple force? Is there a way to attatch sepatrons to the fairings?

By decoupling the fairing outside of the atmosphere, when the rocket is not under acceleration, and waiting for them to fall away before resuming thrust.

[Rybec]

You can always put a little spin on your rocket before detaching as well.

[xtremeqg]

Is that memory leak confirmed? Because if Squad used 64 bit data types in the 64 bit version of the game, everything checks out because the data types are larger in size. The rule of thumb is that a 64 bit program will almost always use more RAM than the 32 bit counterpart because of the technical details of 32 vs 64 bit memory addressing.

That's complete nonsense, please don't spew false information about things you don't know. The size difference between 32-bits and 64-bits comes from the availability of 64-bit words, which translates directly to larger registers. Now, for data nothing really changes. 32-bit datatypes remain to be 32-bits in size. Hell, even on an 8-bit or 128-bit platform they would still be the same size. I would expect unity's internal data structures to use a bit more memory (64-bit pointers, double the space usage). Textures, sounds, meshes and other assets will use the same amount of memory. A 32-bit PNG (24-bit color, 8-bit alpha) will never use more memory, the only thing that uses more memory is the pointer which holds the virtual memory location for the slab of memory it resides on which in this case is a 4-byte increase.

tl;dr version: You are wrong, more addressing bits does not directly increase memory usage. Just storing addressing bits takes more memory.

[e-dog]

tl;dr version: You are wrong, more addressing bits does not directly increase memory usage. Just storing addressing bits takes more memory.

Actually, 64-bit code is usually larger, and since languages like C# use a lot of object addressing, there are a lot of pointers that become 64-bit vs 32-bit, so there's increase in memory needed when switching to 64-bit.

[rynak]

Yeah, but unless the compiled code is a bloated piece of *censoredbadword* , burried under a mountain of dependencies (read: a lot of software nowadays), code really will not be using up much memory. It's data and logistics/organization (ESPECIALLY that), which eats up most of the memory budget.

People seem to think that most of the memory that KSP uses is textures. I thought so as well.... after all, else its memory usage would just be ridiculous - unity can't be THAT bad, riight?

Actually, apparently it really is that bad. I've spend hundreds of hours by now hand optimizing all the textures, sometimes actually tweaking them in photoshop to look better at lower resolutions, so that smaller sizes are possible. Uncompressed, i by now got my texture usage down to no more than 150mb! Yes, uncompressed - not PNG or such. Oh, i know, GPU's use an even more wasteful format to operate on them - might be, but surely KSP won't store them in RAM in that format, right? Only the GPU will do that in VRAM. So: It should make no difference to RAM usage.

And yet, how much memory does my 32bit KSP use? About 1000mb.

Where does all that memory go? Because it ain't textures. I'd say it's a combination of goddamn C#/Mono, Unity and KSP's own data structures. So in short, even on 32bit, KSP will use up about 700-800mb of memory, before even accounting for textures. Now, what if a lot of the data stored in that memory, are pointers? Endless amounts of BSTs, hashtables or even linked lists? Because you see, if yes then a switch to 64bit would double the size of all those structs.

Bottom line: Welcome to 64bit. And if you're now gonna say "But! 64bit also is faster!", then i'll tell you a very uncomfortable story about what exactly makes 64bit-mode on x86 faster.... hint: It's not 64bit...... in fact, there isn't even a reason why it couldn't work in 32bit-mode too.... but AMD/Intel needed a justification to make you buy all new PCs and operating systems. Speaking of which: The memory limitation of 2GB also is artificial - x86-32bit can actually address more, and windowsXP and 2003 even supported it! But it was by default disabled, so that people think they have no choice but to buy 64bit OSes.

[Nereid]

Actually, 64-bit code is usually larger, and since languages like C# use a lot of object addressing, there are a lot of pointers that become 64-bit vs 32-bit, so there's increase in memory needed when switching to 64-bit.

This difference should be negligible. I don't believe that there is some kind of confirmation of a memory leak. I think some have just seen the memory usage going up. But this is no confirmation for a memory leak in a language like C# or Java. They are dependent on a garbage collector and until the garbage collector doesn't free memory, ram usage goes up. Pure memory leaks like in C++ are not possible in languages like C# or Java, because there is no code for freeing memory. There is a similar effect, caused by programming bugs; most of them are caused bis lists or other containers that are not used correctly and keep references of unused data forever (and prevents the GC from deleting it) or because resources are not deallocated in the finally block (the destructor in C# works different than in C++; in C++ a programmer often uses RAII, in Java or C# RAII is not that easy to implement and should be avoided).

Edited July 19, 2014 by Nereid

[NathanKell]

rynak: so you mean you've exported all the multiple gigabytes of SQUAD textures from the KSP_Data folder and resized them too?

Don't think that all the textures KSP uses are in GameData. Where do you think the planet textures come from, for example?

[OwDoge]

I am no longer able to get Procedural Fairings to work, the "procedural" part now disappears in x64KSP and x32KSP. Also, when attaching the cone or eggshaped fairings, they do not resize.

Also, why are you all arguing memory leaks on this page? Take it elsewhere, this is a dev form for Procedural Fairings, grow up a little.

Edited July 20, 2014 by OwDoge
Edit: Confirmed in x32 as well.

[lammatt]

the ejection force is way too weak,

can anyone tell me where in the .cfg governs that?

[tygoo7]

the ejection force is way too weak,

can anyone tell me where in the .cfg governs that?

IIRC decoupler force does not work in 64-bit. That's for all decouplers.

[Drew Kerman]

IIRC decoupler force does not work in 64-bit. That's for all decouplers.

it works sometimes. But mostly it doesn't

[ola]

I am no longer able to get Procedural Fairings to work, the "procedural" part now disappears in x64KSP. Also, when attaching the cone or eggshaped fairings, they do not resize.

Also, why are you all arguing memory leaks on this page? Take it elsewhere, this is a dev form for Procedural Fairings, grow up a little.

I'm seeing this on a Mac as well.

[rynak]

rynak: so you mean you've exported all the multiple gigabytes of SQUAD textures from the KSP_Data folder and resized them too?

Good catch!

Though gigabytes is an exaggeration - unless ALL those "assets" are JPEGs.

Anyways, as others said, this is kinda of topic, so stopping now.

[chaos_forge]

IIRC decoupler force does not work in 64-bit. That's for all decouplers.

Do you happen to remember where you heard that?

[Nereid]

it works sometimes. But mostly it doesn't

In other words: It doesn't work. You would not call a car that can drive sometimes but most often refuses to start, "working" or "usable" in any way.

If I would tell my customers that they just have to try a feature it more often, because it will work sometimes, I surely would get a defect for this and they would not accept a release if a important part is broken. And yes, "broken" is exactly the right term for this.

But no complaint. Squad should now know about this, KSP is still alpha and if anybody wants to use it regardless of this bug, its ok. This early release of the 64 bit version raises chances that such important bugs are solved early.

[Torham234]

Does this still work in KSP 32 bit?

[ola]

Please ignore if you're not a developer-minded person.

I made it work by recompiling against the new KSPAPIExtensions. I'm about to create a pull request for a Makefile.

[tygoo7]

Does this still work in KSP 32 bit?

I'm pretty sure it does.

[smart013]

Hi there. So, i`m using right now 32bit KSP, updated all and everything that was mentioned here and other places to be needed to update for PF to and tweakscale work. But whatever I do, i cant get the fairings to open (relase, eject, whatever the right term is) after i change the size with tweakscale, and the payload (every payload i tested) is stuck inside.

EDIT: ok, it seems to be more complicated. Sometimes it works, and i get the two separator actions in the staging, sometimes i dont get any of that. Strange.

Edited July 20, 2014 by smart013

[FlexGunship]

========== OUTPUTING STACK TRACE ==================

(0x0000000103DF0000) ((module-name not available)): (filename not available): (function-name not available) + 0x0

(0x000000006D37FA8C) (Mono JIT code): (filename not available): Keramzit.PayloadScan:addPayload (UnityEngine.Collider) + 0x46c (000000006D37F620 000000006D37FE07) [00000000023A4D48 - Unity Root Domain] + 0x0

(0x000000006D37F019) (Mono JIT code): (filename not available): Keramzit.ProceduralFairingBase:scanPayload () + 0x379 (000000006D37ECA0 000000006D37F0E2) [00000000023A4D48 - Unity Root Domain] + 0x0

(0x000000006D37C1C5) (Mono JIT code): (filename not available): Keramzit.ProceduralFairingBase:recalcShape () + 0xe5 (000000006D37C0E0 000000006D37EC14) [00000000023A4D48 - Unity Root Domain] + 0x0

(0x000000006D37C076) (Mono JIT code): (filename not available): Keramzit.ProceduralFairingBase:Update () + 0xa6 (000000006D37BFD0 000000006D37C0A4) [00000000023A4D48 - Unity Root Domain] + 0x0

(0x00000000042372DB) (Mono JIT code): (filename not available): (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr) + 0x6b (0000000004237270 000000000423734A) [00000000023A4D48 - Unity Root Domain] + 0x0

(0x000007FEDDE536CA) (mono): (filename not available): mono_set_defaults + 0x2b8e

(0x000000000B1C6FA8) ((module-name not available)): (filename not available): (function-name not available) + 0x0

(0x00000000FFFFFFFF) ((module-name not available)): (filename not available): (function-name not available) + 0x0

(0x00000000023A4D48) ((module-name not available)): (filename not available): (function-name not available) + 0x0

========== END OF STACKTRACE ===========

I got this in the output_log after updating RealCutes this morning (was working with it before).

[RoboRay]

Do you happen to remember where you heard that?

There is no need to have "heard that"... just try a stock decoupler in x64. The lack of ejection force should be obvious.

[Tangle]

Hmmm. I'm still getting ejection force perfectly.