DiSaMe

No, that's not what I meant. As I said, my idea was to apply ped parts to CJ rather than vice-versa. So ped skins would remain non-customizable. addPedClothes wouldn't work for them. But CJ's skin (ID 0) could be applied not only usual clothes, but also ped parts. That would make mixing parts of more than two skins possible. An example: let's say we want to have Sweet with white shirt. So we use skin with ID 0 (CJ), use addPedClothes function to apply Sweet's (ID 270) body parts to CJ's model, except shirt. For the latter we apply CJ's white shirt to the model. And here we have Sweet with white shirt. Also, we could have customized skins put together from 3 or more skins. For example, we take CJ's model and apply shirt of GSF skin and trousers of a balla skin. The result would be CJ with green shirt and purple trousers. Modifying ped models isn't necessary at all. My idea is about making ped parts available as CJ clothes. Because MTA can read DFF files, I think it could also load ped parts as separate models which could be used as CJ body parts. I'm only unsure about splitting the models: how should MTA determine which body part the vertex belongs to? Maybe it could check which bone it is attached to, but I think this way would have some inaccuracies.

"Things which are already in GTA SA" has somewhat vague meaning. I have another idea how to make this work, although I'm not sure if this is possible because I don't know how the stuff works on the lower level. While people talk about applying CJ parts to ped model, I suggest doing the opposite: applying ped parts to CJ model. CJ model is made of separate CJ body part models. I think functionality could be expanded, so that part of a ped model could be taken (for example, vertices which belong to specific bone) and used as CJ bodypart, that means, put into CJ model. Then player models could be made by mixing up body parts of CJ and/or parts of ped models. So maybe all we need is expanding the list of clothes which can be used in addPedClothes. No, SA-MP doesn't have any cloth functionality at all. It only has its own models, such as hats, and a function to attach objects to bones. That's what I was writing about in my first post in this topic, the difference is that SA-MP models come with client and server owners can't add their own models.

addPedClothes working on all skins wouldn't be useless, but I suggested bone attachments as a temporary solution.

"Release it now"? Where do you think I am going to take it from? And what makes me "selfish"? During the time since this topic was created, anyone could have made at least a simple NPC traffic script. So please, stop being so lazy. You can make and release it, nobody is going to stop you. When you make it, I'd advise you to use it in your server only, but it's your free choice, you can release it if you want. I could have made and released such resource many times, but that would be useless because there's hardly anyone who really wants it. If people wanted it, they would make it, but as they are doing nothing and waiting for something magical to happen, I clearly see they have other things to do.

Clothes can be made as objects with custom models and attached to bones.

Yes, it's up to community to decide whether the fun should be ruined or not. But do we really want this?

math.floor

local m3d = playSound3D(math.random(#soundtable), x, y, z, false) The error is here. You get the random number, but instead of using it as a table index, you're passing it directly to the function. You need to write soundtable[math.random(#soundtable)] as the first argument.

But you can use processLineOfSight to check if there's a vehicle or player in front of the object, decrease their health and draw a line using dxDrawLine3D.

I think that shouldn't be too much for you, it's just custom invisible particles system and I already wrote how to do many things.

When the key is held down, use getElementMatrix on the fire truck to get position of water origin, use getVehicleTurretPosition to get the direction of water and store this data into a table. Set a timer or attach a client render event to a function which cycles through the table, changes the coordinates in every table element depending on velocity data, decreases Z velocity, giving a gravity effect, checks the distance between stored coordinates and fire object and deletes the object if the distance is small enough. If you want to see the trajectory of these water "particles", you can draw them using getScreenFromWorldPosition and DX drawing functions. So all you need to do is making the trajectory of these "particles" match the trajectory of water which is coming out of the fire truck. I've done this in the past and that wasn't hard.

I can't imagine scripts causing MTA to crash without a bug in MTA itself.

You mean this?

I've thought about making a delayed reaction to key presses too, but this was a script with only visual effects.

I made another script which uses screen sources: . I think it's the most realistic of all drunk effects ever made on GTA SA, but because I've never been drunk, I'm not sure if it's realistic enough Edit: if the video is blocked for you, try this:

To solve the problems with rotation, you can use getElementMatrix function. With element matrix it's easy to get coordinates of the point with the same offset from the object, no matter how it's rotated. For example, if you want to get position of point which is (2, 3, 4) from element in variable "obj", you need something like this: local m = getElementMatrix(obj) local x = 2*m[1][1]+3*m[2][1]+4*m[3][1]+m[4][1] local y = 2*m[1][2]+3*m[2][2]+4*m[3][2]+m[4][2] local z = 2*m[1][3]+3*m[2][3]+4*m[3][3]+m[4][3] Coordinates of three vectors (m[1], m[2], m[3]) are multiplied by coordinates relative to object (2, 3, 4) and another vector (m[4], which is element position) is added to them. So if you get coordinates in this way, the script will check the same part of the object whatever its rotation is.

setElementSyncer can only set syncer who is near enough to the element. So you need to sync it yourself. You can send train position data from client to server using triggerServerEvent and use that data server-side to set position of the train. Train will need to be always synced for the syncing player, so don't forget to use setElementStreamable.

SA-MP cannot replace TXDs, DFFs and COLs, so all you can do is putting the collision file into custom.img and telling the players to download it. Changing files every time you join another server is too much, compared to MTA SA, where models are downloaded, applied and restored back to original ones automatically.

I see nothing wrong with this. I have a better question: how can people expect everything to be given to them for free?

You can't. If the resource runs on the server, it runs for every player, otherwise it doesn't run for anyone.

triggerClientEvent triggerServerEvent These functions allow server and client scripts to communicate. Make a server-side command which triggers your custom client-side event (create this event with addEvent) and make that event cause the image to be created.

A basic traffic script does not require much effort. In my opinion, the trickiest part to do is proper driving, and still, it shouldn't be difficult. Making paths everywhere takes some time, but that's not a big problem. For the beginning, a part of the map with traffic can be enough, after all. Also, traffic doesn't have to be dense. I think a small number of NPCs already makes the gameplay better and shouldn't use too much bandwidth. So the only reason we don't see NPC traffic in servers is because people don't want it so much.

Some things may be possible to script in other ways. For example, weapon damage can be set via properties, but it has always been possible to modify using player damage and weapon fire events too. Same with target range. So you can change them without changing anything what game understands as the skill.

Don't set everyone's weapon skill to maximum. Do this only for one person, as weapon properties depend on skill.