Jump to content

DomiKamu

Members
  • Posts

    105
  • Joined

  • Last visited

Posts posted by DomiKamu

  1. Thanks a lot (no, thanks a million) micha!

    Your modification (test release 6.8.4.1 mw) seems fine: by using it (stock bar, I never used Blizzy toolbar), no more DPAI icon in KSP menus (main menus) on scenes changes!
    From your ZIP , I'm not sure if .pdb files are required or not (I've installed them, however) - perhaps required debug symbols...

    Also, thanks for cleaned 6.8.4.2 I've seen above, I'll test it this Sunday. EDITED: both 6.8.4.1 mw and 6.8.4.2 mw work fine!

    Great stuff, merci (thanks in French ;) ) - have a merry Christmas in advance.

  2. 10 hours ago, micha said:

    Made a test release - https://github.com/mwerle/Docking-Port-Alignment-Indicator/releases/tag/6.8.4.1-mw

    Should hopefully fix the Stock Toolbar issue but needs more testing.

     

    Hi micha, I've done few tests this evening by using your DPAI 6.8.4.1 "debug" patch - the icon doesn't appears when returning to main menus. Of course, more tests are perhaps required (I presume), but I hope is a good way!

    I use stock bar only (+ ToolbarControl / ClickThroughBlocker, required for lastest Critical Temperature Gauge mod). Last checkbox unchecked (like Stone Blue just above).

    Thanks!

  3. 27 minutes ago, LTQ90 said:

    Hi Domikamu, i m using english version of ksp on a windows 10 french system. There are some icons like yours, showing in the main menu, this for a long time for me, but never feels that as an issue, just a little maybe "bug". Never get problem to run the game. So i may just tell you to consider if the game s running fine, and so let s the icon make their lives :)

     

    Using French Windows 7 too (us-en KSP) - but this "bug" also concerns English Windows users. Firstly, other mods I'm using don't have this "bug". I admit the game runs fine, but be sure it's abnormal. For me, it's a bug, like any other bugs. I don't understand why it wasn't fixed (despite as indicated in TXT file - since 6.8.0 !). For now, I don't use it why this bug remains unfixed.

  4. 31 minutes ago, micha said:

    I don't know how much time @NavyFish has at this time, but I've got a longhaul flight coming up later this week. I can take a look then.

    @DomiKamu are you using stock toolbar or blizzy toolbar for this mod?  Please add any additional information to the bug report. If you don't have a GitHub account, here will do as well. Thanks.

    FYI :

    - Page 54 (May 30, 2018)

    - Page 48 (January 3, 2017)

    - Page 47 (October 26, 2016)

    Perhaps more older post(s) from me, but I don't have checked prior page 47... For pages I've mentioned, simply search my nickname DomiKamu.

    I precise I'm not alone, other users have reported the same issue since long time. I'd like to have a clean KSP on my computer, and I avoid buggy mods.

  5. 17 minutes ago, micha said:

    I don't know how much time @NavyFish has at this time, but I've got a longhaul flight coming up later this week. I can take a look then.

    @DomiKamu are you using stock toolbar or blizzy toolbar for this mod?  Please add any additional information to the bug report. If you don't have a GitHub account, here will do as well. Thanks.

    I'm using stock toolbar. I've already posted in this topic the elements about this issue (but now they're 58 pages).

  6. 2 hours ago, linuxgurugamer said:

    Did you mean to say that the icon shows up on the main menu after having been in the flight scene in a game?

    Yes, this is the issue I mention. By using any other mod, this never occur. Also, from older README.txt (or similar doc, I don't remember precisely) he've mentionned this (cosmetic) issue was solved, but in reality, not. Something is bad in source 'I presume - I don't have C# knowledges to read sources).

    Also, about recent compiled dlls, it's abnormal to see 30/06/2019 (aka 30-June-2019) as timestamp from zip files (from Spacedock, and from GitHub) for... KSP 1.8.1 binaries! Be sure it's confusing for me, but also for other users here. Why the ".version" file mentions from v1.6 to v1.8.9 (from previous release)?

    For me, it's end of this story. I don't want fight or something like. I've reported this issue many times in this topic. Yes, it's an issue (despite the game doesn't crash). By this way, I've just decided to avoid this mod, nothing else.

    Regards.

  7. 21 minutes ago, linuxgurugamer said:

    Did you know that all releases on Spacedock are still there, click the Changelog link.

    and what bug are you talking about?  I have been using this for years, and don’t know what you are talking about.

    There arent any open issues on github.  If this is a real, repeatable bug, open an issue with all the details

    The bug is known and never solved : the icon remains from KSP main menus (the readme says it was fixed, it's false).

    Also take a look about DLLs (3) timestamps from zip (picture in reply above) : 30/06/2019 (format DD/MM/YYYY - I'm using French Windows).

    I've downloaded BOTH from SpaceDock first, then from his GitHub (zip files are identical). Due to this persistent bug, unfortunately I've removed all DPAI from my mods list.

  8. On 12/1/2019 at 5:37 AM, HebaruSan said:

    NavyFish, you taught me how to dock.

    Consider it done!

    EDIT: We have 6.8.3 as 1.6.0 through 1.8.99. Is that OK?

    https://github.com/KSP-CKAN/CKAN-meta/blob/master/DockingPortAlignmentIndicator/DockingPortAlignmentIndicator-6.8.3.ckan

    LOL (I've placed a reply just above - I'm disappointed about this mod)... It's easy to edit the post title on forum and .version file... Unfortunately, previous releases (binaries) are removed (unable to compare files / CRCs).

  9. V6.8.4 updated to v1.8.1: hum... [snip]

    Be sure in advance I don't want to be angry, but simply by checking DLL file timestamps from zip (30-June-2019), it's an old release - and having the continuous bug concerning the icon in main menus in previous KSP 1.7.3 (in fact, please be honest, this bug was never fixed). I don't want to use it KSP 1.8.1, and this mod is ban for my computer. Too bad, because I love the docking port renaming feature, and the gauge itself. [snip]

    EDIT; downloaded from SpaceDock and your GitHub (lastest release, shown by screen capture below).

    19121510155417588316558332.png

  10. On 12/11/2019 at 11:11 AM, Teilnehmer said:

    I like the idea behind Toolbar Controller. Since almost every mod has to deal with AppLauncher and/or Blizzy’s Toolbar anyway, it was a clever idea to implement this functionality once in a dedicated mod other mods can use. LinuxGuruGamer knows it well.
    I too find Toolbar Controller not perfect, but this is not a reason to avoid it. It’s open-source, so we can contribute to it.

    The reason I included Click-Through Blocker as a dependency is simple: Toolbar Controller needs it.

    Moreover, these two dependencies are almost unavoidable since they are included in every mod handled by LinuxGuruGamer. Very few people, I believe, have a modded installation without a single LinuxGuruGamer’s mod :)

    Ok I understand, but in this case, why not two releases? one including the dependencies, one not? Thx

  11. Hi,

    I don't understand why they're some "obsolete" dependencies are included in your lastest package (reDIRECT v0.10.0, downloaded from Spacedock, and tagged as KSP 1.7.3).

    For example, included CRP is v1.0.0.0 (October 28th 2018 - designed for KSP 1.5.0) instead of lastest v1.1.0.0 (more recent - February 2019 - but for KSP 1.6.x).

    Same fact concerning DeployableEngines v1.0.0.0 but recently updated to 1.1.0.0 (very recent - July 29th 2019 - I admit).

    Also B9PartSwitch, a very sensible mod, offered as v2.7.1 instead of v2.9.0.

    By using lastest versions, in particular for Near Future Technologies (and derivatives like Cryo Engines) - instead of provided - I'm not sure about reDIRECT compatibility (I'm using KSP 1.7.3), btw I hesitate to use it...

    Thanks in advance for explanations.

  12. 1 hour ago, TBenz said:

    I don't know how to break this to you, but they wouldn't need to "relocate" Dres very far, seeing as how it's already right between Duna and Jool anyway.

    Also, my gut feeling is telling me that the Outer Planets Mod probably doesn't want to do much changing to any of the inner planets. You may need to look elsewhere (or try your own hand at modding) if you want to change Duna's satellites. 

    @TBenzOh yes it's okay about Dres location (between Duna and Jool). I've said mines questions may are stupid, so... this is one! ;) Okay also for Duna satellites - but unfortunately I don't have enough skills to do by myself. And it's not important. Thanks for your reply, appreciated! ;)

  13. Hi and big thanks concerning Outer Planets Mod addon! I'm using it (v2.2.2) against KSP v1.7.0.

    I have just two questions (maybe they're stupid questions), can are considered as suggestions however:

    1/ is it possible to remove Dress planet? (maybe Dress is remaining in OPM for some reason I unknown - eg technical/KSP limitations, or other)? or maybe - if possible - Dress orbit can be relocated between Duna and Jool (in order to "simulate" Ceres into asteroids belt, for example).

    2/ is it possible to enhance Duna moons system (like Phobos/Deimos) by redesign Ike orbit, and by adding small rock like Deimos?

    The "third" question was already asked in this forum (about Eve retrograde rotation, like Venus does), so I don't ask it again ;)

    TIA.

    Dominique.

  14. 2 minutes ago, Tonka Crash said:

    The only problem with B9 Part Switch is it's causing players to freak out. The latest version is actually showing you errors in B9PS configurations from mods that used to only be dumped to the log. The problems have always been there, but since most people don't look at their logs, they weren't aware of the problems. Since B9PS is now throwing it in the player's face they freak out and think B9PS is broken. This is not a problem with B9PS, it's a problem with the mod with the bad config file causing the warning.

    Thanks Tonka Crash for this useful info! ;)

  15. 8 hours ago, jwenting said:

    Spacedock seems to think NF Construction isn't compatible with 1.7. Guess simply an error of Spacedock.

    Thanks for the relentless work, Nertea. And yeah, do something you like if it gets tedious :)

     

    In my opinion, NF Construction is based on parts only (aka no plugin such .dll file). Also, Spacedock assumes it's a 1.6.1 mod, for this reason it indicates "Outdated mod" warning, but don't worry about this.

    I don't have tested lastest NF yet, unfortunately (I'm too busy actually).

    The doubt may I have concerns B9 Part Switch (enclosed is v2.7.0 as dependency, but lastest version is v2.7.1 for KSP 1.7.0) because I've read negative comments about it (against KSP 1.7.0). But must be confirmed...

  16. 1 minute ago, Snark said:

    Aha.  I think I see what's going on, and it's easily fixed.  Short answer is that you've run into an edge case that I didn't anticipate, and which I didn't encounter since I never run MechJeb.  I'll get a fix out when I can.  Thanks for reporting!

    Technobabble with internal programming details, for the curious, in a spoiler.

      Hide contents

    Most of KSP's C# API is implemented in terms of classes, but there are few places where it uses interfaces.  Targets are one of these.  If you have a ship, and you target something... well, the game lets you target vessels, but also lets you target celestial bodies.

    Vessel and CelestialBody are completely different classes with completely different properties, though they do share some properties in common (e.g. they both have an orbit, for example).  So, put yourself int he developers' shoes.  I've got the Vessel class, and I need it to be able to target something, and that target might be either of two completely different things... how do I write my target-handling code so that it works equally well whether the target happens to be a vessel or a celestial body?

    The simple and (to any programmer) obvious solution is to use an interface, which is what KSP does.  It has ITargetable.  The classes Vessel and CelestialBody both implement this interface.  All perfectly nice and normal.

    So, where BBT ran afoul, here, is that I'm an idiot and committed one of the cardinal sins of programming-- cannot believe I did that, I guess I must have been tired that day.  :blush:  What I did was... I made assumptions about which classes might implement an interface.  There's some code in BetterBurnTime for the geosynchrony tracker that I introduced in BBT 1.9, which basically goes like this:  "Okay, I need to get my target... okay got it.  It's an ITargetable, and I know that the only two things that implement that are Vessel and CelestialBody, and each of those have an "orbit" property, so I'll just get that and use it.

     

    You're welcome! ;) Be sure BBT stays a great mod! Thanks (merci in French - my language).

  17. Hi Snark,

    I'm testing BetterBurnTime v1.9.1 against KSP v1.7.0, I have ton of exceptions generated while landing (using MechJeb 2 Dev #883 - landing autopilot / after "Pick target on map") on the Mun:

    Recurent line is:

    [ERR 11:15:24.956] [BetterBurnTime] (NullReferenceException) Object reference not set to an instance of an object:   at BetterBurnTime.GeosyncTracker.RefreshTarget (.Vessel vessel) [0x00000] in <filename unknown>:0
      at BetterBurnTime.GeosyncTracker.Refresh () [0x00000] in <filename unknown>:0
      at BetterBurnTime.GeosyncTracker.LateUpdate () [0x00000] in <filename unknown>:0

    This is my KSP.log: https://www.dropbox.com/s/wdmei0uith5kskt/KSP.log?dl=0

×
×
  • Create New...