Poodmund

Members
  • Content count

    596
  • Joined

  • Last visited

Community Reputation

541 Excellent

6 Followers

Recent Profile Visitors

4470 profile views
  1. v0.3.0 - KSP 1.2.2 Compatibility update Let me know if you have any issues. Please read all the information in the README file before playing and give me all and any feedback please.
  2. Paging @sh1pman too... could you guys test out this config and log your results with Kopernicus install when landed on the Mun and also Eeloo if you're feeling troubleshoot'y? https://www.dropbox.com/s/dpoxswj6ix4vwd6/voronoiRemove.cfg?dl=0 Be careful not to use this config file on a proper save as it will alter the Mun and Eeloo's terrain slightly so may ruin your base. It basically removes all the Voronoi based PQS Mods applied to those bodies, which are exclusive to the Mun and Eeloo. Could you test whether you see significant FPS increases with that config running with Kopernicus? Sorry for the slight off-topic posting, RoverDude, but I know you're eager to get this issue resolved too so you can explore OPM/GPP.
  3. I would personally suggest to either create a new part based on an existing model (or approach an existing mod author to use their asset) that can reach the outer planets, to some extent. A re-balance of the existing longest range antennas could be done so that they just barely reach Sarnus. That would give you a good transition point between the parts. On a different approach, a part upgrade could be done to the longest reach antennas way down in the tech tree to increase the power ratings of those antennas so that they reach the outer planets. I obviously don't know how you'd prefer to approach it but my antenna signal strength calculator sheet has the OPM bodies incorporated into it where you could edit the power of existing antennas or introduce new antennas to give you the results you are looking for. This can be found here: Link - Note that you have to create a copy of the sheet to you own account to be able to edit it for you own use. If you would like some input, value suggestions or testing to this nature please just say the word and I'll be happy to help.
  4. I've heard quite a few people complain about this issue on the Mun and its its apparent on Eeloo too but not Minmus it would point to the Voronoi implementation but without logs and numbers to back up the issue then its sheer speculation.
  5. Yeah specifically Minmus and Eeloo. I won't explain why at the moment as I wouldn't want to influence you're feeling of lag either way.
  6. I know this will be a bit of a pain but could you try the same on Minmus and Eeloo and report back on whether the lag is as noticeable on those bodies? @Sigma88, could it be the Voronoi PQS module?
  7. I tried to reproduce this bug as I've seen quite a few people remark on it but I was unsuccessful. I launched a Vanilla 1.2.2 install and launched this craft on the pad, waited a few seconds recording the frame rate and then Quit to Main Menu and closed the game: This was the frame rate I was seeing: Logs can be found here: output_log.txt & KSP.log Then did exactly the same with the latest build of Kopernicus (commit 997693711b4d6d3fbcb1bdf3577eede733a4adda - Feb 28th): This was the frame rate I was seeing: Logs can be found here: output_log.txt & KSP.log I couldn't really see much that was discernible. Can someone that is experiencing this bug/issue please log down some reproduce-able steps and the environment and state they are running the game in.
  8. Host them via http://www.imgur.com and post the link to the album.
  9. I appreciate that the M27 Cockpit has its own system for the docking procedure with cameras being place at the center of the reference part etc, but am I correct in thinking that Navyfish's Docking Port Alignment Indicator MFD module is not available on this cockpit? EDIT: If anyone is interested, I've documented the Docking Procedure using the M27 Cockpit with RPM here: http://imgur.com/a/chUx7
  10. I'm sure there is something in the API that can be called to give relative distance or orbital altitude with respect to the Sun body. On the topic of varying particle emission rate, SmokeScreen implements this for the rocket plume generation and does it relative to throttle value. You can then specify a curve in the config for the increase of rate of emission relative to throttle position. It may be worth looking at the SmokeScreen source code if you're definitely interested in implementing something like this.
  11. Well Plock's apoapsis is 675,150,469,668m and Leto's from GPP is 596,852,300,000m so it really depends on how far out you want them to spawn. @KerbalKomets:AFTER[GPP] @KERBALKOMETS { @kometMaxAltitude = 625000000000 } @KerbalKomets:AFTER[OPM] @KERBALKOMETS { @kometMaxAltitude = 700000000000 } ... for example. EDIT: Also in the parts directory you have the KometTail.txt file listed as a text file rather than a .cfg file? Is this intended? EDIT EDIT: Also is there any opportunity to (I haven't exactly looked so correct me if this is already the case) increase the particle emission with proximity to the Sun and vice versa?
  12. By using the uploaded After Effects file I attached to that tutorial you can "auto-magically' blend in the wrap seam during the terrain forming process.
  13. Unfortunately no as the configs are initiated and cached upon Game Load and the cache is not changed during gameplay unless a reload is manually invoked through the debug menu... even then MM does not have a technique that would allow KSP to be able realise which ring config to load upon an in-game event situation.
  14. *All visual mods for systems that contains multiple bodies with rings. I am currently working on other projects at the moment but if it seems there is to be no progress made on this issue I may have to bite the bullet and only implement the ring features for Sarnus and not Urlum whilst also retroactively disabling rings on Jool if present, which is far from ideal... but thats the way it goes, eh?