DiSaMe

Yes, they're disabled. Why would anyone want the game to create unsynced peds? Ped functions are in MTA for a reason.

I think all functionality with IPL we need is ability to remove all map objects via server configuration. Game map can be converted to MTA map format which could then be modified in map editor and controlled using scripts. There is some information related to IPL memory addresses here: http://bugs.mtasa.com/view.php?id=5499 . I don't know how much work it would take to remove/recreate IPL instances, but in my opinion, setting Z coordinate of each IPL instance to some negative value shouldn't be too hard.

If you try to use DFF as a ped skin, then MTA won't be able to use it, but if you use a few separate objects in the same way the transformers resource uses cars, then it will work well. You can try bone attachments to do things like getting position/rotation of bones. If transformer has the same size as the ped does, you can just attach objects to bones.

You're trying to load DFFs from folder 'wheel', but in meta.xml you have them in 'models'.

At least do you know what's going on? First I make a resource, post the link in this topic and then you come, talking in the way as if I don't even want bone attachments, then how do you think that resource appeared in community?

That's MTA bug with peds. If the ped is streamed out when the weapon is given, the player will see him shooting only 1 bullet. I have reported this, but nobody seems to have paid attention.

Yes.

What rest? The list has models designed to be used as pickups, there is no need to write all possible models, use object browser in map editor for this.

I had made my own tram system to use both tram lines in SF and move the trams server-side. To keep the tram always on the rail and synced, I used element data to store the position (one number, "progress" of the tram from start to the end). This data (plus the time since the last progress update) was used onClientPreRender to linearly interpolate the position between two nodes and put the tram there, so it was moving at the same speed, no matter what the FPS was.

Accuracy is less important when no one is near the ped/vehicle. That is the point, you can use setElementPosition to update the position if element has no syncer. I had done such updating to make the ped follow the path and it worked fine.

You can't apply some upgrades in a way that would make GTA see them as upgrades, but you can create objects yourself and attach them to vehicle with these functions: createObject attachElements

With server-sided function clients would still get the new control state at different time because it takes different time for clients with different ping to get the data from the server. And ped/vehicle will still be in position where the syncer sees them. The only workaround I see is a client-side script which detects how much the player is lagging and and according to that, get velocity of all vehicles streamed in and put them further in the direction where they're moving. Still, that needs some work with collision detection to prevent vehicles from moving through walls.

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.