User Tag List

Page 1 of 2 1 2 LastLast
Results 1 to 10 of 16

Thread: Enemy with Tile 0 not drawn

  1. #1
    Keese
    ZC Developer

    Join Date
    Jan 2007
    Age
    34
    Posts
    52
    Mentioned
    27 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    778
    Level
    9
    vBActivity - Bars
    Lv. Percent
    79.01%

    Not A Bug Enemy with Tile 0 not drawn

    If you set an enemy to use tile 0, then it won't be drawn to the screen, even if the tile is later changed through scripting.


    I have a script that creates a new enemy, and then sets its tile, etc. I decided to use a generic "Script" enemy for this, and let the script itself change all its attributes. However, the enemy was invisible until I changed the tile the enemy was using from 0 to a random, other tile. I confirmed through tracing that the enemy->OriginalTile value was correct, as well as its position, even when it wasn't being displayed.

  2. #2
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    Are you changing enemy->Tile or enemy->OriginalTile?

  3. #3
    Keese
    ZC Developer

    Join Date
    Jan 2007
    Age
    34
    Posts
    52
    Mentioned
    27 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    778
    Level
    9
    vBActivity - Bars
    Lv. Percent
    79.01%
    I don't touch enemy->Tile in the script, only enemy->OriginalTile.

  4. #4
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    I took a look at the code just now, here's the reason.

    Code:
        // If they forgot the invisibility flag, here's another failsafe:
        if(o_tile==0 && family!=eeSPINTILE)
            flags |= guy_invisible;
    Enemies by default that use Tile 0 are invisible, it works as a fail safe in case some one forgets to make it invisible manually.

    edit: Note this is initialized in the enemy constructor btw.

  5. #5
    Banned
    Join Date
    May 2015
    Posts
    141
    Mentioned
    34 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    667
    Level
    9
    vBActivity - Bars
    Lv. Percent
    14.48%
    Quote Originally Posted by Tamamo View Post
    I took a look at the code just now, here's the reason.

    Code:
        // If they forgot the invisibility flag, here's another failsafe:
        if(o_tile==0 && family!=eeSPINTILE)
            flags |= guy_invisible;
    Enemies by default that use Tile 0 are invisible, it works as a fail safe in case some one forgets to make it invisible manually.

    edit: Note this is initialized in the enemy constructor btw.
    Thanks for finding out the cause. This should (hopefully) be easy to fixed by putting a conditional somewhere that checks if the tile has been changed.

  6. #6
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    Yeah it should be that way anyways.

  7. #7
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.72%
    Flagging this as 'not a bug', given that it's intentional behaviour.

  8. #8
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    @ZoriaRPG

    Acutely I disagree, whether it's intended behavior should classify it as a bug or not. It should be whether or not it causes problems.
    Last edited by Tamamo; 06-18-2016 at 09:45 AM.

  9. #9
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,817
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,940
    Level
    33
    vBActivity - Bars
    Lv. Percent
    24.2%
    AFAK Tile 0 has always meant to mean NULL in ZC. Another use is setting ffc->Data = 0; for example, although that works slightly different. ZC is weird like that.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  10. #10
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.72%
    Quote Originally Posted by Tamamo View Post
    @ZoriaRPG

    Acutely I disagree, whether it's intended behavior should classify it as a bug or not. It should be whether or not it causes problems.
    Marking it as a non-bug doesn't preclude changing it, but changing it could lead to new bugs. :)

    By this, I mean for quests where people did use tile 0 for invisibility, if any exist, changing this could lead to undesirable behaviour. That said, I don't particularly agree with the design choice of this behaviour, and I'd support changing it.

    We don't have a 'It's a feature' categorisation though, for this sort of quasi-bug topic: I could flag it as 'unverified', but that's not strictly true. What we have here, is another example of undocumented ZC behaviour, and I'm noting it in the docs under npc->OriginalTile. I wonder if there's anything janky like this in *weapon, item, or Link.

    Gleeok is right, in that tile 0 is supposed to be null. I'm sort of in favour of making it impossible to edit the tile, to prevent tilset construction that hinders ZScript tile expectations.

    In this case, a user can utilise a blank tile that is not tile 0 to do invisible enemies, by changing o_tile to TILE_BLANK or to another tile to end an invisibility effect.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social