nlight

This was a mistake by one of ours bots, all should be fixed now. - - - Updated - - - Version 1.5.1 is officially out with many fixes! Thanks to everyone who spent time off your vacations to work on this!

If you are having download timeout issues try this beta CKAN 1.5.1 build.

Hey, sorry if it seemed like the other issue didn't get noticed. I submitted this as an issue 4 hours ago and we're already working on the problem

Hey, sorry I misspelled the cmdline syntax, the repo option should go *after* update, should be fixed now.

Everyone that is encountering HTTP 403/ 402 issues yesterday and today, this is due to a KerbalStuff outage. In order to reliably use CKAN during these periods I urge you to switch to one of our official (99.9% uptime) mirrors: http://amsterdam.ksp-ckan.org/master.zip http://nurnberg.ksp-ckan.org/master.zip Here is how to setup your CKAN install to use a mirror: 1) Command- line users Use the --repo option when updating then use CKAN as usual ckan update --repo="http://amsterdam.ksp-ckan.org/master.zip" 2) GUI users Copy/ paste the repo URL into the CKAN Repository box under CKAN Settings and click 'Apply' as shown on the image below:

Use a mirror like http://amsterdam.ksp-ckan.org/master.zip

For some reason the DX11 backend causes extreme slowdowns on some configurations. I am looking into this, please use 1.4.4 until then.

Version 1.4.5 is up with DirectX11 support, hopefully this will solve all Windows 8 and missing controller related issues. Also dropping support for Windows XP with this release.

I have verified that Windows 8 and SDL don't want to play together so that's why you're not seeing your controllers. DirectX11 backend is in the works so stay tuned.

Thanks for the info, any chance you're running windows 8?

As stupid_chris said, 0.90 made a lot of changes in the background that are not obvious, so it will take some time for modders to catch up. That being said - CKAN makes the process much easier.

Version 1.4.4 is up, thanks to Gowor's amazing feedback I think the EVA bug should be gone for good now, also I fixed the time-warp issues reported a few posts back Could you follow the steps on reporting bugs in the main post so I can investigate?

Version 1.4.3 is up which should fix the throttle bug and some other bugs, hopefully it also solves the EVA issues which I've been unable to reproduce. I'm still looking into the other issues, thanks for the patience, guys

Guys, just want to let you know I am away until tomorrow, I will look into all the issues when I get back, promise!

Hey, thanks for catching this, I guess they removed the code that checks whether you're time- warping so this doesn't bug out. Should be a simple fix. Hey, this seems like a borked AFBW installation. Here are the steps to fix it: 1. (only if you're using CKAN) Uninstall AFBW through CKAN 2. (only if you've installed manually) From KSP's root folder - delete SDL2.dll, XInputInterface.dll, from GameData delete the ksp-advanced-flybywire folder 3. Reinstall AFBW either through CKAN or manually 4. Verify! SDL2.dll and XInputInterface.dll should be in KSP's root folder (next to KSP.exe). The GameData/ksp-advanced-flybywire folder should contain these files: ksp-advanced-flybywire.dll, XInputDotNetPure.dll, toolbar_btn.png 5. Test in KSP and report back

This is most likely a regression in our EVA code, it's all reverse engineered from KSP's code because Squad didn't give us any way to do it properly. I will inform ddaf who wrote this part and I hope we'll fix it for the next build. Thanks for the feedback! This is probably something really simple (like SDL or XInput DLLs missing from KSP's root folder). If you give me your output_log.txt I can definitely pinpoint the issue. The first issue is easily solvable and will most likely appear in one of the next versions, the second will require quite a bit of changes to AFBW's code, but I really want this to happen sooner or later so I guess expect it as well.

Hey, I didn't know about this issue. This is most likely easily fixable, so I'll look into it soon, thanks for the report!

Version 1.2 is up. Now instead of the GUI you can use a simple config file (in GameData/NoMoreGrind/config.txt) that allows the price multiplier to be set by facility type and also allows you to share the configs with each other. Here's how the default config looks like: VehicleAssemblyBuilding = 0.1 TrackingStation = 0.1 SpaceplaneHangar = 0.1 Runway = 0.1 ResearchAndDevelopment = 0.1 MissionControl = 0.1 LaunchPad = 0.1 AstronautComplex = 0.1 Administration = 0.1

So version 1.4.2 is out. Changes: - Hopefully fully adapted to the 0.90 changes - SAS should work fine in all cases now - Negative versions of Yaw, Pitch, Roll, X, Y, Z are back

Hey, I think I can just allow duplicate axis bindings (so you can add Yaw twice, one will be inverted) and this will work again for you I will do this tonight when I get home and release a new version hopefully fixing the latest SAS bug also.

Hey, the Negative versions of axes got removed because now each binding can be inverted by itself (the new Invert checkbox in the preset editor). Does your setup require something more complex that the negative axis bindings solved? Like binding the same action e.g. Yaw to two different joystick axes? I wasn't aware of any such setups but I have a solution in mind if you need this. Hey, this is just another regression caused by the 0.90 changes that I didn't want to rush a fix for (because I'm not sure what else will break). The next version will solve this in one way or another. Thank you so much for the feedback, I will deliver on this asap! Hey, I'm afraid the issue isn't the Saitek drivers, AFBW works just fine with them. It seems that AFBW just doesn't detect some controllers on Windows 8.1. This is probably a bug in SDL (the library I use to get inputs). I will look into this again and see if I can fix it without major changes. If all else fails, I'll implement the new DirectInput API that comes with Windows 8.1 which should solve this issue. Thank you for your patience

I have tested this pretty extensively and it does not seem to be the case, changing the sliders works exactly as advertised - all facility upgrades are ten times cheaper than they would have been without the mod. Could you please check again and maybe give me an output_log.txt?

Andersenman, I'm not sure if this was a comment on the mod description, but anyway I've modified the wording of the main post to make it more clear.

Yes, sorry! This is a very nasty bug that I hadn't forseen due to the 0.90 changes, version 1.4.1 is out now that fixes it. Thank you for the feedback.

I am very happy that I'm seeing this thread! I have put some work into making this happen but sadly it's not at all trivial. The first issue I encountered was that you cannot just pass shader code to Material, you have to go through the Unity compiler first, open up the compiled shader and copy its source. This is semi- OK, it makes things a bit inflexible but we can work with it. The other issues are worse though - first KSP renders with 3 cameras instead of one and blends the results onto each other. This makes many usually trivial post-processing effects like SSAO, DoF and many others to now become very tricky to implement. This is mostly due to the three cameras having different far/ near planes and therefore their depth buffer ranges are very different, I cannot see how this can be worked around without major loss of precision somewhere, maybe somebody can prove me wrong. I see replacing part shaders as being doable in two ways - either walk the scene and forcibly replace all Renderer.material's or use Unity's render with replacement shaders functionality. Both of the approaches have different drawbacks, but I have mostly explored rendering with replaced shaders so I can tweak the cameras to get proper depth buffers. Another thing I've tried is forcing deferred rendering on all the cameras, but many fixes need to be made for this to work also. I hope somebody can figure out how to get a normal and depth buffer with good precision that contains the whole scene, this will at least open up the possibility of a nice post-processing framework. As to replacing part shaders, this will also be fun to do, the only success I've had is to write shaders that have completely identical inputs/ outputs to KSP's stock shaders (which I've had to decompile for this). Also it seems that for some reason most of the part shaders are marked as Transparent and this brings a whole another bunch of problems. Sorry if this seems somewhat incoherent, I've worked on this some time ago and some details slip my mind, this is pretty much what I can remember. Here is my GitHub repo that I've now made public which contains a semi- working implementation of depth of field + some material replacement by walking the scene. The DoF implementation has its own huge issues but the shader loading stuff is there. Sadly I've seem to have lost the shader sources themselves, but the dof shader was from the default unity pack so it should be pretty easy to setup.