Maccer.

Hrm, thanks. But how do you write binary using fileWrite? It only takes strings AFAIK. Sorry if I'm slow, really sleepy.

Hrm, I can imagine fileCreate being able to make a .txd, but the real challenge and the thing I'm impressed about is how you transferred draw coordinates successfully. At least share that with us.

Just stopping by here: getElementPosition(vehicle model="411" posX="x" posY="y" posZ="-23") is wrong. getElementPosition ( vehicle ) -- vehicle can be retrieved using any getVehicleFrom... or getElement... commands. Is proper.

Fire can only be created when the position is streamed. Here are two alternatives. Create fire on stream: addEventHandler ( "onClientElementStreamIn", getRootElement (), function ( ) if ( source == [i]streamed_in_object_goes_here[/i] ) then createFire (3226.576171875, -1374.0059814453, 4.2633757591248, 5) createFire (3226.4548339844, -1355.01538085, 4.7059955596924, 5) end end ) Create an invisible torch, with fire fx. Limited flame size though : _createFire = createFire -- MTA's createFire function transferred to _createFire function createFire ( x, y, z, rx, ry, rz ) local tempObj = createObject ( 3461, x, y, z - 2.5, rx, ry, rz ) setElementAlpha( tempObj, 0 ) setElementCollisionsEnabled ( tempObj, false ) return tempObj -- returns an object, so it's deletable by destroyElement end They're untested, but should work.

Could you please provide further details of what's broken? To assist, here's the resource... The resource: https://community.multitheftauto.com/index.html?p ... ils&id=761 Just from a quick look, I noticed it contains server-side colshapes.

The tab ordering doesn't work, and there's no player search list. But I think you probably knew about this. I like the GTK interface though, but it's a resource hog.

Like another poster said, you're part of the GameNet.fi team. You guys just talk, you don't do anything else. And why does it matter if I have a server or not? So yeah, you're just egoboosting like a previous poster said. You haven't even given us a valid explanation of how the script detects s0beit.

Yeah, that's another bug with our crappy animation system. At the moment, a real hacky way to do this (but easy), is to just set a timer to stop the animation. (setPedAnimation(ped) - Kills the animation, no extra params.)

So... where's the code? I'm a little skeptical of how this works. I still don't understand how it detects m0d_s0beit on F12. So release the code, and don't delay it like last time.

I've been watching this for some time, and I have to say, it has really evolved into something big. But you know, this is just my opinion, but it would be nice for you to create a gui out of the dx functions. But that would be a big rework. I just think it would look fashionable. But anyways, can you direct me to the part of your code in where it has the ped/vehicle interpolation? I kind of need that. Also, wouldn't it be easier to key-sync peds client-side using frames? onClientRender + getKeyState.

Implementing anti-airbreak is kind of useless. It's kind of hard to use it before MTA detects an interpolation error and displays a "NETWORK TROUBLE" momentarily.

No, they aren't.

Why server-side? Try client-side. When you die, it gets sync, so there should be no problem. addEventHandler("onClientRender", getRootElement(), function () if(isElementInWater(getLocalPlayer())) then setElementHealth(getLocalPlayer(), 0) end end ) This is a snippet, but all you have to copy and paste this code somewhere in your code.

Dance: http://dan.bastage.net/mta/dance.zip Aztec: http://dan.bastage.net/mta/sth-aztec.zip

I'm just curious. I see a lot of people complaining about the low FPS of MTA, and some about how fast it is. Well, I have two sides... : I had a Pentium D that lagged horribly on MTA, but it was a GPU problem during the DP2 days. It was pretty much 45 FPS vs 10. Now I have a Core 2 Duo and MTA runs 140 FPS vs 120 FPS on Single Player. So please answer the poll, and put up your CPU and selection.

I get higher in MTA, 80 vs 140. I think that people that have low FPS on MTA has single core processors. My old Pentium D lagged on DP2 though. But it was a graphics card issue, I could only run it on 640x480.

First of all, you didn't need to create these extra variables. You can just simplify things by doing function randomVehColors() for i, car in ipairs( getElementsByType( "vehicle" ) ) do setVehicleColor ( car, math.random(0,126), math.random(0,126), math.random(0,126), math.random(0,126) ) -- setting color to vehicle end end setTimer( randomVehColors, 500, 0 ) -- timer changes all vehicles colors to random every 0.5 sec. I hope this is a client-side script. It should be straight forward on how to create headlight colors. Only headlights only take 3 params, and they range from 0-255, RGB. https://wiki.multitheftauto.com/wiki/Set ... LightColor The MTA wiki pwns.

Maybe he was just doing the old nick-trick. Before: (0) GenericPlayerName (1) LazyAdmin (2) Troll After: (0) GenericPlayerName (1) LazyAdmin (2) #FFFFFLazyAdmin

Word Of Mouth - Two of my friends told me about an upcoming beta test. Too bad my computer could barely run it, MTA:DM was buggy back then. I was forced to play it at 640x480. :\ I kept on watching the MTAQA videos and fantasizing. But then I eventually got a new P.C... and when I heard about MTA going open source, I started playing it.

I don't mind - GiT was really hard to setup until I used SmartGiT. GiT is really bloated, but it's helpful for new developers. It got individuals coding, but kind of stifled MTA Development progress. :\ I'm kind of stuck on this one. Ryden also had a point, coding in GiT was like coding for work. It felt so... corporate, not that it's a bad thing.

Check the documentary, MTA introduced some SA:MP functions for you to work with, and also the possibility to use MTA code.

he made a typo there +1 Me on MSN while chatting with someone on this: "If it's server-side. Each vehicle will have it's own handling data. It will have longer download times. It's just easier to apply all of the data client-side."

I say "let the server owner" beware.

Okay, so, lately there's been some resurgence of the works regarding the handling functions by Flobu and MrHankey. There's been debate about whether it should be client-side, server-side or both. Talidan, and lil_Toady have said this should be server-side, so flobu disabled client-side handling. I respectfully disagree, I think it should be both, since this is perfectly syncable client-side, and it could be server-side at the same time. Keep in mind, these handling functions are per-entity: meaning each vehicle element can have it's own handling. Each vehicle element is individual. And plus, client-side handling allows quicker changes, and not all handling information needs to be synced. It's kind of like the client-side createVehicle ; only for showcasing. And handling is already hackable without any handling mods, so we can weed out the protectionism. And plus, the handling mod allows the restoration of the default handling. setElementVelocity is client-side, is that justified? I think the same argument could be applied with the handling functions. And plus, I use setElementVelocity for a boost key... client-side. And it's synced alright. Your thoughts, people?

onPlayerDamage doesn't register when you have god-mode, along with other events. I think wasEventCancelled() can fix this though. But there's so much events in MTA, there's all sorts of ways to detect it.