Official Game Feedback

  • LBPHacker
    6th Oct 2018 Member 0 Permalink

    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
  • Killedbydeth2
    20th Oct 2018 Member 0 Permalink

    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
  • jacob1
    20th Oct 2018 Developer 0 Permalink
    @Killedbydeth2 (View Post)
    Not a big issue, but it's probably a simple fix.
  • suibian
    25th Dec 2018 Member 0 Permalink

    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
  • jacob1
    25th Dec 2018 Developer 0 Permalink
    @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.
  • suibian
    25th Dec 2018 Member 0 Permalink

    @jacob1 (View Post)

     Because can_move value of 1 no longer to means eaten.

    Edited once by suibian. Last: 25th Dec 2018
  • jacob1
    25th Dec 2018 Developer 0 Permalink
    @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.
  • suibian
    27th Dec 2018 Member 0 Permalink

    @jacob1 (View Post)

     I think if has Lua element, can_move = 4 to making simulation faster.

  • jacob2
    27th Dec 2018 Member 0 Permalink
    @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 problems
    Edited once by jacob2. Last: 27th Dec 2018
  • phamyen
    28th Dec 2018 Banned 0 Permalink
    This post is hidden because the user is banned
    Edited once by jacob1. Last: 28th Dec 2018