sbx320

Temporary bans cannot be appealed.

You can already do this with Lua coroutines. function pausableFunction(co) if not co then co = coroutine.create(pausableFunction) coroutine.resume(co, co) return end local function resume() coroutine.resume(co) end local function wait(time) setTimer(resume, time, 1) end outputChatBox("Countdown!") outputChatBox("3...") wait(1000) outputChatBox("2...") wait(1000) outputChatBox("1...") wait(1000) outputChatBox("Go!") end

Do you have a crash dump located in a "dumps/private" or "dumps/public" directory in your the MTA server folder?

The MTA codebase is entirely written in C++ with some parts written in inline assembly. The modelinfo array is referenced all across the game_sa and multiplayer_sa code, but Lua does not have direct access to any memory locations. All you can do from Lua is to call C++ functions, which then do something.

Try again with the latest 1.5.3 nightly. We had a change in r10816 which should resolve your issues.

It'll generally be slower, due to the additional overhead of calling a php script, which then needs to do the same work as MTA would do using dbQuery. Also allowing the client to save data via a web request is a terrible idea, because you're opening your server to allowing any client to store any information in the database (as I could just go ahead and use my Browser to store data, rather than the MTA client).

Metatables cannot be shared across resources right now. If you pass a table with a metatable across a resource boundary, the metatable is removed. There are basically two options to solve this. A) Move the database class into your resource B) Construct a wrapper class around exports which forwards all metatable calls to the database resource.

If you compile your script via luac.multitheftauto.com it should work. See https://forum.multitheftauto.com/viewtopic.php?f=91&t=78858 for more details.

You cannot load 32-bit modules with a 64-bit server. Multiarch only allows you to run 32-bit applications (e.g. the 32-bit MTA Server). Modules (Shared Objects (.so Files) and .dlls) can only be loaded into a server with matching bitness. To fix this you need to get the 64-bit ml_sockets from this page and put it into your server's modules folder.

There's actually a module which provides a system() function already. https://github.com/multitheftauto/multi ... /ml_system

Moving it to Client since it's clients crashing. The first crash info is related to a failure loading a sound for a specific ped (CAEPedSpeechAudioEntity::LoadAndPlaySpeech). All your MTA Diag logs indicate that the players are using a pirated version of gta, where some sounds were removed to reduce file size, so I suspect that the game attempts to load a specific ped related sound which doesn't exist in this ripped version.

https://wiki.multitheftauto.com/wiki/Where_to_buy_GTASA

The files you found on Github are mostly in the Vendor subfolder of the MTA source. The Vendor subfolder is used for third party components (Libraries/Code not written by us) like Lua and in this case especially Google Breakpad (used for Crashdumps on Linux). These libraries sometimes use other programming languages for build environments or support for other languages. There are no plans to add another scripting language.

There have been some events of people using serial changers as well as players with the same serial. Therefore I'd suggest to avoid using the serial as an account login. My personal solution for auto-logins would be similar to the following: Upon registration ask the user to provide username and password. Store the name and the hashed password in some database. Also create a random hash and store it in the database. Also send this hash to the client and store it there together with the username. On subsequent logins the user has two options: a) Login via Username and Password b) Login via Username and random hash

The setting was removed in some 1.3 version (somewhere around r3900). The network encryption is now always on.

Even with a non-genuine Windows 7/8/8.1 install you get the update notification. However you'll be upgraded to a non-geniune Windows 10. But if you really need a new Windows license the Insider builds were mostly stable for me during the preview phase. However keep in mind that new Windows 10 bugs may interfer with MTA and we're probably not fixing them unless the issue also appears in the stable release.

I've been deleting your comments since they were redundant and added nothing to the topic (which is the bug). Just telling us to please fix a bug or asking why anyone would do that is not helping anyone. If you have something useful to add (for example a script reproducing an issue or further useful details on it) you're more than welcome to add a comment. After all the better the bugreport is, the easier it is to fix. I'm usually available in the IRC chat as well as I usually respond to PMs here in the forum.

It is currently unsupported as Windows 10 is not officially released yet and Microsoft may fix outstanding issues with MTA in the OS itself, which would render our fixes pointless. Once the official release happens fixes in MTA regarding Windows 10 compatibility are likely to happen if needed.

dwThis or dwInterface are usually referring to the instance (e.g. a Vehicle). In your particular example you'll have to get a valid CVehicleSAInterface pointer into dwThis to specify which vehicle's engine you want to toggle. How you get this pointer depends on the vehicle you wish to modify. For example if you want to switch off the local player's vehicle you'll want to have a look at the global player structure.

This is not correct. There are breaking changes in 5.2 and 5.3 which will break (some) existing scripts. As a very simple example, the following code will error under Lua 5.2 while being totally fine in 5.1. print(unpack({1,2,3})) Also 5.2 and 5.3 introduce new opcodes which entirely break compiled files.

Upgrading Lua to 5.2 or 5.3 would cause quite some issues. Many servers are using old code which may be incompatible to newer Versions of Lua without several changes. Furthermore upgrading Lua would cause all compiled scripts to break, which would be a huge issue for servers using scripts which are not available as source code (as an example: many public race maps use compiled scripts for random things). If you're lacking some specific feature of 5.2 or 5.3 there's most likely a workaround or an alternative available.

Do you have a crashdump related to this crash?

This is most likely caused by a weapon desync. While you are shooting at the other guy, you don't have any weapon in your hands on his MTA, which leads in him not being hit. I'm not entirely sure what causes it tho.

The MTA Client always runs under a 32bit environment since GTA SA is a 32bit executable. As far as I know ASLR is active for MTA's libraries, but ASLR isn't designed to stop people from stealing your scripts. As long as you execute anything on the client it will be stealable, no matter how many layers of protection are added. In the end, Lua always needs to be able to execute the code. The current no-cache option plus encrypting your files over luac.multitheftauto.com should be enough to stop most script thiefs already. Those who have the ability to steal your scripts despite that are probably capable of implementing the same things you did on their own.

There's a list of changes in the Wiki: https://wiki.multitheftauto.com/wiki/Changes_in_1.4