@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 ?
Printable View
@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.
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.