Jason Melancon

Alright, in case anyone following this is interested, I finally got the on-screen axis mode notice working, using the KSP API:

I've been using a script I wrote in 2019 to swap the x and z axes of my Thrustmaster joystick on demand. This makes piloting rockets much nicer. However, there normally isn't any on-screen indication of which mode the joystick is in. This fixes that. [Link redacted by a moderator] The TARGET script does the swapping, and the plugin displays the current mode any time you perform the swap, and any time you resume control of a vessel. In airplane mode, the axes are what you'd expect in any ordinary flight simulator. In rocket mode, joystick x axis controls yaw instead of roll, and joystick z controls roll instead of yaw. I find this much more intuitive, for reasons I've detailed in the link above. And now that the plugin tells me which mode I'm in, I won't crash nearly as much because I forgot to switch the mode! I use the T.16000M because I have two of them and I use one left-handed for translation while docking. If you have a Thrustmaster joystick that isn't a T.16000M, you'll need to tweak the script to permit it to work with your particular joystick model. But this shouldn't be difficult. This makes use of the TARGET fix I've posted about before at Many, many thanks to Ivan Wellesz on https://forum.dcs.world, and to users Vebyast and Gotmachine!

Does it work if you delete "override" from the method definitions? That modifier is absent in the "Getting Started" thread examples (https://forum.kerbalspaceprogram.com/index.php?/topic/153765-getting-started-the-basics-of-writing-a-plug-in/).

(These last two have been answered in the main forum: https://forum.kerbalspaceprogram.com/index.php?/topic/209264-postscreenmessage-crashes-when-called-in-net-event-handler/)

Outstanding! Using a flag and checking it in Update() works perfectly. I was hoping to use a callback sort of solution, but this is working well and teaching me more about threads in the process. Thanks again — this is the second time your answer has given me just the right nudge.

I haven't looked at the SDK, but I don't think the game should be loading the Discord Game SDK. I think the only reason to put a .dll into the GameData folder is if the game itself is going to load it as a KSP plugin. You probably only want it to be available to call from your KSP plugin, right? So try leaving it where it's installed, note the path to it, and use it in situ in your plugin.

Would anyone have any idea why ScreenMessages.PostScreenMessage() works fine in the handler for OnFlightReady, but crashes in the handler for FileSystemWatcher.Changed? That event handler works fine too, other than the PostScreenMessage() call. It's only the combination of the two that crashes. from error.log: from my code:

Actually, now that I log a string in the OnFlightReady handler and comment out the method call, the game crashes on the first execution of PostScreenMessage() in that same method, rather than the second execution, when called by the FileSystemWatcher.Changed handler. And I stress that it's not merely PostScreenMessage() that doesn't work, because it works fine when the method it's in is called by the OnFlightReady handler. It's also not the FileSystemWatcher.Changed handler by itself, since it works fine when all it does is log the message rather than putting it on the screen. It's the combination of FileSystemWatcher.Changed and PostScreenMessage(). And the crash happens even when the message displayed is identical for both handlers, and when I print a dummy string to the screen. This makes no sense to me. I had been registering the two listeners in different places, with OnFlightReady in Start() and FileSystemWatcher.Changed in Awake(). I changed it so that both get registered in Start(), which is executed much later in the life cycle. I also put a call to PostScreenMessage() directly in each handler, so they no longer call it indirectly. This produces no change. Both handlers log that execution begins. The only difference is that an on-screen message displays just fine when done in OnFlightReady's handler, and the game crashes when the same is done in the other handler.

I'm having a crash in my plugin where two different event handlers — one for OnFlightReady, and one for .Net's FileSystemWatcher.Changed — call the same method, inside which is a call to ScreenMessages.PostScreenMessage(). The first one that fires is OnFlightReady, and that works fine. But the moment the second call comes as a result of the other handler, the game crashes, and I can't understand why. It's got to be the PostScreenMessage call, because if I take that call out of the method in which it appears, and just log a string instead, that works fine, multiple times, no matter which event handler it's called by. Why would two calls to PostScreenMessage crash the game?

Loaded scene! That's what I didn't search on. Thanks! I was sure there had to be something like that, and that's exactly what I was looking for.

How do you programmatically find the type of scene that's currently active using plugin code? I'm aware of UnityEngine.SceneManagement.SceneManager.GetActiveScene().name and, in Flight scenes, it returns "pFlight4", which of course has "flight" as a substring. Is that the best we can expect? I was hoping to get back something like the enum KSPAddon.Startup, which is part of the class attribute for defining the type of scene in which the addon becomes active. I'm just starting with this, so I'm probably missing something simple.

You're welcome! Nice job! I love swapping roll and yaw using TARGET too. Nothing like moving the stick as though moving the rocket itself, although I can't tell you how many craft I've crashed because I forgot to set the right roll/yaw axis mode for the craft before launch. I lost count a long time ago. I even have a note near the top of my launch checklist (right after checking that stick inputs are working at all after starting the game), and I still manage to screw it up sometimes. I kind of wish TARGET had a way of throwing up an Alert() box, or a hook into a KSP API to display a message about that mode. Okay, that got me thinking, and now that I actually look, I see in fact there's a substantial KSP API. Hmmmm...

Strange that I never noticed a problem using the throttle to cut the engines, though I have been using the part window to deactivate an engine when necessary. I'll have to see whether I notice a difference in behavior now.

I'm sorry I'm just seeing this now! If you post your target.tmh, or send it to me some other way, I can take a look. The relevant code may have moved to some other file, so you may want to post/send multiple files. They may even have made TARGET compatible with Unity out of the box by now; I don't know. (One would hope, right?

I had a similar issue, and like you, I checked here for a solution before working one out myself. I came up with a way of getting TARGET to work with joystick axes in KSP. You can find the article from my forum profile. I hope it can still be useful to you!

This isn't a question, but I feel like it still belongs in Tech Support.

I came here to find an answer to my problem, and I found some clues, but no resolution. With some experimentation, I was able to figure out how to get the TARGET software working with KSP. I have two Thrustmaster T.16000M sticks which weren't being recognized by the game properly when used together. But it turns out that the TARGET software can fool the game into seeing the two sticks as one virtual stick, since the virtual stick driver has exactly twice as many axes and twice as many buttons available as does a single T.16000M. However, the axes didn't work when running TARGET. With the joystick centered, the in-game axes would start at the extreme low end of their range. When the stick was pushed to the up or right, the in-game axis could be moved past the center position to the extreme high end of its range. When the stick was moved left or down, the in-game axis would instantly snap from the low extreme to the high extreme and stay there until the stick was centered again. I read more about TARGET and KSP on the web and came across information that KSP is based on the Unity engine, and the Unity engine does not accept negative input from joystick drivers. It expects all input to be positive. This fit with what I had experienced above. The solution was to map the axis position that TARGET would normally output to the virtual driver to the axis position that Unity expects. This means forcing the normal output, which normally ranges between -32768 and 32767 (a signed, 2-byte integer) to be only between 0 and 32767. That can be done by dividing the TARGET default output by 2 and then adding a quarter of the range, resulting in the Unity's expected output. Fortunately, the TARGET scripting is powerful enough to handle this. The upshot is that to make TARGET work, you have to use the TARGET Script Editor as normal, with a couple of small modifications. First, make two small modifications to the target.tmh "header" file (WITHOUT saving it): 1. Somewhere in target.tmh, preferably after the "include" lines and before anything else, put the following block of code: // Conversion from TARGET axis value output to Unity axis value virtual output // (TARGET only allows outputting signed virtual axis values, while // the Unity engine apparently only accepts positive axis values; therefore, // compress the range and put it entirely in the positives, // resulting in the resolution being cut in half) short UnityAxis (short TARGETAxis) { return TARGETAxis/2 + 0x4000; } 2. On line 620 of target.tmh, change the line if(index < MOUSE_X_AXIS) DX(index-1+OUT_ID_AXIS, value); to if(index < MOUSE_X_AXIS) DX(index-1+OUT_ID_AXIS, UnityAxis(value)); And finally, 3. Save the modified target.tmh as some other filename, preferably in some other directory. Then, at the top of your .tmc script, which will include "int main()", make sure to change the filename in quotes after "include" to the new version of the header file you just changed and saved. (You might need to go to OPTIONS and the FILE PATHS tab and add an entry for the location where you saved it.) You can verify that it's working as intended by using the script editor's DEVICE ANALYZER, and see that the "Thrustmaster Combined" joystick axes (after moving them around a little to calibrate) start with the stick centered at 16384 in the middle of the positive portion, and you can move it left all the way to the middle, near 0, and right all the way to the right end.