Poodmund

@JadeOfMaar, @Sigma88, @Drew Kerman, @Galileo & @OhioBob... Seeing as there was discussion of it over on the Kopernicus thread about EVE axial tilt implementation of clouds and how Sigma did it way back with OPMTilt (giving Urlum a 90 degree axial tilt) I thought I'd just share that it is absolutely possible to give EVE cloud layers axial tilt at any degree of inclination. Basically you implement the texture as a cube map, change the rotation axis of the texture to be through the Y axis and then change the Y value in the texture offset to the amount of degrees of inclination you require. Finally you set killBodyRotation to 'True' to stop the precession.

Hi o/ I've added a box on the Antenna Selector sheet for you to be able to edit the System Rescale Factor that should correctly affect the orbital parameters of the bodies in the system. Please note though that many of the rescale mods out there also change the antenna/DSN powers to compensate so adjust the other difficulty settings on the sheets accordingly. Li0n was doing great work on his mod, not sure what the status of it it at the moment though.

@blackrack, the option in the Scatterer config: "autosavePlanetSettingsOnSceneChange = True" is the default setting. What is the benefit of this to a player/end user? Would it be more appropriate to set it to false by default and then let modders toggle it to true if they are doing dev work?

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.

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?

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.

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.

@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.

Well that makes it somewhat simpler. I'll hang out on IRC and wait for a ping.

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.

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?

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.

Care to post your output.txt, KSP.log and ModuleManager.cache files for our perusal please?

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.

If you decompiled KSP, you would find no reference to the string, Kerbol.

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.

Should this then warrant a bug report on the tracker?

@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?

Except for the fact that each Kerbal calendar year, Kerbin will not be located at the same degree of longitude of Periapsis. I think Kerbin falls short of completing an Sidereal Year (Orbital Period) by 0.076064422 degrees every year, meaning that after 4733 years Kerbals would effectively be a whole year ahead on their calendar...?

I have Kerbin's SMA as 13599840256m, a figure pulled straight from KittopiaTech on an otherwise stock install and it also matches the figure listed on the KSP Wiki. Figures from 1.2.9Pre: Sun Radius: 261,600,000m, Kerbin Orbital Alt: 13,388,240,256m. Therefore Kerbin's SMA: 13,599,840,256m Anyway: Kerbin's Orbital Period or Sidereal Year = 2π*SQRT( (13599840256^3) / (667408E-11 * 1.75654591319327E+28) ) = 9203544.618 seconds = 426d 0hr 32m 24.61s This matches to figures that I have found elsewhere; hence the difference. To counter your post, KSP lists the Sidereal Day as 5h, 59m, 9s with the Solar Day being 6hr.

Errr.... that's exactly my point. 426 Solar Days ≠ 1 Sidereal Year yet the clock in KSP rolls over to the next year exactly after 426 Solar Days have elapsed.

In KSP the game clock rolls over a day every 6 hours as it's Solar Day is 21600 seconds. The game clock runs for 426 days and then rolls over into the next year after 426d 0hr 0m 0s have elapsed, giving a Solar Year length of 9201600 seconds. However, Kerbin's Sidereal Year length is 9203544.618 seconds giving a Sidereal Length of 426d 0hr 32m 24.61s as well all know. How does KSP interpret this mismatch in Solar Day and Sidereal Day when it comes to calculating the game clock at the end of every year? We would need a leap year every 11 years or so to catch up. That or Kerbin's SMA should be 13597924514m so that the Sidereal Year and Solar Day align to exactly 9201600s and 21600s respectively. Am I just being dumb?

I came from the Reddit post and just have to agree wholeheartedly... these textures are pretty stunning.

Or adjust the rotational period?

I'll take a look at this over the weekend.