DiSaMe

Of course, because you didn't use timer on that. You used timer on an empty function.

I see no reason why it's impossible to make compatibility like this. The only thing is that MTA developers would have to copy code from race to make DM client work as race works from server's point of view.

OK, OK, but as I said, I can't do it right now because I'm in the countryside. But when I return, I will try it.

That doesn't change the fact that adjusting the position of a remote player makes no sense imo. What ever client side change you make to a remote player only affects what you see. In other words, the newly calculated position for lead aim will always be relative. yeah, it only affects what you see, this is what we all need because lag makes us see the past. When I am shooting, I always shoot not where I see player, but where he should be after bit of time. In this way I shoot accurately. In other words, this script already works when I use it in my mind. Now I only need to move it to MTA where position will be calculated even better.

Only for GTA SA. Because of game limits. MTA client still keeps information about them. Otherwise there wouldn't be function that checks if element is streamed in. But I have an idea. Map file could be put into server as a downloadable file. And some script could put them client-side. Then nothing would need to be transfered between client and server. But this would only work good with objects that aren't moved, rotated, etc.

Yeah, I will try it. But only when I return home. I'm in the countryside right now and I'm using my mobile phone to post here

you misunderstand this. This has no influence on bandwidth. Not even a byte would be transfered between client and server. Position changes in client's side and goes back after one frame. Just because script is small, it doesn't mean it can't help. At least problem is small too - some player is shown a little bit to the side from where he exactly is. Big thing, huh? So we can use a small script that corrects this small problem.

lol that would be like disabling half of the netcode that makes mta's sync so good^^ No, it disables nothing, it makes sync even better. I do this line of code in my brain when I'm shooting and I choose much better position than super perfect wonderful (no, I don't say it's bad) MTA sync does. And script could even do better. It would be an add-on to the sync

What about single-player? You can only set resolution in GTA without running MTA.

Hey, what about compatibility between race server and DM client? My friend keeps installing, playing and uninstalling race, then doing same with DM. He knows it's possible to keep them both at the same time, but this is the easiest way He plays DM because of its features and race because there are many good maps (offtopic: he also plays SA-MP, a few days ago I made a CLEO script that makes player invincible and we "tested" it on SA-MP, worked good ). Server browser could have DM and race tabs. Then DM users could have "full" fun without installing race. And finally everyone would stop using race client. DM client would become race client+more

setElementAlpha or whatever it's called

Maybe scripting a good server-side objects streamer would help

I think minimizing the game must be possible. Cheaters? They use windowed mode and don't care about FPS. And there are much more ways to cheat. And sometimes when you MUST go to desktop, you have to exit the game. This is much more annoying than cheaters.

Actually when you press TAB, only minimap becomes invisible unless scoreboard script is run in the server. And PM window can be scripted too.

yeah, this is EXACTLY what I wanted to know. Thanks for the information. I think it would be possible to sync position by doing xpos + xvelocity*(other_player's_ping+local_player's_ping). Car position sync is important too. It would let to do P.I.T. and make drive-bys cool.

Alt+tab because sometimes we need it. Players can cheat in this way? There are much more ways to cheat! Also, they can already use window command and there will be no difference. And there is a big difference to non-sucking players because it's slower and it's more fun when game is in full screen. Animations are very important too. And of course, bots. They could even help to test gamemodes. If peds are possible, bots should be too. I'd want to see them having element type "player" with same events being triggered, ability to use commands, "pressing keys" and only able to add and remove by using botConnect and botDisconnect functions because player elements cannot be simply created and destroyed. Well, maybe in some later version, not DP3

First of all, I want to say I DO know client-side can't control server-side elements. But would there be any visible effect? For example, if I put non-local player into other position, would I see him there at least for one frame? I ask this because I want to make well synced position script that would show players in their estimated position like we shoot to the front of running players, not to them. But if it's not possible to do this, then it's a suggestion about better sync to implement into MTA

But why isn't this possible? All elements have their numerical IDs, right?

I suggest making an optional argument for attachElementToElement function: first person turret mode for player elements. The same that is used on some missions. First person shooting, big crosshair. Would be nice to use with helicopter and minigun, for example.

Lua isn't downloadable. Only compiler can be downloadable. And because MTA compiles everything, there is nothing to decompile for you and it's even possible to use notepad or any other text editor that can save files

It's not necessary to use numbers for IDs. If it's really needed, it's already possible to loop through all elements, they have their own numerical IDs

No, it's not.

What? They DO make roleplay servers. Many roleplay scripts are in development.

I had the problem with sky flickering. I read the FAQ and as it was written, I tried typing ceguitext 1 into the console. Problem was solved. But another, bigger problem appeared. Text items are always aligned to left-top and are a little bit bigger than with ceguitext 0. Bad alignment often makes part of text appear off the screen. This happens only with text created with textCreateTextItem. Everything's ok with GUI text.