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?