Search the Community

Showing results for tags 'library'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • 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

Categories

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

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me


Facebook


Youtube


Skype


Web


VK

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 => { mp.gui.chat.push(plates.join(', ')); }); 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 = mp.players.at(0); 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 ${info.player.name}'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: https://github.com/micaww/rage-rpc 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. Version 1.9.6

    70 downloads

    This library is discontinued and lacks some features. I'm working on a new remote call library which is faster and more secure Asynchronous Javascript Communication is a module to allow easy communication between server, client and CEF/browser. This module lets you call server handlers from clients (and vice versa) without dealing with adding and managing custom event handlers. You can easily call a handler and get your callback called as soon as everything is returned from the handler in a promise like way! Let's see how it works in action: // server side const ajcom = require("./ajcom") ajcom.register("getServerName", hCtx => { return mp.config.name }) // client side const ajcom = require("./[package name]/ajcom.js") mp.events.add("guiReady", () => { ajcom.callServer("getServerName").then((ctx, serverName) => { mp.gui.chat.push(`Welcome to ${serverName} ragemp server!`) }) }) That's all! Not convinced yet? See how the above code is done without ajcom: // server side mp.events.add("getServerName", (player) => { player.call("gotServerName", [mp.config.name]) }) // client side mp.events.add("gotServerName", (serverName) => { mp.gui.chat.push(`Welcome to ${serverName} ragemp server!`) }) mp.events.add("guiReady", () => { mp.events.callRemote("getServerName") }) See? It eases the event handling mess. But there's a lot more to ajcom. You can easily handle errors happening on handler's side or any of the callbacks, set delays and other stuff. The full documentation is available here Please post your questions and issues to the forum post Github repo
  3. Hello! Asynchronous Javascript Communication is a module to allow easy communication between server, client and CEF/browser. This module lets you call server handlers from clients (and vice versa) without dealing with adding and managing custom event handlers. You can easily call a handler and get your callback called as soon as everything is returned from the handler in a promise like way! Let's see how it works in action: // server side const ajcom = require("./ajcom") ajcom.register("getServerName", hCtx => { return mp.config.name }) // client side const ajcom = require("./[package name]/ajcom.js") mp.events.add("guiReady", () => { ajcom.callServer("getServerName").then((ctx, serverName) => { mp.gui.chat.push(`Welcome to ${serverName} ragemp server!`) }) }) That's all! Not convinced yet? See how the above code is done without ajcom: // server side mp.events.add("getServerName", (player) => { player.call("gotServerName", [mp.config.name]) }) // client side mp.events.add("gotServerName", (serverName) => { mp.gui.chat.push(`Welcome to ${serverName} ragemp server!`) }) mp.events.add("guiReady", () => { mp.events.callRemote("getServerName") }) See? It eases the event handling mess. But there's a lot more to ajcom. You can easily handle errors happening on handler's side or any of the callbacks, set delays and other stuff. The full documentation is available here and you can grab the module from here Github repo Changelog v1.9.6 (2018/3/7) added jsdocs for constructors added separate enums and classes for types used as parameters added noPostback flag added flags for handlers added special handlers (hooks) for server side handlers getting called added the ability to broadcast a call to all or specific clients added cef support added cross side logging fixed calling a handler with triggerDelay not being called fixed data.source and data.target having wrong values change the namespace so that users can use enums and classes v1.1.3 (2018/2/25) added jsdocs changed event handling codes fixed client > client call fixed some possible crashes (fake client calling server) v1.0.0 (2018/2/15): Initial release!