Sigma88

here's a temporary fix of TR for 1.3 SASS can now be experienced fully

tested it a bit and seems to work well, thanks a lot if you need any help feel free to ping me!

can we see config and screenshot?

yes I can confirm the last link you posted works for me, I might add that I like the new naming scheme

no, it must be a number... stupid hands with 5 fingers, if we had 6 all these issues would not sussist

could you send me the mm cache file?

thanks! are there any preset bases I could try load with this?

try adding offsetDay = 1, it should be 1 by default but maybe there's something going wrong @Kronometer { %DisplayDate { %PrintDate { %offsetDay = 1 } %PrintDateNew { %offsetDay = 1 } %PrintDateCompact { %offsetDay = 1 } } } also, I found out what was going wrong with your install, you have dayLengthMultiplier = 1.66666666666667 and that 7 is what is destroying stuff I think I will add a parameter to round year and day values to the nearest second

I get 404 from that link

I edited my post use the edited one since I don't think the year value is defined by default, which means the @value will fail

@Kronometer { %CustomTime { %Year { %value = // year length in seconds } %Day { %value = 36000 } } }

I have no idea about transfer window planner. But I think most of the code works handling seconds, it's just wheb the time is displayed that years and days come into play So the changes should be pretty easy if they are required @OhioBob it just occurred to me Try hardcoding the year and day values and just set useHomeYear/Day to false

there are 2 options, there are some hardcoded variables used by KSP to define year and day if the mod in question uses those, it might not have worked with ClockFixer since we didn't change those numbers, we fixed that in kronometer and now mods that read those variables work correctly with Kronometer (like KAC) if the mod in question uses its own hardcoded numbers (eg. it just assumes a day is 6hrs) there's nothing we can do about it, they'll need to change to use the stock values if they want to be compatible with Kronometer

both leap year and stock do that the difference being that, since your last day is 0.000000001% too long, it would be cut by leapyear, going to next year with that much remainder the stock clock would be the best option for you since it will just ignore the carry over and restart from year 2 day 1 the problem being that after a certain number of years you get the carry over summed and it could offset the time of day with the position of the sun in the sky of course being that the carryover for you is so small, you might get awat with that I'll add an option to maintain the stock math for now, while I find a solution to to the rounding errors

I don't know, I will need to test this further with your cfg you should get every year starting with day 1

the code is the same, it might just be that the rounding errors with the wrong values SD was using were falling in your favor

it looks like a rounding error to me, sadly there's very little I can do to prevent that, you will need to check the numbers with kittopia, see what gets rounded badly, and manually fix the cfg untill you get the correct approximation right now for example, rotation period of gael is 36000.0000000001 you can fix that with a mm patch that loads after SD, sadly that's a limitation that I am not sure I will be able to fix, I might try some shenanigans later to see if I can get it to work better by forcing an approximation of the approximation

Ugh Yeah I need to know which values ksp is getting You don't need to share much, just radius, geeasl, gravparameter and mass of ciro (whatever of those you have) And sma of gael

Could you upload the mm cache file and the cfgs for ciro and gael?

erm, squad changed the values of G and g like a year ago from 6.674e-11, 9.81 to 6.67408e-11, 9.80665 Somehow I never noticed that SD was still using the old values so that might be your issue you should try with the latest SD that has those values fixed >_>

just wanted to let you know that I have been trying TR on 1.3 and it seems to crash when going EVA I've started looking at the code to see if I can fix it, but if someone with more knowledge on TR source code is already working on it, feel free to contact me, I'm happy to help testing and stuff...

there is a small problem with Texture replacer at the moment which means it cannot be used on 1.3.0 (you can use it, but the game crashes if you try to go EVA) so to get the full experience you'll need to wait for TR to be released for 1.3.0

yup, my bad it's fixed now

@Ger_space I've been trying KK with Kerbin Side Complete Continued (just the KSCUpgrades) but I can't get any statics to spawn past 0.9.9.6 is this expected as a result of the changes introduced in 0.9.9.7 or should they pop up? if it's not supposed to do that I can provide logs edit: from reading the last pages it looks like you have a 0.9.9.9 release, but I haven't tried that since It didn't show up when I went on github yesterday

I forgot to mention: Custom flags And Science Reports + Biomes for all the bodies