Each time the numeric argument to luasettable is -3 because luasettable pops the two stack items above it after incorporating them in its table, so at its end it's at the same level that it was before you stacked the key and value.

Lua Get Key Value From Table In C Programming
Lua Get Key Value From Table In Creo
Lua Table Get Value By Key

Value = Gvarname Because the environment is a regular table, you can simply index it with the desired key (the variable name). In a similar way, you can assign to a global variable whose name is computed dynamically, writing Gvarname = value. Re: Getting values in C from a Lua table, Jose Marin; References: Getting values in C from a Lua table, Jose Marin; Prev by Date: Re: Finding and loading Lua files; Next by Date: Re: Finding and loading Lua files; Previous by thread: Getting values in C from a Lua table; Next by thread: Re: Getting values in C from a Lua table; Index(es.

The problem of handling references to game objects (I’ll call them entities) comes up very often. Sometimes it’s child-parent relationship between the entities, sometimes it’s useful to store a reference to an object in event data, some task scheduling class and so on.

Sometimes a simple pointer, reference or std::reference_wrapper is enough. But the problem with raw pointers and references is that once you use them, you have to make sure that the entity which is being referenced stays alive and is not moved in memory without notifying objects which hold references. And with good design you’ll probably be able to achieve that.

But stale pointers/references give some of the worst bugs, which are difficult to track, crash your game and may not be easily identifiable. Some entities may start to occupy different addresses in memory (for example, after you reload a level and decide to create all entities from scratch). While it’s possible to manually update all pointers to previously referenced entities, it’s certainly will be better to do so automatically and without a chance of forgetting some pointers which will be stale.

Let’s see all these problems can be solved. The latest solution (about storing references to Lua) was discovered by me not long ago and it is the point of me writing the article, but I want to show some other ways of solving the problem. Let’s start!

Some of the problems with raw references can be solved with std::shared_ptr and std::weak_ptr. First, you create your entities as with std::make_shared. After that you’ll create all references to it with std::weak_ptrs which won’t affect your entity’s lifetime. After that you can use std::weak_ptr<T>::expired function to check if the reference is still valid.

The solution is not perfect. First of all, it requires you to create all your entities as shared_ptrs which may have some significant overhead compared to unique_ptrs. And after all, it’s better for the lifetime of entities not to be shared and that semantic is better expressed with unique_ptr. Shared pointers also don’t solve the problem of moving entities in memory: you can’t swap what’s inside the shared_ptr and have all weak_ptrs automatically update their pointers.

One solution to the problem is just creating unique ids for entities and storing those ids instead of raw pointers or references. There a lots of ways to generate and represent entity ids. Ids can just be integers with EntityManager having a counter which will be incremented as new entities are created: the first entity will get id=0, the second one id=1 and so on. Another way to generate ids is to use some hashing algorithm or UUIDs. No matter what, your ids should stay unique, unless you add some additional info (like entity creation time or some tags) to your id.

Here’s how your EntityManager class may look:

Using ids also helps with recreation problem: you can easily reload/recreate the entity and just assign the same id to it as before. It will have a different adress in memory, but the next time someone calls getEntity the updated entity is returned. You can also easily send these ids over the network or save them in your save files.

Your code when using entity id becomes something like this:

Of course this creates some overhead because you now have a layer of indirection: you have to search unordered_map inside the EntityManager to get the raw reference to the entity, but if you don’t do it too often (and you most likely won’t), you’ll be fine!

There’s another improvement which can be done: you can wrap your id inside the struct and then overload operator-> for handle to act like a raw pointer:

Now you can do things like this:

Notice that we also get some error checking with assert which checks validity of the reference.Great! Now let’s see how we can reference entities in Lua scripts.

Full implementation can be found here: C++ part, Lua part.

First of all, it’s obvious that you can use the same approach in Lua. Your handle can just be a number or a table with __index meta-method so that you can use your handle as if it was the raw reference. But there’s a neater method I recently came up with. Let’s see how it works.

First of all, our handles will be tables with raw C++ references stored in them as userdata. They’ll also have a bool named isValid which will help us test if the handle is still valid. We’ll also have a global table of references in Lua, so that you can easily get handle from any place without calling C++. What’s neat is that you’ll get references to your handles, not a copy. It’s great, because you can easily compare two handles or even use them as table keys. You also don’t waste your memory, but that’s not a big concern as our handles are very light.

If you want to remove and recreate some entity, you’ll just have to notify the main Lua handle which will be stored inside some global Lua table. And because all your handles in Lua will be references to original handle you won’t have to care about them: once you update the main handle, it’s updated everywhere.

Another good thing is that once the entity is removed, we can just set isValid to false and raw reference to nil just to be extra safe.

Let’s get to implementation! We’ll use sol2 as our Lua/C++ binding library. Let’s write a simple Entity and EntityManager classes for testing:

Here’s how we will create our handle in Lua:

The Handles global table stores all handles so that we can easily get them later. As you can see, we still use integer ids for it as a tables key so that when we remove an entity, we can easily find its handle and modify it appropriately.

The metatable has an important function: it will let us use the handle as if it was the original reference. Here’s how it’s written:

Just a quick reminder: metatable’s __index function gets called when the key in the table is not found and the table (our handle) and missing key are passed.

Lua Get Key Value From Table In C Programming

Here’s an example of how it all works. When we do this:

Lua checks if handle table has “setName” key, but it doesn’t, so it calls metatable’s __index function with handle and “John” as parameters. The wrapper around Entity’s member function is returned and it gets called. The function which gets returned is a closure which calls the Entity’s class member function on original raw reference. Why can’t we just return Entity[key]? The problem with that is that our handle will get passed into it while the function expects raw reference to be passed (cppRef:setName('John') is the same as calling Entity.setName(cppRef, 'John')).

The error checking that we have here is extremely important and useful! It allows us to easily debug problems with our code: we even print the call stack to find the place where our code crashed!

Notice that we pass '2' as the second argument in `error` function. It tells it that the problem is not the function which called it, the bad one was below it in a call stack.

Another great thing about this implementation is that it l