Controlled Posted August 1, 2014 Share Posted August 1, 2014 I saw this tip on this page on the wiki today: If your script is covered in isTimer and isElement checks to hide debug warnings from deleted elements not being dereferenced (making the variable nil) you will regret it when that element ID or timer pointer has to be re-used by MTA in a weeks time and your script starts acting strangely and you won't have a clue why. Dereference destroyed elements and disconnected players! https://wiki.multitheftauto.com/wiki/Scripting_Tips I'm just confused by what it means when it says the element has to be re-used by MTA in a a weeks time.. I'm not sure what it means to be 100% honest. Can anyone explain to mean what that means? I would appreciate it. Thanks! Link to comment
Arran Posted August 1, 2014 Share Posted August 1, 2014 I've wrote some more explanation, so much so that I had to make a whole section just for it: "Element IDs Being Reused" Link to comment
DiSaMe Posted August 1, 2014 Share Posted August 1, 2014 Is that similar to dangling pointers in C, where allocated memory is coincidentally put where some invalid pointer has already been pointing? I've thought of such problem occuring in MTA but since I clean up my tables, I never faced it. However, if element can be created with the value that's already assigned to a variable, that's design flaw. I'm making a program that's also scriptable in Lua and I avoid the problem by using full userdata wrappers. When C creates an object, it also creates a full userdata in Lua. This userdata holds the pointer to object, so it's a wrapper. Lua scripts can only see the wrapper. When object is destroyed, the pointer contained in the wrapper is set to NULL, so the program knows the value is not a valid object anymore. However, since that wrapper is full userdata whose lifetime is managed by Lua, new wrappers cannot be allocated at the same position in memory. As a result, no new wrapper will ever get the same position until every single variable holding the previous wrapper is assigned something else and the previous wrapper is garbage collected. Which means the scripts that don't clean up the tables will eventually make the program run out of memory instead of silently producing incorrect results. Link to comment
DiSaMe Posted August 1, 2014 Share Posted August 1, 2014 I just did some testing and got 131042 unique element values. Further creating elements resulted in already used value being reused. In contrast, doing the same on my program resulted in 6360000 unique values before I stopped it (because it was eating memory really fast ). Therefore I think the way MTA handles elements is not really good. While the scripts should take care of cleanup anyway, reuse of element values that are already used by variables allows the problems to go unnoticed, and unique values can be guaranteed by using full userdata wrappers. Link to comment
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now