Jump to content

Car Rotators


ShayF2

Recommended Posts

Yknow how in car shops, they have some cars sitting on the circle platforms and the platform spins a 360 constantly in one direction? That's what I'm trying to make here. And I cannot get it to work.

rotators = {}

addEventHandler("onClientRender",getRootElement(),function()
	for i,r in ipairs(rotators) do
		if not object[i] then
			object[i] = createObject(i.object,i.lx,i.ly,i.lz,i.lrx,i.lry,i.lrz)
			setTimer(function()
				local px,py,pz = getElementPosition(object[i])
				local prx,pry,prz = getElementRotation(object[i])
				moveObject(object[i],11000,px,py,pz,0,0,prz+180)
			end,11000,0)
		end
	end
end)

function createRotator(player,cmd)
    if not isPedInVehicle(player) then
        local x,y,z = getElementPosition(player)
        table.insert(rotators,#rotators+1,{object = 3053,lx = x,ly = y,lz = z+0.1,lrx = 180,ly = 0,lz = 0})
    end
end
addCommandHandler("crotate",createRotator)

 

Link to comment

Run this server side

 

rotators = {}
    			setTimer(function()
				for i,v in pairs(rotators) do
    				local px,py,pz = getElementPosition(v)
    				local prx,pry,prz = getElementRotation(v)
    				moveObject(v,11000,px,py,pz,0,0,prz+180)
				end
    			end,10000,0)
	

    function createRotator(player,cmd)
        if not isPedInVehicle(player) then
            local x,y,z = getElementPosition(player)
            table.insert(rotators,createObject(3053,x,y,z+0.1,180,0,0))
        end
    end
    addCommandHandler("crotate",createRotator)

 

Edited by CodyL
Link to comment
    rotators = {}
	rotatorSet = createObject(3053,0,0,0,180,0,0)
	
        			setTimer(function()
					    local px,py,pz = getElementPosition(rotatorSet)
        				local prx,pry,prz = getElementRotation(rotatorSet)
						moveObject(rotatorSet,11000,px,py,pz,0,0,prz+180)
    				for i,v in pairs(rotators) do
        				moveObject(v,11000,px,py,pz,0,0,prz+180)
    				end
        			end,10000,0)
    	
        function createRotator(player,cmd)
            if not isPedInVehicle(player) then
                local x,y,z = getElementPosition(player)
                table.insert(rotators,createObject(3053,x,y,z+0.1,180,0,0))
            end
        end
        addCommandHandler("crotate",createRotator)

 

Link to comment

Here's what I got, event though it needs some editing. It works, Thank you Cody.

rotators = {}
rotatorSet = createObject(3053,0,0,-10,180,0,0)

function rotate()
	local px,py,pz = getElementPosition(rotatorSet)
	local prx,pry,prz = getElementRotation(rotatorSet)
	moveObject(rotatorSet,11000,px,py,pz,0,0,prz+180)
	for i,v in pairs(rotators) do
		local sx,sy,sz = getElementPosition(v.object)
		local prx,pry,prz = getElementRotation(rotatorSet)
		moveObject(v.object,11000,sx,sy,sz,0,0,prz+180)
		attachElements(v.vehicle,v.object,0,0,-1,180,0,0)
	end
end
setTimer(rotate,11000,0)

function createRotator(player,cmd,id)
	if not isPedInVehicle(player) then
		local x,y,z = getElementPosition(player)
		table.insert(rotators,{object = createObject(3053,x,y,z+0.1,180,0,0),vehicle = createVehicle(id,x,y,z+1)})
	end
end
addCommandHandler("crotate",createRotator)

 

Link to comment

Full Script, but not syncing.

rotators = {}
rotatorSet = createObject(13646,0,0,-10,0,0,0)

function rotate()
	local px,py,pz = getElementPosition(rotatorSet)
	local prx,pry,prz = getElementRotation(rotatorSet)
	moveObject(rotatorSet,20000,px,py,pz,0,0,prz+180)
	for i,v in pairs(rotators) do
		local sx,sy,sz = getElementPosition(v.object)
		local prx,pry,prz = getElementRotation(rotatorSet)
		moveObject(v.object,20000,sx,sy,sz,0,0,prz+180)
		attachElements(v.vehicle,v.object,0,0,1.5,0,0,0)
		setObjectScale(v.object,1.1)
	end
end
setTimer(rotate,20000,0)

function createRotator(player,cmd,id)
	if not isPedInVehicle(player) then
		local x,y,z = getElementPosition(player)
		table.insert(rotators,{object = createObject(13646,x,y,z-1.4,0,0,0),vehicle = createVehicle(id,x,y,z+2)})
		for i,v in pairs(rotators) do
			attachElements(v.vehicle,v.object,0,0,1.5,0,0,0)
			setObjectScale(v.object,1.1)
		end
		setElementPosition(player,x,y,z+1.2)
	end
end
addCommandHandler("crotate",createRotator)

 

Link to comment
    rotators = {}
    rotatorSet = createObject(13646,0,0,-10,0,0,0)

    function rotate()
    	local px,py,pz = getElementPosition(rotatorSet)
    	local prx,pry,prz = getElementRotation(rotatorSet)
		moveObject(rotatorSet,20000,px,py,pz,0,0,prz+180)
    	for i,v in pairs(rotators) do
    		local sx,sy,sz = getElementPosition(v.object)
    		moveObject(v.object,20000,sx,sy,sz,0,0,prz+180)
    		attachElements(v.vehicle,v.object,0,0,1.5,0,0,0)
    		setObjectScale(v.object,1.1)
    	end
    end
    setTimer(rotate,20000,0)

    function createRotator(player,cmd,id)
    	if not isPedInVehicle(player) then
    		local x,y,z = getElementPosition(player)
    		table.insert(rotators,{object = createObject(13646,x,y,z-1.4,0,0,0),vehicle = createVehicle(id,x,y,z+2)})
    		for i,v in pairs(rotators) do
    			attachElements(v.vehicle,v.object,0,0,1.5,0,0,0)
    			setObjectScale(v.object,1.1)
    		end
    		setElementPosition(player,x,y,z+1.2)
    	end
    end
    addCommandHandler("crotate",createRotator)

 

Link to comment

There is a very negligible difference in the computation speed of both the loops.

 

For example, if there were 100 elements in a table to be iterated, pairs was faster than ipairs by 3.41E-07 seconds that's 0.0000000341 seconds roughly. So, the speed doesn't really matter till you have many thousands of values. Also as @KariiiM said, it's good to use ipairs in the above example.

  • Like 1
Link to comment
  • 3 months later...
On ‎9‎/‎19‎/‎2016 at 9:26 AM, KariiiM said:

There is no big different in the loop speed

ipairs and pairs do the exact same thing. They loop through the table.

A loop has certain variables, example -
for index,plr in pairs(getElementsByType("player")) do
end

Index stands for index, this can be called anything, i, k, index, number, etc, the index is the number that is assigned to the item in the table. Like an id, similar to what you see on some servers with players on the scoreboard (TAB)

plr stands for the item in the table, this can be called anything, plr, player, p, stupid Variable. This will just be used to call the data from the table.

pairs is what goes through the table, this goes through all the data randomly. Only difference with ipairs is that ipairs sorts through the data evenly, it sorts the data in order..
so
ipairs does take a little longer. Otherwise these two do the exact same name.

getElementsByType("player") creates a table of ALL the elements in the server that are players. - that is a table, no doubt. Usually loops are only used in tables..

This is how tables and loops work, at least what I learned from it. Hope it helped you.

Edited by shay103
Link to comment

You can start questioning the use of ipairs when you're iterating 10,000,000+ table elements (at this point you probably wouldn't care about order anyway, and you should do it in a dedicated instance if you work something like this). We're talking about a couple ticks when it's in the low millions and less... so, in theory, yes, there is a difference, in practice: no one cares. With small tables, which people normally have, the difference is zero to two ticks (meaning your optimization does practically nothing).

Edited by myonlake
Link to comment
10 hours ago, myonlake said:

You can start questioning the use of ipairs when you're iterating 10,000,000+ table elements (at this point you probably wouldn't care about order anyway, and you should do it in a dedicated instance if you work something like this). We're talking about a couple ticks when it's in the low millions and less... so, in theory, yes, there is a difference, in practice: no one cares. With small tables, which people normally have, the difference is zero to two ticks (meaning your optimization does practically nothing).

Why order a list when you check exact variables to find the element? I understand the tick situation sometimes it will be a high check and sometimes it will be a low check, either way without ordering the list, the elements still show up in less than a second, which is all that is needed. Hardly causing server lag if not by a very small fraction.

Finding exact elements -

local checkVehs = {
	{model = 411,x = 0,y = 0,z = 0},
	{model = 372,x = 0,y = 0,z = 2}
}

for i,v in pairs(checkVehs) do
  if i = 1 then
    if v.model = 411 then
      	outputChatBox("Successfully found precise vehicle ("..getVehicleNameFromModel(v.model).."),root,255,255,255)
    end
  end
end

Finding elements through search -

local checkVehs = {
	{model = 411,x = 0,y = 0,z = 0},
	{model = 372,x = 0,y = 0,z = 2}
}

for i,v in pairs(checkVehs) do
  veh = createVehicle(v.model,v.x,v.y,v.z)
  setElementData(veh,"id",i)
end

for i,ve in pairs(getElementsByType("vehicle")) do
	if getElementData(ve,id) == 1 then
    		outputChatBox("Found the infernus!",root,255,255,255)
	end
end

There is quite a difference between these codes, but I'm saying it doesn't really matter what you use, ipairs or pairs, they both complete the job without hardly any memory requirement. I guess you could just say it isn't 'professional'. But oh well, the players cant see that right? Besides, there is no element in MTA that exists over 200 times (hardly any memory impact), unless you make a script spawn 30 thousand elements, you are hardly at all going to tell the difference.

Edited by shay103
Link to comment
5 hours ago, shay103 said:

Why order a list when you check exact variables to find the element? I understand the tick situation sometimes it will be a high check and sometimes it will be a low check, either way without ordering the list, the elements still show up in less than a second, which is all that is needed. Hardly causing server lag if not by a very small fraction.

Finding exact elements -


local checkVehs = {
	{model = 411,x = 0,y = 0,z = 0},
	{model = 372,x = 0,y = 0,z = 2}
}

for i,v in pairs(checkVehs) do
  if i = 1 then
    if v.model = 411 then
      	outputChatBox("Successfully found precise vehicle ("..getVehicleNameFromModel(v.model).."),root,255,255,255)
    end
  end
end

Finding elements through search -


local checkVehs = {
	{model = 411,x = 0,y = 0,z = 0},
	{model = 372,x = 0,y = 0,z = 2}
}

for i,v in pairs(checkVehs) do
  veh = createVehicle(v.model,v.x,v.y,v.z)
  setElementData(veh,"id",i)
end

for i,ve in pairs(getElementsByType("vehicle")) do
	if getElementData(ve,id) == 1 then
    		outputChatBox("Found the infernus!",root,255,255,255)
	end
end

There is quite a difference between these codes, but I'm saying it doesn't really matter what you use, ipairs or pairs, they both complete the job without hardly any memory requirement. I guess you could just say it isn't 'professional'. But oh well, the players cant see that right? Besides, there is no element in MTA that exists over 200 times (hardly any memory impact), unless you make a script spawn 30 thousand elements, you are hardly at all going to tell the difference.

Like I said, if you don't care about order, you probably don't care which you use. So pairs is a fine solution, if you're concerned of a couple ticks here and there.

But when you're iterating 10,000,000+ table elements, you're most likely not concerned about order anyway, so you'd always be defaulting to pairs in your code.

I've ran scripts with tens of thousands of vehicles and items, one pairs loop didn't make any noticeable difference in loading. The real deal is after 100,000,000+ table elements in which pairs loop does indeed improve loading time somewhat noticeably, and I tested this as well.

What I'm trying to say here is I doubt no one in this forum has any active server with 100,000,000 table elements for any dynamic loading situations; meaning, no one should use pairs over ipairs only because "it's faster in some situations". I quite often like to have order because it affects things client-side or the map or so.

There is no noticeable difference in time with the table sizes we here have to deal with.

P.S. If you didn't know, iterating with just the table size for i=1,size... is almost twice as fast than pairs or ipairs... so, if you were to over-optimize your scripts, there's your solution.

Edited by myonlake
Link to comment

In this case it really doesn't matter what is used. i=1,#table can indeed be faster; but really there's no real point in changing it at all. it's just the way I learned that ipairs is slower then pairs, might be by a non noticeable difference in small amounts for sure but over time it adds up ; which will get it out of sync over a large amount of time (1+ months)  (Certainly makes a difference when loading and unloading large amounts of objects.) (Which I assume these will be operating all of the time) there's no real reason this'd effect anything sure; but it might over a long long period of time.

I guess if you wanted to get fancy with it you could just do this

        rotators = {}

        function rotate()
        	for i,#rotators do
				local v = rotators[i]
        			local sx,sy,sz = getElementPosition(v.object)
        				moveObject(v.object,20000,sx,sy,sz,0,0,prz+180)
        			attachElements(v.vehicle,v.object,0,0,1.5,0,0,0)
        		setObjectScale(v.object,1.1)
        	end
        end
        setTimer(rotate,20000,0)

        function createRotator(player,cmd,id)
        	if not isPedInVehicle(player) then
        			local x,y,z = getElementPosition(player)
        				table.insert(rotators,{object = createObject(13646,x,y,z-1.4,0,0,0),vehicle = createVehicle(id,x,y,z+2)})
				for i,#rotators do
						local v = rotators[i]
							attachElements(v.vehicle,v.object,0,0,1.5,0,0,0)
        			setObjectScale(v.object,1.1)
        		end
        			setElementPosition(player,x,y,z+1.2)
        	end
        end
        addCommandHandler("crotate",createRotator)

 

Edited by CodyL
Link to comment

Lua developers had created "ipairs" and "pairs" loops for their purpose, each loop has its role and its own usage;

"ipairs": looping indexed tables and in order.

"pairs":  looping  the tables who were created with a key-value and pairs donnot return the table's items in order even for indexed tables.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...