menu
Downloads Servers Forums Support
Home› General Discussion

Video: Bots gameplay

RobotoRoboto
edited November 2019 in General Discussion
Here are Lagg's bots in action, in the first two minutes I also explained some things with the annotations, turn them off if you find them annoying or leave them on if you want to read some info.

Sorry for the bad video quality...

If you have any questions I will gladly answer them if I can.

Comments

  • BBlakhart
    Do you have any other maps with ai, maps such as dx, scara, the classic tribes map types? I would love to have them. Roboroute would be a good way to teach the ai routes to cap with.
  • BBlakhart
    Roberto, next time you are messing with the ai, set the server to run at realtime under task manager. Even the stock non-Lagg ai are pretty ferocious and do things they never do when the server is not running under realtime. They are even better with Laggs, of course.

    By the way, ms os don't really do realtime, they fake it. Just so you know.
  • Heat KillerHeat Killer
    Never h
    Blakhart
    Roberto, next time you are messing with the ai, set the server to run at realtime under task manager. Even the stock non-Lagg ai are pretty ferocious and do things they never do when the server is not running under realtime. They are even better with Laggs, of course.

    By the way, ms os don't really do realtime, they fake it. Just so you know.
    Never heard of improving the ai by switching to real time. Any chance you could explain? I'm intrigued.
  • BBlakhart
    Try it. Use the stock ai and see how they play first if you can. Then run the upgraded ai. They perform much better and do things they normally don't at lower pri settings. The upgraded ai should be pretty spectacular in realtime but they were better anyway.
  • Heat KillerHeat Killer
    Blakhart
    Try it. Use the stock ai and see how they play first if you can. Then run the upgraded ai. They perform much better and do things they normally don't at lower pri settings. The upgraded ai should be pretty spectacular in realtime but they were better anyway.
    But why is this? Just because you're giving the game more processing power/time which equals better AI combat? Is that why?
  • BBlakhart
    I suspect that it allows the ai to complete whatever task they are tasked with before the timed task routine changes their task. This is what makes them start off on a patrol and in the middle of the map as they are going to the enemy base they turn around and go back, as they have been retasked. Realtime seems to alleviate this. The tasking routine uses weighting of tasks and whatever task is of high weight and needs fulfilled, the closest ai to the task (in armour, proximity to target, and inventory at hand) is commanded to perform that task.
  • Heat KillerHeat Killer
    This makes sense. I have look a little bit into the bots ai from my randomizer mod and from general mapping, and do know about their weights and tasks. The only thing is, being on realtime priority vs normal priority, the game shouldn't run any faster/slower (in regards to time, or simtime). So shouldn't the timed task routine change both scenarios tasks at the same time? Running in realtime shouldn't magically give the bot more 'time' to perform the task, but more 'time' to process it's task. (Now that I just typed that, maybe our definition on time is different which is getting me confused...)
  • BBlakhart
    edited September 2011
    There are at least two time parameters at work here. One is cpu time the thread can run for, wich is allocated by the os and somewhat depends upon the pci or system bus while the other is the time the os allows a thread to run. Up (uniprocessor) systems usualy run at a normally 10ms time slice while mp (multiprocessor) systems run at 16ms or a bit more, probably due to overhead needed by the os to schedule threads in each core. That pci time is the hardware timing and is set by the mobo makers. The os also has a timeslice timer and in xp on up systems you should get 10ms, mp will do 15ms, but again, the os can override that timing. There are registry settings that are employed in each case in M$ os. Sometimes one can edit the registry and go from 15ms to 10ms or whatever the system allows, but often this is ignored by the os and it plods along on the hardware timing. When one fires up a media player the os normally will drop the time slices down to the finest it can, This is why having winamp of wmp running in game usualy gives increased responsiveness in games, games normally use the standard os and hardware time wich is never the finest but a coarser time interval.

    Anyway, then you have the timeslices or quanta given to an app by the os. When the os is set to give most cpu attention to foreground apps, the foreground apps get the most time and higher priority, when the system is set to give background apps more attention, the os gives every app (thread really), not just the background app, a much longer timeslice, and this time slice is equal for all apps, foreground or background. It may also reduce the priority given to inputs from the user that come in over kb and mouse. Server2003 takes this to an extreme, as it actually buffers kb and mouse input while it finishes background tasks such as disk calls and net port calls.

    What realtime does is give every possible timeslice or quanta to the app that has realtime prioity, keeping in mind that no M$ os I know of is actually a realtime os, they just tell you that the app is at realtime to fake you out. So when the server is at realtime, the os gives every possible timeslice it can to the server, and hence the ai get much more cpu time than normal. If you spend much time fooling around with apps at realtime you'll soon see why M$ does not recommend apps be run at realtime. They crash a lot and glitch a lot. I find that "high" pri gives about as much boost as desired, but I must say that t2 ai at realtime, even the stock ai, become pretty vicous.

    So in essence, instead of getting a slice of time for 10ms or 16ms, your thread gets 64ms, or even longer when set to realtime as the os gives that app every possible timeslice that comes available. The issue is that realtime pri preempts some things that need to be taken care of first, such as disk and network activity. This also allows the ai to kick your ass since the game may be having client packets withheld while the ai run amok.
  • ThythThyth
    While sounding nice and scientific, the above is barely accurate. Real-time in the context of OS tasks refers to tasks in systems where there is a deadline imposed on task completion that is measured in real time (e.g. milliseconds). Commodity operating systems are not real time outside of specialized embedded applications.

    There are high precision timing facilities in such operating systems (used for things like media playback), but these are not implemented by manipulating system scheduling timeslices.

    The game internally assumes 32 millisecond simulation frames regardless of what process priority you set it to. The time stamp counter or precision event timer is used to resynchronize the event simulation with real time to compensate for variations in scheduling or execution time of simulation components (e.g. if time spent running scripts takes longer than 32 ms).

    If scheduling affected CPU time allocated to AI processing (say if it were on a real time deadline, which it isn't), the increases in average CPU speed would be a far larger factor over the performance of AI over the lifetime of the game than any process scheduling.
  • BBlakhart
    Try it and see.
Sign In or Register to comment.