Timestamps are in GMT/BST.
| 00:31:38 | | raptor has joined |
| 00:31:41 | | ChanServ sets mode +o raptor |
| 01:07:52 | | raptor Quit () |
| 01:12:14 | | sam686 Quit (Ping timeout: 245 seconds) |
| 02:44:00 | | sam686 has joined |
| 02:44:00 | | ChanServ sets mode +v sam686 |
| 03:05:08 | | [sam686 PING] |
| 03:05:20 | | [sam686 PING] |
| 03:05:41 | | [sam686 VERSION] |
| 03:05:48 | | [sam686 VERSION] |
| 03:06:02 | | [sam686 TIME] |
| 03:40:37 | | raptor has joined |
| 03:40:38 | | ChanServ sets mode +o raptor |
| 04:50:18 | | raptor Quit () |
| 05:41:49 | | sam686 Quit (Read error: Connection reset by peer) |
| 05:45:33 | | sam686 has joined |
| 05:45:33 | | ChanServ sets mode +v sam686 |
| 06:20:18 | | koda has joined |
| 06:36:16 | | koda Quit (Quit: koda) |
| 07:40:09 | | sam686 Quit (Ping timeout: 245 seconds) |
| 07:44:03 | | watusimoto has joined |
| 07:44:03 | | ChanServ sets mode +o watusimoto |
| 08:24:38 | | kodaws has joined |
| 12:55:19 | | -mrmist- [Global Notice] - A reminder that this coming weekend sees our long awaited services upgrade and database prune. All nicks unused for 150 days or more will be dropped from the database. Please make sure you have identified to your accounts, and used your grouped nicks. use /msg nickserv info when identified to see yours and thanks for flying freenode! |
| 13:13:08 | | LordDVG has joined |
| 13:13:38 | | watusimoto Quit (Ping timeout: 240 seconds) |
| 13:32:05 | | LordDVG Quit (Ping timeout: 248 seconds) |
| 13:37:43 | | watusimoto has joined |
| 13:37:44 | | ChanServ sets mode +o watusimoto |
| 13:52:21 | | IAmBeard has joined |
| 14:53:32 | | BFLogBot - Commit b2079724568f | Author: buckyballreaction | Log: Add 5 second spawn delay timer to prevent abuse |
| 15:01:10 | | IAmBeard Quit (Quit: Leaving) |
| 15:06:23 | | watusimoto Quit (Ping timeout: 252 seconds) |
| 15:38:36 | | Watusimoto has joined |
| 15:57:40 | | raptor has joined |
| 15:57:40 | | ChanServ sets mode +o raptor |
| 15:57:44 | raptor | good day! |
| 16:10:26 | | LordDVG has joined |
| 16:22:53 | raptor | so i implemented a timer for the /idle command |
| 16:23:02 | raptor | tell me what you think when you get the chance |
| 16:31:43 | | LordDVG Quit (Ping timeout: 265 seconds) |
| 16:44:03 | | kodaws Quit (Quit: k thx bai) |
| 16:45:42 | | zoomber_mbp has joined |
| 17:07:46 | | BlackBird_ has joined |
| 17:08:45 | | BlackBird_ Quit (Client Quit) |
| 17:15:42 | | Opti_ has joined |
| 17:15:52 | Opti_ | darn |
| 17:16:19 | raptor | hi |
| 17:20:01 | | Opti_ Quit (Ping timeout: 245 seconds) |
| 17:41:28 | | zoomber_mbp_ has joined |
| 17:42:13 | zoomber_mbp_ | hi raptor |
| 17:42:32 | zoomber_mbp_ | I'm being un orthodox right now |
| 17:42:40 | zoomber_mbp_ | using two internets to one server |
| 17:43:32 | | zoomber_mbp_ Quit (Client Quit) |
| 17:43:38 | | zoomber_mbp Quit (Ping timeout: 240 seconds) |
| 17:57:26 | raptor | hi |
| 18:54:06 | | LordDVG has joined |
| 19:41:04 | | LordDVG Quit (Remote host closed the connection) |
| 20:14:43 | | koda has joined |
| 20:21:25 | Watusimoto | hi |
| 20:21:36 | raptor | hello |
| 20:30:00 | | sam686 has joined |
| 20:30:00 | | ChanServ sets mode +v sam686 |
| 20:32:25 | raptor | so i'm thinking about moving the bot action of orbitPoint() to c++ |
| 20:33:42 | raptor | but should I make it: goToAndOrbitPoint() ? i.e. use the waypoint system as well |
| 20:36:43 | Watusimoto | do you recall our conversation about navigational objectives (which I called by a different name)? |
| 20:36:53 | Watusimoto | flightPlans perhaps? |
| 20:37:18 | raptor | vaguely, yes.. (too much has happened since then) |
| 20:37:20 | Watusimoto | so a basic flight plan would be to go to x,y |
| 20:37:39 | Watusimoto | we'd call that... what? a FlightPlan |
| 20:37:44 | raptor | right now in the code a flightPlan is the route along the navmesh zones |
| 20:37:59 | raptor | ObjectiveQueue? |
| 20:38:05 | Watusimoto | maybe |
| 20:38:09 | raptor | FlightPlan fits bettter |
| 20:38:24 | Watusimoto | I was thinking a LinearFlightPlan(dest1, dest2, dest3) |
| 20:38:32 | raptor | Sequential |
| 20:38:47 | Watusimoto | a RingFlightPlan(dest1, dest2, dest3) that repeats |
| 20:38:55 | raptor | ooohhhh |
| 20:39:13 | Watusimoto | maybe a FollowObjectFlightPlan |
| 20:39:23 | Watusimoto | an OrbitObjectFlightPlan |
| 20:39:58 | Watusimoto | so you could "file" your flight plan |
| 20:40:03 | Watusimoto | and the bot would just go |
| 20:40:15 | Watusimoto | there could be an event fired FligthPlanCompletedEvent |
| 20:40:36 | Watusimoto | but if you only wanted to go, you need not subscribe to ontick |
| 20:40:53 | Watusimoto | you just subscribe to FligthPlanComplete |
| 20:41:00 | Watusimoto | and that fn gets called when you arrive |
| 20:41:13 | Watusimoto | of course other events might also be called |
| 20:41:29 | raptor | so will there be a way to queue plans? |
| 20:41:30 | Watusimoto | that might cause you to suspend your flight plan (could be resumed later) |
| 20:41:40 | Watusimoto | this might make nav easier |
| 20:42:18 | Watusimoto | FlightPlan fp = FlightPlan.new(enemnyCore:getLoc()) |
| 20:42:39 | Watusimoto | subscribe(onFlightPlanCompleted) |
| 20:42:52 | Watusimoto | fileFlightPlan(fp) |
| 20:43:19 | Watusimoto | and that would be your nav system |
| 20:43:49 | raptor | that would definitely be a step up from determining object points all the time and having to handle the waypoint system |
| 20:44:14 | Watusimoto | fp = FollowFlightPlan.new(enemyShip) |
| 20:44:20 | Watusimoto | subscribe |
| 20:44:28 | Watusimoto | fileFlightPlan(fp) |
| 20:44:41 | Watusimoto | and you'd always head towards your objective |
| 20:45:11 | Watusimoto | if there's incoming fire, you could: |
| 20:45:20 | Watusimoto | suspendFlightPlan() |
| 20:45:25 | Watusimoto | dodge around a little |
| 20:45:27 | Watusimoto | then |
| 20:45:32 | Watusimoto | resumeFlightPlan() |
| 20:46:26 | raptor | how would you handle multiple things at once, like shooting at enemies while on a flight plan? would that be where you'd use onTick? |
| 20:46:34 | Watusimoto | maybe |
| 20:46:37 | Watusimoto | or maybe via new events |
| 20:46:43 | Watusimoto | onIncomingfire() |
| 20:46:49 | Watusimoto | onEnemyNear() |
| 20:47:07 | Watusimoto | onEnemyFlagSpotted() |
| 20:47:18 | Watusimoto | onMineDetected() |
| 20:47:18 | Watusimoto | etc |
| 20:47:51 | Watusimoto | maybe we could make ontick unnecessary |
| 20:47:55 | Watusimoto | usetimers |
| 20:48:10 | Watusimoto | so every 5 seconds you might reasses the mission |
| 20:48:15 | Watusimoto | rather than every tick |
| 20:48:26 | raptor | i put in a tick timer already |
| 20:48:37 | Watusimoto | a tick timer |
| 20:48:38 | Watusimoto | ? |
| 20:48:39 | raptor | onTick is only fired every (50?) ms |
| 20:48:54 | Watusimoto | depends on framerate |
| 20:49:09 | raptor | yes - before it was fired every server tick |
| 20:49:10 | Watusimoto | 100fps ticks will be 10ms |
| 20:49:18 | Watusimoto | oh, I see |
| 20:49:26 | raptor | now it makes sure at least 50? ms have passed before firing |
| 20:49:45 | raptor | it reduced s_bot CPU resources considerably :) |
| 20:49:52 | Watusimoto | I'll bet |
| 20:52:23 | Watusimoto | one thing to try would be to recode some bots using whatever events would make it easiest and see what we need |
| 20:52:45 | Watusimoto | and make sure we like the way the bots look, and see if this approach is feasible |
| 20:53:14 | raptor | so if we take orbitbot as an example |
| 20:53:27 | raptor | it's basically: |
| 20:53:29 | raptor | 1. find item |
| 20:53:56 | raptor | 2. can see? if yes go towards; if no, get waypoint and go towards |
| 20:54:11 | raptor | 3. if close enough, start orbiting |
| 20:55:05 | raptor | actually, maybe that's closer to SentinelBot that I wrote... orbitbot doesn't do the waypoint part |
| 21:00:09 | Watusimoto | so we could do |
| 21:00:12 | Watusimoto | 1. findItem |
| 21:00:44 | Watusimoto | 2. fp = FollowFlightPlan(item) <--- could pass any item that has a getLoc method) |
| 21:01:31 | Watusimoto | 3. subscribe(FlightPlanArrive) |
| 21:02:13 | Watusimoto | the flight plan would be smart enough to approach an item when it has LOS |
| 21:02:26 | Watusimoto | or maybe |
| 21:02:46 | Watusimoto | 4. fileFlightPlan(fp) |
| 21:02:57 | Watusimoto | 2. fp = OrbitFlightPlan(item) |
| 21:03:42 | raptor | so orbiting requires continual evaluation |
| 21:03:55 | Watusimoto | yes, but not necessarily by lua |
| 21:04:12 | Watusimoto | if we know the ship should be orbiting, it could be done in robot's idle |
| 21:04:13 | raptor | i agree (which is why i've been trying to move it to c++) |
| 21:04:58 | Watusimoto | so we need a way to let the script specify it wants to orbit an object |
| 21:05:33 | raptor | well, orbitbot uses a global isInOrbit boolean |
| 21:06:05 | Watusimoto | that should be in the c code |
| 21:09:22 | Watusimoto | you might be able to do this: getFlightPlan():isInOrbit() |
| 21:09:27 | Watusimoto | if you needed that info |
| 21:10:29 | raptor | the question of being in orbit would come up again if the object has moved and the OrbitFlightPlan as fired teh FlightPlanArrived event |
| 21:12:57 | Watusimoto | maybe we have a LeaveOrbit() event??? |
| 21:13:54 | Watusimoto | maybe an enterOrbit() event as well |
| 21:14:14 | raptor | i'm worried that our events will balloon out of control (but maybe that's not bad?) |
| 21:14:31 | Watusimoto | I hear you |
| 21:14:48 | Watusimoto | but that may have to be the price to pay for abstracting away all the nav details |
| 21:15:04 | Watusimoto | if we are going to support orbiting |
| 21:15:33 | Watusimoto | and you need ot know if you are in or out of orbit, there are only two choices that I see: constant polling in onTick() or enter/exit orbit events |
| 21:16:15 | raptor | so which is the lesser evil? :) |
| 21:16:29 | Watusimoto | events, I think |
| 21:16:48 | Watusimoto | they're cheap, espeically if no one is listenting |
| 21:18:25 | raptor | haha, sounds like blogging... |
| 21:19:44 | raptor | http://despair.com/blogging.html |
| 21:28:52 | raptor | well, i guess it's time to start fattening the event system |
| 22:03:42 | Watusimoto | what's the 5 sec spawn timer display |
| 22:04:06 | raptor | when you go idle, it waits 5 seconds before you can un-idle |
| 22:05:07 | Watusimoto | why is that? |
| 22:05:29 | raptor | this is to prevent abuse by using the /idle command to quickly teleport back to base or use it when on low life - it provides a penalty of sorts |
| 22:06:05 | raptor | maybe 5 seconds is too much? |
| 22:06:10 | raptor | maybe 3? |
| 22:06:17 | Watusimoto | ah, so only when you use the idle command, not when you are away |
| 22:06:22 | Watusimoto | ? |
| 22:06:38 | raptor | well... right now it is a client-side timer that triggers whenever you go idle |
| 22:06:51 | raptor | but i should probably move that to when you use /idle only |
| 22:07:08 | Watusimoto | I think it should be command only, as it's hard to abuse the regular timer |
| 22:07:20 | Watusimoto | and it's already frustrating enough :-) |
| 22:07:26 | raptor | i don't understand |
| 22:07:29 | raptor | oh |
| 22:07:48 | raptor | you're talking about the forced idle timer |
| 22:07:58 | Watusimoto | when the idle timer goes off and you get spawn delayed |
| 22:07:58 | Watusimoto | yes |
| 22:08:13 | Watusimoto | when the user types /idle, the timer makes sense |
| 22:08:16 | raptor | i will change that to command only... |
| 22:08:31 | Watusimoto | good; I think that makes sense |
| 22:08:49 | Watusimoto | does the user know that they can't unidle for 5 secs? |
| 22:09:02 | Watusimoto | I suppose I can just try it! |
| 22:09:07 | raptor | try it! |
| 22:09:22 | | BFLogBot - Commit 2711780ffe42 | Author: watusim...@bitfighter.org | Log: Nexuses are now ported to luaW |
| 22:09:24 | | BFLogBot - Commit eeec25757094 | Author: watusim...@bitfighter.org | Log: Merge |
| 22:09:29 | raptor | the countdown could use work... :) |
| 22:18:05 | raptor | nexii? |
| 22:18:58 | Watusimoto | yeah, well, it's a bit excessive, but probably never displayed |
| 22:19:03 | Watusimoto | radius |
| 22:19:04 | Watusimoto | nexus |
| 22:19:06 | Watusimoto | radii |
| 22:19:07 | Watusimoto | nexii |
| 22:19:14 | raptor | nexi |
| 22:19:28 | Watusimoto | that's just lame |
| 22:19:34 | raptor | haha |
| 22:19:50 | Watusimoto | that's a trampy girls name |
| 22:29:27 | | BFLogBot - Commit 87df0b5fcf5d | Author: buckyballreaction | Log: Only use spawn undelay timer for the /idle command. Also rename timer to make more sense |
| 22:31:18 | Watusimoto | please check my latest checkin to make sure I didn't undo your latest work |
| 22:31:26 | raptor | ok |
| 22:34:29 | | BFLogBot - Commit e323faf64437 | Author: watusim...@bitfighter.org | Log: Compact code, whitespace |
| 22:34:31 | | BFLogBot - Commit 18f34bc04880 | Author: watusim...@bitfighter.org | Log: Merge |
| 22:34:35 | raptor | still looks good |
| 23:00:48 | raptor | going home... |
| 23:21:38 | | koda Quit (Quit: koda) |
| 23:39:00 | | raptor Quit () |
| 23:39:44 | | raptor has joined |
| 23:39:45 | | ChanServ sets mode +o raptor |