Official Game Feedback
-
@Rawing (View Post)
I don't think pasting works on macs. (either that or linux, or both)
And the saving thing might be a different problem. When saving, hitting reload just goes back to before it was saved, but it really was saved. I also made a fix for the stamps being on a 4 pixel grid, it needs to be tested more first, and might be in the next version.
@Powdermaster99 (View Post)
Simon things he knows the problem, so it might be fixed soon.
@Videogamer555 (View Post)
there is nothing that needs life to be saved to that many values, and that is why it isn't saved. It hasn't ever been saved that high. In the future, maybe it could be saved higher. Also, I don't think anything saves a negative number except velocity (and temp sort of)
@Tazman12345 (View Post)
in the stamp browser? To me, the stamps look a lot better compared to tpt, the lines are sharper, not blurrier. -
Odd thing is that some interesting effects occur in deut at such high numbers, including producing cold explosions (try setting life for deut to hex7FFFFFFF, then it turns red, and then trigger it with neut, and it makes an absolute-zero, that's 0K -273C explosion). It is part of TPT. It is meant to happen. So if it can be done onscreen, it SHOULD be saveable. You should change it so these cool effects can be saved.
-
Videogamer555:
It is meant to happen.No, it isn't. If you can only make it using the console, and can't make it using the menu or normal reactions, that's often a hint that it isn't meant to happen. The only reason I haven't yet bothered preventing negative or very large life values causing strange behaviour in DEUT is that they don't get saved.
When calculating the temperature increase, the life value is multiplied by 500. This calculation is done using integers, so a very large life value results in an integer overflow, meaning the temperature increase is negative. Negative temperature increase → 0 K explosion.
Similarly, calculating DEUT colours with a very large life value involves integer overflows. In nothing mode with decorations off, compare life=0x2AAAAA00 to life=0x2AAAAAAA. Blue colour value=original blue colour value + life*3. Multiplying 0x2AAAAAAA by 3 causes an integer overflow, meaning the blue colour value is negative and so is changed to zero, hence the DEUT turns from white to yellow. In nothing mode, set DEUT life to 0x2AAAAA00 and toggle decorations - the colour switches between purple and white because blending with the decoration colour involves multiplying the uncapped integer colour values by 255.
-
This post is hidden because the user is banned
-
jacksonmj:
Videogamer555:
It is meant to happen.No, it isn't. If you can only make it using the console, and can't make it using the menu or normal reactions, that's often a hint that it isn't meant to happen.
It can be done with the property tool also. Yes it is meant to be done. -
@Videogamer555 (View Post)
Using the PROP tool or console to edit things can create problems, and isn't always meant to be done. I think PROP was only added to allow for the multiple FILT tmp modes. If you use the console to get values (like negative life) that aren't normally reachable, then that isn't really meant to be done and doesn't save correctly. It would take up space in the saving code to make it save, which is pointless for a glitch only achievable with the console.
I don't think that glitch will ever be fixed though, it's a waste of time to prevent since it's fun to play with. In the future, maybe extra life bytes will be saved, and that will allow the special DEUT to be saved. I would never fix a glitch like that, if it can only happen with the console, it should be kept.
@Shriek (View Post)
that's not really a glitch. It does go slowly at first, and maybe the rate depends on the temperature or something, i'm not sure.
@cyberdragon442 (View Post)
I already replied somewhere else, but it works perfectly for me. -
The property tool also lets you manipulate particle properties directly, so the same advice applies about things made with it.
Please also read the rest of my post, which explains why the odd behaviour occurs. Even the Powder Toy code is not so complex that it relies on integer overflow to produce intended behaviour. The effects of very large or negative DEUT life values are not intentional.
-
@Spektyte (View Post)
In tpt, it was actually limited to just over the screen size, where you couldn't see it.
In tpt++, where tpt was partly rewritten into c++, a limit wasn't added, and that made a serious performance issue with a large cursor (only a few fps at extremely large sizes). I limit was added, but for some reason wasn't made as large as in tpt. I will make it larger later, back to the tpt limit.
