Quick fix for the "commands break over time" problem

[Megiddo]

Yes we finally tracked down the problem and came up with a fix!

Add this code to a new file (any file name you want as long as it has .lua as the extension) in the autorun folder.

Code: Lua

1. _ = nil -- Make sure we're starting out right.
2. local old__newindex = _G.__newindex
3. setmetatable( _G, _G )
4. function _G.__newindex( t, k, v )
5.         if k == "_" then
6.                 -- If you care enough to fix bad scripts uncomment this following line.
7.                 -- error( "attempt to modify global variable '_'", 2 )
8.                 return
9.         end
10.  
11.         if old__newindex then
12.                 old__newindex( t, k, v )
13.         else
14.                 rawset( t, k, v )
15.         end
16. end

This code will be included in future versions of ULib.

Need detailed instructions on how to do this? See here.

[Dripfed]

Ok, in the interests of my learning...

What is this actually doing? Or what is it preventing from happening?

[Megiddo]

It's making sure the variable '_' stays nil, as it should.

[JamminR]

A little deeper, without getting overly technical;
We're 99% sure that another script not controlled by Ulysses Team, we're still not sure which, was setting _ as a global variable.

That would be fine and dandy, but, many programmers, including us, use _ as a local variable, usually in a for loop or function.

Whichever script was setting _ as a global was then causing havok on ULX.

This tiny bit of code, in simplest terms, sets the global _ as nil permanently.

It will still be able to be used as a local if needed.

[Dripfed]

Thanks for that

[spbogie]

Actually, the problem is not lying when we use it in a for loop, but in the way it is repeatedly used in place of nil in many function calls.

Megiddo,
Although this method works, it will break whichever script(s) is/are setting _ to a value. Although this/these script(s) shouldn't be using _ I think it would better fit our goal to find less intrusive method. I believe simply defining _ as a local variable set to nil at the top of each script should do. This would also be less hacky (not setting the global table as a metatable for itself).

[Megiddo]

I'm fairly sure that whoever is assigning a value to _ is doing it on accident, for example, if you do _, var = string.find() it will assign a value to _ instead of leaving it nil. Doing it this way ensures that other scripts remain working as well.

[Mank]

A little deeper, without getting overly technical;
We're 99% sure that another script not controlled by Ulysses Team, we're still not sure which, was setting _ as a global variable.

That would be fine and dandy, but, many programmers, including us, use _ as a local variable, usually in a for loop or function.

Whichever script was setting _ as a global was then causing havok on ULX.

This tiny bit of code, in simplest terms, sets the global _ as nil permanently.

It will still be able to be used as a local if needed.

Since when were variables inside of for loops local?

(If I'm wrong it's because I only use C++ =P)

[spbogie]

Code: [Select]

for _, ply in pairs(player.GetAll()) do In this case Lua makes _ and ply local variables.

As I stated before however this is not where our problem is steming. It comes when we assume _ is nil without it having been defined localy. This workaround ensures that global _ always remains nil.

[Mank]

Code: [Select]

for _, ply in pairs(player.GetAll()) do In this case Lua makes _ and ply local variables.

As I stated before however this is not where our problem is steming. It comes when we assume _ is nil without it having been defined localy. This workaround ensures that global _ always remains nil.

Ah, I see =)

[EscudoDenali]

Ok, I probably sound like an idiot, but how exactly do i make LUA files? I tried copyinganother LUA file and copy pasting the code, but then it doesnt look the same... It just looks like text.  Not all the tabs and cool stuff that other LUA files have.  If someone could help me out, that would be greatly appreciated!

[spbogie]

Indentation will have no effect on how the script runs. As long as all the lines remained the same you should be fine.

[McGarnagle]

FYI, the news page screws up the code to look like it says =:Code> or something at the top of this tidbit...

I read the comments when i got an error (since im not an LUA guy) and noticed in the thread view the Code block shows up properly.

Just in case anybody is confused, the script starts with the line "_ = nil -- Make sure we're starting out right."

[Megiddo]

Thanks for pointing this out! I was messing with some forum settings earlier today and didn't even think to make sure it didn't effect the front page. Fixed!