steve_v

Because, for the billionth time *people do not listen*. It has been tried before. They do not listen when mod authors say "Do not report WinX64 bugs here" They do not listen when mod authors say "Re-enable at own risk, warranty void" If it's 'confusing a pile of people', it's because they *do not listen*, and do not read the OP before downloading. Is it so much to ask that people RTFM before complaining? This is not a case of 'disliking' x64, it's a case of getting fed up with dealing with irrelevant bugs outside the authors control and a constant stream of people who apparently cannot read.

Me wants bonus points - does it count if assembly is the *only* programming I've done for PC?

As far as RAM goes, the more the merrier. (and RAM is comparatively cheap) What you're not using for applications gets used as buffers / cache, even with an SSD that's a noticable improvement in file access latency OTOH, I have 16GB in my gaming box and every now and then I'll find some zombie process lurking when it should have died long ago - usualy KSP. Sudden performance nosedive, swiftly followed by OOM killer activation The Linux OOM killer even terminates the right process... most of the time.

Not exactly a gaming box, but kinda related since it's where my KSP install lives. (and I had a pic lying around) 10TB ZFS pool / fileserver Webserver MPD server Other stuff... Q8400 @ 3.2GHz 8GB RAM 8x 7.2KRPM 2TB in raid-z2 1x 64GB SSD Cache 2x 10KRPM 160GB in raid 1 (OS) SiS 305 PCI GPU Debian wheezy x86_64 Old, but reliable.

Cool part, but your archive is screwey: $ unzip TT_SSP_MK2_Nose-0.2.zip Archive: TT_SSP_MK2_Nose-0.2.zip extracting: GameData checkdir error: GameData exists but is not directory unable to process GameData/TouhouTorpedo/. checkdir error: GameData exists but is not directory unable to process GameData/TouhouTorpedo/TTSPPnose/. checkdir error: GameData exists but is not directory unable to process GameData/TouhouTorpedo/TTSPPnose/Cockpit.png. checkdir error: GameData exists but is not directory unable to process GameData/TouhouTorpedo/TTSPPnose/Cockpit_NRM.png. checkdir error: GameData exists but is not directory unable to process GameData/TouhouTorpedo/TTSPPnose/model.mu. checkdir error: GameData exists but is not directory unable to process GameData/TouhouTorpedo/TTSPPnose/part.cfg. inflating: readme.txt $ 7z x TT_SSP_MK2_Nose-0.2.zip 7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_NZ.UTF-8,Utf16=on,HugeFiles=on,8 CPUs) Processing archive: TT_SSP_MK2_Nose-0.2.zip Extracting GameData Extracting GameData/TouhouTorpedo Extracting GameData/TouhouTorpedo/TTSPPnose can not open output file GameData/TouhouTorpedo/TTSPPnose/Cockpit.png can not open output file GameData/TouhouTorpedo/TTSPPnose/Cockpit_NRM.png can not open output file GameData/TouhouTorpedo/TTSPPnose/model.mu can not open output file GameData/TouhouTorpedo/TTSPPnose/part.cfg Extracting readme.txt Sub items Errors: 4 UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP. Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ; see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites. Compiled with gcc 4.8.2 for Unix (Linux ELF) on Apr 24 2014. UnZip special compilation options: ACORN_FTYPE_NFS COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported) SET_DIR_ATTRIB SYMLINKS (symbolic links supported, if RTL and file system permit) TIMESTAMP UNIXBACKUP USE_EF_UT_TIME USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported) USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported) UNICODE_SUPPORT [wide-chars, char coding: UTF-8] (handle UTF-8 paths) LARGE_FILE_SUPPORT (large files over 2 GiB supported) ZIP64_SUPPORT (archives using Zip64 for large files supported) USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.6, 6-Sept-2010) VMS_TEXT_CONV WILD_STOP_AT_DIR [decryption, version 2.11 of 05 Jan 2007] UnZip and ZipInfo environment options: UNZIP: [none] UNZIPOPT: [none] ZIPINFO: [none] ZIPINFOOPT: [none]

Huh? I haven't seen a solenoid in a computer outside a museum.

Pure. Genius. Also, +1 on the Linux X64

Wise words indeed, IMO the crux of the issue. I for one loathe restrictive licensing - It often prevents well meaning folks from adding value or results in reinventing the same wheel over and over. Duplication of effort is not fun. An open license allows people to *work together* to make code better. Using it as an excuse for unpleasant behaviour helps nobody and indicates that you have completely missed the point. How about just having a little patience? When the WinX64 build is stable enough to be supported, these checks will likely go away. If you really must have it right now, take it as an opportunity to learn something about how the code works and remove the check yourself, for your own use. Be thankfull that the license allows you to do this. Going against someones express wishes after they have put in a whole heap of work for free is just plain rude.

EditorExtensions FAR KJR ProcFairings Stock Bug Fixes

I see quick 'recipe' at post #38, release thread. Not real obvious if you don't read the whole thread, but it's there.

Thank you Claw, you just made the game 1000% less annoying.

Ya know, I was going to try to make it clearer - but I don't think I can. Before posting on the other thread regarding how easy this is, and potentially being a right d*ck, I did it myself. I have never coded anything in C#, I usually work in ladder or functional block on embedded devices - I hesitate to even call it code. I have never used monodevelop before (on GNU/Linux, so no VS for me). It went like this: So, I need an IDE: Google reveals that there is a KSP wiki page on setting up VS / MonoDevelop. I needed the code (duh): pull the GIT master, unpack it somewhere. Load it up: Within IDE, find downloaded project. I keep hearing the term 'solution', so lets try that '.sln' file. Oh, lookie, some files with a big red 'X' beside them under 'references' tree - recon I've seen those files somewhere - find & add my copies (see aforementioned KSP wiki). Aha! a file called CompatibilityChecker.cs - wanna bet it's in there? A line that sets 'IsWin64'? looks like a good place to start, lets see if I can break it Since I obviously don't want it to return whatever it's currently returning, lets just make it return 'false' and comment out the check (there are obvious comments starting with '//', lets use that). Hit 'build'. Bingo! shiny new dll for me. Regarding more cunning checks - now that we know what a check for Win64 looks like, it's pretty straight forward to search through the rest of the code for the same, rinse, repeat. If I had seen Senshis post before attempting this, It might have shaved a whole 5 minutes off the process - It's an excellent guide & that's really all there is to it. G'th, have you actually *tried* following the steps outlined? If so, what didn't work? I'm pretty sure someone can set it right.

Fairly sure my first launch was an SRB & a command pod. Also pretty sure it didn't end well. Then I discovered parachutes

FWIW, I too have seen this. Only occurs occasionaly for me & my logs are squeaky clean. I've only ever seen it with Karbonite parts, but that may well be a coincidence. 99% of the time all is well on the second go. Debian Sid / x86_64, I'd test on x32, but ~6.5GB RAM usage and all... I'm not too sure where to go with tracking it down, strace just shows an (open) on the texture in question then nada - so I guess it's inside KSP, where I can't get at it. Ideas anyone? do we have another bug in the texture loader?

IIRC stock KSP will remove your ship (or the decoupled parts) if in atmosphere and >2.3km from the controlled vessel... I'm hoping this will change someday, but for the moment there's FMRS, or StageRecovery if you want something a bit lighter just for recovering booster stages (my favoured solution, as I haven't found a good use case for the design you're working on... yet) You can stage your parachutes with the decouplers, but the 2.3k thing still applies. Also, opening chutes while moving upward at high velocity can have... unintended consequences. All my lifters have chutes on the boosters, with stagerecovery. Works nice, more funds SmartParts has altitude based triggers and other goodness, but hasn't been updated for 0.25 so YMMV.

There's a mod for that Here ya go

Precisely. However in order for such a filter to be effective it has to require *some* effort. The relevant code is easy to find, and easier to disable. Information on installing a C# compiler / IDE is abundant on the 'net. You don't need to know how to code, just how to use a search engine and follow instructions. As much as I respect the spirit of the suggestion for a dedicated thread, I really don't see what spoon-feeding is going to achieve - apart from lowering an already quite reasonable bar. If people cannot even read the stickied posts re. how to report bugs or the 'WinX64 NO SUPPORT' message (often in big bold red) in the OP, what makes you think they will follow the instructions re. how to re-compile a dll? By all means, open such a thread, I might even be inclined to help where I can. Call me a pessimist, but I predict it will quickly turn into a mess of endless spoon feeding requests & 'you just do it for me plz, this too hard'. If it remains a 'how to compile mods from source' thread, all good. If it turns into a hacked dll distribution thread, not so much. The urge to help each other is strong, but let's ensure that the helping does not make life harder for those most valued members who make the shiny toys, lest they go away.

Ya know, 'waaah linux is too hard' doesn't really achieve very much - If you have a question, go ahead and ask it. I just installed Xubuntu on a spare drive - mostly to see how the other side looks Installed GPU drivers and updated the system, I didn't see a command line once. ~20 minutes in and I'm 'unziping ksp' and 'double clicking' KSP.x86_64. (actually, I'm launching it in a shell, but I *could* have worn out my mouse button if I wanted to.) GNU/Linux has really come a long way in terms of 'newb friendliness', I was surprised. Then I wiped it to give the latest PC-BSD a spin Used to run Arch, but got lazy re. constant updates. Might have to give Manjaro a go, it sounds like a good comprimise - Debian stable can be a bit *too* 'stable' if you know what i mean. On a less ornery note, ZFS is pure awesome

Yeah, tell me about it. Even the vendors paid support really just says 'use our black-box IMC instruction, designed for just your application' with nill information on how it actually operates internally This approach usually works, with a little fiddling, but one learns nothing from the exercise. Unfortunately my job desription is implementation rather than design, so on the rare occasion an in-house solution is required, I'm just shoving a process engineers math into the controller & tweaking the knobs. I'm a bit of a perfectionist, so the whole scenario really annoys me. But hey, time is money so once it 'kinda works' it's time to move on to the next one

I'm an industrial electrician, with some experience in automation / PLC programming. Mostly ladder logic on the AB PLC5 but starting to get into structured text and functional block. I get to play with a fairly wide range, from 1960s analogue hand-wired TTL controllers to state of the... multithreaded multi-language PLCs. But it's usually fixing someone elses code. or trying to read german blueprints and 'now, what does this jumper do?' A KSP automation system in ladder would be very, very cool... Also, PID loops can be a royal PITA IRL, despite being *just* simple math on paper... Especialy when someone else's 'just works' solution is in place and the process... err, changes. Some of the newer model based controllers are pretty interesting though.

The same way RL landers do it: carrying enough fuel to land somewhere flat Using SAS is cheating IMHO.

IIRC this issue cropped up with 0.24.2, numpad produces null characters with numberlock on. True for stock and therefore passed to mods. Seems I can't find the bug report anymore, but it's certainly still an issue for me. I can map the numberpad keys to action groups as a workaround and the camera controls work fine with numlock off. Needless to say I too would be interested in a solution...

You have B9 installed, yes? FAR nerfs stock turbojets to ~mach 5.5 IIRC B9 nerfs stock turbojets again - to ~mach 3.5, 'cause otherwise they're better than the B9 jets... File in question: B9_Aerospace-Squad_Jet_Balance.cfg. Remove it if you don't like it

Get the dev build?

Well that is pretty wierd, I can't reproduce any of this on either the 64 or 32 bit builds. I am, however, not running steam. What command-line & environment does steam use to launch KSP? How does it fail? You're 64bit native right? just guessing here, but I'm thinking maybe you don't have all the 32bit libraries installed, so steam is loading it's own copies from the steam 'runtime'... which may well be where the problem lies. EDIT: looks like I've been beaten to it Steam does preload old libs, very old - from ubuntu *12*.