Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Lap]

Lua is being used a lot more now because of how immensely easy it is to incorporate. Lua is a supplemental language, not really meant to be used by itself. When incorporated into a game it allows for on the fly debugging and does not require an outside compiler. Recent uses of Lua are Natural Selection 2, Supreme Commander and Demigod. Other roguelikes also have used it (Angband derivates and things like the T-Engine).

Lua is slower than C, and wouldn't be worth Toady's time to change the core of the game. However, it would be useful to have limited use of Lua for modders to use. Take something small, like adventure mode quests. Quests are things that would seem to be a bit too complex for just raws to fully do so Lua would be a great answer. Modders could then easily go about making very detailed quests simply and efficiently. Having Toady make some a couple dozen functions for Lua to use could result in some amazing creations as is the case every time I've seen Lua used.

This also wouldn't require opening up the actual core code, which we all know Toady does not want to do.

**I forgot to mention one of the greatest benefits of Lua: Using it minimizes mod conflicts and the need to create mod packs (see third post of this thread).**

[chucks]

Actually, I've worked with a toolkit called SWIG that provides scripting language interfaces for a wide range of language in addition to Lua.  You can generate bindings for python, perl, java, lua, tcl/tk, etc.  The list is HUGE.  Overall, it's fairly easy to use to get an interface into C/C++ application frameworks, but it does require the author's prior knowledge of the scripting language they are attemping to integrate their platform with.  There are caveats with the framework (any framework like this will have them), but it's still extremely powerful even with its limitations.

http://www.swig.org/

[Lap]

Thanks for the info chucks. I haven't heard of that. There's no doubt adding any scripting language would require an initial investment and occasional maintenance by Toady. They always pay off big though and could actually speed things up by allowing easier debugging.

I also realize I forgot to mention one of the best parts of Lua that make it so perfect for modding. With mods there is always a worry of conflict between two mods trying to modify the same thing. Usually, one mod just overwrites the other entirely, meaning the mod makers would actually have to merge their mods together. With Lua this isn't a big deal.

Going back to the questing example let's say we have a function Toady allows us to access that specifies if a quest giver should give you a quest.

Modder A wants to make it so that you only get the quest if you've killed no one in his family and have killed a certain number of monsters.

Modder B wants to let you be able to bribe/threaten people to give you quests.

These two modders want to access the exact same function and normally only one would win. With Lua you use things called "hooks". With hooks, all of these functions are run one after another. This way you could have any number of mods adding their code without it simply overwriting.

Should someone want to do a total conversion there is still the option of simply overwriting the original function as well.

Because of these hooks smaller mods can be made for certain features and players could more easily choose which features they want instead of having to download merged mega mods and packs. Keeping these packs updated is always a nightmare and you really have to have the same interests as the pack's creator or you're going to end up having to deal with a lot of stuff you would rather not experience.

[Derakon]

Scripting, APIs, and in general increasing moddability have all been suggested many times before. Toady's main concern is that he doesn't want the game that he makes to become too tied to mods that other people produce, and which he has no control over. You may well disagree with his stance, but it's his right to make the decision.

[Mel_Vixen]

Wasnt that only the case for 3-party software? Anyway i am not sure if scripted events would work in Df if the entire Game-world is "alive". In Stock-story-driven games you can add such things like scripting Events and places fairly easy but in df The world goes on and changes constantly so forcing ewvents and places into the game might disrupts some mechanics.

[Lap]

All I saw was one poorly explained request to make objects with Lua, to which there was no official response.

With Lua and many other scripting languages, they are dependent on what the main code allows them to modify. If there's no Toady defined function or variable, it's not modable. If he doesn't want to let you define every single facet of dwarves personality with Lua because it would be a bitch, then he doesn't have to make a Lua function for it. It's very easy to control what types of things would use the scripting language. Toady made the raws accessible and there's already things as different as a Fallout TC without the original game being harmed. Letting people modify certain parts of the game doesn't seem to only benefit everyone. Toady can't please everyone. There's going to be people that want clockwork dwarves with machine guns and modding is the best option instead of having suggestions like that come up over and over.

With things like quests, there are simply no reason not to add more random quests so long as they are of a sufficient quality. Making and debugging quests, especially complex ones, can like debugging a small game. It's time consuming and the actual work, writing, etc. is beneath Toady. He shouldn't have to waste time doing stuff most people can do when there's an infinite amount of things that only his knowledge could accomplish. This would save Toady and Threetoe a lot of time to work on more important things.

Not really sure how the game could be reliant on mods. If a mod becomes so "needed" Toady could just incorporate it at his discretion. No downside here.

Wasnt that only the case for 3-party software? Anyway i am not sure if scripted events would work in Df if the entire Game-world is "alive". In Stock-story-driven games you can add such things like scripting Events and places fairly easy but in df The world goes on and changes constantly so forcing ewvents and places into the game might disrupts some mechanics.

DF is living more than most games, but doing things like creating quest monsters, or finding an existing monster and simply adding a quest flag to them is not intrusive at all. There's no need to force things if you design your addons well either.

There's always going to be ways for players to break the game with their quests, but mods are peer-reviewed and optional so that's something that shouldn't get in the way of it happening.

[Sowelu]

I'd be worried about Lua slowing the game down.  All my experience with Lua for mods and for core engines has been that it is sloooow.  You'd want to heavily restrict where it could be used so that there was no chance of it slowing down the main game.

For stuff like quests, I don't have any opinion on using Lua over any other scripting engine.  Anything that got used would need that hook-based approach anyway.

[Derakon]

Let me elaborate a bit on what I understand Toady's stance to be.

* To be useful for modding, the game engine must expose certain functionality to the scripts. The scripts interact with the game engine in a certain way, as specified by the game engine.
* Someone makes a mod using the specified interaction. It becomes wildly popular.
* Toady needs to update the interaction. This breaks the scripts used in the popular mod.
* Nobody updates to the latest version of the game until the mod has been updated to use the new interaction method.

Worst case, someone makes a popular mod and then abandons it, which means that it never gets updated and much of the fanbase is playing an out-of-date game just so they can keep using the unsupported mod.

Whether or not you think this is a reasonable argument, it's Toady's stance (again, as I understand it), and I don't think he's going to waver on this issue.

[Peteł]

I'd be very happy with scriptable "AI" for the job manager screen at the very least, but AFAIR that's in the dev plans anyway.

Of course, fully exposed LUA AI like in SupCom could, far off in the distant future, allow for single player fort vs. fort maps (think dungeon keeper skirmishes).. whereby a civ of evil dwarves tries to square away your land, or turtles up and hoards all ..turtles, or generally causes havoc fun.

Or, in the same way, scriptable game modes and scenarios:
There was a popular AI mod for SupCom in which the AI would just build loads and loads of Tier 1 units (while still going for a strong economy) and rush you constantly. Imagine loads and loads of naked, muddy goblin wrestlers coming for your pig tail sock stockpile.

[0x517A5D]

Other roguelikes also have used it (Angband derivates ....

Angband itself had Lua at one time.  Then it was removed.  Not really a success story there.

Before adding Lua to DF, it would be worth looking into the failures, not just the successful projects.  I imagine Angband is exceptional, with its removal of a largely working feature, but I would like to see some projects that tried and failed to implement Lua or other scripting language.  Perhaps some lessons could be drawn from them.

[0x517A5D]

One potential benefit no-one's mentioned yet is "normalization" of the raws.

I don't like the current raws format.  It is essentially an mini content description language with hidden inheritance, hidden dependencies, and an ad-hoc format.

Porting the raws to a formal scripting language could clean all that up, and have the further benefit of syntax-checking and (probably) better debugging of problems with the declarations.  Limit warnings at least, and explicit inheritance.

[chucks]

Ok, I've kept quiet on preferences up to now, but I hate lua.  It's slow, clunky, and it's not a fully fledged language with a feature-complete standard library.

If you're going to connect to a fast, feature-complete scripting language, please use python.  Hell, huge chunks of DF could be written in python passing the SWIG-wrapper-around-C-C++-objects to heavily optimized C/C++ portions of the game.  Also, if this sort of architecture is used for future development, it has the potential to abstract the game away into OS independence.  No more windows binary or linux binary or osx binary squawkers.  One archived up python package makes everyone happy.

Also, writing the raws using a well-known and well-understood scripting language is a HUGE bonus.  Don't know the raws format?  A little self-documenting python to the rescue.

I have seen a very large number of architectures and frameworks, proprietary and free software alike, use the methodolgy with python and it shines brightly.

However, there is a huge cost of time to rewrite the portions of the codebase to encapsulate the DF game engine objects into modules that work well within a scripting framework.  It might even be a task as monumentous as threading!!!

Ok, seriously.  Good idea, but this thread is troll and flame bait.

[profit]

I use LUA when I am helping my brother with his open tibia server... 

    I usually end up just adding the feature into the source code and recompiling the server instead of creating a LUA script to do it because they always seem to have performance issues.

I do not know if there are other scripting API's that can be used that would be better but I really do not think it would make this program function smoother to be able to use LUA.

[Lap]

Worst case, someone makes a popular mod and then abandons it, which means that it never gets updated and much of the fanbase is playing an out-of-date game just so they can keep using the unsupported mod.

Whether or not you think this is a reasonable argument, it's Toady's stance (again, as I understand it), and I don't think he's going to waver on this issue.

One of the best things about their scripting languages is they are by nature open source and can be picked up by anyone if a mod is abandoned. You also really have to consider if the people who wouldn't update the engine would even play. I know there's people out there that won't play unless there's a modern mod. I know there's people that wouldn't play unless there were clockwork,robots, and mechanics. There's only so much content and normal Dwarf Fortress a person can take. It's the same for any game. When people get bored their options are either to quit entirely or use/make mods. Worrying about these players not updating is worrying about players you would have otherwise lost completely.

Angband itself had Lua at one time.  Then it was removed.  Not really a success story there.

I might actually look into that. My initial guess is that you don't need lua when half the derivatives already have it and you can choose to add it at your leisure. With how many deriviates of angband there are you can also argue that its code is so easy to modify you don't even need Lua. With open source the only benefit from adding Lua is making it slightly easier for players to change things. With closed source projects like DF there is much more of a benefit.

One potential benefit no-one's mentioned yet is "normalization" of the raws.

I don't like the current raws format.  It is essentially an mini content description language with hidden inheritance, hidden dependencies, and an ad-hoc format.

This would be awesome regardless of a fully functional scripting language!

I do not know if there are other scripting API's that can be used that would be better but I really do not think it would make this program function smoother to be able to use LUA.

I did warn you it was slow, and shouldn't be used for things that need to be run every frame. Quests shouldn't though and I'm sure there's a lot of other stuff that only gets run on activation. I am just recommending Lua because I have had good experiences with it. However, I haven't worked with any of the Lua alternatives so those might be better options, I just can't say.

And as for this being troll and flame bait it looks like there has been reasonable discussion for and against with logical reasons on both sides. No war here.

[Derakon]

As I said, you may disagree with Toady's stance, but it's his choice. I was simply trying to explain my understanding of that stance. I'm not about to try to argue this with you.