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.

Are you changing enemy->Tile or enemy->OriginalTile?

I don't touch enemy->Tile in the script, only enemy->OriginalTile.

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.

Quote:

---

Originally Posted by Tamamo

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.

Yeah it should be that way anyways.

Flagging this as 'not a bug', given that it's intentional behaviour.

@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. ;)

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.

Quote:

---

Originally Posted by Tamamo

@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.

@ZoriaRPG
Good point.

Actually weapons use the wooden sword sprite as null. I know that for a fact. >_>
And items use -1. "Rupees is 0 which is because of the dummy item behavior shops use i think" Right @Gleeok ?

Quote:

---

Originally Posted by Tamamo

@ZoriaRPG
Good point.

Actually weapons use the wooden sword sprite as null. I know that for a fact. >_>
And items use -1. "Rupees is 0 which is because of the dummy item behavior shops use i think" Right @Gleeok ?

---

It would sure be nice if 0 was uniformly NULL, but that may break some things, notably items. I suppose Sprite 0 might be fixable, but if people rely on it...meh.

@ZoriaRPG
I wouldn't change any of null identifiers. Cause knowing ZC, it would break the indexes, aswell as something else.

Quote:

---

Originally Posted by Tamamo

@ZoriaRPG
I wouldn't change any of null identifiers. Cause knowing ZC, it would break the indexes, aswell as something else.

---

Right. I think we're pretty much stuck with a mash-up of what values are considered NULL. It's a real pain for new users, but after a while, you memorise all of them. It would just have been nice if everything was uniform, but I need more fingers to count how many things changing these would break. Any additions though, should use 0 for NULL. It most matters in ZScript return types, as that way, NULL also translates to False, whereas with those -1 returns, you need to read specifically around numeric value sets.

I think items might actually be 0 too, might be something else that determines if an item is on screen or not. (special item has this so it would make sense)
I can't think of anything else with a none identifier other then that where something else is 0.

It just doesn't make sense to me that anyone would program a NULL value as -1. Because that would return true.

Quote:

---

Originally Posted by Tamamo

I think items might actually be 0 too, might be something else that determines if an item is on screen or not. (special item has this so it would make sense)
I can't think of anything else with a none identifier other then that where something else is 0.

It just doesn't make sense to me that anyone would program a NULL value as -1. Because that would return true.

---

The screen index for items starts at 1, for their pointers; but the item IDs start at 0.

I agree about -1. That's exactly what I was stressing, but that;'s what we have in ZScript. -1 for NULL, providing true returns, which means we need to read if ( n == -1 ) instead of if ( !n ) to determine validity in an evaluation. That little hiccup gives people a lot of trouble. DMap screens, and DMap IDs also fall into this trap. Look at the returns in std.zh.