Steven Mading

  • Content Count

  • Joined

  • Last visited

Community Reputation

853 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. So if do it in the reverse order from that, such that I merge the .netkan change into the master branch a few hours *before* I've cut that release from master, will it end up making the previous release of kOS get a dependency on ClickThroughBlocker (because the newer release wasn't there yet when the Netkan bot crawled every half hour and saw the kOS.netkan change in master branch)? If so, then I have to change how I'm doing my PR for this change and split it into two PRs - one for the C# code that calls ClickThroughBlocker's API and another for the kOS.netkan dependency on ClickThroughBlocker that code caused. (Right now they're the same PR which seems sensible at first unless it would cause the scenario I described in the previous paragraph). It matters because my dependency requires a minimum ClickThroughBlocker version number to have the features LinuxGuruGamer just added a few months ago that I'm using. If the previous release of kOS ends up falsely claiming it has a hard dependency on this new version of ClickThroughBlocker, that could prevent CKAN from letting you install it on older versions of KSP that only allow older versions of ClickThroughBlocker. That's why I'm nervous about making sure I do this right.
  2. Thanks for the quick reply. Will it be smart enough to NOT apply the new dependancy to older versions of kOS if I just continue with the .netkan file technique as it is using now? Or do I need to switch to the .ckan file in the ZIP to get that kind of version-specific dependency?
  3. I have a question about how the CKAN bot crawler works. The kOS mod is already in CKAN, but I need to add a new dependency when I make the next release (The next release will depend on ClickThroughBlocker. It didn't need it before.) I know what edits to make to the netkan file to describe the dependency, but I don't know how to get CKAN's bot to see the change. Currently the .netkan file isn't part of the ZIP at all (it's edited "one folder up" from where the ZIP is cut from) so I assume the bot can't possibly see that information. I'm guessing that previously the mod was manually added to CKAN with a pull request but I'm trying to figure out how to make it automate the updates by having the CKAN bot see the information somewhere inside the ZIP file, like it does for the .version file. (This is a mod I inherited from others. I was not the person who originally set it up in CKAN so I don't know what steps were taken at the time.) So my question is this - if I just start using netkan.exe to convert the .netkan file into a .ckan file, and copy that .ckan file to GameData/kOS/whatevername.ckan, inside the ZIP will that automagically make the bot update kOS's CKAN info when I make a release with that ZIP next time? Or are there other manual steps I need to do first? Up until now, we *have* been getting automatic updates in CKAN from the information in the ZIP's "kOS.version" file, but this is a thing the .version file doesn't have in it (dependency on another mod).
  4. The timewarp workaround only fixes one third of the effects the change caused. The other two effects it does not fix are: {1} One-to-Many transfers involving 3 or more tanks don't work anymore, making fuel balancing impossible; {2} It broke the use of fuel hoses to route around blockages like heat shields, meaning you now must play with that difficulty option turned off, as its rules are broken.) These are problems in *stock* gameplay, not even modded. Unlike dok_377, I don't mind that the fix didn't come out immediately. It's probably an issue with dirty cached data and those can be hard to trace without just throwing away the entire caching idea entirely. But I do want to quash this narrative that says it's low severity because of the workaround. The workaround doesn't really fix all the issues this change caused, so please don't move it to the backburner.
  5. Ever since KSP 1.10.1 downloaded today I have gotten 6 crashes to desktop, all when trying to do the same thing (this is stock, no mods, but I do have both DLCs): The crashes only ever happened when trying to drag one of the 6 'knobs' of a maneuver node. Usually (thought not 100% of the time) that maneuver node was made while currently in orbit of Sun, on the way to Jool, and trying to make a maneuver node on the Sun orbit patch that will adjust the future Tylo approach to do a gravity-assisted capture at Jool. This is making it unplayable (as my career is currently in the middle of trying to do stuff at Jool so this Tylo assist is a common task.) and I cannot back out to KSP 1.10 (the Steam "betas" tab does not show 1.10 as an option. I can either have 1.10.1 or 1.9.2 - nothing in between those two.) This problem never happened before today's update. As part of trying to clear out whatever the bug is, after each time, I used Steam's "Verify Integrity of Local Files" and it always finds a few that need re-downloading after the crash. The file "PartDatabase.cfg" is *always* reported as needing a reload. Sometimes it wants to reload other ones too, but that one is the consistent one that always differs. I don't know if this is just a normal side effect of having played the game (maybe it always writes that file out each time the game runs) or related to the crash. Is anyone else experiencing this? Am I alone? I saved the last 4 Crash folders from Appdata/Squad/Kerbal Space Program if that would help.
  6. It sounds like this problem, which is known but not in release yet: Do you have the ability to compile the kOS Project? If so, using the latest Develop branch would probably fix it. Otherwise I think you'll have to wait for release. With KSP 1.10 coming this week, I do plan to have a release of at least some sort within a week after it comes out - even if it's just a basic compatibility release.
  7. Some people have made patches for ModuleManager that add the kOS PartModule to probe cores. This is fine, but if more than one mod has done this, and one of them wasn't set up right, it can install the partmodule in *addition to* some other mod that is also doing it. There is a means in ModuleManager's config files to add the condition "only if it's not already there" to the command to add a KOSProcessor. But somewhere you have a mod that's not doing that. To figure out which of your mods are adding kOS via ModuleManager, search through all files under the GameData folder that are ending in .cfg, and scan them for the magic word "KOSProcessor".
  8. There is both a subreddit and a discord server that are all about kOS and are a better place to ask. There is also a thread on these forums, but that thread has slow response times. I'd recommend the subreddit as the best way to ask a long question (which it sounds like you have) where you need to describe things in detail, post code, and wait for an answer. The discord is better for shorter questions that can be answered fast and don't need a lot of explaining. Thread on these forums -> SubReddit -> (A permalink invite to the Discord server, as well as links to documentation, are in a sidebar of that subreddit.)
  9. Not the same thing. Not at all. Let me explain the difference. The XKCD cartoon is talking about a user who is aware the bug is getting fixed, but prefers it and wants it to stay broken. This is about people who *don't know* the bug is getting fixed, so they don't know they have to remove the offset they put into their code. Their code becomes retroactively incorrect and that's not their own fault. What may be better is to fix it but give it a new name. The old name could be depricated but still work the same way. People could still run out of date code using the old way, but it would spew warning messages on the screen. The newly renamed function would do it the correct way.
  10. Well dang. That's not how it was meant to work. But it's been this way long enough to break people's scripts that expect it to be this way.
  11. So, the tl;dr - From now on, I need to know that any change to the ZIP file's contents requires also changing the ZIP's file's name. (i.e. "" becoming "" or whatever.) I'll test a CKAN install of kOS today. If it still doesn't work, I'll change the filename of the ZIP. (Based on posts in the kOS subreddit, I think someone at CKAN might have gone in under the hood and massaged the data for kOS to give it the new checksum, which is why I should test first.).
  12. Yes but what do you mean by"should"?? I updated the ZIP on github because kOS works fine on KSP 1.9.1 and I wanted the kOS.version file to say so so CKAN would allow it to install. Mod writers are supposed to do that by updating the .version file - I did that and then remade the ZIP with the only difference being the change to the .version file that said max KSP version was 1 8 99 to saying 1 9 1 instead. I have no idea why CKAN calls it invalid for the ZIP file to have changed size. Of course it changed size. Because I overwrote it with a new version. I don;t understand why CKAN claims this is a fatal problem. I thought it was supposed to read the ZIP file and obey what it said, not complain that I changed it. I don;t understand CKAN sometimes.
  13. Define "corrupted". (can you show the exact error message you got and what step you were doing at the time?)
  14. @linuxgurugamerThank you for implementing this - I will be trying it out late tonight.
  15. Rather than "option to ignore one of the windows", I wonder if there could be "option to configure ClickThroughBlocker itself into either click-to-focus or focus-follows-mouse mode". (So it applies universally to all the mods that use it, according to user's preference). The ClickThroughBlocker github code looks simple enough I may try playing around with this myself and see if I can submit a PR. The harder part is seeing if all the other mods using ClickThroughBlocker may have been written in a way that presumes focus-follows-mouse and would break in some way if using click-to-focus. If so then this might not be a viable option even it was technically doable.