next »

[Courgette]

I found that interesting post regarding game events : http://altitudegame.com/forums/showthread.php?p=40077

[WickedShell]

Finally got a chance to install this and test it Pretty good so far! (And now I know how to follow that/implement a parser next time) So thanks for the work so far 

So a couple of things some I can fix in the code, some I'm posting here as I don't have any good solutions. (And I need a pointer as to where I should start looking on one of them).

The biggets issues I've had have to do with starting B3 up while the server is already running/people are connected, then restarting B3. The first issue is that any players already connected when b3 starts are ignored as they are not authenticated. I'm pretty sure I can work this one out.

Bigger issue is that when B3 closes it automatically clears out the command file, as the server never does this. The problem with this is that if the server stays up after B3 restarts at least once it makes the server lose its ability to read the log file. This is a significant issue as it requires the altitude server to restart in parallel with the bot (and before the bot). This one I'm not so sure about, as this is more of a design issue. At this point in time I suspect it may be better not to do this, and to have it be a server admin's job to do the rotation as I don't see anyway to work around this. Really the solution would be to get true RCON support but that doesn't exist yet.

Status plugin and XLRstats both don't work out of the box with the parser (not to suprising). Status is having an issue with object typing, while XLRstats keeps getting nulls in it's query string... I think I can chase these both down, but if there are any pointers as for where to start looking I'm all ears. The xlrstats one I believe to be related to the parser switching back and forth with bad player id's (The parser seems to sometimes load people (registered and unregistered) as @0 which is a problem)

Status's Error;

Code:

110530 22:49:00 VERBOSE StatusPlugin: Building XML status
110530 22:49:00 ERROR   Error executing crontab <bound method StatusPlugin.update of <b3.plugins.status.StatusPlugin instance at 0x1d20dd0>>: 'int' object has no attribute 'replace'
[('/home/alt1v1/b3/cron.py', 276, 'run', 'c.run()'), ('/home/alt1v1/b3/cron.py', 210, 'run', 'CronTab.run(self)'), ('/home/alt1v1/b3/cron.py', 66, 'run', 'self.command()'), ('/home/alt1v1/b3/plugins/status.py', 283, 'update', 'self.writeXML(xml.toprettyxml(encoding="UTF-8", indent="        "))'), ('/usr/lib/python2.6/xml/dom/minidom.py', 57, 'toprettyxml', 'self.writexml(writer, "", indent, newl, encoding)'), ('/usr/lib/python2.6/xml/dom/minidom.py', 1749, 'writexml', 'node.writexml(writer, indent, addindent, newl)'), ('/usr/lib/python2.6/xml/dom/minidom.py', 817, 'writexml', 'node.writexml(writer,indent+addindent,addindent,newl)'), ('/usr/lib/python2.6/xml/dom/minidom.py', 817, 'writexml', 'node.writexml(writer,indent+addindent,addindent,newl)'), ('/usr/lib/python2.6/xml/dom/minidom.py', 812, 'writexml', '_write_data(writer, attrs[a_name].value)'), ('/usr/lib/python2.6/xml/dom/minidom.py', 301, '_write_data', 'data = data.replace("&", "&amp;").replace("<", "&lt;")')]

XLRstats Error;

Code:

110530 21:52:41 CONSOLE {"port":27278,"time":1557091,"streak":1,"source":"plane","player":1,"victim":0,"multi":1,"xp":10,"type":"kill"}
110530 21:52:41 VERBOSE Queueing event Client Kill (100, u'plane', None)
110530 21:52:41 VERBOSE Parsing Event: Client Kill: XlrstatsPlugin
110530 21:52:41 VERBOSE XlrstatsPlugin: ----> XLRstats: WickedShell Killed @0 (kill), checking for assists
110530 21:52:41 ERROR   handler XlrstatsPlugin could not handle event Client Kill: OperationalError: (1054, "Unknown column 'None' in 'where clause'") [('/home/alt1v1/b3/parser.py', 937, 'handleEvents', 'hfunc.parseEvent(event)'), ('/home/alt1v1/b3/plugin.py', 157, 'parseEvent', 'self.onEvent(event)'), ('/home/alt1v1/b3/extplugins/xlrstats.py', 474, 'onEvent', 'self.kill(event.client, event.target, event.data)'), ('/home/alt1v1/b3/extplugins/xlrstats.py', 877, 'kill', 'victimstats = self.get_PlayerAnon()'), ('/home/alt1v1/b3/extplugins/xlrstats.py', 540, 'get_PlayerAnon', 'return self.get_PlayerStats(None)'), ('/home/alt1v1/b3/extplugins/xlrstats.py', 509, 'get_PlayerStats', 'cursor = self.query(q)'), ('/home/alt1v1/b3/storage.py', 302, 'query', 'raise e')]

[Courgette]

The biggets issues I've had have to do with starting B3 up while the server is already running/people are connected, then restarting B3. The first issue is that any players already connected when b3 starts are ignored as they are not authenticated. I'm pretty sure I can work this one out.

in theory, the minimum information you need to create a B3 Client object is the cid (which is a match wide identifier). Such a client is not authenticated and cannot be recognized against the B3 database. No command can be used, etc. For games where cid is the slot id and having rcon commands accepting slot id, it can be useful to have Client objects created as early as possible, but it is only really useful if we also know the players' names because most B3 commands accept a partial player name as a parameter.
Then, you need to get some game wide identifier to authenticate these clients. Most games provide some kind of guid or Punkbuster id. This means you need a game log line that allows you to associate a guid to a cid.
So the minimum info I give myself before creating a B3 Client is : cid + player name

For game that do not accept cid for rcon commands, then it is not that useful to create B3 Client object that early, and this can be delayed until we know the guid + name.

When B3 starts up on a already running game server, it is command to send a rcon command that list the current connected player names with their guid (ideally) so B3 can create all Client object right away. Games that do not provide such a command are doomed to see B3 ignore these players until they reconnect.

Bigger issue is that when B3 closes it automatically clears out the command file, as the server never does this. The problem with this is that if the server stays up after B3 restarts at least once it makes the server lose its ability to read the log file. This is a significant issue as it requires the altitude server to restart in parallel with the bot (and before the bot). This one I'm not so sure about, as this is more of a design issue. At this point in time I suspect it may be better not to do this, and to have it be a server admin's job to do the rotation as I don't see anyway to work around this. Really the solution would be to get true RCON support but that doesn't exist yet.

I chosen to do so because not clearing the command file is worst IMHO as the server would re-execute all commands upon restart (including kick, etc)

Status is having an issue with object typing

maybe check that attrs[a_name].value is not None before using it

while XLRstats keeps getting nulls in it's query string...

probably because a kill event require two B3 Client objects : attacker and victim. If the bot was started while players were connected, then the parser is unable to form a full kill event

[WickedShell]

in theory, the minimum information you need to create a B3 Client object is the cid (which is a match wide identifier). Such a client is not authenticated and cannot be recognized against the B3 database. No command can be used, etc. For games where cid is the slot id and having rcon commands accepting slot id, it can be useful to have Client objects created as early as possible, but it is only really useful if we also know the players' names because most B3 commands accept a partial player name as a parameter.
Then, you need to get some game wide identifier to authenticate these clients. Most games provide some kind of guid or Punkbuster id. This means you need a game log line that allows you to associate a guid to a cid.
So the minimum info I give myself before creating a B3 Client is : cid + player name

That's about what I figured, once again I remembered the listPlayers command, then realized again that it doesn't put the output in the terminal, it only displays it in the console... I gotta start rememering that...

I chosen to do so because not clearing the command file is worst IMHO as the server would re-execute all commands upon restart (including kick, etc)

I definetly agree that it's a terrible decision as it makes it confusing. But as far as I can tell from viewing the log after restarting altitude it does not reparse the entire command file, it only does new commands, which makes it a tad bit better. As I said I'm not sure if this is a big issue once in a stable deployment enviorment, but when frequently restarting B3 to test things I found it terribly frustrating.

The status problem is actually that it has a type int and is looking for an attribute called replace, but I'll take a look at that spot for types to look at.

With XLRstats it was both connected players, and both connected post B3 restart. (Unless it lost them). In the same log file though you can also see people get kills that don't cause a problem in xlrstats. I'll take a look though. (Haven't looked under the hood of xlrstats really yet, past the signature generator as that was intresting)