Cydonian Monk

The only way I was able to get non-KSO-proprietary parts to like those attachment nodes was to clip the VAB camera inside the Cargo Bay from behind. That way there was nothing in front of the camera and whatever I was attaching "snapped" in just right.

I'm not. Anything I build will be 64-bit. (Assuming I can get past the "duplicate entries on x86_64" compiler nonsense I was running into last night..... I've got an unfriendly header somewhere.)

I've been exploring a few alternatives. Namely this: http://sourceforge.net/projects/amserial/ ... which in a round-about way led me to this: https://github.com/playwithmyled/Internet-to-Serial-Proxy/wiki I'm able to build and use both, FWIW, I'm just trying to figure out if it's possible to integrate AMSerial with the C# script in Unity.... I know IP traffic from a KSP plugin is possible, so using that proxy app might be a work-around, though it's not terribly elegant. Think I might look at what plugins such as Telemachus are doing tomorrow night if I get the time. (And building a new app specifically for KSP that's a bit cleaner than what's at the second link wouldn't be difficult.) This would also solve the port discovery problem. I'm also wondering if it's possible to access Python methods from our C# scripts, as it would seem trivial to use this instead (and be platform agnostic, which is the best solution): http://pyserial.sourceforge.net - Not much of use turns up on my searches except some discussion from 2011.... And I'm not sure if something like IronPython is an option here? Outside of that, the default build environment for C/C++/GNU stuff on OS-X 10.9 is non-existent, and it makes things a PITA to set up. (Gentoo back in 2003 was easier to bootstrap.....) The weird thing is I had the entire toolchain set up 2 OS versions ago... it's just all disappeared. Don't recall if I did a full install/restore (maybe), or if the 10.9 install zapped it. Regardless, that's an obstacle I can get past with a large hammer and some time, or I can just relent and use llvm in X-Code (maybe).

Excellent. Thanks Faark! I hope so too. If I don't get to it tonight it'll be sometime next week, as this weekend is rather booked. Not sure how much work it'll take yet, probably not much. Just a question of finding time.... I wouldn't be offended if someone else gets it done first.

Now that I'm awake and semi-coherent (ie: it's not 3AM), I would agree this does not look terribly promising. There might be an unconventional solution to this however, and I'm not yet out of ideas. Still, this is digging into a layer of C# that I have no experience with... I'm a Linux dev by trade and mostly work with C/etc... so it's at least been educational. The description seems to imply that it should be, and there are several discussions among Linux forums about using that same library, so I'm partially assuming it is. I'm not convinced, though, and all the read/write routines seemed to use entry points in core.dll or kernel32.dll, which is a no-go for us. (The kernel32 usage in Port.cs is avoidable, as it is only allocating/freeing a buffer we don't need.) I'll verify tonight if I get the chance. (Edit: It's clear to me now the "multiple OSes" they discuss are Windows and Windows CE. It does appear to be written in such a way that /other/ support could be bolted on, but that would also require some other deep changes, such as environment detection.) No, but it made for a decent example of SerialPort usage in a non-Windows environment. (Plus that page links to the same lib we're talking about, even though they're using System.IO.Ports.) Thanks, I overlooked that. I'll take a look at it.

That's the only way that will work. Under POSIX environments the "named port" is the file descriptor itself. The SerialPort library seems to recognize this, but is being fooled into thinking it's running in a Windows environment by something.... Every bit of reading I've done on that library indicates that the SerialPort lib is POSIX compliant. Including this example: http://www.mono-project.com/HowToSystemIOPorts (Edit: This was also a misinterpretation on my part) I've not sat down and taken a through look at it, which I will do sometime this week when I find the time. Tonight if possible. (I may have been overthinking this anyway.)

Worked as in "got past the registry check in KSPSerialIO and didn't throw an exception prior to Port.Open()", not as in "Successfully talked to something."

Yes. None pleasant. I've a good suspicion that's an issue with the SerialPort lib, and have a couple ideas (one of them being a DllImport in Port.cs that I just fixed). Nothing I'll be able to take a good stab at until tomorrow evening, though. (Another being that kernel32 / WinAPI functions just don't exist outside of Windows, despite oft-repeated rumours on various sites that they might. Cross-platform C# is not something I deal with much at all, and reimplementing that SerialPort library could be treading a _bit_ too close to what I do for a living... and thus might cause "issues". What's weird are how some bits of this work while others don't, I suspect because it's trying to use Windows-specific memory routines....) Edit: To be a bit more precise, with the default build SerialPort is throwing an exception when trying to use LocalAlloc, as that's a Windows memory thing and part of kernel32, which it didn't load (for a couple reasons). Getting beyond that (by fixing the DllImport and then either having a kernel32.dll it can load, or by forcing the lib to realize it's not on Windows), gets it to a point where it "works", but it fails when trying to write to the port it just opened. That's where I was yesterday, though at the time I was assuming it couldn't write to the things I had connected because they were busy or not writeable. Unfortunately it does the same when talking to a dummy listener (as I tested tonight), so I'll need to dig at it a bit. Might also help if I actually have the Arduino stuff connected, but it's not yet making it to the point where the handshaking occurs. (Edit: clearly anything that uses kernel32.dll (for Windows) or core.dll (for Windows CE) will never work on OS-X, despite my optimism for a magical solution....)

Ok, this is a pretty quick and dirty hack here, and since I haven't really changed anything aside from performing surgical removal of some of zitronen's code (and filling in with stubs) I haven't bothered to do a real fork on GitHub. The source code and the updated solution is included in the zip file, and the license remains the same as zitronen's original, which I was unable to find. (I'm implying rights to fork the code and redistribute from these two posts: http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2808-Feb%29?p=944424&viewfull=1#post944424 and http://forum.kerbalspaceprogram.com/threads/68642-Arduino-Addon-for-Mac?p=955379&viewfull=1#post955379 If that's in error I'll freely remove the link and the file.) Download is here: (Edit: Removed, since it doesn't even remotely work.) Give that a whirl and let me know if anything happens, good bad or otherwise. As usual, copy everything in the GameData folder from the zip file to your KSP GameData folder. Try to do it in a "fresh" install of KSP if you can, so that any logs or crash reports are "untainted" by other mods. To change the serial port you'll need to open config.xml in the GameData/KSPSerialIOosx/PluginData/KSPSerialIO/ folder and change the DefaultPort node's value to the tty/cu that you want to use. I'm not sold on calling it a working port library just yet, at least not for OS-X. It /does/ at least act like it's connecting to things (edit: this was a misinterpretation on my part), and seems to know when the port it's attempting to connect to doesn't exist (Edit: that much is true at least.... just don't expect a read to work....). If it doesn't work, though, it's something that's at the layer below KSPSerialIO and would likely need changes to the SerialPort lib (which may or may not be beyond what I'm allowed to get involved with, for various reasons, but would require further evaluation based on whatever issues crop up). Kind of why I wanted to test it fully before uploading it, but....

I'll be home in an hour or two. Taking a quick look at zitronen's config file change it shouldn't be much to remove the registry parts of the code and recompile. When that's done I'll upload a version (with the updated code and project and whatnot included) to DropBox and post a link.

That is probably the better solution for now. There really doesn't appear to be anything that needs changed from the respect of your plugin (though I wasn't able to find my Arduino toolbox to test it before I had to leave for the day).

I'm not really in favour of a "death ribbon" either, but could you at least give the recently deceased a "mission completed" or "mission ended" event and increase their mission count? I know your wording is currently "successful missions," but it somehow feels wrong to not give credit to the dead for a mission where the craft exploded on the launchpad due to a staging error.... Just a thought. Trying out the new version now.

I'm wondering if we'll even need to use the callout devices. I suppose it might be better to use them, though if anyone has a tty connection open to the Arduino they should expect it to block anyway.

Small update, since I've found some time to look at this today. So far I haven't needed to change much (inside of KSPSerialIO). Obviously the registry hack zitronen was using won't work on OS-X, so that needs changed. The SerialPort library built without issues in MonoDevelop on OS-X, and the assembly is already included with KSPSerialIO so I'll just use that. From a project standpoint, KSPSerialIO had to be "updated" to target .NET 3.5, as .NET 4.5 doesn't exist in any format I can use in Mono. There is also an undefined reference to the Microsoft.CSharp assembly that I can't resolve, but as far as I can tell that isn't even needed, and the project build perfectly fine without it. The trick then is getting a list of Serial Ports from OS-X. Serial/tty ports are exposed under /dev/tty* (or equivalent callouts, as discussed below). A connected device on my OS-X system follows the general "readable" format of /dev/tty.[DEVICENAME] and /dev/tty.[DEVICENAME]-[NNNNyyyy] (where NNNN counts up from a zero and yyyy is the year) in addition to its true hardware location of, say, /dev/ttys000. Having that date/iterator string attached to the end of the device path is going to be mildly problematic, and as I've discovered with my USB-RS232 dongle in JMRI it can change every time the device is plugged in to a different USB port. What I'm looking at now is a discovery system for those connections. (As expected, System.IO.Ports is either hard-coded to be off-limits or just flat-out doesn't work. (And may not be in Unity at all?)) This should be simple enough, but we really need some way to select the one we want from inside of KSP. A quick work-around is declaring the device path in a config file and loading that at launch, which is sort of the same as the registry hack used currently by KSPSerialIO.... If I can get SerialPort discovery working though, a selection menu is the most ideal solution. At the very least hard coding the serial port seems to "work"*, though naturally my trackball didn't know what was up when I tried to connect to it. Off to find my Arduino stuff..... (* Edit: As mentioned below, "work" as in "gets past trying to read the registry", not as in "successfully talks to anything.")

You might occasionally run into a mod that doesn't work on Linux (typically because of case-sensitive file names and paths, using \ as a path delimiter instead of /, etc), but otherwise things are ok. I've honestly had more issues with KSP on OS-X than Linux, due mostly to Unity weirdness and my integrated graphics. (Well, except for some hardware issues that screw up joystick support, but I have "weird" hardware.)

Possibly. I know System.IO is (or was) off-limits, but modding Unity itself? Might be worth bringing up in the Soundtrack Editor thread if so. (That's the only place I've seen it done lately.) I don't expect that'll be needed here, but without sitting down to look at it I can't say for sure. Apple's SerialPort support is... different at best and broken at worst. I remember having issues with JMRI when I first jumped from Linux to OS-X that required minor code changes. (Appologies if this is a duplicate post. My phone network just derp'd.)

There's some discussion on the Unity forums about Serial Port support being broken on Unity for Mac. There's also the issue that dlls can't be copied into the KSP.app Application Bundle and work the same way as is done on Windows, where you can place dlls in KSP_data with no issue. (See discussion on the "KSP Soundtrack Editor" thread regarding the mp3 dll.) There are, however, work arounds that can be explored, as long as we don't need to rebuild the App Bundle. (Edit: none of that should be necessary anyway.) Thanks for the link. Unless someone else beats me to it and gets it working I'll look at it this weekend. I'll need to find my Arduino stuff, too, which might be tricky as it's been in hiding since I moved.

Hmm..... I'll take a look at this sometime over the weekend. After a quick glance it looks like it might be possible, and will just need updated to use OS-X serial ports instead of whatever is inside that serialport.dll blob. I've got all the other bits I'd need to test, and I /think/ the Arduino stuff is still installed on my MacBook.... No promises though, ok?

Valid point. Though after a quick test using the flag decals the ladder poking through didn't look /too/ terribly bad, but did look odd. I just find it horribly inefficient to copy 17MBs of on-disk textures should I want to have multiple, named, versions of the KSO. But I see your point.

OK. It's your mod, afterall. I'll just go make my own nameplate.

I'll third the Logitech Extreme 3D Pro. It's somewhere around $35-$40, and hits every category you mentioned. Seems durable, too.

It's an idea that's been floating around for awhile. In the past I tried to make a small flat model to use as such on other craft, but that wouldn't work here since the KSO is curved. Since helldiver has the geometry/model for the KSO, he could "cut out" the part of the craft where the name is and have that added as a part. Now getting it to line up right is a different issue... the base texture might need a "spotting" target so you know where to stick it. Just an idea. (That I think has been mentioned before in this or the dev thread....)

Or, you could make the nameplate itself a separate part, so that instead of changing the texture of the entire cockpit you only have to change the texture on nameplate.....

Sorry, Nazari, helldiver... those boosters being liquid really bugged me. So I "fixed" them, at least for my use. I scaled their thrust and fuel so I have just enough to reach my Station Orbit (130km), making ascent profile a bit more important. Might just work this thing into my main save yet. Here's my STS-3 test launch at Mach 1, around 9 or 10km above KSC.

Indeed. I've used it with the default DRE settings with no issues. (Aside from RealChutes drag chutes burning off... that's a different issue.) If you're using more aggressive DRE settings, try a rolling reentry where you roll left a few degrees then right a few degrees, repeat.... That spreads the heat around to different parts. (I've had to do this with stock spaceplanes, too, FWIW.)