Warp error in KSP V1.1.3

[Efratror]

When i want to set warp like so: SET WARP TO 1. in version 1.1.3 of KSP

kOS give's me the following error:

Method not found: 'TimeWarp.SetRate'. (Cannot Show kOS Error Location - error might really be internal. See kOS devs.)

the WARPTO command works just fine.

[hvacengi]

That's odd. I had been testing through experimentals with a script that uses warp and hadn't observed this issue. It looks like the method still exists, but they added an optional parameter which changes the signature (even though the compiler doesn't complain that there is an error). Must have been a later change.

[Dunbaratu]

Is the additional parameter an optional one with a default value defined? If so then that can explain it. Kerboscript implements defaulted arguments by having the call-ee count the number of args and supply the missing ones itself. But it can do that only because of the arg bottom marker on the stack at runtime. As I understand it, being a compile-time bound language, C# implements defaulted arguments by putting the responsibility on the other side. It's the call-er, not the call-ee, that is responsible for them. When you write foo(a,b); for a method that really had the signature foo(a,b,c) with c being defaulted to 1, the compiler transforms your call foo(a,b) into foo(a,b,1); for you. The call-ee does nothing special. It just expect 3 arguments, period. It doesn't know whether arg c was =1 because it got defaulted or because the caller explicitly said it.

So even though the compiler doesn't claim it cared about the difference, it really does. It builds a slightly different version of the call when it sees the defaulted parameter there in the signature. If you use an older version of your compiled code (i.e. the released kOS.DLL), it's still trying to call foo(a,b) without the ,1 part, and foo doesn't do the work of defaulting the =1 for you. It expected the calling code to do it.

[hvacengi]

That's correct. It's an optional default parameter. Which is also why I didn't run into this in testing, because I didn't test our 1.1.2 release directly, I just compiled the 1.1.2 code against 1.1.3 dlls. It means it's an easy fix, but I think we're so close on our next be release that I'm reluctant to do a third "partial" release for KSP v1.1.x

[adamkoncz]

Do you have a timeline when this will be fixed? Pretty much all my scripts stopped working because of this bug.

[dewiniaid]

@adamkoncz I believe it'll be fixed with the next major release, which I believe has an ETA of "soon". The patch hit in the middle of the actual release cycle. (Since it only requires a recompile, I'm surprised an unofficial build hasn't hit the forums yet.)

[hvacengi]

I debated about doing some kind of a "unofficial development" release, with the same version number just re-compiled. But that's complicated with our git workflow (even a pre-release needs a tag I believe) and anything official would require us to advance the version number. Since that is essentially what we did for the last 2 releases, we'd like to really push to actually get all of these new features out the door. We've done a lot of work since releasing v0.19.3, but users have only seen the bug fixes and compatibility updates.

Soon is most definitely the target. It all depends on our timing.

[kosstarter]

I have the same error.

[Efratror]

With the release of V1.0.0 Release Candidate this bug is fixed. So I will close this issue.