Jump to content

NPC traffic (released)


Reyomin

Recommended Posts

Here's a video about the script which I'm working on:

Bots are generated around the players and disappear when they are far. Driving peds stop if there's a player, ped or a car in the front. They also stop when traffic lights are red :)

Edit: new videos of released traffic and path editor scripts:

Edited by Guest
Link to comment

On the client, all peds streamed in are looped through onClientPreRender and their control states are updated, but it doesn't seem to make my PC lag any more than it already does when there are many peds and vehicles around :) On the server, generating peds slows down a little bit, but I know why exactly it does and how to optimize it and this happens because creating elements takes some time, so there's nothing I could do to optimize it :) And the bandwidth is something what i'm not sure about. I store tables with task parameters as element data to sync ped actions. Something like this: {"goToPoint",x,y,z}. Anyway, if something is wrong, reducing traffic density will help. Something is still better than nothing.

Link to comment

Very nice, as far the AI goes, it seems to be better than my attempt.

How did you created the paths? (trying to create a tool that is able to create paths easily was the thing that put my project in the coma...)

As for the bandwidth - I've don a lot of tests in that mater and I'm shore that by default MTA syncs velocity, position and rotation with the minimal interval of about 0,5 sec and max (if there ate no network problems) 2 sec. as long you don't transfer any other data there is no difference between static and moving vehicle...

However to keep the vehicles from "drifting" on remote clients it is necessary to sync the information about left and right control states manually.

The large intervals on witch the data is updated work great if the vehicle is not moving, or moves very slowly, the faster they move, the less accurate is the position, and they start to lag even if the fps is high and the ping is low (speed = 30-40 km/h seems to be good)

In my script I've made it so the bot is only controlled by one client at a time, and the "task data" is only exchanged with the server when some player gets in or out the range (i even found a cheap way to keep the vehicles persistent, synced and moving when no player is in range)

Anyway good lock to You, hope you finch it ;)

Link to comment

I made a separate resource to create the paths. It's the resource which draws all paths in the beginning of the video. Tool creation part is usually the most boring, but I did it in a few days :)

The sync shouldn't be a problem. Because all what is synced by the script is the task data, there's no need to manually sync control states. Clients use task data to set control states and control peds independently, so the result is the same or at least similar for everyone most of the time. When it isn't, it's still OK because MTA synchronizes positions anyway, making all clients see the same.

What I'm not sure about is the server CPU usage. It works fine when I'm alone in the server, but it will probably slow down when there are many players all around the map. My script moves unsynced peds server-side too, and there may be a slowdown if it needs to move a few thousands of peds at the same time. And I just scripted simple collision checking. It prevents vehicles and peds from getting stuck inside each other when they're generated or moved server-side. Although the algorithm is pretty efficient, using it on thousands of peds may be slow.

On the other hand, I'm going to make traffic density and collision checking controllable by the server. Even if such traffic like single player has turns out to be too much for a public server, a few peds here and there will be better than nothing :)

Link to comment

all clients controlling all vehicles may solve the sync problem (but I'm not 100% convinced) but it certainly may be a source of efficiency problems...

Like i said in my script only the client that has the power to send the data about the position of a ped is controlling that ped, so 1 player on the server (or no players, when all need to be handled by the server) is actually the worse case scenario - its like multitasking - more players online - more equally the tasks are divided :)

Link to comment

I see no reason why setting control states on each client would be inefficient. The worst thing it could do is reducing FPS for players if there were many peds streamed in and there was some task requiring heavy calculations. Syncing control states directly, on the other hand, would require additional bandwidth.

Link to comment
  • 3 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...