If i look at the for-do loop i notice it is 1, 1000
Guessing this loops through all entities, the first 1000 in this case..
Wouldn't it be better to change this 1000, which could be a problem if you have more than a 1000 entities in your game, to g_EntityElementMax ?
That way the script always looks at all your entities, no matter how many you use.



would become

Or simply 'for ee,_ in pairs(g_Entity) do' far more efficient.

Why do I try to understand these issues and I can not ??? Ha ha ha ... I better open the Fragmotion ... Greetings!

I do not know enough of lua to know if your statement is true. Sure, there are better ways to solve this.
But i only wanted to point out the 1 to 1000 is going to give people headaches if they have more than a 1000 entities.
Thats why i opted for the g_EntityElementMax.
I use the same command for my radar script.

Yet.. this only works if my presumption (Entity IDs) is correct.

@ Anubis
You are right it would be better.
In fact you should loop around :

for ee = 1, g_EntityElementMax-1 do

3com

My first thought.. wouldn't that leave out the very last entity?

g_EntityElementMax count player as entity, so if you've 3 barrels and the player, it count 4 entities, including player.

So if you do:

for ee = 1, g_EntityElementMax do
kill_everybody_here
end

most likely you don't want to kill the player as well.

If you placed player firts in your map, so you always know he is the "entity" number 1, so you can start looping from 2 instead of 1,
for ee = 2, g_EntityElementMax do, or Lee changing this behaviour (non including player in g_EntityElementMax ).

3com

Just filter out the player (in 3rd person, there is no player entity in FP) entity.

i.e.
for ee,_ in pairs (g_Entity) do
if ee ~= player_id then
... etc ...
end
end

Attach a script to the player character and have it save the player id, e.g:

if player_id == nil then player_id = e end

Lua lists are stored as linked lists in memory, the generic for mechanism simply walks the linked list returning the keys for each entry in the list (in the simplest usage in the example I gave), this is the most efficient way of iterating a list, by design, according to Roberto himself.

Accessing lists as if they are arrays, especially global lists, is the slowest way to do it.

That is a good point, did not think about it.
Then again, i never put my player marker on the map first.
But with your explanation in my mind.. it might be could practice to do so.

The _Pairs solution of Amenmoses is still alien to me.. i have to read up on that.

Just hope Lee reads this and applies a good solution to the script.

Thanks for elevating my knowledge

It's just pairs and it's Roberto's solution not mine.

The 'k' variable is the key of the list, the '_' just means ignore the value as we are just interested in the key. If you put a variable in there as well then you would get the value of each entry as well as the key, e.g.: ' for key,val in pairs(<list> do' or even 'for _, val in pairs(<list> do' which would give just the values.

Note that the 'value' from a list can be another list or a function, it's very easy to encapsulate the data and functions (or methods if you prefer) together in a list to create objects, metatables can then be used to implement inheritance, privacy and any other oop like features if you feel the need.

The second half of the book (the 5.3 version as he has restructured it from 5.2) is a bit scary at first glance but there is a lot of really clever stuff in there that is worth reading up on even if you never actually use it.

I do not believe Game Guru has gone to the 5.3 version of LUA.

Last I knew we were at 5.2.

I know, the differences are minimal though. The new book otoh is much better, it has been re-arranged so it flows in a more logical manner, all the really weird stuff has been put into the last half so it is less scary for the beginner.

Lua 5.3 has some really cool new things but none of them are really that important for GG, mainly they are additions to make life easier for interfacing with 64 bit engines, especially for things like low level GPU related stuff.

Funnily enough I keep telling people that the only number 'type' in Lua is double precision floating point (i.e. 64 bit FP) and for 5.0-5.2 that is perfectly true, 5.3 otoh now has 64 integers as well, so you can directly set GPR register values and the like. For general scripting though the programmer doesn't have to do anything special, Lua 5.3 will determine the best type to use depending on the values you use.

Very nice. Glad you understand it. Ask me about modelling and animation. lol.