Jump to content

CrystalMV

Members
  • Content Count

    1,327
  • Joined

  • Last visited

  • Days Won

    4

CrystalMV last won the day on April 4

CrystalMV had the most liked content!

Community Reputation

33 Good

7 Followers

About CrystalMV

  • Rank
    Lil' G
  • Birthday February 20

Details

  • Location
    Lithuania

Recent Profile Visitors

2,889 profile views
  1. You need to get the screen resolution with guiGetScreenSize and use it to calculate the coordinates for that resolution. That page has examples for this particular purpose.
  2. @Dutchman101 already mentioned putting elements into a table, and I want to elaborate on that. These functions that return the lists of elements, they create a new table and fill it with elements every time they're called, which is inefficient to do repeatedly if we can reuse previously attained information. An example: local players = {} local function resourceStarted() -- when the script starts, we populate the table with players that are already playing for key, player in ipairs(getElementsByType("player")) do players[player] = true end end addEventHandler("onC
  3. CrystalMV

    Sporadic

    You need string.sub function, it returns a substring of the string. Using the same position for start and end, you get single characters. local value = "Text" local P1, P2, P3, P4 = string.sub(value, 1, 1), string.sub(value, 2, 2), string.sub(value, 3, 3), string.sub(value, 4, 4) Because the value is a string, you can call string functions on it as methods, using OOP syntax. This one is a little shorter and does the same thing as above: local value = "Text" local P1, P2, P3, P4 = value:sub(1, 1) value:sub(2, 2), value:sub(3, 3), value:sub(4, 4)
  4. I would never tell you that - to the contrary, bots were too underused in MTA last time I checked, and I don't know how much the situation has changed since then (it was long ago though). If you want to make bots that perform tasks, that's great. However, if you're not a scripter, it won't be that easy. MTA provides functions for low level control of bots, such as setPedControlState. The good thing about it is that you can make the bot do anything. The bad thing is that this "anything" has to be made from primitive actions. Making a bot drive from point A to B by setting acceleration, bra
  5. That's a good point. It may look like a matter of taste, but there is a difference which may have big implications. If you call dbExec from within the command handler of "ck", right after kickPlayer, then the character only gets deleted when the player uses that command. If you call dbExec whenever the player gets kicked, the character gets deleted even if the player gets kicked by other means. The consequences may be very undesirable if there's some progress associated with a character. Suppose you have an AFK kicker script. The player stays idle for a few minutes, gets kicked - all
  6. Actually, you shouldn't have to manage the life of bots yourself. At least they shouldn't be invincible by default. I suspect where the problem might be. You create the bots at z position 0 or 2. z = 0 means sea level. You're creating them below the ground. And there is no water in that place, they just fall down. Which leads to this: When peds fall below z coordinate -100 or something similar, the game teleports them at some point on ped path. However, that's from the perspective of GTA SA. If you weren't the syncer when that happened, MTA server still sees the ped at the positio
  7. Thanks everyone, I'm happy to know my works are appreciated here. Yes, but this is one of the reasons why I regret leaving for so long. If I had left without having done anything important for people to remember me, it would have been easier. No one looking for me and wondering where the hell I disappeared. Now it's more like I created expectations for people and then vanished. I heard about it when my website went down, and I thought I should bring it back, maybe run a server myself, but I never did because "I'm not in the mood at this moment". Glad I didn't even have to in the e
  8. I don't know why I even have to point this out since this is something I figured out automatically in my early days of MTA scripting. But it seems necessary because I see people using Lua tables but not taking advantage of their flexibility. Very brief overview of tables as arrays Anyway, Lua tables are often used as arrays - that is, data structures that store values under consecutive integer keys starting at 1 (0 in most other languages, but that's another story), making a sequence. Various functions that operate on tables, including those in table namespace, treat them as arrays.
  9. It means you pass a boolean to ipairs, which means "result" is a boolean. According to dbPoll documentation, it returns false if there's something wrong, in which case it returns two more values indicating what went wrong. So if you change this: local result = dbPoll(qh, 0) to this: local result, error_code, msg = dbPoll(qh, 0) if result == false then outputDebugString("Error code: "..error_code) outputDebugString("Error message: "..msg) end it will display a more detailed message.
  10. The variable name in that function's parameter list is "targett", but you're checking "target", so it's a different variable.
  11. My mistake, I meant if isElementSyncer(source) then But now I looked at your code more closely and realized that this checking will prevent the code inside "if boss == "Mutant" then" block from working when the attacker is not the syncer, because that code requires the attacker to be the local player. So that would require more changes. Or you can just keep using "attacker == localPlayer" instead of isElementSyncer after all.
  12. Player damages won't duplicate, right, but you probably didn't notice my first reply. If you use isElementSyncer instead of checking "attacker == localPlayer", the damage will be synced by the player who syncs the ped, and there will be no duplications whether the attacker is a player or a ped.
  13. The damage will still be triggered multiple times if multiple players see the ped damaging another ped.
  14. This has the advantage that the damage event will necessarily be triggered if the attacker sees himself hitting the ped. However, the attacker is not necessarily a player, and the server side code indicates that peds are supposed to damage each other too. Therefore, this code prevents the event from triggering in cases where a ped damages another ped. It's better to check if you are the syncer of the ped: if isElementSyncer(ped) then end This way, the ped will be damaged if the player who syncs the ped sees him getting damaged. It's also more consistent this way because that's exa
  15. There's a simpler solution: use function getAccountsByData. If no account has the value, the returned table will be empty. So this expression will evaluate to true if the number is already taken: #getAccountsByData("bank", bank_number) != 0 Apart from being easier, using getAccountsByData has the advantage of working correctly even if new bank numbers get added from outside your script - which may or may not be relevant in your case. And if you still decide to keep track of them yourself, the problem with the script is that in_table function loops through the whole list of bank num
×
×
  • Create New...