Topic: [Tech demo] AGS chat client - with source!

[Monsieur OUXX]

Hey Wyz,
The TCP plugin underlying the IRC module is often compared by AGSers to the old TCP/IP plugin.
But the TCP/IP plugin was using mostly integers, and could "listen".
Your plugin uses Strings, and I only saw instructions to connect to a host (and process its answers).

So, do you think your plugin is suitable for an AGS-based server, meant to process something else that \r\n strings?

[wolverine79936]

Actually, I have a very similar question to OUXX... The server. Does it have to be simplistic like IRC, or could a server be written in AGS? I have an old, old idea about using PennMUSH as the server to a game idea of mine but was never able to get the old TCP/IP plugin to connect to it properly.

[Moox]

Without looking at the code, does the plugin allow for the client to join multiple channels simultaneously? As in, could the player be in one channel for chat and another for behind the scenes instructions, etc...?

[Wyz]

Apologies fro my late reaction.
Yes my plugin is capable of both listening and connecting TCP sockets and UDP as well only I might have forgot to implement SentTo and RecvFrom  . I keep telling people that I want to rewrite it, but it is hard for me to find a free time slot to do so. I basically threw together this plugin in two days or so and never really optimized it. Well I still want to do it, and eventually I will.

As for servers in AGS, well there are some advantages using a stand alone server; it depends on how many connection you want it to have. If you want something like four play multi-play and both the client and server be part of the same structure then the plugin will cope. For MMO type of stuff obviously not; a stand alone server that can take advantage of threading will be a much better solution.

I guess the plugin is not binary safe at this moment; well actually only '\0' (the null character) will fail because of the way c-strings work. This will require additional function like reading from and to arrays. I can definitely see that happen in the future.

The Tech-demo is hard coded to only work for two channels but I've been working on a module that allows multiple channels. The only real struggle I have there is AGS' lack of doing callbacks. I want AGS to call certain functions when messages arrive but I've yet to find an elegant way of doing this.

[Moox]

As it interfaces with IRC textually, wouldn't it be possible to make the client dumb and have some calculations performed by a custom IRC bot? That would certainly reduce some strain.

[wolverine79936]

The only real struggle I have there is AGS' lack of doing callbacks. I want AGS to call certain functions when messages arrive but I've yet to find an elegant way of doing this.

Just a silly idea, Wyz, but couldn't we hack the AGS source code? It is available. I forgot where I found it but it was somewhere under the downloads section.

I was already thinking about attempting to hack my own networking directly into the engine and use PennMUSH for the server after some hacking on that source code as well. I love open source.

Sorry for pushing the PennMUSH link so much, but lately when I ask, nobody seems to remember text-only gaming.

[icey games]

I was thinking the same thing but I didn't think it was possible so I didn't post the question.

[Wyz]

I'm working on a new version of the sockets plugin and I'm half way there. It will support binary data as opposed to strings, is threaded, ipv6 ready and can handle UDP and both listening and connecting TCP. It can potentially support even more protocols since I intend to wrap BSD sockets as tight as possible but that will probably never be used.

In simpler words: I'm making a new plugin to add networking capabilities to AGS that is both more stable and efficient as the previous one I made. It can be used to access websites, files, mail and IRC among others. Those will not come in the package but will be available as modules in the future.

[wolverine79936]

Nice, Wyz.

The server I was thinking about using was a MUD server. SImple telnet protocol. I just have to figure out how to get AGS to read what comes up from the server and translate it into rooms and such.

[Crimson Wizard]

Quite late to make this reply, anyway, couple of notes -

The only real struggle I have there is AGS' lack of doing callbacks. I want AGS to call certain functions when messages arrive but I've yet to find an elegant way of doing this.

JJS recently mentioned he wants to invent an event system in AGS. I am not sure about details. But plugin interface is a bit limited IMO. Probably you might start some discussion on how it may be developed further to provide more freedom for plugin-writers?
We are also putting some utility classes into use, like Stream, String, etc. There's yet a problem of maintaining backwards compatibility, that's the reason we cannot change parameter types in plugin interface members, like FILE pointer to Stream; some solution has to be found there.

Just a silly idea, Wyz, but couldn't we hack the AGS source code? It is available. I forgot where I found it but it was somewhere under the downloads section.

If you are still interested, AGS engine is being actively developed by JJS for quite a while now (he does ports to other platforms as well as adding ability to run games made by older versions) and I was doing code clean-up since June; now we are finally up to merging our versions into one branch. FYI our AGS code may be found here: https://github.com/adventuregamestudio. You may use Git to make your own personal copy and do whatever you like with that (just a hint).
Regarding adding networking to AGS, that may be an interesting feature request. I just wonder what other people would say about this. Will this be appropriate addition to the engine, or should rather be made as a plugin? After all, networking is not so common for adventure games...

[Wyz]

@ wolverine79936
That can done with the current plugin since telnet uses TCP these days. The are however a lot of characters in the protocol that are not human-readable so that might be a challenge.

@ Crimson Wizard
Yes, I really wish I could get involved but I'm still pretty busy. An event system that is also exposed to the scripting language would really be nice; they simply have to be functions that are stored in a special lookup table. You know what; I'll make a proposal for a system and post it on the forums so people can discuss.
I don't think utility classes are really needed; object orientated programming is nice but is very error prone when trying to export it to an external library like a DLL. There however a number of changes I really could use for the plugin API, also to make it a bit more portable. It's a bit frustrating that things are finally in motion and now my schedule filled up.
I agree; networking in adventure games is too much of a niche to validate networking support by default. I do hope that in the future plugins can also be linked statically; I actually prepare my future plugins for that. The socket plugin also supports linux btw.

On a different note: the new version of the plugin is nearing completion. I will let you know when it goes beta.

[JJS]

About static-linking plugins: the refactored engine can do this. Plugins still communicate over their normal interface but they are linked into the engine. This is simply done by putting them into their own namespace and binding the function calls in the plugin loading code of the engine.

This is necessary for platforms that don't support shared libraries, e.g. non-jailbroken iOS.


E: There is already an event system in place. The plugins can register a notifier for different events. All that is needed is generalizing this so that events can be fired to in-engine functions.

[Wyz]

About static-linking plugins: the refactored engine can do this. Plugins still communicate over their normal interface but they are linked into the engine. This is simply done by putting them into their own namespace and binding the function calls in the plugin loading code of the engine.

Splendid, good to know!

E: There is already an event system in place. The plugins can register a notifier for different events. All that is needed is generalizing this so that events can be fired to in-engine functions.

Well yes but is it also exposed to the scripting language? I need this support for modules mainly; I was already achieving event like functionality with the plugin interface but good to know there is a dedicated system now!

[Radiant]

The links are down. Can anyone do a re-upload please?