[0.90] Kerbin Shuttle Orbiter System v4.13

[p1t1o]

This was a clean .24 install, with only mods updated for .24, or confirmed to work as is in .24 installed. The only thing copied over was my .23.5 save. (Which is backed up along with my entire .23.5 install because I forsaw .24 being bad.)

So...NOT a clean install then...

Try a REAL clean save and come back.

Just because someone puts [0.24] in their mod header, doesn't necessarily mean its kosher. And any Kerbal worth his Kerbal-Salt knows that all savegames are suspect after a major update - yes, even if all your mods have [0.24] in the title.

[Avalon304]

So...NOT a clean install then...

Try a REAL clean save and come back.

Just because someone puts [0.24] in their mod header, doesn't necessarily mean its kosher. And any Kerbal worth his Kerbal-Salt knows that all savegames are suspect after a major update - yes, even if all your mods have [0.24] in the title.

Clean install as reference to 'not taking a heavily modded .23.5 install and updating the KSP bits' in the post I was responding to. Kindly read.

False.

When mod authors say they have recompiled their mods for .24 to ensure compatibility, I would expect that it would be 'kosher' as you put it. If a mod says [.24] in the title, with no other caveats, I EXPECT it to work for all .24 builds.

Additionally... save games are only suspect if the developer (in this case Squad), says the update will break save games. As it was, I saw no such warning about .24.

[helldiver]

So the extremely RAM-hungry mod doesn't work with the version of the game which gives us a usable amount of RAM?

What are some examples of plugins which 'conflict'?

Extremely RAM hungry mod?

Do you know anything about resource usage let alone how KSP handles resources?

Let me clue you in.

-Can we share an IVA without repeating the same texture? NO We need two copies of the same texture if we want two different models to use assets from one another. Is that my fault? Am I a programmer? Is Nazari a Programmer? Non of us are. We do with what we have.

Who's fault is it? Squad

-Unlike other mods out there, KSOS shares resources on the same texture sheet. This has significant savings in VRAM, and also in available system Memory. Had the parts been split off into their own texture sheets you'd have had a significantly larger download and install footprint.

Can we compress such resources into DDS format or any industry grade format without using ATM or some other 3rd party plugin? NO

If Squad was so supportive of Modders, then the above two problems should have been resolved by now. The engine should be able to pick up industry texture formats such as DDS without the need for us to look for 3rd party plugins. Additionally we need a global texture directory per mod or we need to be allowed to direct an Internal to exactly what texture we want it to use. This bullshit of being restricted to "spaces" is part of the problem

gives us a usable amount of RAM

What the hell are you talking about? What version of KSP gives you more RAM? Oh right, 64 bit which doesn't. It allows it to address more memory sure, but the bottleneck is still, and has always been there.

Can you play KSOS alone + 64bit, sure. The average user isn't using KSOS alone. They are using B9 + KAS + FASA + KW Rocketry + Kitchen Sink. So pretty much everyone including me are way over the pathetic amount of RAM that 64bit would give us anyhow. I said it multiple times on the Dev update. No one listened or cared.

what are some examples of plugins which "conflict"?

It seems you think we (Nazari, Avalon, Westi, Freeman, and every other tester) don't test this ?

Random crashes and reports would point to SmokeScreen

Random crash and report would point to MechJEb

Random crash after putting RPM 0.18 in

Random crash and report would point to Firespitter.

Random crash and report would point to "out of memory"

Random crash and report would say nothing.

Random crash when launching (going from VAB to Launch pad)

List goes on.

KSOS is an art mod. That's all it is really. One more time: Kerbin Shuttle Orbiter System including packs are an Artwork Mod. These types of mods are not a priority for developers. Never have been never will be. They create more problems for them and straddle the border between digital rights management.

The mods that Squad does support are data specific mods (i.e. MechJeb, Ferram Aerospace, DRE, etcetera, with a few notable exceptions).

Had they supported a mod like this, I'd have had one of them ask me a simple question: "Your mod uses lots of IVAs, what can we do to make it so they aren't so resource intensive?"

Answer: "Let me choose where I want the asset to look for its textures".

It... isn't a pile of crud? It... is basically the community 'hack' from a couple weeks ago. They just started building KSP against the 64-bit windows Unity Player, and did so fairly late in the development cycle. There are a small handful of bugs which haven't been ironed out, but KSP_x64 is very playable - far moreso than the 32-bit game if you use any more than a couple mods.

No one in this thread (especially me) give a if it's playable. Your argument is irrelevant. I know it's playable stock. I know it's playable with any data mods or a few mods that add a few things. We all know that. I doubt any of us care. We care if it's playable seamlessly with KSOS installed.

So you're saying it's perfectly playable with KSOS installed then?

The only mod which has x64-specific bugs is KAS, which hasn't even been updated for .24.

Your groundless negativity is annoying.

Which isn't true. Based on 6 testers plus Nazari and I having random crashes. Avalon is fully justified in his statement.

Additionally the most important mod for a large majority of Mod users; Active Texture Management has been broken by 64bit and is not fully functional.

Uhm. Ok, there is a lot wrong with basically everything you just said.

1) using the 64-bit client is optional. Just run KSP.exe (or launch the game via steam if you have it on steam), and it will run the 32-bit version of the game. If that doesn't work for you, reinstall\reverify the game, because your problem has nothing to do with the 64-bit implementation.

2) If you cannot get the game loaded at all, with no mods installed, that is not the fault of any mod.

3) The community 'hack' is more or less how Unity works, bro. The flaws have to do with specific aspects of Squad code which doesn't take quirks of the 64-bit Unity engine into account, which will, frankly, take some time and iteration.

I'm reminded of a quote from a signature '"It's in Alpha" isn't an excuse, it's an objective assessment. It's not my fault that it continues to be relevant.'

Very well then, on that I can agree.

As I mentioned and said in the OP, KSOS is now 32bit only.

And to correct you; 64bit doesn't work for my testers or for Nazari or for myself. KSOS+64bit KSP doesn't work equals KSP doesn't work. If you're in this thread, are a KSOS tester or developer, 64bit KSP doesn't work. End of story.

Telling us how great it works stock or with a few chosen mods doesn't help this thread and is bordering on OT-Spam.

Each and every plugin the KSOS uses work perfectly fine standalone. Soon as they come together in a 64bit environment all of us are having crashes. None of us are programmers, none of us wrote those plugins. None of can take the blame for any of those plugins and the project not working.

None of us are adding embellishments to the KSO's. In fact I've been on a feature cutting crusade since day one.

None of us do any special programming or anything outside the basics that Nazari needs to do to get our stuff to work with Firespitter.

As such, we're at the mercy of the plugins that run the mod. If we can't pinpoint a specific problem because we're getting random crashes, we have to point the blame at Squad.

Will it get fixed eventually? Hopefully.

Are some of us upset that 64bit didn't work out of the box? You bet.

To add: There is no plugin authoring in KSOS. In fact we don't even have a plugin author on our team, I'd like one, but we just don't have one. Nazari doesn't do any programming at all. I do the artwork, textures, spit it out to FBX and all it is, is 3D mesh data and texture UVW coordinate data. That's it. There is no programming or anything embedded (such as Gamebryo/Nif file formats).

Nazari then grabs that 3D mesh and assigns it to either Firespitter, KM_Gimbal (Space Shuttle Engines mod), Raster Prop Monitor, or SmokeScreen. That's it. He doesn't do any voodoo magic, or special hack code or anything. If one of those three plugins has a feature we use, great. Otherwise we don't have it.

Currently the KSO's are:

-Flight controls and flight characteristics are driven by Firespitter. His FS modules are the best so far.

-Engine Nozzles are driven by SSE (KM_Gimbal).

-IVA's are fully driven by RPM. Stop thinking that RPM just does the screens. No... RPM drives all the gauges, the flight stick, and soon the ability to exit the IVA through the door.

-SmokeScreen drives the smoke effect of the nozzles.

Is it my fault that the project is one big download? Yes. And I'm glad it's been kept that way now, since finding bugs and conflicts is a heck of a lot easier.

Moving forward however, we'll be splitting it up into four separate packs plus an installer.

Edited July 22, 2014 by helldiver

[helldiver]

There's nothing interesting changed between 0.17 and 0.18 RPM that would prevent 0.18 RPM from working with KSO if it worked with 0.17. Any changes refer to third part mods RPM supported: MechJeb, if you use it, needs to be 2.3.0 or later, and SCANsatRPM.dll needs to be deleted, so that SCANsat 0.6.1 can do it's magic. No changes to KSO files should be required.

Incidentally, I only test RPM on x64, myself, so if anything breaks in x64, it's not me.

Awesome!

On my test it caused a crash each time I'd load KSP. But I think it had to do with 64bit. Will test again thoroughly once I get Nazari's setup.

[colmo]

When I tested KSO on 64 bit Linux, it worked fine. Is this still the case in 0.24?

[qnistNAMEERF]

When I tested KSO on 64 bit Linux, it worked fine. Is this still the case in 0.24?

Well, as helldiver said just two posts above you, it doesn't appear to work properly in 0.24 64bit for us. Random crashes and such. Try it out and let us know.

[Damaske]

I have been having rather good luck running a modded 64 bit KSP. I don't mind attempting to run this mod with the current smaller ones that I have been testing minus the B9 stuff, or a trimmed out B9 stuff. I've found that a lot of that mod I've not been using much so it is going to lose some extra baggage. When trimming out pieces that I done use what is the best method? Just the config files or search for and remove any unused image files, aka pod IVA's, part textures, ect.

[vardicd]

Its always embarrassing when we, {the players} act like little kids throwing a temper tantrum in the store cause we can't have what we want right now. Helldiver, Nazari, anyone else involved, you guys made one of the best looking mod[sets?] out there, and you aren't paid for it. I want you to know your efforts are appreciated. Thank you. {and, it may be frustrating to listen to and deal with, but at least you know people like your mod, if they hated it, they wouldn't care about bugs/crashes/broken installs/user errors. Nothing says we love your mod like starting a fight over it. }

[colmo]

Well, as helldiver said just two posts above you, it doesn't appear to work properly in 0.24 64bit for us. Random crashes and such. Try it out and let us know.

I was specifically interested in Linux. Most of the issues with 64 bit appear to apply to Windows? 64 bit has been virtually perfect for the last few versions on Linux.

I'll give it a go and report back - AFK right now so haven't got my mitts on 0.24 as yet.

[qnistNAMEERF]

I was specifically interested in Linux. Most of the issues with 64 bit appear to apply to Windows? 64 bit has been virtually perfect for the last few versions on Linux.

I'll give it a go and report back - AFK right now so haven't got my mitts on 0.24 as yet.

Yeah, sorry. I don't think any of us have a linux version. I might invest in it but none of my linux systems are really capable of running this game.

[Mikare12]

Why this is not working in 64bit version?Update to make working 64bit version, please...

[qnistNAMEERF]

Why this is not working in 64bit version?Update to make working 64bit version, please...

It's really out of helldiver and Nazari's hands. It's up to the plugin authors and Squad for this mod to run properly on a 64bit client. As it stands, it's not possible to pin-point what is exactly the problem other than it's running in a 64bit client, since the same setup on a 32bit client runs on a whole other level.

[montyben101]

Did you notice there's an update for firespitter, not sure if it's for 64 bit though

[EthanKerbman]

Helldiver, thanks for giving me two reasons to drop KSO for good...

[Alewx]

Why this is not working in 64bit version?Update to make working 64bit version, please...

KSPx64 is not a stable release! There is simply no guarantee that a mod and/or the game will be stable in 64bit.

Mostly because Unity3D, they lacked to implement x64bit for Windows earlyer and better, already for years!!!!

Of course it is totally frustrating to have crashes in the game and in the mods, for developers and players.

But first blame Unity! they made the engine and the bas 64bit support. Two years ago they were not even willing to discuss x64 support.

So the correct order to blame the ppl is: Unity for god damn late and bad Integration of x64 and then squad for bad use of it.

Bringing the hate up through the whole chain is not efficient, start direct on the top and then downwards.

And if I remember correct there is a way to assign textures from different locations, but then you have to assign the model and the textures as a submodel. I can look that up this evening.

[enneract]

Extremely RAM hungry mod?

Do you know anything about resource usage let alone how KSP handles resources?

Let me clue you in.

-Can we share an IVA without repeating the same texture? NO We need two copies of the same texture if we want two different models to use assets from one another. Is that my fault? Am I a programmer? Is Nazari a Programmer? Non of us are. We do with what we have.

Who's fault is it? Squad

-Unlike other mods out there, KSOS shares resources on the same texture sheet. This has significant savings in VRAM, and also in available system Memory. Had the parts been split off into their own texture sheets you'd have had a significantly larger download and install footprint.

Can we compress such resources into DDS format or any industry grade format without using ATM or some other 3rd party plugin? NO

If Squad was so supportive of Modders, then the above two problems should have been resolved by now. The engine should be able to pick up industry texture formats such as DDS without the need for us to look for 3rd party plugins. Additionally we need a global texture directory per mod or we need to be allowed to direct an Internal to exactly what texture we want it to use. This bullshit of being restricted to "spaces" is part of the problem

I think you read in some hostility that just wasn't intended. KSOS increases the memory loading of KSP by about 500MB without ATM, which is totally in line with other mods which add a comparable number of parts which don't reuse squad textures. I wasn't trying to imply that KSOS uses *more* memory than is reasonable, simply that it does use quite a bit in absolute terms given the ceiling imposed by 32-bit address space, and that it was ironic that the advent of an official means of increasing that ceiling appeared, only to become incompatible (for certain values of incompatible, at least)

What the hell are you talking about? What version of KSP gives you more RAM? Oh right, 64 bit which doesn't. It allows it to address more memory sure, but the bottleneck is still, and has always been there.

Can you play KSOS alone + 64bit, sure. The average user isn't using KSOS alone. They are using B9 + KAS + FASA + KW Rocketry + Kitchen Sink. So pretty much everyone including me are way over the pathetic amount of RAM that 64bit would give us anyhow. I said it multiple times on the Dev update. No one listened or cared.

I used 'RAM' as a poor synonym for 'memory allocation space'. My bad.

I'm not sure where you are getting 'pathetic' amount of address space available with the 64-bit build. I haven't loaded my .24 install this heavily yet, but back in .23.5, using the linux 64-bit build, I was routinely at 9-12GB allocation. That... isn't pathetic. The windows 64-bit build isn't as mature. It will get there, eventually.

That being said, you are totally correct in that Unity's memory allocation is somewhat ... poor, and Squad hasn't even made full use of the capabilities of the engine in that regard. The fact that all game assets are loaded at all times is the largest, but certainly not the only, glaring problem.

It seems you think we (Nazari, Avalon, Westi, Freeman, and every other tester) don't test this ?

Random crashes and reports would point to SmokeScreen

Random crash and report would point to MechJEb

Random crash after putting RPM 0.18 in

Random crash and report would point to Firespitter.

Random crash and report would point to "out of memory"

Random crash and report would say nothing.

Random crash when launching (going from VAB to Launch pad)

That.. is kind of what I asked after, actually. I was curious what was actually causing problems.

KSOS is an art mod. That's all it is really. One more time: Kerbin Shuttle Orbiter System including packs are an Artwork Mod. These types of mods are not a priority for developers. Never have been never will be. They create more problems for them and straddle the border between digital rights management.

I have no idea what you are trying to say with this statement.

The mods that Squad does support are data specific mods (i.e. MechJeb, Ferram Aerospace, DRE, etcetera, with a few notable exceptions).

Had they supported a mod like this, I'd have had one of them ask me a simple question: "Your mod uses lots of IVAs, what can we do to make it so they aren't so resource intensive?"

Answer: "Let me choose where I want the asset to look for its textures".

Squad does not 'support' mods, full stop. I'm pretty sure that you are using the word 'support' differently than I would use the word 'support', but even in terms of 'encourages the existence of', I would be dubious of any claim that squad supports mods. The state of the API makes that reasonably clear.

No one in this thread (especially me) give a if it's playable. Your argument is irrelevant. I know it's playable stock. I know it's playable with any data mods or a few mods that add a few things. We all know that. I doubt any of us care. We care if it's playable seamlessly with KSOS installed.

So you're saying it's perfectly playable with KSOS installed then?

The person I was talking to was making the claim that the 64bit build did not work 'out of the box'.

As to if KSOS is playable on 64bit... seems to be so far! I'm running with ~5GB allocated and no crashes thus far. We'll see as time progresses.

Which isn't true. Based on 6 testers plus Nazari and I having random crashes. Avalon is fully justified in his statement.

Additionally the most important mod for a large majority of Mod users; Active Texture Management has been broken by 64bit and is not fully functional.

ATM is 100% unnecessary (and makes things look like crap to boot) on a system with adequate physical RAM, a decent GPU, and running a 64-bit build of the game; or at least will be once the windows 64-bit build is more mature.

The reason why some mods may be more broken on 64-bit KSP has to do with differences in the way that Unity implements certain functions between the two versions. These differences seem to be more profound on Windows than on Linux, or maybe the Linux 64-bit builds are more 'compensated'.

And to correct you; 64bit doesn't work for my testers or for Nazari or for myself. KSOS+64bit KSP doesn't work equals KSP doesn't work. If you're in this thread, are a KSOS tester or developer, 64bit KSP doesn't work. End of story.

So which is it, Avalon is justified in saying that 64-bit KSP doesnt work full stop, or ' KSOS+64bit KSP doesn't work equals KSP doesn't work'?

Telling us how great it works stock or with a few chosen mods doesn't help this thread and is bordering on OT-Spam.

'few chosen mods', yep

Look... again, I think you read a ton of hostility into my post that just wasn't there. I found the situation ironic, and asked for more information about which plugins were crashing on 64-bit specifically, that is all.

.. and then I got irritated at an apparent illiterate who was more interested in hyperbolic quasi-profanity, and blaming his inability to follow basic modding practice (use a clean install for new major versions) on the game's developer.

Edited July 22, 2014 by enneract

[helldiver]

Did you notice there's an update for firespitter, not sure if it's for 64 bit though

We're using 6.3.3 should be the most recent 0.24 compatible version. I'll keep checking.

Helldiver, thanks for giving me two reasons to drop KSO for good...

1 post and joined today. Sorry this mod won't work for you. I know I won't make everyone happy. I can assure you we've had many folks who've come here, tried it, didn't like it for one reason or another and proceeded to uninstall.

[montyben101]

I understand your frustration but at the end of the day squad IS a company and as much as I would like them to do all the things you say they probably just want to appeal more to the casual gamer on steam to make more money. To be honest I think they should convert to a different, more advanced game engine, though that would probably cause more bugs and crashes than 64 bit

[helldiver]

I think you read in some hostility that just wasn't intended. KSOS increases the memory loading of KSP by about 500MB without ATM, which is totally in line with other mods which add a comparable number of parts which don't reuse squad textures. I wasn't trying to imply that KSOS uses *more* memory than is reasonable, simply that it does use quite a bit in absolute terms given the ceiling imposed by 32-bit address space, and that it was ironic that the advent of an official means of increasing that ceiling appeared, only to become incompatible (for certain values of incompatible, at least)

I used 'RAM' as a poor synonym for 'memory allocation space'. My bad.

Very well then, I kind of did. If you did not intend, then my apologies. But I still believe Avalon is justified in his statement. And to clarify (he'll have to clarify himself) I'm of the opinion that he too meant KSOS+KSP64 bit working or not. Not 64bit standalone.

'few chosen mods', yep

You have as many mods as I do, minus about three. The majority of which are data mods (I admit I'm not running some of the special mods you're running like kerbquake) but in terms of resource usage it's about the same. So you're able to get to work fine on Windows 64bit then? Great.

I'm not sure where you are getting 'pathetic' amount of address space available with the 64-bit build. I haven't loaded my .24 install this heavily yet, but back in .23.5, using the linux 64-bit build, I was routinely at 9-12GB allocation. That... isn't pathetic. The windows 64-bit build isn't as mature. It will get there, eventually.

It's been reported that the 64bit Linux client doesn't seem to have the random crashing issues the Windows version has. I got reports of "oh it works fine"...."Linux 64bit". That really doesn't help me. Majority of users are on windows.

Oh and by the way, it's worked fine for me as well... sometimes. In fact I even came on here and reported that it worked fine and had no crashes. Suddenly after further testing (exiting KSP completely and starting again) random crashes would occur. Just because I'm able to start it up and get to the VAB 9/10 times does not mean working perfectly ;D

That.. is kind of what I asked after, actually. I was curious what was actually causing problems.

It's difficult to report to Sarbian, Snjo, Dtobi, or Mihara if there's an issue with their plugin when the crashes aren't consistent. If the log pointed at Firespitter each time, then I have something to report. If it's randomly crashing with MechJeb or RPM or Smokescreen or what ever, it becomes impossible to fill out a report. I suppose I can contact one of them to be kind enough to read my reports, but that's really asking them a bit on something that doesn't really have much to do with their mod. Additionally most of the crashes we've had were do to out of memory (16gb and 32gb systems here).

I have no idea what you are trying to say with this statement.

That I have never seen developers support "artsy" mods such as this. I'm suspect that Rbray never got contacted by Squad to help test or get access to 0.24 before it was dropped. Interesting that suddenly ATM is crashing when handling Squad resources. Could have been avoided by including him in the testing regimen. Again, I can't say for certain. They have not realized the critical importance of ATM (64bit or not).

Squad does not 'support' mods, full stop. I'm pretty sure that you are using the word 'support' differently than I would use the word 'support', but even in terms of 'encourages the existence of', I would be dubious of any claim that squad supports mods. The state of the API makes that reasonably clear.

-On both counts (or both usages of the term Support). Because you're right. The Dev Kit they had has long since vanished and the info available is scarce. Pity since Mods have been the biggest selling and staying point for this game.

The person I was talking to was making the claim that the 64bit build did not work 'out of the box'. As to if KSOS is playable on 64bit... seems to be so far! I'm running with ~5GB allocated and no crashes thus far. We'll see as time progresses.

Because he's right, I have to support that since we have the evidence in the reports. Lets throw Avalon out of the picture. Nazari would be saying the same thing. In fact it took some more loading and unloading for me to realize they were right, we are getting random crashes.

Now if Avalon meant KSP 64bit Standalone with a few choice data mods (and or mods that don't use our plugins in combination), then sure KSP 64bit is awesome. Anyone running stock KSP 64bit is probably having a dandy time. No argument there.

However, KSOS+64bit KSP does not work. 6 people, plus 1 or 2 in this thread now, plus Nazari and myself.

Are some people able to run it? Great awesome. Please PM on what your setup is. Hell, I'd even have you zip up your install and send it to me. I'll test it and make it the distributable.

ATM is 100% unnecessary (and makes things look like crap to boot) on a system with adequate physical RAM, a decent GPU, and running a 64-bit build of the game; or at least will be once the windows 64-bit build is more mature.

KSP doesn't have an asset manager. Meaning it's just going to keep loading resources into memory without unloading them. The only constant we have is that more and more mods will be made. KSOS is going to keep growing, and without a proper asset manager you're going to run out of resources.

The reason why some mods may be more broken on 64-bit KSP has to do with differences in the way that Unity implements certain functions between the two versions. These differences seem to be more profound on Windows than on Linux, or maybe the Linux 64-bit builds are more 'compensated'.

Well I wouldn't know about this. But if there is something we can do, like re-export everything out of Unity or something do let us know.

So which is it, Avalon is justified in saying that 64-bit KSP doesnt work full stop, or ' KSOS+64bit KSP doesn't work equals KSP doesn't work'?

As I mentioned, I'm assuming KSOS+KSP 64 bit, as only that would be relevant to our issues, Avalon would have to clarify. But to be honest with you, I believe Nazari's reports were KSP 64bit as a whole, he hasn't been able to get to start at all. That's really bad. It's really bad because if Nazari can't even get 64bit to start, we are dead in the water. Or I'll have to look for someone else to team up with who can get 64bit + plugins we use to work.

Look... again, I think you read a ton of hostility into my post that just wasn't there. I found the situation ironic, and asked for more information about which plugins were crashing on 64-bit specifically, that is all.

Point taken. I took it hostile as if I purposely made things be resource intensive. Check this out man, I use the minimum amount of geometry (usually boxes) and the minimum amount of texture space for like 80% of the stuff. We're at the bare minimum with phase 2 and higher. The older KSO uses more resources than I'd like to (that'll get fixed), but that was because when I started that, that was all I was going to make.

So to be accused that I'm either purposefully making things be more resource intensive and/or doing things that make it hog more resources is erroneous. On this thread I've been accused of that several times. It seemed like another case of that.

And you said it yourself; it doesn't make sense that we're crashing on a platform that's intended to give us more available memory.

I'm still working on Phase 4, that's not going to stop. Whether or not it'll work with 64bit, that I can't guarantee.

Edited July 22, 2014 by helldiver

[Sochin]

Wow so much negativity aimed at a modding team that is at the mercy of outside influences, what a pack of tools. Helldiver and his team have produced the best shuttle mod in this game, for gods sake get behind him because if he pulls out of KSP we are all at a loss. Helldiver if I could give you anymore rep I would have done for that very long retort post you did last night +1 in my book.

[Virtualgenius]

One of the things that has helped me reduce crashing with the 64 bit build was to move it out of the x86 folder Sarbian made a comment that windows maybe restricting execution of something, so i moved my steam install to c:\games\Steam its slowed down a bit of the random crashing and allowed me to actually make it to the space centre

[Prismatech]

have you test the textur res to reduce to half res . This help at 64 bit that fasa correct run.

[Avalon304]

As I mentioned, I'm assuming KSOS+KSP 64 bit, as only that would be relevant to our issues, Avalon would have to clarify. But to be honest with you, I believe Nazari's reports were KSP 64bit as a whole, he hasn't been able to get to start at all. That's really bad. It's really bad because if Nazari can't even get 64bit to start, we are dead in the water. Or I'll have to look for someone else to team up with who can get 64bit + plugins we use to work.

I mean Modded 64-bit as a whole. Not just KSO+KSPx64. Heres the thing. The ONLY reason we needed a 64-bit build of KSP was to run mods, specifically to run more mods. If KSPx64 runs perfect with a vanilla install... then whats the difference between running the x64 or x86 versions? Absolutely nothing. If I want to run vanilla KSP I'll run the x86 version and go on my merry way.

But vanilla KSP is boring. Im glad people like contracts and are excited for them, but the amount of time Squad took to implement structured gameplay into this game has given me enough time to not care about it having that structured gameplay. And if this game didnt have mods... Id have been gone long before version .24 was even released. So when the 64-bit version come out, the only reason you would ever run it would be to install mods. Mods are what are keeping people here between the major updates when all the vanilla stuff has been played out.

Understand, in .23.5, with my Alpha version of the KSOS and 4 or 5 other (small) mods and ATM-Basic, I was dangerously close to the 3.5GB memory limit imposed on 32-bit applications. Like within .2GB close... so the fact that the version of KSP that can let me use the full 8GB of my system RAM is crashing because of mysterious 'Access Violations' or 'Out of Memory' errors (the latter of which occurs when I still have RAM free, oddly enough) is absolutely 110% annoying.

Also, the fact that a game, upon launch, loads EVERY asset into memory, is 100% bonkers.

I'm going to keep at trying to figure out just what in my install is causing it to crash. And Im certain it is not the KSO System. Im suspecting its KW Rocketry... but Im going to deal with that after I sleep...

tl;dr: If a modded 64-bit KSP install doesnt work, then 64-bit KSP doesnt work. Full Stop.

[kujuman]

I'm doing testing of the KSO on the x64 version to see what I can see.

Fun fact: the .craft provided of the Super25 costs less funds than the original KSO

Edit: flight log. Note that all missions after mission 1 were flown in the same start of KSP.

Test No. Type Outcome
 1 S25 CTD about 2 mins into flight. Clicking IVA on jeb's face caused crash.
 2 S25 Successfully attained orbit. Started flight in IVA, switched to external and back to IVA several times.
 3 KSO Successfully attained orbit. Entire flight IVA.
 4 KSO Flew like an idiot, landed on the runway ~2.5 minutes after launch. Recovered KSO.
 5 S25 Flew like an idiot, stranded 6 kerbals in solar orbit. Switched between IVA and external.
 2b S25 Resumed flight of mission 2, successfully reentered and crashed the ship west of the KSC mountains. Crew survived.
 3b KSO Resumed flight of mission 3, successfully reentered and crashed into a random hill.

Edited July 22, 2014 by kujuman

[helldiver]

I'm doing testing of the KSO on the x64 version to see what I can see.

Fun fact: the .craft provided of the Super25 costs less funds than the original KSO

Edit: flight log. Note that all missions after mission 1 were flown in the same start of KSP.

Test No. Type Outcome
 1 S25 CTD about 2 mins into flight. Clicking IVA on jeb's face caused crash.
 2 S25 Successfully attained orbit. Started flight in IVA, switched to external and back to IVA several times.
 3 KSO Successfully attained orbit. Entire flight IVA.
 4 KSO Flew like an idiot, landed on the runway ~2.5 minutes after launch. Recovered KSO.
 5 S25 Flew like an idiot, stranded 6 kerbals in solar orbit. Switched between IVA and external.
 2b S25 Resumed flight of mission 2, successfully reentered and crashed the ship west of the KSC mountains. Crew survived.
 3b KSO Resumed flight of mission 3, successfully reentered and crashed into a random hill.

Your experience has been similar to mine.

I just ran KSP 64bit (after my response to Enneract) game ran fine. I was about to fall back on all I said...

Built a new station (since I lost my other one, although I have a back up save), was about to launch. Forgot a docking port.

Went back to VAB added said docking port, hit launch... CTD

Round 2

Did another test launch, no problem. I reverted to VAB since I didn't want to finish it.

Loaded my previous ship I built since I figured maybe things would work this time. Crashed when loading it in the VAB....

Round 3

Exited and restarted KSP... crashed on loading stuck on "model007".