Leaderboard

I think it's time to just stop playing. I've had this feeling for a while now and not that this raise change is anything that "made up my mind" neither is it an overreaction, it's simply the little extra thing that made sure that my previous judgement was correct. Ever since Kalcor came back people got to see the true him and while I could accept him responding unprofessionally on his forum, which he may as well do since it's his forums as he pointed it out, we also have a choice to simply not waste time on his "product" anymore and with recent changes maybe this is what he wishes; afterall he's getting older and older, and so are all of us who truely enjoyed this modification of San Andreas. I came back to SA-MP, developing my own gamemode (first gamemode from scratch to be precise) because I wanted to help a guy who really wanted to open a server and I did. But over the time I got reminded of how SA-MP really is, filled with people who are not playing fairly at all. There were servers coming onto our server advertising in /pm multiple time, people posting 3 times under "Server Advertisement" on SA-MP forums without any bigger consequences and things just piling up. Maybe this is how SA-MP has always been, maybe it's just become recently like this but it's not a place for me personally anymore which is why I am simply going to quit. I do realize that this won't really affect a lot of people but I thought of just voicing this out and perhaps "vent out" a bit in a place where I know my post won't be deleted for negative feedback

Back to CS and I'm dominating again

Hey! Welcome to SA:MP Roleplay. Within the next couple of days we will be touching up the script and allowing players who are interested in the server to get acquainted with our forums and features. Our expected release date is Saturday, September 30th, 2017. The server will be unlocked by 1:00 PM (Pacific Standard Time) and any players will be free to join. For now, you may use this thread for any questions or concerns you may have. Some threads you might be interested in: viewtopic.php?f=53&t=64 viewtopic.php?f=53&t=62 We're also looking for someone who has experience in leading and some degree of medical knowledge to take up leadership of the Los Santos Fire Department. The faction will be yours to lead and a forum will be made to allow you to organize the faction. If you're interested in the opportunity, feel free to PM joey or myself on the forums or Discord. Weapons Introduction: Players may carry up to 4 weapons at the same time. These weapons are their: primary weapon, sidearm weapon and 2 melee weapons. This means you cannot, for example carry: A Shotgun and a AK-47; An M4 and an MP5; This is done to have a sense of realism when role playing and being involved around weapon role play. One thing our development and staff agree with is that there has and always will be a demand for a higher weapon distribution count in SA-MP. After all, we all enjoy using weapons. However; allowing players to locate weapons with ease makes us hand out heavier punishments when players violate rules with their weapons. Primary weapons are: Shotgun Micro SMG/UZI MP5 AK-47 M4 TEC-9 Country Rifle Sniper Rifle Secondary weapons are: Colt 45 Silenced 9mm Desert Eagle Visible Weapons: You also have the ability to hide or place a weapon that you have on you! Large weapons like: a Shotgun, AK-47, M4, Rifle cannot be hidden and are visible on a player at all times. General commands are: /weapon /weapon hide [weapon id] - Hides your smaller weapons! /weapon adjust [weapon id] - Adjust your weapons position! /weapon reset [weapon id] - Reset your weapon to the default position (NOT IMPLEMENTED)! /weapon bone [weapon id] - Set your weapon to a specific bone (NOT IMPLEMENTED)! Dropped Weapons: We also have a feature for players to be able to drop their weapon on the floor. You could do this inside any interior and anywhere else. Any weapon is dropable and able to be picked up. General commands are: /leavegun OR /lg as an alternative to leave your gun! /grabgun OR /gg as an alternative to pick it up! Screenshots: Visible weapon! Dropped weapon! Death System Introduction: When a player takes enough damage; they're put into brutally wounded. From there, you may be saved, accept your death or be executed by your killer. When a player's brutally wounded, other players can examine that players damages. Commands: /damages [playerid/username] You must be near the player to check their damages and only when they're brutally wounded. Screenshots: [−] GIFS Introduction: A typical phone system that allows players the possibility to call and or SMS other players. We hope to expand the phone system with a graphical user interface in the near feature that should allow players a more unique experience in the near. Primary Numbers 911 Emergency Services 788-STOLEN-CAR Report a vehicle stolen to the Emergency Services Contacts: With our phone system, you may also have contact listings. You can add, edit and or remove contacts from you list. A player may currently have up to (15) contacts at once. This will no doubt increase if it becomes a popular demand. The commands: /contacts - Gives you a list of commands and their description. /contacts create [contact name] [phone number] - Allows you to create a new listings in your contacts. /contacts delete [contact id] - Allows you to remove a contact from the list. /contacts show [player id] [contact id] - Allows you to show another player your contact. /contacts display - Displays all your contact listings. /contacts edit [contact id] [name] [phone] - Allows you to edit a listing. Commands: These are the general commands of the phone system: /call [phone number OR contact] - You may call another number or your contact. /hangup - Hangs up the phone call or the phone while it gets called / calls. /pickup - Picks up your phone when it rings. /turn_on - Turns your cellphone on. /turn_off - Turns your cellphone off. Burner Phones It has its own documentation that could be found here. Weapon Order System: In beta revision 2.9.7.11 we introduced a number to the phone system that any player could call to order and receive a weapon. We understand that there has and always will be a demand for a higher weapon distribution count in SA-MP. After all, we all enjoy using weapons. This will allow players to receive weapons but also keep it fair. Players are restricted to (1) call per hour but (2) weapons during each call. The number to call for this will not be released but will require players to make a connection with other players to get the number of the order system. This system requires players to stay in character through out its entirety. First interaction call... 15 minutes later... After making an 'order', you receive a call and an SMS about the location of your order. You have eight (8) minutes to get to the location before the order is disregarded. An object spawns which a player has to be pickup at the exact market spot. The prompts rely on what the character says. If you give the wrong answer or say something that doesn't mean sense then the call will be disconnected. We hoped this would encourage players who use the system to learn the 'terminology' used in it. Not only can you order weapons but it also accepts firearm brand names (i.e: Ruger, Remington). We've compiled a list of the most commonly used brand names and hope it goes well. GTA-SA weapons are still accepted. 788-STOLEN-CAR System: In beta revision 2.4.4.8 we introduced a system that players could use to report the theft of their vehicle and also leave a permanent trace to it so law enforcement factions could follow up on it. We hope this this introduces unique opportunities to players who use the system. Like the Weapon Order System, the process requires the player to stay in character through out the entirety of it. When calling, you're given prompts to answer to an operator over the phone. Interaction... Introduction: The graffiti system enables players to utilize spraycans and tag over graffiti locations. There are over fifteen (15) graffiti locations around Los Santos and there will be more added in the future or if suggested by players. This system is particularly for illegal factions to have some role play with graffiti and leave an actual mark on their territory or enemy territory. How do you use it?! It's simple. Newer factions would need to PM an administrators to receive a spraycan. When you've received a spraycan, all you need to do is use /graffiti to set your text and then start spraying! General Commands: /graffiti Screenshots: Select your text... Start spraying! The dialog is kept short but we aim to increase it for better turns and provide a more sense of quality to players. Currently these are just systems which players may easily interact with without any hassle in the process. kane

Hello Multimart Community, I'd like to inform everyone of a few changes that will slowly be put into place regarding how Community Complaints will be handled, this is infront of our Custom Complaints system being developed and tested ready for functional use on the Forum... These changes may or may not effect Community Complaints massively from a Member Prospective, however from a Staffing Prospective we deemed is necessary to Moderate Post Replies, what this means is the following. Creation Of Threads will remain unchanged and no moderation will be required. Creation of comments/posts will now be moderated this will prevent "thread spam" from people who are not involved in the complain at all Old thread will now be archived after two weeks, after this period only staff(and maybe thread creators) will be able to view the complaint Unrelated replies will be soft-deleted meaning only staff can view the response, this is in case someone approves a reply that doesn't concern the poster Furthermore, on the topic of the Custom Complaints system that will be developed in due time... Here's a brief over-view on how it'll function. Creation Of Reports Members of the community will be able to freely create reports on other members of the community along with reasoning behind it, our goal is to "improve" the current reporting system provided by Invision Power (IP) allowing us to filter reports to specific reasons. Responses Once you've created a report on a specific user.. You and the reported person only with staff will only be able to reply to that report, unless a staff member adds another member of the community to the report for a specified reason, kind of how Personal Messages currently work with IP.Board allowing you to invite people to the conversation. Viewing Reports Once a report has been closed and marked accordingly by a member of the Staff Team at Multimart anyone in the community will be able to view it along with any attachments (this is the idea, we may restrict this to staff once an out-come has been assigned), this will also free up space when it comes to On-Going reports and reducing the clutter... Anyone who visits the Community Complaint system will be able to view the on-going reports but only Who's involved (staff not included) along with how many replies the Report has gotten from both the Reporter and Reportee as well as any staff Replies. So why is this system needed? Its been a long time coming with allot of planning on my end, as-well-as allot of research into how IP.Board functions when it comes to the current released version... I have allot of experience with the older version of IP.Board how-ever as with any "software" for the internet its internal code changes a lot during development, from version to version and security update to security update.. A lot of this research was to ensure that I personally understood how Other developers and IP.Board Staff/Developers handled internal security and coding practices to allow for the most secure "Addon" to Multimart Possible without opening up too many loop holes into the system (hopefully none)... Best Regards, Austin "TheOnlyDroid"

This article talks about some key factors to consider when designing a plugin system in C++, and also provides some practical examples of how we’ve addressed these issues in our own code. There’s a lot to cover here, such as binary compatibility, strict API versioning, and interprocess memory management. Sounds like fun right? Well, if you get it wrong then it sure as hell won’t be, sometime in the near future you’ll most likely have a suicide inducing customer support nightmare on your hands, but if you get it right then it’s really not so bad. If you’re looking for the code, we’ve released it as an open source LibSourcey module called Pluga on Github. ABI and Binary Compatibility The first thing to consider when designing your Plugin API is ABI compatibility. Unlike dynamically scripted languages, C++ demands that any shared libraries loaded by the runtime are binary compatible, otherwise all hell breaks loose. Essentially, this means that both the application and plugins must be compiled using the exactly the same development environment. If you can, try and stick to this one simple rule: only pass POD (plain old data) data types across process boundaries. By sticking to POD types the binaries will have no interdependent shared libraries, and you can avoid binary compatibility issues altogether. The tradeoff is that standard libraries differ from compiler to compiler, platform to platform, even version to version, so they should always be deemed to be binary incompatible. This means that unless you want to force clients to use exactly the same OS, compiler and third party dependencies as you when buildng plugins for your application, then you’ll need to avoid using STL containers or other complex types in your Plugin API. “But this is C++!?”, you cry in anguish, and unless you’re rockin’ a mullet with a stubbie cooler then who could blame you? Unfortunately that’s just the way it is, so in this case all we can do is bite our collective upper lip and move on. There are alternatives, such as embedding the standard libraries in your project using STLport or similar to ensure consistency between platforms, but why bother? It seems like overkill, wouldn’t it be easier to just to pass a void* or a char* buffer and encode/decode it as required across the process boundary? The method we’ve been using recently is actually quite simple. The plugin implements a onCommand method which accepts arbitrary commands from the application. The advantage of using this type of interface is that you’re able to implement almost any kind of functionality without having to add new methods and break the API each time you roll out a new feature. Obviously it doesn’t have it be this simple, but you get the idea! Command nodes (see code below) are namespaced using a REST style interface like so resource:action, and the data buffer contains either a JSON encoded message which for representing and converting to an STL container such a std::vector or std::map to pass to the internal API, or it may just be a raw data buffer that can be used directly. Take, for example, the following code: bool onCommand(const char* node, const char* data, unsigned int size) { try { // Handle a JSON encoded options hash if (strcmp(node, "options:set") == 0) { json::Value root; json::Reader reader; if (!reader.parse(data, size, root)) throw std::runtime_error("Invalid JSON format: " + reader.getFormatedErrorMessages()); // Do something with JSON data here... } // Handle raw file data else if (strcmp(node, "file:write") == 0) { std::string path("test.bin"); std::ofstream ofs(path, std::ios::out|std::ios::binary); if (!ofs.is_open()) throw std::runtime_error("Cannot write to output file: " + path); ofs.write(data, size); ofs.close(); } // Handle unknown commands else throw std::runtime_error("Unknown command"); } catch (std::exception& exc) { // Catch exceptions here and return false. // You could set a lastError string here which is exposed to // the application that returns the error message as a char*. // See the full example for details. std::cerr << "Command error: " << exc.what() << std::endl; return false; } return true; } Interprocess Memory Handling One other simple rule that will save you no small amount of frustration later on down the track is: any memory allocated by a process should be deallocated by the same process. Let’s say the application asks the plugin to allocate and return a char* buffer, and then proceeds to delete the buffer when it’s done with it. Honk! Big no no, you’re just asking for a crash. This is good: bool askPluginForSomeSugar(Plugin* plugin) { // allocate buffer of some sort char* data = plugin->gimmeSomeSugarBaby(); // do something cool with data // hand the pointer back to the plugin to be deallocated plugin->putSugarBackInTheBowl(data); } This is bad: bool askPluginForSomeSugar(Plugin* plugin) { // allocate buffer of some sort char* data = plugin->gimmeSomeSugarBaby(); // do something cool with data // don't manage memory data allocated by the other process! delete[] data; } Plugin System API The Pluga plugin system API consists of a single header file that defines a set of macros which export a PluginDetails structure. The PluginDetails structure exposes basic plugin information, a compile time API version, and a static initialiser function to the main application on runtime. By having an intermediary PluginDetails structure that’s loaded on runtime before the plugin is instantiated, we can do things like sanity check the API version, and print information about the plugin. Note that the system API also forward declares the IPlugin type, which must be defined externally in your own code. See the Plugin API for more information about that. // // LibSourcey // Copyright (C) 2005, Sourcey <http://sourcey.com> // // LibSourcey is free software; you can redistribute it and/or // modify it under the terms of the GNU Lesser General Public // License as published by the Free Software Foundation; either // version 2.1 of the License, or (at your option) any later version. // // LibSourcey is distributed in the hope that it will be useful, // but WITHOUT ANY WARRANTY; without even the implied warranty of // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the // GNU General Public License for more details. // // You should have received a copy of the GNU General Public License // along with this program. If not, see <http://www.gnu.org/licenses/>. // #ifndef SCY_Pluga_H #define SCY_Pluga_H #include "scy/base.h" namespace scy { namespace pluga { // Forward declare the plugin class which must be defined externally. class IPlugin; // Define the API version. // This value is incremented whenever there are ABI breaking changes. #define SCY_PLUGIN_API_VERSION 1 #ifdef WIN32 # define SCY_PLUGIN_EXPORT __declspec(dllexport) #else # define SCY_PLUGIN_EXPORT // empty #endif // Define a type for the static function pointer. SCY_EXTERN typedef IPlugin* (*GetPluginFunc)(); // Plugin details structure that's exposed to the application. struct PluginDetails { int apiVersion; const char* fileName; const char* className; const char* pluginName; const char* pluginVersion; GetPluginFunc initializeFunc; }; #define SCY_STANDARD_PLUGIN_STUFF \ SCY_PLUGIN_API_VERSION, \ __FILE__ #define SCY_PLUGIN(classType, pluginName, pluginVersion) \ extern "C" { \ SCY_PLUGIN_EXPORT scy::pluga::IPlugin* getPlugin() \ { \ static classType singleton; \ return &singleton; \ } \ SCY_PLUGIN_EXPORT scy::pluga::PluginDetails exports = \ { \ SCY_STANDARD_PLUGIN_STUFF, \ #classType, \ pluginName, \ pluginVersion, \ getPlugin, \ }; \ } } } // namespace scy::pluga #endif // SCY_Pluga_H Plugin API The plugin API defines the IPlugin class that’s forward declared in the Plugin System APIheader. The IPlugin class is the interface that the application uses to interact with the plugin, and as such it’s also the virtual base class that’s extended from when implementing plugins. Below is a bare-bones example that only implements a single onCommand method: // testpluginapi.h #ifndef SCY_TestPluginAPI_H #define SCY_TestPluginAPI_H #include "scy/pluga/pluga.h" namespace scy { namespace pluga { class IPlugin // Virtual plugin interface. { public: IPlugin() {}; virtual ~IPlugin() {}; virtual bool onCommand(const char* node, const char* data, unsigned int size) = 0; // Handles a command from the application. }; } } // namespace scy::pluga #endif Implementing Plugins Plugin implementations extend from the Plugin API interface to implement plugin functionality. // testplugin.h #ifndef SCY_TestPlugin_H #define SCY_TestPlugin_H #include "testpluginapi.h" class TestPlugin: public scy::pluga::IPlugin // Test plugin implementation. { public: TestPlugin(); virtual ~TestPlugin(); virtual bool onCommand(const char* node, const char* data, unsigned int size); // Handles a command from the application. }; #endif // testplugin.cpp #include "testplugin.h" #include <iostream> SCY_PLUGIN(TestPlugin, "Test Plugin", "0.1.1") TestPlugin::TestPlugin() { std::cout << "TestPlugin: Create" << std::endl; } TestPlugin::~TestPlugin() { std::cout << "TestPlugin: Destroy" << std::endl; } bool TestPlugin::onCommand(const char* node, const char* data, unsigned int size) { std::cout << "TestPlugin: Command: " << node << ": " << data << std::endl; // Process commands as required return true; } A Simple Application The following is a totally minimal example application that shows how to use the LibSourcey SharedLibrary class to load the plugin shared library, instantiate the IPlugin, call it’s methods, and destroy it. #include "scy/pluga/pluga.h" #include "scy/sharedlibrary.h" #include "testpluginapi.h" #include <iostream> #include <assert.h> using namespace scy; int main(int argc, char** argv) { // Set the plugin shared library location std::string path(SCY_INSTALL_PREFIX); path += "/bin/testplugin/testplugin"; #if WIN32 # ifdef _DEBUG path += "d.dll"; # else path += ".dll"; # endif #else path += ".so"; #endif try { // Load the shared library std::cout << "Loading: " << path << std::endl; SharedLibrary lib; lib.open(path); // Get plugin descriptor and exports pluga::PluginDetails* info; lib.sym("exports", reinterpret_cast<void**>(&info)); std::cout << "Plugin Info: " << "\n\tAPI Version: " << info->apiVersion << "\n\tFile Name: " << info->fileName << "\n\tClass Name: " << info->className << "\n\tPlugin Name: " << info->pluginName << "\n\tPlugin Version: " << info->pluginVersion << std::endl; // API Version checking if (info->apiVersion != SCY_PLUGIN_API_VERSION) throw std::runtime_error( util::format("Plugin ABI version mismatch. Expected %s, got %s.", SCY_PLUGIN_API_VERSION, info->apiVersion)); // Instantiate the plugin auto plugin = reinterpret_cast<pluga::IPlugin*>(info->initializeFunc()); // Call plugin methods assert(plugin->onCommand("some:command", "random:data", 11)); // Close the plugin and free memory std::cout << "Closing" << std::endl; lib.close(); } catch (std::exception& exc) { std::cerr << "Error: " << exc.what() << std::endl; assert(0); } return 0; } Installing Pluga For more detailed instructions and full working example see the Pluga insallation guide. All that’s requires is to build build LibSourcey with the Pluga module enabled. And there you have it, a super simple C++ plugin system that you can use in your own projects. Enjoy! Official Public Source: https://sourcey.com/building-a-simple-cpp-cross-platform-plugin-system/ Contributions Applied / Otherwise limited Liability.

Its already there... The most experienced members of the community are leaving or have already left; Myself included... Kalcor has a simple way of thinking and most of the Backend he developed on wasn't made by him

Please be aware that we're currently digging around the Forum Backend to find the stupidly hidden option that allows you to delete your own content within a certain period.... I'm not sure if its been removed since IP.Board 3.x as we're running IP.Board 4.x - Please hang on while I rip my eyes out trying to find it.

most of the weapon hacks work on here! come and have fun

Simple answer is and has always been... Kalcor is a massive prick who prefer's to be in a relationship with his right hand than actually get a life and move on letting someone take over the project or adapt it into something for GTA:5 - And as such is being a little brat when it comes to URL's because *cough* people have been moving over to GTA V MP and posting about it... He's a massive baby and will do anything to keep his "image" although that image in fundamentally flawed, as anyone who's been a member of the SA-MP community for any extended period knows how much of a dick he actually is... Imaginary or otherwise.