The_GTA

No problem! I like to help you. If you have any further questions about Lua scripting in general please ask.

Hello Andres99907! Nice to meet you. I am an experienced developer and want to help you become a better Lua scripter. For this purpose I want to give you advice on how to incrementally improve your work. Did you know about local variables in connection with Lua closures? You can do amazing things with this mechanism like this. local global_index = 0 index = 0 function CreateClosure() local index = global_index + 1 -- uses the "global_index" local variable in the up-most script closure local function callback() return index -- uses the index variable of line 6 end global_index = index return callback end index = 42 -- modifies the global variable "index" which is not a local variable assert( CreateClosure()() == 1 ) assert( CreateClosure()() == 2 ) assert( index == 42 ) -- not changed by CreateClosure function Lua closures are created each time your script puts a function into a variable/table key. When you call a closure then the function is executed which then does access so called "upvalues", the local variables of closures that enclose this closure. Before you can use a local variable you have to declare it using the local keyword! Using this technique we can improve your script by remembering the variables you create during your FlarePhys function call, like this: Flares = {} Chaffs = {} function FlarePhys(x, y, z, distance, gz) local player = client local index = #Flares + 1 Flares[index] = { ["Vehicles"] = { getPedOccupiedVehicle(player) }, ["Lights"] = { createMarker(x,y,z,"corona", 1, 255,0,0) }, ["Flares"] = { createObject(2060, x,y,z) } } setElementData(Flares[index]["Vehicles"][1], "Dismissile", true) setElementCollisionsEnabled(Flares[index]["Flares"][1], false) attachElements(Flares[index]["Lights"][1], Flares[index]["Flares"][1]) moveObject(Flares[index]["Flares"][1], distance*100, x, y, gz +1.5) setTimer ( function() if isElement(Flares[index]["Vehicles"][1]) then removeElementData(Flares[index]["Vehicles"][1], "Dismissile") else destroyElement(Flares[index]["Flares"][1]) destroyElement(Flares[index]["Lights"][1]) end end, 1000, 1 ) setTimer ( function() outputChatBox(getPlayerName(player)) destroyElement(Flares[index]["Flares"][1]) destroyElement(Flares[index]["Lights"][1]) end, 8000, 1 ) end addEvent("UseFlares", true) addEventHandler("UseFlares", getRootElement(), FlarePhys) This script should work better for you because now the "creator" does not suddenly change anymore.

If you want to know based on a 2D orientation whether you want to turn left or right to face toward a point, you can invert the 2D coordinate system with center point set to the position of your entity to get local coordinates (lx, ly) from the world coordinates of your entity. If lx > 0 then you have to turn right. If lx < 0 then you have to turn left. This idea involves Linear Algebra but getting the idea is another topic.

1) Yes. By completely implementing the Lua 5.1 language this approach can speed up any 10+ years old Lua resource/gamemode. Don't get me wrong, I want to implement the entirety including garbage collection, luac binaries and the API layer for applications like MTA. But there will be limits where security is at risk, mainly the luac binaries that use sequences of opcodes that cannot be generated by the reference Lua 5.1 bytecode compiler (call opcode with stackframe intersection, exploits, etc). 2) Great care will be taken that the execution order of all statements does perfectly match the order of the Lua 5.1 reference compiler. I will go into the old source code if I must make things clear, and I have already studied the internal workings of it in great detail. Thus NO, there will be no misinterpreting long/complex operations. The compiler will be created with great scientific effort and documentation. 3) Yes. My goal is to optimize the code as much as possible. I will post about any optimization technique that will be implemented in great detail in this thread once I get to them. Removing unused and redundant code is an important optimization I want to make. An example situation is: if there is code which does not call C functions and whose effects can be isolated to have no influence on code which otherwise would call C API, then the code can be removed. This is possible by inspecting the dependencies of language constructs (arrows in the calculation graph). I plan to improve the error messages of script compilation and provide warnings where code does not perform well, for example if by static analysis the compiler finds that two booleans would be added together. In Lua 5.1 this code is allowed to compile but once that code is to be executed, the language throws a runtime error. This situation will not change due to compatibility, but a warning will be put out to help devs. ?

While I cannot point you to any materials outside of my experience, let me chip in with some of my ideas... This is a problem of detecting all possible paths around a recommended path (set out by your "dot points") using the movement rules of a GTA SA car and the game physics. To solve the game physics question you need to solve collision detection (NOT intersection!) problems of a GTA SA collision model that consists of triangles, cones, spheres and boxes in movement directions. This is an active part of my research but suffice to say there is no perfect mathematical solution other than the best approximation you can come up with around sin/cos/euler equations, all in all hard work. The better the approximation the better the player will feel your solution, that's important. The game world can be loaded from the official game .col files in connection with the game map files for placement. What about the game physics and the GTA SA car rules? Suffice to say it is using a weird FPS based approximation so you better study it based on experience and what the game has to offer through configuration files (handling data, model data, the game executable in the worst case). Vehicles have the most complicated collisions, followed by objects followed by peds (which are just a box or cylinder I believe). From your post one could be deluded to think that the only route you need is the nodes you have put. But think about this problem as a navigational issue. Your nodes are just recommendations which in real life the path is more complicated. From 4 points on a map you might have to expand them into 117. Just maybe you could start by taking a look at algorithms like Breadth-first search - Wikipedia and navigational data structures. Hope I could guide you somewhere useful!

Of course it can be made to work! In the past weeks I have been working on an optimal internal representation and calculation dependency graph system for the compiler. I am doing good progress on that part and I want to share some internal details I have set on so far. (Lua to 80386 machine model example - graphs post - Imgur) Let's try to compile a very simple Lua program and you will see that it is not such a big deal. local value value = 1 + 1 print( value ) return value If we lex the program into our compiler we can obtain the following graph (pure language structure): There you see that we have created internal objects for each language structure. Each node that you see in the graph above is a memory-allocated object in a programming language. Our language target is C++ which is very fast and powerful, especially in the latest standard. Our next step is to schedule the graph into an operation order: Now we have assigned each opcode a natural number so the processor would know in what order to assign so called "instructions". This is important because each program is defined to be a strict sequence of instructions. Now that we have such an order we know in what regions which variables are used inside the program. Thus we know what registers to assign between which operations so that they do not collide. Take a look at this possible 80386 machine model example: This model is just an example hence not yet detailed enough but it should give you a general idea about the feasibility of the compiler. The programs that result from this compilation can be packaged into PE files or into other formats that support electronic signatures. I hope that I could convince you of my methods! --- From the above example you can deduce the required components for this task: lexer, computation graph and transformation rules. I am currently working on the lexer.

Yes. I recommend you to put a realistic value like 5000 milliseconds. If it takes longer than that then there is some serious trouble going on inside of your database server.

Yes. An empty database result is returned as an empty table. There is no connection error so dbPoll does not return false. You are using the API correctly, too (besides the -1 for dbPoll which is a freeze-hazard for your server).

Please take a look at the Wiki page of the dbPoll function. There it says that it does return a table of results if the poll was successful but it returns false or nil if an API or connection error occured. From the effects that you are seeing, the dbPoll request is successful but empty. Please try this code instead: addEvent("account:login", true) addEventHandler("account:login", root, function(thePlayer, username, password) if not username or not password then return false end local queryCheck = dbQuery(db, "SELECT * FROM `accounts` WHERE `username` = '" .. username .. "'") local result = dbPoll(queryCheck, -1) if result then for k,row in ipairs(result) do local hashedPassword = row["password"] if passwordVerify(password, hashedPassword) then triggerClientEvent(thePlayer, 'account:succesfullogin', thePlayer) setElementData(thePlayer, "account:id", row["id"]) setElementData(thePlayer, "account:username", row["username"]) setElementData(thePlayer, "account:email", row["email"]) setElementData(thePlayer, "account:ip", row["ip"]) setElementData(thePlayer, "account:serial", row["serial"]) setTimer(function() spawnPlayer(thePlayer, 1245.1999511719, 332.5, 19.200000762939) triggerClientEvent(thePlayer, 'account:switchcamera', thePlayer) end, 2900, 1) return; end end triggerClientEvent(thePlayer, 'account:noaccount', thePlayer) else print("database error"); --this is where I dont get anything in return (tried putting outputconsole of an error message but i dont get that either) end end)

What do you mean, marker? Do you mean blip or some kind of 3D arrow? createBlipAttachedTo - Multi Theft Auto: Wiki attachElements - Multi Theft Auto: Wiki + createMarker - Multi Theft Auto: Wiki

Have you tried putting in a username that does not exist? Your code does only seem to send a client event if no such user exists.

To answer your original question, please take a look at this code: function validateLoginData(command, username, password) if username == "" or password == "" then return outputChatBox("Umple toate spatiile!", 255, 100, 100) end triggerServerEvent('accountsystem:login', localPlayer, loginPlayer, username, password) end addCommandHandler('loginaccount', validateLoginData) The third argument to triggerServerEvent, the global variable "loginPlayer", is not defined anywhere. Did you mean to use "localPlayer"?

Please post the full code, especially the part where you trigger the event on the clientside.

This bug is probably related to the famous issue of "writing pointers into quaternions". It is a known issue inside of the GTA SA game.

I am perplexed by the procedure of this support topic, but it just shows how creative minds are working asynchronously in relation to people trying to help them. I mean there are people who want to help you because they emotionally engage into support but that's OK. I wonder if OP has any more questions?

Once this opcode is available any resource could enable it inside of their own meta.xml file. <script src="advanced.lua" type="client" extended_syntax="true" /> We are talking about a possible feature in the future. I could implement it inside of the Lua compiler that I have started working on this month. Then it would be merged into MTA after QA.

Sorry, you misunderstand. Do you have any idea about the math involved in drawing pixels onto screen? I had been as naive as you, so don't worry and please listen carefully, lad. You want to place your text inside of the rectangle pos = (x,y) with size (w, h). Now imagine that you only want to have a partial area, in your case a rectangle pos=(xs,ys), size=(ws,hs) visible of your text. The ONLY WAY to perform text scissoring is the render target, thus we choose it (if you disagree feel free to post an issue on the MTA GitHub, I would appreciate that). We can place a render target on-screen using the dxDrawImage function call, thus I hope you realize that there is a screen coordinate position at which the render target resides at as "raster" plus a size (rx, ry, rw, rh). Render target is our scissor, so (xs,ys) = (rx,ry) and (ws,hs) = (rw,rh). After you call dxSetRenderTarget, all drawing coordinates are turned relative to (rx,ry), thus... pos of text on render-target = (x,y) - (rx,ry) size of render-target = size of the area that you want to cut out of your text = (ws,hs) Do not forget to call dxSetRenderTarget() to get back to drawing onto the main screen space.

This sounds like you do not agree with the Lua language design. The idea of named parameters could be nice if the Lua function call were extended to be a key-value map for parameters in general. Right now the parameters to a function are an integer-map. By adding a new opcode "LUA_CALL_MAPPED" each parameter could first pass the ID and then the value. This would prevent the creation of a table for each function call (IIYAMA made an excellent point why creation of a table would be a bad idea). I disagre with your syntax though, so here is mine: function named_args map( one, two : two, three : 1 ) -- one = 1 -- two = 2 -- three = 3 end named_args( "one" = 1, two : 2, 3 ) This syntax is backwards compatible with the old way of calling Lua functions.

As Tut has suggested, setting them double-sided in 3DS Max can only result in two outcomes: the triangles are doubled, each one for each facing side, causing a massive increase in filesize the function does nothing at all because there it fails to set a backface culling option that does not exist within RenderWare model data Inside RenderWare the culling mode is defined as "render state" thus GTA SA has these settings defined within its own map files. Unfortunately MTA does not provide functions to modify rendering properties of original map objects. Feel free to suggest such a feature on the official MTA GitHub if you really need it. MTA would not be MTA if there'd not be a workaround, though. Did you know that you can modify DX9 render states using FX shaders? Consider the dxCreateShader and engineApplyShaderToWorldTexture functions. I find this a very strange work-around though and you might be better off requesting direct access to map rendering properties instead.

- SA physics consist of cones, triangles, boxes and spheres. Bullet Physics supports all of those collision objects so yes. But you cannot just embed Bullet Physics into the game world without heavily patching the GTA SA game executable. Since there is engineRequestModel now I do not see the point why, you can just create a .col file for that instead. - Since GTA game physics depend on FPS, it is not recommended to perform GTA game physics calculations on the server. Loading the game world is possible if you copy the game files onto the server (every game client has the same collision files). I would find it cool if Bullet Physics enabled us to write small minigames that are not embedded into the GTA game world. Then you can perform custom time-based synchronization across all game clients through the server.

I unironically agree. Reason: reverting the changes of single Lua scripts is not documented/defined/expected (Lua table contents, created MTA elements, registered callbacks, ...). And patching is not defined either since the Lua VM state is too complicated.

Consider what happens if clients are already connected to your server. Unless you restart your resource they will not see the changes. Because of that changing resource files is not recommended but I have been tinkering around with it in the past (resource "resedit").

I don't think we are fully aware of the risk associated with big features like this: Is the proposed API easy to learn for scripters? Has the Bullet API been properly used according to documentation, best practices? Is there any exploit inside the Bullet collision framework that could be escalated to crashes or worse? What about longterm support of this feature? Will OP be around to keep the code up-to-date? Are there any estimations about the cost/benefit tradeoffs? But maybe this is being too cruel to new feature proposals. Consider the amount of time that new content like this takes for development. Verification should take less time, if there was an elected board of experts for decisions like this. Possible Benefits: Bullet Collision is known across the internet so we could attract scripters that want more "bang for their buck" Encouragement for working on new features can be increased

Com' on, man! You know I am a dreamer just like most of us here. Let our inspired people work on things they are passionate about. Since OP has created documentation and implementations already, he has a good chance to get beyond the development stage into testing stage. Maybe OP grows up in the process, becomes better and better at development.

The issue with Lua bytecode is that it can express more than can be written down with the Lua syntax. I agree that junking about with the bytecode will just lead to problems so I suggest multiple protections against it: Reject execution of unsigned Lua bytecode binaries; instead allow self-signed ones for testing purposes For special cases where "exploit-y" bytecode is used we slow down execution with safeguards such as Lua stack virtualization with pre-and-post zeroing-guard No Lua VM will be shipped with my approach. I will be taking personal responsibility and liability for any exploit found within my product that leads to severe casualties such as shellcode execution. I have much experience in this field and am performing research to mitigate any possibility prior to it occuring. Suffice to say I am taking this topic of security very seriously. Signed code execution is a great security feature. If the MTA team signs all binary scripts that run on both MTA servers and clients then only code that comes from official compilers, not binary/machine code twisters can run on MTA software. It comes with the burden of maintaining security certificates and their recommended properties (due-by date, strong ciphers, etc).