Jump to content

Dunbaratu

Members
  • Content Count

    3,845
  • Joined

  • Last visited

Everything posted by Dunbaratu

  1. Hopefully this gets fixed in a KSP 1.11.1 patch soon. To any players playing career in KSP 1.11.0, I wanted to drop a warning in here. The new contracts that were added with KSP 1.11.0 such as repairing rovers and satellites, and adding parts to satellites, have impossibly short durations for interplanetary missions. They seem fine for around the Mun or Minmus, but not for Duna, Jool, etc. You take the contract and get blamed for "failing" at it (sending money into the red if it's big) even though you were never even given the time it takes to make one single attempt at it. The pr
  2. This might be an obvious thing to check you already tried but ... do you have a controller plugged in and maybe during the upgrade did the game lose the nullzone settings for it (so it now thinks an analog stick is always slightly offcenter and that's making it rotate the camera?)
  3. There are a few issues in the bug tracker where other players have reported the same problems since KSP 1.11 came out this week. There's something wrong with how this new way of storing light color info works. Either it is not getting saved in files or it's not being loaded back from files. It also gets forgotten in craft files so if you spend time in the VAB fiddling with the light settings it's wasted time because it gets forgotten when you go from VAB to launchpad. Not sure what is wrong but anything that involves saving/loading to a file fails to preserve these settings.
  4. Is this a bug or is it expected behavior? ClickThroughBlocker is in focus-follows-mouse mode, and I hover the mouse pointer in an area where two windows overlap. Instead of JUST the input lock of the window on top, it's activating the input lock of both the windows, including the one that's underneath. In the screenshot, both the two windows are created using ClickThruBlocker, with this specific version of the many overloaded variants of the Window call: ClickThruBlocker.GUILayoutWindow(int, Rect, GUI.WindowFunction, GUIContent); This variant is one of the ones that uses the Wind
  5. The bug tracker, at https://bugs.kerbalspaceprogram.com/ has started getting spambots posting "issues" which are actually ads. Some of which have stayed in there a while. Is anyone on top of this and reading the issues? I'm wondering because the spambot issues aren't being removed or closed, making me wonder if anyone working for SQUAD or Take 2 is even looking at the tracker anymore.
  6. 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 ClickThroughB
  7. 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?
  8. 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
  9. 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 h
  10. 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 tryi
  11. It sounds like this problem, which is known but not in release yet: https://github.com/KSP-KOS/KOS/issues/2666 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.
  12. 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 endi
  13. 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 -> https://www.reddit.com/r/Kos/ (A permalink invite to the Discord
  14. 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, b
  15. 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.
  16. 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. "kOS-v1.2.1.0.zip" becoming "v1.2.1.0_b.zip" 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.).
  17. 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 cl
  18. Define "corrupted". (can you show the exact error message you got and what step you were doing at the time?)
  19. @linuxgurugamerThank you for implementing this - I will be trying it out late tonight.
  20. 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.
  21. kOS developer here. A few months ago I tried to explain a thing I saw in ClickThroughBlocker code that felt kind of off to me, and I did a poor job trying to describe it. I now have a much better example to illustrate what I was talking about with the word "focus-follows-mouse". For this example, I use "KSP Notes", which is the simplest ClickThroughBlocker-using mod I could find (it just lets you type text notes in a window.) (For the screenshots below, I had to maually draw where the mouse pointer was, since KSP's screenshots don't show the pointer.) The same effect happens f
  22. @AxleGreaserThere's just not enough information to know what you're talking about. Too much guesswork about what the rest of your code is doing that isn't shown.
  23. I just made this an issue in github - thanks for bringing it to my attention.
  24. I'm not going to walk through your whole code. Just print out the value of 'data' immediately prior to the line that complains. Just before this: local t is data[0]. do this: print "data is type: " + data:typename(). print "data is value: " + data. and see what data really is. It's not what you think it is.
×
×
  • Create New...