|
A couple notes about that code:
First, it should run critical. Why is simple: If not, other NPCs could be created which would go beyond that number. Perhaps it won't matter for the purpose that script was made for, though.
Second, though; that script will only iterate through Mobile serial numbers - not item serial numbers, which are all higher. Serial numbers for mobiles (including PCs and NPCs) start at 0x1, but serials for items start at roughly 1 billion. (0x40000000). If you want to cycle through ITEMS, you would set critical, create an item and get its serial, then iterate from 0x40000000 to its serial. However, even that won't work properly if you have a large and long-running shard, which has rolled over on the serial numbers (the serial number is a 32 bit integer, it seems by the way it's been split, so the max would be roughly 0x80000000). If it's remotely possible your shard has rolled over on serial numbers, code like the above would not at all be useful.
Third, there will be massive ranges of serials that do not exist due to item/npc destruction, resulting in lots of wasted effort trying to find objects that don't exist. Depending on what you are doing, why you are doing it, and when you are doing it through, that might not be a problem. But I think that a methodical way of going through all the items that do exist, such as Austin's code, is much better, because it avoids the overhead of trying to find literally millions, tens-of-millions or even hundreds-of-millions of items that do not exist.
And then, let's go back to that sleepms() thing; this is again why sleeps are a BAD idea in this type of script: You really need to run this sort of thing critical - get it done fast and have NOTHING else going on at all on the shard in the meantime.
A shard can easily go through, say, 200 million item serial numbers in a couple of years. How can I be so sure? Because I've seen it myself, first hand. If you use something like the below, and cycle instead from 0x40000000 to the last serial, and you have 200 million items to go through, with a sleepms(250) on each item, let's do some math:
200,000,000 items *0.250 seconds/item = 50,000,000 seconds of sleeping, alone (not counting actual code running, nor scheduling time)
50,000,000 seconds = 833,333.33... minutes
833,333.33... minutes = 13,888.88... hours
13,888.88... hours = 578.703... days.
So, let's be clever and reduce it to only sleepms(1). Those who know anything about this sort of thing know that you'll always get a much longer sleep than 1 ms from this - more likely you'll get something from 2-10ms, with a good round number being 3ms, depending on your system. For the sake of argument, let's aim right at the bottom of that range and say you'll get an entirely perfect outcome every time of 2ms of actual delay. To get our final number then, we simply divide our last result by 125:
578.703... days / 125 = 4.629... days
So... assuming that code ran perfectly, the sleeps alone on even a small shard that's been running a couple years would take over four-and-a-half days. That's not even including the actual code running.
|
