Jump to content

Reyomin

Helpers
  • Posts

    1,388
  • Joined

  • Last visited

  • Days Won

    14

Reyomin last won the day on May 31

Reyomin had the most liked content!

10 Followers

Member Title

  • Forum Helper

Details

  • Location
    Lithuania

Recent Profile Visitors

4,443 profile views

Reyomin's Achievements

Loc

Loc (38/54)

91

Reputation

  1. The global environment (the table holding the global variables) can be accessed using variable _G. local playerName = getPlayerName( player ) local variableName = "Timer"+playerName _G[ variableName ] = setTimer ( function() end, 1000, 0 ) However, building variable names is usually not recommended for generic manipulation of data. Instead of putting the timers into global variable space, you can create your own table specifically for timers: -- at the top of the script playerTimers = {} -- then, somewhere in the code local playerName = getPlayerName( player ) playerTimers[ playerName ] = setTimer ( function() end, 1000, 0 ) But I suspect that's still not exactly what you want to do. Should the timer be linked to player's name, or to the player? If it's linked to the player's name, then if the player changes their name during the game, playerTimes[playerName] will no longer refer to the timer created before the change. If that's not what you want, you can bypass the retrieval of the name and just use the player element directly as table key: -- at the top of the script playerTimers = {} -- then, somewhere in the code playerTimers[ player ] = setTimer ( function() end, 1000, 0 )
  2. Reyomin

    Follow Ped

    You can make the ped perform actions using setPedControlState, with accelerate, vehicle_left and vehicle_right being the most important controls you would want to use for driving. You also need to retrieve the relative placement between ped's and player's cars, using functions such as getElementPosition and getElementRotation and some math. All these things need to be done repeatedly so that the control states would be updated as the elements move. If you also want to make the ped follow the roads (instead of going straight towards the player), then it gets more complicated because the script has to do pathfinding.
  3. You can check which seat the player occupies using getPedOccupiedVehicleSeat function. Other functions involving vehicle seats are getVehicleOccupant and getVehicleOccupants.
  4. Now the question is much clearer. You can query the information about elements using functions like getElementsByType, getElementChildren and getElementData. So if you want to create a list in the GUI that represents a list of elements (like teams or skins), you can do so using getElementsByType and looping through the list of elements and creating a GUI element for each element in the list. getElementData allows you to retrieve attributes such as team name so you can pass the result to GUI functions to have it show up in the GUI. If you use getElementData on map elements from within the client side scripts (like, during the creation of GUI), you need to have <sync_map_element_data>true</sync_map_element_data> in meta.xml of any running resource. But usually a better way to use the team data from the map is to retrieve it on the server side into a table in the beginning, then pass that data to triggerClientEvent when you want to display the spawn selection window for the player.
  5. Depends on how you define 'gamemode', because a gamemode is just another script. mapmanager and other related resources provide a standard way to do some things, but you don't have to use them - in fact, I don't remember ever doing that. I'll assume your confusion is the same as mine was a long time ago, which is getting anything to work at all, so that with the gamemode you would have a minimally playable game. There are several (per-player) things you need to do. First, a player is not physically present in the game world upon joining the server. You need to call spawnPlayer to make them appear. Also, their camera is set to some position where only the sky is visible. To make the player's camera follow the player, call setCameraTarget, passing the player element to both arguments. And last, the screen is black when you start. You have to call fadeCamera for that. That's how the player gets to run around in the game world. The rest is up to your imagination.
  6. You can do that using processLineOfSight function. You cast a ray between two points and it will return information about the surface that it hits, including the material ID.
  7. Perhaps the distinction should be drawn between what can only be controlled by scripts and what can be changed by other means. Position can change because of physics, which is why we want MTA to sync it, but control states cannot be changed by anything but scripts. If the script fully controls them anyway, it makes sense to let it take care of making them consistent. Also, there would be a benefit in syncing some other things besides position (assuming they're not synced already), such as whether the ped is knocked down. It's another thing related to physics that can make a big difference.
  8. Well, that clears it up. I thought there was a possibility that it was changed, but I wasn't thinking of it as something that's supposed to be changed. I would argue that making our own data to describe tasks and using it on all clients independently can give better results than having MTA sync the peds' actions, because high level actions allow more accurate predictions than low level ones. Think "follow a particular element" versus "accelerate and steer right". The former can give acceptable results with much longer sync intervals because the latter will usually become obsolete quickly. This is in contrast to player sync, where primitive actions are the highest level actions we have, which I guess makes player sync a more complicated subject than ped sync.
  9. But my question was, are ped actions resulting from setPedControlState, setPedAimTarget and several other functions even synced? It's understandable that setPedEnterVehicle needs to be synced, because it directly involves other elements. But setPedControlState directly involves just the ped, so is it still synced? If it is, then you're right about why using isElementSyncer would be necessary, but if it's not, then ped state will be inconsistent between clients either way, and all clients should control the ped to make it more consistent, otherwise, as I said, the ped will appear to teleport around while standing still, to everyone but the syncer.
  10. I'm a bit late to the party, but... Shouldn't the client side part of controlling be done on all clients? In other words, are peds' actions synced? I don't know how much it has changed since I last scripted peds, but I was under the impression that it's just placement and velocity that are synced, but actions are not - in which case every client, not just the syncer, should set the control states and other control-related parameters, otherwise non-syncers will see the ped changing position but not actually performing any actions.
  11. Oh, okay. It was the wording that confused me
  12. Yes, peds are more popular than they used to be, it's just that I was expecting them to be even more popular. Not that I have any particular plans to return to scripting, but it's a possibility. I love these videos! I might have gotten some things right, but my goal was to make ped scripting easy so that even beginners could do it. Didn't come close enough because I only implemented very basic tasks. Was thinking of implementing pathfinding but never did. Analyzing how the game does it may help getting the peds behave the way they do in original game, but I'm not a fan of this approach. Reimplementing original behavior wouldn't be satisfying enough, I always wanted peds to perform complex tasks regardless of how the game does it. I'm not sure if I understood what you're saying. I mean I didn't do anything special regarding that. But you're making it sound like I did something that I didn't actually do. When I was playing around with nodes from original game, I found that there were many redundant nodes (or so it looked). But I created my own paths in the end (which is what I created npchlc_traffic_editor for), and obviously, I wouldn't create nodes that I find redundant. So Rockstar created more nodes in their paths than I created in mine. That's it. If I remember correctly, it's just a vector that tells lane position relative to the node position. When you drag while creating a node in the editor, that's when you set RX and RY.
  13. You're right. But I already could tell there was something wrong with the code even then. Which is why I always considered it an unresolved matter from the beginning. Never stopped thinking it would be nice to make a better ped system. You could say it's not pressure, but motivation. In addition, by making the resource I wanted to demonstrate that ped scripting is not really that hard, and encourage more people to try it, hoping that after a while we would have more ped/traffic resources. That didn't come true to the extent that I was hoping
  14. Wow, I'm very happy to see my scripts are still relevant, thanks! But it can be a negative thing as well, I mean it wasn't supposed to end up this way, back then I tried to improve the script, then I tried to make a new, a more advanced ped system from scratch but didn't have enough time, and to make things even worse, the code I wrote then looks horrible to me now So happy to feel appreciated, yet the fact that everyone's focused on my work that still wasn't satisfying enough to myself, gives me this unpleasant feeling that I gotta clean up this mess, gotta finish the work I once started but I don't know when I'm going to try scripting on MTA again Conversion of game paths to my path format sounds interesting, but making my own paths instead of converting the ones from the game was the reason I came up with my format and traffic editor to begin with. I was having trouble understanding some things in the game's format, and the paths have things like multiple nodes in a straight line, which needlessly uses more data. Now, to the documentation details. node_conns tells the connection ID from node IDs. That is, node_conns[node1_id][node2_id] = connection_id. Also, node coordinates are decimal fixed-point numbers, not floats, and RX/RY each takes 2 bytes as opposed to 4. Reading the value as integer and dividing it by 1000, you get the actual value. I had some problems converting between bytes and floats, and integers were faster to process. Finally, traffic lights. The value 3: "PED" means red for all cars, and that's when the peds cross the road. Normally it would work according to pedestrian traffic lights, but as far as I know, those are neither synced, nor scriptable - at least they weren't when I made the resource.
  15. Reyomin

    Money Hack

    Money limit is 999 999 999 in GTA SA. 10 times more than you're checking against.
×
×
  • Create New...