Jump to content

Bungle

Members
  • Posts

    46
  • Joined

  • Last visited

Details

  • Gang
    ULK
  • Location
    Liverpool, England

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Bungle's Achievements

Rat

Rat (9/54)

0

Reputation

  1. Bungle

    Iyon's Stunt Server

    Way to go bumping a 6month old topic I ran the DNA clan's stunt server roughly around the same period, which if I recall we often competed against in getting the players but I do recall both were equally as populated on average. Did attract quite a few from Iyon's and that then defunct server was often mentioned, although naturally the effect could not have been the same. It still runs now, albeit much less used
  2. Bungle

    !carloc on MTA:VC

    That is a good example about not being a feasable script (although i admit, i never thought of that, but it still validates my point) I suppose if you returned a list of cars that were closest (say the closest 3), it might be a workaround for that, but again that is adding additional workload to the scripter and the CPU which is un-necessary. I am not a fan nor a user of GRS so i can't comment on the the script which is included within it, but if you say that it is CPU intensive, i suppose that speaks for itself.
  3. Bungle

    !carloc on MTA:VC

    I agree with Tommis's point about the un-necessary activity that would be required on the CPU, though not because of it being separate players (i have noted this below). I don't feel it's a feature worth attempting for the reason of the points that i mentioned both in my first post and the paragraph following the below code example. on *:signal:mta.command: { ;check if cmd is !carloc ;check if the car is in use by someone now ;(if true, return the location of the driver) ;else goto below code ;check if there is an entry for when the last person used it ;(if there is, compare it against when the player joined the server) ;if player joined after entry was added, they will see it at spawn, so return default location ;else we'll assume they were in game when the entry was added, so they should see it at the coords that are in the database ;else if there isn't an entry, assume the car has yet to be used, so should still be at default spawn location } That is basically how i see it, though i don't see any point writing a whole script because i don't see it actually being worthwhile. There are 2 ways of doing it though; 1) using car IDs (much easier from a scripting perspective), 2) using actual car names (starts to get icky). If you use CarIDs in the !carloc command (so search for a exact car), you can simply reference the number with the database and check if there is a match. However, if you use car names, not only will you have to convert it to an ID, but also it would then have to calculate the current location of every vehicle that matches that name, and return the result of the one which is the closest to the player upon executing that command. Whether that is what you meant by "CPU Intensive" tommis, possibly, as that is only reason why i would think it would be intensive on the processor. My script uses CarIDs, so players simply have to remember which ID the car they want to find is. This also assumes, as i mentioned in my first post, that the player executing the command is actually in game, and if they have just come in game, but had been connected to the server for a significant amount of time, additional code would be required to check if their status has only recently become ingame (again, that may require a constant timer for every player which also adds to the CPU load as Tommis pointed out). Basically my point is, to get a good script of this is certainly not worth the effort, at all - Bungle
  4. Bungle

    !carloc on MTA:VC

    i wouldn't recommend even attempting to make a script like this. I have one coded by myself on our stunt server and because of the way the server engine works, it doesn't work well for newly joined players. You are correct when you say you can record it's location when someone exits; however, to my knowledge of the way the 0.5 core works, when a new player joins, they see all cars at spawn unless a player is in it (ie: if a car was exited at south of the map and it's original spawn was north, if a new player joined and noone was in the vehicle they would see it in the north). It works "ok" for players who were in the server at the time someone exited the vehicle, but i wouldn't use it for general usage. Now, if the server engine is where the current car locations were kept (memory), then we might have a different story (being client side though causes that issue). The only way around this i see is by calculating when the player exited the vehicle, and when the player initiating the !carloc joined the server. So, if that player joined after the carloc entry was added, then give them the location of where it spawns. Therefore, if they joined the server before the carloc entry was added (so if they were in game whilst someone exited), give them the coords that are in a database you have made). Of course, this would only work if the player is actually in game, and not just connected to the server - Bungle
  5. Bungle

    MTA:MA Scripting

    The $2 parameter IS the player's id, you use it to gather other information about the player. Unless you mean how to get a player's ID if you have their name (so the opposite). There is a command $mta.getid(SERVERID,NAME). So if i was MTAPlayer and you wanted my ID (and say it was 11), if you used the command $mta.getid(SERVERID,MTAPlayer), it would simply return "11". This also works for wildcard searches, so $mta.getid(SERVERID,MTA) would also return "11" if there was noone in the server who also had MTA within their name (and if they did, be more specific on the name ) It's actually detailed in the manual you get with MTAMA if you want to look it up further.. - Bungle
  6. you need to learn hash tables my friend.. you can use them to store ips/usernames instead of just checking against 1 hard-coded ip all the time (though some might argue text files do the same job.. but hash tables are still worth learning ) *grins* i suppose you could have spaced out the lines a bit to make it more readable.. but meh - Bungle
  7. i stopped playing 0.5 deathmatch many months ago; the only fun times i have with 0.5 now is on our [DNA] stunt server, but even that aint the same as it used to be. times just.. change.. you can't expect time to stand still at all.. especially not as far as online gaming is concerned. I can honestly say from within, my own opinion of course.. any server running rpg can't really be regarded as a proper server (at least as far as knowing what a proper MTA DM server can be like). I haven't been the most well-known community member or skillful player in MTA, but i have been around here long enough to see a change that maybe isn't for the best, but has happened, and hopefully MTA:SA will try to turn back some time and regain what's been lost over time. XBlade, i know where you're coming from, but rather than looking back, look ahead (at least the future hasn't happened yet, so could swing either way, unlike the past/present which really can't be changed). Sorry for the mini-essay - Bungle
  8. at first, i thought you were lying when you said they were fake. nice work, believeable (if they aren't real, heh) second one is pretty classic - Bungle
  9. having N/A next to my contact details aint cool.. my msn messenger account is [email protected] thanks to those who have responded and it's nice to be fully back in the MTA scene again! - Bungle
  10. accurate admin list for stunt.. lvl5: [DNA]Bungle, [DNA]JunX, [DNA]Capone, [DNA]DoPeY lvl4: [DNA]SmartiE, [DNA]Crack lvl3: [DEW][NDER, BNW-Bunny101, [VCP]Mike lvl2: lvl1: [DNA]DC, [DNA]yetty, Hanney2K5 (i also lvl5 on the other servers) - Bungle
  11. Bungle

    Bored at work...

    http://www.divisiontwo.com/articles/mcse2.htm .. i think the "Windows versus Linux - Preference Tracking and Calling Home" paragraph was most ammusing.. something that ammused me in work today
  12. it aint often i am amused by something like that.. but classic - Bungle
  13. they really should consider maybe ending the vice city app/process if the player disconnects from the active server, would prevent stuff like that happening (just a thought) - Bungle
  14. it's pretty rare that the script has caught anyone getting over 2000 for a stunt, and if it was a genuine one, i am sure they would feel the need to comment on the server if they were penalised for a genuine high stunt. It only bans if it catches them getting over $1000 3 or more times, any would simply kick any amount less than that. It might not be a great way to prevent cheaters of this variation, but to date and with the limitations of scripting in the current core, it's the most effective way i have been able to think of (any suggestions though would be quite welcome). - Bungle
  15. you don't "need" it if you are capable of making your own
×
×
  • Create New...