| 00:00.58 | jeffm | wonder what the time to connect to the db file is |
| 00:04.14 | *** join/#bzflag blast007 (~blast007@bzflag/developer/Blast) |
| 00:04.14 | *** mode/#bzflag [+v blast007] by ChanServ |
| 00:04.18 | *** join/#bzflag cods (~cods@tuxee.net) |
| 00:04.22 | *** join/#bzflag McYukon (~McYukon@204.11.62.10) |
| 00:04.26 | blast007 | I don't think that's an issue |
| 00:04.50 | *** join/#bzflag rathis (~rathis@b01bd9ce.bb.sky.com) |
| 00:05.00 | *** join/#bzflag Marzipan (~Marzipan@sign-4db6b345.pool.mediaWays.net) |
| 00:05.30 | blast007 | the actual connect is just done when the plugin initializes |
| 00:06.17 | blast007 | well, by connect I mean file open, since it's not a network socket ;) |
| 00:09.15 | jeffm | and it leaves it open? I was thinking it could be slow if they try to reopen on each event |
| 00:09.37 | allejo | opened on init() and closed on cleanup() |
| 00:09.38 | *** join/#bzflag lvlinux (~n1gg@c-50-142-165-230.hsd1.tn.comcast.net) |
| 00:11.31 | jeffm | well with mysql the writes would be done in another thread and be async to the bzfs process |
| 00:11.41 | jeffm | unless you are just writing way too much data |
| 00:12.12 | jeffm | bzfs itself doesn't use much disk access, so if it happened in another thread it should not affect the app |
| 00:12.49 | jeffm | but with SQLlite then it's going to do the writes in the bzfs thread during the calls to the lib |
| 00:17.06 | allejo | hmm.. hadn't thought about it that way |
| 00:17.32 | jeffm | you want your events to take as little time as possible in the plugin |
| 00:17.48 | jeffm | you could run your sqllite in a thread and pass the event messages do it |
| 00:18.29 | jeffm | but as for diskIO another process should be able to thrash the disk with out bzfs changing speed much, so long as you aren't in swap and there are enough resources for CPU and net sockets |
| 00:21.45 | jeffm | hmm looks like you'd have to compile sqlite with -DTHREADSAFE=1 |
| 00:22.03 | jeffm | but you may only need to do that if you have more then one thread using it at a time |
| 00:25.25 | blast007 | my suggestion was to just pass stuff off to a web application |
| 00:25.43 | blast007 | keep the plugin pretty stupid and have all the real work in the site |
| 00:25.43 | jeffm | yeah |
| 00:25.56 | jeffm | that'd do the same type of thread offloading |
| 00:26.23 | jeffm | I've noticed problems when I've tried to do long computations in event calls |
| 01:00.04 | *** join/#bzflag makos (~makos@rrcs-97-78-189-66.se.biz.rr.com) |
| 02:01.10 | allejo | sorry i stepped out for a bit. depending on how much of the resources are used after i finish rewriting a few stuff, i'll go for the mysql and url job approach |
| 02:01.22 | allejo | a few things* |
| 02:10.46 | jeffm | that is the most scaleable method |
| 03:06.45 | jeffm | Constitution, mouse works fine for me |
| 03:18.50 | *** join/#bzflag L4m3r_ (~l4m3r@bzflag/developer/L4m3r) |
| 03:18.50 | *** mode/#bzflag [+v L4m3r_] by ChanServ |
| 03:26.02 | *** join/#bzflag mrapple_ (~tony@204.11.62.10) |
| 03:29.49 | *** join/#bzflag khonkhortisan (~kyle@c-76-121-156-73.hsd1.wa.comcast.net) |
| 03:38.32 | Constitution | jeffm: is it any different as far as you can tell? |
| 03:38.45 | jeffm | nope |
| 03:38.53 | Constitution | it worked okay for me too but just felt a little sluggish for some reason |
| 03:39.05 | jeffm | felt snappy to me |
| 03:39.43 | jeffm | was your FPS any lower then normal? |
| 03:47.30 | Constitution | nope, the same |
| 03:47.49 | Constitution | could just be in my head, I suppose |
| 03:51.30 | jeffm | well I got blowed up and was unable to dodge on mofo just like normal, so it seemed the same to mee |
| 04:28.09 | *** join/#bzflag khonkhortisan (~kyle@c-76-121-156-73.hsd1.wa.comcast.net) |
| 04:39.23 | *** join/#bzflag ts3d (~ab@unaffiliated/ts3d) |
| 04:40.19 | Delusional | Old Grand-Dad Kentucky Straight Bonded Bourbon Whiskey |
| 04:40.52 | Delusional | woop ww |
| 05:11.24 | *** join/#bzflag swigg (~swigg@nsc69.38.101-238.newsouth.net) |
| 05:11.25 | *** join/#bzflag swigg (~swigg@bzflag/player/Swigg) |
| 05:15.45 | *** join/#bzflag Deadalot (~philb@fl-67-232-195-126.dhcp.embarqhsd.net) |
| 05:21.27 | *** join/#bzflag ts3d_ (~ab@99-43-11-24.lightspeed.mtryca.sbcglobal.net) |
| 05:24.52 | *** join/#bzflag macsforme (~josh@bzflag/developer/Constitution) |
| 05:27.44 | *** join/#bzflag cods (~cods@tuxee.net) |
| 05:29.03 | *** join/#bzflag JBdiGriz (~dbw@108-197-33-160.lightspeed.sndgca.sbcglobal.net) |
| 05:31.55 | *** join/#bzflag nielsle (~nielsle@3239149-cl69.boa.fiberby.dk) |
| 05:38.36 | *** join/#bzflag khonkhortisan_ (~kyle@c-76-121-156-73.hsd1.wa.comcast.net) |
| 05:41.03 | *** join/#bzflag nielsle_ (~nielsle@3239149-cl69.boa.fiberby.dk) |
| 05:49.54 | *** join/#bzflag allejo_ (~allejo@li59-174.members.linode.com) |
| 05:50.32 | *** join/#bzflag mdskpr_ (~quassel@li59-174.members.linode.com) |
| 05:51.47 | *** join/#bzflag khazhyk (~khazhyk@204.11.62.10) |
| 05:52.48 | *** join/#bzflag Fira (artix@unaffiliated/fira) |
| 05:52.48 | *** join/#bzflag khazhyk (~khazhyk@bzflag/player/Me1) |
| 05:54.31 | *** join/#bzflag allejo (~allejo@unaffiliated/allejo) |
| 05:54.33 | *** join/#bzflag Deadalot (~philb@fl-67-232-195-126.dhcp.embarqhsd.net) |
| 05:55.12 | *** join/#bzflag AAA_awright (~aaa@69.72.216.27) |
| 05:56.49 | *** join/#bzflag khonkhortisan_ (~kyle@c-76-121-156-73.hsd1.wa.comcast.net) |
| 05:56.49 | *** join/#bzflag JBdiGriz (~dbw@108-197-33-160.lightspeed.sndgca.sbcglobal.net) |
| 05:56.49 | *** join/#bzflag Chestal (~thilo@141.99.42.43) |
| 05:56.49 | *** mode/#bzflag [+o Chestal] by calvino.freenode.net |
| 06:03.35 | *** join/#bzflag mebigfatguy_ (~dave@38.102.19.7) |
| 06:09.55 | *** join/#bzflag runde (~terje@cpe-75-80-168-176.san.res.rr.com) |
| 06:13.17 | Guest94004 | Sorry. |
| 06:13.19 | *** part/#bzflag Guest94004 (~terje@cpe-75-80-168-176.san.res.rr.com) |
| 06:24.59 | *** join/#bzflag mdskpr (~quassel@li59-174.members.linode.com) |
| 11:38.36 | *** join/#bzflag ibot (~ibot@rikers.org) |
| 11:38.36 | *** topic/#bzflag is http://BZFlag.org || https://www.ohloh.net/p/bzflag || http://wiki.BZFlag.org/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || 2.4.2 is the current version |
| 11:38.36 | *** mode/#bzflag [+o ibot] by ChanServ |
| 11:59.09 | *** part/#bzflag alezakos (~kongr45gp@unaffiliated/alezakos) |
| 12:04.00 | *** join/#bzflag alezakos (~kongr45gp@unaffiliated/alezakos) |
| 12:18.21 | *** join/#bzflag dcat (~dcat@c-98-244-106-246.hsd1.va.comcast.net) |
| 13:03.11 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 13:03.12 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 13:22.08 | *** join/#bzflag ashvala (~ashvala@unaffiliated/ashvala) |
| 13:29.30 | ashvala | Does anyone here have an executable of the Text Tool? |
| 13:30.29 | blast007 | ashvala: I could, I think |
| 13:32.27 | ashvala | Cool. |
| 13:32.51 | ashvala | blast007: let me know when I can acquire a copy. ^^ |
| 13:32.54 | ashvala | please. :p |
| 13:33.21 | blast007 | hmm, error building ;) |
| 13:35.56 | ashvala | ouch. :p |
| 13:37.46 | blast007 | think it needs to link to zlib |
| 13:52.35 | *** join/#bzflag delusional_ (~delusiona@pool-108-17-117-49.pitbpa.fios.verizon.net) |
| 13:52.36 | *** join/#bzflag delusional_ (~delusiona@unaffiliated/delusional) |
| 13:55.06 | *** join/#bzflag allejo_ (~allejo@li59-174.members.linode.com) |
| 13:55.27 | *** join/#bzflag L4m3r_ (~l4m3r@bzflag/developer/L4m3r) |
| 13:55.27 | *** mode/#bzflag [+v L4m3r_] by ChanServ |
| 13:55.31 | blast007 | ashvala: http://static.bzexcess.com/downloads/TextTool.exe |
| 13:55.42 | ashvala | ooh thanks! :D |
| 13:56.04 | blast007 | I think there's some things you need to do to make it work right, like possibly disabling font smoothing on your system |
| 13:56.42 | blast007 | it is possible to manually create the font textures, though it'd be a bit tedius |
| 13:57.23 | blast007 | they're just PNG files and a text file describing the glyphs |
| 13:59.58 | ashvala | I wrote a python script on node box to generate the pngsā¦ Need to work on the text file. :S |
| 14:02.37 | blast007 | 2.99.x has a font system that just uses TTF files. It makes use of FTGL. |
| 14:04.20 | ashvala | ah okay. |
| 14:04.23 | *** join/#bzflag Fira (artix@unaffiliated/fira) |
| 14:07.46 | *** join/#bzflag dcat (~dcat@c-98-244-106-246.hsd1.va.comcast.net) |
| 14:08.20 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 14:21.44 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 14:37.36 | *** join/#bzflag Admirarch (~Athelthra@mrush.mth.abdn.ac.uk) |
| 14:41.17 | *** join/#bzflag blast007_ (~blast007@bzflag/developer/Blast) |
| 14:41.17 | *** mode/#bzflag [+v blast007_] by ChanServ |
| 15:46.11 | *** join/#bzflag jeffm (~jeffm@cpe-76-167-236-199.socal.res.rr.com) |
| 15:46.12 | *** join/#bzflag jeffm (~jeffm@unaffiliated/jeffm2501) |
| 15:46.12 | *** mode/#bzflag [+v jeffm] by ChanServ |
| 16:12.10 | *** join/#bzflag mdskpr (~quassel@li59-174.members.linode.com) |
| 16:24.38 | *** join/#bzflag ashvala (~ashvala@unaffiliated/ashvala) |
| 17:19.07 | *** join/#bzflag Oejet (~Oejet@unaffiliated/oejet) |
| 17:36.20 | *** join/#bzflag swigg_ (~swigg@nsc69.38.101-238.newsouth.net) |
| 18:20.18 | *** join/#bzflag swigg (~swigg@bzflag/player/Swigg) |
| 18:31.00 | *** join/#bzflag contempt (contempt@unaffiliated/contempt) |
| 18:44.34 | *** join/#bzflag allejo (~allejo@unaffiliated/allejo) |
| 19:19.37 | alezakos | Any ideas on why bzadmin will join the server and quit immediately over cron? |
| 19:21.19 | blast007 | does the same thing happen if you run the same command directly at the shell? |
| 19:21.23 | BulletCatcher | bzadmin probably wants to read commands from the standard input. |
| 19:21.57 | blast007 | ah, perhaps -ui stdout would help then? |
| 19:21.58 | alezakos | it's not on my machine, but it does work when you run it from the shell |
| 19:22.10 | alezakos | -ui stdout is already placed |
| 19:22.32 | blast007 | and you're providing the username, password, and server as part of the command line? |
| 19:22.51 | alezakos | yup |
| 19:24.01 | blast007 | what are you trying to do exactly? |
| 19:25.20 | alezakos | I'm trying to help Benfish on his picu & gicu bots, which are supposed to restart every 2 hours or so |
| 19:25.39 | blast007 | why does he need two bzadmin bots? |
| 19:26.07 | blast007 | because technically that's in violation of the list server usage policy (artifically inflating the list position) |
| 19:26.47 | alezakos | I don't know, he uses one of them for logging purposes |
| 19:26.56 | blast007 | using them for logging is silly |
| 19:27.11 | blast007 | bzfs has built-in logging and is also bundled with the logDetail plugin |
| 19:27.17 | alezakos | he just wants to make it clear that he doesn't record pms |
| 19:27.28 | blast007 | meh |
| 19:27.58 | BulletCatcher | It might be easier to modify bzfs to not log them. |
| 19:28.00 | blast007 | he could modify the logDetail plugin then to not output MSG-DIRECT and MSG-TEAM messages |
| 19:28.29 | alezakos | i know, not logging wouldn't be guaranteed then... |
| 19:28.35 | blast007 | so what? |
| 19:28.40 | blast007 | it's a GAME |
| 19:28.57 | jeffm | not logging isn't guaranteed with the bots ether |
| 19:29.05 | jeffm | the end user has no way of knowing what the server is doing |
| 19:30.16 | BulletCatcher | Back to bzadmin via cron, does it successfully log in before it exits? |
| 19:30.30 | alezakos | yup, it does |
| 19:30.53 | alezakos | and no error messages are produced, neither client-side, nor server-side |
| 19:31.12 | blast007 | my suggestion is to stop abusing bzadmin ;) |
| 19:31.37 | blast007 | we have ways to do the logging, and if you need some kind of scheduled command execution, we have the bzfscron plugin |
| 19:32.04 | jeffm | build it debug and attach gdb as part of the cron, see what causes the exit |
| 19:32.43 | BulletCatcher | Something like this ought to log in stay connected: |
| 19:32.44 | BulletCatcher | bzadmin -ui stdout callsign@localhost:5154 "/password 12345" |
| 19:33.05 | alezakos | okay, thanks for the help |
| 19:33.08 | alezakos | I'll tell him |
| 19:33.15 | alezakos | and see what can be done about the ls abuse |
| 19:34.04 | blast007 | we should probably just make observers not count at all when sorting |
| 19:34.35 | jeffm | we should not even send them to the list server |
| 19:34.42 | BulletCatcher | It is nice to know where human observers are. |
| 19:34.55 | blast007 | BulletCatcher: there's no way to differentiate that though |
| 19:34.59 | BulletCatcher | Yeah. |
| 19:36.16 | BulletCatcher | At the next protocol break we could fix that by adding an "I'm not human" flag for bzadmin and solo bots. |
| 19:36.38 | blast007 | I think solo bots are already sent as a RobotPlayer |
| 19:37.00 | jeffm | bzadmin can be used by human |
| 19:37.16 | jeffm | or do you really just want to know about observers using a full client? |
| 19:37.50 | jeffm | bzadmin was created to be used by humans so they can kick/ban with out having to log a full client in |
| 19:38.08 | blast007 | finish SSPs a bit further and finish webAdmin, remove bzadmin ;) |
| 19:38.32 | jeffm | SSPs should be able to chat right now |
| 19:38.51 | blast007 | they can, but they can't join as a player |
| 19:39.19 | blast007 | dunno if we'd want that or not for webAdmin |
| 19:39.22 | jeffm | yeah, they can as observer and thats all bzadmin can do |
| 19:39.32 | blast007 | I mean not even as observer |
| 19:39.41 | jeffm | oh |
| 19:39.41 | blast007 | it makes stuff crash |
| 19:39.41 | jeffm | ahh |
| 19:39.42 | BulletCatcher | For me, the difference between human vs. robot is more important than full client vs. bzadmin. |
| 19:39.48 | jeffm | should be easy fix then, then stuff is there, and they could in 2.99 |
| 19:40.02 | jeffm | BulletCatcher, then how do you identify a "robot" bzadmin? |
| 19:40.28 | jeffm | make them set -notMeat |
| 19:40.39 | blast007 | jeffm: you tell it to harm a human and see if it refuses |
| 19:40.40 | *** join/#bzflag rob1n (~rob1n@97-113-28-212.tukw.qwest.net) |
| 19:40.40 | *** join/#bzflag rob1n (~rob1n@unaffiliated/rob1n) |
| 19:40.45 | jeffm | heh |
| 19:40.53 | jeffm | give bzadmin a capacha with a timeout |
| 19:40.57 | blast007 | hehehe |
| 19:41.10 | blast007 | and if it solves it, it's a robot |
| 19:41.17 | jeffm | yeah |
| 19:41.24 | jeffm | or make it do the creepy audio ones |
| 19:41.27 | BulletCatcher | "bzadmin -ui stdout" is non-interactive, so that would be a robot for me. |
| 19:41.43 | jeffm | that'd work |
| 19:42.01 | jeffm | you don't need a proto break for that, there is already a "is human" bit |
| 19:42.06 | jeffm | just make it set it |
| 19:42.19 | *** join/#bzflag contempt (contempt@unaffiliated/contempt) |
| 19:42.46 | alezakos | would adding a "don't count observers when sorting" option be too silly? |
| 19:43.15 | jeffm | it should not be an option, it should be default |
| 19:43.36 | jeffm | we can report them so BulletCatcher is happy but just not use them in the default sort |
| 19:43.47 | jeffm | I'd make the option "use observers" |
| 19:44.47 | *** join/#bzflag apeman_ (~apeman@156.236.69.111.dynamic.snap.net.nz) |
| 19:45.38 | blast007 | or just have a better lobby system and remove the need to find human observers on an otherwise empty server |
| 19:46.43 | alezakos | I don't see why not report observers for the moment, but not counting them sounds reasonable |
| 19:47.22 | blast007 | alezakos: currently we *do* report human observers (which would generally be all observers, since -solo bots don't join observer) |
| 19:47.51 | blast007 | the client counts players on an actual team as 1000 times more valuable than an observer when doing sorting |
| 19:48.16 | alezakos | what about not counting observers who have the "bzadmin" motto? |
| 19:48.23 | jeffm | maybe BulletCatcher wants to know when "the man" is watching |
| 19:48.31 | jeffm | alezakos, that's convention not protocol |
| 19:48.45 | jeffm | and not all bzadmins are bots |
| 19:49.08 | jeffm | I can see that if you can know if a human run bzadmin is there, then the server has some form of active administration |
| 19:49.26 | alezakos | you have a point |
| 19:49.37 | jeffm | and that can show that server is maybe a better place to play then "mY S3rb3r iz AWS)M3!" |
| 19:50.02 | jeffm | I'l look into why observer SSPs crash |
| 19:50.09 | jeffm | when I get back from lunch |
| 19:50.21 | apeman_ | SSP? |
| 19:50.29 | jeffm | Server Side Player |
| 19:50.39 | BulletCatcher | Solid State Player |
| 19:50.44 | jeffm | same thing ;) |
| 19:50.48 | BulletCatcher | :-) |
| 19:51.13 | jeffm | it's a mechanism that lets the server add players to the player list but not send them network messages |
| 19:51.18 | jeffm | they get API events into a plugin |
| 19:51.47 | jeffm | it'd be a better way to do bots once we can thread them |
| 19:51.58 | apeman_ | i didnt know such a mechanism existed and was expected to be working |
| 19:52.20 | jeffm | it was back ported from 2.99 |
| 19:52.25 | jeffm | it hasn't been tested much in 2.4 |
| 19:52.44 | apeman_ | is it the bz_addServerSidePlayer stuff? |
| 19:52.45 | jeffm | in 2.99 it was working pretty well for observers, I built a bzfs/irc chat relay |
| 19:52.46 | jeffm | yeah |
| 19:52.59 | jeffm | I had them joining as players but they would never die or shoot |
| 19:53.06 | *** join/#bzflag contempt (contempt@unaffiliated/contempt) |
| 19:53.11 | jeffm | they need a state for that to work |
| 19:53.38 | apeman_ | to my understanding the current way it's written is not ever going to work |
| 19:53.46 | jeffm | huh? |
| 19:53.49 | jeffm | why not? |
| 19:54.39 | apeman_ | where is the state going to go? How can you havfe a bot that can sense the map without doing massive amount of work |
| 19:54.46 | blast007 | jeffm: specifically, it made normal clients crash after I tried to have an SSP join the game |
| 19:55.07 | jeffm | apeman_, the state can go on the server, it can get all the same info a remote client can do |
| 19:55.29 | jeffm | and yes the actual bot code is the hard part, but they have been working on that in bzrobots and robocode for a while |
| 19:55.38 | jeffm | this would just let all that work be used on the server |
| 19:55.51 | jeffm | I mean solo bots have some logic |
| 19:55.59 | jeffm | that same logic can be run on the server |
| 19:56.15 | jeffm | blast007, ok, using the SSP sample I assume? |
| 19:57.02 | jeffm | apeman_, your statement would be correct if you replaced "the way it is written" with "in it's current completion state" |
| 19:57.05 | jeffm | it's just not done |
| 19:57.10 | jeffm | it's not written wrong |
| 19:57.41 | jeffm | thankfully observers don't need the state so that can do a lot that bzadmin needs server side |
| 19:58.05 | jeffm | and now that webauth is working in the HTTP stuff webadmin can be worked on |
| 19:58.07 | apeman_ | if the bot runs on a plugin, how do you run the plugin on another thread? |
| 19:58.23 | jeffm | the plugin would have to spawn a thread |
| 19:58.36 | jeffm | or we make a method for bzfs to spawn the thread |
| 19:58.42 | jeffm | that's part of the work that needs to be done |
| 19:59.05 | jeffm | probably have the plugin register a bot class that gets run in the thread |
| 19:59.10 | apeman_ | and then the bot still uses TCP/UDP to communicate? |
| 19:59.14 | jeffm | nope |
| 19:59.25 | jeffm | it's done via the API |
| 19:59.45 | jeffm | lists of pending events and the like |
| 20:00.18 | apeman_ | the bot would have lag |
| 20:00.26 | jeffm | why do you say that? |
| 20:00.41 | jeffm | it would be running in a much tighter loop then a remote client |
| 20:00.43 | apeman_ | because it has frames per second |
| 20:00.50 | jeffm | the server has no frames ;) |
| 20:00.55 | jeffm | it's event driven |
| 20:01.14 | apeman_ | currently the way to get a plugin to loop faster is maxWaitTime |
| 20:01.25 | jeffm | yeah, thats why you'd need another thread |
| 20:01.31 | jeffm | do you understand how threads work? |
| 20:01.41 | apeman_ | yes |
| 20:02.02 | apeman_ | i'm not familiar with their exact performance in practice |
| 20:02.05 | jeffm | you'd do all the logic stuff in the bot thread |
| 20:02.17 | jeffm | then have the plugin push the events in from the bzfs thread |
| 20:02.25 | jeffm | since the bzfs thread would call the plugin when it got the evens |
| 20:02.33 | jeffm | not based on some polling loop |
| 20:02.53 | apeman_ | the issue is if the bot tries to compute a lot of things |
| 20:02.54 | jeffm | then the logic thread would do what it needed to the events and push them to the bzfs gamestate |
| 20:03.01 | jeffm | sure |
| 20:03.13 | jeffm | that's all part of bot design, you can't be slower then a person |
| 20:03.18 | jeffm | again solo bots do this now |
| 20:03.21 | apeman_ | 1) say someone shot 2 shots at the same time. 2) when events are not happening, the bot will still want to change behaviour |
| 20:03.41 | jeffm | exactly like a remote solo bot |
| 20:03.48 | jeffm | it's no worse then current solo bots |
| 20:04.27 | apeman_ | i'm not saying its worse, i'm wondering what happens if theres an event, bot computes, then another event before bot finishes computing |
| 20:04.38 | jeffm | the bot code has to be prepared for that |
| 20:05.08 | jeffm | a bot may need to run multiple threads itself, one that checks events and several that figure out what to do |
| 20:05.13 | blast007 | jeffm: I wasn't using the SSP sample, I was trying it when backporting the bzfscron plugin |
| 20:05.15 | jeffm | then it can cancel a computation when it sees it's invalid |
| 20:05.20 | jeffm | blast007, ok |
| 20:05.24 | blast007 | so it's possible I was doing something wrong too ;) |
| 20:05.32 | jeffm | i'll try it with the SSP sample first |
| 20:05.45 | apeman_ | are you saying solo bot is event-driven rather than state machine? |
| 20:05.55 | jeffm | it's a bit of both |
| 20:06.07 | jeffm | but what you are talking about are common issues when doing AI design |
| 20:06.27 | jeffm | my goal is not to solve those problems but provide a framework for AI developers to use to solve those problems |
| 20:07.01 | jeffm | and yeah no matter what your AI connection is, you have to deal with incoming event |
| 20:07.08 | jeffm | since you have to deal with remote players |
| 20:07.33 | jeffm | you can do it as a state machine, it just won't be a very good bot |
| 20:08.21 | apeman_ | i think of state machine as the way i program it; it still "responds" to events simply by knowing they occurred in the next frame |
| 20:08.37 | jeffm | that's one way to do it |
| 20:08.45 | jeffm | it's common to do single threaded tasks that way |
| 20:09.14 | jeffm | another way is to put each task into a thread and have something examine the results as they come out, and decide if it should use them based on events that happened inbetween |
| 20:09.34 | jeffm | but that's AI design |
| 20:09.46 | jeffm | given the framework I have in mind you could program it ether way |
| 20:09.49 | apeman_ | ah the other main concern is, how much CPU will the bot take? |
| 20:09.59 | jeffm | the solo bots don't take much |
| 20:10.11 | jeffm | the client spends 99.9% of it's time drawing triangles |
| 20:10.37 | jeffm | so it will depend on how fancy you make them |
| 20:11.39 | jeffm | pathfinding would probably take the most CPU and since maps are static a lot of stuff can be precomputed |
| 20:11.47 | jeffm | and our maps aren't that complex |
| 20:11.55 | apeman_ | isn't this bot API going to be months of work, realistically? |
| 20:11.59 | jeffm | probably good enough to grid it up and do A* |
| 20:12.06 | jeffm | sure for full player bots |
| 20:12.25 | jeffm | but it has usefulness as it goes allong |
| 20:12.36 | jeffm | when we have observers we can do a lot of admin stuff |
| 20:12.49 | jeffm | when we have a shot state the server can look for a lot of cheats |
| 20:12.58 | jeffm | when we have tank collisions we can do more, etc... |
| 20:13.37 | jeffm | it's mostly just another use for all the little things we want to do |
| 20:13.50 | jeffm | the first thing for player bots would be to expose the map to the API |
| 20:13.57 | jeffm | and that has usefulness for other plugins |
| 20:14.13 | jeffm | it could help with spawn plugins for example |
| 20:15.34 | blast007 | or super smart homing missiles ;) |
| 20:15.41 | jeffm | that as well |
| 20:15.45 | jeffm | or smart world weapons |
| 20:16.04 | jeffm | shots will give us training maps, where a plugin can detect if a target was hit |
| 20:17.32 | apeman_ | plugin can already detect that |
| 20:17.39 | jeffm | not with a rico |
| 20:17.46 | apeman_ | fire world weapon, track shot ID |
| 20:17.46 | jeffm | the server doesn't track shots |
| 20:18.03 | jeffm | you'd have to do the math for where the shot was on your own |
| 20:18.03 | apeman_ | oh, i meant if target "died" |
| 20:18.17 | jeffm | yeah I mean if you hit a box or world object |
| 20:18.19 | jeffm | not another player |
| 20:18.40 | jeffm | make a map object with a bullseye and track if it got hit or not |
| 20:19.55 | BulletCatcher | We could call that object a "bullet catcher". |
| 20:20.00 | blast007 | heh |
| 20:20.04 | jeffm | but I must go, my people need me. I shall return latter |
| 21:15.57 | *** join/#bzflag jeffm (~jeffm@cpe-76-167-236-199.socal.res.rr.com) |
| 21:15.58 | *** join/#bzflag jeffm (~jeffm@unaffiliated/jeffm2501) |
| 21:15.58 | *** mode/#bzflag [+v jeffm] by ChanServ |
| 21:22.58 | *** join/#bzflag JeffM (~Jeffery@cpe-76-167-236-199.socal.res.rr.com) |
| 21:22.59 | *** join/#bzflag JeffM (~Jeffery@unaffiliated/jeffm2501) |
| 21:22.59 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 21:29.35 | *** join/#bzflag mebigfatguy_ (~dave@38.102.19.7) |
| 21:37.05 | *** part/#bzflag rob1n (~rob1n@unaffiliated/rob1n) |
| 21:37.05 | *** join/#bzflag rob1n (~rob1n@unaffiliated/rob1n) |
| 21:46.54 | *** join/#bzflag ashvala (~ashvala@unaffiliated/ashvala) |
| 21:56.42 | JeffM | blast007, did it crash in some event stuff? |
| 21:57.12 | blast007 | unfortunately wasn't running a debug client, so I'm not sure where it crashed |
| 21:57.30 | JeffM | k |
| 21:57.36 | JeffM | I can crash the server |
| 21:57.40 | JeffM | fixing that now |
| 21:58.09 | JeffM | seems the event manger dosn't like it when you add events while an event is being called |
| 21:59.14 | JeffM | and that kinda makes sense, the event processing is totaly different in 2.4 then it was in 2.99 |
| 22:27.40 | *** join/#bzflag mrapple (~tony@unaffiliated/mrapple) |
| 22:31.52 | JeffM | uggg, events that call events when you are calling events! |
| 22:38.27 | JeffM | it ok if bots get an IP of 0.0.0.0 ? |
| 22:38.32 | JeffM | or should I do something else fancy? |
| 22:38.49 | blast007 | SSPs? if so, why not 127.0.0.1? |
| 22:39.03 | JeffM | because it's easier to pack 0 ;) |
| 22:39.06 | JeffM | I can do 127 |
| 22:39.10 | blast007 | heh |
| 22:39.36 | JeffM | they ignore bans anyway |
| 22:40.20 | JeffM | but calling netHandler->packAdminInfo when you don't have a netHandler is not going to lead to anything good |
| 22:41.39 | JeffM | ok so I have a bot that taunts you when you shoot |
| 22:42.00 | blast007 | heh |
| 22:42.10 | blast007 | I had solo bots that did that in 1.7 ;) |
| 22:42.45 | Notify | 03BZFlag:jeffm2501 * 22677 trunk/bzflag/src/bzfs/commands.cxx: casting casting casting people! |
| 22:42.56 | blast007 | though I think they also flew and shot lasers.. |
| 22:43.51 | Notify | 03BZFlag:jeffm2501 * 22678 (trunk/bzflag/include/WorldEventManager.h trunk/bzflag/src/bzfs/WorldEventManager.cxx): Yo dog, I heard you like your events to call events that register events. Prevent that stuff from crashing by pushing the event adds that are generated during an event call till after the event list is done processing so it doesn't change during iteration. |
| 22:44.32 | Notify | 03BZFlag:jeffm2501 * 22679 trunk/bzflag/src/bzfs/GameKeeper.cxx: pack up a fake IP address for server side players that don't have real network connections |
| 22:46.22 | Cobra_Fast | i lold |
| 22:46.47 | Cobra_Fast | still waiting for a commit with a pony reference |
| 22:46.58 | Notify | 03BZFlag:jeffm2501 * 22680 trunk/bzflag/configure.ac: Add a sample for Server Side Players |
| 22:47.04 | JeffM | nothing here is worthy of ponies! |
| 22:47.12 | Cobra_Fast | aww :( |
| 22:48.00 | JeffM | we have no muffins |
| 22:48.08 | allejo | lol ponies |
| 22:48.17 | JeffM | and we set no accademy records |
| 22:48.37 | JeffM | and our tanks had wings long before Twilight Sparkle did |
| 22:48.56 | Cobra_Fast | true true ... |
| 22:49.08 | JeffM | blast007, that should make it better for cron |
| 22:49.32 | JeffM | the bot sample should also echo back private messages to itself |
| 22:49.40 | JeffM | but I did not try the SendServerCommand method |
| 23:04.53 | blast007 | Server Side Ponies |
| 23:17.55 | JeffM | that'll have to wait till we have models |
| 23:17.59 | JeffM | then server side ponies |
| 23:18.08 | JeffM | server side giant robot made up of 5 lions |
| 23:23.17 | *** join/#bzflag ts3d (~ab@unaffiliated/ts3d) |
| 23:29.03 | allejo | would like to push for Voltron |