NoMrBond

Unfortunately this is because the OS-X version KSP 0.25 is built on a different release of Unity than the Linux or Windows release and there is no way for stupid_chris to test on that version. Is RealChutes still working beyond just giving you the version warning?

Hi Winston and KAKyle, Whilst enjoying KWR (latest 2.6d2) I noted that the 3.75m docking port is only set for size2 nodes (both for stack_node and for docking) rather than size3 like the NASA/ARM/3.75m parts? Would it be causing lower joint strength after the 0.23.5/ARM adjustments to how joint strength works (would FAR also think there's a size mismatch i.e. a 2.5m part attached to a 3.75m part)? Best regards, NMB.

I think 3-4 was the last 0.24.x release, you can get it directly from rbray's github releases

Grayscale sounds like a height map rather than a normal map, I didn't think KSP even used those? Did KSP use heightmaps at some point in the past and those parts are old enough to use what is now a legacy shader? (still there in game, but we can't select it any more via the part tools)

You could try the 6-8 Beta release which rbray89 mentioned a little while back, it has minimum size support so things like the toolbar icons would be automatically excluded from compression and may fix your issue. Be warned however that it is a beta release and not a mainstream update so YMMV.

This sounds like a query for Deadly Reentry?

Hi balricaso, please fill in the following bug report (shamelessly stolen from FlexGunship) The details will help in solving any problems you may be experiencing ----- BUG REPORT Bug Title - one liner DATE SEEN date the bug was found goes here include the time, if you are submitting more than one bug VERSIONS Operating System and version KSP version Mod version other installed mods, if applicable hardware information, if applicable BUG DESCRIPTION A concise description of what the problem is. Pure description, no narrative or conversational language. SEVERITY: Trivial, Minor, Major, or Catastrophic STEPS TO REPRODUCE: Step by step instructions on how to reproduce this bug. Do not assume anything, the more detailed your list of instructions, the easier it is for the developer to track down the problem! Test these steps as you have them written. If they don't work then the bug is unreproducible and should not be reported yet. ACTUAL BEHAVIOR: Type what happens when you follow the instructions. This is the manifestation of the bug. EXPECTED BEHAVIOR: Type what you expected to happen when you followed the instructions. This is important, because you may have misunderstood something or missed a step, and knowing what you expected to see will help the developer recognize that. TROUBLESHOOTING/TESTING STEPS TRIED: Describe anything you did to try to fix it on your own. WORKAROUND: If you found a way to make the mod work in spite of the bug, describe how you did it here. ATTACHMENT: output_log.txt or player.log

If I could make a suggestion, would it be possible for a left click to toggle the display on and off, and right click to open the options menu?

xEvilReeperx is possibly working on updating ScienceAlert first, but they've definitely been active

Awesome rbray89 Does this include the sub-100px automatic occlusion you mentioned earlier?

Presumably like FireSpitter, where the all copies go to ...\GameData\DDSLoader\Plugins and if you want to include it, they all include the plugin at that exact location so they don't end up with multiple copies

There are quite a few reports of the modified stock chutes not playing nicely when modified by RealChutes in last two pages or so Until stupid_chris finds a solution, you can delete the Stock_Realchute_MM.cfg which comes with RealChute (the stock chutes will revert to their stock behavior) to solve the problem

Sorry yes, 0.25 (fixed in OP). It seemed smaller than it should be, and offset from it's attach node (pic from Binary_Omlet) I had the same issue too, looks like the KSPRC textures on their picture though so I'll check it on stock

Can fix the odd Turboject size by opening the \Kerbal Space Program\GameData\Squad\Parts\Engine\jetEngineTurbo\jetEngineTurbo.cfg Replace the model = and scale = lines with MODEL { model = Squad/Parts/Engine/jetEngineTurbo/model scale = 1, 1, 1 } Then it will fit (almost) properly (for both size and with it's assigned 1.12 attach node) [Edit] Still slightly too small but better than it was

It's not bugged in Windows-x64, it's disabled in Windows-x64. If you would like to use RealChutes with 64 bit KSP, you are recommended to use the Linux 64 bit version.

Thanks for all the work you put into the community dtobi, and going even further by passing the torch Best of luck in whatsoever you choose to pursue from here

This should probably be in the support forum? In any case, maybe something like AltInput or AFBW might help?

Updated and repacked 6S TubesSwitched to use ModuleAnimateGeneric (same as that used to animate the SPP+ cargo bays, no longer requires FireSpitter) Fixed scale/node positions The models and textures, original configs and all other works are Nothke's and this updated repack is provided for the convenience of 6S users under the permissions granted by the CC BY-NC-SA 4.0 license. Should Nothke wish this removed, or to incorporate the changes included and provide their own release I will pull this down immediately. Please see Nothke's v1.3 release for 6S

How about supplying a blank frame, no texture or internal anything, just a blank outline/skeleton/shadow of a wedge as a .blend/.fbx/.3ds/et al? Maybe including the transforms necessary for their attachment (if that's done using empties for the NODE{} system at the model level anyway) That way other modders could take it and build any out-of-scope stuff to fit inside this outline knowing that by following that framework it would fit exactly with/within the 'wedge' profile?

Thanks for the 0.25 update Biotronic I made a pull request on Github to update some KOSMOS sizes after noticing some oddities too

I have little problem with the no-support clause on TAC-LS or sarbian's Nyancat warning but I don't agree with the lockout. I can understand why the authors felt it was necessary though, and it is absolutely their choice to do so. A lot of people don't follow bug reporting practices, search for solutions before throwing blame, and harass authors with misattribution even when used in unsupported cases and it'd grind you down as well as suck up a lot of time. I'm not sure getting complaints from 100% of x64 users is better than getting complaints from some x64 users (even after the warnings) though?

(1) This link from the opening post should work http://www./download/i1k5kdcz9iw6yq9/RealChute_v1.2.5.3.zip (just a URL parse error in the post) Not sure about (2)

Maybe have a form response; support requests which don't use the form (filled in) don't even get looked at. You might also be able to find volunteers to essentially run initial support in the thread, and issues can only be escalated to you by one of the thread support volunteers

You could have multiple cloud configs, or it could be a compatibility problem between 7-4 (build for 0.24) and KSP 0.25 Do you have a picture of the issue, what version of KSP are you using (x86/32bit or 64 bit, and on what OS?), what version of EVE are you running, do you have the output log for troubleshooting purposes?

Go to Ferram's github page , it should be on the (linked) releases list