Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sol::this_environment has no value (nullopt) when accessing from a metamethod #1464

Open
ensisoft opened this issue Mar 9, 2023 · 0 comments

Comments

@ensisoft
Copy link

ensisoft commented Mar 9, 2023

Hello,

I have the following code

#include <string>
#include <cstdio>

#define SOL_ALL_SAFETIES_ON 1
#include <sol/sol.hpp>

struct MyEntity {};

std::string GetSomething(MyEntity& entity, const char* key, sol::this_state this_state, sol::this_environment this_env)
{
    std::printf("GetSomething, key='%s', has environment = %s\n", key, this_env ? "yes" : "no");

    return "dummy";
}

void environment_variable_test_entity()
{
    sol::state L;
    L.open_libraries();

    auto entity = L.new_usertype<MyEntity>("MyEntity",
      sol::meta_function::index, &GetSomething);

    sol::environment env(L, sol::create, L.globals());

    L.script(R"(
function Tick(entity)
   --print(entity.test_value)
   --print('hello')
   local var = entity.test_value
end
    )", env);

    MyEntity e;

    env["Tick"](&e);

}

int main(int argc, char* argv[])
{
    environment_variable_test_entity();

    return 0;
}

sol::this_environment doesn't have a value, i.e. the underlying std::optional is nullopt. However , the problem goes away
when either one of the prints is enabled in the Tick function !

It seems that the prints cause some side effect that sets the this_environment ?

Tested with Sol 3.3.0 (which reports 3.2.0 in sol.hpp) and with GCC 12.2.1.

Thanks!

ensisoft added a commit to ensisoft/detonator that referenced this issue Mar 9, 2023
Add a scripting variable private flag for limiting access scope to
only to the Lua script that is associated with the entity/scene.
The goal is to ensure smaller scope for variable access and help
reduce possible game code spaghetti.

Currently, there seems to be a Lua/sol2 bug related to the Lua
environment  so this means that the access check cannot always be
performed. ThePhD/sol2#1464
ensisoft added a commit to ensisoft/detonator that referenced this issue Mar 20, 2023
Add a scripting variable private flag for limiting access scope to
only to the Lua script that is associated with the entity/scene.
The goal is to ensure smaller scope for variable access and help
reduce possible game code spaghetti.

Currently, there seems to be a Lua/sol2 bug related to the Lua
environment  so this means that the access check cannot always be
performed. ThePhD/sol2#1464
ensisoft added a commit to ensisoft/detonator that referenced this issue Mar 20, 2023
Add a scripting variable private flag for limiting access scope to
only to the Lua script that is associated with the entity/scene.
The goal is to ensure smaller scope for variable access and help
reduce possible game code spaghetti.

Currently, there seems to be a Lua/sol2 bug related to the Lua
environment  so this means that the access check cannot always be
performed. ThePhD/sol2#1464
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant