Flickering debug lines

  • Raphi
    25th Jun 2013 Member 2 Permalink

    When using debug mode and if you are in fire display at the same time, you can see lines from a wifi to every other wifi pixel with the same channel when moving the cursor over one.

    However, when doing this in persistent display, these lines flicker somehow, can be seen best when paused and using many single wifi pixels.

     

    edit:

    I found some more bugs: You can go somehow over the maximum pages, e.g. "my saves" I can go to "page 5 of 4". This can only be done with scrolling down with the wheel on your mouse. On the 5. page there is also a NEXT button, but it does nothing.

    Another bug: When going to the next page of stamp browser when not all preview thumbnails are loaded, no thumbnails will be drawn ever again. Just closing and reopening TPT helps. I think this is related to the slow loading of thumbnails bug.

    Bug: when selecting a stamp or pressing L sometimes weird things are displayed before placing the stamp (not in stamp browser):

    -no preview

    -wrong preview (of another stamp)

    -right preview wth a preview of another stamp on top.

    All these can be fixed by rotating the stamp.

    And I have a suggestion: Could the preview of a stamp before placing (not in stamp browser) be rendered with current display modes and (when deco is off) without deco? Try placing a stamp which is drawn black with deco... Or try placing an activated PCLN(PHOT), where some PHOT are around....

  • greymatter
    25th Jun 2013 Member 1 Permalink
    @Raphi (View Post)
    1)Happens due to persistence. Maybe this can be classified as a "bug".
    2)Never noticed that one before.
    3)I just have half a page of stamps so this doesn't happen to me.
    4)This used to happen just after the release of tpt++. But it got fixed and it doesn't happen for me.

    And even I don't like the stamps showing deco while placing, making it hard to place if you have painted it a dark colour.
  • Raphi
    25th Jun 2013 Member 1 Permalink

    Another one: When working long enough, the text input changes: When I want to enter:

    !set type dmnd none

    that comes out:

    !!!!!!!!!!!!!!!!!!!!!!!!sssssssssssssssssssssseeeeeeeeeeeeeeeeeetttttttttttttttttttttttttt                    dddddddddddddddddddmmmmmm

    and so on.

    The repetition rate of keys at text input filed is extremely high then so it fires 10 letters even when pressing the key shortly. Then I have to reopen TPT.

     

    I don't know if others have these bugs, too. I compile TPT myself for linux 64 bit.

     

    @greymatter:

    1) of course it happens due to persistence, because it happens only in persistent mode.

    2) bug http://www.fotos-hochladen.net/view/bildschirmfotolyi95h824j.png

  • jacob1
    25th Jun 2013 Developer 1 Permalink
    I added this to my list of bugs.

    As for the too many pages thing, i'm surprised that's there, I thought tpt++ fixed that bug finally, since it used to happen all the time in the old version (even though it was a very small fix). I'm sure this is a similar small fix too, along with the next button thing.

    The thumbnails not rendering i'll look into, i've seen several people get it before but have no idea what causes it. The thumbnail render just prints "shutting down" and stops working I think. I also know that thumbnails load slow, that does get annoying and makes the two local browsers almost impossible to use with a lot of saves / stamps. There isn't much I can do about that except looking into canceling render requests when you change pages.

    About the stamp thumbnails sometimes getting mixed up / being broken, no idea at all how to fix that or what causes it. I'm not going to try to fix it since I don't understand that part of the code enough to know what exactly it's doing. I know Simon did something once that was supposed to fix it, I guess it didn't work.

    And that last suggestion looks good I guess. But probably only the deco part. When tpt++ came out it used to render them with fire too and this was a few times more laggy than it is now at rendering saves. I disabled it rendering with fire and don't really want to add that back.
  • jward212
    26th Jun 2013 Member 0 Permalink

    on my iron man suit i'm doing with eggy the piston leaves behined the p type silicon and I know it is not mechnical because when i paste a other down it works. But after i save it doesn't work again

  • cyberdragon
    26th Jun 2013 Member 0 Permalink

    wrong thread sir

  • jacob1
    26th Jun 2013 Developer 0 Permalink
    sounds like a particle order issue. Every particle has an index and they are updated in order from first placed on the screen to last placed on the screen. When you save though, it changes the order so that the first particle is the most top (then left) one, and then it updates that top row, then the row below, and all the way down to the most bottom (then right) particle.

    Sometimes changing the orientation helps, or changing it in some other way. It's hard to tell without actually seeing the save.
  • jward212
    26th Jun 2013 Member 0 Permalink

    thx

    If you want to see it go to ID:1201862

  • xetalim
    26th Jun 2013 Member 0 Permalink
    This post has been removed by jacob1: seems unnecessarily mean, we do need the id
  • greymatter
    26th Jun 2013 Member 0 Permalink
    @jward212 (View Post)
    You can embed saves on posts by doing ~SAVEID


    And that's quite a weird issue...
    For anyone checking the save out and don't know which part is wrong, it is the extension on the top left corner on the iron man suit.