Quote:
Originally Posted by spider661
i did not understand it all saw that it went to 7 but in the code only went to like 3 did not know you added it up.. question is though is it still tied to the player or npc or is it tied to the server or something like that? becuase what im wanting to do is move from one zone to another with player 1 then the npc in zone 1 should read the variable and tell player 2 the zone is in use come back later and then npc 2 in zone 2 should turn off the same variable so that npc 1 will then again let players in without needing to know what npc its reading from or what player got the variable set? because from the code it seems that it always ties it to a player or npc or zone maybe.
|
We're basically working with a bitmask in the options field. The first binary bit is NPCs, the 2nd is Player, and the 3rd is Zone. Since it looks like you would need all 3 to be able to access the global, that would make it 111 in binary. Because binary reads right to left, that would be the same as saying this:
Code:
Option: Zone Player NPC
Decimal value: 4 2 1
Binary value: 1 1 1
So, when you add that up, you get 7. Another example would be just the zone & player: 4 + 2 = 6.
Quote:
Originally Posted by spider661
the code i have working now just simply sets a variable to the database name and value and then calls it based on the name.. not set to anything npc,player,zone wise.
|
That's exactly what quest globals do: set a variable in the database (the quest_globals table) that can be called based on the name of the global. By default (when 0 is used for the option), it is specific to that player, npc, & zone that it was set in, but with the options, it opens up those permissions, just like the permissions on a file.
Hope this provides a little more clarity.
Threaded Mode
