Mołot

Now? It would break crafts in savegames. At least we would need a "legacy" plugin with all these fairings available now to keep going until we could land or crash last ship still using them.

Who is responsible for making it required dependency instead of a suggestion in CKAN?! Come on, people, no need to force-feed this down users' throats. Whoever did it, I hope it'll get changed soon.

True, to some extent, but (as can be seen in official description ): "If you remix, transform, or build upon the material, you may not distribute the modified material." so it does prevent me from sharing my changes on the forum, or even from sharing them with my friends. If sharing it back with original author / maintainer is legal is somewhat gray area, there is no explicit exception for him in the licence. I believe that's what you meant, but that's not what licence text says. Also, most of other licences require attribution - so no "claiming as their own". For forking - do you really want to prevent that? Why, exactly? I mean, original authors didn't mind, in the first place. And if someone over there will show he can keep this up to date and enrich it's features, why not? If you will go GPL, you will be able to take his changes back as you please. And he'll be forced to mention all previous authors in his fork's description, so no "claiming". The problem with CC licences is that they were never really designed for code. Using any kind of it will make merry law hell to any kind of teamwork. See their own recommendation. If anyone knows where not to use CC, they do.

If you really really need it, you can compile it yourself, without that check. I did it, and so far it works. The best part? If you're the kind of user who hacks and compiles plugins, you probably have a good grasp of what comes from, and decency to test spotted errors with supported version before reporting anything.

Don't get me wrong, I don't want to make a fork, not really. But CC Attribution-NonCommercial-NoDerivatives may be interpreted in many ways. For sure I cannot release any patches, for example. So no-no for me hacking out toolbar requirement. Or, more truthfully, no-no for me to share it with you or anyone. Maybe even no for compiling code as-is. And using things like Active Texture Management starts to be dubious, as it creates uniform textures on people's computers - derivative for sure! Possibly legal as it's only cache and it's not distributed but that's grey area. If you want to develop DLL and everything on your own, good luck. But the licence you are thinking about would stop great people like Khatharr from contributing, and people like me from tinkering and sharing ideas. The latter is of no particular worth yet, but the former got this mod running again whilst you did not have time to do it. That's something, ain't it? CC for crafts would make sense, with the problems described above. For code (and parts' cfg files), if MIT is not what you want, there is a lot of opensource licences available. GPL or LGPL for example. I understand that if someone works on code for free, he may want this code to stay free, and that's something MIT licence does not ensure. But licence that makes you the only legal developer when you apparently could use some help?

Well, the package Khatharr posted was, is, and will be MIT license, as you can't effectively revoke it, you can only apply new license on new releases (even if you don't change code). And he released under MIT, forking your release under MIT, so we are free to work on it further. That says the license you used.

Thanks! Worked like a charm. Could I ask you two more things? Make it Toolbar - independent as 0.90 has it's own toolbar. Using mod toolbar should be an option, not requirement. Share full archive with VisualStudio project, if you can. I'm new to C# so having more than just .cs file would be lovely. I mean, having only one of these two should be enough, I'm pretty sure I can do the first if you'll give me the second... Hacking around using other projects as references. Probably I should be able to anyway, but it would take me longer than absolutely needed.

Lucky you. If you'll ever be in Warsaw, Poland, please drop by, I pay with my homebrew ale For now, Windows it is, I don't have enough time to fight loosing battle alone when all I want is some fun.

Sad thing is - I was using Ubuntu. Windows versions are much more stable for me - and I compared all 4 ( 2 OS x 2 word lengths). On Ubuntu, FAR was the only plugin I got working smooth and stable. Most of the others, not so. MechJeb had it's glitches I could live with, and others usually crashed my game. But I already "won" career mode with FAR + MechJeb only (well, it's science mode now, but I unlocked all tech, and visited most bodies). Now I want some more, and Linux versions are not up to the task. I understand the decision not to support Win x64. Hopefully Squad will make it better. Or other mods will start working properly on Linux at some point.

Could you please add a configuration option like "I know what I am doing, let me run it on x64 Windows"? I know it's not supported and I'm not going to ask for support, I just wanted to see how well it plays, and consider if it's worth it. Now, I probably will recompile on my own this evening, but config option would be simply more convenient, and I believe not so hard to do?

I removed Firespitter parts I didn't need (I only installed it for propellers anyway) and the errors are gone. Thanks, seems it was it.

Why yes, of course. All was downloaded when they were marked 0.90 compatible, pretty much all of them merely last week, and they are updated, to the best of my knowledge.

My GameData folder: ActiveTextureManagement BoulderCo Chatterer EnvironmentalVisualEnhancements FerramAerospaceResearch Firespitter KAS MechJeb2 ModuleManager.2.5.6.dll ModuleManager.ConfigCache ModuleManager.ConfigSHA NASAmission PartCatalog ProceduralFairings RealChute SCANsat SmartStage Squad StageRecovery Don't have any fast method to tell where exactly they came from, but afair the ones that are not self-explanatory are PartCatalog - seems to come with FireSpitter; BoulderCo - textures for city lights and clouds; EnvironmentalVisualEnhancements - well, city lights and clouds, basically. As I've already said: "And crashes all the same with and without ActiveTextureManagement, only without it percentage used is higher." I should say "seems" instead of "is", to be honest, but anyway.

Error occurred at 2015-01-05_230016. C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP.exe, run by Mołot. 68% memory in use. 0 MB physical memory [2224 MB free]. 0 MB paging file [787 MB free]. 0 MB user address space [394 MB free]. Read from location 00000000 caused an access violation. Full dump at http://molot.pl/KSP-modded-errors.zip How can I know which mod did it? 68% of memory in use does not seem like much. Two-thirds of what I have, sounds like nice safety margin. And crashes all the same with and without ActiveTextureManagement, only without it percentage used is higher. It happens at random points, not necessarily in graphic-heavy situations. I would suspect out of 32bit address space, but Read from location 00000000 looks more like pointer error than anything. Or is it?

Maybe I'm strange, but I was taught that I should expect every file I load can be broken - unless it's a file I provided with my software (and sometimes even then). Fonts are no exception, as far as I can see.

Weird. I didn't install it. Not manually, that's for sure. I just checked my downloads folder (it's still pretty fresh install, didn't purge it yet), and there is one font, FoglihtenNo07. I'm sure I installed it later, after experiencing this bug. And it's still available. So it came with something. That leaves us with: Windows, AMD drivers, ASUS drivers, AVG antivirus, Firefox, Steam, Baldur's Gate Enchanced Edition (both 1 and 2) and Oddworld series (all Steam games). Or maybe, just maybe, Libre Office? I'm pretty sure I installed it after experiencing this bug, but I might be wrong. That's all, I have nothing else on this machine at the moment. But I believe more important than identifying font source would be answering these two questions: Why can't game / engine enclose font loading in some kind of try ... catch block to at least provide human readable information before crash? Or, of course, to try and load another font... Why can't it be locked into using only fonts it supplies? As far as I see the font file, it wouldn't make any sense to try to use it in futuristic game. It's signed as: Title: Unical Version: 1.0 1998.02.13 Copyright: Generated by Fontographer 3.5© Peter Rempel Embedding: with limitations No other data on it. And indeed file seems broken, but at least font preview identifies it properly as broken and does not crash.

Thanks, that worked. Damn, any chance it is caused by AVG or FireFox? Because if not, I can't imagine what software provided that font. And isn't there a way to just, dunno, force KSP to use fonts it provided, only?

Did it. Did not help. From my log:C:\Windows\SYSTEM32\xinput1_3.dll:xinput1_3.dll (0AB70000), size: 90112 (result: 0), SymType: '-exported-', PDB: 'C:\Windows\SYSTEM32\xinput1_3.dll', fileVersion: 9.18.944.0 So it seems it is not the problem now? http://molot.pl/ksp-error.zip It's irritating because I meet Recommended System Specs, and it's a fresh install of everything, I had no time to break anything yet. And it is KSP bug because if game needs something that's not normally found on supported OS, it should provide it or request it - but it didn't.

I have fresh (3 days ago) install of Windows 8.1 x64, just installed AMD drivers (autodetect option), with fresh Steam and Kerbal updated today - 0.9 beta version. First run. It crashes right after creating a new game. I tried 3 ways, with the same effect: Run via Steam Manual run of 32bit KSP.exe Manual run of 64bit KSP_x64.exe Folders with error data here: http://molot.pl/sites/default/files/ksp_errors.zip My install can't be any more fresh than it is now, so what should I do to have game running? Verified files using Steam built-in tool and it says files are OK. I have 4GB of RAM so I shouldn't be running low, not without any mods.

Well I don't claim I know it all But, you know, these issues correspond very well with real life issues of this design, too! So as long as the game does not crash, I think it would be OK to leave them be. No payload? So ring should have no hole. Why anyone would want it? Not our problem. Cargo not round? So hole should be a smallest circle that can hold cargo. More wobbly instead of less? Well, one more Kerbal killed on duty. As long as it only happens for weird cargo, well, it happens. Issues with fairing ejection? Sure IRL there was some, too, it's only fair if they will happen in KSP if cargo will obstruct ring separation, just as they happen in life. I'm not arguing it will be easy in code. It might be hard to get it "good enough" in code, I don't know. If you say "hard", I believe. But if it will recreate real life problems in game arguably accurate, I'm all for it.

The way I would approach it, if I knew enough of Kerbal development: Add nodes to fairings, one at the point where cylinder turns to cone, other in half of the cylinder's height (again, that's pretty much from real life) Create a part that would take a shape of 1/n of a flat ring with a round hole at the center - going as close to payload as possible. If there are 8 fairing parts, the ring should be divided into 8 pieces, too. Made that part to work as a strut connected from fairing to payload, or automagically add "invisible struts" from that part to cargo (to prevent part from disappearing on decouple if it was treated totally as a strut) Well, I don't think I will be able to do this... Time to start learning, I'm afraid I can code, just have no idea about C# or Kerbal's API.

Hello. Thank you for your great add-on. Is there any chance for something like "Centaur Forward Load Reactor"? I know it sounds strange, but really it's just a ring that holds cargo inside fairings. Like inner struts, pretty much. It would make it way easier to prevent payload swinging, in a way that is used IRL - so no cheat. Source article about real life implementation here.

Hello again. Sorry to bother you, but is it worth it to put 2 different sensor arrays on one vessel? There are 110 pages in this thread, if you could edit first post to include quick reference for noobs who, like me, wasn't there when it started? Like what parts do what, what we can do, what we can't, what we can but shouldn't try? How science works with them? And so on? I don't expect full manual, of course, just a quick sketch of what to expect.

Well, I came here to ask about integration. It would be really neat to have one part to scan them all. Too bad it isn't like that just yet.

This should make a vessel explode, shouldn't it? But on the other hand, you can't make a collider that collides only with ships and not with planets