DiSaMe

There wouldn't be such difference unless server-side physics are implemented.

Kenix, you're wrong. engineLoadDFF documentation says second argument must be 0 when replacing something else than vehicle.

The function doesn't itself sync anything automatically. It's how syncing position, velocity, health and some other properties works. Simply, server-side position of the element is where the syncer sees it. If the position changes client-side for syncer (no matter if via scripting or just physically moved), the same will happen on the server. This keeps elements synced.

Its Suggestion ! He asked for new function like other do If you dont want it ... others will want it Its up to developers For me yes better than nothing If I didn't want the function, why would I make it? Writing the function in Lua isn't "nothing" and I haven't seen people who care if the function is added by the resource or implemented into MTA itself.

That's not a bug. That's the way GTA object scaling works.

Using colshapes isn't very reliable because ped cannot be controlled in perfect accuracy in this way unless there are colshapes on all sides of paths to lead the ped back on the path. When controlled in my way, peds are cycled through every frame (onClientPreRender) the data is processed (like calculating angle from current position and destination) and their control states are set. That means they're always aware of changing conditions. So you can calculate the angle from plane to the destination path point and use it to set control states. On the other hand, this way may need optimizations to be efficient when used on many peds. Controlling the ped using colshapes may work well, but these are things you should take care about: 1. Cover the path with colshapes from all sides. For example, if the ped has turned to the right too much, he must hit the colshape which makes him turn left, so that he gets back on the path. 2. When the ped gets streamed in for the client, it should be checked whether he is in any of the colshapes, and if so, then set the control state to what the colshape should set.

Server-side setPedControlState isn't necessary at all. It's not hard to use it client-side and keep the ped synced. First of all, you should remember that position is synced. If ped is doing 100 different things on the screen of each client, everyone will still see him in the position where syncer sees him. Also, element data is synced too, unless you choose not to sync it. Element data can be used by the server to set the ped task. So, we have two most important things synced: position and element data. Every client can use it to control the ped on its own, and most of the time they will see the same. A simple example: you want the ped to walk straight to the position where you set. Client can simply calculate rotation from the current position to the destination and set camera rotation and control state. The only thing it needs to know is destination. You can simply set it from the server using element data. If every client has the same primary data, the result will be the same too.

What does my technique have to do with ped physics sync? No matter in which way you control peds, there will be the same desync problems, unless you sync the physics yourself. The point is, ped is always in position where syncer sees him and that's enough to prevent him from desyncing too much. If you want better ped physics sync, then it should rather be another script, not involving AI.

There's no need to trigger events at all. It's much easier to do with setElementID and getElementByID. For example change triggerClientEvent line into something like: setElementID(pilota1,"pilot") Then in go function: local pilota1 = getElementByID("pilot") And attach go function to onClientResourceStart.

There's no resource worldped in MTA community. There was some resource world-peds, but P-Script (the person who uploaded it) had simply stolen it.

Position is synced, so is element data and that's enough to keep the ped synced. I've seen people who wanted to have server-side setPedControlState, so that they could fully control ped from the server. Still, I don't see the point in this as control states involve physics, which are only available for client. Server could use element data to set the task for the ped and client should do the rest of the job. Look at my house killer script: . The only thing synced by this script is killer's target, set via element data. Client uses this data to navigate killer to the target and attack, using setPedControlState. Even though every client controls the killer on its own, they control it in the same way because the primary data (position and task) is synced. I tested the script with another player and saw no desync.

It's not difficult to do for one person either. I once had made NPCs walking all over the map: . Unfortunately, I lost the script, but I wasn't going to giving to anyone either. It wasn't very hard to make it. It took me a week or two to script ped spawning/walking and to create path nodes everywhere NPCs should walk.

That's not because of your script. Peds used to crash the game for me too, but after some 1.1 nightly build, I don't have this problem anymore, so the bug must have been fixed in MTA SA 1.1.

I doubt if MTA will beat SA-MP in player count if community is going to always wait for something, but do nothing. SA-MP community isn't so special in any way either, but because most people are used to it, they won't move to MTA unless they see something unique and original. If MTA servers used all potential of the mod, SA-MP players would see more point in switching to MTA, but no - its community is just waiting. I'd rather like to see NPC traffic scripted and not released, but used in the server by resource author.

Why to wait for something for months instead of scripting that in a few weeks?

There has been the stimilar situation with bone attachments: everyone wanted them, but nobody scripted them. So I had to script them. It's the same about peds: many people want NPC traffic, but they're just waiting. And I feel like I don't really have time to make it. People would better start acting, not just wait and watch.

We all want MTA to be better than SA-MP and that's exactly how it is. But I find a little problem in MTA community: everyone wants somebody to come out of nowhere and do the job for them. That was the situation with bone attachments: getPedBonePosition has existed for a long time, but there still were many people who wanted bone attachment functions to be implemented. That took such a long time that they could have scripted it themselves, but they didn't. So I decided to make the resource myself. I'm glad that people like it, but I also feel a bit disappointed in them.

Why do people take SA-MP as an example? SA-MP sucks and has nothing impossible for MTA. Actually, with getPedBonePosition in MTA you can do much more than SetPlayerAttachedObject in SA-MP. If you don't want to script attachElementToBone yourself, use bone attachments resource. It has no limits for attaching objects, while in SA-MP there are only 5 object slots per player.

This has happened to me a few times when I was playing around with my resource which uses NPCs. The NPC appeared/behaved in a way GTA peds do, not like I had scripted and MTA seemed to be unaware of it.

AFAIK, this may be caused by markers. And you don't need to write such block of code. Put it somewhere around isLineOfSightClear and you will see the line when the object gets checked. Then if the line looks too long, change the offset, restart the script and check again.

Yes, you need to make sure that no objects with the same model ID are near. And it's better to do replace/restore model onClientElementStreamIn/onClientElementStreamOut. That's not right. The object may be streamed in even if it's too far to be visible. 'Streamed in' means that the object is physically present in GTA world. When it's streamed out, it gets removed from the game and only exists in MTA memory.

I don't think so. Why don't you test it yourself? Make a dxDrawLine3D call and you will see what offset you need. By the way, disable checking of all elements other than objects in isLineOfSightClear.

Yeah, but not too far, so that the ray wouldn't hit nearby objects.

Just get the position of the object for one point and a little offset from the object for another, so that one point would be inside the object and another would be outside.

The server shouldn't rely on client that much, otherwise it will be vulnerable to hacking.