Lua may be getting axed, how many people care?

Game Talk The Lab
41

None of these functions from catalua.cpp are exported to class_definitions.cpp - this is intended.

// Registry containing all the game functions exported to lua.
// -----------------------------------------------------------
static const struct luaL_Reg global_funcs [] = {
    {"register_iuse", game_register_iuse},
    //{"get_monsters", game_get_monsters},
    {"items_at", game_items_at},
    {"choose_adjacent", game_choose_adjacent},
    {"dofile", game_dofile},
    {"get_monster_types", game_get_monster_types},
    {"get_item_groups", game_get_item_groups},
    {NULL, NULL}
};
42

The stuff that’s being externalised will continue to be externalised and genericised for re-use elsewhere, and I never for a moment suggested that any one person would be expected to shoulder the burden entirely. ;-)[/quote]
I only referenced the binding overhead as a side note, the main issue is the 10,000+ lines of new LUA you’re proposing someone should create, with no benefit to the work other than “it’s the right way to do it”.

[quote=“JT, post:40, topic:13488”]The reason that dynamic exists is because of the lean and mean principle: building story mechanics into the main build involves an overhead that can slow or stifle the development process on both sides of the equation, especially in something as mutable as a story. While development is normally iterative, moving from one feature to the next except when feature creep obviates or breaks previous features or bugs are discovered, storywriting is normally recursive, continuously refining, revising, rearranging, deleting, expanding, and distilling existing pieces to build a more cohesive whole.

My assertion is that it is indeed necessary and the right thing to do because any kind of direct integration with the program code will naturally suffer from substantial “noise” as every last change is made, re-made, reverted, and re-re-made.[/quote]
I’m not seeing where LUA is substantially lower-friction than C++, it still needs a build for testing and it still requires PRs, review, commits etc. The only thing you don’t need for LUA code is C++ expertise, which cuts bth ways because LUA expertise isn’t a given.

I’ve heard about how easy Lua is to integrate compared to, say, Python; if it really is that easy then it won’t be a major loss, so long as it can come back in another form later on. It’d render anything I was contemplating moot, but all of that doesn’t even exist yet so it’s a literal zero-value loss (actually even a net benefit to me as it saves me some time, come to think of it, although I’ll lament not being able to do it ;-)).[/quote]
It really is, the build support and code inclusion is a handful of lines, integration is completely dominated by language bindings.

What I mean is less the bindings themselves, but more of an outline of what LUA’s role in the game is. For example the biggest no-brainer is NPC conversations, the binding necessary to support conversations are very minor. Stuff like that, and even then, not until we actually need it.

43

Will it be a good reason to keep LUA if most of mapgen code will be transferred from CPP to LUA?

mil_surplus mapgen in LUA: https://www.dropbox.com/s/3gn2p4sgmt5gdmz/cdda_mapgen_mil_surplus.zip?dl=0

Please don’t afraid excess amount of loot - i didn’t add check for loot spawn chances yet.

44

Nope, we’ve been signalling for months now that LUA is going away, and nothing compelling has surfaced to change that decision.

45

(sigh)

Nevertheless - Dropbox - cdda_lua_mapgen_v2.zip - Simplify your life

Four overmaps in LUA:

s_pharm
s_sports
mil_surplus
sub_station

46

Hey Zhilkin, could this work for the mod I wanted to do where:

The apocalypse continues to evolve as you explore with fighting pits, cannibal towns, and apocalypse churches.

Basically, I wouldn’t want them to generate in the first overmap, but I would want them to start generating when you reveal more overmaps. Possibly also only during later seasons.

47

[quote=“Chezzo, post:46, topic:13488”]Hey Zhilkin, could this work for the mod I wanted to do where:

The apocalypse continues to evolve as you explore with fighting pits, cannibal towns, and apocalypse churches.

Basically, I wouldn’t want them to generate in the first overmap, but I would want them to start generating when you reveal more overmaps. Possibly also only during later seasons.[/quote]

There are four LUA callbacks, two of which are calendar-related:

[ul][li]on_new_player_created - called when starting the game (used in StatsThroughSkills mod)[/li]
[li]on_skill_increased - called when player skill is increased (used in StatsThroughSkills mod)[/li]
[li]on_day_passed - called once a day (at midnight)[/li]
[li]on_minute_passed- called once a minute[/li][/ul]

It is possible to store player string variables which can be saved/loaded with the game.

    player = {
        parent = "Character",
        functions = {
            { name = "get_value", rval = "string", args = { "string" } },
            { name = "set_value", rval = nil, args = { "string", "string" } }
        }
    }

Calendar class fields are exported to LUA:

    calendar = {
        new = {
            { "calendar" },
            { "int" },
            { "int", "int", "int", "season_type", "int" },
        },
        by_value_and_reference = true,
        attributes = {
        },
        functions = {
            { name = "day_of_week", rval = "string", args = { } },
            { name = "day_of_year", rval = "int", args = { } },
            { name = "get_season", rval = "season_type", args = { } },
            { name = "get_turn", rval = "int", args = { } },
            { name = "increment", rval = nil, args = { } },
            { name = "minutes_past_midnight", rval = "int", args = { } },
            { name = "print_time", rval = "string", args = { "bool" } },
            { name = "print_time", rval = "string", args = { } },
            { name = "seconds_past_midnight", rval = "int", args = { } },
            { name = "is_night", rval = "bool", args = { } },
            { name = "seconds", rval = "int", args = { } },
            { name = "minutes", rval = "int", args = { } },
            { name = "hours", rval = "int", args = { } },
            { name = "days", rval = "int", args = { } },
            { name = "sunlight", rval = "float", args = { } },
            { name = "textify_period", rval = "string", args = { } },
            { name = "turn_of_year", rval = "int", args = { } },
            { name = "years", rval = "int", args = { } },
            { name = "sunset", rval = "calendar", args = { } },
            { name = "sunrise", rval = "calendar", args = { } },
        }
    }

All lua mapgen-related (like, map:ter_set) and other functions are usable during the game, not only on mapgen stage.

So it should be possible to store initial calendar values, calculate time difference once a minute or once a day and make some changes to the map once enough time is passed.

Still there are many limitations in LUA (or at least I didn’t find the way to find a solution):

[ul][li]lua generated buldings aren’t rotated automatically;[/li]
[li]overmaps (displayed in the map) cannot be changed;[/li]
[li]it is not possible to calculate the number of tiles the player have traversed;[/li]
[li]bigger overmap coordinates are unknown.[/li][/ul]