Why does stamping truncate life to 65536

  • Holly866_668
    2nd Sep 2020 Member 0 Permalink

    When you load a stamp with life 2147483647, the life property is truncated to 65536, but when you copy/paste, you get 2147483647.

     

    Please fix or clarify this.

  • polokus
    2nd Sep 2020 Member 0 Permalink

    @JohnSmith777779 (View Post)

     In that same fashion, negative life DEUT was removed.

  • LBPHacker
    2nd Sep 2020 Developer 2 Permalink
    Copy/pasting doesn't involve the de/serialisation procedure of particles into an actual save file that saving/loading a stamp/save file does. This procedure applies limits to particle properties, such as truncating the life property to 16 bits (which turns all of -3, 131069, 196605, etc. into 65533).

    This isn't considered a problem as life values outside the range [0, 65535] are never actually valid; life is used either as a power multiplier or as a time-to-live value in the vast majority of cases, neither of which make sense when set to such high or low values. Furthermore, these values are unattainable via normal in-simulation means (except maybe via LSNS, but that's a very hacky element) and even if you somehow do attain them, the save format is incapable of storing them.
  • Holly866_668
    2nd Sep 2020 Member 0 Permalink

    Thanks

  • polokus
    11th Sep 2020 Member 0 Permalink

    @LBPHacker (View Post)

     If they're never valid, how did negative life determine whether DEUT had a red color?

  • LBPHacker
    11th Sep 2020 Developer 0 Permalink
    DEUT's colour is calculated as a function of its life, and that function happens to give a result for life values that are considered invalid too. The fact that it does produce an output doesn't mean that that output is valid (I mean, come on it's red :P).
  • JustAPlayer
    17th Sep 2020 Member 0 Permalink

    32-bit integer limit apparently :P

  • LBPHacker
    17th Sep 2020 Developer 0 Permalink
    That is absolutely incorrect, please take the time to read what I said.