_GV and __jarray ?

[Troll-Brain]

I was looking for available lua API and found _GV as custom user data, and __jarray as a function.
Probably nothing important, but just in case i'm asking if someone has a clue of what's their purpose and eventually if we can use them ?
I realize it's probably used internally by wc3.

        for k,v in pairs(__ENV) do

            local s = SubStringBJ(k,1,1)
            if StringCase(s,false) == s and SubStringBJ(k,1,2) ~= "bj" then
                print(k,type(k),v)
            end

        end

 

[TriggerHappy]

jarray is meant to return a default value where Lua tables would normally return nil.



I'm not sure what GV is.

 

[MyPad]

jarray is meant to return a default value where Lua tables would normally return nil.

View attachment 362575

I'm not sure what GV is.

Is that extracted from the game itself? I would like to know more about this. (Sorry for hijacking the thread, Troll-Brain)

 

[TriggerHappy]

Is that extracted from the game itself? I would like to know more about this. (Sorry for hijacking the thread, Troll-Brain)

Yes. The game executable has an embedded file titled luahelper.lua and the screenshot shows the contents of that file.

 

[pr114]

Interesting, so it looks like they overwritten math.random to redirect to the GetRandomInt native.

 

[Troll-Brain]

Well, it makes sense, as it's better to be same value for everyone heh.
No need to reinvent the wheel for a random function

 

[Drake53]

Well, it makes sense, as it's better to be same value for everyone heh.
No need to reinvent the wheel for a random function

Isn't reinventing the wheel exactly what they're doing by overriding lua's random functions with their own?

 

[Troll-Brain]

Isn't reinventing the wheel exactly what they're doing by overriding lua's random functions with their own?

I'm ok to bitch about reforged any time when it's appropriated, but there really it's not needed.
What do you prefer, native random lua overwritten or not having the same result on each computer ?

They should overwrite lua even more, like making pairs iteration the same for everyone (if it's possible in a decent way), or anything which is async but should be synced from wc3 point of view.

So yeah technically they didn't really needed to overwrite math.random but why not, it's just less error prone and i don't see what features are lost there.
But if there are a few revelant ones, tell me please, more knowledge is always cool, i don't pretend to know everything and always willing to learn

 

[Drake53]

I'm ok to bitch about reforged any time when it's appropriated, but there really it's not needed.

Lua was added in 1.31, and I love the addition of lua, so explain how this is related to reforged and how I'm supposedly bitching.

What do you prefer, native random lua overwritten or not having the same result on each computer ?

How about neither?? Lua has the function math.randomseed, so making sure that random numbers are in sync using lua's built-in random library should not be a problem.

 

[Troll-Brain]

I edited my previous post, as the tone was not what i had in mind.
I didn't mean to be offensive.
I'm just saying reforged is a fail (hence the bitching), and we are talking about a radom function (was also a joke with "random function" expression), so it's a bit too much for arguing about that for me, regardless it was a good or bad choice, it's kinda irrevelant at the end (unless like i said on my edit i miss something).

Yes it's a quick and dirty fix to make it synced but why not ?

 

[Drake53]

They should overwrite lua even more, like making pairs iteration the same for everyone (if it's possible in a decent way), or anything which is async but should be synced from wc3 point of view.

I disagree, overwriting lua functions is easy, but undoing that and get the original function back is impossible, so it should be up to the mapmaker to decide if they want to overwrite certain functions or not.

So yeah technically they didn't really needed to overwrite math.random but why not

They shouldn't have because it's slower. I have benchmarked lua's math functions against wc3's and they're all about 50% (don't quote me on that btw, I did this months ago and don't have the exact times in front of me right now) faster in lua. Of course I can't benchmark lua's random library because it was overridden, but I'm assuming it'd be faster too.
A better solution for making sure lua's math library is synced would be to set the lua random seed using warcraft's own randomizer, before loading the map script into the lua state.

it's just less error prone and i don't see what features are lost there.

I see you never tried to get a random number between -2147483648 and 2147483647. Using GetRandomInt it will always return -2147483648. Seems like an error to me. Of course I don't know if lua's random library also suffers from this because, again, it was overridden.

 

[Troll-Brain]

Well, i didn't speak about efficiency simply because i didn't have in mind a case where it would matter for getting a random number.

And yeah i didn't used full range of integer but more used like percent, not sure that in wc3 contest more is needed, but again i didn't use GetRandomInt intensively.
Maybe you had that need.

I prefer safety rather than a not so obvious "random" behavior (i mean just looking the code you have to think about how functions work), especially when the native lua behavior brings nothing in wc3 contest, like normal pairs behavior.
I don't see any benefit of iterations not being synced (well i supppose that in lua the iteration is not determined, so it can be fast)

 

[Drake53]

Well, i didn't speak about efficiency simply because i didn't have in mind a case where it would matter for getting a random number.

For most use-cases it's true efficiency is probably not important. But for some it can be, like random level generators.

And yeah i didn't used full range of integer but more used like percent, not sure that in wc3 contest more is needed, but again i didn't use GetRandomInt intensively.
Maybe you had that need.

I admit my example is an edge case that the average user is unlikely to ever run into, but I don't think I ever saw this behaviour documented before so might as well mention it.

I prefer safety rather than a not so obvious "random" behavior (i mean just looking the code you have to think about how functions work)

I don't understand why you think wc3's implementation is 'safer' than lua's.

 

[Troll-Brain]

For most use-cases it's true efficiency is probably not important. But for some it can be, like random level generators.

Ok, fair enough

I admit my example is an edge case that the average user is unlikely to ever run into, but I don't think I ever saw this behaviour documented before so might as well mention it.

Always good to mention any bug/unexpected behavior.

I don't understand why you think wc3's implementation is 'safer' than lua's.

No, i just mean GetRandomInt function (written in C probably) was obviously built to be synced, same result on each computer.
So yeah they could have done better, like you mentionned, like i said it was just a quick and dirty fix from them, but as said, on other hand, in most if not all cases it doesn't really matter.
At least doing that, they are not bringing new bugs, as the function has been well tested earlier.

What i mean is that we are not running a lua script locally on an unique computer.
In wc3 contest we have to think about data being synced and behaviors determined instead of not determined (like pairs iteration), that doesn't mean we can't run local code at all.
And yes i know there are workarounds, like using several tables , sort, ipairs instead of one table and pairs to have a determined iteration.
But more abstraction about that is cool for me (from game engine behavior), if that doesn't involve a notable efficiency loss.


Well, not sure i'm clear enough lol, i know what i'm trying to say but not sure i'm saying it correctly

 

[Drake53]

No, i just mean GetRandomInt function (written in C probably) was obviously built to be synced, same result on each computer.

Every random library where the user can set the seed is 'synced'. Look at lua's documentation for math.randomseed:

Sets x as the "seed" for the pseudo-random generator: equal seeds produce equal sequences of numbers.

Notice it says 'sequences' of numbers. So if you set the seed and then get a random number, that number will always be the same. Then if you then get another random number it will still be the same.
So the only thing that needs to be synced is the initial seed. For wc3's randomizer this happens automatically, for lua it could also happen automatically if the devs added one line of code.
When the initial seed is synced, it doesn't matter if you use wc3's or lua's random library, it will remain synced (of course it can desync if you use the randomizer inappropriately, like when you use it in combination with GetLocalPlayer, but this is true for both wc3 and lua randomizers).

 

[Troll-Brain]

Ok, then i suppose they just didn't want two different random functions, which is error prone by itself.
I'm personnaly ok with that but i got your points

It was a cool convo but i'm done with it, and ty for the extra knowledge

 

[Prometheus3375]

Yes. The game executable has an embedded file titled luahelper.lua and the screenshot shows the contents of that file.

Is it possible to publish this file somewhere?

 

[Luashine]

@Prometheus3375 I've shown in "Reforged's luahelper.lua and broken FourCC" how to extract luahelper.lua yourself.

__jarray is used by transpiled Jass code, since this is where this function call appears a second time (as part of the transpiler).
I'm not sure about _GV, but due to its proximity to all the Jass API functions (memory layout and pointers), it is probably itself a pointer to a Jass structure. lightuserdata/userdata is how you would present a pointer to Lua from the C API. This is my best guess.

 

[Bribe]

Note for future readers:

_GV is actually the same object as "globals". No surprises, unfortunately:

print(globals, _GV, globals == _GV)

Prints: