Dutchman101

First of all, please don't post on the ban appeal topic of anyone else. Secondly, please don't say such things without knowing for sure. You either don't want to acknownledge (or didn't know) that your friend Antichrist was banned like 6 times in total, having been a "core DD abuser" through various activity of things like EXEMOD creation/bypass attempts (massively), also using EXEMOD while it was still not detected, messing with lagswitches in order to try and bypass detection on individual lagswitches, etc. He was also working closely together with other DD abusers like Ashame, towards the goal of getting undetected abuse tools for DD. Let me inform you that if this "#SAVEDD" topic (created by a DD abuser, how ironic) is going to be used as a pretext to draw some banned people to appeals for trying to get unbanned, that we will not let that happen, they will be dealt with like otherwise. I can see you brought over 6 people to this topic who are viewing and typing (probably much more pending), mostly DD abusers and friends thereof, and the answer is this kind of a movement won't be tolerated. We are simply not going to unban a bunch of such people just because some of them decided to start a ruckus about how so many abusers in Turkish DD scene are banned. We would rather deny all appeals (stemming from this) for a while if this attempt was made. Now on to this - @anti98christ appeal denied, we won't unban you at this point. And to @mertcan4555 it's ironic to see a massive DD abuser like you, have DD abuser friends.. the apple doesn't fall far from the tree. Anyways, conclusion is that MTA won't tolerate a movement from DD abusers at this point. I see what is happening, and will fight it. I hope you all realize that.

I don't understand why the Turkish DD scene in MTA has so many people constantly looking for ways to abuse, cheat and gain unfair advantage.. it's like they have a higher percentage of players that cannot play fairly without tools, exploits and lag switches. These people got themselves banned by their behavior, some of them never stopped (got temporary bans many times and still didn't learn) so they eventually got a permanent ban. Most of those people also were heavily invested in spreading abuse through the Turkish DD scene, by disseminating their abusive methods and tools whenever they managed to get working ones. It's clear that we work against those types of people, MTA can't keep detecting individual lag switches till infinity if there's a bunch of people creating new ones like a factory.. so then why not get rid of those people, for instance. In DD, lag switch has a huge impact (as the gamemode is ramming based) and opposed to cheats (that AC patches by methods used) you can't go beyond detecting these lag switches individually, as the "method" is system lag, which can have many types of causes - even bad network speeds, so if we stopped mopping with the tap open (a lot of people creating & modding a lot of DD lagswitches) and detect purely lag, AC can't be sure and this will result in false positives. As you can even manipulate ping and cause lag in ways that aren't bound to any application on your PC. Anyways, go figure - because we gotta detect them individually, bypassing these detections is possible by creating new lagswitches and heavily modifying existing ones, a practise done regularly by these bad apple players.. the exact thing that most DD abusers (banned) are engaged in. We didn't see any widespread initiatives from Turkish DD scene (server owners) to combat it either, they aren't sampling lag / packet loss with available script functions, or detecting micro freezes (e.g when the abuser is about to get rammed, they trigger it in order to absorb the hit) in order to kick them as violations above a certain threshold. So if there's a high percentage of wannabe abusers in their scene, and their own behavior (not able to play DD fairly) gets them banned from the game, then it's just "RIP", nothing we can do about it. If the types of people that play Turkish DD scene are like this, and the server owners don't have much interest to implement solutions (instead they fully rely on AC) or try to change these mentalities, then the reality just is how it is. I don't know who planted the bad seeds, and i also dont know if the reality is truly as bad as you're implying (about the lack of players in this scene). I rather think that Turkish DD scene was never really that big, and that you just happen to have a bunch of friends who are bad players and got banned, causing you to have this impression as the cause of not seeing much people to play with. Anyways, all "DD abusers" who got permabanned have gotten tons of chances (most of them even got a last chance after initial permaban following many tempbans from which they didn't learn - but yet they messed up again, and now are asking for a new "final chance" and so it will go on till infinity) so obviously we aren't planning to unban all of them at once, as you are pleading for. They aren't the type of players you, or any normal fair player, wants to be playing with. We protect fair play, so these people have to go, only those that have already demonstrated they will never learn, as others said in this topic as well, but something you seem not to believe. Try to get some fresh people into the Turkish DD scene, who can play fairly like normal players without having to find ways to abuse. Anyways, i hope that my reply cleared some things up. We can't help it. Also just to clear up the gut feelings of a few people that have read your posts and suspected you also weren't a normal DD player: yes, we know you also have used exploits & abuse methods in DD before, having been banned multiple times (you.. @squen besides SquenN also known in DD scene as "Raimondex" / tuna1999..) and we know you have a lot of friends who did that more often. You have even been using stuff & trying to, during the past month, so very recently.. but this time i will act like i didn't see that (next time however, it will be over). So maybe you know more accurately why so many Turkish DD scene players are abusers, having been one and being surrounded by them. How can you say all these things if you're part of the problem?

That's fine.. only the changed serial is banned (so it can't be used) and as long you won't repeat this activity in the future, your main serial won't have a ban.

We are willing to give you another chance, but not before you stop trying to have this serial change. The reason i am saying this, is because you are either still running the spoofer in question, or it has made changes to your system that you'll need to revert (not our problem). After you completed this, post here @randomdude1313

"prolaps02": model ID 5846 (texture located in lawnbillbrd.txd) "heat_02:" model ID 4230 (texture located in billbrd01_lan.txd) use tools / search methods like this in the future: https://dev.prineside.com/en/gtasa_samp_model_id/ https://dev.prineside.com/en/gtasa_samp_game_texture/view/ https://textures.xyin.ws/index.php?page=textures https://www.google.com/search?q="prolaps02"+gta+sa https://www.google.com/search?q="heat02"+gta+sa

That's impossible, you must have something else going on (like another resource using the same skins)

That's simple client.lua: local radio = playSound3D(ent[2], ent[3], ent[4], ent[5], false, false) just change the first "false" to "true" (check looped from https://wiki.multitheftauto.com/wiki/PlaySound3D) So it becomes local radio = playSound3D(ent[2], ent[3], ent[4], ent[5], true, false)

This is where you should continue debugging by yourself, as i have hinted at before. It's almost becoming the same case as here (your other scripting help topic), so locked. All you are doing is pushing the code in our face, you're not making any effort to do something by yourself with the given guidance..

You should actually put in some effort to identify the material name (e.g using the tools i linked for doing that) Let me quote this part of the Scripting section guidelines topic, it sort of applies here: Locked

See https://forum.multitheftauto.com/topic/96390-¿gta-map-to-mta/ I wasn't very good to explain that in a simple way in 2017 - it is mapping with custom models. Basically, once you got the 3D models of the map in question, you apply them as you would load any other custom objects, face them physically and put them down in map editor. Due to you dealing with custom objects, they will look like them with the exact dimensions they are, making it possible to attach them to eachother and lay down the custom map in editor. The resulting .map file and a script to always load the required 3D models (for players) is your end product then. Example resources that do exactly this (custom maps ported to MTA from another game): 1) Akina 2) Okaru Just take a look at those aspects (the 3D models txd/dff and .map file loading them to resemble the map). Now like SpecT said, you will either need to be a modeller / mapper to make such a map, or find/hire people that are to help you.

Each icon / blip is a GTA texture, so replacing the texture of that specific one with an alpha texture (transparant) should do the trick. That technique is also known as "texture removal (shader)" - instead of messing with the radar / map TXD's, simply use a shader to apply the alpha texture. Example of texture removal shader: client.lua theTechnique = dxCreateShader("shader.fx") alphaTexture = dxCreateTexture( "tex/alpha.png") function textureRemovalShader() engineApplyShaderToWorldTexture(theTechnique, "texname") dxSetShaderValue(theTechnique, "gTexture", alphaTexture) end addEventHandler("onClientResourceStart", resourceRoot, textureRemovalShader) shader.fx texture gTexture; technique TexReplace { pass P0 { Texture[0] = gTexture; } } alpha.png (transparent alpha texture itself): download You will clearly have to identify the material name of that radar icon you wish to remove (in order to edit "texname", the texture to apply transparent alpha to) and you can do that with the help of tools like shader_tex_names or Prineside texture view / Prineside ID search (which also provides an overview of textures per thing).

Bad argument @ 'getElementData' [Expected element at argument 1, got boolean] In this context, (boolean) means the element which you're checking isn't valid, as it's false (which is a boolean value). Apparently you are using elementdata on markers (bad practise itself) and since you're checking element data of source (in onClientMarkerHit that is the marker itself) it probably means the marker is no longer there when the check executes. So, most likely another piece of code (in that resource, or another) is interfering, such as destroying markers as soon it gets the chance, e.g when player enters it. This is why we still cannot help you, as you haven't posted full scripts including any other relevant ones that handle your marker stuff. For entire gamemodes or many potential culprits that is understandable though, and the reason why first learning basic scripting & debugging for yourself is a very good idea. Otherwise, you will need to put some effort in and come up with the most likely culprit to ask for further help on, if you cannot immediately spot the bug. I guess that rather this whole thing is effort related - this type of issue is 1 of the easiest to debug, why don't you follow the leads yourself? As going this route so far isn't going anywhere, you should look at either what you tell us (or how so) in this topic or the reason you're not digging into your script. Think about the script's logic, like i described a part of it.

Please read the Advice paragraph (bottom part) in the Scripting forum guidelines topic, or else i doubt anyone can help you. We need corresponding line numbers (from debugscript to code) and the full script.

You probably gotta wait for MTA to lift some limits (when it comes to dynamic ID assignment, thus unlimited) that already got done on various types of models, but can easily be done for upgrade parts in the near future as well. Even though some development manpower is delegated to that sort of stuff (with several related drafts/pull requests open) maybe it would be helpful if you add another issue to tracker specifically for this. Currently, applying GTA upgrade parts is limited to the upgrade part IDs bound to that vehicle (as i described in my first post) which means there's just a few IDs to mod or apply per vehicle that supports tuning.. however, some servers have worked around it by using custom upgrade part systems, that don't utilize upgrade part IDs at all (more like attach a custom bumper to where it's supposed to be). If you're a scripter you should be able to figure out how to implement such a thing.

Mixing upgrade parts from different cars will obviously produce wrong results or crash the game, as they aren't made for eachother. You should already be able to do what you have in mind (with replacing upgrade parts / loading custom upgrade parts made for that vehicle which you're applying them to). Often it's even neccesary, as GTA vehicle mods sites offer many models that come with multiple smaller DFF files, which are the upgrade parts designed for their mod, so you'll need to 'port' them to MTA by using a script that replaces it all. You can better understand this stuff after inspecting this example resource that i uploaded: https://community.multitheftauto.com/index.php?p=resources&s=details&id=18483 Just look at the code and files. It's a Jester mod, that also loads various upgrade parts, such as rear and front bumper. It's a piece of cake, and you don't need to be messing about with anything like carmods.dat Anyways, if you really want to "put Jester front bumper on a Sultan" (no matter how visually crippled that will look), in theory you would need to export the bumper part of Jester (e.g rbmp_c_j.dff, using Alci IMG tool) and load it onto the Jester as its own front bumper (ID 1169, fbmp_a_s.dff) simply by replacing the Sultan bumper model with the desired bumper upgrade part, in the same way as the above example resource does it. If you want to understand the logic better: Each vehicle in GTA SA supports only its own upgrade parts (specific IDs, like for bumper variants) so you can decide the model used for those IDs and applying any custom model to it (like one modelled by yourself, so looking as entirely different bumper). You cannot apply the upgrade ID from another vehicle, to a vehicle for which that ID is not (take a look at Wiki: Vehicle Upgrade IDs or alternatively use GTA SA Prineside ID lookup) Just for reference, script from that resource separately: function replaceModel() txd = engineLoadTXD("559.txd") engineImportTXD(txd, 559) dff = engineLoadDFF("559.dff") engineReplaceModel(dff, 559) end addEventHandler("onClientResourceStart", resourceRoot, replaceModel) setTimer(function() -- rear bumper upgrades dff = engineLoadDFF("tuning/rbmp_a_j.dff") engineReplaceModel(dff, 1159) dff = engineLoadDFF("tuning/rbmp_c_j.dff") engineReplaceModel(dff, 1161) -- front bumper upgrades dff = engineLoadDFF("tuning/fbmp_a_j.dff") engineReplaceModel(dff, 1160) dff = engineLoadDFF("tuning/fbmp_c_j.dff") engineReplaceModel(dff, 1173) end, 5000, 1) After replacing upgrade parts with your desired custom model, all you need to do is use addVehicleUpgrade (with the ID of where you applied the mod to) as @Tekken mentioned.

Don't lie Temporary bans cannot be appealed, but as the ban reason says, the next time you're going to perform the same activities (testing lagswitches if they are detected & building your own lagswitches) you will get a permanent ban If you do something, accept the consequences @rianhday

It appears that you're a game cheater (as in: any other game) which has led to you using a spoofer in the past. This spoofer made permanent changes to your system. From here on, it's your responsibility to make sure no spoofers are running, and that any of such potentially permanent changes are undone. If you cannot pinpoint them for reversing manually, the only solution is to completely re-install Windows. As it's not a problem on our side, that is the best advise we can provide (no technical support). Hope it helps anyways, @Lerdi Learn a lesson from this: don't be a cheater in any game, and using tools that cheaters need can mess up some stuff in your OS. Edit (for others searching this): The ban reason HW SPOOFER MADE PERMANENT SYSTEM CHANGES (IN THE PAST?) RESET OS is for a type of spoofer that we now confirmed to be 'bad', as in: it does irreversable damage by changing HW values in Windows OS, without ever restoring them to original.. not even if you turn it off or remove the spoofer. So, as far we know this type of spoofer forces you to reinstall Windows cleanly to reverse the permanent system changes, which again is your responsibility, also for understanding this is neccesary (most people that hear this will try to push for support further). If you want to avoid such things in the future, dont be a cheater so you dont need tools like HW spoofers that do messy things on your PC that may cause a violation with some anticheats.

Since recently, we regularly ban massive forks cheaters (dedicated cheaters, that make others miserable on forks) and then we manually activate some of the official MTA serial security / anti global ban evade measures to these individuals. This means that while many forks cheaters expect they can easily bypass their ban (not a big surprise, see forks), we are literally ending some of them for good. This is to help forks with their massive cheater problem. None of these bans will ever be reconsidered, they are final. Btw, your 'friend' appealed for you as well, at https://forum.multitheftauto.com/topic/130895-глобальный-бан-forks-cheater/ .. no further appeals about your ban, no matter who posts it, will be considered.

Since recently, we regularly ban massive forks cheaters (dedicated cheaters, that make others miserable on forks) and then we manually activate some of the official MTA serial security / anti global ban evade measures to these individuals. This means that while many forks cheaters expect they can easily bypass their ban (not a big surprise, see forks), we are literally ending some of them for good. This is to help forks with their massive cheater problem. None of these bans will ever be reconsidered, they are final.

Since the ban is issued on behalf of @.:CiBeR:., he'll handle this appeal soon. Although that's not required, as you haven't followed the instructions. Instructions in ban reason window, to contact him through Discord.

No This proves once again that MTA global bans are harsher than bans in other games.. you cannot evade them as easily as you'd expect. You're not sorry, you only regret this reality. There are people actively looking for ban evades. Changing a lot of stuff or using a different PC usually won't work here, sorry bud.

Changed serials are considered inauthentic and subject to permanent bans. This isn't our problem, you should ensure that any spoofer you used is no longer running, and otherwise make sure that permanent system changes done by said spoofer are reverted (even going as far as to re-install Windows, if you can't figure it out - again, it's not our responsibility). Global bans on changed serials won't be removed, they serve to ensure the changed serial can't be used.

You're a massive cheater on forks and also recently brought your bad activities to official MTA, therefore we have ended you. What does that mean? It's for massive forks cheaters/serial changers (where both of these practises are fairly easy on forks) which caught our attention and to which we have applied stronger measures (against serial changing / ban evading) so they will be unable to continue like they are used to. This is why you constantly failed when trying to evade over 10 times during the past month. No, we won't unban you. At most, you are sorry for not being able to evade again, and also you're lying in your appeal about not having done anything. @1rg999

Just the changed serials are banned, what you should do is make sure all traces of the spoofer are gone (if it made permanent changes to your system, you should re-install Windows) but we're not going to get out of our way to help a forks cheater / dev to be able to use their changed serials (we're not gonna unban them, or whitelist you). All of the problems are on your side here. Obviously, when a serial change is detected, the 'fake' serial gets banned so it cannot be used. If you have solved the problem by yourself, you really should stop those practises or else we will go out of our way, but in a negative sense: to make sure you will be fully banned (and not able to return, not even on your real serial), in order to help forks protect themselves against you.

It's better for forks if we don't unban you.. forks have a really weak anti-cheat and you pose a danger to it. Since we want to help forks wherever we can, we don't have any plans to unban forks cheat developers. @coderally