Lua lobby?

[smoth]

hows it going? last I heard there was some issue with need someone who understood the server protocol stuffs.

[AF]

Can lua lobby handle these things itself? Or does it not get passed traffic directly

[Pako]

Can lua lobby handle these things itself? Or does it not get passed traffic directly

Yes the lobby protocol could be handled in Lua and should be.

I did Lua lobby with manually handling net messages but bad documentation and outdated server protocol makes making it very slow and lack of downloading maps or generating minimaps means it will be a huge effort to get all working. But I have a plan to make it happen.

[abma]

@Pako:

do you have some online repository? i'm interested in coding downloading-stuff in lua, too. i already wrote a downloader in c++ and already tested around with lua-socket but didn't start yet.

[Cheesecan]

Pako did you check this? It's more or less up to date.

But yes writing Lua lobby must be unpleasant that's why the last thread was posted one year ago and got barely any interest.

[smoth]

I don't need map dl or mini map preview, at least not at first. so as far as hosing a battleroom, joining channels and all that how class are we?

[koshi]

The current implementation can barely chat afaict.

[smoth]

Bummer

[AF]

Channels and PMs are the most basic part of the lobby system, they're incredibly easy/simple

JOIN channelname
SAY channelname why hello there

SAID channelname AF why hello there

SAYEX channelname ate himself

SAIDEX channelname ate himself

( AF ate himself )

There's also SAYPRIVATE SAIDPRIVATE SAYBATTLE SAIDBATTLE etc

[Cheesecan]

Dont forget topic. players join leave. player status.
All server commands could be described as easy. It is the implementation of them that is non trivial. eg. for chatting you also need to parse all status updates to have a list of channels and players. You need to do user table. present chat in an appealing way. show players leaving or joining etc.

In Lua I imagine you need to write a lot gui components from scratch meaning low level drawing primitives and blitting. Handle threads so gui doesnt lock up on time consuming tasks. interface with other systems say elo eanking via sockets. list goes on.

Then also write tests and make it maintainable by others in the future. it is the biggest lua project so building it like you would a widget means it will eventually break. in ba widgets crash all the time even though they are relatively simple.

Excuse the punctuation im writing on my phone.

[AF]

As someone who built a lobby I can tell you I'm aware of those things, but the most basic, easiest part of the entire protocol is simple chat. You don' need to parse the bitfields and see if a user is a bot or an admin to be able to chat

[Cheesecan]

Well at very least users expect to know if a person is in a game. They want to be able to join that game from rightclicking playername.

If it is nontrivial the core design is more important than adding features. if core is goid, adding features is easier.

Ofc no excuse why there is no chat after 1 year+ :0

[aegis]

LuaLobby right now doesn't allow raw message sending, just a few predefined commands. IMO this is a mistake, I'd just handle login using the engine (to make sure they're connecting to a lobby server), and pass raw protocol into lua when it's done. This would even give us full raw sockets for anyone who implemented a lobby server handshake, which is a bonus :)

I even have a bit of a framework in pure lua for the protocol handling I could reuse from when I was playing with raw sockets.

Ditch all the current commands, allow connecting to anything matching a lobby server handshake, and give us raw send/recv methods.

[AF]

I oppose the attempt to force TASServer on everyone, remove the login too and just give us a raw sockets protocol instead

[Cheesecan]

A DHT would be cool. Using CORBA instead of sockets.

[Licho]

Raw sockets would be useful for more application. For example you could implement simple webbrowser to display news etc.

[aegis]

it's too easy for pure raw sockets to violate sandbox. that's why flash uses crossdomain policy files.

requiring a known handshake is a very easy way to respect the sandbox. better suggestions are welcome, but doing something so open we'd either be able to violate the user's trust or require user permission constantly isn't necessarily the best path

[hoijui]

how does fixed handshake prevent malicious usage?
i just code viral stuff, sent after lobby handshake procedure.

[AF]

That's a horrendous idea.

Why we should NOT tie the engine into a handshake protocol

• It locks us into the TASSERVER protocol
  There are plenty of non-TASSERVER uses for sockets
• It forces us to use a string based protocol on top of messages separated by newlines.
  What if I want to interface with a service that does not rely on this type of encapsulation?
• It forces a huge amount of cruft on any non lobby server use of sockets
  So when are we getting the apache module for TASSERVER logins? Do I need my LAMP stack to start every connection with TASSERVER and wait for a LOGIN command before it handles a basic AJAX request? Must we handle OpenID and OAuth using proxy servers to get around this arbitrary limitation?
• It locks Lobby updates into the Engine release cycle.
  We can't update the lobby server protocol until we update the engine
• It complicates the lobby server deployment
  To update the engine if the protocol has changed we would need to update the lobby server to a new version at the same time
• Its anticompetitive
• Say I implement a basic lightweight lobby server and protocol that was aimed at sitting on top of an existing protocol, say a chat network based on XMPP, how would I do that if I'm forced into the TASSERVER handshake?
• How would one include a ladder system without integrating it directly into Uberserver or Hoijuis Spring Lobby server?
• How would one connect to a statistics server for sending reports etc?

At the moment I fail to see the sandbox model being a justification, since we can already break that using files and external tools and programs. Sockets are unsynced, and if unsynced data sources can introduces desyncs into synced code, then something more fundamental is at fault.

The only thing that holds watertight as a benefit of such an action is the continued survival of the TASSERVER protocol and its benefactors, who stand to benefit from such an enforced handshake, at the cost of development speed and flexibility.

People who would lose out:

• Innovators
  Spring could be used for all sorts of visualisation purposes with sockets and the lua APIs, fancy gadget AIs could be built that learn and report back what they found, libraries that could never be supported before, remote control via other devices, all stifled and limited because of a short sighted choice.
• New lobby protocols, and continued development of the existing protocol are stifled and slowed because of the limiting of progress to the pace set by the current engine release cycle.
• Content developers
  Forced to use only the features they have available, unable to move off of the current platform, stuck with the current lobby system as the only effective means of networking, and being forced to work around with bots for game specific things like the planetwars meta game

[Cheesecan]

If you want security you could use cryptography on a higher layer.

Make some signatures for trusted sources e.g. springdevs and then let lobbies and content ppl get theirs signed.