DiSaMe

I'm okay with the idea, but I'm not so sure if it's keyboard that's causing the problem. I mean if I tried to get support, I would try to explain clearly regardless of what device I use. But then again, maybe I think differently from most people.

I don't know if this still works, but I have run two instances of MTA in the past. On Windows, I ran separate MTA instances on separate users. It was inconvenient because I couldn't see both windows at the same time. On Linux, I made another Wine prefix. Separate Wine prefixes work as separate Windows systems and each can run its own instance of GTA SA.

I don't know what this has to do with dimensions. The code should work unless thePlayer variable is changed before the timer elapses. Therefore the part where thePlayer gets changed must be where the problem comes from, but you're not showing us that part. @The_GTA showed you how the code can be modified so that changes to thePlayer wouldn't cause this problem.

It's amazing how you know all these details. Knowledge about TXD/DFF in general would have helped me a lot back then. And even though I don't do anything related anymore, that doesn't make your findings any less interesting

What an interesting finding. If RenderWare developers specifically made textures work that way, then it's not a bug of RenderWare. Is it a bug of MTA, though? That's a separate issue. If the purpose of TXD functions was to make custom textures apply to models and nothing else, then yes, it's a bug that's caused by absence of data validation in engineLoadTXD. If the purpose was to load the data the exact way RenderWare does it, it's not a bug. But that's just playing around with words - even if it's not a "bug", whether we should keep it or not is another separate issue Where is it specified? I'm looking at https://gtamods.com/wiki/Raster_(RW_Section) and there's some rasterType structure member but no description, is that it? Remembering the times I used to read/write TXD files, it's interesting to find out that there's this thing I never knew about. On the other hand, it's likely I wouldn't have found it interesting if I somehow managed to get this behavior back then, without knowing how it works.

These kinds of things don't usually go to waste either way - if it gets released, there are going to be people who will use it in MTA. But letting people outside MTA community know about it would make things even better. It could set higher standards for GTA multiplayer in general. An unfamiliar person might expect that multiplayer has the same things that single player does, except it allows multiple players to play together - seems like what you were thinking of back then, if I understand you correctly. With Sphene, that could become a standard rather than just an expectation. An in-game editor? That's amazing! Sure, if we have a map editor that people use for purposes not limited to MTA, why not a SCM script editor as well?

Yeah, I guess even if creating a custom weapon and attaching it is kind of a workaround, it comes in handy. I see there's accuracy among properties - if they can shoot in a different direction than they're pointing at, then it's one of the things setPedAimTarget can't do. When I wanted to simulate imperfect accuracy using setPedAimTarget, I did it using math.sin with time as parameter. Everything looked okay until I looked at the ped from up close and realized that it's very noticeable how it waves the weapon around Your approach reminds me of back when peds couldn't enter/exit vehicles apart from warping instantly (that's a recent addition, right?), and I was thinking of reimplementing vehicle enter/exit animations using attached elements, ped animations and vehicle door rotation. Didn't go anywhere with it though. Had I done that, it would have helped me with train system that I was thinking of doing. I wanted to define my own train tracks, and in order to do this, I had to set the train as derailed and control its position from the script. But you can't enter the derailed train, and making my own vehicle enter/exit system would have solved this problem. I once did the "define my own tracks" thing for the tram by the way (wanted to use both tram tracks in SF), but later I lost the script, though it looks pretty easy to make now that I think about it. It gets in the way when we have to resort to workarounds, especially when it's due to bugs like that one I had with setPedAimTarget, and yet, the very fact that we can implement those workarounds to begin with, just shows how powerful MTA is. I don't think that's specific to server peds, although I never checked this. Element streaming is a client-side thing, element disappears from GTA when you get further, but MTA client still remembers it. It just seemed not to remember things like stats, health and ammo. So unless this has been fixed, your peds might also be susceptible. It would be harder to notice on your peds since they're centered around the local player, plus if shooting is implemented using custom weapons, you can't observe the same bug with ammo. Being pragmatic can get things done here and now, but perfectionism has its benefits in the long term. When I was making my traffic and my server, I was also being somewhat pragmatic. On the other hand, there have been many moments when I tried to code something but couldn't think of a good approach, data structures and stuff. And it felt like my perfectionism was holding me back. However, now I realize it wasn't for nothing. Far from it. I was just looking for something, and it was that "something" that made me much better at coding. Glad to know it's interesting to you. But because I have lots of things to do, I don't want to get your hopes up too high - no idea when I'm going to make something. Anyway, I can say the same to you, good luck to you too

Oh, so that's what you've gone through. Workaround after workaround. Never tried custom weapons myself, but that's not the standard way to make peds shoot, so it's not really peds that you had a problem with, but rather a separate MTA feature that I've never seen being used anywhere else in GTA. But I guess you did it that way because you had issues getting them to shoot the standard way? I used to call setPedAimTarget and set the fire control state, and the peds would appear to shoot, the weapons would appear to fire, but the bullets sometimes wouldn't fly out. Turns out a NaN would appear somewhere in calculations in the game itself. But the problem would not occur at longer distances, so the workaround was simple: put the target thousands of units further in the same direction. Drive-by was even more problematic, I called setPedDoingGangDriveby along with setPedAimTarget, and while peds did appear to shoot, I never managed to get their bullets to fly out reliably, plus they were visually aiming in the wrong direction. And regarding info not being preserved between stream out and stream in: I create a ped. I give that ped a weapon using giveWeapon. Seems okay. Then I go further away and return back. The ped only has one bullet. If I try to make it shoot, it shoots one bullet and then continues the shooting animation but the weapon doesn't fire and no bullets appear. With no client-side giveWeapon, my workaround was to call it on the server side every couple seconds or so. Many other properties were not preserved either. Health being one of them, but this didn't get in the way when I had my own server because I had a custom health system anyway. I don't know how much the situation changed since then, I have been assuming things have improved, considering peds can enter/exit vehicles now. It's surely interesting to know how it all works. I agree, the game world just doesn't feel that empty with peds around. And you did what I didn't find time to do. You made peds more interactive, which is why yours feel more alive. But I couldn't limit myself to client-side peds. I understand your reasons, but when I make peds for players to interact with, I want them to be synced, because that's one of the things I love about MTA: synced peds. And if actual server-side peds were still too heavy for my purposes, I would try implementing my own using client-side peds and triggerServerEvent/triggerClientEvent. But to each their own, sometimes I get a bit perfectionistic with things like these ? I'm also happy to have someone to talk to about peds. When I was scripting mine, I felt alone. All I could see was people occasionally posting things like "is there a resource to have peds walking and driving everywhere?" People only wanting a traffic resource but not trying to make one themselves. It's not even that hard to make something basic that works. I currently can't run MTA because of some hardware issues (should be simple to resolve, just haven't gotten myself to do it for a while), but that isn't my focus. I've become better at programming in the recent years and I've learned to make my code much more reusable. What I've been thinking is that I could try making something that runs on anything running Lua, with minimal additional code needed to bind it specifically to MTA API.

Wow guys, I'm very happy to know you appreciate my work! When I was making the traffic in 2012, even though I stayed around for quite a while afterwards and even made my own server, it was already MTA scripting sunset for me. I had no idea where my life was going, and since I still had barely made anything usable on MTA in general, I wanted to finally produce something that actually works. But I didn't know what would come of it. And I wouldn't have thought that after this many years, my scripts would still have such an impact. It seems like not only it didn't fade away with time, but to the contrary, over time more and more people see them, get inspired and make their own works that impress me. It's a little hard to believe that this much time has passed, and I miss those days I scripted on MTA. Not making any actual plans yet, but maybe after the sunset the new day has to come Precisely what I used to think, though depends on what that "weird stuff" is. Some things may be unexpected and look very weird at first but totally understandable once you get to know them, like ped without syncer ending up in completely different positions for server and clients. Others, such as health or ammo not being preserved between stream out and stream in, look like bugs, although I don't know if that's still the case. I was a little worried we might hijack this topic if I start commenting about your videos without saying anything else, but now I feel as if I had done some backseat moderating or something like that, I don't know, maybe I'm just thinking too much ?

This is great, I can't believe I missed it. And I never thought anyone would ever make that much use of it. But this topic is not exactly the right place for this, because this is where @EnemyChad demonstrates his NPC system, so posts that only focus on other systems are a bit out of place here.

Yes, rendering, that's what I had in mind. And it's nice to know you use coroutines, a very useful mechanism that is underused. If you implement all those game features, it could eventually replace single player. I mean even people who just want to play alone, could do so on their own local servers, with ability to run other MTA resources being the bonus. This inspires me to do some related scripting, not necessarily something exclusively for MTA, but something that could be used on MTA.

Wow, I've had an idea like this myself a long time ago - didn't think that someday someone would make this. Where does the SCM execution take place? Server or client? When I had the idea, I was thinking it should be on client because some parts of SCM scripts are supposed to work without delay for the player. For example, if we have an operation "wait 0", execution will wait for the next frame before proceeding. But what I considered the problem was that if the script creates elements (like vehicles) and they're supposed to be synced, the client has to tell the server to create the element, and since there will be a delay before the client becomes aware of that element, execution will have to pause as SCM script won't be able to use the element which doesn't exist on the client yet. But now it doesn't look like a big problem, just making some wrapper that will take care of sync stuff, and operating on that wrapper. On the other hand, relying on client to tell the server what to do may cause problems like hackers creating lots of cars in one place, or creating an army of peds and sending them after some player But making all SCM scripts of GTA work with this is much more than just making an interpreter, right? SCM relies on lots of other functionality that has to be reimplemented in Lua. Ped AI, zones, gang wars, wanted levels. I mean some of those things are big enough to be made into separate projects, with SCM interpreter using them as dependencies. Anyway, looks great, and I hope you guys will be able to do even better.

This is amazing! It was because of lack of scripts like this that I created the traffic script. Except maybe that if peds aren't synced, I would still have created it. My logic was that MTA deserved to have traffic, and since no one was making it, I had to do it. It is heavy indeed, because it's not optimized well. But yours looks great, even if it's not synced. At least peds are much more interactive - something I had planned but didn't find time to do. I remember wondering why the hell no one makes use of peds in MTA. It was this kind of thing that I was looking for

That looks unusual. While it may look intuitive that the script will execute on server before executing on client, I guess there's no guarantee it will be that way, so it looks like a race condition. But I would expect onClientResourceStart to get triggered after everything has been set up on the server so it's better to do this kind of communication from that event.

You can't control "WorldModel" as element, but you can remove it and create an object in its place using createObject. Such solution looks clean enough to me, although a little more than that may be needed if there are low detail objects involved.

First of all, your id table is needlessly nested. {481}, {462} and {509} are tables on their own, so unless you're going to add some other data in addition to IDs, it's better to replace them with plain numbers: local id = { 481, 462, 509, } Now, to get to the point, the table id has 3 fields, which makes #id equal to 3, therefore your math.random call generates a number 2 or 3, and uses it as vehicle model ID. What you need to do is to generate a random number to choose the table index and then retrieve the value under that index from the table: createVehicle(id[math.random(1, #id)], v[1], v[2], v[3]) Same but more verbose: local idCount = #id local index = math.random(1, idCount) local modelId = id[index] createVehicle(modelId, v[1], v[2], v[3])

Then you probably need onClientGUIClick instead of onClientClick. onClientClick is an event for general purpose clicking detection. onClientGUIClick is an event for detection of clicking of GUI elements. You can bind different handler functions to different buttons.

To bind a function to a command: addCommandHandler To retrieve the weapons: getPedWeapon To remove the weapons: takeAllWeapons To restore the weapons: giveWeapon

Most stuff in 3D graphics is made of things that are straight/flat. If you want a curved line, you can make one by putting multiple straight lines together.

First of all, use code blocks (preferably with Lua highlighting) instead of spoiler blocks. It's hard to read it the way it is. Second, did you try to understand why those messages are there? Did you try doing things like checking the variable values, like this: outputDebugString("veh = "..tostring(veh)) Documentation of both getVehicleOccupant and getPedOccupiedVehicle tells what return values are possible. If you check the variable values when the warnings appear and read the documentation on when those values are returned, it should be easy to understand why it happens. Perhaps your topics were locked because of lack of research on your part (or at least it looked like that), so I'm trying to lead you on the right track.

There is another solution that doesn't require render targets, and it's closer to dxDrawImageSection in the way it works: dxDrawMaterialPrimitive. dxDrawImageSection only operates on rectangular sections. dxDrawMaterialPrimitive allows you to draw triangles, specifying the texture coordinates for each vertex, and since triangles can be put together to form other shapes, you can do what dxDrawImageSection does but not limited to rectangular sections. There isn't an example in the wiki page on how to use it, but dxDrawPrimitive has one, and dxDrawMaterialPrimitive works in a similar way, only it takes image as second argument, and each vertex has 5 parameters instead of 3 (2 extra parameters are for image coordinates). I came up with some function, for drawing a radially cut out section of an image. I only tested it as much as I could test it in standalone Lua interpreter so I don't know if it works in MTA, but if it does, someone may put it on useful functions page in wiki ? It uses trianglefan primitive type, puts the first vertex in the center and other vertices around it. local white = tocolor(255, 255, 255, 255) local degToRad = math.pi/180 local function makeVertexAtAngle(centerX, centerY, halfWidth, halfHeight, angle, color) local angleRad = angle*degToRad local xAdd, yAdd = math.sin(angleRad), -math.cos(angleRad) local maxAdd = math.max(math.abs(xAdd), math.abs(yAdd)) xAdd, yAdd = xAdd/maxAdd, yAdd/maxAdd return { centerX+xAdd*halfWidth, centerY+yAdd*halfHeight, color, 0.5+xAdd*0.5, 0.5+yAdd*0.5 } end function dxDrawRadialImageSection(posX, posY, width, height, image, startAngle, stopAngle, color, postGUI) if color == nil then color = white end if postGUI == nil then postGUI = false end local halfWidth, halfHeight = width*0.5, height*0.5 local centerX, centerY = posX+halfWidth, posY+halfHeight local roundedStartAngle = math.floor((startAngle-45)/90+1)*90+45 local roundedStopAngle = math.ceil((stopAngle-45)/90-1)*90+45 local vertices = {{centerX, centerY, color, 0.5, 0.5}} table.insert(vertices, makeVertexAtAngle(centerX, centerY, halfWidth, halfHeight, startAngle, color)) for angle = roundedStartAngle, roundedStopAngle, 90 do table.insert(vertices, makeVertexAtAngle(centerX, centerY, halfWidth, halfHeight, angle, color)) end table.insert(vertices, makeVertexAtAngle(centerX, centerY, halfWidth, halfHeight, stopAngle, color)) dxDrawMaterialPrimitive("trianglefan", image, postGUI, unpack(vertices)) end This example should display a looping 5-second animation of image going from 0 to 360 (if I didn't screw anything up): function drawAnimatedRadialSection() local angle = (getTickCount() % 5000) / 5000 * 360 dxDrawRadialImageSection(100, 100, 200, 200, "your_image.png", 0, angle) end addEventHandler("onClientRender", root, drawAnimatedRadialSection)

It clearly says that image/blip/6.png failed to load. Does that file exist? Is it added in meta.xml?

There are problems with this code. First, the source of "onResourceStart" event is the root element of that resource (same as resourceRoot, I think), but bindKey requires player as first argument. Second, the handler functions for bindKey don't have sources. Instead, the player is passed as first argument. I don't know if bindKey has call propagation (call propagation means a function call made on an element will apply to its children elements). If it does, we can pass root to the player argument of bindKey and the key binding will be added for all players: function killMe(player) killPed(player) end function onStartBindKill() bindKey(root, "n", "down", killMe) end addEventHandler("onResourceStart", resourceRoot, onStartBindKill) If bindKey doesn't have call propagation, the above code is still wrong and we have to call bindKey separately for each player. That means calling bindKey every time a player joins. But a resource might be started after some players have already joined, so we also have to call bindKey for already present players when it starts: function killMe(player) killPed(player) end function onJoinBindKill() bindKey(source, "n", "down", killMe) end addEventHandler("onPlayerJoin", root, onJoinBindKill) function onStartBindKill() local players = getElementsByType("player") for key, player in ipairs(players) do bindKey(player, "n", "down", killMe) end end addEventHandler("onResourceStart", resourceRoot, onStartBindKill)

spawnPlayer works when the player is spawned and alive as far as I know, but it does more things than just teleporting, such as setting the skin and resetting the health to full, which is why it's not the right choice for teleporting.

The problem is that collisions unload when objects are far enough from the camera. You can use setElementFrozen to freeze the player in place when you put the camera somewhere else, then unfreeze when you reset the camera to follow the player.