lua: Add ways to automatically run lua on startup #3041
Conversation
DolceTriade
commented
Jun 20, 2024
DolceTriade
commented
- g_luaScript to run at startup
- luaScript spawn flag
Scripts can be in a dpk or in <homepath>/game. Files in <homepath>/game are preferred and then fallback to files in dpks. The same logic applies to imports for Lua.
The semantics are the same as g_luaScript, which might be problematic because theoretically the script the mapper loads can clash with a script that the user has, but that is unlikely. The mappers should namespace their scripts in a location like maps/<mapname>/lua/<file>.
| // Initialize Lua | ||
| Lua::Initialize(); | ||
|
|
||
| if ( !g_luaScript.Get().empty() ) |
There was a problem hiding this comment.
To make this more useful and less redundant with simply putting a Lua command in a map config, how about delaying the command until the first non-fake frame? There's the server startup code
// run a few frames to allow everything to settle
for ( i = 0; i < GAME_INIT_FRAMES; i++ )
{
gvm.GameRunFrame( sv.time );
svs.time += FRAMETIME;
sv.time += FRAMETIME;
}
During the first frames some entities are still popping into existence and the floating buildings from Radiant-created layouts have to fall to the ground. It could be nice for the script to wait so that entities will all exist and be in the right place.
There was a problem hiding this comment.
I have been using the timer to run code on the next frame.
Timer.add(1, function() print('next frame') end)
There was a problem hiding this comment.
I didn't mean anything about rerunning the script every frame. I'm saying it may be better not to run the script in the very first frame because the level isn't truly done loading at that point. For example buildables may not exist yet. So it might mess up a script that does something with buildables.
| G_SpawnStringIntoCVar( "BPBudgetPerMiner", g_buildPointBudgetPerMiner ); | ||
| G_SpawnStringIntoCVar( "BPRecoveryRateHalfLife", g_buildPointRecoveryRateHalfLife ); | ||
|
|
||
| G_SpawnString( "luaScript", "", &s ); |
There was a problem hiding this comment.
I think it's premature to add support for Lua embedded in BSPs... people seem to have an expectation that backward compatibility will be maintained forever for every map. It would suck if we immediately get locked in to any API design flaws
There was a problem hiding this comment.
The vision is that you can do things like open doors, operate elevators, and do cool stuff not using Lua embedded in the bsp, but pointing to a script shipped with the map.
This is a single spawn flag which is global to the entire BSP and just loads a script to set up behaviors that map depends on.
As long as we maintain the lua -f interface or the g_luaScript interface, that's equivalent.
There was a problem hiding this comment.
Right, it's not embedded in the BSP but (presumably) somewhere in the map package. At least it's a bit easier to fix a broken one that way. Not sure how it will affect compatibility expectations.
Another thing, I think kai pointed it out in IRC the other day, is that this now lets maps execute arbitrary commands. So a malicious map can give out rcon access to the server or something. Not saying that we can't have the feature but we should be aware of the tradeoffs. It would be good to have a cvar to disable auto-running map Lua scripts.
