stibbons

Hey @TriggerAu, I guess you missed it because it happened during the 1.3 crunch, but I opened a very small pull request fixing a bug in the last stage calcs for the ARP API wrapper. Doesn't affect actual plugin usage at all, but hopefully it's worth merging regardless.

Like @Freshmeat said. It's theoretically possible. But in practice if you can achieve it it won't be for very long.

In other words, absolutely nothing has changed. Take Two are still free to issue takedown notices to single player mods that infringe their IP. Which is exactly what they did in this case. That's really all that happened.

I just realised I never actually wrote the plugin code to send a message on scene changes. Um, sorry about that. I'll push out a new release that includes it very soon.

I've just uploaded plugin version 1.2.0, which adds channels for vessel rotation, translation, wheel commands and the main throttle. CKAN should have it in the next hour or two. The rotation, translation and wheel control channels will override things like SAS when non-zero commands are sent. Note that if you send, say, a rotation command, that command will remain in effect until the plugin receives another rotation command. The throttle channel is slightly different. If the plugin receives a throttle packet, from then on the throttle can only be controlled by the plugin. Pretty sure that suits my use case, but if it's a problem I'll look at expanding it so that the plugin can yield control somehow. I've also released version 1.1.0 of the Arduino library. To use these new channels, update your library to the latest version using the Arduino IDE library manager. As well as including structs and constants for the new channels, the new library adds a more useful `send()` function, that lets you send arbitrary payloads without having to convert them to byte arrays manually. Here's a really quick example of how you can tell the game to translate your vessel forwards at full speed: // Create a translationMessage object translationMessage myTranslation; // Set the Z axis to its highest value to translate forward myTranslation.Z = 32767; // The mask variable tells the plugin which parts of this // translationMessage are valid commands, and which ones // to ignore. This enables separate controllers to control // separate axes. Set to 7 to make valid for all axes. myTranslation.mask = 7; // Send our message to the game. mySimpit.send(TRANSLATION_MESSAGE, myTranslation);

A thousand times this. I can't read minds, and can't tell you what's wrong with code without seeing it. A full bug report contains: What you tried (hardware setup, code) What you expected What you got (error messages, unexpected behaviour) The Arduino playground has a great i2c_scanner sketch. Hook up your device, run that sketch, and it will output any found addresses on the i2c bus. Super handy for dealing with slightly mysterious devices.

If you do test it, you'll notice it works a little differently to the other groups. When the flight scene starts, the stage bit is 0. It remains 0 until the next stage is activated. Then it will return 1 until the next stage is activated, and so on. That's what the game is returning, and I thought it best to pass that on. In other news, I started on the vessel control stuff this evening. Hoping to get another release with rotation, translation, throttle and wheel control sorted out this weekend.

Hah, I didn't do anything special. And I don't keep my entire KSP folder in version control, mostly because Steam has literally never messed up my install and I really am serious about moving to a new version as soon as it's out and never looking back. But if you do check your full install in to git, @pjf talked about using git worktrees to maintain multiple separate installs if that's your bag.

One. Although if you want to get picky about it, using separate machines to play the game, do mod hacking and CI means I maintain three installs on three computers. I don't see any value I keeping old releases around, and keep my save files, GameData and CKAN metadata under git version control for backup and easy switching on the few occasions I want to vary my mod set.

Read the first post and the last couple of pages of the Scatterer thread: You will find out that a) Scatterer hasn't been updated for KSP 1.3 so yes it's going to have problems, and b) there are a couple of workarounds that you can change in the Scatterer settings that seem to resolve most of the reported problems. Apart from that, there's no fix but to wait for it to be updated.

If it's their opinion of how it's affecting the game when they write that review, then I'd agree with you. Negative reviews based on some hypothetical doomsday scenario, though, are completely invalid.

There is.

Version 1.1.1 should be available through CKAN soon. The only change in this version is fixing the data sent by the Action Group channel. Sorry, I haven't had time to get much work done on all of the fun stuff in the backlog.

Oh, dang. No idea where those numbers are coming from. Will bump debugging that to the top of my todo list. Apologies for being quiet the last couple of weeks, real life has been getting in the way. Nope. Those numbers are the literal bit mask, not an offset for the 1. Perhaps it makes more sense if you see them written as public static class ActionGroupBits { // This is the same order given in // https://kerbalspaceprogram.com/api/_base_action_8cs.html public static byte StageBit = 0b00000001; public static byte GearBit = 0b00000010; public static byte LightBit = 0b00000100; public static byte RCSBit = 0b00001000; public static byte SASBit = 0b00010000; public static byte BrakesBit = 0b00100000; public static byte AbortBit = 0b01000000; } The idea is that the sending end can OR together the appropriate constants to form a data packet containing the active action groups, and the receiving end can AND a constant with the data packet to find out if that action group is set. EDIT: But, of course, instead of the sending end ORing things together, it's trying to do bitshift shenanigans. I must have been really tired when I wrote that, sorry. Will have a fix out ASAP.

That was in reference to this thread, of which some also leaked in to the KSP Weekly thread and was modded out. Hopefully, with the extra context it's clear that she did mean the first option.

Right. So nothing's wrong with it? We're back to baseless fearmongering? Goodo.

You said it needs better oversight. Did you see the part where I asked you what's wrong with the current oversight? Would you like to go back and have another go at answering the question?

You're still avoiding the question. Why would you bring up store security at all here if by your own admission there's nothing wrong apart from baseless fearmongering?

So, what's wrong with the current oversight of the store security? Why is improving it a pipe dream? What about it needs improving? Why is defending what you say so hard?

What about the store security needs better oversight? And what's wrong with the oversight it already has? You're making grave allegations here, and I'm curious about what they're founded on.

What about the store is insecure?

Hehe, nice work. Apologies, I should have provided some more useful information, and probably helper functions, about how to get information out of the Action Status messages. I'll make sure that's properly documented in the next release. You're right, it's one byte. Each bit of the byte corresponds to one of the action groups. You can use bit math to check the status of an individual action group, by using a bitwise AND (the Arduino tutorial talks about using an AND to mask out individual bits - this is exactly what we're doing here). I'm at work, so haven't tested this code, but something like the following would be how you can check the status of the landing gear: void messageHandler(byte messageType, byte msg[], byte msgSize) { switch(messageType) { case ACTIONSTATUS_MESSAGE: byte actions = msg[0]; // actions now contains the action group message if (actions & GEAR_ACTION) { // The landing gear action group is active (gear is down) } break; } } Interesting! I don't think I'd heard of that mod yet. It looks useful, and a quick glance at the source for it shows it would be fairly easy to integrate. But it's starting to tie in to the next thing on my "too hard to think about right now" pile. It feels like something I'd like to make optional. But almost none of the framework for configuring individual channels is in place yet. I'll add it to the backlog as something to think about, but it'll be a few weeks before anything concrete happens with it, sorry.

It's marked as a pre-release on github - the CKAN indexer will only include full releases.

RPM v0.29.0 beta 2 is marked as a pre-release on github, so the CKAN indexer won't include it. Once a full release is out, the CKAN listing will automatically update.

Fallacies aren't the way to prove a point.