Gamesnert

I've been working on the vehicle entry / exiting for 1.1 for a while now (ok, to be honest, it was slacking / other stuff I had to do most of the time) but recently when trying to fix my entry / exiting code, I kind of stumbled upon a rather interesting "issue": Passenger jacking. (Gee, who would have guessed that from the title?) So I've spoken to ryden and being able to jack passengers seems like a good idea overall, if there's a way of specifying whether that's actually desired. Make "enter_passenger" control (default: G) take the closest seat possible, jacking who's inside Make "enter_passenger" control find an empty seat and take that instead (Current default) So: - Which of these do you think should be default? Easy enough question: Should entering as passenger just rid the closest passenger of his seat, or should police on RP servers politely ask criminals to leave their vehicle when arrested? So now that I've asked that, another question: - How should players / servers gain access to the alternate method of entering as passenger? Imagine you would want to sit with 4 people in an Admiral with passenger jacking enabled. You'd have to position yourself around the car in such a way that the closest door is really the one you wish to enter, or you end up jacking every soul in the car just to get into the right seat. However, without passenger jacking, it would be kind of stupid to steal someone's car and drive it half way to your hideout, just to notice some old lady sitting right next to you. (Somehow glued to the seat so tightly you'd wonder why there's no way to remove the entire seat from the vehicle in the first place) A possible solution we considered is adding a parameter to the "enter_passenger" command to allow you to decide whether you want the jack functionality or not. This could be used to both players and servers: Players: /bind [key] enter_passenger jack Servers: bindKey ( [key], "down", "enter_passenger", "jack" ) If you have any other suggestions, I'd like to hear them.

Which only shows up if you press a button which says "Messages 0/0" most of the time and if someone sends a report, the only thing that happens is that it turns into "1/1". It's way too easy to miss.

You don't háve to divide files. Files are divided so it's easier to find particular pieces of code, but you don't have to divide scripts. Just if you want to have both server-side AND client-side, then you'll need 1 script for server-side, and 1 for client-side. But except for that, it's only for convenience.

I have helped a server get rid of the cheaters for the most part. Here's all you need to do: Block all versions lower than 1.0.4, so also block 1.0.3. This'll make it harder for people with hacks to join a server Get that anti-cheat by PhatLooser Get a few (good and active!) admins Create a simple report system, so people can report cheaters to admins (possibly via IRC / E-Mail using the sockets module) That's basically all you need to do. You'll be surprised how many cheaters are already prevented by blocking versions lower than 1.0.4. Barely anyone non-cheater still runs 1.0.3 or lower anyhow. PhatLooser's anti-cheat will prevent s0beit pretty nastily, don't count on them doing a lot of harm after that beast has been unleashed. And the report system and admins would be a pretty fail-safe system, just in case the hacks aren't being detected. That's all. Of course you'll still have some problems with hackers, but it won't be out of control; not by far.

The newest map editor should be able to load maps, no matter how big they are, completely. (newest resources can be downloaded from HERE) As for disabling the freeze checks, there's simply no need to do this. Think about this: You're basically asking for a function which will freeze the server so hard, it'll be incapable of doing the following things until the script is done: Handling players on the server Handling connecting players Handling sync Letting other scripts execute ... I doubt that's what you would want. There is an alternative however. Lua provides coroutines. What this does is giving you the ability to "pause" your function. If done correctly, the server would have some time to handle all other required tasks it has to perform. So the server doesn't freeze up, and there's no reason to show an "Infinite/too long execution" error.

Scripts are unlikely to be made for free. If they're made and for public use, they're on the community website. If they aren't on there, you'll have to either make your own or try to convince someone of making it for you, which is much less likely to succeed. Also, if there are multiple people involved, it sounds to me like there is someone in the team with more scripting knowledge than you. Why wouldn't you simply let him look at Orange's post and respond to it?

Disable the firewall. It blocks what you want to let pass through, and lets pass through what you want to block anyway.

I don't understand the problem. Can you please explain what errors you're getting? And can you please show us some code so we can see what you're trying to do?

There is an animation file (ped.ifp, if I recall correctly) which is also between the list of checked data files. Apparently, ped.ifp can be used to someone's advantage. Frankly, I'm not sure in what way, but if I remember correctly you could make yourself run faster and jump higher. EDIT: As the original ped.ifp file doesn't appear to be in the data files zip, I've hosted mine HERE. ( ~ 1.4 MB)

<!-- This is a comment, whatever is inside this, won't be read by MTA --> Meaning the solution is to remove

The functions "mysql_connect" and "mysql_errno" are functions from the MTA-MySQL module. In case you don't know what a module is, it's kind of like a file that adds functionality to the MTA server. (in this case, MySQL) To solve this problem, simply install the MTA-MySQL module like described on the wiki page, and you shouldn't have any problems.

Use "source" when you want to know what's the main element involved in the event (for instance, source = the vehicle a player entered in onVehicleEnter) Use "client" if you've triggered a server-side event from the client, and want to know what client triggered the event. Use "player" if you've actually defined it.

Well, you could make a small plug-in script for it. Just a small script that gets all the translations of one resource and declares is. Besides, that's why I also included language.HELLO_WORLD in the example.

It may be worth the hassle for servers which prefer multilingualism. I'm sure there are plenty of those servers. The arguments stated in that topic mostly apply to MTA itself. In C++, it's much harder to make something multilingual than in Lua, and because the main menu contains mostly basic stuff most people can understand (or at least randomly click) it's really not worth it. But on indivudual servers it's easier to implement, and servers might prefer it. Oh and if I may make a suggestion, make it something like this: <lang name="English"> <!-- possibility #1 --> <string id="HELLO_WORLD" text="Hello world"/> <!-- possibility #2 --> <string id="HELLO_WORLD">Hello world!</string> </lang> -- Possibility #1 outputChatBox(HELLO_WORLD) -- Possibility #2 outputChatBox(language.HELLO_WORLD) In this way you can make it as descriptive as you like, without having to waste a long line on a difficult export.

I'd keep it English-only as well. Several reasons for this: The main menu is nothing more than a few clicks. It costs a lot more effort to implement multilingualism than it might solve People playing an international game should, in my opinion, speak an international language. (unless they're on a server with a specific language) It's very annoying if you're having a friendly conversation, and someone suddenly comes in and yells a language you can't understand right through your conversation. Multilingual MTA would encourage this behaviour People got to the English website, got to the English installer, got through the English installer and they're playing MTA. If they can get so far, they can really guess what the main menu does The translating hassle as Dr4x mentioned

For as far as I know, it has yet to be reported at the bug tracker. You have an higher chance of getting this issue on the 1.1 TODO list if it's actually on there. I think you should try putting a ped behind the steering wheel, see if it improves anything. If it does not, you should report that peds should have more synchronization in a vehicle. You don't need a lot of sync with an unoccupied vehicle, as it's only a waste of valuable bandwidth. With a ped in it, however, it's usually your intention to actually make it drive, so the sync should be improved for peds. And I think the unoccupied vehicle syncer syncs the correct data, but at a very slow rate. As I said before, unoccupied vehicles are usually just vehicle which are just sitting around, not doing much except for maybe driving down the hill because somebody forgot the handbrake. So it's usually simply not necessary to sync unoccupied vehicles in a not-poor way. setElementSyncer won't create (much) better results, because they're still "unoccupied" vehicles. And MTA doesn't really care who the syncer is. All setElementSyncer does, is allowing the scripter to decide who syncs the vehicle. But MTA automatically picks a syncer by default. So it doesn't improve the sync a lot.

% is about the same as doing this: number = 9001 while number >= 2000 do number = number - 2000 end You basically set a maximum for your number. If it exceeds the maximum, % rounds it back to within the range you specify.

Please note that you should also modify the actual width. You can modify the UV as much as you like, but this means the rest of the picture will be stretched out over the width and height. Your picture will always be 256 pixels wide with your script, because you specify 256 to be its actual width. The only thing the UV is for, is so you can decide to draw a partial image. For instance, if you'd be making a custom minimap, you wouldn't want to have to draw the entire minimap onto the screen. To fix this, you can try setting the width to the same value as you set the U width. Then it should work.

Does this sound like a particularly attractive offer to you? I doubt he'll actually pay (enough for being two "hard" scripts) to make it worth for anyone.

It's perhaps useful to post steps to reproduce, like a script or something. In my recent attempts for dxDrawImageSection, I can actually confirm it works fine. Either that or I made some mathematical error in which it somehow corrected itself correctly. Also, you noted that the function prototype indeed is: bool DrawTextureQueued ( float fX, float fY, float fWidth, float fHeight, const std::string& strFilename, float fRotation, float fRotCenOffX, float fRotCenOffY, unsigned long ulColor, bool bPostGUI ); However, this isn't the only function with that name. You can "overload" functions, meaning you can make another function with the same name, but with another return type or arguments. Like for instance: bool DrawTextureQueued ( float fX, float fY, float fWidth, float fHeight, float fU, float fV, float fSizeU, float fSizeV, bool bRelativeUV, const std::string& strFilename, float fRotation, float fRotCenOffX, float fRotCenOffY, unsigned long ulColor, bool bPostGUI ); If this wouldn't be correct, the function wouldn't even be in MTA, because it would fail to even actually compile.

It still does, but not every option. (Anti-Aliasing for instance)

1.0.4 is actually the new stable release. It's no longer a beta. About the CPU problem, do you have any special resources or modules running? Does this happen immediately, or after some time? Any more info you can give us?

Colshapes are a method for scripters to determine if a player or vehicle is within a certain area. This is mainly used in stuff like markers (like the Race checkpoints) to determine whether a player is inside the marker or not. The problem in 1.0.3 (and before, I guess) was that markers attached to other objects were slowing down the game significantly. Several markers could drop FPS to unplayable levels. In 1.0.4, colshapes have been optimized a lot, meaning they don't lag (nearly as much) anymore.

I don't get this... What's the point of this topic? It wouldn't make any sense to release 1.0.4 if 1.0.3 would be better...

MTA is failing at low FPS, because GTA fails at low FPS. Simple as that. And FPS being half, I wouldn't call that a "small difference", frankly. Anyway, there are several things you can do: Make sure you don't run anything on the background Try turning down resolution. It can help a lot Some things (like speedometers) can sometimes make FPS drop a bit. If you have such resources on, try turning them off Blur and clouds can be disabled in Race. In-game, open the admin panel -> Resources tab -> Click race -> Click settings -> find "blur" and "clouds" -> Make sure you turn them off (probably "false") You can lower the FPS limit of MTA. Go to %Place where you installed MTA% -> server -> mods -> deathmatch -> local.conf / mtaserver.conf (first if you use "Host game" in the main menu, the second if you use the dedicated server) -> Change 36 to whatever you like. (minimum = 25) When using 1.0.4, you can go to Settings -> Advanced and set "Asynchronous Loading" to "On". Should help on maps with a lot of objects. (if not running 1.0.4, read: upgrade to 1.0.4) If all fails, I'd suggest to either upgrade or replace the slower PC. Single-cores are just getting too slow compared to dual / quad / hexa / whateva core processors.