Thoughts about moving general settings to config.lua

[Evil Puncker]

Hey everyone, what are your guys thoughts about this Pull Request?

For those who didn't understand, the proposal is to move a few settings that are spread between several files/places to a single place, config.lua

This kind of seems to divide the opinion of the community, so I would like to hear more suggestions and ideas



(imo, it is fine, but I also want to see the other side)

 

[WibbenZ]

I like it since it would help new users, but at the same time personally I think config.lua should be reserved for things you can't edit without source edits and a compilation.
When it comes to having 1 setting for multiple scripts I would prefer a library file.

 

[kokokoko]

I prefer keeping it small and focused, only including "more important/global-ish" settings (like settings for connection, rates, map). But I do think it would be nice to improve the discoverability of settings that are currently hidden away in other lua files. I'm not sure lifting these to config.lua is the best approach though. An alternative is to document these settings somewhere instead, maybe a customization.MD file (or whatever name) that would explain the functionality of common flags/settings and where these can be changed?

 

[slaw]

Of course they should be placed in config.lua

Because:
1) its easier to pull git changes from repo, when the only file you changed is config.lua (which is ignored by git). So it's easier to update the files because they are untouched.

2) its more user-friendly for no-advanced OT users. Well, yeah.. there are users that don't understand Lua but still want to create server just for fun. So for them it should be easy to change this basic behaviour of the server. It doesn't matter if it's in Lua or C++.

About big "amount" of configurables. Look how many options Apache offers: Verzeichnis der Direktiven - Apache HTTP Server Version 2.4 (https://httpd.apache.org/docs/current/de/mod/directives.html)

Then say its "much"!

 

[Mr Trala]

I voted yes but I think @WibbenZ idea is way better imo.

 

[EvilSkillz]

I like the idea

 

[WibbenZ]

Of course they should be placed in config.lua

Because:
1) its easier to pull git changes from repo, when the only file you changed is config.lua (which is ignored by git). So it's easier to update the files because they are untouched.

2) its more user-friendly for no-advanced OT users. Well, yeah.. there are users that don't understand Lua but still want to create server just for fun. So for them it should be easy to change this basic behaviour of the server. It doesn't matter if it's in Lua or C++.

About big "amount" of configurables. Look how many options Apache offers: Verzeichnis der Direktiven - Apache HTTP Server Version 2.4 (https://httpd.apache.org/docs/current/de/mod/directives.html)

Then say its "much"!

Well to be fair I could add a git ignore to ex "data/libs/configs.lua" in 2 seconds, thats not a problem.
But in a way I think it's wrong to not check for changes in config.lua, just look at when revscripts was added and everyone got 100 prints, "X was loaded" and the support team or the user themself had to find the correct config boolean and add that as a false value.

I don't think anyone in this community would say a huge config is a bad idea (atleast when it comes to helping newbies) but I think it would be a good idea to split those files into 1 or 2 or even more files, instead of having a 1000 line config.lua

We have to remember that the config values really don't help or make a huge diffrence for a person who knows the code, they know where the code is loaded will change it in that file. All they really "need" the config file is for variables that require a recompilation.

 

[Peonso]

I don't think it makes any sense. You can make infinite amount of customization on TFS, you gonna add a way enable/disable/customize every action/movement/creature script through the config file? It doesn't even have a map, the entry level talk makes nonsense. It is just clutter. Change sex script option on config? Why price in days and not gold? Use worms? Why not also an option for oldschool rope script? Can dig scrab in sand? I would say it even make it less noob friendly by the added complexity and by mixing important stuff with random niche customizations. A file is replaced or some other datapack is used and now you have stuff on config that won't even work, it makes the whole thing more stiff.

 

[Azakelis]

1. Each file should do only its job, keep config.lua values as it is.
2. Why the hell is it even a lua file? Why isn't it like xml already? (or even better a json/yaml)

 

[pink_panther]

Hey everyone, what are your guys thoughts about this Pull Request?

For those who didn't understand, the proposal is to move a few settings that are spread between several files/places to a single place, config.lua

This kind of seems to divide the opinion of the community, so I would like to hear more suggestions and ideas



(imo, it is fine, but I also want to see the other side)

Add item and vocation regen into the config as well.

I like it since it would help new users, but at the same time personally I think config.lua should be reserved for things you can't edit without source edits and a compilation.
When it comes to having 1 setting for multiple scripts I would prefer a library file.

Config file for anything you would otherwise need to modify in more than 1 other location.

 

[Nekiro]

Config lua for source code configs, anything else in separate file example: global.lua. Also making configs for everything is stupid. If we gonna make leechers live easier then this community will die even sooner.

 

[Michael Orsino]

Agree with Nekiro - config.lua for source code configs, everything else in a separate file. (e.g. like I did with the forgotten war server config file)
Going down this path you could actually strip back the existing config.lua a bit too and move some of it to the new file.

I don't agree with the second part of Nekiros statement though - configs are great and making life easier for people is great too. Yes there could be endless options made, but common decisions like...worms for rods, change gold, etc. could be a really nice feature to allow quick and easy customisation.

This community was built on the back of it being easy to enter (xml download & run, sqlite download & run). Now I feel like half the community actively tries to make entry more difficult for new users, while the other half (largely dissociated with otland already) actually wants to make it easier because they remember how they got started - and it sure as shit wasnt by being a fucking programmer already.

 

[Mr Trala]

I strongly disagree with the second part of Nekiro comment, OT community is dying, and you don't want to make life easier for newcommers? cmon.
The one that never leeched from otland or stackoverflow throw the first stone.

 

[Nekiro]

I strongly disagree with the second part of Nekiro comment, OT community is dying, and you don't want to make life easier for newcommers? cmon.
The one that never leeched from otland or stackoverflow throw the first stone.

Leeching is not learning, you are talking about learning, if you gonna make easy everything then no one will ever learn, so no one will contribute to the comnunity back, because they will wait to see "new config values". That's my opinion though.

 

[Xikini]

Increasing the level of entry to reduce the amount of leechers also reduces the amount of people who are likely to contribute.

While we cannot continue to provide download+run servers anymore, we should at least make the process of setting up a server as smooth as possible, while also improving the usability of the current files.

As it is, there are many variables hidden away in the source files, that make using Lua functions next to impossible for newer users unable to find them.

Even today, here, it was a nuisance trying to locate the different variables, even knowing what I was looking for.

You have to remember that for people new to programming / Lua / C++ / OT's, there is a lot of information to learn, before you can even fiddle around and create basic scripts.

If the level of entry is too high, no amount of willingness to learn is going to overcome that obstacle, and the community will surely die as a result.

So my stance is;

Level of entry should remain as easy as possible.
---

Leechers will always exist. You, myself and 99.9% of other people were a leecher at some point or another.

We should not punish new users because we don't value leechers are highly as contributors.
Instead, we should make the transition from leecher to contributor as easy as possible.

 

[Itutorial]

I think adding all the luascript commands in a file again would be good. Including examples of how to use them. Along with all functions onUse, onMove, ect. Also, get a good description of what is being passed for example: Creature, Player, Monster, ect. is Userdata. Position is a table. I don't think modifying lua scripts that are pre-coded is an issue. Understanding TFS is harder than ever because have a lot of the newest coding methods which means less people know about it and it is more advanced.


Another thing would be adding files that explain all methods and variables that are in each class. Which would pretty much just be copying all the .h files but keeping it a bit more organized. Possibly add some notes for important things. At this point even really good developers do no want to touch TFS because it would require hours of searching through files trying to figure it all out when we could have it structured in just a few files.

 

[Azakelis]

That's what proper documentation is for.

 

[oen432]

I think adding all the luascript commands in a file again would be good. Including examples of how to use them. Along with all functions onUse, onMove, ect. Also, get a good description of what is being passed for example: Creature, Player, Monster, ect. is Userdata. Position is a table. I don't think modifying lua scripts that are pre-coded is an issue. Understanding TFS is harder than ever because have a lot of the newest coding methods which means less people know about it and it is more advanced.


Another thing would be adding files that explain all methods and variables that are in each class. Which would pretty much just be copying all the .h files but keeping it a bit more organized. Possibly add some notes for important things. At this point even really good developers do no want to touch TFS because it would require hours of searching through files trying to figure it all out when we could have it structured in just a few files.

You are literally describing docs. Lua functions (https://docs.otland.net/ots-guide/tfs-documentation/lua_functions)
Btw. you are free to contribute to these docs, it's lacking a lot.