PhrozenByte

First of all: Naturally you don't have to use it, I do not intend to change anyones debugging preferences. The main goal of this resource is to allow both on-the-fly debugging on productive systems and keeping the server logs clean. Many resource developers use some global variable in LUA (e.g. DEBUG_MODE) to enable/disable their debug messages. The main disadvantage of this approach is that you can't enable debugging without restarting the resource (i.e. on-the-fly debugging). Depending on the resource and its ability to cleanup when being stopped, this might break its functionality or makes the issue you're trying to debug disappear. Using outputChatBox() furthermore shows the debug message to all players - something you definitely don't want to when debugging an issue that encounters only on productive systems. That's the reason why MTA supports the outputDebugString() function. However, this function doesn't really check whether a user is actually debugging and floods your server log all the time (i.e. keeping the logs clean). The resource furthermore allows you to send client-side debug strings to the server (serverLog() functions) and provides some very helpful debugging functions (dump() and get() - which I forgot to mention... I'll edit the post appropriately). Another big feature of this resource is on-screen-logging. It's quite impossible to debug a resource which uses the onClientRender() event. This resource adds a great technique to debug such features and even allows you to calculate means (e.g. to update a value just once a second so you can actually read it). The above screenshot shows on-screen-debugging in action, it shows the debug gravity information of the magnet marker of PhrozenByte Stunt Drag Markers at the top of the screen. And not to forget: It's open source.

PhrozenByte Debug is a is a free software utility resource allowing resource developers to add "quiet" debug messages to their resources. MTA's built-in debug mechanism (outputDebugString() function) floods both the server console and log with debug messages - even in productive environments. This bears the danger that a server administrator misses important messages in his server log. This utility resource hooks into MTA's built-in /debugscript command to detect whether a (authorized) player is currently debugging MTA. If this is the case, it passes all debug messages to MTA's outputDebugString() function; otherwise it discards them. Download: https://community.multitheftauto.com/index.php?p=resources&s=details&id=13657 GitHub repository (source code): https://github.com/PhrozenByte/mtasa-debug PhrozenByte Debug exports the following server-side functions: int getDebugLevel() bool log(int level, [ player fromPlayer = nil, ] string message, [ int red = 255, int green = 255, int blue = 255 ]) bool notice([ player fromPlayer = nil, ] string message, [ int red = 255, int green = 255, int blue = 255 ]), warn(…) and error(…) It furthermore exports the following client-side functions: Client-side debugging: int getDebugLevel() bool log(int level, string message, [ int red = 255, int green = 255, int blue = 255 ]) bool notice(string message, [ int red = 255, int green = 255, int blue = 255 ]), warn(…) and error(…) Server-side debugging: void requestServerDebugLevel([ element callbackElement = resourceRoot, ] string callbackEventName) bool serverLog(int level, string message, [ int red = 255, int green = 255, int blue = 255 ]) bool serverNotice(string message, [ int red = 255, int green = 255, int blue = 255 ]), serverWarn(…) and serverError(…) On-screen debugging: int getOnScreenLogCount([ string column = nil ]) int initOnScreenLog([ element sourceResource = nil, ] string message, [ int pauseUpdate = 0, mixed textAlign = "center", int red = 255, int green = 255, int blue = 255, int alpha = 255 ]) void clearOnScreenLog(int logID) bool updateOnScreenLog(int logID, table data, [ string calcMode = nil ]) bool simpleOnScreenLog(string message, table data, [ mixed textAlign = "center", int red = 255, int green = 255, int blue = 255, int alpha = 255 ]) Last but not least it exports the following shared functions: void dump(mixed variable, [ string name = nil, int level = 3 ]) string get(mixed variable) When you're experiencing problems with PhrozenByte Debug, please don't hesitate to create a new Issue on GitHub. If you're a developer, you can help make PhrozenByte Debug better by contributing code; simply open a new PR on GitHub. Contributing to PhrozenByte Debug is highly appreciated! License PhrozenByte Debug is free software, released under the terms of the GNU Affero General Public License version 3 (GNU AGPL). This license offers you maximum freedom to modify the software and create derivatives to fit your needs. However, you must comply with some conditions regarding the disclosure of your modified source code. Please refer to our License tl;dr on GitHub for details.

PhrozenByte Stunt Drag Markers is a free software MTA:SA resource allowing mappers to add scripted events to their maps. Download: https://community.multitheftauto.com/index.php?p=resources&s=details&id=13658 GitHub repository (source code): https://github.com/PhrozenByte/stunt-drag-markers This resource was primarly developed for MTA's Race gamemode, but should, at least basically, work with any other gamemode. The resource fully supports MTA's official map editor by allowing mappers to freely place Stunt Drag Markers (SDMs) in their maps. Everything is very easy to use and doesn't require any deeper knowledge of the technology behind. Simply… download the resource archives of stunt-drag-markers and phrozenbyte-debug (simply check the phrozenbyte-debug checkbox when downloading PhrozenByte Stunt Drag Markers), move them to the resources directory on your computer (server/mods/deathmatch/resources/ in MTA's installation directory), start MTA's map editor, click on the Definitions icon and add PhrozenByte Stunt Drag Markers to your map, scroll your mousewheel on the buttons in the bottom-left corner until you reach the Stunt Drag Marker buttons, and place Stunt Drag Markers in your map. After you've created your map, upload the map resource, the stunt-drag-markers resource and the phrozenbyte-debug resource to your server and move them to MTA's resource directory. That's it! PhrozenByte Stunt Drag Markers currently supports the following markers: sdmText: Creates a custom text on the player's screen when he hits the marker. sdmMagnet: Turns the vehicle's wheels into an magnet, i.e. allows a player to drive a vehicle on walls and even the ceiling. sdmGravity: Changes a vehicle's gravity. sdmTeleport: Teleports a player's vehicle to the position of the matching sdmTeleportTarget marker. sdmHealth: Changes the health of a player's vehicle. You can repair it, make it burn or blow it up, depending on the health you set. sdmSky: Changes the sky color for an player. sdmWater: Changes the water color for an player. It additionally adds the following map settings: skyTopColor and skyBottomColor: Changes the sky color for all players. waterColor: Changes the water color for all players. gravity: Changes the gravity on the server. When you're experiencing problems with PhrozenByte Stunt Drag Markers, please don't hesitate to create a new Issue on GitHub. If you're a developer, you can help make PhrozenByte Stunt Drag Markers better by contributing code; simply open a new PR on GitHub. Contributing to PhrozenByte Stunt Drag Markers is highly appreciated! You can e.g. make the resource work with other gamemodes. License PhrozenByte Stunt Drag Markers is free software, released under the terms of the GNU Affero General Public License version 3 (GNU AGPL). This license offers you maximum freedom to modify the software and create derivatives to fit your needs. However, you must comply with some conditions regarding the disclosure of your modified source code. Please refer to our License tl;dr on GitHub for details.

Hi, some days ago I've changed my password on https://community.multitheftauto.com/ what left me an unusable account: neither the new nor the old password work. So I've tried the password reset function and after not receiving any e-mail, I've checked my mailserver log. Your mailserver setup is broken, the mailserver sends a invalid HELO command: Sep 11 16:34:31 *** postfix/smtpd[14834]: NOQUEUE: reject: RCPT from ds9.modpro.be[213.239.211.202]: 450 4.7.1 <aventine.localdomain>: Helo command rejected: Host not found; from=<[email protected]> to=<***> proto=ESMTP helo=<aventine.localdomain> Depending on the configuration of the receiving mailserver all e-mails from MTA's community are either completely rejected or treated as spam. Please fix your mailserver setup. If you're e.g. using Postfix, you will have to change the myhostname parameter to a valid FQDN that resolves to your server's IP address (e.g. ds9.modpro.be). Greetings

Hi, I would like to make a suggestion for using GitHub more efficiently: Never use rebase on public branches, you'll lose history. Use merge instead (personally I even prefer with --no-ff) - this allows you to easily track development between many branches. Rebasing should only be used on private branches (= branches that exist only on your computer; that's the so called "golden rule of rebasing"). A simple example: The commits 9476d2f and 1d79b4f are the same - but Git doesn't now that. GitHub will always tell you, that master and 1.4.1 branches aren't in sync. It says about the 1.4.1 branch: "This branch is 24 commits ahead, 61 commits behind master". Why is it 24 commits ahead? Does that mean, that some commits (e.g. bugfixes) weren't merged back into master and will appear again in the next release? No, it probably doesn't mean that, but you can't be sure. Don't use rebase. More information: http://geekblog.oneandoneis2.org/index. ... rom-rebase git-scm about rebasing: http://git-scm.com/book/be/v2/Git-Branching-Rebasing Even people which prefer rebase don't hide the downsides: https://www.atlassian.com/git/tutorials ... f-rebasing