What did you do in KSP1 today?

[CatastrophicFailure]

4 hours ago, Stunkfish said:

Any "bullet proof" way to integrate pics here?

Make sure the image location you’re copying has the file extension on it, usually ends in .png. Imgur can be tricky, especially with their horrid new beta update. It’s sometimes helpful to reload the page after you’ve uploaded to clear any funkiness. Also, “paste as plain text” usually works best on the forum for some reason. 

[linuxgurugamer]

1 hour ago, Tyko said:

Very cool! I read once a while back that a bunch of open docking ports can slow down your computer. I believe the reasoning was that the game wants to constantly check open ports to see if there's something in range to connect to.

Not aware of it, but I can believe it.

[Tyko]

5 minutes ago, linuxgurugamer said:

Not aware of it, but I can believe it.

This is from 2016, so wasn't sure it was still accurate:

 

[EvenFlow]

18 hours ago, Kronus_Aerospace said:

Full Stock, about 1900 parts and quite a Beaut when it's not devolving into a glitchy mess.

HNGHHH

I WAS NOT PREPARED

HOLY SH** IT'S BEAUTIFUL

Edited August 8, 2018 by EvenFlow

[Zosma Procyon]

I launched this fuel depot station to Eve, where an asteroid is already waiting to be digested.

[4x4cheesecake]

Finally, outside temperature dropped enough so I can play the game again without melting on front of my monitor.
I've preprared the Mun base for the next shuttle challenge. I build the base and some rovers to surface assemble all parts together. Now I have to find a way to get the modules out of the cargo bay...got a nice idea to use an airbreak on the bottom of the cargo bay to lift and pitch over the modules but it needs some fine tuning^^
Maybe something like a skycrane would be a better solution...

 

[Kronus_Aerospace]

6 hours ago, CatastrophicFailure said:

Reminds me of something out of Infinity War... which I’m yet to actually see.  

What’s actually going on there?

Hard to describe. It's a glitch where part models at random go invisible in areas where they are near another part model (that's the best I could do okay?). it seemingly happens at random and varies in intensity. I think it has something to do with the games shaders, since the effect disappears when you zoom the camera far enough away such that the game switches to it's lowest quality shader (an optimization feature).

As far as I can tell it effects both stock and modded installs. Are you using the most up to date version of KSP? Because if not, then that would lend credence to the theory that it is a glitch from the newest version of the game.

5 hours ago, EvenFlow said:

HNGHHH

I WAS NOT PREPARED

HOLY SH** IT'S BEAUTIFUL

TH-THANK YOU

You shall have it by tomorrow or the day after... hopefully

Edited August 8, 2018 by Kronus_Aerospace

[CatastrophicFailure]

13 minutes ago, Kronus_Aerospace said:

As far as I can tell it effects both stock and modded installs. Are you using the most up to date version of KSP? Because if not, then that would lend credence to the theory that it is a glitch from the newest version of the game.

Welp, since you mention it, I’ve never actually encountered it before. But I do mostly play in my old 1.2.2 game...

Does it give you any log errors when it happens?

[EvenFlow]

1 hour ago, Kronus_Aerospace said:

Hard to describe. It's a glitch where part models at random go invisible in areas where they are near another part model (that's the best I could do okay?). it seemingly happens at random and varies in intensity. I think it has something to do with the games shaders, since the effect disappears when you zoom the camera far enough away such that the game switches to it's lowest quality shader (an optimization feature).

This glitch has become my worst enemy since 1.4 came out. I've noticed some stuff about it so I may try to contribute:

1. The glitch seems to be most pronounced near ground level, up to about 150m when only a single craft is within the physics range and will gradually build up the longer you stay at low altitude. It does not happen all the time with only a single craft but it usually does.

2. When other flying craft are within physics range the glitch gets more noticeable. The further away the craft are from each other, the more Z-fighting and flickering occurs. Again, this seems to be a bit less prevalent at higher altitudes. With low separation the Z-fighting is negligible (but can sometimes still occur, especially with camera zoomed out and clipped parts (not clipped as to ensue traditional Z-fighting though, just close to each other on one or more axes).

3. As mentioned before, the amount of z-fighting when the glitch occurs is proportional to the camera distance from the craft.

4. The most interesting aspect of the glitch for me is that when ANY vessel is within physics range on the ground / splashed down, whether it be a craft or debris, all craft within load range experience severe Z-fighting. This only seems to occur when there is a combination of flying/landed craft. When the glitch starts it does not go away after the flying craft is landed (When loading both craft to runway/pad from any interface it usually does not occur.).

5. With a single flying craft, the glitch seems to greatly increase in intensity after landing, this effect does not go away until a certain altitude (150m in my case) is passed and if the craft goes under that altitude it will show up again. Reverting or loading a quicksave seems to reset this effect in these exact conditions.

6. Moving craft with VesselMover over big distances causes extreme glitching.

1-5 apply to both stock and modded installs, 6 obviously applies to VesselMover equipped installs.

All these characteristics point me to believe that this bug is caused by some sort of float inaccuracies in the data structures which hold info about the positioning of parts, almost as if the game couldn't decide where to exactly draw the part textures. Since the position values are probably some sort of floating point types, and I presume they are updated every tick of the game clock, perhaps there is some sort of a float instability which throws off later calculations, thus elevating the problem further and leading to more extreme glitching. (all these changes seem to be more or less gradual, never snappy in nature which supports this "domino effect" theory)

Oh, I'd also like to point out that these glitches sometimes occur not only between different parts, but sometimes between different sections of a single part - For example on stock airplane cockpits the windowpanes, the white hull of the part and the black window frames start becoming all "jelly-like" and clip through each other when the glitch occurs.

EDIT: I've recorded it some time ago so here's what it looks like.
 

This is not too severe and shows the case of glitching after landing the plane as described earlier. It can sometimes get far more extreme than that, similar to the screens provided by @Kronus_Aerospace.

Edited August 9, 2018 by EvenFlow

[adsii1970]

Spent some time working on my star system mod, Nohochacyum. And for about an hour (or two), enjoyed some time launching and performing orbital maneuvers with a shuttle.

Spoiler

 

[Mythical Donuts]

Yesterday I got Luna Multiplayer working and taught my friend how to get mods. The multiplayer was fun, but really hectic because my iPad ran out of charge which I was talking with my friend on. In the end though, he got on and we had fun

[DeltaDizzy]

4 hours ago, EvenFlow said:

<snip>

 

5 hours ago, CatastrophicFailure said:

<snip>

 

5 hours ago, Kronus_Aerospace said:

<snip>

To me it looks like very severe z-fighting. As far as I know, it mainly occurs with clipped parts. The wikipedia article I linked explains it better than I ever could. It's always been there, but something in 1.4 made it much more pronounced, especially near sea level.

[CatastrophicFailure]

14 minutes ago, DeltaDizzy said:

 

 

To me it looks like very severe z-fighting. As far as I know, it mainly occurs with clipped parts. The wikipedia article I linked explains it better than I ever could. It's always been there, but something in 1.4 made it much more pronounced, especially near sea level.

Ok yup, can confirm, just got it for the first time. Seems like really big, complicated things trigger it. 

So, I’ll ask the stupid question...

...has anyone started a proper bug report thread to report it to @SQUAD? 

[JadeOfMaar]

I made a TSTO spaceplane inspired by a new startup aerospace company somewhere with an epic new approach to commercial flight and the domination of LKO. The small orbiter (manned or just a cargo dropper) is exclusively a rocket plane and is launched as horizontal as can be. It does not ride on the back of the lifter or in the middle of a souped up stratolauncher.

They separate near orbital velocity. The lifter safely lands somewhere. I don't need a stage recovery mod. The orbiter has enough TWR to secure a high Ap and fast before either craft leaves the physics bubble.

I did not go gentle/quiet into the night... But I could and did on the next try and landed intact.

Spoiler

Changing the jet engine layout and adding some more Oxidizer granted the performance I was missing the first time, in which I struggled to gather speed and had to do an annoying nearly flat run the whole way, and used all the Oxidizer getting to Mach 5, and then fighting off asymmetric flameout in the J-92s in Shcramjet mode.

Both planes have great handling without needing forward fins.

Landed this, easy.

 

 

[LaydeeDem]

Spent hours trying to get this thing into orbit to no success, remembered why I don't build spaceplanes:

 

I'm always about 200-300 m/s short on dV by the time I reach space. At least it looks pretty:

[EvenFlow]

4 hours ago, DeltaDizzy said:

 

 

To me it looks like very severe z-fighting. As far as I know, it mainly occurs with clipped parts.

I dont think it's the same. Regular z-fighting only occurs in areas where parts overlap. When this glitch gets severe enough it affects the whole craft. Craft which dont use clipping are also affected too, if I get to filing a proper bug report later today I'll try to include some pics. 

[purpleivan]

57 minutes ago, EvenFlow said:

I dont think it's the same. Regular z-fighting only occurs in areas where parts overlap. When this glitch gets severe enough it affects the whole craft. Craft which dont use clipping are also affected too, if I get to filing a proper bug report later today I'll try to include some pics. 

There may be other issues in play here, but some of what's seen in the video is definitely  Z fighting... seen and fixed enough of it in my time to recognise it

It would be good to see a video with glitching that appears in areas without overlapping parts, especially if the view can be a close to the area that's glitching, to get a clear view of it.

A guess as to why the glitching might appear more pronounced at lower altitude, is that the aerodynamic forces might be greater (depending on the speed) at near sea level than at high altitude. That could  generate greater or and/or more frequent flexing of the joints between the parts, and so create more pronounced z-fighting issues.

[garwel]

Yesterday, my first (really, after 3250+ hours playing the game) crewed mission to Duna reached its SOI! The interplanetary ship, named Albatross, houses a lab, a panorama module, two Hitchhikers, lots of life support systems (USI-LS) and even a radiation screen (Kerbal Health). It provides ample room for three kerbals to support stay in orbit almost indefinitely (again, with Kerbal Health's most punishing settings). It is propelled by two atomic motors and power is supplied by a nuclear reactor. It also has a Planet Exploration Transport, or PET, which can bring the three crew members from an orbit to a moon and back + lots of experiments.

This is Albatross above Duna:

But the circularization burn failed for several reasons (the CoM was too far from the CoT, kOS script issues, engine overheating etc.). As a result Albatross found itself, instead of a neat 130x130 km orbit, in a very eccentric elliptical orbit with Ap barely within Duna SOI and Pe deep inside Duna's atmosphere. What's worse, we nearly run out of fuel. It should be enough to fix the Pe problem, but there is a big risk of the station being thrown into the Sun orbit by Ike.

The good news is that I have a special unmanned ship, called FOX (Fuel-Oxygen eXtractor), approaching Ike that is capable of extracting fuel (hydrolox in this case) from the moon. So my plan is to:

1) orbit Ike

2) land in an ore-rich spot

3) fill the tanks with hydrolox

4) take off and leave Ike's SOI

5) rendezvous and dock with Albatross

6) refuel Albatross and repeat if necessary

One challenge here is that all of this will have to be done with a 2-3 minute signal delay, so I must use kOS scripts for nearly everything. The other is to make it all quickly before Albatross was tossed out of the system. And much of it I'll have to do for the first time. (Oh, and besides, I don't load previous saves even in cases of catastrophic failures.)

I don't know how it all ends, perhaps in a big explosion or even more likely with my kerbals dying on the station of lack of starvation and boredom. But it's going to be anything but boring to me.

Edited August 9, 2018 by garwel

[Kronus_Aerospace]

2 hours ago, purpleivan said:

There may be other issues in play here, but some of what's seen in the video is definitely  Z fighting... seen and fixed enough of it in my time to recognise it

It would be good to see a video with glitching that appears in areas without overlapping parts, especiall'sy if the view can be a close to the area that's glitching, to get a clear view of it.

A guess as to why the glitching might appear more pronounced at lower altitude, is that the aerodynamic forces might be greater (depending on the speed) at near sea level than at high altitude. That could  generate greater or and/or more frequent flexing of the joints between the parts, and so create more pronounced z-fighting issues.

It's not a video but a gif is good enough.

As you can see, the glitch even occurs between different segments of the fairing that composes this craft's body, which in no way could be z-fighting. Z-fighting occurs when planes of the part models are perfectly overlapped, this is not the case with ANY of this craft's parts, and obviously not the case with a singular fairing which has no part clipping whatsoever.

without part clipping being a necessity for the glitch to occur we can safely rule out Z-fighting

Unfortunately this still doesn't tell us why the glitch is occurring.

[MisterKerman]

I found out my commercial booster can't handle it's job! Reverting back to Kerbin Orbit before the LEM/Booster split for their trip to Minmus, I'll wait for a booster with twice as much fuel to make it's way up. Hopefully doubling fuel without adding another engine doesn't mess with my TWR for maneuvers. I'll dump the fuel and deorbit the old one.

I was using an old booster as a slosh tank to avoid equilibrium issues while transferring fuel. Ironically it's the most capable booster I have in orbit but I refuse to use it because it's big, ugly, inefficient, and in the way. I have a company image to uphold now.

Edited August 9, 2018 by MisterKerman

[Hotel26]

2 hours ago, EvenFlow said:

When this glitch gets severe enough

How similar would you say your glitch is to this one:

This one occurs in KSP 1.3.1 after "teleporting" with a mod I was working on.  (I never solved this problem.)  I'd like to know how similar the artefact is, though...

Things shake and others within focus.  But switch away and back and it's OK.

Edited August 9, 2018 by Hotel26

[Kronus_Aerospace]

1 hour ago, Hotel26 said:

How similar would you say your glitch is to this one:

Not at all, the glitch we are discussing is purely visual rather than being a physics glitch.

[EvenFlow]

1 minute ago, Hotel26 said:

How similar would you say your glitch is to this one:

Hm, this may look visually similar, but the glitch I experienced and described is purely visual, it does not involve any part movement at all. It seems like the bug messes with how the parts are drawn on-screen, not with how they are positioned physically. 

[Whisky Tango Foxtrot]

Well, I'm back.

Started a new career in 1.4.5. My last play-through was fully stock, but this time around I'm running a few mods, such as Planetary Base Systems, Flexible Docking Ports, Snacks and Stockalike Station Parts. The mods haven't really played much of a role yet, though, as I work through the early stages of the tech tree.

Orbiting the Mun.

Probing Minmus.

Up to sending the first krewed landing mission to the Mun. (He made it home, by the way.)

It's good to be back.

[purpleivan]

3 hours ago, Kronus_Aerospace said:

It's not a video but a gif is good enough.

As you can see, the glitch even occurs between different segments of the fairing that composes this craft's body, which in no way could be z-fighting. Z-fighting occurs when planes of the part models are perfectly overlapped, this is not the case with ANY of this craft's parts, and obviously not the case with a singular fairing which has no part clipping whatsoever.

without part clipping being a necessity for the glitch to occur we can safely rule out Z-fighting

Unfortunately this still doesn't tell us why the glitch is occurring.

Actually z-fighting occurs when the geometry is separated by less than the resolution of the z-buffer (i.e. doesn't have to be perfectly coplaner), which is dependent on how it's been set up and if parts are moving slightly, then what's in that state is going to be a moving target.

I'm not saying that what's seen in the GIF z-fighting...don't have a close enough view, or know enough about the construction to say that.

Is the craft file available anywhere to take a look at? If not, is it possible to post some video at higher resolution than the GIF and preferably a bit longer too?