60fps are 60fps, which means timers should be the same, shouldn't they?

(And my pc is acutally quite fast, hmn, without fps_max the fps goes up to 700)

I think so unless counter has to be increased by time step...
Having a fast pc is what may cause the fast movement
it doesnt use frame waits in the crowd update.
Its a looped thread ,although i think o should rather
try and code the thread diffrent to use a looped
update with engine wait time ,with the whole loop scripted..
Do you have any idea of the cause of problem? Oh and also
reaching the counter target very fast could prevent movemenz
so perhaps mine takes longer to reach 800?

Sorry, I can't help you, as I never worked with threads (beside in Java)

Thanks rey for looking at it though . Im on my own i gues
unless someyone with more experience than myself
Have any ideas

okay i gave it another shot ,problem i think was using a sleep function
instead of an engine wait i really hope what i came up with to solve
the issue worked ,please be so kind to say no if it did not work !!

thank you 3run and rei for taking time to look at it ,i THINK i got it
im not sure if it will run as it is suppose to on other pc so please
anyone take a look at it and tell me if you would be so kind and
thank you in advance...

They still stuck mate.. Looks like they are moving properly, then they stuck for a half of second (walk animation still playing) and then they move again.. I have no idea why this happens, but in the old examples (making bots walk from one point into an other) worked without that stucking problem. May be thats how you make them walk randomly?
This group of bots stucked for about three seconds, they where just turning around:

Thanks man.my concern were the frame speed diffrence
from my pc to yours. Where mine ran slow but yours fast...
the stuck thing is scripted like that you see sometimes they pick the
exact same random point as a target position and then all those
who picked that point bunch up around it and cant get to a distance of 5 within
that point couse they cant walk through eachother so instead of preventing that
in the script i just added a timer to alter their targets again and again because
i didnt want to code alot extra... but in a game ofcourse you would code to prevent that
this can easily be tested for your own satisfaction by the following.
use one bot and only change total points to something like 500 in avoid.c line 14

to try and resolve any frame update speed i have also
included a non threaded crowd update...wil not upload until
i added more functionality and error checking.
i also have been trying to cope with hmp terrain
and its a biggy because i tried writing to file all the vertices
and triangles ,when i looked into the file i found verticed that were
garbage data so i tried creating a mesh entity for each hmp chunk
and wrote that data to file and still i found garbage in vertices
.i wil continue until i pin down the mistake or problem for hmp

hmp is a naughty thing, in the end of hmp vertex list, you can find separately the shared chunk border vertices, in the same order as standard vertices i.e. starting from the upper left corner, so it could cause problems. some time ago I wrote a function to access them for proper terrain mesh deformation, but not really used it because later I fixed my problems by a DX function, but if you need I can try to find it (hopefully not deleted).
I would be very happy if you could make it also for terrain, I have some simple game idea where I could use your navmesh+crowd system.

I would appreciate your help hmp confuses me