Search the Community

Showing results for tags 'opensource'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • RAGE Multiplayer
    • Announcements
    • Discussion
    • Suggestions
    • RDR2 Multiplayer
  • Scripting
    • Scripting
    • Resources
  • Community
    • Support
    • Servers
    • Media Gallery
  • Non-English
    • Русский - Russian
    • Français - French
    • Deutsch - German
    • Espanol - Spanish
    • Română - Romanian
    • Portuguesa - Portuguese
    • Polski - Polish


  • Scripts
  • Gamemodes
  • Libraries
  • Plugins
  • Maps
  • Tools

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



About Me






Found 3 results

  1. Hey everyone. Here are some super annoying RAGE client-server-browser communication pitfalls that most of you will probably recognize: Communication mechanisms between different contexts on RAGE are limited. The server can only communicate to clients, browser instances can only communicate to the local client, and the client can communicate with either. In order words, you can only send messages in a single step. You can't send some data to the server directly from a browser instance or vice-versa. There are a couple of things you could do, like routing every single event through the client or setting up an HTTP server on top of your game server and using AJAX calls within the browser. Let's not go there... that's really messy. Unable to get result from event triggers. RAGE treats all events in a "send it and forget it" fashion. That means you can trigger an event on a local or remote context, such as the server, but then that's it. The only way to see how the server handled the request is to make another event handler on the client, then have the server trigger the event with the result. But what if the remote event is called multiple times? How does the "result" event handler know which request it's seeing the result of? Now imagine the same situation, but you want to ask the server something directly from a CEF instance. Now, you have to send an event to the client to tell it to send an event to the server, only to get the server to send an event back to the client which also should send an event back to your browser. AND you have to keep track of different requests so that the relevant result handler gets called. Oh my god. This can get really complicated, really fast. Here's a surprise: these are now all issues of the past! Yesterday, I decided to go at these problems head-on by writing rage-rpc: a universal, asynchronous Remote Procedure Call (RPC) implementation for RAGE. For those of you who are unfamiliar with the term and don't feel like hitting that link (I don't blame you), RPC is a mechanism that lets a context call a function on a remote context, and then retrieve the result of the remote function. It's not as complicated as it sounds, trust me. Here are some feature highlights of rage-rpc: Universal. There is one small library (<5 kb) that you can include in any context: browser, client, or server. Multi-step communication. Any context can send data to any other context. Browser instances can directly message the server. The server can directly send data to any browser instance of a specific player. Asynchronous result retrieval. Registered functions can return any JSON-able value, and it will get immediately passed back to the caller in the form of a Promise. This means that the client can ask the server for something, wait for it to finish executing, and then see the result in-line. No more need to set up multiple events and track requests just to get a simple response from a remote context. The bottom line is: any context can call a function that resides in any other context and immediately get access to its return value without any extra work. Enough of the chit-chat. Let's dive into some code examples. I'll post a comment on this post with plain RAGE event versions of each example. Beware. Installation You can download the minified JS bundle from the GitHub page or install the package with NPM. npm install -S rage-rpc Example 1: Client --> Server Let's start simple. Say we want to get a list of license plates of all vehicles on the server. We could do this on the client, but it might not always work if some vehicles aren't streamed in. For reliability, we want to ask the server to provide this list for us. Here's the client-side code: /* Client */ const rpc = require('rage-rpc'); rpc.callServer('getAllLicensePlates').then(plates => {', ')); }); Yeah. That's it. Seriously. Take a look at the server: /* Server */ const rpc = require('rage-rpc'); // the callback will be called, and the result will be sent back to the client automatically rpc.register('getAllLicensePlates', () => mp.vehicles.toArray().map(veh => veh.numberPlate)); That is all. Requests are matched up all under the hood. There are no events for you to handle or request IDs to manage. The client-side code is actually 100% compatible in the CEF environment also. No code changes anywhere. Example 2: Server --> Browser Imagine we want to get/set the value of some input field defined in some CEF instance of a player, but we're on the server. There are definitely better examples than this, but this isn't a common issue to begin with. Let's dive in and start with the browser code. You can define this in any CEF instance. /* Browser */ // assuming you're loading rage-rpc via script tag, "rpc" will be a global variable. // or if you're using a bundler like Webpack: //const rpc = require('rage-rpc'); const $input = $('#input'); rpc.register('getInputValue', () => $input.val()); rpc.register('setInputValue', val => $input.val(val)); For client-side, there is no code, but the module just needs to be required somewhere. This is because the browser has to route through the client to get to the server and vice-versa: /* Client */ require('rage-rpc'); Now for the server-side part: /* Server */ const rpc = require('rage-rpc'); const player =; rpc.callBrowsers(player, 'getInputValue').then((value, info) => { // notice the "info" variable. this is an object that contains various information about the callee such as: // - id: the internal unique ID associated with the request // - player: the player who called this function, if remotely called from CEF or client // - environment: the environment that called this function. one of "cef", "client", or "server". in this case it would be "cef" console.log(`The value of ${}'s input is ${value}!`); rpc.callBrowsers(player, 'setInputValue', 'pooooop'); }); When you use callBrowsers, the client iterates over every browser instance until it finds a browser that has defined the procedure we're looking for, then it calls the first one it finds. This is why you can define the procedure in any browser instance, because technically each CEF instance is a completely separate context. You can even use callBrowsers from inside a CEF instance to communicate with other CEF instances. The API is the same as above, but you just leave out the player parameter from callBrowsers. Changelog 0.1.0 ADD: Bundled Typescript definitions IMPROVE: CEF outgoing call returning performance IMRPOVE: callBrowsers performance on all contexts FIX: Some code simplifications 0.0.3 FIX: Bug that prevented multiple resources from using RPC at the same time FIX: False alarm for multiple CEF instances receiving the same result ADD: Extra player verification for outgoing server calls 0.0.2 FIX: UMD exposing for correct Node.js importing 0.0.1 Initial commit Conclusion Please try it out and let me know what you think. This system makes communicating with remote contexts a breeze. And remember, you can call code on ANY context from ANY other context with rage-rpc. Also as a reminder, this is the very first iteration of this library as it was only made and tested within one day. I have some ideas for more features to incorporate in the future. Check out the GitHub page for more implementation details and API documentation: If you have any questions, comments, or issues, contact me on Discord: micaww#3032 You can also use the issue tracker on the GitHub page for feature requests and bugs.
  2. Sehr verehrte EntwicklerInnen, wir sind ein Team, das sich schon bei Arma 3 das Ziel gesetzt hat, möglichst authentische Voraussetzungen für gutes Roleplay zu schaffen. Wir entwickeln unser Framework dabei gerade nicht nur für unseren Server, sondern für alle, die es nutzen wollen. Dazu veröffentlichen wir u.a. unsere Arbeit auf GitHub unter der GNU AGPLv3 Lizenz. 51st State ist für all jene gedacht, die den Open Source Gedanken unterstützen wollen und auch sonst geistig mit unseren Ideen und Visionen verbunden sind, dass Inhalte also für viele entwickelt werden und der Sache dienen sollen, nämlich unser RP uneigennützig und dennoch effizient vorwärts zu bringen. Klar kann jeder sein eigenes Süppchen kochen. Wir glauben jedoch daran, dass je mehr nach dem Open Source Prinzip arbeiten, desto besser das Spielerlebnis für die gesamte GTA RP Community wird. Von daher würden wir deshalb auch gerne mit Entwicklungsabteilungen von anderen Communitys zusammenarbeiten oder kooperieren. Weitere Informationen zu unserem Projekt findest du in unserer Servervorstellung (s. Link unten). Wie bereits in unserer Servervorstellung erklärt wurde, besitzen wir bereits ein ausgefeiltes Konzept, welches primär die Förderung von Roleplay durch technische Gegebenheiten vorsieht. Darunter fallen z.B. Features wie ein Housing-System, ein Lagersystem oder ein einfaches Smartphone. Viele dieser Funktionen und Features befinden sich noch in Entwicklung. Genau aus diesem Grund suchen wir Dich als Entwickler! Wir wollen zweierlei Dinge: Wir wollen unser öffentliches Projekt voranbringen und wir wollen einen bespielbaren Server mit einer ersten funktionierenden Version so zeitnah wie möglich veröffentlichen. Deshalb suchen wir Dich als leidenschaftlichen Entwickler, der gerne an einem OpenSource Projekt mitarbeiten will. Wir suchen Entwickler in zweierlei Hinsicht: Einerseits möchten wir auch Dritte, die nicht Teil unseres Teams sind, dazu begeistern an diesem Projekt mitzuwirken. Andererseits suchen wir Entwickler, die daran interessiert sind, unserem Team beizutreten. In jeder Hinsicht ist es eine Win-Win-Win-Situation für alle Beteiligten: Wir profitieren von der Mitarbeit an dem Projekt, Dritte profitieren an der Mitwirkung an diesem Projekt und natürlich auch Du als Entwickler. Wir suchen Dich als Frontend- und/oder Backend-Entwickler! Du solltest für die folgenden Aufgabenbereiche folgende Kriterien erfüllen: Frontend-Entwickler (TS): Für unser Frontend - sei es für Webbrowser oder GTAV - suchen wir Angular 2+ Entwickler. Dementsprechend solltest Du als Frontend-Entwickler über Kenntnisse in JavaScript/TypeScript besitzen. Darüber hinaus fassen wir unter einem Frontend-Entwickler auch diejenigen, die clientseitig für GTAV entwickeln. Wir nutzen dazu derzeit TypeScript. Backend-Entwickler (C#): Als Backend-Entwickler solltest Du dich in C# auskennen und solltest mit dem SCM git umgehen können. Optional wäre es von Vorteil, wenn Du bereits mit Datenbanksystem (in unserem Falle PostgreSQL) gearbeitet hat. Unser Angebot: Wir bieten Dir eine freundliche und ehrliche Atmosphäre im Team und darüber hinaus bieten wir Dir auch Continuous Integration für Repositories (GitHub, GitLab) an, sowie auch einen Aufgabenplaner (Wekan) und stellen Dir eine private GitLab-Instanz bereit. Wenn wir Dich mit unserem Konzept und unserem Plan überzeugt haben, oder Du noch mehr zu unserem Projekt erfahren willst, dann schreibe mich auf Discord oder hier im Forum an oder besuche uns auf unserem Teamspeak 3 Server. Viel Glück und viel Erfolg beim weiteren Entwickeln, Vincent H. / @TheMysteriousVincent Leitender Entwickler bei 51st State Discord: TheMysteriousVincent#0650 Wichtige Links: 51st State Servervorstellung: 51st State auf Teamspeak: 51st State auf GitHub:
  3. Hey there guys! I recently created some docker images for the RageMP server for a project where I am involved at. In the project, we currently use those Docker images to deploy test-servers in our infrastructure. The main advantage of the Docker image is that the RageMP server can be run on any operation system - regardless of whether it is Windows, some Linux distribution or MacOS. You simply can deploy your Docker container with Docker everywhere. Furthermore, you can build upon the given Docker images by copying your binaries or source files into the base Docker container. That is the how [email protected] deploy our testing server. See the Docker reference for more information on Docker itself ( Of course, our Docker images are available at DockerHub (nevermind that DockerHub is a bit slow compared to, too: I've created two seperate Docker images: The first image, which is basically just the plain RageMP server without any bridge or whatsoever (see the Links below). The second image, which is the RageMP server plus the C# bridge (see the Links below). Side note: Both Docker images use the base Docker image "debian:stretch" and so the RageMP server is run on Debian Stretch in both images. If you want to know, how we use Docker images in production, visit the GitHub repository of our project (see the server repository in the Links below). Our server files are OpenSource. This means, also you can use our files if you publish your changes under the same license in public. If want to get in touch with our projects concepts and ideas, see the readme files of our repositories. Our project currently only focuses on German speaking players. If you want to contribute to our project, then go right ahead. Otherwise, have a great day with our Docker images. Sincerely ~Vincent Docker image for the default RageMP server: Docker image for the bridged RageMP server: Our project on GitHub: Our server repository on GitHub: P.S.: if there is any problem with uploading the RageMP server files to a public mirror like DockerHub, please message me so that I can take those images offline.