Jump to content

Poodmund

Members
 View Profile  See their activity

  • Posts

    2,032

  • Joined

  • Last visited

 Content Type 

Everything posted by Poodmund

  1. Poodmund
    I would suggest then there is an issue with your install: https://github.com/Poodmund/Outer-Planets-Mod/blob/master/GameData/OPM/KopernicusConfigs/SarnusMoons/Ovok.cfg#L26
  2. Poodmund
    If a specified variant, used in a craft file, doesn't exist it will fall back to using the base variant as specified in the part file (basically the default variant).
  3. Poodmund
    Something very odd and bad is happening with the PQS mesh of the body here at the end of the log: Did you say that this absolutely does not happen when Sigma: Dimensions is not installed? With S:D installed on my own test bed I have also found that ground scatter is floating in mid air when it spawns in distant places so there may be some issues here. The first issue, like I mentioned to Nicias on this page above, I cannot really comment without seeing log files so if you could post them itr would be appreciated. With regards to the 2nd issue of the orbit lines jumping, unfortunately thats an inherent issue with orbits with a very large semi-major axis. This is a long-running Kopernicus issue that, at the moment, we have all just lived with for a long time.
  4. Poodmund
    If not already, please set your Terrain Detail setting to High and report back with further details. Please also upload your: Kerbal Space Program/KSP.log file and also the contents of your Kerbal Space Program/logs folder.
  5. Poodmund
    Most likely cause is that the Scatterer planets list config file is specifying the wrong star. This is GPP's issue, or more specifically, GPP_Secondary's issue so I would suggest you raise the issue with the developers of said planet pack to see if they can resolve it for you.
  6. Poodmund
    I pushed v2.2.7 to allow for Kopernicus Continued support (https://forum.kerbalspaceprogram.com/index.php?/topic/194936-191-kopernicus-continued/) on KSP 1.9.1 and redid the KSPedia bundles to work on KSP 1.8.*+. Downloads can be found in the usual places, Github and through CKAN.
  7. Poodmund
    I believe the CKAN team are aware of the situation and are debating some ideas also.
  8. Poodmund
    @prestja if you plan to add this to the CKAN index then may I suggest that you list the minimum version as 1.9.0 so that anyone running a previous version of KSP is forced to use the main Kopernicus trunk release versions?
  9. Poodmund
    That's actually completely false when you consider the licensing that this mod uses, of which the add-on rules of this forum have enforced upon it. The fate of this mod is in the hands of ANY community member that wishes to contribute their time, effort and capability to work on the mod. The best remedy is not to 'not use the mod', the best remedy is to educate yourself in C# and invest a lot of time and effort to fork and contribute effectively towards development. Please don't use such statements when talking about mods in this way as you are actively turning potential developers away from contributing.
  10. Poodmund
    And the reason its showing 11,250,000 as the Vessel Power is because its only considering the antenna power for the combined vessel power as 5,000,000 each, which resolves to 5E+06*(2)^0.75 = 8,408,964 which is less that 5E+06 * 2.25 (Range Modifier) = 11,250,000 ... so it thinks that just the 1 antenna is more powerful than both of them combined. It would take 3 HG-5s at the standard power to eclipse the power of 1 HG-5 with a range modifier of 2.25. @MalevolentNinja, try adding a 3rd one on there and see if the Vessel Power finally updates to this number: 11,397,535 (this number being the power of 3 HG-5s with no range modifier applied). If so, then it confirms my testing and suspicions.
  11. Poodmund
    It seems to have fixed the issue of the single best antenna power being displayed using the Range Modifier value but I've spotted that the range modifier value is not being used when calculating the total vessel power when multiple antennas are on a craft and is still using the non-Range-Modifier-modified power values. I spotted this by changing the Range Modifier to 2.00 which would change the Communotron-16's power from 500,000 to 1,000,000 and this antenna has a combinability exponent of 1 so the power adds up non-lossy. I put 1 Comm-16 on the vessel and it displays the vessel power as 1E+06 which is correct with a range modifier of 2.00, then added another Comm-16 but the power doesn't change (it should have increased to 2E+06 but stays at 1E+06), then I added another Comm-16 and the power displays as 1.5E+06 (instead of 3E+06). This would suggest that its using the range modifier multiplier when considering the strongest single antenna but not when calculating the total, combined vessel power. See screenshot below: EDIT: Just for clarification, this issue persists across direct antenna and relay antenna.
  12. Poodmund
    The total power of a combination of a feed and a dish is the product of the antenna's feed scale and the sum of the power of feeding antenna and the reflecting dish i.e. Feeding Antenna Feed Scale * (Feeding Antenna Power + Reflecting Dish Power). When you have a combination of antennas on the craft all feeding into the same or multiple reflecting dishes and want to know the total power of the vessel, you then consider the combinability exponents of each feeding antenna and use the traditional CommNet calculations. It can get rather complicated, I updated the CommNet Calculator Google Sheets doc to handle NF:Ex mechanics on the 'NF:Ex (Reflectors) Calculator' sheet which may help you visualise what is going on: https://docs.google.com/spreadsheets/d/1qIgFB8OXnlgpPCGsxv7JYUYQq5O671IcZXpumVaStek
  13. Poodmund
    The Poodle had around 5 times the thrust of the Terrier so there is quite a large void here in this regard which you could slot another engine into whilst changing it's specific impulse and/or mass to balance it out. When considering engine part performance you kind of have to disregard to Wolfhound as it is so anomalous and an outlier in its performance status compared with all the other engines, it's more comparable with the LV-N than any other bipropellant engine.
  14. Poodmund
    I think a lot of the reasoning behind people voting for it to be a different part is so that it can have different performance values.
  15. Poodmund
    Its pertinent to appreciate that power is a unitless quantity and does not specify range, as MalevolentNinja said above, range is the sq.root of the product of the total vessel power of point A and total vessel power of point B. When both end points have the same total vessel power then, yes, the range will coindidentally be the same as the power. Also, in the persistent.sfs save file you can change the Range and DSN Modifier values to specific float values. Search for 'Range' and it should show up. Its easy to set it to something like 2, 5 or 10 to test with.
  16. Poodmund
    No worries, Linux... these kind of things are really frustrating I know. It may be worth pinging @Li0n also (even though I know they've moved on from the mod) as a nugget of wisdom may be all it takes.
  17. Poodmund
    This commit may help: https://github.com/Li0n-0/Antenna-Helper/commit/3fc2915dafa72c7d8fff726deacdcce8df5e43a8
  18. Poodmund
    I can confirm the issue persists on KSP 1.7.0 through to KSP 1.9.1 with all the respective versions of Antenna Helper and dependencies built for those versions. So the issue has been around for a while. EDIT: Gone back as far as 1.4.3 and it still isn't working correctly.
  19. Poodmund
    I also went through this and Flart's mod and I came to the same conclusion that it doesn't seem to be doing anything inccorrect but something may have been changed in KSP's Assembly library during the 1.8 or 1.9 update as I'm pretty sure this used to display properly. 'antennaPower' may now be factoring in the Range Modifier itself internally? Coincidentally Linux, my CommNet calculator (https://goo.gl/Wn03VL) was what Li0n used to resolve the mathematics behind this mod which agrees with what MalevolentNinja has shown above. EDIT: I'll go back through previous versions of KSP to see what differences there are.
  20. Poodmund
    Yeah, if you want a fix for that to confirm the issue, try out this mod which resolves all of the broken UI displays with regards to CommNet: Theres been an issue raised about it for 2 years with no recognition... https://bugs.kerbalspaceprogram.com/issues/19996
  21. Poodmund
    This is most definitely the case. Individual Effective Antenna Power = Individual Default Antenna Power * Range Modifier
  22. Poodmund
    No, something funky is going on here. The 'Range Modifier' doesn't actually modify the range, per se, of connections, it is just a multiplier coefficient that is applied against antenna parts' power rating. So for an RA-2 antenna with power of 2E+09 and a 'Range Modifier' of 2.0, the power of that antenna should become 4E+09 not 8E+09 as shown in the screenshot above. EDIT: Tested the issue myself and I am seeing the same thing. With a Range Modifier of 2.00 it is resulting with a vessel power of 8E+09 which is doubled. Interestingly, if you chose an antenna part for a target instead of a vessel, you can see that the part list option is correctly showing the RA-2's power as 4E+09 in the list so I expect the issue is occurring when the total vessel power is being calculated. My guess is that it is calculating the 'true power' of all antenna parts (as it should be doing) by multipling each antenna by the range modifier (as specified in AHUtil.cs) but then its also taking the total vessel power and multiplying it AGAIN by the range modifier which is why it appears to be raising it to the square of the range modifier. I just started to look through the Source Code and GitHub has just gone down. Also, as an aside, the text is becoming mis-aligned when the 'Status' text is wrapping to a new line.
  23. Poodmund
    I was hoping for Poodle_v2_final_final1
  24. Poodmund
    Seen a couple of reports about this and it seems that recently its become apparent that mesh normals affect surface attachment rather than just the raw collider geometry. I've raised an issue about this here: https://github.com/PorktoberRevolution/ReStocked/issues/865 If anyone else spots any parts that may be affected by this, causing issues with surface attachment, please let us know for reference.
  25. Poodmund
    @harelk, follow Blowfish's instructions above to resolve.
×
×
  • Create New...