Timestamps are in GMT/BST.
| 00:23:48 | | Watusimoto Quit (Ping timeout: 245 seconds) |
| 04:44:49 | | raptor Quit () |
| 06:07:14 | | sam686 Quit (Ping timeout: 245 seconds) |
| 07:03:24 | | kodaws has joined |
| 08:10:18 | | watusimoto has joined |
| 08:10:18 | | ChanServ sets mode +o watusimoto |
| 11:10:41 | | Watusimoto_ has joined |
| 11:41:18 | | Watusimoto_ Quit (Ping timeout: 246 seconds) |
| 14:19:30 | | LordDVG has joined |
| 14:56:02 | | raptor has joined |
| 14:56:02 | | ChanServ sets mode +o raptor |
| 14:56:09 | raptor | good morning! |
| 14:57:35 | watusimoto | hi |
| 14:57:39 | raptor | hello |
| 15:16:23 | raptor | i posed a question last night about bot 'control ticks' |
| 15:16:35 | raptor | or rather, ideas |
| 15:17:05 | raptor | we could have a default control tick of like 66ms (or whatever) |
| 15:17:16 | raptor | and then exposed a method to change it for bots |
| 15:17:37 | raptor | or |
| 15:18:01 | raptor | we could require a control tick setting for all bots |
| 15:18:11 | raptor | and impose a minimum speed |
| 15:27:38 | watusimoto | I think we should try the speed limit approach first, as it will be easier |
| 15:27:50 | watusimoto | we already have a method for calling onTick() |
| 15:28:09 | raptor | sorry.. control tick = speed limit |
| 15:28:13 | watusimoto | we just record the accumulated time since the last call to a bot's onTick() |
| 15:28:30 | watusimoto | if we are under our threshold, we simply copy the bot's last move (or don't clear it, or whatever) |
| 15:28:44 | watusimoto | and if we are over the threshold, we call onTick() and reset the accumulator |
| 15:28:56 | raptor | yes, that is exactly what i'm thinking |
| 15:29:05 | watusimoto | this will be very easy to implment |
| 15:30:27 | raptor | yes |
| 15:30:53 | raptor | 67 ms = 30 fps |
| 15:30:55 | watusimoto | look for EventManager::get()->fireEvent(EventManager::TickEvent, timeDelta); |
| 15:31:18 | watusimoto | though this fires onTick for all bots, but that should be ok |
| 15:31:23 | raptor | ah... |
| 15:31:34 | raptor | so you are thinking of a global default |
| 15:31:59 | watusimoto | well, we just wrap that in a if(time > timeToTick) { } |
| 15:32:17 | watusimoto | and right above it is clearBotMoves |
| 15:32:20 | raptor | i was thinking of a per-bot settings |
| 15:32:25 | raptor | that could be set to slower |
| 15:32:43 | watusimoto | let's try a global setting first since it would probably be 5-10 lines of code |
| 15:32:50 | watusimoto | and see how it works in general |
| 15:33:05 | watusimoto | can we discern a difference in bot behavior? |
| 15:33:20 | watusimoto | if not, then we can look to refine the technique |
| 15:33:23 | raptor | i doubt we will |
| 15:33:35 | raptor | ok, what tick-per-second limit do you think? |
| 15:33:35 | watusimoto | if it looks like it will suck, then we can remove our 10 lines of code and think of something different |
| 15:33:38 | raptor | 30 fps? |
| 15:33:41 | watusimoto | sure |
| 15:33:41 | raptor | 20? |
| 15:33:55 | watusimoto | let's start with 50ms btween bot runs |
| 15:34:09 | watusimoto | bots will still respond to other events between those ticks, but that's ok |
| 15:35:37 | raptor | so just for the onTick event? |
| 15:35:48 | watusimoto | for now, yes |
| 15:35:56 | watusimoto | for s_bot, that's 99% of bot activity |
| 15:36:05 | watusimoto | could also do this less frequently: |
| 15:36:05 | watusimoto | computeWorldObjectExtents |
| 15:36:16 | watusimoto | that's relatively expensive and probably not really necessary |
| 15:37:47 | raptor | is TickEvent map to onTick? |
| 15:38:17 | watusimoto | yes |
| 15:41:16 | raptor | so i was thinking of using a Timer |
| 15:44:04 | watusimoto | perfect |
| 15:44:31 | watusimoto | more elegant than the quick and dirty method I was thinking of, and probably no harder |
| 15:50:39 | raptor | yay for Timers |
| 15:57:54 | raptor | ok, does fireEvent get fired synchronously? |
| 15:58:31 | watusimoto | you mean in-line with the rest of the game? |
| 15:58:33 | watusimoto | yes |
| 15:58:37 | raptor | ok |
| 15:58:40 | watusimoto | do you mean all bots get fired at once? |
| 15:58:41 | watusimoto | yes |
| 15:58:56 | raptor | ok phoew |
| 15:58:56 | watusimoto | yeah, I really like that timer class |
| 15:58:58 | raptor | thanks |
| 15:59:15 | watusimoto | ideall, we'd fire each bot independently so we don't get "pulses" of bots going off |
| 15:59:24 | watusimoto | but it may not be a real problem |
| 15:59:40 | watusimoto | bot surges |
| 16:00:30 | watusimoto | I'd think the default BM bot behavior (circling opponent) would be relatively sensitive to timing |
| 16:00:41 | watusimoto | so it may be a good easy test; it's what s_bot wants to do |
| 16:00:55 | raptor | BM? |
| 16:00:58 | watusimoto | bitmatch |
| 16:01:18 | watusimoto | you can bump up the timing until the orbit starts to decay, and get some sense for what values might work |
| 16:01:24 | raptor | i htink at 20fps, it'd be hard to notice any difference... |
| 16:01:33 | watusimoto | probably right |
| 16:01:48 | watusimoto | 20fps = 50ms btwn cycles? |
| 16:02:58 | watusimoto | yes |
| 16:02:59 | raptor | yes |
| 16:06:49 | raptor | brb... i have something to test but have to switch machines |
| 16:06:54 | | raptor Quit () |
| 16:13:28 | | raptor has joined |
| 16:13:28 | | ChanServ sets mode +o raptor |
| 16:14:03 | raptor | ok, time to tes... |
| 16:14:05 | raptor | test |
| 16:17:43 | raptor | i messed something up spectacularly |
| 16:18:58 | raptor | watusimoto: here is my diff, what did i do wrong?: http://pastie.org/3762830 |
| 16:27:30 | raptor | so shooting is ok, but moving and module usage is stuttery |
| 16:29:06 | watusimoto | figure it out? |
| 16:29:13 | watusimoto | to use timer, use like this: |
| 16:29:40 | watusimoto | if(controlTickTimer.update(deltaT)) { timer_went_off; controlTickTimer.reset() } |
| 16:29:41 | raptor | i think my timer is ok - is the bot movement tied to onTick, too? |
| 16:29:58 | raptor | yes, i did something similar to that |
| 16:30:04 | raptor | the timer is OK, i think |
| 16:30:06 | watusimoto | ok, the code you posted looks wrong |
| 16:30:08 | watusimoto | ok |
| 16:30:42 | raptor | how does it look wrong? |
| 16:31:28 | watusimoto | maybe I'm reading the diff wrong |
| 16:31:35 | watusimoto | otherwise it looks fine |
| 16:31:44 | watusimoto | post the whole chunk |
| 16:31:48 | watusimoto | rather than the diff |
| 16:32:30 | raptor | i think the bot movement and modul processing is tied to ontick, so it only moves a bit |
| 16:32:33 | raptor | http://pastie.org/3762904 |
| 16:32:36 | raptor | is the whole method |
| 16:33:43 | raptor | maybe i need to modify deltaT as the interval... |
| 16:35:04 | watusimoto | oh, I see what you did |
| 16:35:13 | watusimoto | controlTickTimer.getCurrent() == 0 |
| 16:35:19 | watusimoto | that bit is not typical usage |
| 16:35:31 | raptor | it's because i don't trust the boolean return of update |
| 16:35:37 | raptor | it seems wrong to me |
| 16:35:38 | watusimoto | if(controlTickTimer.update(deltaT)) |
| 16:35:41 | watusimoto | ok |
| 16:35:49 | watusimoto | well, that's how the rest of the app does it :-) |
| 16:36:13 | watusimoto | and don't do this in fireEvent |
| 16:36:29 | watusimoto | because this event handler might be used for other events with the same signature in future |
| 16:36:35 | watusimoto | this is a generic handler |
| 16:36:51 | raptor | ok, then i misunderstood where you thought it should be done |
| 16:37:02 | watusimoto | EventManager::get()->fireEvent(EventManager::TickEvent, timeDelta); |
| 16:37:14 | watusimoto | ServerGame.cpp 1395 |
| 16:37:18 | watusimoto | or so |
| 16:37:24 | raptor | OOOooooo |
| 16:37:41 | watusimoto | just wrap that line and the clearBtMoves() inside the timer |
| 16:38:03 | raptor | ok, i'll move the timer |
| 16:38:05 | raptor | thanks |
| 16:38:10 | watusimoto | if(timer.update(timeDelta)) |
| 16:38:10 | watusimoto | { |
| 16:38:10 | watusimoto | // Clear all old bot moves, so that if the bot does nothing, it doesn't just continue with what it was doing before |
| 16:38:10 | watusimoto | Robot::clearBotMoves(); |
| 16:38:10 | watusimoto | // Fire TickEvent, in case anyone is listening |
| 16:38:10 | watusimoto | EventManager::get()->fireEvent(EventManager::TickEvent, timeDelta); |
| 16:38:11 | watusimoto | timer.reset() |
| 16:38:11 | watusimoto | } |
| 16:38:17 | watusimoto | something like that |
| 16:40:55 | watusimoto | I was totally confused about where you were doing this |
| 16:41:08 | raptor | hehe, yeah i completely misunderstood |
| 16:45:16 | raptor | Timer::update still doesn't look right... |
| 16:45:46 | raptor | it's supposed to return true if it runs out, right? |
| 16:46:13 | raptor | if so, why is this a part of the method?: |
| 16:46:15 | raptor | if(mCurrentCounter == 0) |
| 16:46:16 | raptor | return false; |
| 16:49:57 | raptor | well, in any case, bots work MUCH better now |
| 16:51:32 | raptor | huh |
| 16:51:51 | raptor | the lower tick rate is pulling out bugs in the bot code: they seem to get stuck on the walls for a few cycles |
| 16:52:00 | watusimoto | interesting... |
| 16:52:12 | watusimoto | I hope to get my bots working again tonight, so I can see your new fix |
| 16:52:16 | watusimoto | anyway, heading home |
| 16:52:18 | watusimoto | later! |
| 16:52:19 | raptor | ok |
| 16:52:21 | raptor | bye |
| 16:56:24 | | watusimoto Quit (Ping timeout: 245 seconds) |
| 17:07:17 | | BFLogBot - Commit 7ac6d84cdd37 | Author: buckyballreaction | Log: Bots now have a control tick; they run onTick using an interval. Set to 30 fps at the moment |
| 17:07:18 | | BFLogBot - Commit b79f00791a92 | Author: buckyballreaction | Log: Don't have s_bot in two places |
| 17:41:11 | | raptor Quit () |
| 17:42:40 | | kodaws Quit (Ping timeout: 260 seconds) |
| 17:49:04 | | raptor has joined |
| 17:49:05 | | ChanServ sets mode +o raptor |
| 17:51:21 | | raptor Quit (Client Quit) |
| 18:08:07 | | raptor has joined |
| 18:08:07 | | ChanServ sets mode +o raptor |
| 18:41:50 | | sam686 has joined |
| 18:41:50 | | ChanServ sets mode +v sam686 |
| 18:44:56 | raptor | hi sam686 |
| 18:45:05 | sam686 | hi |
| 18:45:16 | raptor | i am curious |
| 18:45:25 | raptor | cracatoa has a server up called 'Supernova' |
| 18:45:33 | raptor | but it shos up 4 times |
| 18:45:36 | raptor | *shows |
| 18:45:52 | raptor | he says only one bitfighter.exe is running on his windows xp box |
| 18:46:13 | raptor | would you have an idea of what is happening? |
| 18:48:10 | sam686 | parhaps becasue they are actually multiple different servers coming from same ip address, possibly coming from same computer |
| 18:49:22 | sam686 | they are multiple dedicated servers, tested with multiple clienbts |
| 18:49:41 | raptor | yes |
| 19:02:57 | raptor | i was thinking that it may be better to put static const and enum in the cpp |
| 19:03:08 | raptor | that way a header change won't require a complete recompile |
| 19:03:25 | raptor | so if in the header you have something like this: static const U32 someValue = 1000; |
| 19:03:42 | raptor | that could be changed to: static U32 someValue; |
| 19:04:04 | raptor | and in the cpp just add someValue = 1000; |
| 19:04:55 | sam686 | yes, that mean the value could change at any time, and the compiler won't be able to optimize the way it can for constant values that never changes.. |
| 19:05:12 | raptor | ah |
| 19:05:18 | raptor | so const is good |
| 19:06:20 | raptor | i wonder what the compiler does for enum |
| 19:06:24 | raptor | same thing? |
| 19:06:52 | sam686 | probably yes, though, enum is always constant |
| 19:07:03 | raptor | ah ok |
| 19:09:06 | sam686 | although, you can have "class Object1{ static const U32 someValue;}; const Object1::someValue = 1000; |
| 19:09:24 | raptor | really? |
| 19:09:35 | raptor | i thought that game compile warnings... |
| 19:09:50 | sam686 | but then, the compiler that compiles one .cpp file at a time will be blind and won't know that the real const value is.. |
| 19:10:08 | sam686 | until it come to linking |
| 19:12:12 | | mollie has joined |
| 19:12:22 | mollie | sup |
| 19:12:37 | mollie | hello |
| 19:12:38 | raptor | hi |
| 19:12:45 | mollie | sup |
| 19:12:48 | sam686 | hi |
| 19:12:54 | mollie | hi |
| 19:13:26 | mollie | do you still have the old veison of bitfighter |
| 19:13:32 | raptor | which one? |
| 19:13:41 | mollie | 16 |
| 19:13:47 | raptor | you can find all old ones here: http://bitfighter.org/releases |
| 19:13:53 | raptor | well.. *most* of them |
| 19:14:05 | mollie | ok |
| 19:14:20 | mollie | but I still have |
| 19:14:36 | mollie | 16 and nobody else has it |
| 19:14:47 | raptor | so you want the new version? |
| 19:14:50 | raptor | get 017a |
| 19:15:02 | raptor | everyone else has upgraded |
| 19:15:06 | mollie | yes but it has a vires |
| 19:15:10 | raptor | ahh.... |
| 19:15:12 | sam686 | http://code.google.com/p/bitfighter/downloads/list?can=1 lists old version too |
| 19:15:15 | raptor | actually it doesn't |
| 19:15:22 | raptor | that is the virus scanners fault |
| 19:15:36 | mollie | I guess |
| 19:15:38 | raptor | it is a 'false positive' |
| 19:16:00 | raptor | we even contacted norton about it and they said they'd update their virus database |
| 19:16:04 | mollie | I will try again I will be back |
| 19:16:13 | sam686 | if you can disable such anti-virus from scanning, install bitfighter, then i guess you can re-enable anti-virus scanner |
| 19:16:18 | raptor | but they still haven't done their part i guess |
| 19:16:35 | | mollie Quit (Client Quit) |
| 19:16:50 | sam686 | since it only flags the installer (incorrectly) as a virus, i think |
| 19:17:48 | | mollie has joined |
| 19:17:56 | mollie | sup |
| 19:18:04 | raptor | hi again |
| 19:18:32 | mollie | it still isn't working |
| 19:18:42 | sam686 | which anti-virus are you using? |
| 19:18:52 | mollie | Norton |
| 19:18:53 | raptor | norton is wrong |
| 19:19:00 | raptor | you have to disable norton to install it |
| 19:19:02 | mollie | I know right |
| 19:19:08 | raptor | then after installation, re-enable norton |
| 19:19:14 | raptor | and it'll work ok |
| 19:19:29 | sam686 | you may have to disable norton, and try downloading and installing bitfighter 017a |
| 19:19:41 | raptor | ah yes - disable norton before re-downloading |
| 19:19:48 | sam686 | then i think it is safe to re-enable after done installing bitfighter |
| 19:20:02 | mollie | @ rapor do you play Club Penguin |
| 19:20:14 | raptor | no. sorry - i don't really play any games |
| 19:20:33 | mollie | but you play bitfghter |
| 19:20:48 | raptor | yes, but i code more than play... |
| 19:20:57 | raptor | i have to play to test the code :) |
| 19:21:16 | mollie | what code |
| 19:21:30 | raptor | code = program |
| 19:21:37 | raptor | i program bitfighter |
| 19:21:40 | raptor | with sam686 |
| 19:21:43 | mollie | ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh |
| 19:22:16 | sam686 | this kind of code: http://code.google.com/p/bitfighter/source/browse/zap/ClientGame.cpp in bitfighter |
| 19:23:44 | mollie | wow |
| 19:28:01 | | mollie Quit (Quit: Page closed) |
| 19:32:24 | raptor | sam686: did you see that I added a 'control tick' to robots? |
| 19:32:40 | raptor | basically onTick will only be fired at 30 fps right now |
| 19:35:21 | sam686 | not sure if limiteing control tick of robots to only 30 fps will help, especially if the server happens to be running slower then 30 fps... |
| 19:37:01 | raptor | well, i used callgrind |
| 19:37:17 | raptor | and it seems to have helped tons |
| 19:37:25 | raptor | but my computer is fast anyways... |
| 19:37:55 | sam686 | if you happen to make your servergame go slower then 30 fps (with 100 bots or more), then it won't hardly make a difference on improving any speed |
| 19:38:08 | raptor | very true |
| 19:38:27 | raptor | but now it is harder to make the server go slower |
| 19:38:35 | raptor | because many bots won't slow it down as much |
| 19:39:02 | sam686 | yes, it may use less CPU usage if the server running higher then 30 fps |
| 19:39:12 | raptor | what is the default for a server 100fps? |
| 19:39:16 | sam686 | yes |
| 19:39:31 | raptor | i know of no one ever changing that |
| 19:43:17 | sam686 | possible problem with timer bot with the new 30 fps robot limit, instead of chat every 2 seconds of timer stats, it chats like every 4-12 seconds, due to relying on adding a counter by milliseconds passed using timeDelta in onTick |
| 19:44:57 | raptor | ahh... maybe i should change the timeDelta to be the interval? |
| 19:45:13 | sam686 | yes |
| 19:46:22 | raptor | will that be precise enough? |
| 19:47:59 | sam686 | maybe just do timeDelta2 += timeDelta; if(timeDelta > 30) {do_Robot_Idle(timeDelta); timeDelta == 0;} |
| 19:48:13 | sam686 | oops, all, but one should be timeDelta2 |
| 19:48:23 | sam686 | timeDelta2 += timeDelta; if(timeDelta2 > 30) {do_Robot_Idle(timeDelta2); timeDelta2 == 0;} |
| 19:48:28 | raptor | so replace the timer |
| 19:48:39 | raptor | that seems messier |
| 19:49:17 | sam686 | thats the most accurate way |
| 19:50:22 | sam686 | fireEvent(EventManager::TickEvent, 30/1000); if the server running only 10 fps, then the robot time ticks for timer bot will be chatting every 6 seconds anstead of 2 |
| 19:50:43 | sam686 | (and that makes timer bot completely useless if it only see one number all the time) |
| 19:51:22 | raptor | Try testing the accuraty with just changing timeDelta to BotControlTickInterval on ServerGame.cpp:1399 |
| 19:51:53 | raptor | i mentioned to watusimoto that each bot should be able to specific their control tick |
| 19:52:04 | raptor | but have a default if not specified (like 30fps) |
| 19:52:46 | | Watusimoto has joined |
| 19:53:50 | sam686 | you can get timer bot (and other bots i have) here: http://sam686.maxhushahn.com/bitfighter/robots/ |
| 19:54:00 | raptor | great, thanks |
| 19:57:02 | raptor | ok, what is the default rate? 10 seconds? |
| 19:58:03 | sam686 | i think it is 2 seconds.. |
| 19:58:11 | raptor | hmm... it's still taking like 8 |
| 19:59:19 | sam686 | in a timer bot code, rate = tonumber(arg[1]) or 2000 in main() controls the rate (you can also do "/addbot timer 0 500" for 0.5 seconds |
| 20:04:21 | raptor | still once every 8 seconds... |
| 20:04:22 | raptor | weird |
| 20:07:24 | raptor | i even did your way without the Timer |
| 20:07:32 | raptor | no difference |
| 20:08:30 | raptor | must be a bug elsewhere |
| 20:09:29 | raptor | but i pushed an accurate fix anyways... |
| 20:09:52 | sam686 | maybe (robot.cpp line 634) have something to do with the problem |
| 20:10:53 | raptor | it's returning the move time?? |
| 20:10:57 | raptor | that doesn't seem right.. |
| 20:12:34 | | BFLogBot - Commit 545c0c18fd4e | Author: buckyballreaction | Log: Send in proper time change for bot control tick |
| 20:12:35 | sam686 | i will be back in about 25 minutes.. |
| 20:19:49 | raptor | ok |
| 20:38:28 | | LordDVG Quit (Remote host closed the connection) |
| 20:57:03 | Watusimoto | so how are the bots working out? |
| 20:57:11 | raptor | bots are OK-ish |
| 20:57:16 | raptor | except |
| 20:57:31 | raptor | we expose the deltaTime to the Lua scripts |
| 20:57:38 | Watusimoto | yes |
| 20:57:53 | raptor | the problem is that it is exposed via currentMove.time |
| 20:58:09 | Watusimoto | it's passed in onTick |
| 20:58:25 | raptor | ok, then that shouldn't be a problem... |
| 20:58:42 | raptor | for whatever reason, sam's timer bot is going at 8 second intervals instead of 2 |
| 20:59:17 | Watusimoto | are you passing accumulated time via the onTick event, or just the time for that iteration of idle? |
| 20:59:26 | raptor | accumulated |
| 20:59:34 | raptor | (after my latest commit) :) |
| 20:59:36 | Watusimoto | you are accumulating it somehow? |
| 20:59:37 | Watusimoto | ok |
| 20:59:52 | Watusimoto | the code I proposed earlier did not include that |
| 21:00:08 | raptor | yes, i pass in the timer ellapsed time + timeDelta |
| 21:01:05 | Watusimoto | that could be an error, depending on how elapsed time is handled |
| 21:01:26 | raptor | i grab the elapsed time before the timer is updated |
| 21:01:53 | Watusimoto | ok. well, there is no other source of the problem, unless the timer bot is doing somehting hokey |
| 21:02:01 | Watusimoto | like using time from currentMove.time |
| 21:02:09 | raptor | hehe |
| 21:02:15 | raptor | i thought you said that is ok? |
| 21:02:26 | Watusimoto | currentMove.time is not right |
| 21:02:38 | Watusimoto | but I don't think the bot can get that |
| 21:02:44 | raptor | well, that is what is exposed to the scripts in LuaRobot::getTime |
| 21:02:59 | Watusimoto | mmmm.... well that's probably a bug |
| 21:03:05 | Watusimoto | it was probably right at one point |
| 21:03:11 | Watusimoto | but isn't if you are skipping cycles |
| 21:03:33 | raptor | so how to get the correct time now? |
| 21:03:43 | raptor | sorry if i'm a little new at the bot event stuff... |
| 21:03:58 | Watusimoto | what time do you want? time since last tick, or cpu time? |
| 21:04:21 | Watusimoto | getTime should return cpu time (if we want to expose it) |
| 21:04:30 | Watusimoto | time since last tick is passed as an arg to ontick |
| 21:04:32 | raptor | well, the case at hand is sam's timer bot |
| 21:04:39 | raptor | which uses onTick |
| 21:04:50 | raptor | http://sam686.maxhushahn.com/bitfighter/robots/timer.bot |
| 21:05:14 | Watusimoto | it's wrong |
| 21:05:16 | Watusimoto | should be |
| 21:05:22 | Watusimoto | function onTick(deltat) |
| 21:05:32 | Watusimoto | sum = sum + deltat |
| 21:05:46 | Watusimoto | something like that |
| 21:06:06 | Watusimoto | we shoudl either get rid of getTime or have it return cpu time |
| 21:07:55 | raptor | so the signature of the lua-exposed onTick should have deltaT passed in? |
| 21:08:00 | Watusimoto | yes |
| 21:08:06 | raptor | i have no idea how to do that |
| 21:08:45 | Watusimoto | TickEvent onTick(timeSinceLastTickInMs) Called every frame of the game. Unlike other events, robots are subscribed to this event by default. |
| 21:09:03 | Watusimoto | it is passed. just change the bot |
| 21:09:23 | Watusimoto | from function onTick() to function onTick(deltat) |
| 21:10:16 | raptor | testing... |
| 21:10:24 | raptor | where is that method in the cpp? |
| 21:13:33 | raptor | it works! |
| 21:14:35 | Watusimoto | function onTick(deltat) |
| 21:14:38 | Watusimoto | oops |
| 21:15:14 | Watusimoto | void EventManager::fireEvent(EventType eventType, U32 deltaT) |
| 21:15:40 | Watusimoto | lua_pushinteger(L, deltaT); is where the time actually gets pushed onto the Lua stack |
| 21:17:23 | raptor | so sam686's timer.bot needs a change |
| 21:17:31 | raptor | and do we even want getTime() ? |
| 21:22:39 | Watusimoto | I don't know |
| 21:23:06 | Watusimoto | Possibly cputime would be useful if a bot sleeps a while, or wants to track time elapased without implementing ontick |
| 21:23:49 | Watusimoto | though we have timers and such so bots proabblay don't need time for all that much |
| 21:24:12 | raptor | it seems to me that onTick should be used for 'judgement changes' in bots behavior |
| 21:24:15 | raptor | is that correct? |
| 21:24:48 | Watusimoto | or detailed changes; orbiting requires constant adjustments |
| 21:24:52 | Watusimoto | for example |
| 21:26:01 | raptor | i think all the bots are broken except s_bot: no main() |
| 21:26:12 | Watusimoto | they don't need one |
| 21:26:21 | Watusimoto | at this point, it's more of a recommendation |
| 21:26:28 | raptor | well orbit bot is quite stationary... |
| 21:26:43 | Watusimoto | ah, well, they;re all stationary for me at the moment |
| 21:26:50 | raptor | ohhhh |
| 21:27:07 | raptor | that's right... you're in the middle of a lua system rewrite... |
| 21:27:14 | raptor | ok, i'll forebear |
| 21:27:18 | raptor | and sit tight |
| 21:27:40 | Watusimoto | orbitbot is probably broken because it has function getMove() |
| 21:27:40 | Watusimoto | and not ontick() |
| 21:28:00 | Watusimoto | rename getMove to onTick and it should work |
| 21:28:12 | Watusimoto | getMove was the old design |
| 21:32:55 | raptor | it's still borken |
| 21:33:27 | raptor | ***ROBOT ERROR*** Robot error handling event Tick: scripts/robot_helper_functions.lua:86: attempt to index local 'loc' (a vec value). Shutting bot down. |
| 21:35:18 | Watusimoto | robot_helper_functions has a function function findClosest(items, teamIndx) |
| 21:35:18 | Watusimoto | that's probably broken |
| 21:35:56 | raptor | maybe no one is building bots because our examples have been slowly breaking.... |
| 21:36:09 | Watusimoto | who would build bots? |
| 21:36:30 | raptor | the hordes of bitfighter enthusiast lua programmers? |
| 21:36:53 | Watusimoto | besides them, I mean |
| 21:37:06 | raptor | probably just sam686... |
| 21:37:09 | Watusimoto | this will require a little testing when bots work again |
| 21:37:11 | Watusimoto | probably |
| 21:37:20 | Watusimoto | even I'm a little scared of it |
| 21:45:05 | raptor | what are you currently doing? ripping out lunar for luawrapper? |
| 21:57:50 | Watusimoto | trying to find a lua bug |
| 21:58:00 | Watusimoto | that keeps scripts from running |
| 21:59:14 | Watusimoto | I've optimized it so the helper scripts only get loaded and compiled once, instead of once per bot |
| 22:07:33 | Watusimoto | the thing about luawrapper is I have no idea if it will be better in any way aside from providing subclassing support |
| 22:11:06 | raptor | i have more profile data with the new bot control tick: http://sam686.maxhushahn.com/upload/callgrind.out.21927 |
| 22:12:12 | raptor | i want to say it does about 1/4 to 1/2 as many calls |
| 22:12:25 | raptor | probably clsoer to 1/4 |
| 22:16:00 | raptor | sha256_compress is now like 45% of resources spent... |
| 22:17:09 | Watusimoto | wow |
| 22:25:13 | Watusimoto | is that happening at start up, or throughout the process |
| 22:25:25 | raptor | no way to tell... |
| 22:25:31 | raptor | comes from ServerGame::Idle |
| 22:26:08 | raptor | mNetInterface->processConnections() |
| 22:26:53 | raptor | then NetInterface::continuePuzzleSolution |
| 22:37:56 | Watusimoto | you could put a print statement in there and see if it gets called alot |
| 22:38:19 | raptor | that' what i'm doing now - it get's called twice |
| 22:38:29 | raptor | actually wait, i'm not doing a server... |
| 22:38:50 | Watusimoto | i bet it only gets called when clients connect |
| 22:39:35 | raptor | heh |
| 22:39:36 | raptor | yep |
| 22:39:38 | raptor | that's it |
| 22:41:04 | raptor | have one more test to do... |
| 22:43:08 | Watusimoto | ok, then probably not a big deal |
| 22:43:30 | Watusimoto | would be nice to back it off a bit when connecting locally :-) |
| 22:43:50 | raptor | yep, just the once... |
| 23:09:27 | | Heyub has joined |
| 23:10:05 | Heyub | Good evenin'! |
| 23:21:37 | Watusimoto | hi |
| 23:27:12 | raptor | ok, i'm out |
| 23:27:17 | raptor | good night! |
| 23:28:45 | Heyub | Good night |
| 23:28:57 | raptor | well, mostly good night to Watusimoto |
| 23:29:09 | raptor | since it's gotta be past midnight at his place |
| 23:29:09 | Watusimoto | mostly |
| 23:29:14 | Watusimoto | 1:29 |
| 23:29:15 | Watusimoto | AM |
| 23:29:18 | raptor | !! |
| 23:30:04 | Heyub | lol |
| 23:30:27 | | raptor exlamation points |
| 23:31:03 | raptor | ok bye now |
| 23:31:13 | | raptor Quit () |