darkdreamingdan

No, the source dependencies arent required. You need these dependencies: http://multitheftauto.googlecode.com/fi ... a-r175.exe

I dont think you need to replace the net.dlls. The important thing is to install the nightly, then the Dependency files in GTASA\MTA as you stated.

Firstly your registro command handler is wrong, you forgot quote marks, it should be: addCommandHandler ( "registro", hideLoginWindow ) As for the kickPlayer if you dont accept, you will need to use addEvent serverside and triggerServerEvent from the client script under an onClientGUIClick handler. See the examples in onClientGUIClick and triggerServerEvent in the wiki to see what i mean.

I dont know, its one of those things like Garage doors. They're synced in 1.0 but its because R* conveniently assigned them all IDs which can be used to easily retrieve them. In the case of traffic lights, its highly unlikely they'd bother tagging them individually. Instead there's probably an overall system that takes nearby lights. That's just a guess, but it immediately makes it more problematic to start trying to figure out how to retrieve each set of traffic lights so that they can be set.

It just means noobs get censored which is what we want. Its fun to see trolls get their posts raped by the censor.

For now, i have developing the gamemode in 2.3, but will be a good idea to test the nightly builds of 1.0. Thanks for the idea I never worked with pawn, for me, is very hard than lua. I have a question, it's possible to combine functions, scripts, etc..., between MTA and SA:MP emulator???? Ex: An arrest script in SA:MP, and a GUI in MTA that show the arrest code in SA:MP emu. So, let's test the nightly build It is, but its not ideal. Since SA-MP scripts are "gamemodes" and forcefully take control of some aspects you might want to control yourself. For example, SA-MP forcefully provides a spawnscreen which you cannot remove (e.g. you want to add a Login GUI and a License agreement instead). You may be able to modify the emulator to ignore some aspects but that's where it gets complicated. If i were you i would start from scratch with Lua. MTA provides much better functionality to write your own arrest script - rather than using a crappy "/arrest" command, scripters have the ability to detect bullet shots and melee hits which you can easily use to trigger an arrest.

Please dont troll in other forums, we dont encourage that at all and infact its the opposite of what these sigs are trying to achieve.

First things first, are you developing for DP2.x or for MTA 1.0 (MTA 1.0 has much improved scripting functionality but is unreleased)?. Its also worth mentioning MTA 1.0 will offer proper Joypad/Gamepad support, which will no doubt be essential for any racing servers. Also, if you still have your SA-MP version of your script, you may be interested in an SA-MP Emulator: https://forum.multitheftauto.com/viewtop ... 15&t=23863. This is only compatible with MTASA 1.0 and will require you download a nightly. Obviously this is a good solution but we highly reccomend switching to Lua due to speed and sheer scripting capabilities it offers (e.g. just like the GUI you have here, something which is not possible in SA-MP). But yeah, even if you're not strong at Lua we'll be happy to help. You should find there are many perks over using PAWN.

Admitedly i didnt spend long making the tree, emphasis was on...the other part. Unfortunately no one's yet to bring it up yet, lol.

Actually if we were communists, all the posts would have remained. Now stop being an idiot.

Yeah i've seen it. I believe its actually Rockstar who did it, but we thought of that slogan long before they did. Its probably a coincidence.

how about dynamic as in changing continuesly? like a previous version, not having to refresh to see them all He already made one. Making them all show without having to refresh sucks though, it completely gives the game away imo.

your best bet would be to hack this in yourself. You could do it like this, by importing this into every resource that sets skins: addEvent"onPlayerSkinChange" local mta_setPlayerSkin = setPlayerSkin function setPlayerSkin ( player, id ) local set = mta_setPlayerSkin ( player, id ) if ( set ) then triggerEvent ( "onPlayerSkinChange", player, id ) end return set end It would be tidier to create a skinchange.lua and seperate it there. To use the event you could simply adapt what you've already written: function cop1 ( skin ) if ( skin == 280 ) then setPlayerTeam ( source, police ) else return end end addEventHandler ( "onPlayerSkinChange", getRootElement(), cop1 )

Last time i commented on something like this it ended up in the person flipping out at how useless we are and spend all our time playing hay. But essentially this isnt going to happen anytime in the near future to the nature of it.

Yeah the argument overshadowed the post i made

Yeah i read about this - and actually its present in all versions of IE supposedly. Get some other browser. Full article here: http://news.bbc.co.uk/1/hi/technology/7784908.stm

It's worth noting that 1.0 now offers a redirectPlayer function.

XetaQuake is probably correct on this. Can i just suggest trying your script on a 1.0 development build to see if performance has improved.

willy's link is outdated. search the forums - there's an API that offers full argument listing

Anyone suggesting you to destroy the object clientside are wrong - you'll find that serverside elements cannot be destroyed clientside. As i mentioned earlier, surely using setElementDimension clientside is what you're looking for? You can write your own algorithm to decide when to hide and show elements by setting the objects (not players) to a different dimension. For example you could easily use the onClientRender event to work out when to show elements that are within <20m range. If you want to do this from the server, its simple enough to code something like hide/showObjectForPlayer using triggerClientEvent and setting dimensions appropriately.

simple: setElementDimension clientside. Serverside objects exist both serverside and clientside. You can use IDs or lots of other methods to retrieve them. Also you might want to try development builds to see if performance has improved in 1.0.

You can get a copy of the development builds which have ped support in them, just check the development section.

Such an error reporter was actually built into Race and MTA0.5. It could easily be reintroduced, just we have an Open Bugtracker now so people can report bugs there. The problem with such error reporters is that for it to be useful, we need people to give steps to reproduce.

A) Yeah, you stole my guitar skills! Q) What's tall, has two legs but doesnt walk?

Ped functions are both clientside and serverside, and will work for players and peds. Despite this, peds and players remain as two seperate elements that simply share functions. I also believe the old player functions redirect to Ped functions for compatibility purposes.