Steven Mading

  • Content Count

  • Joined

  • Last visited

Community Reputation

824 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. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Update for KSP 1.8.1 released. Special thanks to @Thunderous Echo, who started contributing to the code with this release. v1.2 Unity Update This update is mostly to make kOS compatible with KSP 1.8.x, which started using a newer version of Unity, and a newer version of .Net, which have some consequent changes in the code and build process. BREAKING CHANGES None that are known about, other than the usual reminder that KSM files need a recompile after every version update of kOS. NEW FEATURES Now forces both the toolbar window and the telnet welcome menu to list the kOS CPUs in a consistent unchanging sort order. Previously, it was pretty much random what order you would see kOS CPU's listed in the menu, which made it hard for JonnyOThan's Twitch-Plays-KSP chatbot to know which CPU it was attaching to when it sent commands to kOS. This has been changed to a predictable sort order as follows: (1) Sort by which vessel the CPU is on, starting from the active vessel, and then for other vessels, sorting by distance from the active vessel, closest first. (2) When the same vessel has more than one CPU, break that tie by number of "hops" from the root part, such that CPU's attached closer to the root come first. This is by "number of parts to walk through to reach root" rather than by actual physical distance, since using physical distance might have led to inconsistent sort order given that some ship parts can hinge and extend, changing that distance. pull request New suffixes Dockingport:PARTNER and Dockingport:HASPARTER will tell you which docking port this docking port is docked with. issue pull request HEADING() Now allows optional 3rd argument, "roll". issue pull request Let user-made GUIs toggle IMGUI's wordwrap flag with a new suffix: Style:WORDWRAP. This should let you fix that annoying problem where a GUI Label would insist on wrapping even when it could have fit by making the window wide enough. Setting wordwrap to false will force the GUI layout engine to keep the label's area wide enough to not wrap the text. issue pull request Add BODYEXISTS test issue pull request Allow FLOOR() and CEILING() to specify a decimal place other than the one's place, like ROUND() can do. issue pull request Add a constructor, CREATEORBIT() that will make a new Orbit object for any hypothetical orbit given Keplerian parameters, without it coming from a vessel or a body that already exists. issue pull request Added new suffix to waypoint: :ISSELECTED, which will tell you if the waypoint is the one the user has selected for their navball. issue pull request BUG FIXES Bound variables like SHIP, UP, VELOCITY, etc stopped existing in the KSP 1.8.x update. This was because kOS makes use of reflection techniques to store information about C# Attributes that help it find the bound variables in its code, and .Net 4.x changed the meaning of Attribute.Equals() in such a way that it broke what kOS was doing to store this reflection information. A Dictionary that kOS was using to track bound variables by Attributes started having key clashes because of that change to what it means for an Attribute to be Equal to another Attribute. ((No link to a github issue because this was part of the general KSP 1.8 update PR and didn't have an issue.)) Prevent waypoints with bogus body names. pull request Fix a problem that made the GUI terminal sometimes get stuck refusing to repaint when resized to a size too small to hold all the text it previously had showing. issue pull request Several minor doc typos pull request pull request The startup message about default font and "if you want the old look" was quite obsolete by now and needed to be removed. issue pull request Changed the technique used to load DDS icons used in the kOS GUI terminal and the kOS toolbars, to bypass KSP's strange API and go directly to Unity. This may or may not help people who had the purple square icon problem. ((No issue - SlimJimDodger contributed PR out of the blue.)) pull request
  8. Can you elaborate on a specific scenario, hardware and OS, where it was failing before this PR, but working after it? I ask because I never saw the original texture problems other people reported so I'd like to know an exact thing to do to make it happen. I fear it may be graphics card dependent, as DDS decoding is sometimes done by the device driver.
  9. You appear to be asking a question as a user of the kOS mod, which isn't what this thread is for. This thread is for people *developing* mods, not using mods. I put the reply to your post over here instead:
  10. @Matt Stryker posted this in a different thread - I'm replying to it here: Are you running this on KSP 1.8? If so, then kOS is almost completely broken on KSP 1.8 and that's the problem you're having. All of kOS's bound variables are missing in KSP 1.8 - verticalspeed, core, ship, velocity, apoapsis, etc. I know why and fixed it in the develop branch but there's other problems with the KSP 1.8 update I need to fix first before I release a kOS that's compatible with KSP 1.8. (Without going into too much detail, the problem was apparently caused by a very subtle difference in how "Reflection" does things in the newer C#/.Net, causing some Types to be "Equal" which were not "Equal" before. kOS was storing information about these Types in a collection that requires unique keys and this change meant they weren't unique anymore.)
  11. The screenshots show what I mean - Just started a career in KSP 1.8. When I transition up to the Mun, the moment it shifts into the Mun's sphere of influence, the Pe is drawn in the wrong spot - not even on the orbit line at all. The problem tends to fix itself once I make my capture burn and the orbit becomes elliptical instead of hyperbolic. It might only be happening after transition when the orbit patch is still hyperbolic. I can make a report in SQUAD's bugtracker, but first I wanted to ask here if anyone else is seeing the same thing. My only mod is a preview version of kOS that I'm trying to test to see if I got it working on KSP 1.8 yet (I'm a kOS dev). I have no clue what kOS could be doing that would cause this.
  12. Can we get a more specific description of the .Net version than just "4.x"? Because I don't know what is safe, I am only using 4.0, not 4.5. If I could use 4.5 it might be a good idea to do so, but I don't know so I'm avoiding it for now.
  13. This sticky post has one small piece of information that just became wrong in KSP 1.8: I noticed that Unity finally made all the platforms use a consistent name for the output log. It no longer makes Windows an exception where Windows uses output_log.txt while everyone else uses Player.log. Now all three platforms (Mac, Linux, Windows) use Player.log - if you still have an output_log.txt file after the KSP 1.8 update, it's a stale old copy leftover from the last time you ran a pre-1.8 version of KSP, and not the most recent run. I don't know if NathanKell is still around to edit that post, but somebody probably should (or stop making it sticky so it can be replaced with a new post) before modders start getting user reports using the stale output log file.
  14. Okay it seems something went wrong when I copied over the dll's to the project, and I got older versions of the dlls from KSP 1.6, not the KSP 1.8 version. That's why the method was missing. I wiped KSP from steam entirely and redownloaded, then copied the DLLs over to the Visual Studio project folder and THEN it compiled. I don't know what I did but it was something on my end, clearly. It's resolved now.
  15. EDIT: The following question appears to be moot now. I found the answer, I think. See next post for explanation. Here is my first question to start the thread: PartModule.Fields.TryGetFieldUIControl went away When Breaking Ground came out, TriggerAU helped me with a problem in kOS, giving the advice that I should use this method when accessing the fields on PAW's for the servo partmodules of BreakingGround: bool PartModule.Fields.TryGetFieldUIControl(string name, out UI_Control control) This was a relatively new method I hadn't seen before KSP 1.7.x. But now In KSP 1.8, it looks like this method doesn't exist anymore, or maybe I need to include another new DLL reference or using statement to make it work. As of KSP 1.8, It now gives this error when compiling: "Error CS1061 'BaseFieldList' does not contain a definition for 'TryGetFieldUIControl' and no extension method 'TryGetFieldUIControl' accepting a first argument of type 'BaseFieldList' could be found (are you missing a using directive or an assembly reference?) kOS C:\Users\Steve\Documents\GitHub\KOS-1\src\kOS\Suffixed\PartModuleField\PartModuleFields.cs" For reference, this is the snippet of kOS's code that it is complaining on: // Using TryGetFieldUIControl() to obtain the control that goes with this // field is from advice from TriggerAU, who gave that advice in // a forum post when I described the problems we were having with the servo // parts in Breaking Ground DLC. (There is some kind of work being done here // that seems to allow one field's ranges to override another's as the servo // parts need to do. This is work which doesn't seem to happen if you look at // the KSPField's control ranges directly): UI_Control control; if (!partModule.Fields.TryGetFieldUIControl(, out control)) // <----- Worked in KSP 1.7.x, not in KSP 1.8 { throw new KOSInvalidFieldValueException("Field appears to have no UI control attached so kOS refuses to let a script change it."); } If this call went away or got renamed, what should I replace it with?