Official Game Feedback
-
With this. Just remember to make a Brushes folder where your powder.pref is (or powder.exe if you don't know where your powder.pref is); last time I used this it didn't do it by itself. Never mind, it does do it by itself now.
Edited once by LBPHacker. Last: 6th Oct 2018 -
Ctrl + shift + right clicking on any element of GoL deletes all connected GoL elements, even if they aren't of the same type. Not really a big issue though
Edited once by Killedbydeth2. Last: 20th Oct 2018 -
-
Suggestion: can_move[moving type][type at destination] = 4 means particle is eaten
https://github.com/ThePowderToy/The-Powder-Toy/blob/master/src/simulation/Simulation.cpp#L2183-L2187
Edited once by suibian. Last: 25th Dec 2018 -
@suibian (View Post)
Hmm? What do you mean?
The comment says "3 = Varies, go run some extra checks". There are special if statements for every element with can_move = 3. It is invalid to put 3 for a can_move value unless there is special handling here: https://github.com/ThePowderToy/The-Powder-Toy/blob/master/src/simulation/Simulation.cpp#L2338-L2394
Particles like VOID can already handle stuff like being eaten. It has a can_move value of 1 (swap places), but there is special handling here: https://github.com/ThePowderToy/The-Powder-Toy/blob/master/src/simulation/Simulation.cpp#L2587-L2596
If anything, we could add a can_move value of 4 to mean eaten. But it makes no sense to add it to 3 when 3 is already used for something else. -
Because can_move value of 1 no longer to means eaten.
Edited once by suibian. Last: 25th Dec 2018 -
@suibian (View Post)
I linked the lines of code used by VOID to mean "eaten". VOID is the only element we have that eats elements with no other conditions. And actually that's not even true, VOID uses can_move of 3 and then changes it to 1 or 0 depending on whether that element has the same type as VOID's ctype (if VOID's ctype is set).
The other elements which eat stuff on can_move=1 are VACU/BHOL and VENT/WHOL. These also have special logic for increasing their own temperature when heat simulation is enabled.
So this means no elements at all would be able to take advantage of can_move = 4. So there is no reason to add it. -
I think if has Lua element, can_move = 4 to making simulation faster.
-
@suibian (View Post)
You're technically correct. It would help with certain Lua elements. But I think it's unnecessary to add a feature that maybe one or two Lua elements ever would use. Lua elements are always going to be slow. I've made a powered void element before in Lua with no problemsEdited once by jacob2. Last: 27th Dec 2018
