stibbons

I set `ksp_version_strict` to true in my netkan. Does setting compatible version in the CKAN client override that flag, or does it just influence what the client considers as "generally recognised" compatible (ie, only influence behaviour when ksp_version_strict is false)?

Not in Steam, at least. Deselecting the DLC in the Steam client removes the GameData/SquadExpansion folder entirely. Selecting it downloads the whole 400MB expansion package again.

@EricccMa Wait, are you using an RC transmitter to control KSP? That's really awesome. for(int i=0;i<4;i++) { RC[i]=map(RC1[i],1100,1900,-97,97); RC[i]=map(RC[i],-97,97,-31000,31000); } So the values you're reading from the controller are in the range 1100-1900, and you're mapping that to the full range of a signed 16 bit int. That's fine. RC[2]+=3000; RC[2]=RC[2]<0?0:RC[2]; RC[2]=map(RC[2],0,6000,0,1000); Are you sure you want to be discarding negative values of RC[2]? I don't know how your controller behaves, but I do know that the throttle on my Logitech USB joystick uses the full 16 bit range, so "throttle off" is actually -32767. Finally, I'm not sure of the impact of using the map function when the input is outside the specified range. But I think you're effectively dividing the throttle value by 6? That could end up lower than you'd expect. The plugin treats the throttle data the same as the pitch/roll/yaw data, with the exception that negative values are ignored. So send a 0 for throttle off, and 32768 for full throttle. I'm worried that second block altering RC[2] ends up setting it to a value that is too low to be useful. Maybe try writing the throttle value to your LCD before sending it as well to confirm it's giving decent data. Unfortunately my test hardware rig is still in a box somewhere after a recent move, so still getting my life back to the point where I can put decent time in to investigating this and doing serious development on the plugin. But it's getting there!

Love your work, thanks. Minor nit, the SVE_Textures link in the "To Install" section of OP still points to the 1.0.4 release.

Tiny things I like about 1.4.1 / Making History: I track my save folder in git, and 1.4.1 is the first release that didn't complain about the .git folder being an incompatible save. Yay! Tiny things I don't like about 1.4.1 / Making History: The ASCII art in the Making History readme is longer than 80 characters?! Literally unplayable.

With apologies for the long delay - KSP 1.4 dropped without warning the day before I went away for a short holiday, and I had to do a lot of work getting my build server functional again. But I've just uploaded version 1.2.3 of Kerbal Simpit, which has been built for KSP 1.4.0. The CKAN robot should pick it up shortly. Build server is working again, so I promise an update for 1.4.1 will be much faster.

You definitely do. See the large headline at the top of OP. Download the latest release, and just copy it over the old one. Refer to the https://github.com/KSP-CKAN/CKAN/wiki/User-guide for full installation docs.

Sorry, I've only just now saw this. Life has been busy, and I haven't had much time for working on side projects. But with the 1.4 drop I'll be doing a little work getting this updated. Will look closer at your problem soon. Would you wind sharing a little of the code you're using?

There hasn't yet been any official announcements. Enhanced Edition is based on KSP 1.2.2, while Making History will require the KSP 1.4 version that was released for PC today. If I had to bet on it I'd say, yes, the DLC will be ported to console, but not for a little while - there'll probably be another patch release for the current EE, then work will start updating it for 1.4, and that update plus DLC will appear around the same time. Probably? There is one. Apparently you can access it by

Win what? What are you hoping to achieve with a negative review? What rights are you losing with the new EULA that you had before?

The EULA doesn't apply to the forums.

"incorporated in" could indeed apply to mods, sure. This is not relevant, though. So that means there's no given stance on mods. OK cool.

You're not quoting the whole clause. From http://www.take2games.com/eula/ That applies to content created in-game, such as videos and missions made using the Making History mission builder. I fail to see how it applies to code written outside of The Software. Where in the current EULA does it state that?

Per which part of the original agreement, precisely?

1.4 is a prerequisite for Making History, so we can expect it either same day or slightly before. Don't think there's been a huge announcement about the 1.4 release date, but it's been confirmed:

Ninja'd. That said, I personally like the original layout just fine. For those who wrongly think they have OCD, sure, align the name and class. But it's a minor thing.

Disagree. Left-aligned means it's always in the same place. Right aligned means more work for the user trying to find the button. Argue for aesthetics all you like, but making it harder for the user to click a button is not great UX.

A four year necro is impressive work.

Sure. Key word to search for is a momentary toggle switch, centre return. But if you're planning on using it as forwards/reverse, don't you want a DPDT? Something like https://www.amazon.com/Heavy-Handle-Momentary-Toggle-Switch/dp/B000LFVFA8

I missed the space, but the thought of what would happen if $d ended up being parsed to a blank space gave me chills.

There's a few options: A USB keyboard. You can go a long way by gutting a cheap keyboard and connecting your own switches and thing to the key pads. A Leonardo class Arduino compatible. Either get a Leonardo board, or one of the clones like a Pro Micro from SparkFun. This is the bare minimum; these boards can easily emulate a USB HID device. Arduino Uno and Mega can not without some hard work. Teensy. Much more powerful controllers - more inputs, faster clock speed. The most recent even have an FPU, they're great for doing complex floating point math with telemetry from the game. They're popular with the DIY mechanical keyboard crowd. Not as much as you might think. My controller uses KSPSerialIO with an 80ms refresh, equivalent to 12.5fps. I've never noticed any latency between hitting an actuator and the game recognising it.

There's a very large disconnect between acknowledging the existence of something, and describing in detail how to use it. If you disagree, talk to a lot of people. Maybe you could start with the folk who originally implemented the code used for the console KSP cheat menu. They were proving you wrong in the cheat code for Gradius in 1985. Spoiler.

Because of this: The development team have explicitly said that they want players to figure it out. It seems only reasonable to hide it from casual spoilerage. EDIT: I'm happy to admit that the clues in there may be hard work, especially for gamer generations newer than mine. But surely we can do better than just spelling it out. Can't we at least drop some more hints for them to google?

Yes. Definitely. But the ones on unproven craft have more need to know how to properly use parachutes, yes? So the lower level crew members should definitely be more capable of using parachutes, while it makes sense that more advanced specialists need chutes less, so they'd be less capable of steering or even activating them.

Spoiler tags please?