Feature #181

Add some kind of user management to the mod for online servers

Added by IR4T4 over 5 years ago. Updated over 1 year ago.

Status:In Progress% Done:

100%

Priority:High
Assignee:-
Category:Lua scripts
Target version:ET: Legacy Development - ALL

Description

Similar to shrubbot there is a need to deal with users/custom commands/authentication/ levels & such.

- shouldn’t be file based (sqlite)
- inspect if Lua is the way to go - see http://dev.kernwaffe.de/projects/noq

etl_db_diagram.png (35.5 KB) Radegast, 23.12.2013 18:01

247

Related issues

Related to Lua scripts for the Legacy mod - Feature #234: XP save Fixed 05.03.2013
Related to ET: Legacy Development - Feature #403: Add bayesian skill rating Fixed 18.11.2013
Blocked by ET: Legacy Development - Feature #309: ET:L database connectivity Fixed 03.06.2013

Associated revisions

Revision 278fc490
Added by Radegast over 4 years ago

ladm: initial groundwork, refs #181

Revision 70048556
Added by Radegast over 4 years ago

ladm: added command table, refs #181

History

#1 Updated by Radegast over 5 years ago

  • Target version changed from 2.71 to 2.77

#2 Updated by ailmanki over 5 years ago

Many lua scripts will need info about the players and there levels. So if different lua scripts can talk to eachother (IPCSend IPCReceive are not so pleasant to deal with), then it should be done in lua, but else the mod should handle that.

#3 Updated by IR4T4 about 5 years ago

  • Subject changed from Add some kind of user management to the mod/engine? for online servers to Add some kind of user management to the mod for online servers
  • Description updated (diff)
  • Priority changed from Normal to High

#4 Updated by IR4T4 about 5 years ago

  • Target version changed from 2.77 to 2.71rc3

#5 Updated by IR4T4 about 5 years ago

  • Target version changed from 2.71rc3 to 2.71rc4

#7 Updated by Radegast almost 5 years ago

IR4T4, why are you surprised?

Hmm, I just realized I don’t know what license NOQ is released under. Also, I think you sent me a newer version of NOQ than the one I committed, but I couldn’t find it anywhere. This discussion doesn’t belong here, we should move it to the Lua scripts for the Legacy mod project.

#8 Updated by Mateos almost 5 years ago

Radegast wrote:

Hmm, I just realized I don’t know what license NOQ is released under.

https://gitorious.org/enemy-territory/pages/Home

#9 Updated by Spyhawk almost 5 years ago

Mateos> NQ isn’t NOQ

(the link you provided is my own work, but I removed the NQ source code a while ago).

#10 Updated by IR4T4 almost 5 years ago

  • Project changed from ET: Legacy Development to Lua scripts for the Legacy mod
  • Category changed from Mod QAGAME to Lua scripts
  • Target version changed from 2.71rc4 to ALL

Radegast wrote:

IR4T4, why are you surprised?

Because you did add a sql based Lua script to the rep. If I do remember correctly you wanted to add a sql interface to the engine and do it this way. However the decission might push legacy mod online servers when the NOQ is adjusted to legacy. It’s just sad we’ve lost at least a year of development

Actually there is no real licence.

NQ Lua team 2009-2011 - No warranty :)

#11 Updated by Radegast almost 5 years ago

Oh no, I was never against the use of database from within Lua (just look at my XPSave script). What I do not want to do is to add database handling inside the Legacy mod itself. I still think it is best to do it engine-side and let mods use it through an interface (and yes, that means expose it to Lua as well).

Spyhawk said on the IRC today that it is a shame there is no admin system for the Legacy mod, so I thought we might use NOQ in the meantime.

#12 Updated by Radegast almost 5 years ago

Radegast wrote:

Also, I think you sent me a newer version of NOQ than the one I committed, but I couldn’t find it anywhere.

I think the version of NOQ I committed is too outdated. I haven’t had a closer look at the time, but I remember the one IR4T4 gave me had command plugin system for example.

#13 Updated by IR4T4 almost 5 years ago

Radegast wrote:

Oh no, I was never against the use of database from within Lua...

See your last answer here: http://dev.etlegacy.com/boards/1/topics/477?r=483#message-483

revision 199 is only a bit outdated but currently I don’t have access to the NOQ repository. RaFal or ailmanki might know more about the current revision.

#14 Updated by Radegast almost 5 years ago

Yes, my opinion hasn’t changed, but let me make it clear once again. Adding db access to C code on the mod side and exposing it to Lua → not OK. What I have in mind is:

#15 Updated by IR4T4 almost 5 years ago

Well I don’t think existing mods will use ETL engine SQL ... it’s a bit too late to introduce such a standard ... but maybe I’m wrong

1. people are forced to use ETL server (is this a reason ? ) / moders have to update their persistence code
2. I think we run into buffer issues/limits (32000 chars) when we pass bigger resultsets through the engine

Finally if you add an arrow in the above image from Lua-API to MySQL we have the current and planned situation?! We might use 2 SQL clients (server & lua) on the same database.
Modders can do the same way and we don’t have to blow the mod game code up ...

#16 Updated by ailmanki almost 5 years ago

IR4T4 wrote:

revision 199 is only a bit outdated but currently I don’t have access to the NOQ repository. RaFal or ailmanki might know more about the current revision.

I have not more access then you have IR4T4, I think Luborg from Kernwaffe community should now more, I haven’t touched NOQ in ages.
In my opinion it had good stuff, but overall - to be honest - I was not liking the direction it went so I stopped working on it.

I was never a fan of MySQL, as its difficult to predict what it doing. Its a black box in some ways - sure that is not completely true as such.
But lets just look at extreme situations, you are running a server for 10 years, your SQL db can be huge. MySQL is great but it has to be correctly used, and that is not so easy I think.
The idea of shifting MySQL into the core of ET, I like a lot - as then it should be possible to have proper threading I guess? What I wonder why MySQL, in my experience most software allows to define a SQL compatible database and just use what you prefer.
Lastly mods can then expose access to the DB in lua if they like.

#17 Updated by Dragonji almost 5 years ago

IR4T4 wrote:

Well I don’t think existing mods will use ETL engine SQL ... it’s a bit too late to introduce such a standard ... but maybe I’m wrong

Most active in development mods already has got some kind of DBs. I don’t really think devs will spend time on moving to SQL. What is more they want their mods to be compatible with as wide range of ET versions as possible, they’re not going to limit use of their mods to etlded only. Just my opinion.

#18 Updated by Spyhawk almost 5 years ago

Dragonji wrote:

Most active in development mods already has got some kind of DBs. I don’t really think devs will spend time on moving to SQL. What is more they want their mods to be compatible with as wide range of ET versions as possible, they’re not going to limit use of their mods to etlded only. Just my opinion.

That’s true. But in my opinion, we shouldn’t focus on existing mods. They’ll work anyway, regardless of what is done in etl (either through db access in the mod code, or through Lua). At this time, the only concerned mod is Legacy, and possibly future mods derived from it.

Note that since it is distributed with etl, there’s also no reason to make effort to keep Legacy mod compatibility with 2.60b server (I’m not talking about the 2.60b client here). It might break at some point, or it might even be broken already(?).

As I currently see it, the question to be answered is: "What is the best way for the Legacy mod and future derived mods?" And also "What is the best way for the Legacy mod and future mods?", but only once et:l will have taken over the world

Btw Radegast, it would be great if you could write the "roadmap and thoughts about the future of ET:L and the Legacy mod" as discussed a few months ago (it doesn’t have to be long, it only needs to define the main direction you are thinking about).

#19 Updated by gaoesa almost 5 years ago

I’m not really sure how to properly write posts in these as this is my first.

I have couple of notes that I think should be considered. First, for a server admin having MySQL server on their server is not automatic. For admins who host their servers on paid providers, would need to get the MySQL from their providers. In that sense, using TinySQL could be a better alternative, as the database can be locally stored in the server game folder. Second, MySQL is a resource hog, from the administrator stand point. Third, having to deal with a generic relational database will add a lot of overhead to the mod execution. This could be alleviated by loading required data before the game starts or with asynchronous accessess for example. The first is the easier method of these two. It’s a good thing to have a ready made database solution for a new mod, that will let the mod to store whatever data it wants. But I would like to emphasize these needs and especially fetching large results should be taken into acount in the implementation and in the interface.

P.S. It is unlikely that silEnT will move to a new database solution. But some form of optional compatibility (for admins to get data out) would not be out of the question. If ET SDK licensing allows using interfaces of the GPL version of the engine.

#20 Updated by Radegast almost 5 years ago

MySQL was chosen just as an example, but we will be using ODBC, so most database engines will be supported including sqlite3, TinySQL and PostreSQL. You can even use Microsoft Excel as your DB backed if you wish I am confident we will be able to make it efficient.

Dragonji wrote:

IR4T4 wrote:

Well I don’t think existing mods will use ETL engine SQL ... it’s a bit too late to introduce such a standard ... but maybe I’m wrong

Most active in development mods already has got some kind of DBs. I don’t really think devs will spend time on moving to SQL. What is more they want their mods to be compatible with as wide range of ET versions as possible, they’re not going to limit use of their mods to etlded only. Just my opinion.

ET:L is aiming to become the standard.

I don’t expect existing mods to migrate to our database api if they already have a working database solution. This feature is primarily aimed for new mods or those mods that don’t have DB support yet.

#21 Updated by gaoesa almost 5 years ago

Radegast wrote:

MySQL was chosen just as an example, but we will be using ODBC, so most database engines will be supported including sqlite3, TinySQL and PostreSQL. You can even use Microsoft Excel as your DB backed if you wish I am confident we will be able to make it efficient.

Indeed I actually meant sqlite. I just mixed it. Yes, I’m sure it can be made efficient, I just wanted to distress these requirements to the disucciosn as they need to be thought out early in the database table design and in the interface. Engine blocked in sleep to wait results from the database would be bad.

#22 Updated by Spyhawk about 3 years ago

#23 Updated by Spyhawk almost 3 years ago

See relevant discussion here too: http://dev.etlegacy.com/boards/2/topics/431

#24 Updated by Spyhawk over 1 year ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 100

We’re going the WolfAdmin route. See #975. DB engine has been added.
This ticket can be closed (I can’t ).

Also available in: Atom PDF