Author Topic: Lua may be getting axed, how many people care?  (Read 4617 times)

Offline Gunsmith

  • Zombie Food
  • *
  • Posts: 14
    • View Profile
Re: Lua may be getting axed, how many people care?
« Reply #30 on: May 14, 2017, 07:00:02 PM »
Cool, there is an actual (oceanic/Lake based) water world?

I always wanted to make undead infested nuclear aircraft carriers (with jets and helicopters), nuclear submarines/minisubs - a claustrophobic trapped scenario + impending doom deep under the ocean due to limited and depleting food, water (and perhaps oxygen if the oxygen generators malfunction/sabotage/run out of energy) supplies - forcing you to fix and/or take over control of the sub, in order to head back to the water surface or die by suffocation, starvation, radiation (damaged nuclear reactor), nuclear/conventional missile detonation (due to sabotage/damage by zombies, damage by fire) or simply by being swarmed and eaten alive - kinda similar to the lab escapes but worse.

Furthermore, other ships such as Littoral Combat Ships/Coastal Defense Ships/Amphibious Assault Ships, where one could launch from and return to, your Littoral Combat Ship within the safety of your amphibious tank!), helicopter carriers (launch your raids from your own helicopters!), Drone carriers (massacre zombies with your drone legion), (Guided missile)destroyer ships, Engineering ship (mobile ocean-based factory), hospital ships (crawling with advanced undead types, but also much needed medicine and tools) and/or civilian Cruise Ships, Mega oiltankers, Mega Cargo Ships of Oil Platforms in the game, all came to mind, but there was not enough water surface and water depth to make such very large ships happen. And not to forget, Large fishing ships such as big fishing trawlers to catch all those fish (and occasional Landshark/Undead LandZhark - think the ZHulk + Shark that is a significant threat even at end game situations, both on land as well is in water).

This water world seems like exactly what I needed.

Alternatively, oceanic coastal or lakeside areas with boats would really be awesome too! Just rush to a boat, clear it out of all hostiles, and head to safety of the open seas and hopefully find a nice little island/oil platform to make your base. Failing that make your boat into a mobile base (kinda like doom-mobile but on water), and raid the coast at your leisure with your boat(s)!
« Last Edit: May 14, 2017, 08:01:20 PM by Gunsmith »

Offline Kevin Granade

  • Administrator
  • Survivor
  • *****
  • Posts: 5588
  • I code dead people.
    • View Profile
Re: Lua may be getting axed, how many people care?
« Reply #31 on: May 15, 2017, 02:33:10 AM »
I'm planning on replacing LUA-based code with behavior you can configure with JSON wherever possible, so hopefully little to no features will be lost.
I'm curious, how would that work code-wise?
It depends on what exactly the mod does, but in most cases it will mean translating the logic to c++, then just turning on and off (and possibly configuring) the behavior with a mod option instead of coding it in LUA.
In a lot of cases, like StatsThroughSkills or FasterZombes, it'll just be a matter of making a scaling factor available that can be set by a mod.
It looks like the ninja mod adds some item or trait behavior, we would just impliment that behavior in the core c++ code, and allow mod-only items or traits to use it.
Its like a fun family cookout, except your family is burning in flames while trying to eat you. -secretfire
I'm more excited than a survivor on meth and toast'ems. -Nighthawk
The the giant wasp is slammed through the zombie brute!

Offline Cassumbra

  • Zombie Food
  • *
  • Posts: 8
    • View Profile
Re: Lua may be getting axed, how many people care?
« Reply #32 on: May 16, 2017, 11:35:49 PM »
i really want to do some things in lua that im pretty sure can't be done in json. what are things that json can and cant do and how many of the cants does lua take the place of? also im having a lot of issues trying to figure out how to mod this game, is there some json documentation lying around somewhere? :V

also i need a list of lua callbacks pls

Offline Alec White

  • NPC
  • **
  • Posts: 215
  • I'm shy
    • View Profile
Re: Lua may be getting axed, how many people care?
« Reply #33 on: May 16, 2017, 11:46:54 PM »
i really want to do some things in lua that im pretty sure can't be done in json. what are things that json can and cant do and how many of the cants does lua take the place of? also im having a lot of issues trying to figure out how to mod this game, is there some json documentation lying around somewhere? :V

also i need a list of lua callbacks pls

Zhilkin already linked where the lua wizardry is.

Check example mods in https://github.com/CleverRaven/Cataclysm-DDA/tree/master/doc/sample_mods

Also all LUA bindings are automatically extracted to https://github.com/CleverRaven/Cataclysm-DDA/blob/master/lua/class_definitions.lua

Offline Zhilkin

  • NPC
  • **
  • Posts: 218
    • View Profile
Re: Lua may be getting axed, how many people care?
« Reply #34 on: May 31, 2017, 02:57:49 AM »
I've played a bit with the LUA: http://smf.cataclysmdda.com/index.php?topic=14542.msg300320#msg300320

Will that be enough to prevent LUA from being axed? :)

Offline Zhilkin

  • NPC
  • **
  • Posts: 218
    • View Profile
Re: Lua may be getting axed, how many people care?
« Reply #35 on: June 01, 2017, 01:22:19 AM »
Lua mod that adds two atomic Rivtech tools (entity scanner and earthquake generator):

https://www.dropbox.com/s/yurzmmqtjhv0r98/ExtraTools_alpha.zip?dl=0

Offline JT

  • Zombie Food
  • *
  • Posts: 5
    • View Profile
Re: Lua may be getting axed, how many people care?
« Reply #36 on: June 01, 2017, 07:49:37 AM »
Whoa, join a game a week after everyone decides to get rid of the one thing that actually caught your interest in the game... O blessed art thou, circumstance.  Well, small loss if they go through with it and I disappear, I guess. ;-P

I get that its support is probably a pain, and indeed so many people are doing things in hard-code.  But the problem isn't that everyone's doing stuff in the native code and therefore Lua support is irrelevant... the problem is that everyone's doing stuff in the native code when they shouldn't.  Esoteric, purpose-driven scripting or behaviour should be externalised; the stuff that's hard-coded in a game should almost always be limited solely to core mechanics and platform support.  Things like door pulleys, etc. should be externalised as a matter of best practice.  The vast majority of the mapgen stuff is being externalised already, and the only holdouts are, no surprises, scripted functionality.

Lua would also be pretty much essential for NPC behaviour and dialogue, unless one can honestly assert they're willing to put in the work on a JSON-based solution that could rival, say, Fallout 1's level of complexity.  (Which Black Isle used scripts for, I might add. =))  At the very least, it should be easy to foresee that, once people stop worrying over the gameplay mechanics and start concentrating on the late game, numerous amounts of scripted behaviour will be critical.  Lua is the glue that affixes the game to the sandbox.  It's a great sandbox game, but its longevity is limited to an in-game year at best, and the only meaningful way of introducing dungeons, conversations, quests, and unique artifacts will be with a script engine.

"Not being used" as a justification for removal is a self-fulfilling prophecy: it will indeed never get used if you get rid of it.  Rather than throwing out the baby with the bathwater, concentrate on showcasing it and discouraging improper use of the engine for stuff that really should be maintained in soft-code.  Pretty much every time someone says "I don't think this should go into the mainline" is a pro for Lua support. =)  If you give people actual time to use the functionality it adds, and provide documentation that isn't as obtuse as raw compiler-generated output, we'll be more likely to see interesting mods cropping up here (like those of the Japanese community).

[edit]Just saw the thread linked here on Github debunking the "time" part, but wanted to mention the game currently attracts only programmers and sandbox-players because there isn't an actual plot going on -- shift the focus onto a campaign (presumably, downloadable independent campaigns) and you're far more likely to see writers and designers showing up as well, who will be clamoring for anything that doesn't require them to get down and dirty with the core code, and yet will be deeply and profoundly disappointed with the limitations of JSON or the (relatively) astronomical turnaround time on requesting engine features needed for their questlines.  Thus, my "time" argument is not based on "give it time", but rather "wait for the time where it becomes relevant".  No one will use the Lua functionality right now because the game just isn't far enough along for it to matter, but that's no incentive to get rid of it... that's incentive to keep it in now so it doesn't become an absolute bitch to bring back in later.  If this game will only ever remain a zombie sandbox, then this of course no longer matters.

That all said, there are more than a few examples of iuse features in those Japanese mods that would make a not-insubstantial number of people pissed if support were removed entirely. =)
« Last Edit: June 01, 2017, 08:16:08 AM by JT »

Offline Kevin Granade

  • Administrator
  • Survivor
  • *****
  • Posts: 5588
  • I code dead people.
    • View Profile
Re: Lua may be getting axed, how many people care?
« Reply #37 on: June 02, 2017, 06:03:11 AM »
Well reasoned argument, but it's simply not compelling.
I have personally spent dozens to hundreds of hours on LUA support, a number of other very productive developers have spent far more time than me.  In addition, LUA support makes builds harder for everyone, representing a drag on the entire project's productivity.  The sum easily represents over a thousand dev-hours of time spent on this feature.  The lua bindings themselves are 24,000 lines of C++.
On the other hand, we have what you see listed in this thread, an extremely meagre list of features, that in most cases would have been quicker to develop in C++, totaling something like a few dozen hours worth of development.  There's something like 2,000 lines of LUA that have been written for this project.

This ratio just. does. not. make. sense.

the problem is that everyone's doing stuff in the native code when they shouldn't.
That's a really hard sell in a project like this, I'm not about to tell people that they MUST code certain things in LUA, regardless of whether they know the language or not.  That literally means refusing contributions in some cases.
Things like door pulleys, etc. should be externalised as a matter of best practice.
If we're talking converting existing functionality to LUA, I'm sure as hell not going to shoulder the overhead of rewriting tens of thousands of lines of code* in a scripting language purely in the name of "correctness".  For that matter, I don't want to review tens of thousands of lines of LUA code that don't add functionality to the game, but instead just move it elsewhere.
Lua would also be pretty much essential for NPC behaviour and dialogue,
...
Lua is the glue that affixes the game to the sandbox.
...
the only meaningful way of introducing dungeons, conversations, quests, and unique artifacts will be with a script engine.
This assertion doesn't follow, you can obviously do anything in C++ that you can do in LUA.  There is some kind of dynamic in games development where LUA or other scripting languages are preferred over coding things directly in C++, but it just hasn't surfaced in this project.  We seem to have very little LUA expertise, even though a number of people have stated it's the "right thing to do.
Thus, my "time" argument is not based on "give it time", but rather "wait for the time where it becomes relevant".  No one will use the Lua functionality right now because the game just isn't far enough along for it to matter, but that's no incentive to get rid of it... that's incentive to keep it in now so it doesn't become an absolute bitch to bring back in later.
I disagree, we ether have zero interest in writing meaningful features in LUA, or we have deeply disfunctional LUA integration, such that people interested in using it flee in terror immediately.  In either case, the solution is to get rid of the disfunctional integration and then bring it back when it is needed AND someone (frankly, not me, I have no idea how that sort of integration *should* work) has a plan for supporting scripters other than "expose a bunch of internal game state to LUA".  Basic LUA integration is extremely simple (though it does add some complexity to the build process), so it's fairly trivial to restore, it's the infrastructure to expose engine internals to LUA that's a PITA, and that's what hasn't proven successful.

*You might think I'm exaggerating, but check the main targets for this.  iuse.cpp ~8,000 lines of code, mapgen.cpp ~10,000 lines of code, mapgen_functions.cpp ~5,000 lines of code, iexamine.cpp ~3,500 lines of code, monattack.cpp ~4,500 lines of code.
Its like a fun family cookout, except your family is burning in flames while trying to eat you. -secretfire
I'm more excited than a survivor on meth and toast'ems. -Nighthawk
The the giant wasp is slammed through the zombie brute!

Offline Chezzo

  • Survivor
  • ***
  • Posts: 321
    • View Profile
Re: Lua may be getting axed, how many people care?
« Reply #38 on: June 02, 2017, 12:28:10 PM »
Gunsmith, water mod is in here:

http://chezzo.com/cdda/mods/Japanese_Mods.zip

It does use Lua, but not to make it a water world, it looks like it uses it to give fish better vision.

Offline JT

  • Zombie Food
  • *
  • Posts: 5
    • View Profile
Re: Lua may be getting axed, how many people care?
« Reply #39 on: June 02, 2017, 07:52:12 PM »
That's a really hard sell in a project like this, I'm not about to tell people that they MUST code certain things in LUA, regardless of whether they know the language or not.  That literally means refusing contributions in some cases.
[snip]
If we're talking converting existing functionality to LUA, I'm sure as hell not going to shoulder the overhead of rewriting tens of thousands of lines of code* in a scripting language purely in the name of "correctness".  For that matter, I don't want to review tens of thousands of lines of LUA code that don't add functionality to the game, but instead just move it elsewhere.

*You might think I'm exaggerating, but check the main targets for this.  iuse.cpp ~8,000 lines of code, mapgen.cpp ~10,000 lines of code, mapgen_functions.cpp ~5,000 lines of code, iexamine.cpp ~3,500 lines of code, monattack.cpp ~4,500 lines of code.
[snip]
This assertion doesn't follow, you can obviously do anything in C++ that you can do in LUA.  There is some kind of dynamic in games development where LUA or other scripting languages are preferred over coding things directly in C++, but it just hasn't surfaced in this project.  We seem to have very little LUA expertise, even though a number of people have stated it's the "right thing to do.

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. ;-)  I've been looking at the mapgen stuff specifically as something I've wanted to hop into and start externalising myself, which is hampered mainly by the fact that I would need to get directly involved with the build process too.

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.  It can of course mimic development closely (and vice versa if there is no check on feature creep), but it's usually easy to spot those games that have done their stories that way: they usually feel like run-on sentences with one stereotype after the next, rather than archetypes who fit in (or more accurately don't fit in).

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.  I'll be a lesser man and note that there are three separate implementations of winches in the game engine, one for each of garages, farms, and vault, which is precisely the scenario that a data-based architecture is intended to correct. Okay, this was completely wrong.  Could've sworn I had seen separate code somewhere...

Essential balance of map generation is another -- for instance, the hard-coded one_in(100) for a spiderweb to spawn means that probabilistically, you will encounter at least one after walking through just 23 horizontal tiles of forest, assuming your reality bubble overlaps three map tiles.  This could be switched over to externalising that magic number into an option-friendly global variable, or could be turned into its own feature request to refine the probability further, but if the work were done to externalise these sorts of things into their own map tiles without concerning themselves with balance, a balancing and refinement pass could then balance dozens or hundreds of these sorts of things simultaneously in a fraction of the time and overhead.

This divide is also why almost every substantive change I've seen in the codebase so far has focused on raw mechanics and refining the existing feature set; it's not easy or quick to work on balance-, plot-, or mission-related mechanics as both the development and scripting language are oriented towards engine-focused behaviour.

I disagree, we ether have zero interest in writing meaningful features in LUA, or we have deeply disfunctional LUA integration, such that people interested in using it flee in terror immediately.

It's definitely the latter scenario.  For instance, every single one of the extant "do one op to all monster types" Lua mods, including even the Ninja mod, uses this:

local monster_types = game.get_monster_types()

This function is not listed in class_definitions.lua or anywhere else in the data.  One has to go directly to the C++ code in catalua.cpp to find it.

(Incidentally, the Japanese Elona roguelike is written in a language that is so high-level (Hot Soup Processor) that it's a borderline scripting language in its own right.  I suspect that Japanese modders are thus naturally inclined to use Lua.  I also note that it must be jarring to have to switch to a Romantic/Germanic language to program with: to a person knowing a pictographic language, code is quite literally code.)

In either case, the solution is to get rid of the disfunctional integration and then bring it back when it is needed AND someone (frankly, not me, I have no idea how that sort of integration *should* work) has a plan for supporting scripters other than "expose a bunch of internal game state to LUA".  Basic LUA integration is extremely simple (though it does add some complexity to the build process), so it's fairly trivial to restore, it's the infrastructure to expose engine internals to LUA that's a PITA, and that's what hasn't proven successful.

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 ;-)).

In the end, and it seems like we're agreed on this, the difficulty here is that the Lua support for all of its fantastic power is basically just a layer on the game engine which requires direct and intimate knowledge of the program code, because there isn't enough abstraction and because the totality of its bindings are not actually visible to anyone who'd want to use it.  Don't get me wrong, having the power to affect the game engine so tightly is a godsend in any scripting environment -- but it's not documented meaningfully or in a way that would encourage its use over the game engine itself, and conventions that would apply from other "languages" like the scripts in Bethesda's Gamebryo incarnations don't apply here.  Thus, anyone who wants to use it will need to refer directly to the program code anyway.

The pragmatists among you have correctly realised that if they have to learn/know C++ to use the Lua support then they might as well just use C++, especially if they don't also already know Lua.  The... let's call them "lazyists", like me, would much rather work outside of that environment with rapid prototyping that needs no more than the load time of the game to try.  Given the immense popularity of the game on Reddit and those few sites I've bumped into that laud it, there's a substantially low ratio between "devs" and "community" and I suspect that ratio reflects programming ability -- many people would contribute if they could, but don't.

(Granted, the (unsuccessful) VS build I tried took only about three or four minutes to build the object code before it broke at the linking phase, although I'm not sure how much longer it would have chugged on the linker.)

-----

If you do want a candidate for an improved architecture, all you really need is an event-driven system:

1) Global: Currently already handled with the main.lua in each mod.

2) Missions: Currently, each "mod" provides a global script and a preloader to attach scripts to iuse actions.  Taking a page from Bethesda, it could also be a container for missions that run scripts -- each mission could have zero or more scripts attached.  Each script attachment would define a turn interval where it would fire, and these scripts would thus heartbeat so long as that mission is in the player's quest tracker.  (Because we don't have to work around the unique perversions of the Bethesda engines, there's no need to rely on hidden quests and that sort of nonsense, since we have a built-in global script architecture also.)

3) Mapgen: Any time a map tile is loaded, check the JSON for that map tile and, if it defines one, fire the main function in the named script.  This would make it almost simplistic to externalise the majority of the mapgen code in and of itself.

4) Item Use: Already functional, although tying scripts to iuse actions more directly (i.e., specifying the filename of the script to run directly in the JSON) would make things cleaner.

5) Objects: Each object can have zero or more scripts attached, and objects receive heartbeats to fire their scripts which are divided over the total number of loaded script objects to avoid burdening the engine -- unless a script is declared mission-critical, where it would fire every turn.  (Some common sense conventions like declaring creature objects mission-critical if they happen to be in combat with the player would also make sense.)  This would handle Macguffins, scripted movements and scenes, and could even be used to override AI behaviour and control them manually.

...

There is, for the sake of honesty, one overriding and uncontestable counter-argument to anything I have here: if the game is intended to be a single centralised forum working on a single unified plot, rather than based on a community that contributes its own independent plotlines and featuresets -- i.e., a game that is based on creating an idealised singleton rather than a game that is based on catering to individual whims and fancies and creating their own unique flavours -- then there is absolutely no benefit to distinguishing a modder versus a developer.  It will, unfortunately, limit the game to those modders who are also developers, but that isn't necessarily a bad thing.

The real Duesy (if implementing Lua later on is a bitch, then this is the name-it-after-my-wife-Dotti) is that any meaningful script system would have to keep certain entities persisting at a low level of fidelity, with periodic script updates, which would involve basically discarding the reality bubble as we know it.

(Out of context, that last part almost sounds like something you'd read on a dark web forum...)
« Last Edit: June 02, 2017, 08:56:37 PM by JT »

Offline Zhilkin

  • NPC
  • **
  • Posts: 218
    • View Profile
Re: Lua may be getting axed, how many people care?
« Reply #40 on: June 02, 2017, 08:59:07 PM »
None of these functions from catalua.cpp are exported to class_definitions.cpp - this is intended.

Code: [Select]
// 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}
};

Offline Kevin Granade

  • Administrator
  • Survivor
  • *****
  • Posts: 5588
  • I code dead people.
    • View Profile
Re: Lua may be getting axed, how many people care?
« Reply #41 on: June 04, 2017, 07:52:25 AM »
"this is too much work"
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. ;-)
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".
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.
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.
In either case, the solution is to get rid of the disfunctional integration and then bring it back when it is needed AND someone (frankly, not me, I have no idea how that sort of integration *should* work) has a plan for supporting scripters other than "expose a bunch of internal game state to LUA".  Basic LUA integration is extremely simple (though it does add some complexity to the build process), so it's fairly trivial to restore, it's the infrastructure to expose engine internals to LUA that's a PITA, and that's what hasn't proven successful.
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 ;-)).
It really is, the build support and code inclusion is a handful of lines, integration is completely dominated by language bindings.

If you do want a candidate for an improved architecture, all you really need is an event-driven system:
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.
Its like a fun family cookout, except your family is burning in flames while trying to eat you. -secretfire
I'm more excited than a survivor on meth and toast'ems. -Nighthawk
The the giant wasp is slammed through the zombie brute!

Offline Zhilkin

  • NPC
  • **
  • Posts: 218
    • View Profile
Re: Lua may be getting axed, how many people care?
« Reply #42 on: June 08, 2017, 07:43:30 PM »
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.

Offline Kevin Granade

  • Administrator
  • Survivor
  • *****
  • Posts: 5588
  • I code dead people.
    • View Profile
Re: Lua may be getting axed, how many people care?
« Reply #43 on: June 08, 2017, 11:38:43 PM »
Nope, we've been signalling for months now that LUA is going away, and nothing compelling has surfaced to change that decision.
Its like a fun family cookout, except your family is burning in flames while trying to eat you. -secretfire
I'm more excited than a survivor on meth and toast'ems. -Nighthawk
The the giant wasp is slammed through the zombie brute!

Offline Zhilkin

  • NPC
  • **
  • Posts: 218
    • View Profile
Re: Lua may be getting axed, how many people care?
« Reply #44 on: June 09, 2017, 01:23:23 AM »
Nope, we've been signalling for months now that LUA is going away, and nothing compelling has surfaced to change that decision.
(sigh)

Nevertheless  - https://www.dropbox.com/s/rlgitvrk9hoo49r/cdda_lua_mapgen_v2.zip?dl=0

Four overmaps in LUA:

`s_pharm`
`s_sports`
`mil_surplus`
`sub_station`