Oz.

MTA and SAMP aren't really in the same ballpark. SAMP is 'more popular' for now, but is ultimately a pile of crap and lacks 99% of the functionality and flexibility that we get from MTA. In theory, you could have as many paint jobs as you like using the engineLoadTXD function, so long as the TXDs are compatible with the car you want to put them on. Bear in mind though that decent high-quality TXDs for car mods can be pretty heavy (1-2MB or more), so if you had more than a few, your client download would start to get pretty big. You can replace GTA vehicles with vehicle mods using LUA functions like the one above, but I'm not sure how well that would go with with your tuning objective. You could replace the tuning objects (bumpers, spoilers etc) but they would most likely not be interchangeable with car mods, only the original tunable GTA vehicles (if you did it correctly). There's some instability issues when a client replaces a tunable car (eg Elegy), that's really GTA's problem rather than MTA, I'm not sure if that can be avoided when it is a server-enforced replacement. Depending on what you want to accomplish you'd probably want to have a pretty good grasp of 3D modelling & modding and/or LUA scripting.

You checked the meta to ensure all image files are present and with the correct names, and that the resource folder is structured properly?

I'll cry if it's case-sensitive...

As long as they are crediting the people who put the time and effort into creating it, and it works as nice advertising for MTA... I think I can live with that

That's fine, I'd guessed you were running it from your local machine, which does separate your client /mods folder from the /server/mods folder. At least that mistake has been ruled out. It seems to be in the right place, and presumably that is the correct and complete list of relevant files...I'm not really sure what the problem is - perhaps someone else will have a suggestion to make.

That's pretty weak that they are using MTA's Map Editor instead of their own crappy version. I hope they've been diligent in pointing out that the Map Editor was created by and for MTA, not just conveniently leaving that fact out.

Those sorts of objects can be easily created by anyone who knows how to 3D model, and the particle effects etc can already be scripted with MTA's existing functions. I prefer MTA's approach of creating a superior and far more flexible framework for server operators to develop their own content (including new objects), than the approach SAMP takes. I wouldn't be surprised if those objects are the only non-stock items SAMP servers can use...

I think you'll find that the Wiki is really the only way to learn - there are examples provided there to help those starting out. It would be best for you to try to script, and when you get stuck you can ask for assistance here and the scripting folks will generally help out if they can. The community here seems to be very supportive, genuinely helping people who are trying to learn and improve themselves. However, you're unlikely to get any assistance if you don't make any effort yourself, likewise you are unlikely to get someone to do work for you without something useful in return (i.e. money). So as I said, learning yourself using the Wiki is probably the best way to go. I don't think that a YouTube video would really explain anything much better than what is already in the Wiki - at the end of the day you'd still just be watching someone typing out functions into Notepad.

This may be a silly question, but it's bound to be something simple like this... ..you did put it in server/mods/deathmatch/resources/speedometer, right? Not just /mods/deathmatch/resources/speedometer

Any luck with the custom models? I liked the radar showing your actual map, nice touch

The format is pretty much the same, just pull the IDs you need to replace, specify coordinates if necessary (i.e. if you're placing your replaced object somewhere other than its original location), and that's about it. Main difference is needing to specify a col for your object, if you want to be able to collide with it (as you would with a building). There is an example for replacing an object here: https://wiki.multitheftauto.com/wiki/EngineReplaceModel As you can see, the process is very similar to replacing a vehicle.

That mod is doing more than just replacing the texture. Perhaps jetpack's DFF cannot be replaced, in much the same way that ped DFF's can't be either?

Presumably he's suggesting the ability to add filters to the server browser, so that you can browse servers of a particular gamemode only. But you can order the servers by gamemode already, you could just scroll down to the gamemode you like and flick through the servers there, I'm not sure adding filters for it would be worth the effort in the short term.

Ok, well there were a few things wrong with that, so your problem may have been one of several. 1. You exported your DFF as 'Rampy', but in 3DS your object was called 'Quader001'. You should always name your 3DS entity the same as the DFF/COL you will be exporting to. So in your case, the entity should have been called 'Rampy'. 2. Your object was not aligned to the pivot point (centre of the 'world' in 3DS). Unless you have a good reason not to, it's good practice to align your object to the pivot point, so that the relative position of the object you are replacing, and the position of your replacement object are the same. 3. There were some geometry issues, even though you were only making a triangular prism (should be 5 faces) it had 12 instead. May have also been the reason behind your COL problems, in my experience COLs work better if the surfaces are somewhat similar in size. In your case you had 5 large faces, and 7 very small/overlapping ones. Anyway, I fixed those and made a TXD for you. I haven't tested it but it should work as long as I didn't bugger up something myself Should look like this: (Of course you can change the textures or whatever you want) Download link: http://rapidshare.com/files/439503259/Rampy.zip

You tried replacing and restoring Interior objects? Kayl and I had been using interior objects as the basis for custom model replacements for months, I don't think we encountered any instability or problems with them that made them unusable. Not that I can recall, anyway. Though he's got some l33t scripting skillz so he may have tried a few different techniques or something, I don't know. Either way, the main advantage is that they do not conflict with other objects on the map, so you can put it wherever you like on the map without having to worry about your replacement being too close to an original object.

Where possible, just use object IDs that are native to the Interiors. That way there will never be conflicts with objects that exist in San Andreas int 0 (unless you are using those objects in a map edit or something).

If it's your first custom model, chances are high that there will be some fail. The process of getting 3D models into SA is fine once you get the hang of it, but to begin with it seems pretty complicated and there's a lot that can go wrong. If you're still having problems with your resource I'll be happy to take a look at your model files if you'd like, at least then we can find out whether the problem lies there or elsewhere.

I can't help you much with the scripting but I'm reasonably handy with custom models - I'm surprised you were able to make a DFF and COL, but not the TXD? It's a very simple process, I'll explain briefly, hopefully it helps you: *Download a TXD-creating program > I personally use TXDWorkshop 4.0B *Click File > New > 32BPP *Press the 'insert' button on the keyboard and add more 32BPP slots, as many as you need for each of the textures used in your model *Click on a slot, click the 'Import' button at the top, navigate to the textures you used in your model *Double-click the slot you imported an image to, and change the image name so that it is the same as the texture's filename/same as the name you gave it in the modeller *Click 'compress' - non-Alpha images will compress to DXT1, images with Alpha will compress to DXT3 (For textures with alpha, click the 'alpha' tickbox, then click the 'Alpha/Mask' tab at the bottom, Import your alpha and compress as above) *Make sure the image names you used are exactly the same as your filenames (hopefully you already truncated them to 8 characters or less before using them in the modeller, or you may be destined to fail) and that each one is compressed. *Save it

The Wiki is working fine for me - try again?

I'd say its possible to make, both with custom weapon models and modified weapon.dat, and new animations ('shooting styles'). Whether it's possible to do it in MTA is another kettle of fish entirely - although there is probably more flexibility in MTA's LUA than in modifying original game files. Might be able to have a better crack at it in MTA1.1.

Presumably you are looking for the accompanying TXD for the DFF 'vgshseing28'. DFFs often have shared TXDs, where multiple DFFs will take their textures from a single TXD, there is not always a TXD of the same name as a DFF. The TXD you need is called: vgsehseing1.txd ...from vegasE.ide: 8558, vgshseing28, vgsehseing1, 130, 128 If you're ever stuck, you can run through the IDE lists in /data/maps/ and find the DFF/TXD, or use MEd.

Merry Christmas to all The 4th place in the ModDB list is an excellent and well-deserved result, congrats to all the MTA Devs for their work, and to all the server owners/admins/contributors for their work too. @Kayl: Bon travail comme toujours, MP <3 merci pour votre temps (?) cnt w8...

There are multiple TXD's for skin ID 0 (CJ). They are contained within player.img, not in gta3.img. The head, torso, arms and legs are all in separate TXD files, as are each individual clothing item (except for underwear, which is contained in the 'legs' TXD's). If you open the archive with something like IMGTool, and search for 'Torso' or 'Legs' etc, you should find the TXD's you need.

Well if the colshapes work anything like real object cols then the size limit (~255m radius) ought to be non-negotiable. Any object cols larger than that are not recognised by GTA/MTA - presumably the colshapes would work in much the same way? Perhaps you could try defining your area with more colshapes that are smaller, rather than just one huge colshape?

You could always attach another object to the hand bone of the ped, and replace that object with your cigar. Although, we had mixed results when testing that technique on the DKR Server for universal Santa hats attached to ped head bone - sync was ok but ped rotation (eg going down a slope) failed. It might be even worse for a ped's hand, not sure. You could always give it a go, or just wait until a later version of MTA and do it the way you suggested originally.