[Bug] Float cost & entryCost fields

[PhineasFreak]

The user GordonDry mentioned on the forums that:

After updating

    FAR to 0.15.8
    KJR to 3.3.2
    Kopernicus to 1.2.2-6

and loading KSP during the third part of loading process after the MM patching I got 4 NRE in a row with some other exceptions before:

I never had problems with KW parts before. 

@blowfishpro noted that:

Something is setting the cost to be a non-integer (which is not allowed).  It doesn't look like it's FAR.  Are you sure FAR is the only thing you updated?

E: It's RP-0.  You should make an issue over there. 

Meaning the cost and entryCost fields cannot be floats. RP-0 has been using float values for many parts but it seems that nobody ever used KW Rocketry with it? I did a quick test using MM and a completely stock install with the following patch:

@PART[*]:FIRST
{
    @cost += 0.1
    @entryCost += 0.1
}

The result:

[ERR 19:24:06.160] PartLoader: Encountered exception during compilation. System.FormatException: Input string was not in the correct format
  at System.Int32.Parse (System.String s) [0x00000] in <filename unknown>:0 
  at PartLoader.ParsePart (.UrlConfig urlConfig, .ConfigNode node) [0x00000] in <filename unknown>:0 
  at PartLoader+<CompileParts>c__Iterator62.MoveNext () [0x00000] in <filename unknown>:0 

None of the parts were compiled (not even the asteroids). Changing the values from 0.1 to 1 allowed the parts to complile correctly.

Known parts affected are AIES Aerospace and KW Rocketry but i am sure that there are more.

[jwvanderbeck]

Odd I use and almost always have used both KW and AIES and never noticed any problem getting stuck loading. Is this new?

[PhineasFreak]

That was exactly my reaction when i finally found out that this was the cause of the problems...WTH? IIRC the B9 procedural wings also have costs of "0.1" but nobody ever complained.

Seems that this is new with KSP 1.2.(2). I do not have access to older versions currently so if someone can verify it for older (1.1.3) versions of KSP then please do so.

Edit 1: all RO procedural fairings also use floats. But they load just fine under KSP 1.2.2!

https://github.com/KSP-RO/RP-0/blob/master/tree.yml#L104-L124

Edit 2: and the stock KSP parts:

https://github.com/KSP-RO/RP-0/blob/master/tree.yml#L223-L242

[NathanKell]

Cost always used to be a float. I guess @JPLRepo or @TriggerAu changed it?

…

On May 24, 2017 9:50 AM, "Phineas Freak" ***@***.***> wrote: That was exactly my reaction when i finally found it out...WTH? IIRC the B9 procedural wings also have costs of "0.1" but nobody ever complained. Seems that this is new with KSP 1.2.(2). I do not have access to older versions currently so if someone can verify it for older (1.1.3) versions of KSP then please do so. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#658 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE5-Io8eamYRUUyInxvc36jSswTtbs_Qks5r9F_xgaJpZM4NlYFa> .

[blowfishpro]

Sorry everyone, I totally remembered this incorrectly

cost can still be a float, but entryCost must now be an integer.

Looking back, it looks like entryCost was always supposed to be an integer, but it would have silently failed to parse it before and set to zero. Now it will fail loudly.

[NathanKell]

That sounds correct

…

On May 24, 2017 10:33 AM, "Joseph Wong" ***@***.***> wrote: Sorry everyone, I totally remembered this incorrectly cost can still be a float, but entryCost must now be an integer. Looking back, it looks like entryCost was always supposed to be an integer, but it would have silently failed to parse it before and set to zero. Now it will fail loudly. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#658 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE5-IhAQ_2QA4r7TTAmKyGPUIZFry0LJks5r9GoCgaJpZM4NlYFa> .

[jwvanderbeck]

Odd inconsistency but ok.

[PhineasFreak]

OK, i went through every entryCost field and they all seem OK (all entries have integer values). So, what is actual RP-0 problem?

[JPLRepo]

Part.cost is a float. No change.
AvailablePart.entryCost is an int. No change.

[blowfishpro]

@PhineasFreak it looks like for parts that don't define entryCost in tree.yml, it defaults to 20x the cost. So in the case of e.g. KW1mDecouplerShroud the cost is 1.23 and the entry cost will be 24.6 which is not allowed. I think that bin/yml2mm has to be modified to round entryCost in this case.

[PhineasFreak]

It must be handled by the patch creator itself. Got it.

Should we also add a check to disallow entry cost fields that are floats? Or, can Travis by itself handle this? Just to be on the safe side...

[blowfishpro]

You could certainly check in the case that entryCost is specified and fail the build if it is not an integer.

[PhineasFreak]

@pap1723 Will this still be a problem with the next RP-0 releases? If not then it is time to close this issue.