While is so fast than itemcount.[LUA]

[jujruer]

Helo guys.
I want to make this simple thing.
I have some gps in my depot, platinum coins in one backpack and crystal coins in another.
I try to move an certain quantity of gps to middle of depot.
But when i debbug my code, the while is so fast, and itemcount give me a wrong count.
I make my itemcount to count into 'browse field'
My code is this.
When i debbug without the (wait) i get this.
Example:
Gold to move is 1 crystal coin and 80 platinum coins
when i print, i get this

The total to move is 18k

14:04: 1
14:04: 1
14:04:
14:04:
14:04: 80 // quantity to move
14:04: 80 // while move my item and itemcount can't count my item in 'browse field', then return the same quantity
14:04: 50 // Now itemcount can read my quantity in 'browse field' and return certain
14:04: // Now is nothing to move

if this occur i will move to 'browse field' 23k. and it's wrong.
This occur because i have only 30 platinum coins in my first slot of backpack , and the bot move 30 platinum first and after move the rest.

for i,v in ipairs(gold) do
   while itemcount(gold[i],field1)~= tonumber(g[1]) and itemcount(gold[i],field1)~= tonumber(g[2]) do
       if(gold[i] == 3043) then
          local cc = tonumber(g[1]) - itemcount(gold[i],field1)    // this decrease the total to move but is slow, if =0 then break
               if(cc<=0) then
                   break
               else
                   moveitems(gold[i],crystalbp,ground(posx+1,posy+1,posz),cc)
               end
           //wait(400) if i put this wait this work fine, but my code get an bug, and people can abuse.
       elseif(gold[i]==3035)then 
          local cp = tonumber(g[2]) - itemcount(gold[i],field1)   // this decrease the total to move but is slow , if =0 then break
               if(cp<=0) then
                   break
               else
                   moveitems(gold[i],platinumbp,ground(posx+1,posy+1,posz),cp)
               end
           //wait(400) if i put this wait this work fine, but my code get an bug, and people can abuse.
       end 
   end
end 

[Blequi]

if I got it right, you are trying to write a dice script for iBot or WindBot and you are having problems transfering gold when a player wins. You are affraid of these "wait" due people cheating on your system.

Considering the thread title, one of the possible reasons your while is "faster" than itemcount function may be due the bot's internal function to read backpacks content. The bot owner could have setted an interval (ex: 100 ms) to update backpacks content rather than to read it on demand.

Ex: if you call itemcount(...) with same parameters twice in a timespan shorter than 100 ms, the bot could return the same value, because it's updating just in interval of 100 ms.

If the bot's internal was coded the way described above, you haven't a good way to update it, because you're limited by the bot's internal functions and this busy wait won't help. In other words, it may be a bot fault, not your fault.

However, I can give a few hints related to the code itself.

Hints

• Chances are that your CPU usage will increase considerably using this busy while to wait for changes. You should consider at least a "wait(1)" in between.
• Use variables to store your data instead of pasting it everywhere like these itemcount(...).
• Probably ground(...), tonumber(g[1]) and tonumber(g[2]) can be moved out of the for-block to a variable.
• v = gold[i], by definition if you won't change it, but the use of "v" is faster, because it already contains "gold[i]".

[Blahhh]

As blequi says, you are most likely limited by the bot you are using. The bot probably maintains a data structure containing client information, which is updated in intervals. itemcount[ID,field] reads the values stored inside the bot data structure (which may be outdated) and not directly from the client

[wgrzelak]

I know from personal experience that you can't read data up to date from client, it must take a while a few milliseconds.

[jujruer]

I will made different ways to use this code, move from an location first and after to browse field.