Timestamps are in GMT/BST.
| 00:00:03 | Watusimoto | I did testitem.getLoc() instead of testitem:getLoc() |
| 00:00:24 | raptor | ha |
| 00:00:34 | raptor | i do that all the time... |
| 00:00:50 | raptor | i think i spend half my time with RepairBot making that mistake... |
| 00:00:54 | raptor | *spent |
| 00:01:13 | Watusimoto | crappy syntax |
| 00:01:25 | Watusimoto | really really error prone |
| 00:01:42 | raptor | can you overload operators in Lua? |
| 00:01:44 | Watusimoto | I had an argument on the lua list about that |
| 00:01:48 | Watusimoto | some |
| 00:01:50 | raptor | haha |
| 00:02:15 | raptor | man, all your experiences on the Lua list don't make me want to join it... |
| 00:02:30 | Watusimoto | :-) |
| 00:02:39 | raptor | dinner! |
| 00:02:44 | Watusimoto | good night |
| 00:06:18 | | BFLogBot - Commit f037d46ec1b9 | Author: watusim...@bitfighter.org | Log: Remove some old junk |
| 00:09:13 | | Watusimoto Quit (Ping timeout: 245 seconds) |
| 00:56:05 | | Heyub Quit (Quit: leaving) |
| 01:47:13 | raptor | hi sam686, are you around? |
| 02:01:53 | sam686 | hi |
| 02:21:02 | raptor | hi again sam686, still here? |
| 02:21:22 | sam686 | hi, still here? |
| 02:21:27 | raptor | yes :) |
| 02:21:32 | raptor | ok, so i have a problem |
| 02:22:07 | raptor | i'm trying to make an class 'Engineerable' that I will apply to Turret and ForceFieldProjector, as well as Teleporter |
| 02:22:31 | raptor | All three of those subclasses will inherit from Engineerable |
| 02:22:40 | raptor | they also inherit from 'Item' |
| 02:23:09 | raptor | my problem: I need to be able to access the Item methods from Engineerable |
| 02:23:22 | raptor | would i use a dynamic_cast? |
| 02:23:37 | raptor | or make Item itself a child of Engineerable? |
| 02:24:24 | raptor | or something else? The problem is because I want to make teleporters engineered, but they are not an EngineeredItem |
| 02:24:24 | sam686 | not sure.. |
| 02:24:37 | raptor | they're a LineItem |
| 02:26:10 | raptor | maybe make BfObject a child of Engineerable? |
| 02:29:56 | sam686 | maybe scrap the engineerable class, and just have a bool isEngineered (and if it is, allow it to be destroyed and turn back into ResourceItem) |
| 02:31:03 | raptor | so make it completely separate from the other two engineered items? |
| 02:34:00 | sam686 | the way EngineeredItem is, that there is many functions not specific to engineering, but specific to both forcefiend and turrets, such as mAnchorNormal, mSnapped.. |
| 02:34:14 | raptor | yes, specific to wall snapping, etc... |
| 02:34:17 | raptor | hmmm |
| 02:34:20 | raptor | you may be right |
| 04:59:54 | raptor | good ngiht! |
| 05:01:54 | | BFLogBot - Commit e3217bfd470a | Author: buckyballreaction | Log: Teleports can be built with engineering module now. They don't go anywhere, though... |
| 05:01:56 | | BFLogBot - Commit 81c1161546ba | Author: buckyballreaction | Log: Remove duplicate Lua method registration |
| 05:02:03 | | raptor Quit () |
| 05:11:58 | | BFLogBot - Commit c37cb6d13f31 | Author: buckyballreaction | Log: Forgot this header, sorry |
| 07:33:20 | | watusimoto has joined |
| 07:33:20 | | ChanServ sets mode +o watusimoto |
| 07:33:29 | | sam686 Quit (Ping timeout: 245 seconds) |
| 13:22:54 | | IAmBeard has joined |
| 14:11:05 | watusimoto | hi |
| 14:20:52 | | Watusimoto_ has joined |
| 14:35:51 | | LordDVG has joined |
| 14:44:31 | | LordDVG Quit (Ping timeout: 252 seconds) |
| 14:44:31 | | Watusimoto_ Quit (Ping timeout: 252 seconds) |
| 15:01:59 | | LordDVG has joined |
| 15:10:28 | | IAmBeard Quit (Quit: Leaving) |
| 15:14:44 | | LordDVG Quit (Ping timeout: 256 seconds) |
| 15:35:09 | | raptor has joined |
| 15:35:09 | | ChanServ sets mode +o raptor |
| 15:35:19 | raptor | hi watusimoto |
| 15:35:29 | | LordDVG has joined |
| 15:36:48 | watusimoto | hi |
| 15:37:18 | raptor | hi |
| 15:37:26 | raptor | so i got teleports working with engineer |
| 15:38:04 | raptor | but I still have to think about how to split it up into enter/exit points |
| 15:46:08 | raptor | sigh - i broke teleporters in the process... :( |
| 15:50:05 | watusimoto | ha... know the feeling |
| 15:50:26 | watusimoto | but that's cool |
| 15:55:39 | | LordDVG Quit (Read error: Connection reset by peer) |
| 15:56:53 | | LordDVG has joined |
| 15:59:44 | raptor | final vote is up, it ended up being 'Bastion' and 'Castle Fighters' as the top two |
| 16:02:30 | watusimoto | Couldn't bear to include picture frame? |
| 16:02:50 | raptor | it wasn't tied for second anymore when i checked this morning |
| 16:03:34 | watusimoto | lucky break! |
| 16:07:13 | watusimoto | I realized that with this luaW, we can create a sinlge "add object to game" method, and have it work for all objects |
| 16:07:25 | raptor | ? |
| 16:07:38 | watusimoto | I restricted the lua design with lunar to avoid implementing tons of functions everywhere |
| 16:07:56 | watusimoto | t = TestItem.new() |
| 16:08:06 | watusimoto | t:addToGame() |
| 16:08:17 | watusimoto | to put the test item into the game itself |
| 16:08:34 | watusimoto | the inheritance model is great! |
| 16:08:46 | watusimoto | with lunar, every object would need to have addToGame implemented |
| 16:08:57 | watusimoto | as well as setters for all properties |
| 16:09:09 | watusimoto | now just implement once and inherit |
| 16:09:16 | watusimoto | t:setVel(100,100) |
| 16:09:26 | watusimoto | t:setLoc(45,0) |
| 16:09:31 | watusimoto | t:addToGame() |
| 16:09:38 | watusimoto | and voila, moving testItem |
| 16:09:58 | raptor | oooo |
| 16:10:20 | watusimoto | so we could implement a testItem cannon this way, for example |
| 16:10:29 | watusimoto | fly into a zone and voom! |
| 16:10:37 | raptor | haha |
| 16:10:38 | watusimoto | a test item comes flying at you |
| 16:10:48 | raptor | oh the possibilities! |
| 16:10:59 | watusimoto | there are many |
| 16:11:01 | watusimoto | most of them bad |
| 16:11:25 | watusimoto | but we're really close |
| 16:12:49 | raptor | I think i'm going to need to have an onConstructed virtual method for my interface... |
| 16:36:13 | | watusimoto Quit (Ping timeout: 244 seconds) |
| 16:43:58 | | BFLogBot - Commit 886f2d4e509e | Author: buckyballreaction | Log: Fix normal level teleports |
| 16:54:55 | | Watusimoto has joined |
| 16:59:10 | | LordDVG Quit (Remote host closed the connection) |
| 17:14:12 | | Watusimoto Quit (Ping timeout: 246 seconds) |
| 17:31:35 | | Little_Apple has joined |
| 17:31:40 | Little_Apple | hellooo |
| 17:39:27 | raptor | hi |
| 17:41:55 | Little_Apple | whatcha doooin |
| 17:45:21 | | Watusimoto has joined |
| 17:46:38 | Little_Apple | helloo |
| 17:58:10 | raptor | hi |
| 17:58:12 | raptor | brb |
| 17:58:15 | | raptor Quit () |
| 17:58:34 | | raptor has joined |
| 17:58:51 | raptor | back |
| 17:58:52 | | ChanServ sets mode +o raptor |
| 18:01:41 | Little_Apple | yoyo |
| 18:01:45 | raptor | ma |
| 18:05:13 | Little_Apple | lol |
| 18:05:20 | Little_Apple | iseewhatyoudidthare |
| 18:06:15 | raptor | guess what |
| 18:06:30 | Little_Apple | wat |
| 18:06:40 | raptor | you might find this interesting: https://code.google.com/p/bitfighter/source/detail?r=e3217bfd470a8326c95e18fb74a8c795df5312ce |
| 18:07:01 | Little_Apple | PORTAL GUNS!!!! |
| 18:08:00 | raptor | welll... |
| 18:08:11 | raptor | it has a ways to go, but you can place them... |
| 18:09:30 | raptor | :) |
| 18:09:32 | Little_Apple | :D |
| 18:09:39 | raptor | and no, not really a portal gun |
| 18:09:45 | Little_Apple | its still awesome |
| 18:09:47 | raptor | constructable wormhole |
| 18:09:51 | raptor | err teleporter |
| 18:10:02 | Little_Apple | wormhole would be correct |
| 18:10:08 | Little_Apple | they do the same thing :P |
| 18:10:14 | raptor | still have to figure out how to place the endpoint, and how to make them destructable |
| 18:10:53 | Little_Apple | maybe give them a shell like cores have |
| 18:11:12 | Little_Apple | that you can go through |
| 18:11:26 | Little_Apple | but still be able to shoot |
| 18:11:51 | raptor | yeah, it'll probably be like that |
| 18:12:00 | raptor | and i think Watusimoto wants them green instead of blue |
| 18:12:41 | Little_Apple | or your team color? |
| 18:12:45 | raptor | no |
| 18:12:50 | Little_Apple | (like cores) |
| 18:12:53 | raptor | they will let anyone go in |
| 18:12:58 | Little_Apple | yea |
| 18:13:10 | Little_Apple | ok i see... |
| 18:16:44 | raptor | the trick is to make sure they are balanced... |
| 18:17:17 | raptor | also, Watusimoto has the idea that if you are killed before you place the endpoint, then the entry point is destroyed, too |
| 18:19:19 | Little_Apple | or it fades out and you dont get teleported when you fly over it? |
| 18:19:40 | raptor | destroyed - you have to place both without dying |
| 18:19:59 | Little_Apple | or maybe just being able to place one of each teleports? |
| 18:20:21 | Little_Apple | like in tf2 :P |
| 18:20:38 | Little_Apple | the tf2 way of doing it is pretty good |
| 18:20:39 | raptor | not two-way... |
| 18:20:47 | raptor | and i haven't played tf2 |
| 18:20:49 | Little_Apple | nono not two way |
| 18:21:15 | Little_Apple | i meant one portal and one exit for the portal |
| 18:21:43 | raptor | i'd have to see it to understand what you're suggesting |
| 18:22:33 | Little_Apple | ok... |
| 18:22:54 | Little_Apple | you have two portal options in the engineer menu: portal entry and portal exit |
| 18:22:59 | raptor | ah |
| 18:23:13 | raptor | instead of auto-detecting that it needs an endpoint? |
| 18:23:32 | Little_Apple | the portal entry would be the normal portal thing with some sort of health system |
| 18:23:52 | Little_Apple | but the portal wouldnt be activated until you have placed the portal exit |
| 18:24:20 | raptor | ah |
| 18:24:57 | Little_Apple | the portal exit could look like a core with the old mechanics when its about to be destroyed or something |
| 18:25:11 | Little_Apple | about the size of a current spy bug or something |
| 18:25:33 | raptor | hmmm |
| 18:26:10 | Little_Apple | that way you could move your portal entry without having to reset the portal exit |
| 18:26:52 | Little_Apple | or the enemy could shut down the portal without actually going to the portal entry |
| 18:26:58 | Little_Apple | see? |
| 18:28:18 | raptor | yes, i understand now - i hadn't really about how to handle portal destruction... |
| 18:28:30 | raptor | one thing at a time... :) |
| 18:29:41 | Little_Apple | :P |
| 18:29:59 | Little_Apple | just one possible way engineerable portals could work |
| 18:32:46 | Little_Apple | possssiibbblleeeelelelelele |
| 18:52:07 | Little_Apple | laters |
| 18:52:09 | | Little_Apple Quit (Quit: Page closed) |
| 19:00:30 | | Little_Apple has joined |
| 19:00:41 | Little_Apple | I AM BACK TO TORMENT YOU |
| 19:01:03 | raptor | it's like you never left... |
| 19:01:06 | raptor | :) |
| 19:01:10 | Little_Apple | :D |
| 19:08:35 | Little_Apple | pootpootpootpootpootpoot |
| 19:20:13 | Little_Apple | laterssssss :D |
| 19:20:33 | | Little_Apple Quit (Quit: Page closed) |
| 19:47:10 | | Little_Apple has joined |
| 19:47:14 | Little_Apple | HEEEYYYYYYY |
| 19:47:17 | Little_Apple | HEEEEEEEYYYYY |
| 19:47:21 | Little_Apple | HEEEEEEEEYYYYYYYYYEYEYEYEYEYEY |
| 19:47:44 | Little_Apple | back again. |
| 19:52:00 | Little_Apple | ZAM ZAM ZAM ZAM ZAM ZAM ZAM ZAM ZAM ZAM ZAM ZAM ZAM ZAM ZAM ZAM ZAM ZAM |
| 19:53:57 | Little_Apple | AHHHHHHHH IM BORED |
| 19:54:40 | | sam686 has joined |
| 19:54:40 | | ChanServ sets mode +v sam686 |
| 19:55:53 | Little_Apple | helloo |
| 20:00:10 | Little_Apple | moo! |
| 20:03:56 | raptor | hi |
| 20:04:18 | Little_Apple | hihihihihihihiihih |
| 20:05:35 | Little_Apple | byebyebebyebyebyebyebyebyebye |
| 20:05:42 | | Little_Apple Quit (Quit: Page closed) |
| 20:28:15 | Watusimoto | looks like someone fell asleep on his keyboard |
| 20:33:22 | Watusimoto | ++ |
| 20:34:30 | | raptor wakes up! |
| 20:39:18 | Watusimoto | not you! :-) |
| 20:41:56 | raptor | so i'm making a new game object: TeleporterExit |
| 20:48:12 | Watusimoto | you are? |
| 20:48:18 | raptor | well |
| 20:48:19 | Watusimoto | well... I suppose it makes sense |
| 20:48:26 | raptor | i'm not sure how to construct the endpoints |
| 20:48:27 | Watusimoto | we need to render it |
| 20:48:30 | Watusimoto | to interact with it |
| 20:48:32 | raptor | ^^ yes, that |
| 20:48:40 | Watusimoto | etc |
| 20:49:44 | Watusimoto | so will it be more than notionally related to regular teleports? |
| 20:50:13 | Watusimoto | it could be a completely different object that shares rendering code and similarly transports players |
| 20:50:41 | raptor | i was thinking about extending Teleporter to EngineeredTeleporter |
| 20:51:05 | raptor | right now it's a real honest-to-goodness teleporter |
| 20:51:42 | Watusimoto | so will regular teleporters need endpoints? |
| 20:51:56 | raptor | that's the stickiness i'm thinking about right now... |
| 20:52:08 | Watusimoto | ok, I would suggest the answer is no |
| 20:52:40 | Watusimoto | I would further suggest that you consider the geometry as a fundamental characteristic of the entity |
| 20:52:55 | Watusimoto | a simple line perfectly describes a teleport |
| 20:52:55 | raptor | yeah, right now they have Vector of destinations that is sync'd from server to client, then whenever a ship goes it, the index is sent |
| 20:53:16 | raptor | yes |
| 20:53:34 | Watusimoto | perhaps an engineerred teleport would also be a line |
| 20:53:58 | Watusimoto | but you could have teleport entrance and exit objects that exist only while the teleport is being established |
| 20:54:18 | Watusimoto | when the exit is placed, entrance and exit are removed and replaced with a line |
| 20:54:24 | raptor | ah |
| 20:54:32 | Watusimoto | that might not be quite right |
| 20:54:41 | Watusimoto | why do you need an exit object again? |
| 20:54:50 | raptor | rendering... |
| 20:54:57 | Watusimoto | it seemed obvious a minute ago, but not seems superfluous |
| 20:55:01 | Watusimoto | now |
| 20:55:05 | raptor | yeah... i don't know |
| 20:55:11 | raptor | only for rendering |
| 20:55:19 | Watusimoto | we render regular teleports without entry objects |
| 20:55:49 | raptor | before this conversation, i was thinking about just adjusting the destination point of a constructed teleport when you placed it |
| 20:56:00 | Watusimoto | yes |
| 20:56:04 | Watusimoto | that might make sense |
| 20:56:10 | raptor | right now it is constructed as a normal teleport with entry and exit points the same |
| 20:56:17 | Watusimoto | ok |
| 20:56:23 | Watusimoto | that seems logical |
| 20:56:28 | raptor | i could test for the isEngineered flag and adjust the endpoint when i want to place the endpoint |
| 20:56:56 | Watusimoto | and when rendering, check for the flag, and see if you need to render an exit point |
| 20:56:57 | raptor | but i'd still need a game object for rendering our green outline of the exit point, no? |
| 20:57:04 | raptor | oh yeah |
| 20:57:05 | Watusimoto | no |
| 20:57:06 | raptor | duh |
| 20:57:11 | raptor | that makes perfect sense now |
| 20:58:33 | Watusimoto | you just have an extended render method for engineered teleports: render normal entrance, then exit |
| 21:00:04 | raptor | good idea |
| 21:24:39 | | BFLogBot - Commit 8615257bd794 | Author: watusim...@bitfighter.org | Log: Remove some includes -- no reason for this to keep recompiling |
| 21:24:40 | | BFLogBot - Commit 0bb75c496583 | Author: watusim...@bitfighter.org | Log: Comment |
| 21:24:42 | | BFLogBot - Commit ce2f334390eb | Author: watusim...@bitfighter.org | Log: Add try/catch to better handle errors, add NULL check, and do some stack cleanup when errors encountered |
| 21:24:43 | | BFLogBot - Commit 431b977aadea | Author: watusim...@bitfighter.org | Log: Add setLoc(), setVel(), and addToGame() methods to lua interface |
| 21:24:45 | | BFLogBot - Commit 290320e3254c | Author: watusim...@bitfighter.org | Log: Better (?) error handling for scripting problems |
| 21:24:46 | | BFLogBot - Commit 6bc1f8165b31 | Author: watusim...@bitfighter.org | Log: Merge |
| 21:24:48 | | BFLogBot - Commit db171f31996f | Author: watusim...@bitfighter.org | Log: Remove dead code |
| 21:24:49 | | BFLogBot - Commit 31cfa381c1ff | Author: watusim...@bitfighter.org | Log: Make some methods private |
| 21:24:51 | | BFLogBot - Commit bc8f739bc6c1 | Author: watusim...@bitfighter.org | Log: Fix compile error |
| 21:25:18 | raptor | !! |
| 21:25:51 | Watusimoto | addToGame works in levelgens now |
| 21:25:56 | Watusimoto | but only at the start of a level |
| 21:26:09 | Watusimoto | you can create objects, set their pos & vel, and add them to the game |
| 21:26:14 | Watusimoto | without generating levelcode |
| 21:26:28 | raptor | oooo |
| 21:27:10 | Watusimoto | won't work with walls, but with all point items it should work |
| 21:31:18 | raptor | Watusimoto: was there a reason for moving the computeExtent methods private? |
| 21:35:52 | raptor | the EngineerModuleDeployer used it |
| 21:37:56 | Watusimoto | it did? |
| 21:38:02 | raptor | yes |
| 21:38:20 | Watusimoto | How did it compile??? |
| 21:38:37 | Watusimoto | I only moved it as part of a general desire to make things private where possible |
| 21:39:01 | Watusimoto | I moved that one at this time because your recent work brought it to my attention |
| 21:39:11 | Watusimoto | nothing else |
| 21:40:02 | raptor | oh, haha |
| 21:40:27 | raptor | it compiles because i made computeExtent() a public virtual method in the Engineerable interface |
| 21:40:46 | raptor | so the private methods of the sub-classes are still called somehow... which I didn't know would work |
| 21:41:42 | Watusimoto | I think private children can override public parents |
| 21:41:47 | Watusimoto | but I don;t like to do that |
| 21:41:57 | raptor | interesting |
| 21:41:57 | Watusimoto | I like them all to be the same, unless there is a good reason |
| 21:42:03 | Watusimoto | that seems less confusing |
| 21:42:10 | Watusimoto | I think you can do that in java as well |
| 21:43:45 | raptor | well, i didn't know you could call the public virtual parent externally a nd have the child method still work... but it does! |
| 21:47:10 | Watusimoto | we can put it back to public if you like -- I didn't realize it was accessed externally |
| 21:47:41 | Watusimoto | odd... eliza.bot crashes bf hard |
| 21:47:52 | raptor | huh |
| 22:12:24 | Watusimoto | question |
| 22:12:35 | Watusimoto | what happens to your sort algorithm if a class has two parents? |
| 22:12:42 | raptor | kaboom! |
| 22:12:49 | Watusimoto | oh boy |
| 22:12:50 | raptor | first one wins? |
| 22:13:05 | Watusimoto | I think I need to look into this a little more |
| 22:13:09 | raptor | no diamonds! |
| 22:13:27 | Watusimoto | no |
| 22:14:39 | raptor | if both parents are first-level, it should be OK |
| 22:15:30 | raptor | actually, it's probably resilient, because it tests each parent-child pair separately |
| 22:15:38 | raptor | and won't register until the parent is |
| 22:15:56 | Watusimoto | one parent is a first level |
| 22:15:59 | Watusimoto | and one is not |
| 22:16:09 | Watusimoto | robot intherits from ship and (now) scriptRunner |
| 22:16:17 | sam686 | you have a "typedef EngineeredItem Parent;" in Turret so... you can't have multiple "Parent" names, its an error. But you can call a second parent a "Parent2" or directly by using EngineeredItem::something... |
| 22:16:22 | Watusimoto | scriptRunner holds the subscribe method |
| 22:17:04 | Watusimoto | I could work around this, but would prefer to extend from two classes if it will work |
| 22:17:09 | raptor | just do it! |
| 22:17:18 | Watusimoto | ha |
| 22:17:39 | Watusimoto | if it doesn;t work, we'll get compiler specific errors that will be hard to fix |
| 22:17:51 | raptor | back to normal then |
| 22:18:13 | Watusimoto | think it won't work |
| 22:18:40 | Watusimoto | if it finds only one parent, it will think it is ready to be added |
| 22:19:05 | raptor | it will register twice |
| 22:19:36 | raptor | there is no check to see if it is already there... that is why i used a map before - unique keys |
| 22:19:45 | Watusimoto | right |
| 22:19:59 | sam686 | i think both child can have a same (maybe virtua) name, and a parent must have a same virtual name as well (to avoid unresolved 2 class with same name) |
| 22:20:02 | Watusimoto | I wonder if we could use a pair <class name, vector<parents> > |
| 22:20:27 | raptor | sure, then we'd need to add an extra check to make sure both parents are found |
| 22:20:34 | Watusimoto | yes |
| 22:29:02 | raptor | i forgot how to query all objects of a specific type in the level... |
| 22:29:34 | raptor | i.e.: query all teleports, find engineered ones, check if it needs an endpoint |
| 22:30:24 | raptor | or actually... we want to tie a teleport to the player somehow? |
| 22:30:47 | Watusimoto | alright I'm fried |
| 22:30:52 | raptor | bzzzzt |
| 22:30:54 | Watusimoto | knocking off for the moment |
| 22:30:58 | raptor | good night |
| 22:31:02 | Watusimoto | your question |
| 22:31:25 | Watusimoto | you want to find all teleports? |
| 22:31:34 | raptor | y |
| 22:32:12 | Watusimoto | you could either cycle through all items in the database, or maintain a list of teleports like we do for spybugs |
| 22:32:30 | raptor | oooo spybugs |
| 22:32:33 | raptor | forgot about that |
| 22:32:36 | raptor | i'll look at that |
| 22:34:01 | Watusimoto | findobjects_fast (or somesuch) returns a list of all obs in the database |
| 22:34:05 | Watusimoto | nearly costless |
| 22:34:16 | raptor | ok |
| 22:34:29 | raptor | yeah -it will only be called when deploying a new teleport |
| 22:35:16 | Watusimoto | mGame->getGameObjDatabase()->findObjects(SpyBugTypeNumber, spyBugs); |
| 22:35:22 | Watusimoto | looks like it might do the same for you |
| 22:36:19 | Watusimoto | that one is pretty efficient |
| 22:36:30 | Watusimoto | just loops through all objects looking for type match |
| 22:36:35 | Watusimoto | no spatial queries |
| 22:37:08 | Watusimoto | I thin kwe want to tie teleport to player thoguh |
| 22:37:18 | Watusimoto | because they can only finish the one they are making |
| 22:37:53 | Watusimoto | so if there is a teleport pointer on the ship, you'll always know which one thye are working on |
| 22:38:20 | raptor | yes |
| 22:38:33 | Watusimoto | and if that is not NULL, we could render the ship differently perhaps |
| 22:38:48 | raptor | so the other team can attack! |
| 22:38:50 | Watusimoto | oh, one other detail on my thoguhts about how this would work |
| 22:39:05 | Watusimoto | I thought the deploying ship can't fire while going to place the outlet |
| 22:39:14 | Watusimoto | to make it that much harder |
| 22:39:28 | raptor | hmmm |
| 22:39:33 | Watusimoto | think about it |
| 22:39:34 | raptor | sounds evil |
| 22:39:43 | raptor | but it requires another resource item? |
| 22:39:48 | Watusimoto | I think this will be apowerful weapon |
| 22:39:52 | raptor | yes |
| 22:39:56 | Watusimoto | 1 resource per teleport |
| 22:40:03 | raptor | so endpoint is free? |
| 22:40:05 | Watusimoto | not one for inlet and another for outlet |
| 22:40:09 | raptor | ah ok |
| 22:40:14 | Watusimoto | well, it's part of the same thing |
| 22:40:20 | Watusimoto | pick up resource |
| 22:40:25 | Watusimoto | place intake |
| 22:40:29 | Watusimoto | resource disappears |
| 22:40:33 | Watusimoto | place outlet |
| 22:40:38 | raptor | then how to reactivate the engineer deployer? |
| 22:40:52 | raptor | or maybe it shouldn't go away until endpoint is placed |
| 22:40:54 | Watusimoto | with engineer again, I suppose |
| 22:41:15 | Watusimoto | well I think the resource should be tied to the entrance |
| 22:41:33 | Watusimoto | the ship will need to be in a special mode -- placing teleporter mode |
| 22:41:41 | raptor | hmmm |
| 22:41:43 | Watusimoto | with (possibly) special rendering |
| 22:41:51 | Watusimoto | and (possibly) limited firing |
| 22:43:01 | Watusimoto | but in this special mdoe they could use engineer again without a resource to place the ouput |
| 22:43:06 | Watusimoto | they they exit the special mode |
| 22:44:31 | raptor | hmmm |
| 22:46:01 | raptor | ok, well, this will require thought... and probably several code iterations |
| 22:46:48 | Watusimoto | yes |
| 22:47:01 | raptor | i release you to bed, then... thanks! |
| 22:47:15 | Watusimoto | I am open to othr ideas... tomorrow |
| 23:14:45 | | raptor Quit () |
| 23:14:55 | | raptor has joined |
| 23:14:55 | | ChanServ sets mode +o raptor |
| 23:26:01 | raptor | ok |