DiSaMe

There's not even an object with model 160. That's an ID of the ped model.

1.3 was released to solve problems with network, so that shouldn't be surprising. The only time I was surprised was release of 1.0. Because of problems with peds, it looked unfinished to me.

You need to add the resource to an ACL group which has the right to use addAccount. https://wiki.multitheftauto.com/wiki/ACL

I once had done this by getting position of the turret using getElementMatrix on the vehicle and some calculations with offsets and making my own particles system. Technically those particles were just some data in a table. If the player held the key, the particles were created (position and velocity data was put into table). The data was repeatedly processed in short intervals (position changed because of velocity, velocity changed because of gravity). Distance from particles to fire objects was measured and if it was short enough, fire could be extinguished. Also, to make these particles repeat the trajectory of the water perfectly, I used getScreenFromWorldPosition with dxDrawRectangle to see where they go, so that I could know how to alter some constants (gravity, particle starting velocity).

Could that be related to the fact that setCameraMatrix only has 9 parameters, but you're using 11?

It's also possible to do this by generating a TXD file using file functions and applying it to the model, like in video, but that may be inefficient, though the script in the video could be optimized a lot.

Objects aren't colshapes, that must be obvious. To detect player-object collisions, it's better to try something with isLineOfSightClear or processLineOfSight.

There's a way to workaround this. First, make all weapons invisible by replacing DFFs or TXDs with empty/transparent ones. Then replace some unnecessary object models and textures with original weapon models and textures from the game. And finally, you need to create objects with these models and attach them to player's hands, so they will look like regular weapons, but they will be MTA elements and you will be able to control their visibility. To attach objects to player hands, you can either use getPedBonePosition and some calculations to get rotations of bones or include this resource, where the job has been done for you, and use its functions.

You can also keep checking player's dimension in some timer function and trigger the event when it changes. An example: old_dimension = {} --make an array to store previous dimensions of players addEvent("onPlayerDimensionChange", true) function checkDimensions() local this_dimension = {} --current dimensions of players local players = getElementsByType("player") for _, player in ipairs(players) do --cycle through all players this_dimension[player] = getElementDimension(player) if this_dimension[player] ~= old_dimension[player] then --if dimension is different than it was triggerEvent("onPlayerDimensionChange", player, old_dimension[player], this_dimension[player]) end end old_dimension = this_dimension --store this_dimension for the next check end setTimer(checkDimensions, 1000, 0) And then you can do: function showDimensionChange(olddim, newdim) outputChatBox(getPlayerName(source).." went from dimension "..olddim.." to dimension "..newdim..".") end addEventHandler("onPlayerDimensionChange", root, showDimensionChange) Not tested, but it should work. You can make put this code into a new resource. However, you will need to improve it because I only showed you how it should work. For example, if the player who just joined is checked, old_dimension[player] will be nil, therefore different than current dimension, so the event will be triggered. Also, the event isn't triggered instantly, but when dimensions are checked.

I guess you also forgot "make sure your computer is running", as event won't be triggered if computer is turned off...

This seems like a bug. Description of function guiScrollBarGetScrollPosition says it returns a float between 0 and 100. However, it actually returns an integer. I have this code: function createScroll() local scrollbar = guiCreateScrollBar (0.95,0,0.05,1,false,true) guiSetProperty(scrollbar,"StepSize",0.1/19.5) addEventHandler("onClientGUIScroll",scrollbar,onScroll) showCursor(true) end function onScroll() outputChatBox(tostring(guiScrollBarGetScrollPosition(source))) end createScroll() When I'm clicking the lower arrow of the scrollbar, it outputs these numbers: 0,1,1,2,2,3,3,4,4... Numbers in the sequence are increasing, what means the scroll position stored in MTA is a floating point value. But the function returns an integer, so I can't get an accurate position. Can I do something to get a float or at least a more accurate integer (for example, a value between 0 and 1000)?

That wasn't "wrong", you probably changed the way the event is triggered.

You can also try disabling object collisions, creating another object which has a similar shape and cannot be destroyed, and making it invisible (put it into another interior or use setElementAlpha). If I remember correctly, objects with disabled collisions cannot be destroyed even with explosions.

createObject works fine. It creates the object instantly. It only takes time for the object to be streamed in. So you may want to try respawning object only when isElementStreamedIn returns true.

I'm sorry if I sound dumb, but how to do this? With shaders?

Bugged how? Everything is fine here. I used to play single player with Driver mod, it added NRG near the safehouse in El Corona and that NRG was exactly the same. It's simple, if you don't like one variation, choose another.

What "symptoms"? It's not a "symptom", it's GTA feature. I see nothing wrong with it.

setVehicleVariant

If you make a global variable/function in one script, it will be available in another script of the same resource on the same side. Are you sure that code in a.lua was executed after b.lua, not before it? No, it's not nil. If it was nil, then getRootElement() would be wrong too because nil value can't be called. getRootElement is a function value.

Find it using MEd?

Oh, i mean, print(main("1")) will print false if we use your "main" function. megaman54 didn't ask for a way to check if an argument exists (in addition, checking the type is useless, just compare the variable to nil). He asked for a way to determine whether the player typed in a number. FatalTerror showed how to do this correctly. Your example is wrong because it doesn't check whether the string contains any numbers.

Wrong. print(type("1")) will return false. Command arguments are always strings, so no matter what player writes, it will give the same results.

It's not about spawning, it's related to streaming in or setting the syncer, as this problem (also preventing the ped from being given the weapon or getting warped into vehicle) also occurs when setPedAnimation/giveWeapon/warpPedIntoVehicle are used on ped which isn't near any player.

There's hardly any way to prevent them from doing what they are doing now. As I said, we need to exploit limitations of SA-MP instead of making changes which will only work until someone makes a program to read another MTA map format.

handbrake + left/right