I know from experience that only the 16 least significant bits of tmp2 are saved, i.e. its remainder when divided by 65536 (rounded toward negative infinity). In other words, a multitude of values will get turned into, say, 3 when you save your simulation, including 3, 65539 (3 + 65536), 131075 (3 + 2*65536), -65533 (3 + -1*65536), etc.

Your experience with QRTZ adheres to this but with CRMC it doesn't (and I couldn't get it to save as 65496 unless I tried to save CRMC with a tmp2 of -40 (which is 65496 + -1*65536) or something similar. This is most likely not something that will be fixed because it involves changing the save format. You'll just have to try to get by with values between 0 and 65535 :/

As for tmp, all its 32 bits are saved so I don't see why it would misbehave for you. I couldn't get it to misbehave anyway, and you don't seem to have pointed out any issue with it either, beside in the title.