Jump to content

How to make a ped or bot, attack a player.


Sentineldev12

Recommended Posts

Hi, i started scripting with lua a few days ago... i was trying to make my own zombie script, but i find myself kinda stuck... i was able to spawn the zombies so far, in a specific area etc...

my problem now is that i cant make them to  attack directly to me or an specific person

i tried creating peds with the 'createPed' function in client side, but they dont move, i saw a few post here about using setPedAimTarget and setPedControlState and they just attack when spawn and stay there doing nothing, can anyone give me a tip on how i can make them move or follow an specific person until the person its dead.

 

I also try using slothbot, this works great, only thing i didnt like its that whenever a bot attacks another bot, they start killing eachother any way i can make that they just attack me and in case they attack one of them, they just keep the focus on me. any help would be appreciate thanks!.

Link to comment

Hi, very cool that you started scripting! Good luck with your adventures.

 

Slothbot is a bit complex, and although a bit outdated nowadays, I think you can still use some of the methods it used to control the peds you want to have, in your own script instead of just using the entire slothbot resource (just my advice).

What you need to code the bot AI that follows a player and kills it if it's not dead is a way for it to repeatedly check for that player/players around itself and do certain actions.

What I would do (clientside) is some sort of infinite timer that makes the bot(s) check for nearby enemies and walk towards them to attack them. The reason I'd do this clientside is because you have the following functions that you can use, like you said :D

https://wiki.multitheftauto.com/wiki/SetPedAimTarget

https://wiki.multitheftauto.com/wiki/SetPedControlState

 

I can give you an example if you want, but you should give it a try and ask questions if you find specific issues that you can't solve :) Best of luck @Sentineldev12

  • Thanks 1
Link to comment
10 hours ago, Sentineldev12 said:

i tried creating peds with the 'createPed' function in client side

I would like to add that peds should be created on the server-side and then the syncer of the ped, which can be checked using the client-side isElementSyncer function, should control it, for example using the methods as described by FernandoMTA. I did do experiments many years ago when the peds still had to be controlled using old functions. From my experience I can say that creating a bot system is very complicated. Also there is no access to pre-made API about navigational meshes or the math surrounding it so the design does require actual work. I am not sure if this project is a good idea for a self-proclaimed beginner like you.

Edited by The_GTA
  • Thanks 1
Link to comment
3 hours ago, FernandoMTA said:

Hi, very cool that you started scripting! Good luck with your adventures.

 

Slothbot is a bit complex, and although a bit outdated nowadays, I think you can still use some of the methods it used to control the peds you want to have, in your own script instead of just using the entire slothbot resource (just my advice).

What you need to code the bot AI that follows a player and kills it if it's not dead is a way for it to repeatedly check for that player/players around itself and do certain actions.

What I would do (clientside) is some sort of infinite timer that makes the bot(s) check for nearby enemies and walk towards them to attack them. The reason I'd do this clientside is because you have the following functions that you can use, like you said :D

https://wiki.multitheftauto.com/wiki/SetPedAimTarget

https://wiki.multitheftauto.com/wiki/SetPedControlState

 

I can give you an example if you want, but you should give it a try and ask questions if you find specific issues that you can't solve :) Best of luck @Sentineldev12

Hmm, im gonna give a try. Probably if i have questions ill come here. Thanks for the advice! :D

1 hour ago, The_GTA said:

I would like to add that peds should be created on the server-side and then the syncer of the ped, which can be checked using the client-side isElementSyncer function, should control it, for example using the methods as described by FernandoMTA. I did do experiments many years ago when the peds still had to be controlled using old functions. From my experience I can say that creating a bot system is very complicated. Also there is no access to pre-made API about navigational meshes or the math surrounding it so the design does require actual work. I am not sure if this project is a good idea for a self-proclaimed beginner like you.

Hmmm i see, yeah probably, this is mostly for self learning. mta was one of the games i played the most. now that im into this programming world, would like to try my own thing haha! thank for the advice :D

1 hour ago, Tut said:

Moving this into the scripting section!

Sorry. i was kinda confuse making the post :(

  • Like 1
Link to comment

I'm a bit late to the party, but...

On 29/12/2021 at 15:43, The_GTA said:

I would like to add that peds should be created on the server-side and then the syncer of the ped, which can be checked using the client-side isElementSyncer function, should control it, for example using the methods as described by FernandoMTA.

Shouldn't the client side part of controlling be done on all clients? In other words, are peds' actions synced? I don't know how much it has changed since I last scripted peds, but I was under the impression that it's just placement and velocity that are synced, but actions are not - in which case every client, not just the syncer, should set the control states and other control-related parameters, otherwise non-syncers will see the ped changing position but not actually performing any actions.

Link to comment
2 hours ago, Reyomin said:

I'm a bit late to the party, but...

Shouldn't the client side part of controlling be done on all clients? In other words, are peds' actions synced? I don't know how much it has changed since I last scripted peds, but I was under the impression that it's just placement and velocity that are synced, but actions are not - in which case every client, not just the syncer, should set the control states and other control-related parameters, otherwise non-syncers will see the ped changing position but not actually performing any actions.

The enter-and-exit of vehicles does require a check of the syncer as described by the wiki documentation of the setPedEnterVehicleFunction. The setPedControlState clientside function does not have such a remark but to properly synchronize the peds it is absolutely recommended to let only one computer do the calculations. Otherwise you might get different ped positions and states depending on client FPS, timing (ping) and user interaction with the ped. You don't have to make your own syncer-registry in this case: simply reuse what MTA has assigned anyway.

Edited by The_GTA
Link to comment
1 hour ago, The_GTA said:

The enter-and-exit of vehicles does require a check of the syncer as described by the wiki documentation of the setPedEnterVehicleFunction. The setPedControlState clientside function does not have such a remark but to properly synchronize the peds it is absolutely recommended to let only one computer do the calculations. Otherwise you might get different ped positions and states depending on client FPS, timing (ping) and user interaction with the ped. You don't have to make your own syncer-registry in this case: simply reuse what MTA has assigned anyway.

But my question was, are ped actions resulting from setPedControlState, setPedAimTarget and several other functions even synced? It's understandable that setPedEnterVehicle needs to be synced, because it directly involves other elements. But setPedControlState directly involves just the ped, so is it still synced? If it is, then you're right about why using isElementSyncer would be necessary, but if it's not, then ped state will be inconsistent between clients either way, and all clients should control the ped to make it more consistent, otherwise, as I said, the ped will appear to teleport around while standing still, to everyone but the syncer.

Link to comment
1 hour ago, Reyomin said:

... but if it's not, then ped state will be inconsistent between clients either way, and all clients should control the ped to make it more consistent, otherwise, as I said, the ped will appear to teleport around while standing still, to everyone but the syncer.

You are right in that assessment. The ped does teleport around. You have to still call setPedControlState on every client to synchronize the ped actions/animations. I just did a test with a friend of mine on my server.

I was of the impression that this behaviour was changed but nah. ^^ Wrong impression given my reading too many incomplete MTA wiki docs.

I have amended the wiki documentation of setPedControlState to reflect this observation.

Edited by The_GTA
  • Like 1
Link to comment
4 hours ago, The_GTA said:

You are right in that assessment. The ped does teleport around. You have to still call setPedControlState on every client to synchronize the ped actions/animations. I just did a test with a friend of mine on my server.

I was of the impression that this behaviour was changed but nah. ^^ Wrong impression given my reading too many incomplete MTA wiki docs.

I have amended the wiki documentation of setPedControlState to reflect this observation.

Well, that clears it up. I thought there was a possibility that it was changed, but I wasn't thinking of it as something that's supposed to be changed. I would argue that making our own data to describe tasks and using it on all clients independently can give better results than having MTA sync the peds' actions, because high level actions allow more accurate predictions than low level ones. Think "follow a particular element" versus "accelerate and steer right". The former can give acceptable results with much longer sync intervals because the latter will usually become obsolete quickly. This is in contrast to player sync, where primitive actions are the highest level actions we have, which I guess makes player sync a more complicated subject than ped sync.

Edited by Reyomin
  • Like 1
Link to comment
57 minutes ago, Reyomin said:

(...) The former can give acceptable results with much longer sync intervals because the latter will usually become obsolete quickly. (...)

I like the idea that MTA would not greatly disturb the sync actions performed by your own Lua logic. The position syncing is the most primitive approximation being performed but I guess you'd want to do that anyway. Due to the network delays no sync action can perfectly describe where the ped element should be. But having the freedom to find best practices in "high level actions" is certainly a great idea.

  • Like 1
Link to comment
18 hours ago, The_GTA said:

I like the idea that MTA would not greatly disturb the sync actions performed by your own Lua logic. The position syncing is the most primitive approximation being performed but I guess you'd want to do that anyway. Due to the network delays no sync action can perfectly describe where the ped element should be. But having the freedom to find best practices in "high level actions" is certainly a great idea.

Perhaps the distinction should be drawn between what can only be controlled by scripts and what can be changed by other means. Position can change because of physics, which is why we want MTA to sync it, but control states cannot be changed by anything but scripts. If the script fully controls them anyway, it makes sense to let it take care of making them consistent. Also, there would be a benefit in syncing some other things besides position (assuming they're not synced already), such as whether the ped is knocked down. It's another thing related to physics that can make a big difference.

  • Like 1
Link to comment

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...