Leaderboard

الكود الأول ماني متأكد اذا راح يشتغل معك local dataTable = getElementData ( player, "Data" ) dataTable[2] = true setElementData ( player, "Data", dataTable ) -- local dataTable = getElementData ( player, "Data" ) setElementData ( player, "Data", { dataTable[1], true, dataTable[3], dataTable[4], dataTable[5] } )

setPlayerHudComponentVisible("area_name", false) in client setPlayerHudComponentVisible(thePlayer, "area_name", false) in server

Thank you must serve!

Substitua 'pAccount' com getAccountName(pAccount)

only on initialization, it is a good idea to send the whole table. Else it is just a waste of data including the risks of de-synchronize the data.

HD Radar New This is an edit of the HD Radar resource by vx89 with tiles generated from the OpenStreetMaps version of San Andreas, OSAM map by cl4ptr4p using the tool provided with SanMap by ikkentim Download: https://github.com/osnapitzjamie/hd_radar_new/archive/master.zip GitHub Repo: https://github.com/osnapitzjamie/hd_radar_new

Introduction Particles and lights are found many places in the game. Cars has corona lights for their tail, brake and headlights, exhaust fumes and tire smoke. These are effects and can help boost the atmosphere. Adding these effects can be done with ease, however, those who wish to use specific tools may have to incorporate more tools to transfer the data between files. This guide aims to introduce GTA modders to 2d billboard effects (lights, splashes) and particles through use of 3ds Max and relevant tools. To get started, user must obtain a selection of programs and 3D scripts available from this topic: Kam's 2018 scripts, The Hero's RW importer/exporter (optional if using for object export; harder), Dexx's 2dfx export script, RWanalyze and tools for setting up texture files. Table of Contents Working with lights using Kam's 2018 script Working with lights and particles using RW script (and Kam's 2018 for data exporting) Common uses of 2dfx Working with lights using Kam's 2018 script The upgraded Kam's script has an in-built 2dfx tool for quickly adding lights to models. Below is presented a step-step guide on adding a blinking light to a cone ID 1238. Import trafficcone.dff from gta3.img using the Kam's 2018 script importer. Navigate to Create Panel > Lights > Standard > Omni Light. Spawn one at the top of the cone. Link the Omni to the model, so it is a child of the model. As seen on the image below, expand '2DFX' on the script GUI. With the Omni selected, click 'Get'. Now the light parameters can be set to the user's likings. Below is a detailed explanation of config. Once done, select model and the child light and click Export to DFF. Time to test! The following config and export settings are ideal but may be adjusted to individual user's preferences: Each setting explained: Presets: presets for easy setup of lights Set to selected lights: needs be clicked each time changes has been made to a light. Get: copies the selected light's information, allowing one to paste that onto other lights. Color: the color of the light. Corona size: the size of the physical corona light. Draw distance: distance in which the light can be seen from (in SA units). Light range: distance in which the light illuminates peds and vehicles. Corona name: light texture e.g traffic light, blood splatter, corona star. Show mode: enable for flashing and other effects. Reflection: gives the effect of the sun shining into a lens when looking at the light source. Shadow size: the size of the round transparent shadow. Shadow distance: the distance in which the shadow can be seen (e.g if object is 100 meters above surface, the shadow can be seen if set to 105 units) Shadow multiplier: intensity of the shadow. Shadow name: defines which texture is used for the shadow. Flags: defines light properties. Working with lights and particles using RW script (and Kam's 2018 for data exporting) Lights method The steps presented in Kams method needs be followed with export included. On 3ds Max with the RW version of the model (with Omni Light) ready, export the model with its child Omni Light using RW script. The RW version does not need any specific light data, it just needs a regular Omni Light as placeholder. The reason for having Kam's DFF version available is that it contains data that can be extracted from the Kam's file and imported into the RW file. With Kam's DFF and RW DFF in a folder, open RWanalyze. Open the Kam's DFF and spot the section named "2dfx [xxx bytes @ xxxxx] - [0x253F2F8]". To proceed, right click the highlighted section > Export Section Data (ctrl + e) > select project folder and name as 'cone'. Now, open the RW version and find the same section located approximately in same order in the hierarchy containing a Bin Mesh PLG. To proceed, right click the highlighted section > Add section > [0x253F2F8] 2dfx > Right click the new section > Import section data > Find and select 'cone' > save file. Particles method For adding particles to the model, Dexx's 2dfx tool is introduced to the user. This method is not tool specific and works with both KAM and RW exporters. In this case RW exporter is used. With the RW model in 3ds Max, go to Create Tab > Helpers > Dummy > create one at the top of the cone. Link it to the model so that it's the child of the model. Start Dexx tool. Click 'Add Particle Info (Dummy)'. Expand 'Setup / Edit Particles'. In 'Particle System' select 'Fire'. Click 'Apply to Dummy(s)'. Expand 'Export Effect Info'. Click 'Export Info' with only the dummy selected, not the model. Export to project folder and name file as 'fire'. Export the model with the dummy included. Now with RWanalyze, open the DFF that was exported and find the following section. To proceed, right click the highlighted section, click 'Add section' and find [0x253F2F8] 2dfx. Right click the newly generated section and click 'Import section data'. Find the file 'fire' and on RWanalyze click save. The model now contains a fire from the top of the cone. Common uses of 2dfx In GTA SA, lights and particles can be integrated into models regardless if they're world objects or vehicles. Thus it opens up a whole level and opportunities for modelers to improve visuals of their models. A few uses are compiled below. Street lamps Fireplaces Cars Sirens Fire simulations Structure lighting Aircraft blinking lights Traffic lights Fountains Cement mixers Farming utilities The possibilities are endless, although the rendering limits of corona images is 32. This explains why the Pyramid in Las Venturas has 8 lights on each 4 corners.

Introduction 3D models using alpha transparency (or known as alpha; opacity; transparency) can at many times be glitchy and not render correctly. In the following guide, common uses and step by step methods will be shown. The guide assumes the user is familiar with 3ds Max and knows how to export models with their textures to test on MTA. Table of Contents Identifying the issues with alpha transparency in MTA How to model glass that renders anything behind it (except particles, effects & water) Modeling gradient alpha at the expense of extra geometry Identifying the issues with alpha transparency in MTA Understanding how MTA renders objects behind alpha, reading FAQ #8 on this topic is necessary. In many cases 3D modelers has done an oopsie by assigning alpha material an ID that's lower in hierarchy by other diffuse materials - thus renders the alpha before opaque materials, causing glitches. It is also worth noting that MTA natively does not have any support for custom .ide and .ipl files which contain crucial information for models, including "secondary alpha transparency flag". This flag (property) is required for semi-transparent textures to properly render what's behind them. Window glass is suffering from the lack of model settings available. Thus the only way to draw glass in MTA is either using no bitmap for the glass material, or using a simple 4x4 bitmap that has a flat color with transparency, in other words a simple "fill color". How to model glass that renders anything behind it (except particles, effects & water) One may want to use transparent glass for their custom model but haven't had any luck. Fortunately there are very simple ways of producing glass-like models. Give the window frame a texture of its own. Attach the window glass to the frame if not done already. Give the window glass a new material which has opacity set to 35/100. Do not give it any bitmap/texture. Make sure that the glass material ID is higher than any other material in the model (follow #8 on this topic). Model now contains glass and can be exported to MTA. On MTA DFF replacement script, alphaTransparency must be enabled. Enjoy! For troubleshooting, window above is available for download here. (by Tut) Modeling gradient alpha at the expense of extra geometry Due to MTA not supporting 2nd alpha property in models, the only way to replicate gradients e.g for lamp lights, neon etc., one must add 'steps' of alpha where the opacity decreases per step of geometry, as seen below. Note that the third sample is mirrored top-bottom giving it a gradient look. Whereas the second has 20 triangles, the third was made with 100 segments and then optimised. The third sample has around 19 steps of alpha meaning 19 materials and climbs from an opacity level of 100 to 81.

Introduction Vehicle indicators are mostly seen on other GTA modifications where the mod 'IVF - Improve Vehicle Features' is compatible. This mod allows for light modifications such as police flashlights, custom LED flashers, indicators and much more. These features are sought after by MTA roleplaying servers a lot. This guide aims to introduce 3D modelers to prepare models for customisable lights, which then requires coded shaders to work. Anything related to scripting is not included in this guide. The guide assumes that the modeler has basic understanding of importing and exporting models. Editing existing Huntley for indicator lights With Huntley imported into 3ds Max, isolate the mesh called 'chassis' as it is the only component that needs working lights. As seen the car has 4 lights; right tail light, left tail light, right headlight and left headlight. All 4 has their own material assigned for them to act each their own way. The material color codes are hardcoded in the game telling it when to show illuminated brake lights for when the car brakes and so on. For this custom vehicle however, any geometry meant for custom vehicle lighting needs white color code and a custom texture name for shadering to work. Before anything, it's required to get the custom lighting texture ready. For this guide, vehiclelights128 and its illuminated version works perfectly fine. These needs be renamed to customRRLightsOff and customRRLightsOn and so forth. The 'RR' is for 'right rear', where as 'LR' would be 'left rear'. This needs be done for front too, so in total 4 'off' images are needed while only one 'on' is needed, as it can simply be instanced when shadering. Below is a step-step process on editing Huntley's geometry and adding custom indicators. Add an 'Editable Poly' modifier to the model. Press '5' key on keyboard which enables 'Select by Element'. Select the two rear light meshes, ensure they are both highlighted. On 'Modify Panel' scroll down and find 'Slice Plane', click that. This creates a rectangle that has a line-preview for the cut. Align the plane to the lights and create two cuts for the indicator lights. Select one side of the geometry that was cut by using 'Select by Polygon'. On the modifier stack, click 'Collapse all', leaving only 'Editable mesh' on the stack. Press 'M' key for 'Material browser'. Create a new GTA material. In the texture slot, add in the 'customRRLightsOff'. On material browser, click 'Assign material to Selection'. Note that this needs be done for the left side too but with different material and texture. Apply a new modifier on the model called 'Unwrap UVW'. Press 'Open UV editor'. On the UV editor, enable 'Select by polygon'. Grab the UV island and drag it onto the orange section of the image, which is for indicator lights. On modifier stack, collapse all, to save the new UV's. Above: example of what can be achieved. Front lights section already has indicator lights, so all that needs doing is 2 new materials with each their own light texture, like done on rear side. The 4 new textures needs be added to the car's .txd file. Model is now ready for export. Now all that's needed is MTA scripting for the light shaders to work. Exact same process can be applied for creating custom emergency lights. Note that it is not necessary to have these 128x128 textures in the model. They can be downscaled to 4x4 in the .txd and then a MTA shader script can apply the originals, which greatly reduces the size of download. This means it'll download 4 images which are then instanced onto every custom model using the lights. To put it short, each .txd will have 4 placeholder-images of 4x4 resolution rather than 4 images of 128x128 resolution.

Introduction Properly handling your user's credentials (username and password) is very important, this guide gives detailed information and code samples on how to (properly) implement an account "system". This guide assumes you are not using MTA's built in accounts. Disclaimer: Any code shown in this tutorial is purely for illustrative purposes, and is not finished code, you should use it as a guideline, not a solution. Content The following topics will be discussed in this tutorial: How to hash and salt passwords (register) How to validate a hashed password (login) How to add "remember-me" functionality How to offer password recovery How to migrate from an older hashing algorithm, to a newer one Using a password policy (Extra) How to handle database leaks (Extra) What even is hashing and salting? For the purpose of this tutorial we expect a database structure which is somewhat similar to this: How to hash and salt passwords When you have a user register on your service, that user expects of you to keep their password safe. Whilst it is generally bad practice to use the same password for multiple services there are many users that still do so. Because of this it's crucial that you save the user's passwords in a way that an attacker will be unable to find out the original password the user typed. This includes if they have full access to your database. In order to do this we do what is called "Password hashing" When a user registers, your server receives the user's intended username, (email) and password. Before you save that password to the database you have to hash and salt this, luckily MTA has a function that takes care of this. If you wish to know more about what exactly it does, there's more information at the end of this tutorial. In order to hash this password you use the passwordHash function. This function is relatively slow (by design), so it is highly recommended you pass a callback to this function, so your entire script doesn't wait for it to complete. https://wiki.multitheftauto.com/wiki/PasswordHash local mysqlHandle -- we're assuming this value is set somewhere else in code function register(username, email, password) local player = client passwordHash(password, "bcrypt", {}, function(hashedPassword) -- callback function for hashing the password local handle = dbQuery(function(handle) -- callback function for storing the user in the database if (handle) then triggerClientEvent(player, "registrationSuccess") -- inform the user that registration was successful else triggerClientEvent(player, "registrationFailed") end end,mysqlHandle, "INSERT INTO users (email, username, password) VALUES (?, ?, ?)", email, username, hashedPassword) end) end addEvent("passwordTutorial:register", true) addEventHandler("passwordTutorial:register", getRootElement(), register) How to validate a hashed password Once you've saved the hashed password to your database you need to do a little bit of additional work when authenticating the user. Luckily MTA offers a passwordVerify() function, which is the counterpart of the previously discussed passwordHash(). What this function does it basically hashes the password in the same way, resulting in the same output hash. https://wiki.multitheftauto.com/wiki/passwordVerify In order to get the account the user is trying to log in to you have to do a query for an account which has the user submitted username, and of which the password matches through passwordVerify. PasswordVerify is also a relatively slow function, thus you should use a callback. function login(username, password) local player = client dbQuery(function (handle) -- callback for the query selecting the user by username local results = dbPoll(handle, -1) if (#results == 0) then triggerClientEvent(player, "loginFailed") return end passwordVerify(password, results[1].password, {}, function(matches) -- callback function for the password verify if (matches) then -- Do anything you wish with the database result to log the player in with the rest of your scripts triggerClientEvent(player, "loginSuccess") else triggerClientEvent(player, "loginFailed") end end) end, mysqlHandle, "SELECT * FROM users WHERE username = ?", username) end addEvent("passwordTutorial:login", true) addEventHandler("passwordTutorial:login", getRootElement(), login) How to add "remember me" functionality When users on your server log in, they often do not want to have to enter their username and password every time they want to log in. In order to satisfy this need you can implement a "remember me" function. What I've seen happen in the past, is people would store the user's password (encrypted) on the client. This is NOT safe, and should never be done! In order to properly use remember me functionality what you would do is upon login in, generate a random string. The longer the better. This random string is what we call an access token. You would then allow the user to log in with such an access token, preferably only once generating a new access token each time one is used. To implement this you would generate that token every time the user logs in, whilst they have "remember me" enabled. You will have to save this token in your database alongside your user. For extra security you could also store the user's serial alongside the access token, you can then validate that the access token is being used from the same device. https://wiki.multitheftauto.com/wiki/Filepath function login(username, password) -- This code should be put in the callback to the dbQuery function, but to keep the example clean that's not shown here if (rememberMe) then local token = generateRandomToken() dbQuery(mysqlHandle, "INSERT INTO access_tokens (user_id, token) VALUES (?, ?)", results[1].id, token) triggerClientEvent(player, "loginSuccess", token) end end function rememberMeLogin(username, accessToken) -- this function handles a user's login attempt dbQuery(function(handle) local result = dbPoll(handle, -1) if (#result == 0) then triggerClientEvent(player, "loginFailed") else -- Do anything you wish with the database result to log the player in with the rest of your scripts triggerClientEvent(player, "loginSuccess") end end,mysqlHandle, "SELECT users.* FROM access_tokens JOIN users ON users.id = access_tokens.user_id WHERE users.username = ?", username) end addEvent("passwordTutorial:loginRememberMe", true) addEventHandler("passwordTutorial:loginRememberMe", getRootElement(), login) How to offer password recovery Offering password recovery requires a little bit more than just your MTA server. Generally password recovery is done with emails. So you would need access to an email server / service which you can use to send an email from an HTTP request. (Like you can do with fetchRemote()). When a user requests a password reset, have them enter the email you registered with. You then fetch a user from the database with this email address. You would then store a password recovery token for this user. This token, just like the remember me token, is a random string. Ideally, you would send the user a link with a password reset form that goes to a webpage where the user can reset their password. You could do this with an external service, like a webserver. Or you could use MTA's Resource web access for it, but if you do make sure you handle permissions properly for anything else that uses this. However another option would be to have the user copy paste the generated token from the email into you server's login window. Which of the two solutions you pick is up to you, my personal preference goes to the one with the link in the email. But in either case the server side logic is the same. When the user attempts to perform password recovery, verify that the token they give you belongs to a user, and then change the password to the newly requested password. Make sure you hash this password the same way you do in your login. function requestPasswordRecovery(email) dbQuery(function (handle)) local result = dbPoll(handle, -1) if (#result == 0) then triggerClientEvent(player, "passwordTutorial:passwordRecoveryRequestFailed") else local token = generateRandomToken() dbExec(mysqlHandle, "UPDATE user_data SET recovery_token = ?", token) -- mail the token to the user, mail implementation depends on the mail server/service you use triggerClientEvent(player, "passwordTutorial:passwordRecoveryRequestSuccess") end end, mysqlHandle, "SELECT * FROM users WHERE email = ?", email) end function recoverPassword(recoveryToken, password) dbQuery(function (handle) local result = dbPoll(handle, -1) if (#result == 0) then -- this is only valid if you have the user request password recovery from ingame triggerClientEvent(player, "passwordTutorial:passwordRecoveryFailed") else passwordHash(password, "bcrypt", {}, function(hashedPassword) -- callback function for hashing the password local handle = dbExec(function(handle) -- callback function for storing the new password in the database if (handle) then -- this is only valid if you have the user request password recovery from ingame triggerClientEvent(player, "passwordTutorial:passwordRecoverySuccess") -- inform the user that registration was successful else -- this is only valid if you have the user request password recovery from ingame triggerClientEvent(player, "passwordTutorial:passwordRecoveryFailed") end end,mysqlHandle, "UPDATE user_data SET password = ? WHERE recovery_token = ?", username, recoveryToken) end) end end, "SELECT * FROM users WHERE recovery_token = ?", recoveryToken) end Besides changing the password, it's important you also delete any access tokens that user might have if you're using remember me functionality. It is also good practice to make recovery tokens expiry after a certain amount of times, and not allow a recovery token to be created whilst one is already in progress. This prevents a user from sending a large number of emails from your service. How to migrate from an older hashing algorithm, to a newer one Maybe after reading this topic you realise that your password security is not what it should be. So you want to change your old password hashing / validation logic to the ones explained in this topic. And due to the nature that hashes can not be "unhashed", you can't simply migrate your passwords over. So in order to migrate the passwords what you have to do is when a user logs in, first validate their password with the old hashing algorithm. If this matches, then hash (and salt) it with your new hashing algorithm and save it in your database. Make sure to delete the old password otherwise your password security is not any better than before. Using a password policy Passwords policies are important to prevent your users from picking a password that is too easily cracked / brute forced. Many password policies come in the form of "Must have at least one capital letter, one digit and one number". But that discards that fact that the best way to make your password more difficult to crack, is making your password longer. So in the code snippet below is a function that measures the 'search space' of a password. The search space of a password is the amount of possible passwords there are with a certain combination of characters. In order to use this, you would have to set a minimum password search space when a user registers for an account. This minimum is up for you to set, but be reasonable, you shouldn't expect a user's password to be impossible to remember / create. I recommend playing with the function a bit to see what values you get out of it, and pick something you believe is sensible. function getPasswordSearchSpace(password) local lowerCase = password:find("%l") and 26 or 0 local upperCase = password:find("%u") and 26 or 0 local digits = password:find("%d") and 10 or 0 local symbols = password:find("%W") and 32 or 0 local length = password:len() return (lowerCase + upperCase + digits + symbols) ^ length end -- The below function calls are to indicate the difference in search space for a set of passwords print(getPasswordSearchSpace("a")) print(getPasswordSearchSpace("abc")) print(getPasswordSearchSpace("Abc")) print(getPasswordSearchSpace("Ab!")) print(getPasswordSearchSpace("Ab!0")) print(getPasswordSearchSpace("Mu#9A0h.")) print(getPasswordSearchSpace("This is a demonstration of how easy an incredibly strong password is to remember")) How to handle database leaks If you have reason to believe that your database has been leaked or otherwise compromised, it is important that your first course of action is removing any access tokens stored in your database. Once you have done that you have to inform your users. Whilst when properly hashed and salted it's extremely difficult / time consuming to find out a user's password it is still a possibility. So you should inform your users of the breach, tell them that their passwords were properly hashed, and they do not need to fear for their passwords immediately. However you should suggest to your users that they change their password either way, just in case. What even is hashing and salting? Hashing has been brought up several times in this tutorial, whilst you do not need to know what it is / does, you might be interested in knowing regardless. I won't be going too far in depth as I simply do not have the knowledge, but the basic idea of hashing is this: When you hash anything, you turn it into a string of characters (or other value) that has no relation to the original input, other than when you hash the original input again, it will always generate the same hash. For example, when you hash the string 'banana' using the sha512 hashing algorithm, it will always yield the output: "F8E3183D38E6C51889582CB260AB825252F395B4AC8FB0E6B13E9A71F7C10A80D5301E4A949F2783CB0C20205F1D850F87045F4420AD2271C8FD5F0CD8944BE3" Now hashing can not be reverted, you can not "unhash" a hash, so in order to verify someone's password you hash it again, and see if the two hashes are the exact same. Now this is great, passwords are safely stored. However there is still more to do, salting. Salting is adding some random data to your password prior to hashing it. This prevents when two users (on the same service, or on others) have the same password, that their hashes are also the same. Meaning if one password is compromised, the other password is not. It is important that a salt is random for every user in your application, not one salt for your entire application. Now you might think we didn't do any salting in the code / tutorial above. This is not true, we just didn't do it ourselves. MTA's passwordHash function actually hashes the passwords and salts it, this salt is then stored in the output hash it self, just before the actual password hash. In the case of bcrypt it actually stores a little bit more info in the resulting hash, but you need not worry about that.

Introduction Modding is a term used when modifying components, files and what not, in this particular case modifying game installation files in order to achieve unique results not seen in the vanilla game. GTA:SA is 3D era, where modding the game requires special 3D packages. Older games such as GTA:II uses a 2D engine, which means that modding the game was commonly done with image editing applications. We will cover some aspects of modding game textures and models. This guide intends on introducing those inexperienced with modding and 3D as a whole, on how to obtain 3D software and their recommended tools. It also introduces ways to import and export models, basic workflows for 3ds Max, texturing and creating models. TOC 3D packages, helpful tools and how to obtain them Extracting game assets How each type of game model works Limitations - MTA vs GTA Working with 3ds Max Texturing a game-ready cube 3D packages, helpful tools and how to obtain them There are various applications being used for modding. Although some has more tools available, there really isn't one that tops the others. In this section there'll be lists of a few 3D packages and tools used for modding. 3ds Max, arguably the most used program with the greatest amount of third-party plugins and scripts for various games. For GTA:SA, this program is favored by many modders due to it having 3rd party scripts for dealing with animations, collisions, lighting, modeling etcetera. There isn't much that 3ds Max can't, that other programs can, when it comes to GTA:SA modding. Although this can be expensive to run on a longer term, there are education licenses available which last for 3 years. These do not allow commercial use, and is marked purely as "educational use only". View more. Kam's (vanilla) max scripts, the first official script package for modding GTA:SA with 3ds Max. After the release of his scripts, a lot of others has developed scripts of their own, some of which are more optimized and less prone to issues. Even despite Kam's scripts having overseen issues, it is still to this day widely used for tasks such as, but not limited to; IPL map generation and import, collisions, animations, characters, vehicles, environment modeling. View more. Kam's (2018) max scripts, a modified version of Kam's vanilla scripts for 3ds Max. Notable features that were added are; DK22pac's Normal map plugin support, reflection map support for environment models, 2dfx panel for lights such as aircraft lights or street lamps. View more. The Hero's RW importer/exporter, a modern plugin that works extremely well with vehicles and environment models. Due to its simplified layout it is very easy to get used to. It's far recommended to use for vehicle model import/export due to its quality handling and materials, which are based on RW formats (renderware, the engine GTA:SA runs off). With the plugin using different model material formats from Kam's, it comes with a maxscript to convert scene materials from GTA_MTL to RW_MTL and vice versa, if needed by the modeler. View more. Deniska's max scripts, a pack for various types of GTA:SA modding, some features are obsolete for MTA users due to IPL and IDE modification required. Although, the pack does come with a few tools that may be useful to MTA modders, such as prelight tools to set the vertex colors and illumination to fixed values. View more. DexX's 2dfx export script, a standalone 3ds Max script that exports Omni and Dummy informations to .sae file formats, to then be added to the .dff using RW analyzer. With this script it's possible to integrate lights and particles into custom models, e.g flashing aircraft lights, street lights, fire and smoke, etcetera. With the release of Kam's 2018 scripts, this script is used less as using Kam's may be less work for some cases. View more. Blender 3D, a freeware (yes, completely free, no paid watermarks or any limitations), not as favored by modders throughout the years until recently, where a developer has released his script 'DragonFF' on GTAforums. Although it is WIP, modders has already binned 3ds Max and moved permanently to Blender. Although Blender is free, it actually combines several programs into one, allowing a Blender user to sculpt, paint, do lighting, professional rendering and modeling in one. A recent update in 2019 changes the RMB selection to LMB and UI among other things, making for a potential alternative to 3ds Max. View more (Blender). View more (Blender GTA script) Zmodeler, not as commonly used as the aforementioned programs, although it is being used very frequently by modders in various games, most notably for GTA:games. It does not have support for skinned characters, although it is being commonly used for vehicles, and sometimes environment modeling as well. This is a fairly inexpensive solution, but lacks tools for more broad modding. View more. Sketchup, a 3D application that focuses on architecture. For modding, it is a rather uncommon, though has a free and paid version and can be used for seemingly OK modeling. It does not have access to any 3rd party scripts for GTA:SA, hence its only use is modeling and then exporting model files to then import into 3ds Max or Blender. View more. Photoshop, mainly used for graphic design, but can also produce 3D models, video, GIF and textures for assets. Photoshop is the most favored by modders in regards to working with textures e.g paintjobs and retexturing. Although there are alternative image editors in the market, Photoshop definitely hits the top in terms of usable scripts (user-customized scripts as well) and ease of workflow. View more. DFF Viewer, a 3D graphics engine that is used for visualising GTA:SA models and supports .DFF and .TGA formats. Only single dff's can be loaded at a time. Though this is rarely used by those who has access to 3ds Max and Blender, it is commonly used for troubleshooting/testing work that involves retexturing a model e.g changing the clothing textures of a character. This program is entirely free and available from various GTA modding sites. View more. TXD Workshop, a texture dictionary editor that has been around for years, only since recent years to be succeeded by Magic TXD. Though TXD Workshop may not be the best for setting up TXD files, it has a built-in IMG archive editor, allowing one to browse all of the contents of gta3.img. View more. MagicTXD, a new texture dictionary editor with features for mass exporting .TXD contents from folders into image subfolders, texture compression, mipmaps, resizing textures etcetera. This is broadly used for .txd files and almost took over TXD workshop when it comes to working with texture dictionaries. View more. RW Analyze, a multi-use program with notable features being; ability to lock/unlock game files, add data to game models e.g 2dfx and vertex colors information extracted from other DFF files. View more. Extracting game assets In order to start modding GTA, access to the files is required. The files in question are commonly found in parent files that require some sort of program to open. In this case, TXD Workshop or any IMG editor and optionally Magic TXD for later on will work just fine. The below steps shows one way to extract all models and their texture dictionaries. For IMG editors (e.g Alci's IMG Editor): Open the editor. Under File, select Open. Find gta3.IMG stored in GTA SA directory\models. Highlight the first file in the list, then scroll down to the very bottom and SHIFT+LMB click the file on the bottom. This highlights every file in GTA3.IMG. Right click the list of files and select Export. On the popup window, find and select, or create a new folder on desktop called GTA SA ASSETS. Click enter to proceed. ((For cases where specific files are wanted, use the search field to find the necessary files and export them individually)) For TXD Workshop users: Open TXD Workshop. In the toolbar it says Open IMG. Click this, then find and select gta3.IMG stored in GTA SA directory\models. Highlight the first file in the list, then scroll down to the very bottom and SHIFT+LMB click the file on the bottom. This highlights every file in GTA3.IMG. Right click the list of files, select Extract. On the window, find and select, or create a new folder on desktop called GTA SA ASSETS. Click enter to proceed. ((For cases where specific files are wanted, use the search field to find the necessary files)) Now the folder GTA SA ASSETS contains nearly every .dff, .col, .txd and so on used by the game. Assuming one would like having all of the textures in PNG, DDS, TGA or any other common image format, they may follow the below steps using Magic TXD. Inside GTA SA ASSETS create a new folder named IMAGES. Open any .txd file found in GTA SA ASSETS using Magic TXD. Navigate to the toolbar. On Tools, click Mass export. Export settings are as following. Game root = root folder containing TXD's Output root = folder where images goes Image format = self explanatory With texture names only = exports images directly to folder and duplicate named ones gets replaced by one another Pre-pended with TXD name = exports images with TXD prefix In separate folders = makes new folder(s) for every TXD's contents Hit export. This process may take some time. Note that this process is the same for other .IMG archives such as player.img. There are also .txd and .dff files elsewhere, such as \models\generic\generic.txd, which is the vehicle shared texture dictionary file. How each type of game model works Models used on GTA SA uses different rendering techniques and data hierarchy than others. This section will introduce the features that some models has that others don't. Vehicles: Vehicle model components utilises hierarchies, where each component is linked to a dummy (helper) and each dummy is linked to parent dummies e.g chassis_dummy, for them to be registered in the hierarchy. In order for vehicles to not look flat or cartoon, a few steps are made in the model; Diffuse material is given a grunge texture or AO map, this helps telling the depth of the vehicle as well as giving it a feel of realism, so it isn't just clean. A specular lighting image is applied to the vehicle surface material, giving it a fake shine when looking from certain angles. If the vehicle has hard edges (smoothing), this image can increase the visibility of the normals, retaining its original look rather than being flat without visible difference in geometry. An environment (ENV) map is applied to the vehicle surface material, producing a fake reflection that is animated horizontally as the vehicle travels. Vehicles also has a lot of hardcoded features such as headlights, brake lights, emissive lights, taxi/aircraft lights, rotatable components and dynamic collisions for special vehicles like Forklift. Vehicles are also the only dff models that uses baked collisions, which means they are stored in the .dff itself. Below is a detailed hierarchy used for cars, and special components used by a number of vehicles (click the spoiler). Skin characters: Ped skin characters uses bones (dummy objects) that are connected to each other and linked to the character model. These bones are not visible in-game. In order for the bones to know what part of the 3D model they're responsible for, the skin needs to be rigged. Character rigging for GTA:SA is done by applying weigh on vertices. Using heatmap display, colors go through blue-red, low-high respectively. Values go from 0 to 100. If the value is 0, it means that the vertex is not used for any bone. This can cause issues. If the value is < 100, it means that the vertex is used for multiple bones. This results in smooth animations ingame, as the 3D model transitions smoothly through each bone. If the value is 100, it means that the vertex is only responsible for one bone. Skin rigging is generally something that is being avoided by modelers and makes Skin modeling the most difficult on GTA. Bones are as shown: CJ character: Carl Johnson's 3D model is split into several pieces in order to be compatible with the clothing script used to let the player customize CJ. These models uses a function known as multiclump to support 3 meshes per dff; normal, ripped and fat. This is for CJ's health stats to physically show in-game. Other than multiclump and additional bones, modding CJ skin is essentially the same as any other ped skin. Map environment: World objects .dff contains only single models, though they do support omni and dummy objects for 2d effects. These types of models uses Vertex Colors/Face Colors. This requires the modeler to paint colors onto the model which is then stored in the vertex colors channel (daytime) and vertex illumination channel (nighttime). Although uncommonly used by R*, these models do support reflection maps like vehicles use. Goldfish's modified version of Kam's scripts is excellent for exporting with reflection maps. GTA SA utilises multiple collision archives (.col) for every IPL district, being responsible for all of the world objects' collisions. However, on MTA, collision archives are not supported, so custom collision files are single models per .col. Not every object uses collisions though, some merely has their bounding space. These objects can not be selected with MTA map editor, thus requires additional scripting or modding. Limitations - MTA vs GTA Speaking of native support, MTA currently is behind in several places. Notable features that aren't available on MTA, but on GTA are as following. Item Placement (IPL) - another type of mapping file, but contains a lot more functions such as zones for real-time reflections as seen in interiors. Item definition (IDE) - a file used to but not exclusively, define settings for models, enabling alpha flags, disabling backface cull, enable breakable effect and much more. Limit adjuster - a rework of the game that allows for adding more ID's and bypass common limits. This however is being developed by one of MTA's contributors. There are various limitations such as polys per model, max dimensions for models and collisions, (very) strict size limits for collisions and CPU usage that can easily cause issues for modders. Not to mention the majority of the game data files which most MTA servers likes to force original, else the player won't be able to connect. These limits all has potential solutions being developed as with the limit adjuster. Working with 3ds Max As described above, 3ds Max is without a doubt the most common program for GTA modding. It's also used by professionals within architecture and visualisation and film industry. What's amazing about this program is that whatever is created in 3ds Max can ultimately be added to the game. A modeler made a square - it can get added right away, no adjustments required. That's the charm of 3ds Max. There's no need for additional tools to process the model for it to be compatible with GTA. It is also the primary program that Rockstar's developers used for creating the environment in GTA:SA. At a first glance, the program may seem rather intimidating. The main functions of the program that a beginner should be aware of are listed below. Shows the default home screen with 4 viewports. Left, Top, Front and Perspective. The 3 side ones are Orthographic viewports while Perspective is in regular mode. It is also the most common one to use. Highlighting a viewport and pressing (left)ALT W will full screen the viewport. In order to rotate camera view, the user must click and drag the square in the upper right corner. Its face also tells which side the camera is viewing e.g Top. If one wishes to see viewport statistics such as polygons per model, vertex amount etc., clicking: [ + ] icon on the upper left side > Configure Viewport > Statistics > Total + Selection > Apply > Clicking 7 on keyboard shows the statistics. This feature is extremely useful for modelers who are limited in polygons per model, or simply wants to see how many polys a car is. Common keyboard shortcuts F1: Opens Autodesk help section in new browser tab F2: Displays blue overlay on models F3: Displays models in wireframe F4: Displays edges on models F10: Opens render setup 9: Shows viewport statistics Q: Select objects W: Select and move E: Rotate R: Select and (mode) scale U: Orthographic viewport mode P: Perspective viewport mode A: Toggle angle snap S: Enable snap D: Disable viewport G: Enable/disable grid J: Display bounding edges LALT X: Xray mode for model Ctrl Z: Undo action Ctrl Y: Redo action In a heavy program like 3ds Max, being able to change preferences to one's likings is important. Do so by going to Customize > Preferences. Performance, file settings and such can all be configured in there. For GTA:SA modding, knowing how to subdivide and add geometry to existing GTA models is very important. Below is a list with actions that may come in handy. No-brainer: Editable Mesh is inferior to Editable Poly. Use Poly, poly, poly, poly... Editable mesh modeling Vertex selection mode Edit Geometry section Attach: attaches another model in the scene to the selected mesh Chamfer: chamfer selection of vertices; creates additional geometry Weld: merges vertices together within a specified threshold Surface Properties section Edit Vertex Colors: sets the color and illumination of selected vertices Edge selection mode Edit Geometry section Divide: divides an edge, adding a new vertex where it was divided/split Extrude: create and pull a new face out from existing edges (keyboard shortcut: LSHIFT + LMB-drag) Face selection mode Edit Geometry section Divide: creates a new face Extrude: pulls the select face(s) outwards or inwards and creates new geometry off that Bevel: essentially an Extrude followed by scaling of the face Surface Properties section Flip: flips a face 180 degrees Smoothing groups: defines the smoothing of the model. Autosmooth is in many cases OK, but may not fulfil everyone's expectations Editable poly modeling Vertex selection mode Edit Vertices Connect: selecting 4 verts on a box side and using this function will triangulate the side. Edge selection mode Edit Edges Connect: creates an edge between the selected edges, as in a bridge between two cliff sides (use the 'Settings' to choose between multiple or one edge on creation) Polygon selection mode Edit Polygons Inset: places a new polygon inside the selected, allowing to be scaled Bridge: connects two opposing polygons by creating a bridge between them (can be used for walls and gaps) Edit Geometry Slice Plane: enables the user to create a perfect cut on the model, can be rotated by degrees Rendering scene Modelers working on projects for companies or friends might want to show what they've accomplished, but a regular screenshot may not suffice. Talking of a screenshot like this: Instead, the modeler might want to show the scene with textures. Perhaps more than just textures - lighting? reflections? transparency? - this is where 3D rendering comes into play, and can be done by simply pressing SHIFT + Q on the keyboard. This can also by default use alpha channel. However, the quality could improve. The quality of the render depends on the scene assets (models, materials, lights), the Renderer and its settings. By default, 3ds Max utilises Scanline Renderer. This is not a production quality render, but rather meant for test shots and demos. Though the quality isn't great, it's still possible to produce seemingly interesting renders. The following render took merely 8 seconds. Using 3ds Max allows modders to bring GTA:SA into modern graphics, easily comparable or even superior to ENB's. It also enables modelers to share visualizations of their models to help the customer understand how it could potentially look for their game. In the above render, a Skylight is used with Scanline Renderer. A very basic render, though interesting and contains lots of depth. In order to replicate this result, below are the steps to follow: On the Create panel, where one would normally find boxes and spheres, click the toolbar Lights. Where it says Photometric change that to Standard. Click the Skylight and place it in the 3ds Max scene. Settings for Skylight explained Multiplier: intensity of the light Sky color: the color of the light Cast shadows: enable to produce shadows, though this is more of an Ambient Occlusion than actual shadows Rays per sample: quality of the shadow, ideally keep at <5 for tests and 15-20 for final shots In the actual render above, a sample of 5 was used, creating grainy shadows but quick render. Backface culling was enabled to avoid slowing down the render time. Skylight is great light source and is generally used to illuminate an entire scene and not particular models. In the same Lights tab, one may find use of Omni or Free lights, which both works great. These are great point lights, which as opposed to skylight, are able to illuminate parts of the scene e.g acting as street lights. Modifiers When modeling, modifiers can come in use and save the modeler a lot of time. The following modifiers are highly suggested for beginners to know about. Bend: bends the model, effect depends on the differences in the geometry Mirror: copies the mesh and mirrors it on the other side, commonly used for vehicles using symmetrical geometry Smooth: generates and applies smoothing to the model, generally the lower values makes for higher file sizes Symmetry: essentially the same modifier as 'Mirror' Turbosmooth: Smoothens the mesh, adding geometry, uses iterations Unwrap UVW: advanced UV editing, commonly used for preparing textures for models like characters and game assets UVW map: basic UV editing, X/Y/Z projection mapping as well as spherical, box and planar mapping Vertexpaint: allows for painting colors onto vertices and faces, these colors are rendered during either ingame or night time Texturing a game-ready cube Modeling has to start somewhere. Using standard 3D primitives is a good place to start. For the purpose of this guide, a Cube will be created in 3ds Max and textured in Paint.net, a free image editing software. Video tutorial: To start off, navigate to 3ds Max's Create tab on the right hand side panel, as shown below. Shows the Create tab on the panel. For this guide, click on Box (Cube). Use LMB and click and drag the mouse in the viewport to create the cube. Now that the Cube primitive is spawned in the viewport, on the same panel that it was created from, go to Modify tab and set its dimension parameters to 5,0, 5,0, 5,0 and 1 segment for all 3. Convert the model to Editable Poly by right clicking it in the Viewport > Convert to > Editable Poly. Go into Polygon selection mode and scroll down until the following buttons are visible: With viewport selected, on the keyboard press `CTRL A` to select all faces on the cube. Now, where it says `Color`, click the bar and on `Value` set it to 100, then do the same for `Illumination` but value at 35. What this does is it sets the vertex colors so that the model won't be overexposed during day/night time. Exit polygon selection mode and on Modifier List, click that and find Unwrap UVW. This applies a modifier stacked on top of the Editable Poly mesh. Under Edit UVs click Open UV Editor. This allows the user to make changes to the UV coordinates which tells the model how textures are projected onto the model. On the editor, ensure that Polygon selection is enabled. While in the UV editor, press `CTRL A` to select all UV islands. On the top of the editor click Mapping, then Unfold Mapping.... Keep it as Walk to closest face and enable Normalize Clusters. Click OK. The result should remind the user of how a simple cardboard box in real life looks when it's yet to be folded into a box. With the model unwrapped, on the toolbar on the UV editor, click Tools > Render UVW Template. The export settings below are ideal for this particular task. If one wishes to know exact dimensions of each square, enable Seam Edges. After exporting, on the modifier stack, press Collapse to. This saves the new UV's. The width and height should be on a 1:1 ratio to avoid stretching issues. 1024x1024 is more than enough. On the rendered image window, click the Save button and find a location to save it in, name it Cube_unwrapped and use Alpha channel (optionally). Now open Paint.net and insert the image. Once happy with the result, export as cube_diffuse. Diffuse map generated with the help of a UVW template. In order to apply the texture on the model, simply drag and drop the image from file browser onto the model in the Viewport. Although the example above is not textured properly in regards to rotations, it shows what can be done by using UVW templates, and how easy it really is to produce textures for models made from scratch. The model can be directly exported as DFF. Materials are not required to be GTA or RW, they can be standard and still show ingame. Some exporters wants the model in Editable Mesh however, so converting it may be required. Thanks for reading this guide, we hope it helps and we wish you the best of luck with modelling! For questions on modding, please refer to MTA's modding FAQ or MTA discord #modelling channel. KAM_s_GTA_Scripts_Upd_by_GF_v0.3.7.zipKAM_s_GTA_Scripts_Upd_by_GF_v0.3.7.zip

You must set the position for the vehicle instead of for the driver (if he's in a vehicle).

remove the player from the vehicle first. https://wiki.multitheftauto.com/wiki/RemovePedFromVehicle

Both can be used. if type(value) == "number" then end Just tonumber is more forgiving, as you can also accept strings by converting them to numbers. local value = "123" value = tonumber(value) if value then end It just depends how forgiving you want to be. Do not do this: (2 function calls) if tonumber(c_buffer) and tonumber(c_buffer) >= 0 then end But do this: (1 function call) c_buffer = tonumber(c_buffer) if c_buffer and c_buffer >= 0 then end If you can reduce function calls, by just writing it a bit different without messing with the programming flow, you should take it.