anything against removal of lualobby?

[abma]

i want to remove lualobby because it seems to be unused.

imo if someone wants such a functionality luasocket should be used.


these files would be removed:

rts/lib/lobby
rts/Lua/LuaLobby*
Menu/LobbyConnection*
cont/examples/Widgets/ingame_lobby.example.lua

(and maybe some more)

is it used anywhere?

[smoth]

>:|

I really want this. Please don't remove it. It is not used because last I checked it was incomplete. When I tried to start a thread asking about it, the thread was pretty summarily shutdown and the idea shat on.

I really hope that some day I will not have to use the lobbies at all. So please do not remove it.

[smoth]

talking with abma, lualobby was not what I thought it was and lua sockets is more in line with what I wanted.

[Kloot]

Any feature that is completely unused even after an extended period of time (or not even close to being finished plus unlikely to receive coding work) and better done in Lua should be sent to /dev/null IMO.

[zerver]

I agree, but... can you accomplish the same with plain lua? I think not.

I didn't study lualobby in detail, but if a feature is highly modular and therefore does not interfere with the other code at all, there is no need for a hasty removal.

Edit: Okay, looking at the code now it seems lualobby is not what I thought it was. But it indeed seems very modular. Only reason to remove it would be if we don't want someone to use it because it will be deprecated soon anyway.

[smoth]

zerver, it creates a maintenance nightmare thought, It requires an engine side implimentation of the server protocol vs lua sockets which can(assuming it works properly) get the server communication and I just parse out server commands(which I will have to implement). I don't think the maintenance of such a thing should be an engine dev responsibility. With luasockets the update and maintenance of thier lua implimentation of a lobby becomes the responsibility of the content developer whose project uses it. So why add MORe work to a feature that only a few will actually utilize?

If what abma told me in chat is true, I can pretty much do all I need with lua sockets. Where as lualobby it adds more overhead for you guys, and you guys are busy enough

[Licho]

Imo lua socket is more generalist approach. "LuaLobby" API can be rewritten in lua using sockets now if someone is interested. It shoudln't be that hard.

[smoth]

yep.

[gajop]

Agreed, but maybe wait till there's a lua Spring library out there which implements most of that?
I've found a couple of posts in regards to it, and some code that comes with it, but I haven't tried it out yet, does any of it work?

[smoth]

if anything, is there a way to remove it from the source but give a link to the old files? I know with subversion I can grab old files. Honestly like licho said, once the luasockets implementation is done by someone, anyone, lua lobby will be superfluous. Maybe having the old lualobby C++ may be helpful but I don't think it needs to stay in the engine for that.

[gajop]

easy to use it even with the github GUI (obvious it's also doable by just going to a specific commit with git CLI)
f.e:
https://github.com/spring/spring/blob/6 ... ckImpl.cpp

[knorke]

once the luasockets implementation is done by someone, anyone,

lua sockets works since a year or so. What "implementation" are you waiting for?

[PicassoCT]

Someones, he clearly stated it. Why asking twice? Have some faith into someone, he never let us down.

[smoth]

once the luasockets implementation is done by someone, anyone,

lua sockets works since a year or so. What "implementation" are you waiting for?

Someone has to do the lua to parse the commands and make the ui for all the lobby shit in game..

nothing as far as I know needs to be done by the engine devs. In your playing with it, did you find luasockets wanting?

[PicassoCT]

Can we have materia in the sockets?

[gajop]

once the luasockets implementation is done by someone, anyone,

lua sockets works since a year or so. What "implementation" are you waiting for?

Someone has to do the lua to parse the commands and make the ui for all the lobby shit in game..

nothing as far as I know needs to be done by the engine devs. In your playing with it, did you find luasockets wanting?

a step in the right direction would be to make an library(API only, not UI) which is similar to the lualobby thing

[smoth]

You can make a lua library to be used by people in their uis. That is how I would do it. If it works, add it to the spring base lua files and BAM errybody can use

[abma]

a step in the right direction would be to make an library(API only, not UI) which is similar to the lualobby thing

koshi (dev of springlobby) already did that, afaik its a c++ lib. its just not released...


EDIT: also imo it would be better to add the ability to load .so/.dll's for extending the unsynced part (and maybe synced part?) of the engine so it gets more modular...

[gajop]

a step in the right direction would be to make an library(API only, not UI) which is similar to the lualobby thing

koshi (dev of springlobby) already did that, afaik its a c++ lib. its just not released...


EDIT: also imo it would be better to add the ability to load .so/.dll's for extending the unsynced part (and maybe synced part?) of the engine so it gets more modular...

By library I meant an implementation in Spring lua using luasockets, native lua or engine code is the way to go.

Also not sure about the dlls, only if really needed imo. The problem with having custom dlls is that they need to be compiled for each platform separately, which will just add more maintenance hell.
F.e I'm not happy with the current state of VFS for user save/load (there doesn't seem to be a VFS.SaveFile, there isn't a clear VFS<->OS FS path mapping, and imo it confuses the user by showing a different FS tree). So since lua doesn't have a dir listing (http://stackoverflow.com/questions/5303 ... y-in-a-lua) I could use the lfs library for that, but it requires compiling, which creates a bigger platform dependence than just using os.popen.

PS: I'm not Picasso :)

[smoth]

EDIT: also imo it would be better to add the ability to load .so/.dll's for extending the unsynced part (and maybe synced part?) of the engine so it gets more modular...

I prefer the lua approach. it is os agnostic and requires others to be able to see your code.