Leaderboard

Ban appeal denied.. we already figured you out, and are confident in knowing about your activities due to things that go beyond whatever you described in here. But we are not obliged to explain anything to you, to let you learn how to avoid being caught in the future. This ban won't be removed or reconsidered @Matrix.AC

How about you don't draw nametags that are not visible on screen? Since the 3D projection is a frustum which has a bottom plane (far-clip) too far players do not get a screen position either. Or just use the function I have linked for you. It does not return false in the far-clip case. HINT: you need to enable OOP in your MTA resource to use the get_screen_coordinates function! HINT: the get_screen_coordinates function does return relative values; you have to multiply them with the screen dimensions to get pixel values.

You're welcome! Don't worry, I am a patient man. So my hunch about the transpilation debug message adjustment was correct. I think that the users of your library have to be made aware that in support cases they have to show us both the transpiled as well as the input code for proper support. I like that you want to keep the transpilation output human-friendly. I think it is a very important strategy to the success of your product. Being able to understand how the code was generated from the original source will aid developers in the trust into your code generator. It will also raise the confidence that your product performs well. Good choice! You seem to go beyond my expectations in overriding default Lua debug facilities. While this is an interesting concept I am afraid not many people make use of these. There should be more tutorials on MTA forums about proper debugging of code and you should contribute to those with how your product is really well made regarding debugability!

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.

Olá, @Leinad Raiz! Seja bem-vindo(a) ao fórum. ? O erro ocorre pois você especificou que a mensagem iria ser mostrada para todos os jogadores. Para corrigir isso, altere aquele getRootElement() para thePlayer thePlayer - pois você o definiu lá na função, como sendo a variável que armazena o jogador que executou o comando.

Hello and welcome, Don't ask your scripting questions in Tutorials please. I have moved it to the portuguese scripting section.

Nice work! I am interested in the debug-ability of TypeScript code. Last time I used TypeScript in connection with JavaScript I saw that you could annotate function signatures with types or leave out the types. By leaving out the types you did revert back to regular Lua with all of its glory (and pain?). Anyway, since we are using Lua it is going to be the backend of your solution. What if we introduce errors into the script? In a traditional Lua resource we do receive warning and error messages into the scripting debug console (both server and client) with line numbers and a somewhat-helpful message. How do they look like in your solution? Is it a mess due to the transpilation? Or have you compiled to bytecode directly as well as written a custom debug-info generator to adjust for the TypeScript-based line numbers? Have you introduced any kind of new debug messages to help developers? I am asking this because what if somebody is using your solution and then comes asking inside of our forum Scripting section. We have to know how to support your TypeScript-based resources!

Olá, tente isto: local function Skin( ) if eventName == 'onPlayerSpawn' then local nData = getElementData( source, 'save-skin' ) if nData then setElementModel( source, nData ) end else setElementData( source, 'save-skin', getElementModel( source ) ) end end addEventHandler( 'onPlayerWasted', root, Skin ) addEventHandler( 'onPlayerSpawn', root, Skin )