karlis

http://rbwhitaker.wikidot.com/bump-map-shader-1 this, and library from some of the shaders examples in wiki is all you need. basically, in shader examples there is function somewhere that calculates the lighting way gta does, edit the function to include bump mapping.

considering the relative complexity of race engine and question the op was asking, its not that easy for him.

make vehicle gravity point recalculate on planes when planes pitch/roll or go fancy and make rocks actually have gravity, some clever maths and moveobject, and there you have a solar system also probably you could make the ped rotating too, if rotating world instead of ped. did you use some kind of texture replacement?

nope

they are just not handled at all

no, you will have to figure out yourself how to even read the traffic data.

mta is as playable as samp, it depends on server hardware and internet, but neither would be playable when all players are loaded in, do 800^2 and you get how much syncing packets would need to sync all players to all players.

so i tested it, and indeed the problem is nothing else then sync and bandwidth. with even few cars the syncing is bugging out seriously, no velocity seems to be applied at all.

is test over, i kind of forgot

ok ill get in if i can

ped is a table in main table, which contains all controls that you're going to handle. if you're using this of accelerate and brake buttons, with 10 peds syncered per player, it'll be 20loops only. and, as you see you're not forced to call the func for all players, just the syncer.

i didn't test it, and there's some probability i left in some silly bug, but this could improve the driving alot by emulating float control. local controls={} local realcontrolvalues={} local controlframecount={} function emulateAnalogControl(ped,control,float) if not controls[ped] then controls[ped]={} end if not realcontrolvalues[ped] then realcontrolvalues[ped]={} end if not controlframecount[ped] then controlframecount[ped]={} end realcontrolvalues[ped][control]=getPedControlState(ped,control) and 1 or 0 controlframecount[ped][control]=1 if float then controls[ped][control]=float else setPedControlState(ped,control,false) controls[ped][control]=nil realcontrolvalues[ped][control]=nil break end end addEventHandler('onClientRender',root,function() for k,ped in pairs(controls) do for n,control in pairs(ped) do local tempavg1=(realcontrolvalues[k][n]*controlframecount[k][n]+1)/(controlframecount[k][n]+1) local tempavg2=(realcontrolvalues[k][n]*controlframecount[k][n])/(controlframecount[k][n]+1) if math.abs(tempavg1-control)abs(tempavg2-control) then setPedControlState(ped,control,true) realcontrolvalues[k][n]=tempavg1 else setPedControlState(ped,control,false) realcontrolvalues[k][n]=tempavg2 end controlframecount[k][n]=controlframecount[k][n]+1 end end end) PS: higher fps=more accuracy

you could implement a accelerate release on a sharp turns so bots can make the turns without going away from road.

it sure does not. as im not aware what is OP trying to do i cant help too

unlike complete gamemodes i think this should be released,after all its more of a tool for better maps in general, and adds possibility to be creative. good work.

testing links, codes, images and yt vids in spoilers EDIT: seems all works, but links need in these.

woo good work PS: too bad spoiler cant contain spoilers, couldn't prank with 10spoilers on each other

hey, this i script i have made long time ago, originally to get paid, but seems requester lost interest, so i decided ill release it to community eventually. there's a lot of tweaks and balance and even some features yet to be made, but you can see the idea. don't mind the bugs, most of them are fixed by now. also sorry for the lag, i was doing more then my pc could handle, and on bad fpslimit. and, don't say that aiming is improper, i know that, and its accurate now. for those, who are wondering, physics are made completely from scratch, and handled as object position change onClientRender

i have managed to make it, however it is not perfect. that is, checking doesn't centre of screen collide is very simple, i did it, but checking all four corners and doing proper maths to zoom camera in isn't easy at all. i used freecam res as original source, and edited it quite a bit PS: camera can be seen in viewtopic.php?f=98&t=37648&p=387866#p387866

unfortunately this dont work that well, because some of the scripts(syncing of something the most) requires approval and data from client, that server just cant get without client input. so this cant work on all solutions, unless you do really complicated and not well working matching between various players and etc.

its not that it has serious compatibility issues i bet, slight function of their syntax changes.

spanish, it calculates shortest road to a point, what is wrong in that? and why cant you fix it?

few suggestions, some are hard to make, but would look cool: 1)light up the screen by capturing the screen source onClientPreRender, and using shader to brighten it up.(or probably just drawing half transparent white dx rectangle over the screen) 2)make the sound actually come after bolt(irl the sound speed is ~1000km/h comparing to light speed of 300000km/s, so obviously sound comes last.but as SA is smaller scale i'd advise something like sound speed 500kmh here) 3)randomize the color a bit 4)make lighting bolt bit fatter 5)add sub-bolts kind of stretching around the main one with bit other color and tinier.

as i said already, a syncing algorithm synced by randomseed would work the best, literally no bandwidth used. harder to implement tough.

and only thing explaining the postGUI thing is that you got any nil arguments before the postGUI.