Timestamps are in GMT/BST.
| 00:00:02 | Watusimoto | even though one is dead |
| 00:00:24 | Watusimoto | so probably it's not being removed from the db before it's being accessed |
| 00:00:46 | Watusimoto | raptor: I did not do a count of how many times the cache was accessed |
| 00:00:49 | sam686 | it could be BfObject::deleteObject changing type number |
| 00:01:39 | sam686 | and then it thinks not to remove the mSpyBugs cause it is no longer SpyBugTypeNumber |
| 00:01:45 | | YoshiSmb_ has joined |
| 00:01:53 | Watusimoto | mGame->getGameObjDatabase()->findObjects(SpyBugTypeNumber) |
| 00:01:57 | Watusimoto | oops! |
| 00:02:01 | Watusimoto | wrong window! |
| 00:02:36 | | YoshiSmb Quit (Ping timeout: 272 seconds) |
| 00:02:46 | | YoshiSmb_ is now known as YoshiSmb |
| 00:02:49 | Watusimoto | sam686: or a delayed delete |
| 00:03:02 | Watusimoto | though then the object would still be valid |
| 00:03:09 | Watusimoto | even if exploded |
| 00:03:38 | Watusimoto | let me put a breakpoint in spybug destructor |
| 00:03:47 | raptor | oh kaen, cache test is over: 975 cached paths ~400K memory |
| 00:04:06 | sam686 | the problem is delayed delete changing type number + GridDatabase::removeFromDatabase checking for specific type (deleteType is not Spybug type) |
| 00:04:41 | Watusimoto | the 400k is just a guess |
| 00:04:56 | kaen | I've been wondering about the delayed delete thing |
| 00:04:59 | Watusimoto | it assumes 50 points per path, which is a number I just made up |
| 00:05:12 | kaen | those are the best kinds of numbers. |
| 00:05:28 | kaen | but, is there a rule for the deletion delay to use? |
| 00:05:31 | Watusimoto | delayed delete is so you can rid yourself of an object but still have it stick around to do its explodey thing |
| 00:05:35 | kaen | I've seen 500 a lot |
| 00:05:42 | kaen | oh alright |
| 00:05:52 | | amgine1234567890 has joined |
| 00:05:58 | kaen | and just disable collision once it sholdn't physically exist right? |
| 00:06:04 | Watusimoto | exactly |
| 00:06:13 | kaen | is that just server side? |
| 00:06:17 | raptor | explodey things are cool! especially teleporter... |
| 00:06:26 | Watusimoto | mmmm I think it;s mostly client side |
| 00:06:37 | Watusimoto | server doesn't have explodey things |
| 00:06:52 | Watusimoto | but I'd have to look at the code to be sure |
| 00:07:07 | kaen | hmm alright |
| 00:07:11 | amgine1234567890 | watissimo |
| 00:07:15 | raptor | air ducts are clean... loads of dust, colored pencils, old food, etc... |
| 00:07:19 | amgine1234567890 | did oyu see my cursor link |
| 00:07:44 | kaen | amgine1234567890 my friend, do you know what tab complete is? |
| 00:08:21 | YoshiSmb | Server: Super Bit Fighter Bros / Accepting arraged connection from IP:66.219.237.77:49501 |
| 00:09:09 | Watusimoto | hmmm.... spybug destructor calls remove from database |
| 00:09:35 | Watusimoto | amgine1234567890: ??? |
| 00:09:55 | amgine1234567890 | wattisimo a few days a go i made a bitfighter ship cursor i was wondering itf it would be possible to implement in game |
| 00:10:20 | raptor | haha |
| 00:11:04 | amgine1234567890 | what oyu said i could ask XD |
| 00:11:37 | Watusimoto | amgine1234567890: what is this cursor? do you ahve a screenshot or somethign? |
| 00:13:03 | raptor | http://www.filedropper.com/bfshipcursorbeta1 |
| 00:13:22 | raptor | ^^ that was it.. he made a bitfighter-themed cursor for windows |
| 00:14:06 | Watusimoto | how about a screenshot? |
| 00:15:19 | amgine1234567890 | i dont know how actully the traditional print screen doesnt show the screen cursor |
| 00:15:29 | Watusimoto | oh |
| 00:15:33 | Watusimoto | good point |
| 00:15:42 | Watusimoto | ok, I'll see it somehow |
| 00:15:56 | raptor | here, i parsed it: http://sam6.25u.com/upload/1BF%20ship%20cursor%20beta%201.cur |
| 00:17:25 | amgine1234567890 | ty raptor |
| 00:18:41 | raptor | i just realized something... |
| 00:18:41 | Watusimoto | sam686: you;re right |
| 00:18:56 | raptor | i'm never going to learn all i want to before i die |
| 00:19:05 | Watusimoto | the typenumber is set to DeletedTypeNumber so the database doesn't remove it from the specialized lists |
| 00:20:09 | Watusimoto | that parsed file is just the sam as he upoaded, no? |
| 00:20:14 | raptor | that probably sounded bad... what i meant: i want to learn lots and lots about different subjects but i may be unable... |
| 00:20:29 | raptor | Watusimoto: yes, can you not view it normally? |
| 00:20:47 | Watusimoto | what do you mean by normally? |
| 00:20:50 | raptor | my leet Linux system can... |
| 00:20:59 | Watusimoto | ah, like a graphics file? |
| 00:21:07 | raptor | yes |
| 00:21:39 | Watusimoto | it opens in notepad |
| 00:21:43 | raptor | haha |
| 00:21:56 | Watusimoto | but I'm sure I can read it |
| 00:22:14 | Watusimoto | there we go, DirectoryOpus displays it |
| 00:22:36 | raptor | what on earth is directoryopus.. |
| 00:22:39 | Watusimoto | I think it would just be confusing to have that in the game |
| 00:22:48 | YoshiSmb | kaen |
| 00:22:55 | Watusimoto | dopus is the awesomest windows file manager |
| 00:23:04 | Watusimoto | replacement for explorer |
| 00:23:14 | kaen | YoshiSmb |
| 00:23:26 | Watusimoto | http://www.gpsoft.com.au/ |
| 00:23:39 | raptor | supports tabs? |
| 00:23:51 | YoshiSmb | why you joined the server 190.96.113.66 |
| 00:24:04 | Watusimoto | of course |
| 00:24:12 | Watusimoto | though I don;t use them |
| 00:24:21 | kaen | because I thought people were playing. |
| 00:24:25 | raptor | it looks a bit like konqueror in KDE3 |
| 00:24:33 | YoshiSmb | well. i was there. |
| 00:24:36 | kaen | I saw that |
| 00:24:41 | YoshiSmb | why you dont play a little there? |
| 00:24:59 | kaen | because you were idle |
| 00:25:01 | kaen | silly. |
| 00:25:14 | YoshiSmb | sorry. i was doing something else |
| 00:25:24 | raptor | i just started blizzard control on the contest server... the levelgen didn't run |
| 00:25:33 | raptor | upon /restart, it ran |
| 00:25:44 | raptor | maybe levelgens don't load coming out of suspend? |
| 00:29:33 | Watusimoto | sam686: I think I have a fix |
| 00:29:57 | sam686 | ok. |
| 00:30:39 | sam686 | though I made a stupid fix that only changes BfObject::deleteObject (remove from database, change type, add to database) |
| 00:31:40 | Watusimoto | My fix is to save the typenumber before setting it to deleted, then restoring it in the bfObject destructor so the database can find it |
| 00:33:50 | sam686 | I will just use http://sam6.25u.com/upload/text1301/130105_18-01-16.txt for my server (for now) |
| 00:35:40 | YoshiSmb | kaen i was cheking my port of my server |
| 00:35:54 | kaen | I've got work on some stuff for now. sorry bud |
| 00:36:05 | sam686 | ... minus that extra if(mGame) on my fix.. |
| 00:36:07 | YoshiSmb | sam686 what udp i need to use to allow the ping of my server? |
| 00:36:08 | YoshiSmb | ok |
| 00:36:15 | YoshiSmb | any way good game kaen |
| 00:36:21 | sam686 | default is UDP 28000 |
| 00:36:31 | Watusimoto | sam686: that might cause expllding objects to not render |
| 00:36:46 | YoshiSmb | ok |
| 00:36:49 | YoshiSmb | thanks sam |
| 00:37:00 | Watusimoto | if you remove from the database early, they won't be found at render time |
| 00:37:05 | Watusimoto | mayeb |
| 00:37:15 | sam686 | it don't work if it is stayed removed from database.. |
| 00:37:43 | sam686 | but, removing and adding the same object has an effect of not being un-scoped by TNL at all.. |
| 00:38:31 | Watusimoto | ha, sorry, didn;t see you were adding it back |
| 00:38:33 | amgine1234567890 | anyways back oto the cursor discusiion |
| 00:39:00 | Watusimoto | yeah, that looks pretty hacky! :-) |
| 00:39:29 | sam686 | at least that will prevent my server from crashing with this hack.. |
| 00:39:34 | Watusimoto | yes |
| 00:39:42 | amgine1234567890 | lol what hack? |
| 00:39:42 | Watusimoto | my way isn't totally clean either |
| 00:39:58 | Watusimoto | this one: http://sam6.25u.com/upload/text1301/130105_18-01-16.txt |
| 00:41:43 | sam686 | edited the text on that link (press F5 on this link) (removed extra if(!mGame) ) |
| 00:42:08 | amgine1234567890 | ok maybe im being stupid but i dont see the add curves commands in the editor instrucitons |
| 00:47:19 | raptor | look harder - page 5 |
| 00:48:59 | kaen | these doxygen call graphs are delicious |
| 00:49:47 | YoshiSmb | some help. i need to configure my udp for the server im hosting now. |
| 00:52:03 | | BFLogBot Commit: 43faa45cc12e | Author: watusimoto | Message: Whitespace |
| 00:52:05 | | BFLogBot Commit: e4a5e9e26a70 | Author: watusimoto | Message: Hacky fix to problem of database not removing certain objects after they have been deleted |
| 00:52:07 | | BFLogBot Commit: 95f94df75665 | Author: watusimoto | Message: Streamline a little |
| 00:52:08 | | BFLogBot Commit: cde885e085bc | Author: watusimoto | Message: Merge |
| 00:52:45 | Watusimoto | YoshiSmb: not sure what you mean -- you should not need to do any firewall config for hosting |
| 00:53:03 | YoshiSmb | to allow the client's to ping my server |
| 00:53:15 | Watusimoto | is your server up now? |
| 00:53:25 | YoshiSmb | yes |
| 00:53:35 | YoshiSmb | im configurating it. |
| 00:53:48 | YoshiSmb | so i need to restart it |
| 00:54:04 | raptor | hacky fix! |
| 00:54:17 | Watusimoto | you might need to open port 28000 |
| 00:54:28 | Watusimoto | but I don't think so |
| 00:56:54 | amgine1234567890 | lol my cursor idea got dropeed XD oh well. |
| 00:57:14 | YoshiSmb | IP 190 . 96 . 113 . 66 and instead of showing port 28000 show a random port |
| 01:00:41 | Watusimoto | the first server you host will go on port 28000 |
| 01:00:44 | Watusimoto | I think |
| 01:16:33 | amgine1234567890 | lol what heppened about my cursoir XD |
| 01:33:12 | | amgine1234567890 Quit (Ping timeout: 245 seconds) |
| 02:30:15 | raptor | question for anyone still around |
| 02:30:56 | raptor | if i set up a connection from a client to master, can i disconnect that connection on the master side? |
| 02:31:00 | raptor | with TNL? |
| 02:36:30 | | Watusimoto Quit (Ping timeout: 272 seconds) |
| 02:53:55 | sam686 | you could disconnect that connection from master side, but sometimes the client will only just auto-reconnect to master.. |
| 02:55:29 | sam686 | for server/client, either the server can disconnect the client (kick) or the client can disconnect from server (quit) |
| 02:56:08 | sam686 | for master/client or server/client, same thing, (master can disconnect such as wrong username/password) |
| 03:04:08 | raptor | ok thanks |
| 03:22:36 | | YoshiSmb Quit () |
| 03:43:18 | | amgine1234567890 has joined |
| 03:45:44 | amgine1234567890 | so any consesus on hte cursor idea |
| 03:45:56 | amgine1234567890 | and sorry bout that my netowrk crashed |
| 05:45:27 | | bobdaduck has joined |
| 05:46:52 | bobdaduck | haigaise |
| 05:52:40 | bobdaduck | baiguise |
| 05:52:58 | | bobdaduck Quit (Quit: Page closed) |
| 06:03:06 | raptor | hi |
| 06:03:58 | raptor | amgine1234567890: i think watusimoto was of the same opinion I was - that the cursor doesn't really fit in-game. You may want to share it in the forums as a fun thing for desktop usage |
| 06:18:07 | raptor | well good night all! |
| 06:18:09 | | raptor Quit () |
| 06:41:01 | amgine1234567890 | gtg all bye |
| 06:41:05 | | amgine1234567890 Quit (Quit: Page closed) |
| 06:54:29 | | Fordcars has joined |
| 07:36:53 | | Darrel has joined |
| 07:48:37 | | Fordcars Quit (Ping timeout: 245 seconds) |
| 07:53:23 | | Darrel Quit (Read error: Connection reset by peer) |
| 09:26:27 | | LordDVG has joined |
| 10:51:15 | | Watusimoto has joined |
| 13:59:49 | | BFLogBot Commit: 7038a64868d6 | Author: watusimoto | Message: Comments |
| 13:59:51 | | BFLogBot Commit: 71b2e24cdb21 | Author: watusimoto | Message: Typo in comment |
| 13:59:52 | | BFLogBot Commit: 0439c7b9ee02 | Author: watusimoto | Message: Formatting |
| 13:59:54 | | BFLogBot Commit: ca64c37514b5 | Author: watusimoto | Message: Formatting |
| 13:59:55 | | BFLogBot Commit: fdcfac0ed421 | Author: watusimoto | Message: Formatting |
| 13:59:59 | | BFLogBot Commit: d3ad8aab70a7 | Author: watusimoto | Message: Formatting, comments |
| 14:00:01 | | BFLogBot Commit: 38b8ee6c6994 | Author: watusimoto | Message: Send flag to master signifying whether a server is a debug build or not. Master currently makes no use of this info. |
| 14:00:02 | | BFLogBot Commit: 1cd5e8c711c0 | Author: watusimoto | Message: Stop looking after we find the client. Is it safe to assume that this list will not have repeated entries? If not, this will need to be reverted. |
| 14:00:04 | | BFLogBot Commit: f0fa6a5bba4b | Author: watusimoto | Message: Formatting |
| 14:00:05 | | BFLogBot Commit: 669daf4f9055 | Author: watusimoto | Message: Formatting |
| 14:00:07 | | BFLogBot Commit: 962758fd51e1 | Author: watusimoto | Message: Formatting, trivial |
| 14:00:08 | | BFLogBot Commit: d016b14b856c | Author: watusimoto | Message: Formatting |
| 14:00:10 | | BFLogBot Commit: ba97d252d8e4 | Author: watusimoto | Message: Formatting, minor code changes for readability, comments |
| 14:00:11 | | BFLogBot Commit: 9ebb9023721e | Author: watusimoto | Message: Formatting |
| 14:00:13 | | BFLogBot Commit: 1b4e8dcf3547 | Author: watusimoto | Message: Disambiguate stoi, needed on VC++ 10 |
| 14:00:14 | | BFLogBot Commit: 26a32107cc3e | Author: watusimoto | Message: Formatting |
| 14:00:16 | | BFLogBot Commit: 475171e88fc7 | Author: watusimoto | Message: Include boost in VC++ project --> still doesn't build on VC++, linker errors |
| 14:00:18 | | BFLogBot Commit: a637ca4a19f1 | Author: watusimoto | Message: Formatting |
| 14:00:19 | | BFLogBot Commit: 75c457a78ead | Author: watusimoto | Message: Formatting |
| 14:00:21 | | BFLogBot Commit: c113a23d2e57 | Author: watusimoto | Message: Formatting |
| 14:00:22 | | BFLogBot Commit: 1f6bdd9cfba9 | Author: watusimoto | Message: Add support for checking whether client is running in debug mode, and, if so, excludes them from the json feed. This requires sending an extra flag while connecting to the master. The code for doing this has been commented out, and marked with "<<<< raptor >>>>" because I want to confer with raptor about his changes to the master server before we enable this. Without uncommenting these two lines, the code *should* be fully compatible with the existing master protocols. Note that I have compi |
| 15:15:44 | | YoshiSmb has joined |
| 15:24:29 | | Watusimoto Quit (Ping timeout: 260 seconds) |
| 15:37:58 | | YoshiSmb_ has joined |
| 15:40:39 | | YoshiSmb Quit (Ping timeout: 240 seconds) |
| 15:44:13 | | Watusimoto has joined |
| 15:52:10 | | YoshiSmb_ is now known as YoshiSmb |
| 16:06:51 | | BFLogBot Commit: f0c0e58a4485 | Author: watusimoto | Message: Rejiggered most recent checkin a little -- will now send 8 flags instead of 1 (so we can add more in the future without changing the protocol). Also made both client/master start sending/receiving after we tick up the MASTER_PROTOCOL_VERSION to 6. Still untested. |
| 16:09:54 | | raptor has joined |
| 16:09:54 | | ChanServ sets mode +o raptor |
| 16:10:47 | raptor | good day |
| 16:10:50 | | YoshiSmb Quit (Ping timeout: 248 seconds) |
| 16:13:08 | raptor | master changes to merge... |
| 16:17:59 | raptor | ok merged.. |
| 16:28:42 | raptor | Watusimoto: sam686 has master building in his vcproj file i think, if you're having trouble.. |
| 16:29:40 | Watusimoto | hi |
| 16:29:53 | Watusimoto | he's using a different version of vc++, I think |
| 16:29:55 | raptor | hi, i can check out the debug changes... |
| 16:34:49 | Watusimoto | ok |
| 16:35:05 | Watusimoto | I think everything is ready to go once we increment the MASTER_PROTOCOL_VERSION |
| 16:35:32 | raptor | yes - i had actually already done that with my anonymous protocol changes... |
| 16:35:57 | raptor | so there will be a check in two different places in MasterSErverConnection::readConnectRequest() |
| 16:37:55 | raptor | Watusimoto: with your changes, the JSON has: |
| 16:37:57 | raptor | "players": ["raptor"], |
| 16:38:04 | raptor | "playerCount": 0 |
| 16:38:20 | Watusimoto | now... that's strange |
| 16:38:29 | Watusimoto | I assume you are playing with debug engabled |
| 16:38:46 | Watusimoto | so, if anything, I would expect playerCount to be 1 with an empty list |
| 16:39:07 | raptor | yes debug enables, connecting with non-debug client now... |
| 16:39:43 | raptor | ok, so i connected with an 018 client: "players": ["raptor2", "raptor"], |
| 16:40:03 | raptor | "playerCount": 0 |
| 16:40:22 | raptor | two clients connected 019 debug, 018 release |
| 16:40:59 | Watusimoto | ok, I see why playerCount is wrong, but I don;t see how it is 0 |
| 16:41:08 | Watusimoto | oh wait |
| 16:41:10 | Watusimoto | yes I do |
| 16:41:21 | Watusimoto | it is the sum of all players connected to any registered servers |
| 16:41:38 | Watusimoto | and if your server is running in debug mode, it is not listed |
| 16:41:51 | Watusimoto | so the total number of players connected to them is 0 |
| 16:41:53 | raptor | just server? how about the player itself? |
| 16:41:57 | Watusimoto | ok |
| 16:42:07 | raptor | wait wait |
| 16:42:16 | raptor | what are we trying to accomplish with this? |
| 16:42:20 | Watusimoto | and raptor is not flagging itself as a debug mode client, so player is being listed |
| 16:42:50 | raptor | i thought it was, to not show player names in the JSON if they are connected via debug build |
| 16:43:00 | Watusimoto | exactly |
| 16:43:08 | Watusimoto | and that's what's happening |
| 16:43:08 | raptor | i figured we'd still show servers, that way we can test with each other... |
| 16:43:20 | Watusimoto | you can still see the server on the join menu |
| 16:43:26 | Watusimoto | it's just not listed in the json feed |
| 16:43:34 | raptor | ok, that's fine |
| 16:43:36 | Watusimoto | this is only about the json feed |
| 16:43:38 | Watusimoto | nothing else |
| 16:43:42 | raptor | so... am i doing something wrong? |
| 16:43:52 | Watusimoto | no, I think it is working properly |
| 16:44:09 | Watusimoto | playerCount = 0 because there aer no non-debug servers with players |
| 16:44:23 | Watusimoto | players: raptor because that one is not a debug client |
| 16:44:32 | raptor | it was compiled with TNL_DEBUG |
| 16:44:40 | raptor | full recompile |
| 16:44:45 | Watusimoto | no |
| 16:44:50 | Watusimoto | raptor was a 018 client |
| 16:45:03 | Watusimoto | raptor2 was debug client, did not show up in list |
| 16:45:06 | raptor | i am testing on my local master |
| 16:45:32 | raptor | i will connect again.. |
| 16:46:15 | Watusimoto | [[[ motivation for this: when people start using these player notifiers that we have (one for windows, one for mint), it is extrememly annoying to see test servers turning on and off ]]] |
| 16:46:32 | raptor | yes, i fully support this endeavor |
| 16:46:34 | raptor | ok |
| 16:46:41 | raptor | now i see in the JSON: "players": ["raptor_debug_019", "raptor_release_018"], |
| 16:46:55 | Watusimoto | are you using a new master build? |
| 16:46:58 | raptor | yes |
| 16:47:12 | raptor | i just compiled everything fresh at tip |
| 16:47:15 | Watusimoto | and new client build |
| 16:47:17 | Watusimoto | obviously |
| 16:47:19 | raptor | yes full recompile |
| 16:48:39 | Watusimoto | in master.cpp, line 615, you'll see this line: |
| 16:48:47 | Watusimoto | if(client->mIsDebugClient) |
| 16:49:07 | Watusimoto | try putting a printf statement in that if clause to see if that is being triggered... though it probably isn't |
| 16:49:31 | Watusimoto | or, maybe in master.cpp line 1217 |
| 16:49:33 | Watusimoto | ther is this: |
| 16:49:43 | Watusimoto | mIsDebugClient = flags & ClientDebugModeFlag; |
| 16:49:47 | Watusimoto | maybe try printing flags there |
| 16:50:23 | Watusimoto | oh, did you increase the MASTER_PROTOCOL version to 6? |
| 16:51:04 | Watusimoto | I left it at 5 to avoid breaking connections to the master until we got a new one up |
| 16:52:18 | raptor | let me do that.... |
| 16:53:16 | Watusimoto | if it was still at 5, that explains everything |
| 16:53:32 | Watusimoto | as it explicitly tests the versions to avoid breaking things |
| 16:56:29 | raptor | it works! |
| 16:56:37 | raptor | both clients connected fine |
| 16:56:49 | Watusimoto | and the json looks good? |
| 16:56:49 | raptor | but only 018 release showed up |
| 16:56:53 | raptor | yes |
| 16:56:58 | Watusimoto | good! |
| 16:57:22 | Watusimoto | I think we can push that out then to master |
| 16:57:41 | Watusimoto | I also included the possibility of 7 more cleint flags, though I have no idea what they would be |
| 16:57:57 | raptor | the evil bit |
| 16:58:02 | Watusimoto | :-) |
| 16:58:11 | raptor | the troll bit |
| 16:58:36 | Watusimoto | maybe a little bit |
| 16:58:40 | Watusimoto | or a tidbit |
| 16:58:45 | raptor | haha |
| 16:58:54 | raptor | want me to update the protocol? |
| 16:59:01 | raptor | and i can then push the change to master |
| 16:59:08 | Watusimoto | yes |
| 16:59:14 | Watusimoto | do you want do to that or shoud I? |
| 16:59:46 | raptor | i can |
| 16:59:57 | Watusimoto | actually if you want to, you should because I'm in the middle of a big debug session |
| 17:00:08 | raptor | ok |
| 17:00:10 | Watusimoto | trying to fix the stupid timers |
| 17:00:10 | raptor | will do now |
| 17:01:42 | raptor | Watusimoto: you reverted the version.h change? can i put it back to 019? |
| 17:01:58 | Watusimoto | sam put it to 018 |
| 17:02:07 | raptor | oh, ok, i put it back, then |
| 17:02:07 | Watusimoto | this does not need an upgrade to 019 |
| 17:02:16 | raptor | wait wait - |
| 17:02:19 | raptor | we're still on 018? |
| 17:02:24 | Watusimoto | apparently so! |
| 17:02:30 | raptor | when did that happen?? |
| 17:02:34 | Watusimoto | last night |
| 17:02:48 | raptor | i feel like the codebase has run away without me.. |
| 17:02:58 | Watusimoto | I know the feeling :-) |
| 17:03:51 | | BFLogBot Commit: 3f33d038def8 | Author: buckyballreaction | Message: Update master protocol since testing client-debug changes were successful |
| 17:04:44 | | raptor Quit () |
| 17:04:54 | | raptor has joined |
| 17:04:54 | | ChanServ sets mode +o raptor |
| 17:05:04 | Watusimoto | thanks!!! |
| 17:05:26 | raptor | let's see if that script still works.. |
| 17:11:40 | raptor | ok, master updated! |
| 17:16:34 | Watusimoto | excellent |
| 17:16:39 | Watusimoto | thanks for doing that |
| 17:21:46 | raptor | argh! |
| 17:21:54 | raptor | 3 maps have the same number of votes... |
| 17:25:49 | raptor | Watusimoto: did you see that another patch was submitted for the /announce bit? |
| 17:26:01 | Watusimoto | oh from donny? |
| 17:26:03 | Watusimoto | I did see it |
| 17:26:04 | raptor | yes |
| 17:26:09 | Watusimoto | I wanted to ask you about that |
| 17:26:21 | Watusimoto | it looks like an "inverse" patch, and wasn;t sure how to apply it |
| 17:26:28 | raptor | yes, let me reformat it... |
| 17:26:34 | Watusimoto | is there a tool for that? |
| 17:26:44 | Watusimoto | or do you manually edit? |
| 17:26:54 | raptor | not really, just force apply it inversely, then make a new proper diff |
| 17:27:19 | Watusimoto | ok, not sure how that works, but whatever |
| 17:30:04 | raptor | this patch is weird... |
| 17:30:47 | raptor | ok Watusimoto, here is the fixed patch: http://sam6.25u.com/upload/donimicov-task-patch2-fixed.patch |
| 17:30:54 | raptor | now it's time for french toast... |
| 17:31:06 | Watusimoto | laters |
| 17:43:21 | raptor | ok |
| 17:43:37 | raptor | so what am i going to do if there is a tie for level voting tomorrow? |
| 17:45:32 | | Watusimoto Quit (Ping timeout: 264 seconds) |
| 18:18:54 | kaen | fight to the death. |
| 18:31:11 | | LordDVG Quit (Remote host closed the connection) |
| 18:36:11 | raptor | interesting proposal... |
| 18:44:56 | | Watusimoto has joined |
| 19:07:39 | Watusimoto | my reply to donny mitsov: |
| 19:07:40 | Watusimoto | http://www.google-melange.com/gci/task/view/google/gci2012/8025216 |
| 19:08:53 | | BFLogBot Commit: ea97e5f7c4a3 | Author: watusimoto | Message: Supress errors when traveling back in time. We don't handle this situation well in any event. |
| 19:08:55 | | BFLogBot Commit: e5e3dd24272c | Author: watusimoto | Message: Add explicit argument checking to ensure timers are only passed functions |
| 19:08:57 | | BFLogBot Commit: abec99bfcbc8 | Author: watusimoto | Message: Whitespace |
| 19:08:58 | | BFLogBot Commit: 33e769192f9d | Author: watusimoto | Message: Merge |
| 19:09:03 | | BFLogBot Commit: 94cfd408dd85 | Author: watusimoto | Message: Take a look at /announce command by Donny Mitsov s |
| 19:09:04 | | BFLogBot Commit: d59f9739f119 | Author: watusimoto | Message: Formatting -- mostly but not entirely related to Donny Mitsov code |
| 19:09:06 | | BFLogBot Commit: 220bca7c3f0f | Author: watusimoto | Message: Formatting |
| 19:09:07 | | BFLogBot Commit: fc3f52f9d2f9 | Author: watusimoto | Message: Remove extraneous junk from beginning of announcement |
| 19:09:09 | | BFLogBot Commit: 1eceafbf3251 | Author: watusimoto | Message: Formatting |
| 19:09:39 | raptor | commits!! |
| 19:09:42 | raptor | ok, reading... |
| 19:09:45 | Watusimoto | the /announce command does not currently work; I merged it into the codebase because it's close, and it seemed the best way to move forward with him. You can checkout a revision pre-94cfd408dd85 and work from there if you do not want to include his stuff |
| 19:10:12 | Watusimoto | it occurs to me that this probably does break compatibility with 018 |
| 19:10:18 | raptor | nooooooooooooo |
| 19:10:48 | raptor | in your opinion, would there be a better way to close an anonymous connection than I am attempting here: http://pastie.org/5632021 |
| 19:10:58 | raptor | it's the commented out 'disconnect' line |
| 19:11:00 | Watusimoto | so we'll need to decide whether to include this our bugfix release and advance to 019, or comment some of the code out and stick with 018 |
| 19:11:29 | raptor | the reason being - everytime i call disconnect there, the connection is detected as not established, so the client gets no TerminationReason |
| 19:11:52 | Watusimoto | Well, disconnect is right, no? |
| 19:12:18 | Watusimoto | does the client need a reason? it should be expecting a disconnect |
| 19:13:05 | Watusimoto | didn't you rename anonymousConnection? or is that what you renamed it to? |
| 19:14:10 | Watusimoto | ok, I think I see a better way, perhaps |
| 19:14:30 | Watusimoto | readConnectRequest() is receiving the connectino request |
| 19:15:48 | Watusimoto | why not read the protocol version, then read a flag saying "just here for the motd/or here for a real connection |
| 19:15:58 | Watusimoto | if here just for the motd, send that, and disconnect |
| 19:16:17 | Watusimoto | no need to get into the question of client v. server |
| 19:16:39 | Watusimoto | then you can break the logic out a little differently |
| 19:16:57 | Watusimoto | or perhaps you can send a 0 for client, 1 for server, 2 for motd only connection |
| 19:17:23 | Watusimoto | instead of mIsGameServer = bstream->readFlag(); |
| 19:18:39 | raptor | ok |
| 19:18:41 | raptor | so |
| 19:18:55 | raptor | anonymousConnection <-- wasn't that what we said was a better name? |
| 19:19:25 | raptor | >>> why not read the protocol version, then read a flag saying "just here for the motd/or here for a real connection |
| 19:19:34 | raptor | that's exactly what i'm doing... |
| 19:19:51 | raptor | unless you mean to do it ahead of time, outside the block of if(isServer...) |
| 19:24:21 | raptor | i gues that's what you mean... maybe that's a good idea.. |
| 19:26:11 | raptor | i think my problem will still exist, though... the client needs to know it was disconnected so ClientGame can then turn off the anonymous flag for the connection |
| 19:26:23 | raptor | be back in a few.. |
| 19:30:21 | Watusimoto | yes, what you wrote is all true |
| 19:30:46 | Watusimoto | it just seems odd to decide between client and server, then basically ignore that decision |
| 19:31:12 | kaen | wow. apparently I successfully refactored all of that stuff... |
| 19:31:45 | kaen | the last few hours is just a blur of compiler errors |
| 19:32:32 | kaen | now... to raise the courage to merge |
| 19:41:26 | kaen | now... to back out of this merge and learn how to resolve conflicts in vim... |
| 19:41:34 | kaen | because I clearly do not know how. |
| 19:45:10 | | YoshiSmb has joined |
| 19:50:17 | Watusimoto | first rule of resolving conflicts in vim: |
| 19:50:24 | Watusimoto | don't resolve conflicts in vim |
| 19:53:06 | YoshiSmb | Quote: <Watusimoto> first rule of resolving conflicts in vim: |
| 19:53:07 | YoshiSmb | <Watusimoto> don't resolve conflicts in vim |
| 19:53:13 | YoshiSmb | what is vim? |
| 19:53:45 | Watusimoto | satan incarnate |
| 19:53:47 | Watusimoto | or |
| 19:53:48 | Watusimoto | http://en.wikipedia.org/wiki/Vim_(text_editor) |
| 20:03:54 | | YoshiSmb Quit (Ping timeout: 252 seconds) |
| 20:11:02 | | YoshiSmb has joined |
| 20:13:05 | kaen | it was super easy in git |
| 20:13:18 | kaen | in hg it opens up three files and all this jazz |
| 20:21:15 | raptor | back! |
| 20:23:10 | raptor | kaen: I have this in my .hgrc: |
| 20:23:12 | raptor | [merge-tools] |
| 20:23:13 | raptor | kdiff3.args = $base $local $other -o $output |
| 20:23:49 | raptor | and it opens it up in the three-view piece |
| 20:23:55 | raptor | make sure you have kdiff3 installed |
| 20:24:16 | raptor | oh oops, and this needs to be in the .hgrc beforehand: |
| 20:24:18 | raptor | [extdiff] |
| 20:24:19 | raptor | cmd.kdiff3= |
| 20:24:41 | raptor | oh and you need to enable the 'extdiff' extension |
| 20:24:50 | raptor | ok, that's it... for reals... |
| 20:25:31 | raptor | but if there is tortoiseHG for Linux, that may be easiest |
| 20:25:47 | | YoshiSmb Quit (Ping timeout: 244 seconds) |
| 20:30:00 | raptor | so Watusimoto, what we can do is pass a U8 for connection type, and right now we'd have 3: fromClient, fromServer, anonymous |
| 20:30:13 | raptor | is that what you were thinking? |
| 20:30:19 | Watusimoto | yes |
| 20:30:32 | raptor | ok |
| 20:30:43 | Watusimoto | I think that is cleaner than two bools |
| 20:30:48 | raptor | yes, me too |
| 20:30:55 | Watusimoto | then let's do it! |
| 20:31:09 | | YoshiSmb has joined |
| 20:31:09 | raptor | ok, i'll work on that... |
| 20:31:11 | Watusimoto | You could, I suppose, pass a rangedInt from 0-4 |
| 20:31:20 | raptor | ah yes, that's a good idea |
| 20:31:27 | raptor | 256 connection types seems unlikely |
| 20:31:34 | Watusimoto | that would let us expand by one more option before changing the protocol |
| 20:33:02 | raptor | sam686 will probably want to jimmy rig these latest commts back to 018 somehow |
| 20:33:13 | Watusimoto | ha |
| 20:35:10 | raptor | where was that file with these type of enums... |
| 20:35:21 | Watusimoto | sharedConstants? |
| 20:35:25 | raptor | ah, SharedCons.... yes |
| 20:37:11 | raptor | enum MasterConnectionType sound OK? |
| 20:50:03 | | BFLogBot Commit: 6c3222428233 | Author: sam8641 | Message: Make compatible to older 018 client/server while keeping the new RPC commands. |
| 20:50:14 | raptor | ha! |
| 20:51:18 | sam686 | hint, it is the last argument number "1" on my changes that does the versioning system, like the master connection.. |
| 20:51:49 | raptor | that's it? |
| 20:51:53 | raptor | neat... |
| 20:54:17 | Watusimoto | MasterConnectionType --< great! |
| 20:56:09 | Watusimoto | clever |
| 20:56:26 | Watusimoto | you are telling TNL that the new methods are of a newer generation than the existing ones |
| 20:56:36 | Watusimoto | so it doesn't break compatibility |
| 20:56:41 | Watusimoto | is that basically right, sam686 |
| 20:56:41 | sam686 | yes.. |
| 20:56:42 | Watusimoto | ? |
| 20:56:45 | Watusimoto | great |
| 20:56:48 | raptor | we can stay on 018 indefinitely! |
| 20:56:51 | Watusimoto | ha |
| 20:57:01 | sam686 | newer version will simply be ignored by older server or older clients |
| 20:57:19 | Watusimoto | so older clients can't use or recieve /announce |
| 20:57:59 | raptor | coding practice question: when we have an enum, and we want a value of that enum as a member to a class, should we define it as the enum name or as a U32/S32/whatever? |
| 20:59:15 | raptor | so for instance, in master.h, should I say it has a member: MasterConnectionType mConnectionType; OR U32 mConnectionType |
| 21:00:29 | Watusimoto | MasterConnectionType mConnectionType unless that's a tremendous pain |
| 21:00:33 | Watusimoto | (as it is on occasion) |
| 21:00:38 | raptor | it makes sense to use the enum name... but we have it the other way in places |
| 21:00:46 | raptor | ok |
| 21:00:52 | Watusimoto | that gives better type safety, better readbilty, and is just nicer |
| 21:01:27 | Watusimoto | but enums are kind of broken in C++ |
| 21:01:39 | Watusimoto | (should be better in c00x++x+) |
| 21:02:16 | | BFLogBot Commit: 6eba1c63a2b6 | Author: watusimoto | Message: Remove unused var |
| 21:02:18 | | BFLogBot Commit: 8ca0e0335d1d | Author: watusimoto | Message: Fix (some) problems associated with errors in levelgens; improve lua stack trace; provide a way for a misbehaving levelgen to kill itself. |
| 21:02:19 | | BFLogBot Commit: 0c699b6956b8 | Author: watusimoto | Message: Merge |
| 21:02:30 | raptor | haha, your c++ standard string makes no sense, yet anyone would know exactly what you meant... |
| 21:02:52 | Watusimoto | yup |
| 21:03:04 | Watusimoto | I thnk they should have just called it c+=2 |
| 21:03:07 | Watusimoto | or c++++ |
| 21:03:18 | Watusimoto | the name they chose is just silly |
| 21:04:17 | raptor | i think it was renamed to c++11 ? |
| 21:04:20 | raptor | i don't even know.. |
| 21:07:45 | sam686 | int c=0; c = c+++11; looks strange, but compiles fine (it adds 12 to "c") |
| 21:17:15 | kaen | I knew I would enter merge hell shortly... but I could not prepare for the evils I would see here. |
| 21:17:32 | raptor | kaen, there has been some real evil |
| 21:17:38 | raptor | sam686, you crack me up... |
| 21:18:35 | kaen | it doesn't help that I haven't merged in almost two weeks. |
| 21:20:01 | raptor | i've had 3 merge conflicts with my changes in the last 2 days alone... but i've been keeping up.. |
| 21:22:35 | Watusimoto | kaen, are most of your edits in robot.cpp, or elsewhere? |
| 21:22:55 | Watusimoto | (at least the parts that you have to merge with existing code) |
| 21:24:18 | raptor | does game server need the MOTD? |
| 21:25:01 | raptor | i'm ripping up the guts of readConnectRequest in master.cpp; may I ask that no one touch it for a while... |
| 21:30:15 | raptor | Watusimoto: should I log anonymous connections on master? |
| 21:30:38 | raptor | we do: SERVER_INFO or CLIENT_INFO |
| 21:30:43 | raptor | when a connection is made.. |
| 21:30:50 | Watusimoto | I don't think that would be useful, unless someone is trying to swamp the server... and even then... |
| 21:30:58 | raptor | yeah, ok |
| 21:31:00 | Watusimoto | what would we do if they were? |
| 21:31:19 | Watusimoto | we'd still have to listen for the packets and do something |
| 21:31:29 | Watusimoto | to decide if they were DOS packets or other |
| 21:31:40 | kaen | mostly in robot.cpp, but the formatting changes coincidentally conflicted with my refactoring and some of the stuff I had to do for the swarming stuff |
| 21:31:46 | raptor | i think there is flood control already build in... |
| 21:31:48 | Watusimoto | so the best is probably to give them what they want and get rid fo them |
| 21:32:22 | Watusimoto | kaen, are your probelms focused on robot.cpp, or everywhere? |
| 21:32:45 | Watusimoto | most of the widescale changes I know of involve removing the UserInterface:: prefix off a slew of rendering methods |
| 21:33:08 | kaen | almost exclusively in robot |
| 21:33:31 | kaen | there was a lot of whitespace conflict... it sounds like that's something I introduced |
| 21:34:47 | Watusimoto | well, if you're unusure of anything, don't be shy about asking |
| 21:35:33 | Watusimoto | every one of us feels your pain |
| 21:36:05 | raptor | it burns! |
| 21:37:22 | sam686 | umm one problem. since when do you do a renderAnnouncement from only inside a s2cDisplayAnnouncement? (/announce doesn't display at all) |
| 21:41:45 | kaen | yup. just confirmed that I have been working this whole time with automatic whitespace removal on in code blocks, and have been committing this minute changes mixed in with all of my real ones, and the difficulty of that merge was due almost entirely to that. |
| 21:41:59 | raptor | !! |
| 21:42:10 | kaen | so... |
| 21:42:32 | kaen | I honestly don't even know how to procede. it sounds like I'd be better off making a diff and starting from scratch |
| 21:42:54 | raptor | i'd go back to your previous changes and auto-format all the whitespace properly |
| 21:43:07 | raptor | then attempt the merge again |
| 21:43:26 | kaen | all of the corrections are... correct. they're just littering my local commits |
| 21:43:46 | kaen | I was able to merge to a working state, but only realized all of this afterwards. |
| 21:44:33 | kaen | so I guess it's almost a non-problem, but isn't including those whitespace changes considered a bad thing? |
| 21:45:13 | raptor | if it's a change that brings it in line to our coding style, then no (e.g. 3 spaces indent |
| 21:45:15 | raptor | ) |
| 21:46:19 | sam686 | The only thing that doesn't really produce merging hassles is line ending changes, everything else could cause merge problems.. |
| 21:46:58 | kaen | it's pretty much entirely line-ending whitespace getting trimmed |
| 21:47:32 | sam686 | whitespace trimming is what can cause merging problem.. |
| 21:48:53 | raptor | my ide auto trims whitespace on anyline you've edited/changed |
| 21:49:08 | kaen | well it's really just an experiment anyway. I'll cross the merge bridge when I come to it |
| 21:49:20 | Watusimoto | sam686: /announce doesn't work; we're going to let donny fix it if he can |
| 21:49:49 | kaen | raptor, mine too. but I have a bad habit of editing, backspacing, and then saving |
| 21:49:58 | sam686 | ok, maybe don't auto trim (get rid of extra spaces at end of line) every single line, just the one edited.. |
| 21:49:58 | kaen | rather than simply undoing. |
| 21:50:37 | kaen | sam686 that's a good idea |
| 21:50:42 | kaen | you should make IDEs |
| 22:01:54 | raptor | Watusimoto: maybe for anonymous connection I can future-proof it a little? like send an enum for an AnonymousConnectionAction or something... |
| 22:04:59 | Watusimoto | what sorts of actions would we use currently? |
| 22:05:09 | raptor | MotdAction |
| 22:05:14 | raptor | tada! |
| 22:05:31 | raptor | maybe GeneralHighScores? |
| 22:05:43 | raptor | or, DosMasterServer |
| 22:06:37 | Watusimoto | how about Shutdown |
| 22:06:43 | raptor | ? |
| 22:06:51 | Watusimoto | fetchRootPassword |
| 22:06:56 | raptor | exactly! |
| 22:07:05 | raptor | all perfectly anonymous to us! |
| 22:07:07 | Watusimoto | sendViagraSpam |
| 22:07:17 | raptor | anonymity is secure, right! |
| 22:07:22 | raptor | oh wonderful |
| 22:07:49 | Watusimoto | you could send an enum, but you will need to reserve a certain number of "slots" (i.e. bits) to pass the largest enum you envision |
| 22:08:16 | raptor | that was the plan... but i'm more asking if it would be smart to do so... |
| 22:08:48 | raptor | in your expert opinion - although we may never use it for anything ever again |
| 22:09:31 | Watusimoto | right now we have 1 or possibly 2 potential actions; we could save room for, say 8 |
| 22:09:50 | Watusimoto | we could always use the last one to mean another batch of 8 are coming in the next byte |
| 22:10:07 | raptor | ? |
| 22:10:16 | raptor | that sounds like extended partitions... |
| 22:10:22 | Watusimoto | kind of |
| 22:10:29 | Watusimoto | 1 = get scores |
| 22:10:32 | Watusimoto | 2 = get motd |
| 22:10:34 | Watusimoto | ... |
| 22:10:45 | Watusimoto | 7 = read another byte with 8 more actions |
| 22:11:03 | Watusimoto | or rather another 3 bits |
| 22:11:04 | Watusimoto | or whatever |
| 22:11:08 | raptor | i think you're thinking further ahead than me... |
| 22:11:29 | Watusimoto | or just reserve a whole byte's worth! 256 is pretty future proof |
| 22:11:51 | raptor | i have altered the connection to first send mConnectionType, then based on that it'll read the bitstream accordingly |
| 22:12:22 | raptor | so for ConnectionTypeAnonymous, i can then send an enum of actions |
| 22:12:55 | raptor | that all the future i'm thinking of.. |
| 22:15:04 | raptor | *that's |
| 22:19:01 | Watusimoto | how many enum values? |
| 22:19:11 | raptor | i was thinking 4 or 8 |
| 22:19:38 | raptor | because I cannot (at this moment) conceive of many anonymous actions... |
| 22:19:44 | Watusimoto | that's fine |
| 22:19:49 | Watusimoto | go with 8 |
| 22:19:56 | Watusimoto | we can afford the extra bit! |
| 22:20:13 | Watusimoto | remember how much data a typical http connection sends, just to set up |
| 22:20:20 | raptor | so you *do* think it's OK to send an action? |
| 22:20:42 | Watusimoto | sure; this is not in-game connection; this is a connection to the master server while not playing |
| 22:21:00 | raptor | OK |
| 22:21:05 | Watusimoto | you'll use a rangedInt? |
| 22:21:11 | raptor | sendEnum |
| 22:21:16 | Watusimoto | perfect |
| 22:21:27 | Watusimoto | I think that is just a wrapper around rangedInt |
| 22:21:34 | raptor | yes |
| 22:22:01 | Watusimoto | why can't I find that function? |
| 22:22:47 | raptor | writeEnum |
| 22:22:48 | raptor | sorry |
| 22:22:59 | raptor | bitStream->writeEnum(...) |
| 22:24:13 | Watusimoto | nice function, that one |
| 22:24:19 | raptor | yes |
| 22:24:19 | Watusimoto | simple, clean, elegant |
| 22:24:22 | raptor | i like it |
| 22:29:49 | | kaen Quit (Read error: Connection reset by peer) |
| 22:29:57 | | masterkaen has joined |
| 22:38:06 | | masterkaen Quit (Changing host) |
| 22:38:07 | | masterkaen has joined |
| 22:38:10 | | masterkaen is now known as kaen |
| 22:38:27 | kaen | so I got the pathing behavior into my swarmers :) |
| 22:39:36 | raptor | great! |
| 22:40:45 | kaen | hmm. what to do next. |
| 22:41:38 | kaen | I think it's close to being play-testable. maybe I should work towards that for now. |
| 22:42:41 | kaen | really all of the structural stuff is in place now that the pathing is in. I just have to flesh out the actual gameplay (i.e. more enemies) |
| 22:45:37 | Watusimoto | sounds awesome! |
| 22:46:02 | Watusimoto | is your refactor stuff worth checking in? |
| 22:49:49 | raptor | i think kaen is rewriting the game... |
| 22:53:54 | raptor | Watusimoto: i'm running into the disconnect problem again - i cannot seem to be able to actually call disconnect from within MasterServerConnection::readConnectRequest() |
| 22:54:05 | raptor | and have the client receive the message |
| 22:54:36 | Watusimoto | ok |
| 22:54:43 | Watusimoto | looking |
| 22:55:10 | raptor | soo... does it have something to do with queueing the action on a thread and running it after the connection is considered established? |
| 22:55:51 | kaen | Watusimoto, I would say it's not. there's no real reason to have it unless you plan on having something do pathfinding other than robots. |
| 22:56:17 | Watusimoto | ok; was just thinking of easing future merges |
| 22:56:45 | kaen | I thought about that too, but at the very least it needs some polishing before checking in |
| 22:57:41 | Watusimoto | raptor: I doubt it... I'm thinkint that by using a m2c the connection might need to be established beofre it gets run... or rather, maybe that's what you meant, in which case, it might well be |
| 22:59:14 | raptor | maybe sam686 would know. sam686: would you know why calling disconnect() in MasterServerConnection::readConnectRequest() doesn't seem to work? |
| 23:00:18 | sam686 | disconnect() doesn't work on readConnectRequest, because it is not fully connected... instead, return false to refuse connection.. |
| 23:01:20 | sam686 | and optionally set reason = something just before "return false;" |
| 23:01:53 | Watusimoto | just for fun, try skipping the m2c and try writing the string directly to the connection |
| 23:02:27 | Watusimoto | so you need to fully establish the connection, then shut it down |
| 23:02:30 | sam686 | careful with version compatibility stuff.. |
| 23:03:05 | Watusimoto | which suggests that, maybe, it can't be used in the super lightweight manner we've been looking at? |
| 23:05:16 | sam686 | if you look at gameNetInterface.cpp, there is some networking code "ping" stuff that can send more information, without connecting. |
| 23:06:46 | raptor | hmm |
| 23:06:55 | raptor | ok, so what i wish to do: |
| 23:07:15 | raptor | open anonymous master connection, do an action, close connection |
| 23:07:51 | raptor | so i've been trying to make it so master closes the connection immediately after doing an action |
| 23:07:56 | raptor | like sending MOTD |
| 23:08:21 | raptor | then the client would pick up that it has isn't connected anymore |
| 23:08:34 | raptor | maybe there is a different way? |
| 23:08:53 | sam686 | maybe don't make the master close connection, instead just make the client close connection (client could sent multiple commands) |
| 23:10:11 | raptor | so instead of sending an action on opening an anonymous connection, just open one connection and wait for the client to explicitly request MOTD? |
| 23:10:37 | raptor | should i just keep anonymous connection open no matter what? then change it to Client connection when needed? |
| 23:10:46 | sam686 | how about a seperate "class A_Seperate_Connection : public EventConnection" ? |
| 23:12:30 | sam686 | that is what kindof was done with DataConnection (zap/dataConnection.cpp) |
| 23:25:28 | Watusimoto | >>> instead just make the client close connection (client could sent multiple commands) <<< I kind of like this |
| 23:27:19 | kaen | I have a Ship* that I dereference in the idle loop of an object. is there way to check that the Ship is still valid (beyond null checking?) |
| 23:29:00 | | kodaws has joined |
| 23:29:40 | Watusimoto | where do you get it from? i.e. could be available wrapped in a SmartPtr<>? |
| 23:30:01 | Watusimoto | sorry, that might be SafePtr |
| 23:30:21 | Watusimoto | SafePtr is a TNL smart pointer that turns to NULL when the underlying object is deleted |
| 23:31:26 | Watusimoto | absent that, check for NULL, and if it's not NULL, check mHasExploded which, if it's set, the object is essentially dead but not yet deleted |
| 23:32:10 | raptor | Watusimoto: what if the anonymous connection persisted, then the client terminated it when it wanted to connect as a client? |
| 23:32:27 | Watusimoto | here is a block that shows how we do it elsewhere: |
| 23:32:28 | Watusimoto | Ship *ship = static_cast<Ship*>(hitObject); |
| 23:32:28 | Watusimoto | // We've hit a ship or robot (remember, robot is a subtype of ship, so this will work for both) |
| 23:32:28 | Watusimoto | // We'll need to make sure the ship is a valid entity and that it hasn't exploded |
| 23:32:28 | Watusimoto | if(ship->hasExploded) |
| 23:32:30 | Watusimoto | return false; |
| 23:32:56 | Watusimoto | raptor: why persist it? |
| 23:32:59 | raptor | and no actions were sent upon connect, rather requested via c2m or whatever |
| 23:33:31 | Watusimoto | oh, persist it until client depersisted it |
| 23:33:46 | raptor | yes |
| 23:33:49 | Watusimoto | I think that could work |
| 23:34:01 | Watusimoto | though I would haev the client grab what it needs and go |
| 23:34:15 | raptor | so, connect... stay connected... request motd, disconnect (from client) |
| 23:35:47 | Watusimoto | sure |
| 23:35:50 | Watusimoto | that seems sane |
| 23:35:53 | Watusimoto | orderly |
| 23:36:04 | Watusimoto | builds on our existing ways of doing things |
| 23:36:09 | raptor | but the request would be outside of the connection bitstream |
| 23:36:18 | Watusimoto | a little less hacky than what I was suggesting earlier |
| 23:36:39 | Watusimoto | meaning a c2m? |
| 23:36:43 | raptor | yes |
| 23:36:54 | Watusimoto | well, that's fine |
| 23:37:26 | raptor | or anything you think would be better... |
| 23:37:28 | Watusimoto | so maybe the client shoudl first declare whether they are logging in or just coming for anon stuff |
| 23:37:46 | Watusimoto | then, if loggging in, would declare themselves as a client or server |
| 23:37:48 | raptor | well, i have mConnectionType being sent in the connection request |
| 23:38:00 | raptor | so client, server, anon |
| 23:38:00 | Watusimoto | yes |
| 23:38:12 | Watusimoto | yes |
| 23:38:14 | Watusimoto | yes |
| 23:38:25 | Watusimoto | stick with that |
| 23:38:28 | sam686 | one possible problem with not logging in, is... might not want to have just about anyone changing or running commands that might want to be limited... |
| 23:38:54 | Watusimoto | sam686: there would only be one or two commands available |
| 23:38:56 | raptor | we already let anyone |
| 23:39:04 | raptor | they just need a non-registered name |
| 23:39:09 | Watusimoto | oh right! |
| 23:39:51 | kaen | >>> where do you get it from? <<< It comes from a call to findObjects() |
| 23:40:22 | sam686 | for what? a program that reads number of players and reads motd, and possibly alert if anything changes? |
| 23:41:31 | kodaws | greetings from the west coast! |
| 23:41:38 | raptor | hi kodaws |
| 23:41:42 | raptor | in the US? |
| 23:41:58 | raptor | if so, welcome! |
| 23:46:48 | Watusimoto | kaen: is that coming from the database? |
| 23:47:18 | kaen | I'm not sure how to tell: findObjects((TestFunc)isShipType, fillVector, Rect(getActualPos(), 1200)); |
| 23:47:20 | Watusimoto | if so, you don;t need to do NULL check -- database objects should always be valid. Just check the deleted flag |
| 23:47:26 | kaen | inside of VelocityItem::idle |
| 23:47:29 | Watusimoto | you're good |
| 23:47:36 | Watusimoto | that;s a call to the database |
| 23:48:08 | Watusimoto | you can rely on the database to be a source of good, solid, meaty objects |
| 23:48:19 | Watusimoto | unless you are a vegetarian, of course |
| 23:48:25 | kaen | heh |
| 23:48:28 | kaen | not even a little |
| 23:48:47 | Watusimoto | I am, a little |
| 23:49:20 | kaen | okay, maybe a little |
| 23:49:30 | Watusimoto | so I am using meaty to draw a picture, not as a literal dietary entity |
| 23:49:49 | kaen | I don't know why but that made me laugh audibly. |
| 23:49:51 | Watusimoto | don't eat objects from the database |
| 23:50:26 | raptor | nom nom |
| 23:58:17 | kaen | okay so it's not apparent to me how to "check the deleted flag" |
| 23:58:27 | kaen | are you talking about SafePtr::isValid() ? |
| 23:58:37 | Watusimoto | no |
| 23:58:48 | Watusimoto | if(ship->hasExploded) |
| 23:58:53 | kaen | oh alright |
| 23:58:58 | Watusimoto | sorry; sloppy in my verbiage |
| 23:59:05 | kaen | no problem |
| 23:59:18 | Watusimoto | and, as I think about it, I doubt that will ever come back true |
| 23:59:32 | Watusimoto | but I'm not sure about that |
| 23:59:36 | Watusimoto | so check it |