Server Help :: View topic - ASSS vs Python(bugs) vs C++ vs merv vs TWCore vs Java

Server Help

Bot Questions - ASSS vs Python(bugs) vs C++ vs merv vs TWCore vs Java

Gus. - Tue Dec 06, 2005 12:10 am
Post subject: ASSS vs Python(bugs) vs C++ vs merv vs TWCore vs Java

Let the battle begin

Bak - Tue Dec 06, 2005 12:40 am
Post subject:

I'd make you an ASSS plugin for it, any chance you're using ASSS?

Gus. - Tue Dec 06, 2005 1:01 am
Post subject:

nope. we arent using any asss at this time.

Anonymous - Thu Dec 08, 2005 7:10 am
Post subject:

Hey BaK. I noticed you'd prefer coding a lot of your stuff for as3 instead of merv. Why is that? Don't you know Merv pretty well?

Bak - Thu Dec 08, 2005 10:16 am
Post subject:

yeah... think of it this way

If I was making a movie I'd release it on DVD not VHS, even though I might now how to do it on VHS.

ASSS is the future, no sense in fighting it.

Dr Brain - Thu Dec 08, 2005 10:50 am
Post subject:

And for anything more complicated than ?helloworld, it's easier to make things with ASSS.

Agurus - Thu Dec 08, 2005 12:33 pm
Post subject:

ASSS isn't very stable for large zones, despite it's amazing features it isn't worth the unstability.

D1st0rt - Thu Dec 08, 2005 12:41 pm
Post subject:

It's good enough for Hockey Zone, and I wouldn't consider them a small zone. It's not unstable if you know what you're doing and don't have buggy modules.

Anonymous - Thu Dec 08, 2005 2:26 pm
Post subject:

Then mabye I need to ditch merv and enter the future, ASSS.

Muskrat - Thu Dec 08, 2005 2:28 pm
Post subject:

Go for it. 'Unstability' issues are in subgame+bots to, as you should well know, Ag.

Cerium - Thu Dec 08, 2005 2:36 pm
Post subject:

*sendto for the win.

Gus. - Thu Dec 08, 2005 6:16 pm
Post subject: Re: Looking for a custom plugin.

Gus. wrote:

Do you know of a plugin that simply does this. i need a plugin of it or one made. Im asking this on behalf of Servitude of SSDC Aftermath.

OK we need a 4 freq, kill counter, like at the certain number of kills u win. and, theres an adjustable ini for the kills. maybe with a score counter for a higher game

Anonymous - Thu Dec 08, 2005 6:35 pm
Post subject:

Muskrat wrote:

Go for it. 'Unstability' issues are in subgame+bots to, as you should well know, Ag.

lol

Bak - Thu Dec 08, 2005 6:51 pm
Post subject:

D1st0rt wrote:

It's not unstable if you know what you're doing and don't have buggy modules.

You don't even need to be a perfect coder or know what you're doing, just use python.

Quote:

ASSS isn't very stable for large zones

Hockey Zone was already mentioned, but I just want to add that HZ handles over 100 people at a time on daily basis.

Cyan~Fire - Thu Dec 08, 2005 7:00 pm
Post subject:

Yep, I spent weeks on a MERV upgrade (I was going to call it SALT, if anyone gets it), but decided to drop it since I'm asss all the way.

Anonymous - Thu Dec 08, 2005 7:19 pm
Post subject:

Okay. Its offical then. Im going to look into ASSS. C looks harder to learn than C++ though. Python seems cool, but I heard its only good for making quick modules.

Agurus - Thu Dec 08, 2005 7:51 pm
Post subject:

bleh HZ got lucky

Bak - Thu Dec 08, 2005 9:12 pm
Post subject:

pythons limitations are that you can't create interfaces with it and it only supports a (large) subset of the functions you can use in C. And there are workarounds for the functions it doesn't support.

In one example I wanted to perform an action whenever a player fired a bomb. Since there is no callback for this, the way I would do it in C is to use net->addPacket for C2S_Position and examine the packet to check if the player is firing a weapon. Since function pointers don't translate well to python, this was not possible (indeed you couldn't even attempt to use the funtion from the net interface in python). The solution (hack) I came up with was to, rather than recompile pymod with a new callback, use a c module to perform the necessary logic, and issue a callback python can use (I chose CB_CHATMSG with a unique mode that identified this as a bomb callback (normalled CB_CHATMSG uses modes 0-12, so I used 13)). If you want to see the source for this module, it's attached.

Anyhoo, most of the limitations of python can be eliminated by creating simple C modules (which if you find a way to crash the server with them, you should be shot).

Dr Brain - Thu Dec 08, 2005 11:50 pm
Post subject:

Ew? That's a gross hack.

What happens when everyone else uses your idea and starts filling the CB_CHATMSG with random numbers? eventually you'll get overlap and BOOM, two entirely seperate modules no longer work together. It'd be a pain in the ass to find, too.

Bak - Fri Dec 09, 2005 12:04 am
Post subject:

the idea is only use one pyhack module at a time, but you're right, it is a terrible hack. I suppose you could fill the message part of the data with the name of the module you intend it to be used for, or better yet the type of callback that it is. That would prevent the problem you proposed.

At any rate, it looks like when grel creates "dynamic interfaces and callbacks for python" as his bug tracking system says he's working on, this problem will go away and you'll be able to just use regular callbacks for this sort of thing.

BlueGoku - Fri Dec 09, 2005 12:53 am
Post subject:

Agurus wrote:

bleh HZ got lucky

How so?

D1st0rt - Sat Dec 10, 2005 4:15 pm
Post subject:

Agurus just because you can't get it to work doesn't mean that other people can't

Gus. - Sun Dec 11, 2005 3:58 am
Post subject:

New topic name for you all. <3

Cyan~Fire - Sun Dec 11, 2005 12:24 pm
Post subject:

Everybody who does not accept that ASSS is better than bots is just afraid of new technology.

BDwinsAlt - Sun Dec 11, 2005 2:55 pm
Post subject:

poor TWCore is being left out.

Gus. - Sun Dec 11, 2005 5:33 pm
Post subject:

Once someone makes a decent point that gives TWCore a reason to be in the battle i will edit him in.

Bak - Sun Dec 11, 2005 5:50 pm
Post subject:

java is easy to code in

Cerium - Mon Dec 12, 2005 12:29 am
Post subject:

Its the only java core that has bots already developed.

Grelminar - Mon Dec 12, 2005 2:49 am
Post subject:

Bak wrote:

This should really be in another section, but oh well.

I am indeed disgused by that hack. You're already compiling another C module, so why not write up a little header file for the callback you want to define, stick it in some directory, and then rebuild pymod to pick up the new definition? I realize that procedure is annoying, and far from optimal, but surely it's better than overloading another callback like that.

Anyway, I might as well use this opportunity to get some feedback on my ideas. My solution for this particular problem would be something along these lines: you'd write a header file (foo.h) with pycb and pyint declarations, just like the standard ones, but then you'd run pymod-process on it (actually, you'd write a makefile rule to do it), and it would generate a new module: pyglue_foo, that when loaded, would provide python code access to your new callbacks and interfaces. The difference would be that you don't have to recompile pymod yourself. The downside is that there's an extra module to deal with. It might be possible to add some extra magic to auto-load that module whenever it's needed. Of course, then there's extra magic to deal with.

Unfortunately, because of how the python interface is currently structured, there's not much hope for exposing new callbacks and interfaces between C and python without writing a header file, generating some code, and compiling it into a module. That module might not be pymod itself, though. On the bright side, there's considerably more hope for callbacks/interfaces that go between python modules only, not touching C.

Comments? Questions?

By the way, it wouldn't be that hard to add support for real packet callbacks to python. I haven't done it because of efficiency concerns (I don't want python in the fast path for position packets), and because I was hoping to keep the interface higher-level. That is, it should be possible to do everything you would want to do without handling raw packets in python, although it may require creating more callbacks, like a general position packet callback. I think I'd rather do that, then expose raw packets. So if a position packet callback would be useful, please request that too.

Bak - Mon Dec 12, 2005 4:33 am
Post subject:

I would like a player position callback.

Cerium - Mon Dec 12, 2005 10:45 am
Post subject:

I would like you to stop using multiple identifiers for the same purpose.

IE:
- ? and * for the same commands
- Char 10 and 13 for packet delimiters in chatnet.

=(

Muskrat - Mon Dec 12, 2005 12:05 pm
Post subject:

* is only used in the sgcompat module...

Grelminar - Tue Dec 13, 2005 3:31 pm
Post subject:

Bak: Ok, I noted it as a feature request. But no comments about the other stuff? You're allowed to say "both of those options suck" (although that doesn't mean anything will change).

Cerium:
If I could get rid of * for commands, I would, but that's a question of backwards compatibility.

As far as chatnet delimiters, I consider that an instance of the well-accepted principle of network communications: be liberal in what you accept, be conservative in what you produce. asss itself will always produce line feeds (10s), so that's all you have to accept, if you want. And you can write your code to produce just line feeds also. Overall, no more complex code than if I just picked one.

And accepting both means I can telnet to the chatnet port, log in, and hold a conversation, without any client.

Bak - Tue Dec 13, 2005 3:43 pm
Post subject:

Adding real packet support would be useful, if it's not too hard to do. Although for something like player position packets it would slow down the execution significantly, the capability could be useful for other packets. I would suggest putting a note near the function that says to use it conservatively in python and a short reason. Let the programmer shoot themselves in the foot if they want to.

As for the pyglue solution, it's better than recompiling pymod, but still not ideal. I'll need to look more into how pymod works before I can suggest a better alternative.

Cerium - Tue Dec 13, 2005 4:35 pm
Post subject:

Grel, for the most part I was just giving you shit, as I dont use ASSS or chatnet primarily. Though, the little work I have done with them, I noticed those quirks and I found it to be somewhat annoying.

Anyway:
Why even have hardcoded/designated command characters? Why not let modules/command classes/whatever decide how to determine what a command is by processing the message directly, or by registering a prefix with the command manager or such.
Besides, the '?' is so 1997.

With ChatNet, it bothered me because when I was processing the stream, I was left wondering how exactly you broke up the packets. Did you use a system-defined line break character/variable, or did you specify 10 or 13 (or both)? Should I expect it to change from system to system? What about the bit of overhead to check and dismiss empty packets resulting from doubled up delimiters? How about fubar'd data from a missed/skipped delimiter?
I eventually decided to default to 10 and provided a function to toggle it, banking on the assumption that you didnt use both. Maybe next time Ill just ask you.

Grelminar - Wed Dec 14, 2005 12:52 am
Post subject:

Cerium: it's better for users for there to be some consistency between what is interpreted by the server and what gets sent in pub chat. I wouldn't want to use a server where stuff I typed in the chat box may or may not get sent to the rest of the arena, depending on what set of modules happen to be loaded.

I thought the protocol was pretty clear as far as delimiters go: either 10 or 13 or any combination of those can end a message.

Cerium - Wed Dec 14, 2005 1:51 am
Post subject:

Well it pretty much goes without saying that commands should follow some kind of uniform definition, but what if I want to use a ! in my zone, or even ? for player commands, * for admin commands and ! for arena-specific commands? Even newbie developers will use (mostly) the same syntax for their commands.

Indeed, I read the protocol and got 99% of my chatnet knowledge from it. But whats wrong with a simple null character? or even always using 10 OR 13, not both? Why leave it so open ended and force the clients to add some unnecessary overhead to properly parse packets? I dont see why you use these dynamics in a communications protocol but not in something like the command manager; seems backward imo.

Mine GO BOOM - Wed Dec 14, 2005 2:05 am
Post subject:

Cerium wrote:

add some unnecessary overhead to properly parse packets

Keep reading bytes until:
curByte == 0x10 || curByte == 0x13
Then, check next byte. If same, move pointer ahead one. Else, its a new command to parse.

Wow, very hard. In fact, most scripting languages have line-parsers built into them that will correctly handle 10/13/both endings of lines in strings. Null characters are awkward to do with a telnet client, and adding in simple support of spliting lines via 10/13/both in a programming tool is dead simple.

In the beginning, Grel wanted all commands to be ? only. But, because ASSS wouldn't be a night-day swap for all zone admins, he had to deal with the fact most admins and bots used * and wouldn't be very easy to change around. Having different sets of commands, where ?arena does one thing, *arena does another, and under your suggestion, !arena can do a third, it becomes annoyingly complex. It is easier to just state that all commands are done via ?, but we need the * to allow people to transfer over to ASSS.

IRC, Battlenet, etc, they all work where every command begins with a / in front. I don't see a need to have more command symbols than is needed. ! only came around because bots needed a command symbol that servers would not strip away. Let ! die with the bots.

Cerium - Wed Dec 14, 2005 2:58 am
Post subject:

I never said it was hard, but its literally twice the work necessary if the other end is only using 0x13. Im very nazi-ish when it comes to wasting instructions when you dont/shouldnt need to.
To be honest though, I never saw chatnet as a protocol for telnet clients, despite all the signs, nor did anyone else Ive had this discussion with. I guess if thats what the intention for chatnet is I can just accept it for what it is, but meh, whatever.

Thats stupid. If some zone wants to use 18 tildes for their command prefixes, why stop them? Obviously they have a reason to want to set it up that way, be it preference or mental retardation. If I were to setup a zone, it would probably be setup how I described above. I find it to be more organized, and would probably make setting up player access easier.

Dr Brain - Wed Dec 14, 2005 9:40 am
Post subject:

Cerium wrote:

Thats stupid. If some zone wants to use 18 tildes for their command prefixes, why stop them? Obviously they have a reason to want to set it up that way, be it preference or mental retardation. If I were to setup a zone, it would probably be setup how I described above. I find it to be more organized, and would probably make setting up player access easier.

If some zone wants to do that, then there's nothing stopping them from adding an 18 tilde command prefix, or just checking incoming chat packets.

I prefer the current system. I'd rather not specify that I want both *shipstatus and ?shipstatus.

Cyan~Fire - Wed Dec 14, 2005 12:59 pm
Post subject:

Cerium wrote:

Im very nazi-ish when it comes to wasting instructions when you dont/shouldnt need to.

Are you kidding me, Mr. Java?

Cerium - Wed Dec 14, 2005 7:45 pm
Post subject:

Cyan~Fire wrote:

[..]

Are you kidding me, Mr. Java?

Hah! Zing.