Weird pipe generation

  • phox
    28th Apr 2018 Member 1 Permalink

    Whenever I try to generate a pipe normally, the last two pixels of pipe don't transfer anything. if I delete those last two pixels then the particles in the pipe will be able to exit, but otherwise it just doesn't work

     

    here's an example

     

    https://powdertoy.co.uk/Browse/View.html?ID=2277236

    Edited once by phox. Last: 28th Apr 2018
  • lamyipfu
    29th Apr 2018 Member 2 Permalink

    This is an undiscovered bug, likely caused by the somewhat huge update on PIPE.
    Let's call the leftest PIPE with water as Selfish PIPE(tmp = 0x80600) and
    the rightest PIPE without water as Poor PIPE(tmp = 0xDA100).

    The Selfish PIPE is using the "predefined 1 pixel thick pipe movement(line 476)"

    so it simply try to push its content to the direction pointed by
    DIRECTION_THAT_IT_READS_FROM(value=6[Right]) (line 478).
    But this is wrong! It should be pushing to DIRECTION_THAT_IT_SENDS_TO(value=7-6=1[Left])
    Therefore the Selfish PIPE never even check if the Poor PIPE is empty or not, it does not care.

    It could be the fault of line 478, which try to use DIRECTION_THAT_IT_READS_FROM,
    but it could also be the fault of line 164-165, which defines the position storing DIRECTION_THAT_IT_READS_FROM and DIRECTION_THAT_IT_SENDS_TO
    yet giving strange values to each of them as if the coder mix them up after dealing with a lot of bit representations with no obvious meaning.

    But I am still quite busy so the analysis must ends here.

    Should raise a issue in github and be fixed.

  • Turanic
    29th Apr 2018 Member 1 Permalink

    Not only there are problems with exit, but with PIPE and PPiP in general. Now 1 pixel width pipe is the slowest type of pipe again - just like in pre-Cracker64 era. It basically undoes all the work done with pipe.

     

    EDIT: Oh, it doesn't even hold quartz colors anymore (clay is still ok).

    Edited once by Turanic. Last: 29th Apr 2018
  • jacob1
    30th Apr 2018 Developer 2 Permalink
    Yeah this is definitely a bug. I think I tested single pixel pipes from existing saves, but didn't test creating new single pixel pipe. So only existing saves work.

    @lamyipfu (View Post)
    Thanks for the research, it definitely is because of all the PIPE changes I made to support higher particle IDs. I'm not sure if you are correct though (but I haven't looked into it at all). Existing single pixel pipe from older saves still works, including the exits at the end. I have a feeling the bug here is in the code that initializes the single pixel pipe. That is lines 155-169.

    Edit: I fixed it. There are two bugs, one is that it doesn't properly keep track of which direction to send the particle to, due to a short circuit in the code I added to make it faster. The other is that it looks for the wrong color pipe when deciding whether to change a pipe to a single pixel pipe. I'll commit it and make a new snapshot tomorrow or something this week.

    Edit2: I didn't commit it yet, so it's not in the newly released snapshot, but maybe the next one will have it
    Edited 3 times by jacob1. Last: 3rd May 2018
  • Turanic
    30th Apr 2018 Member 0 Permalink

    I realized that pre-update pipes also don't keep the quartz colors but they do with clay, why? I thought it used to be different.