Toliak

Thank you for reply! Sorry for a long response. Yes. The output messages will have the filename and line number of the error (in generated Lua file). Yes. The original line numbers and file names will be lost, if error happens in runtime. However, there are several solutions to debug the code: 1. (Hard) Look at lua context (function names, class names, variable names). The TypeScriptToLua (TSTL) library I'm using does not obfuscate or minimize the code, therefore, result Lua code is read-able. The user can match the Lua code and TS code and determine the error line. 2. (Simple) Lua itself provides debug.traceback function. TSTL wraps the function into its own and in runtime debug.traceback can be used in code to show the current full traceback log. If the user will combine p.1 and p.2, he will be able to debug his script in less painful way If you have some ideas, how can I improve the logs, you can write them here or in the issues.

I have released the 1.0 version of MTASA TypeScript project. Main changes - Upgraded the Wiki parser, OOP definitions and add generics (for event declarations or key binding) - YML format for meta file (with schema, so you will receive hints while filling it). Supports multiple resources in the same boilerplate. - Reduced steps to create a new project - Better linting for declared in meta files and client-, server- side import Quick Start 1. Steps to create a new project a) Install NodeJS from the official web site. b) Open a console in the resources directory and enter npx mtasa-lua-utils new-project Fill the inputs and select the feature you would like to use. That's all, you are ready to code 2. Available commands Since, there is a multiple resources support, you can use the command to create a new one: npx mtasa-lua-utils new-resource To build the entire project use one of the listed commands: npx mtasa-lua-utils build npm run build 3. YML format for the meta file info: name: TypeScriptResource # Name of the resource type: script # Resource type compilerConfig: srcDir: TypeScriptResource # src/TypeScriptResource will be the script root folder scripts: # Declarations of all TS files, used in the resource - src: client.ts type: client cache: false - src: server.ts type: server cache: false - src: utils.ts type: shared cache: false --- # Here you can put another resource declaration Schema for the YML file already prepared in the boilerplate for VSCode and WebStorm. Schema file location, if you would like to specify it manually.

Event Types Hinting I have implemented the types for events. Example code is available on GitHub Demonstration How To Use Event Handlers mtasa.addEventHandler<mtasa.Event./* specify the event type */>( /* the event name will be hinted automatically */, /* put the source element here*/, function (/* function arguments will be hinted */) { // Insert the payload }, ); Events trigger (with custom event, for example) export interface YourCustomEvent extends GenericEventHandler { name: 'MyCustomEventName'; // You can specify `const enum` for multiple names function: (this: void, ...args: any[]) => void; } mtasa.triggerClientEvent<YourCustomEvent>( /* put the source player (or root) */, /* the event name will be hinted automatically */, /* put the source element here*/, /* function arguments will be hinted */ ); What are you thinking about the idea? Is that interesting for you (and why, if not)?

MTASA Typescript I am developing utility packages for transpiling TypeScript into an MTASA-compatible Lua code. I would like to share that project to receive some suggestions and, I believe, to help someone in resource writing. Why Lua is not so good Classes. Lua does not support classes (syntax) from scratch. If you want to write OOP code with your own classes, you have to use metatables to implement class objects behavior. That's make the source code more complicated, than it could be. Hints (from your IDE). Lua is dynamic typed language, therefore, it's hard to determine, what the variable is and, hence, IDE cannot hint you function declarations, object methods and etc. MTASA Lua is still 5.1 (it is not developing). Lua, like any programming language, is developing, however MTASA core strongly linked to Lua 5.1. Why TypeScript There is TypeScriptToLua project. My project is based on TypeScriptToLua (I use it as a dependency). General purpose of TypeScriptToLua: convert (transpile) typescript code into Lua code. Thus, you can use TypeScript without modifying MTASA core. You are available to not use types in some parts of code (you are not restricted to use types everywhere). The TypeScript is being developed by Microsoft and, I believe, that TypeScript will be alive for several years. When to not use TypeScript (where to use Lua instead of TypeScript) 1. If you are not familiar with Lua or with scripting in general. 2. if you are writing simple script. Introduction Video I have made the video, where I describe Lua disadvantages, explain, why I have chosen TypeScript (and language transpiling) and write an example. Few word about mtasa-lua-types I have created this package to provide MTASA declarations in TypeScript. If you would like to create a resource, you haven't to install it manually, just use the boilerplate. Quick Start I have provided the tutorial here: https://github.com/mtasa-typescript/resource-boilerplate. So, you have to install NodeJS and download my boilerplate. And,... you are ready to code. If you have any ideas, issues or suggestions -- post them below, or in youtube comments, or in github issues ? Example code (from youtube video) import { Player } from 'mtasa-lua-types/types/mtasa/server/oop/Player'; import { mtasa } from 'mtasa-lua-types/types/mtasa/server'; interface GithubCommitApiResponse { commit: { message: string; } } mtasa.addCommandHandler('getcommit', function(player: Player, cmd: string) { mtasa.fetchRemote( 'https://api.github.com/repos/mtasa-typescript/mtasa-lua-types/commits?per_page=1', (data: string) => { const json = mtasa.fromJSON(data) as GithubCommitApiResponse mtasa.outputConsole(`The last commit message: ${json.commit.message}`) } ) }) Future plans - Github bot, that will crawl mtasa wiki and update mtasa-lua-types continuously - Add better hinting for `addEventHandler` function Links WebSite: https://mtasa-typescript.github.io/ GitHub MTASA TypeScript Projects: https://github.com/mtasa-typescript Resource Boilerplate: https://github.com/mtasa-typescript/resource-boilerplate Resource Example: https://github.com/mtasa-typescript/resource-example

One more TypeScript wrapper: with tutorial (how to install and how to use), template resource (boilerplate) and example resource Template: https://github.com/mtasa-typescript/resource-boilerplate Resource Example: https://github.com/mtasa-typescript/resource-example

Hello! Nice tool. Hot-reloading is very impressive. I'm currently working on mtasa-lua-types (nodejs repository with types declarations). I have the resource example, written fully on TypeScript: https://github.com/mtasa-typescript/resource-example . Here is the "boilerplate" and tutorial how to setup: https://github.com/mtasa-typescript/resource-boilerplate . You can use those packages, boilerplates, etc. in future, if you are interested in :)

You can check distanation between trailer and trucker (if they linked) on client prerender. Normal is between 8 and 10. If not, you can detach and attach trailer (on client-side, of course)

use source instead of getPedOccupiedVehicle( player ) And if you want to check only driver exit, you should check addEventHandler( "onVehicleStartExit", resourceRoot, function( player, seat ) --you dont need if here. source always exists if (seat ~= 0) then return false end --exit if not driver -- your code here

What is the best way of encryption (or protecting) client files?