darthgently

Maybe reloading the scene has helped in similar situations, but not this one.

FYI, when typing into a kOS pop up terminal, typing underscore character on linux [RShift][-] triggers the [Alt][-] behavior for Hullcam. I'm not sure if that is a kOS issue, or a Hullcam issue, but one would not expect chars typed into the popup terminal to affect things outside the terminal. I'm mention it over on kOS also

I was trying to board a kerbal into an airlock with the Easyboard mod which lets you press "B" prior to reaching a hatch, then they board when they reach the hatch. I'd forgotten I'd installed LadderWarp. So he drifts past a ladder, ends up in the ladder seat. Now he can't get out. The "leave seat" in the PAW is there, but when clicked nothing happens but exceptions. The log says no one is in the seat, and that is probably the root of the issue. Good thing this asteroid miner isn't destined for re-entry. Dondred Kermin will just have to live on the ladder I guess and be a useless crew member lost in his reverie as he ponders the vastness of space while everyone else works their butts off, lol. A fix would be great

In the VAB, CTB allowing clicks to fall through the KIS Inventory Close button for me no matter if in 'mouse' or 'click' mode on linux, just another data point that in this case at least, it isn't just 'mouse' mode. At least not via the new on screen toggle button 'mouse'/'click'. I'll try changing in settings and see if that behaves differently [edited from PAW to KIS Inventory Close]

Lately I'm launching some behemoth "miner/tankers" with lots of gangly stuff hanging off of them and certainly not just aft. I don't really do SSTO/spaceplanes, so I'm more interested in what i can do to make these things less like pushing a giant oak tree into space. I use fairings as I can, but never worried about exposed unused nodes until now

What are the simplest, lightest weight, methods of covering exposed nodes? My first thought was very small and flattish procedural nosecones. If there is a better place to discuss this lets move it there. Or PM me

I just learned something very important. Exposed nodes cause drag? Should one cap off exposed nodes as a design technique?

Is part.position and part.CoMOffset coming from a C# environment? I can get position in kOS, not sure about CoMOffset. But I'll pass that on to some kOS devs, thanks for the info. As for the HASPHYSICS flag, strangely ProcParts do have MASS in their structure in kOS so I don't think it is being assigned to the parent. The CoM I calc is within 5 or 6 decimal places of the actual CoM with cylindrical tanks so I don't think their mass is going to the parent, which is located some distance away and because they have more symmetry than a cone (I assume) their offset dovetails better with KSP use of position or something similar

Maybe I misunderstand and should have kept quiet. I thought he was talking about changing a user setting that would make a sweeping change of how the tech tree worked in sandbox and just figured that is something best left to the user, or at least make it clear up front that it would be required for that mod. I think I must have misunderstood. Please disregard

I'm not sure if that is a question directed at a particular person or the forum in general, but in my view doing that automatically would change the game a lot for people who wouldn't be expecting it. A better approach might be to let potential users know up front that for SmartTanks in their current form to be usable they will have to select that option. Leave it up to them. Another option is to break up the functionality of SmartTanks into progressively more powerful options and work them into the tech trees so it isn't all or nothing. Procedural Parts does this by gradually lifting restrictions on how large and how small you can make things, along with delaying when you get certain items like procedural ore tanks and such

I'm not sure this is relevant but I noticed while writing a kOS script that traverses the ship parts tree that at least some (all I was working with) ProcParts have the kOS HASPHYSICS flag set to false, and yet they report a MASS. Which is unusual. Anyway, KSP transfers the drag and mass of physicsless parts to the parent part typically (which is why they report zero mass; it has been moved) and idk what the entire approach is for KSP on physicless parts. So maybe in the confusion a procpart item is somehow altering the aero on a winglet if that winglet is attached to a ProcPart? I don't know. But ProcParts should probably not be coming up as physicsless in kOS. Whether that is a kOS or ProcParts issue I'm not stating here because I don't know

This may be a big PR ask, but in kOS I'm trying to compute center of mass of parts of ships still connected to the main ship by walking the parts tree from the decoupler down. My method is working great until I hit a cone shaped ProcParts fuel tank. The position reported by kOS for that tank is not its center of mass as with all other parts. When I change it to a cylinder it works fine. KSP correctly adjusts for the cone shape in its CoM calculation so I'm guessing the information is there, just not exposed in a way that a kOS script can get to it. Is this something that kOS should be computing from the shape info? Or is it something that ProcParts should be exposing more directly? idk, but wanted to bring it up

Are you in career mode? If so, the smallest and largest sizes start out in a narrow range on pparts, then allow smaller and larger as you advance. That has been my experience anyway. Also, this is an old forum, try the new forum at link below

That works; let me know if you need any testing done. Specifically, the issue with EVA is removing focus from an EVA kerb sends them drifting, so any interaction with PAWS must be done quickly and with a preplanned inertial path. As for kOS, I only brought it up as an example of how there may be a click-focus transfer issue requiring more than one click to change focus. But it may be unique to my install or caused by other higher priority demands starving the gui, not kOS or CTB. Now that I think of it, it may be my kOS script starving the gui of cycles

Not really a bug report, but more of an FYI, the Focus Follows Click makes KIS/KAS EVA work really hard, but otherwise that mode is the sanest in my view. Would there be a way to make on-screen blizzy or other button that toggled between focus follows mouse and ..click? Better yet, make it context triggered. I only have an issue on EVA and when juggling kOS terminal windows (it often takes 2 clicks to activate those windows and often takes two clicks to click out of them, but it is a lottery so I just end up clicking several times real fast for good measure. Probably hard on the mouse

This is good news also. EVE is so great. But bad news because a gremlin still lurks somewhere....

Thanks for looking, much appreciated, but now you know why I've been hesitant to get others involved. But being new-ish to KSP I didn't know how much of this was "normal" for a modded install and how much was peculiar to my set up. I wanted to get a sense of the context. Not overclocked, but this model has been known to overheat like many gaming laptops. So I'm trying to carve out time to disassemble, apply heat sink paste, clean fans, and maybe nerf the speed a bit. Memory tests showed clean. But I've never gotten the mmap protected memory error or the low level GPU errors outside of KSP and my understanding is that mods, and obviously KSP, have a free hand in screwing with memory if they so desire or fumble, so who knows. I'll get what I can under control on this end, then see what remains of the issues. Again thanks, let me know if you have a coffee fund, patreon, or whatever

Well, the plan was actually to remove EVE and test, then maybe share a log file if it didn't work, but since the fix was a red herring, your plan takes first place. I'm in the process of building another machine as I get so many low level errors that I need to take this laptop apart and look for a heat issue. I've already tested the RAM and it is good. The machine is a Core i7 with 16GB of RAM and an NVidia GEFORCE GTX in opengl mode on Debian linux. In KSP, on days I play, I get daily protected memory accesses leading to hard crashes, often preceeded by lots of NULL OBJECT refs, which are nearly always there to some degree, often in editor in calls to Editor Logic related functions while in the VAB but also in flight related to various mods and unity functions. Occasionally I get GPU related low level errors leading to hard crashes. It is so across the board it smells like corrupted memory leading to multiple outcomes. Lately the NULL OBJECT errors gather like a storm when using symmetry mode, especially after selecting a subass'y that I'd previously saved; it will get into a state where I can't put down the part/subassembly I was trying to place, nor can I place it. Ghost symmetric versions of the object will appear and freeze at odd angles and locations. All I can do is exit the editor. The machine has 1/2 a gig of RAM leftover (but linux is strange, iirc, in that it will pre-allocate RAM even if it isn't really used, then really allocate it later; the short version) and I have disk space left over. I have no issues with other programs but KSP is the biggest load I run on it also. Blender is ok, as is GIMP. I don't have a player log as I haven't been launching via the Unity launcher. But here is link to my KSP.log with the NULL OBJ and other exceptions. Logs: https://drive.google.com/file/d/1xwmfpA1E0YaXJSTKTUSXKiK7nzpdc7l8/view?usp=sharing [edit] Crashed just now with GPU error when loading launch scene (EVE uninstalled): i965: Failed to submit batchbuffer: Bad address

I get tons of NULL OBJ refs, from a variety of sources since Breaking Ground on linux. None of the orbits in my sfs have IDENT. And I'm running EVE. If this fixes the issue, I'm going to celebrate with pizza and everything

I'll throw in here that if you can recover that upper stage via Stage Recovery or otherwise those costs can be recouped quite a bit. I'm using kOS to make smart boosters with a reserve burn-back tank and on separation they burn back toward KSC and parachute nearer to it which recoups more funds. The lower boosters typically don't bother burning back, just chute down from where they are separated (depends on horizontal distance mostly). I'm looking forward to converting the upper stages to hydrolox, but I have a few things to tweak yet before making that big conversion. I'm also playing with a script that will allow upper stages on separation to determine if, given their reserve fuel and current vector, it would make more sense to circle around semi-orbital or even orbital prior to returning toward KSC. Because sometimes I find a sweet spot in my launch trajectory that my upper stage ends up nearly in orbit, or close enough, to make an air-scraping circuit around rather than burning retro back to KSC which is a very high cost at the point of upper stage separation

Not that it will surprise anyone following this subthread, but after installing 1.10.1-1 my pink planets are back to normal

From what I've gathered, and I'm open to being better educated by someone with more knowledge, Click-through-blocker only works very well with mods that are coded to work through click-through-blocker. Often altering the "focus follows click"/"focus follows mouse" can alleviate issues with mods that aren't specifically coded to work with click-through-blocker. But for some mods, until the mod is recoded to work with CTB, there may not be a satisfactory solution for that specific mod, which leaves one having to choose between the mod in question, or CTB, or finding a work-around in how one uses the GUI

I don't know about all the other bozos on the internet, but this bozo appreciates your efforts. Without knowing it as a certainty, I would bet that the people who are good at shaders didn't start that way and got better by trying anyway, lol. Yet another example of on-the-job training, right? FWIW, I'm ok with the previous version that works for now. I kept playing for quite a while with the big pink planets so it wasn't a show stopper for me anyway I know that the first thing I'd do is a 'diff' of the version that works and the one that doesn't. It could just be a minor typo, but it kind of smells like the code isn't taking into account some operation that needs to be special for open-gl or something. Or maybe it isn't properly detecting the open-gl at that point in the code. Looking at another similar shader that handles both open-gl and non-open-gl successfully in a similar situation might show what is missing in the shader in question. When I'm in over my head in code I make a lot of use of similar code that works for comparison purposes

I've just been flying around pink planets and trying to ignore them. But it is getting a bit cloying, lol. And trying to find KSC when returning home can be more complicated. Is the link you posted on mediafire the 1.10.1-1 flavor? Actually, it looks like CKAN still has the -1 available, I'll just swap via CKAN. Thanks guys

I'd rather get it straight from a git repos or similar, but thank you So it looks like on git that the only shader modified remotely recently is SpherePlanet.shader. How do I get the older version of that from github? [edit] looks like SphereCloud.shader was also modified recently.