Steven Mading

  • Content Count

  • Joined

  • Last visited

Community Reputation

837 Excellent


About Steven Mading

  • Rank
    Capsule Communicator

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The kOS DLL that was compiled for 1.8.1 also works fine with 1.9.1. SQUAD didn't make any changes that affected kOS between those version. The Telnet warnings are actually while trying to read the config file for kOS, and the config options related to telnet aren't being loaded right. Even if you don't use telnet, a failure to read one part of the config file correctly can still possibly break other config options that were meant to be loaded afterward. I suggest you remove kOS entirely and re-install it. This will lose your config options and you'll have to set them again, but should (I hope) get rid of that message.
  2. I am considering removing the input lock code of kOS and replacing it with just using this mod, because the current kOS code doesn't always prevent other mods from seeing keypress events first before kOS gets them. It does for most mods but there's always one or two edge cases that bleed through. But one phrase in the description gives me pause, and it's this: This describes how it handles mouse clicks, but how does it handle a mod trying to capture an EventType.KeyDown in its OnGui()? Does it use the mouse pointer's current position at the moment the key is pressed (like X-Windows' focus-follows-mouse mode)? Or does it use where the mouse pointer *used to be* the last time there was a mouseclick, even if the pointer's not there anymore now (Like click-to-focus mode)? kOS's terminal window currently behaves in a click-to-focus mode.
  3. That would be true in the imaginary version of this game where the only place such contracts exist is on low gravity moons. But in the actual game, Eve exists.
  4. Well, EVA kerbals don't have pressure sensors, or thermometers, etc. So those contracts already were good for rovers even without this problem. For me it got worse in 1.9. I am wondering about whether or not the changelog note about altering the kerbals' colliders for ladder reasons might have increased the incidence of the issue.
  5. No. Just kOS and HyperEdit (for kOS testing).
  6. In KSP 1.9 I am having trouble finishing one of those "take EVA report on surface of Kerbin at Alpha, Beta, Gamma site" contracts because I can't run a kerbal without them sinking through Kerbin's ground terrain and exploding in a puff of smoke because of it. To keep them from dying I have to stop every 2 or 3 meters and let go of the controls when I see their feet starting to sink below the surface to make the kerbal rise back up to the surface properly. If the Kerbal sinks more than halfway down into the surface, they blow up. Has anyone else been getting this?
  7. I just downloaded KSP 1.9 and ran into this issue right away. When two manuever nodes are in your future flight plan, the second one can't be edited by pulling on the GUI knobs for it. That used to work just fine. Am I the only one having this problem?
  8. I like it. It's hard to do chords in the SKID chip since each 'voice' is only able to do monophonic notes. To get a chord you have to make multiple voices have their notes 'align' in time. I'm impressed you pulled it off.
  9. LaserDist v1.3.0 out, for KSP 1.8.1. No changes to Laserdist except API usage with KSP 1.8. KSP 1.8 deprecated some API calls, replacing them with alternate versions. In particular, the shader used with LineRenderer to draw the laser lines needed to be built with a new kind of constructor. I had some issues in the last couple months that kept me away from Kerbal modding for a while, but I'm getting back into it now. That's why this was so late in getting an update. It was still working for KSP 1.8 except the visual laser lines (if you have the "Visual" button enabled on the PAW) were drawing all wrong because the Shader wasn't being found and it was throwing exceptions midway through drawing it each update. (KSP 1.8 changed the way you access the built-in shaders.)
  10. It seems to be home-made and not "based on" anything pre-existing. Originally it was meant to sort of feel like the slow primitive BASIC interpreters that 1980's era home computers tended to have. In fact the original terminal was painted using a bitmap template taken from the Commodore 64 character set to give it that look. (I've since changed it to use a real system font from your computer OS, so it can support more Unicode glyphs for people printing things out in Russian, Polish, Japanese, or whatever. The C-64 font has a lot of nostalgia for me, but it only ever had glyphs for English letters. I didn't want the job of having to draw out little bitmap images of all the letters in all the languages to add them to the texture template it was using, so I made the change to a real OS font to offload that burden onto the font makers not me.) kOS has also passed through multiple hands of stewardship, with more than one person working on it so it currently looks very different from what the original person had in mind, probably. (For example, the original had only global variables, with no local variable scoping and no function calls, both of which I've added later. Since I added them later, I have no idea if their syntax is "in line with" what the original author had in mind.) I'm the current maintainer but not the original initial creator, and there's definitely stuff about it that I wouldn't have picked to be that way but I don't want to tear it to shreds and start over ruining everyone's existing scripts so I try to stick to the same "general" principles it appears to have started from, which are: 1 - Tends to use keywords more than punctuation. i.e. "SET X TO 5." rather than "X = 5;". Using a period (".") as a statement terminator instead of a semicolon or just an eoln like many other languages do. 2 - Reading it in English should sort of sound like what it does. as in: Set x to 5. lock throttle to 1. wait until altitude = 1000. When blah is true then print "blah". and so on. (This is one of those styles I'm not a huge fan of, for reasons too long to go into right now, but I kept trying to adhere to it with the many features I added, because I figure keeping the whole language in the same style is still better than switching to a new style halfway through for the new stuff, while keeping old stuff in the old style, creating a style clash.) As an example of *trying* to make it English-ish, when I wanted to implement something like the 3-part for loop of C: (the one that looks like this: for (init; check; increment) {body}), I struggled to find a way to make that sound vaguely english-like, when there's no real English construct that looks like that. So I settled with FROM init. UNTIL check STEP increment DO body. to get the same general idea but kinda sorta make it look vaguely like english.
  11. I don't know what to say. I can't tell what's happening. I can only suggest trying one of these two things, as they have made a difference in the past: 1 - If it's a manned ship with no unmanned capability (only a crewed capsule, no probe core), try adding a probe core to it as sometimes the comms system doesn't bother doing work when the capsule is manned, under the assumption it doesn't need to bother checking for connection for control when the ship requires a person in it anyway to control it. 2 - If the antenna is of the "direct" type, try having a "relay" type antenna on it as well as (or instead of) the direct antenna. Some aspects of the comms system seem to only be loaded by KSP when the vessel is relay-capable, as some kind of way to save CPU cycles, again under the false assumption that commnet only has to check for human control ability and the subsystem that checks for distance and hops doesn't need to exist when nobody else could be piggybacked onto the connection to this ship.
  12. Because of the changes to Unity, I seriously doubt it will work right on 1.7.x, although I haven't tested to verify this. BTW, I never had the problem the PR allegedly fixed. The original code loaded textures in 1.8 just fine. But I trusted that there was some case where the change was needed but it was a case I didn't have. Ironically, the PR actually *caused* textures to fail to load for many people. It hardcoded Windows-style backslashes instead of slashes into the pathname, so the PR caused the texture errors people on UNIX systems were getting. Anyway, it's all good now in kOS v1.2.1.0, where I took your PR but swapped the backslashes for slashes and it now works cross-platform.
  13. I uploaded the wrong ZIP file for v1.2.1.0 to the three sites (curseforge, spacedock, github) and just uploaded a corrected version. If you obtained it within the last 2 hours, please download it again to get the new correct ZIP.
  14. The DDS texture loading bug on UNIX platforms should be fixed in the hotfix I just released, called v1.2.1.0. I do not have access to a Linux or Mac machine powerful enough to run KSP (mine are very old computers) so I cannot test this myself. I am *hoping* the change I made fixes it. Please try it and let me know. Try to put a wait of a few seconds into the top of the boot script. It sometimes will load the ship and let its PartModules start operating (like kOS) before KSP has finished loading up and populating Comnet fully. Waiting 2 or 3 seconds should give commnet time to finish settting itself up.
  15. kOS is broken on UNIX platforms. The PR contributed for DDS fixes had hardcoded backslashes in the filenames, which I thought .Net libraries would make cross-platform but they do not. It only makes it cross-platform in one direction but not the other. (The .Net file routines will convert Unix paths (with slashes) so they work on Windows, but won't map the other way. They don't convert Windows paths (backslashes) to work on UNIX.) I'm making a new ZIP which has the paths in the UNIX way so they'll work on all platforms.