Poodmund

Members
  • Content count

    687
  • Joined

  • Last visited

Community Reputation

653 Excellent

6 Followers

About Poodmund

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

4904 profile views
  1. Planet meshes are still PQS based. Check out this presentation from around 30mins 30secs in, it'll explain a lot about how KSP renders it's LOD.
  2. For the sake of the users that follow this thread, would you kindly edit @N3N's posts on the previous page to alleviate this issue?
  3. It seems fine for me. I have locked editing capability to preserve the sheets functionality. Ensure that you make a copy of it to your own Google account so that you have permission to edit it.
  4. At the moment Scatterer auto saves the configs when you open the GUI and make changes... due to the way some of the MM implementation was done it meant that when using some visual packs, the configs would be constantly overwritten with tons of entries for bodys over and over again if you kept opening the Scatterer GUI. I think Blackrack may be planning to turn this behavior off when I last spoke to him about this issue. Also configs can be written with better MM practice to avoid this in most cases.
  5. @Ger_space, its proving very difficult to interact with statics that use the same asset as all the INSTANCES get listed under the same defined STATIC node without unique identifiers to differentiate between each listing. Would it be possible to include a user defined, unique identifier in-game that is listed against each instance so that there is some semblance of hope ( ) when trying to interact with placed assets, possibly something like PQSCity.name? Basically if Kerbal Konstructs used unique names for the PQSCity instances it would be far easier for us to integrate KK into GPP without having to rewrite custom configs for every KSC++ and KSC Floodlight asset that we use... and also again for each rescaled system config that we also support. I feel like @Sigma88 is coming across a similar issue and is trying to jump the same hurdle without success. If its possible to add something along these lines I think it may increase extensibility with other mods/planet packs and could soothe a few headaches along the way.
  6. Well that makes it somewhat simpler. I'll hang out on IRC and wait for a ping.
  7. I can jump on, yeah. The issue with KK assets and SD rescaling is that the assets retain their Long/Lat coordinates... this is the correct behavior and I don't see how this could be changed in any way without unintended consequences and causing more issues. We are personally have issues with the KSC++ and KSC Floodlights spreading out as the body is upscaled (as you'd expect). What I am proposing to do is use the KSC PQSCity coordinates as an origin and find the x,y components of the coordinate offset between assets and the KSC coordinates, then divide the components by the resize factor, then add them back to the KSC origin coordinates to give the new Lat/Long coordinates of that asset. In theory it should work, I just need to write the MM config so that it correctly affects only the assets that we want... shouldn't be too, too difficult. As a footnote, due to them only being over short distances, the body curvature on adds in fractions of a millimeter in error which should not cause problems.
  8. I am trying to solve the issue with assets around the KSC being separated significantly when an upscaled system is used; obviously the distance between the assets increases as the scale factor increases. As I'm only concerned about the assets around the KSC, if I take the KSC PQSCity coordinates as the origin point I can calculate the vector between the KSC origin and any additional asset, giving me the Long/Lat components of distance. By dividing these components by the rescale factor and then adding them to the origin coordinates the result seems to be pretty accurate in giving me the Long/Lat coordinates of where the asset would be required to be placed in the rescaled system to be positioned correctly at the KSC with respect to the stock sized layout. This can be seen here: https://docs.google.com/spreadsheets/d/1nFybNKxZD00OJJzlMiDHhYl9FbVelSSNcxW96RTiDsM/edit#gid=1324233737 I can type in the Long/Lat coordinates of "KSC Floodlight1, type in a Rescale Factor (example of 10x) and it will output the new Long/Lat coordinates. This can be verified by comparing the distances (m) in Column J, they should be approximately equal. However, am I correct in assuming that KK positions the assets by the radialPosition values in the config over the refLongitude and redLatitude values? If so, what do the radialPosition values represent in this case and can I convert Long/Lat coordinates into values for the [0] and [1] keys for radialPosition?
  9. Kerbin is in fact the only body where the rotational period is specified as it's solar day rotational period. It has a Boolean modifier toggled true, solarRotationPeriod, to specify this.
  10. Care to post your output.txt, KSP.log and ModuleManager.cache files for our perusal please?
  11. Seeing as in OPM-VO I pull a few textures from SVE if SVE is installed, I was planning to include configs to check for SVT and if so/if not apply all the necessary configs to ground scatter and textures. I personally have it on the cards basically for a future release, doesn't affect whether you also intend to or not, Galileo.
  12. If you decompiled KSP, you would find no reference to the string, Kerbol.
  13. PSA to those using Rescaled Systems We have been having some dev discussion with regards to the issue with rescaled systems ending the calendar year at times that are not midnight i.e. a calendar year is not an integer amount of days. There have been decisions made that in the next update that the rescale configs will consist of the following with regards to Gael's orbital and body parameters: 1x (Stock Scale) - not changing, values staying the same. Day Length: 6hrs Days in Year: 426d Orbital Period: 9201600s SMA: 13982766706m 2.5x Day Length: 10hrs Days in Year: 404d Orbital Period: 14544000s SMA: 34948895994.9601m 3.2x Day Length: 12hrs Days in Year: 381d Orbital Period: 16459200s SMA: 44742819242.0888m 6.4x Day Length: 18hrs Days in Year: 359d Orbital Period: 23263200s SMA: 89450717932.7214m 10x Day Length: 24hrs Days in Year: 337d Orbital Period: 29116800s SMA: 139887843072.6100m 10.625x Day Length: 24hrs Days in Year: 347d Orbital Period: 29980800s SMA: 148524802065.2240m Basically what are doing is making the orbital period for Gael the exact multiple of the Day Length * Days in Year so that when Gael makes 1 exact orbit of Ciro, it will have rotated exactly the correct amount of days, down to the second, for that period... thus, the in-game time/calendar should not drift and go out of sync. To achieve this we have determined suitable lengths (in hours) for the Gael day length at each rescale level so that it does feel like Gael is spinning around too fast at larger scales and determined the closest amount of full days that Gael can rotate to complete an orbital period... then we are manually calculating the corresponding SMA for that time period. What this does do however is put Gael's SMA at a VERY slight difference to the rescale factor, for example at 2.5x Gael's SMA is something like 2.4994263816883400 times greater not 2.5 but this should not have an effect on playing the game in a realistic approach. tl;dr We are changing the SMA of Gael at the different rescale levels to tie up the in-game calendar time to 1 exact orbit of Gael around Ciro. This shouldn't really affect gameplay at a noticeable level. I just wanted to fully explain this and put the values out there to let everyone know exactly what is going on as a 'warning' for the next update. It probably, should not, possibly, maybe have any effect on saved games.
  14. Should this then warrant a bug report on the tracker?
  15. @JPLRepo, sorry for tagging you but I didn't know who else to ask with some authority on the issue. Could you shed some light on this, please, or if you know who may know better?