| *** tpb has joined #tp | 00:00 | |
| *** ChanServ sets mode: +o tpb | 00:00 | |
| *** epyon-sakura has joined #tp | 00:35 | |
| *** epyon-sakura has quit IRC | 01:23 | |
| *** nash has joined #tp | 01:31 | |
| *** epyon-sakura has joined #tp | 01:42 | |
| *** verhoevenv_ has quit IRC | 01:56 | |
| *** Erroneous has quit IRC | 02:12 | |
| *** epyon-sakura has quit IRC | 02:40 | |
| *** epyon has quit IRC | 02:40 | |
| *** epyon-okami has quit IRC | 02:40 | |
| *** epyon-sakura has joined #tp | 02:54 | |
| *** epyon-kitsune has joined #tp | 02:59 | |
| *** Epyon has joined #tp | 03:01 | |
| epyon-kitsune | llnz: is there any reason we need the set of active connections? | 03:09 |
|---|---|---|
| epyon-kitsune | maintaining a set of them will violate thread separation | 03:09 |
| llnz | it should be possible to pass that down to asio | 03:11 |
| epyon-kitsune | great :) | 03:11 |
| llnz | you will need connection objects though | 03:11 |
| epyon-kitsune | actually not asio, but shared pointers | 03:12 |
| epyon-kitsune | they allow objects to live because asio will be holding them in the async loop | 03:12 |
| epyon-kitsune | yes I know | 03:12 |
| llnz | ok, can we get some design text/diagrams? | 03:12 |
| epyon-kitsune | but I won't need socket objects, nor distinction between http etc diagrams | 03:13 |
| epyon-kitsune | err classes | 03:13 |
| epyon-kitsune | I'll try to do a diagram for the next blog update | 03:13 |
| *** glew has quit IRC | 03:13 | |
| llnz | col | 03:13 |
| llnz | cool, even | 03:13 |
| epyon-kitsune | There'll be a single Server class that'll be responsible for the threaded io_service launch, and will be creating 5 acceptor classes | 03:14 |
| epyon-kitsune | these will have a callback that will pass the accepted sockets to the server which will create a proper (Admin or Player) connection class that will be thrown into the asio proactor again | 03:15 |
| llnz | ok | 03:15 |
| llnz | btw, it's probably double the number of listen sockets open | 03:16 |
| llnz | as ipv6 sockets no longer bind to IPv4 as well | 03:16 |
| llnz | (at least on debian) | 03:16 |
| epyon-kitsune | the server will have an explicit state enum that will tell if we're processing a turn or running it | 03:16 |
| llnz | cool | 03:17 |
| epyon-kitsune | llnz: yeah, that also means will need two separate acceptor classes | 03:17 |
| llnz | really? | 03:17 |
| epyon-kitsune | (or maybe I'll use a template argument for that) | 03:17 |
| llnz | the only difference is the address class | 03:17 |
| epyon-kitsune | considering that the acceptor class is very slim, I guess I could template it based on the IP protocol | 03:18 |
| llnz | and don't forget that it can be set to an explict bind address as well | 03:18 |
| epyon-kitsune | hmm, correction : | 03:20 |
| epyon-kitsune | seems that the bind method I use is independent of IP protocol | 03:20 |
| epyon-kitsune | it resolves the passed address and chooses protocol based on that | 03:21 |
| llnz | oh, that was the other thing, i would like to see code | 03:21 |
| epyon-kitsune | llnz: where should I push it? | 03:22 |
| llnz | the refactor branch on git.tp.net if you want | 03:23 |
| epyon-kitsune | also, just to be clear -- I'm building the ASIO server besides the existing implementation | 03:23 |
| llnz | a branch on github if you have to | 03:23 |
| epyon-kitsune | (it seems easier) | 03:23 |
| llnz | cool | 03:23 |
| *** epyon-sakura has quit IRC | 04:05 | |
| *** StupidIncarnate has joined #tp | 05:16 | |
| * llnz wanders off | 05:20 | |
| llnz | later all | 05:20 |
| *** llnz has quit IRC | 05:20 | |
| *** tansell-laptop has quit IRC | 05:31 | |
| *** bisc has joined #tp | 06:54 | |
| bisc | tansell: ping | 07:38 |
| tansell | bisc, pong | 07:39 |
| bisc | tansell: would be glad to get your reviews on open issues (again, except 59001and 54002) | 07:40 |
| tansell | bisc, looking at 53001 | 07:47 |
| tansell | freeze/thaw doesn't effect window size/position | 07:47 |
| tansell | it effects the calculation of dynamic sizers | 07:47 |
| bisc | tansell: oh, well. Then I'll delete these calls. Any way to make window calculate its size, but not display immediately on screen? | 07:49 |
| tansell | bisc, not to my knowledge | 07:49 |
| bisc | tansell: ok. But I personally didn't notice this window appearing in wrong position before movement. Do you think calling Show before Move is unacceptable? | 07:50 |
| tansell | bisc, is the window a fixed size? | 07:51 |
| tansell | (or could it be a fixed size?) | 07:51 |
| bisc | tansell: no, it's not fixed. Its size greatly depends on 1) length of available filters 2) whether some filters are selected. And checklist boxes dynamically resize. We can try setting fixed size, but then we risk getting some filters labels not fit in. | 07:53 |
| tansell | bisc, shouldn't there be a scroll bar if there are too many filters? | 07:56 |
| bisc | tansell: not too many, but too long filters. Currently no, the window is resized. Do you think I should apply horizontal scrollbar there and set fixed size? | 07:57 |
| tansell | bisc, you sure? | 08:00 |
| tansell | I can't see code which does the resizing? | 08:00 |
| bisc | tansell: | 08:01 |
| bisc | tansell: aren't they resized because of sizers? | 08:02 |
| bisc | tansell: let be check this | 08:02 |
| tansell | okay | 08:02 |
| bisc | tansell: I have found out these facts: 1) no fixed size for filter frame (and its components) is set in either code or xrc. 2) both horizontal and vertical sizes are currently by lenth and number of filters. | 08:13 |
| bisc | tansell: so, there are 2 ways to handle it : 1) set fixed size, call move before show 2) set no fixed size, call move after show | 08:14 |
| bisc | tansell: ...are currently _determined_ by lenth and number of filters. | 08:15 |
| bisc | tansell: and one more interesting thing: calling move after show makes the filter frame align close to the screen border, not going over it (while theoretically it should). | 08:19 |
| bisc | tansell: so, if we have this Messages panel in another part of screen -- we'll have to check whether this frame is out-of-screen. But calling Move after Show solves it? | 08:20 |
| bisc | tansell: misprint. not ?, but ! | 08:20 |
| tansell | bisc, hrm.... | 08:36 |
| tansell | bisc, we don't really want the window to go off the screen do we? | 08:37 |
| bisc | tansell: of course we don't. | 08:37 |
| tansell | so I must mis-understand what you are saying then | 08:37 |
| bisc | tansell: yeah, sorry, let me refolmulate. | 08:38 |
| bisc | tansell: two global options to organize the window: 1) move before show (with explicitly set coordinates) 2) move after show (with coordinates taken from window). Currently we have the second and you don't like it. I say that there is problem: filter frame can be off screen. If taking the first option, we will need to solve this problem with explicit checking whether the window is out of screen. | 08:42 |
| bisc | tansell: and if we leave the second option, this is done automatically. | 08:42 |
| bisc | tansell: don't know why it is done automatically, but the frame doesn't want to go off screen if we call Move when the window is shown. | 08:46 |
| bisc | tansell: have my words become more clear? | 08:51 |
| *** null_000 has joined #tp | 09:02 | |
| null_000 | hi all | 09:03 |
| *** nash has quit IRC | 09:10 | |
| *** StupidIncarnate has quit IRC | 09:29 | |
| *** JLP has quit IRC | 10:28 | |
| *** JLP has joined #tp | 10:59 | |
| *** JLP has joined #tp | 10:59 | |
| *** null_000 has quit IRC | 11:28 | |
| *** glew has joined #tp | 12:16 | |
| ezod | glew: hey | 12:49 |
| *** verhoevenv has joined #tp | 12:50 | |
| ezod | glew: still no github forks? | 12:54 |
| *** bisc has quit IRC | 13:27 | |
| ezod | so how is everyone's GSoC projects going? | 13:28 |
| ezod | don't work in a bubble, let's hear about it :) | 13:28 |
| alanp | but bubbles are so much fun | 13:29 |
| verhoevenv | Like this? http://www.youtube.com/watch?v=ART2V2ICxZI | 13:44 |
| tpb | Title: YouTube - My Bubbles (at www.youtube.com) | 13:44 |
| *** JLP has quit IRC | 14:12 | |
| *** JLP has joined #tp | 14:12 | |
| *** JLP has joined #tp | 14:12 | |
| *** Agon has joined #tp | 15:54 | |
| Agon | hello | 16:01 |
| Agon | Is the velocity of an object in tp03 used to describe the direction in which eg. a fleet moves or can it be used for that? | 16:04 |
| *** Erroneous has joined #tp | 17:23 | |
| *** null_000 has joined #tp | 17:57 | |
| *** null_000 has quit IRC | 18:17 | |
| *** llnz has joined #tp | 20:10 | |
| llnz | morning all | 20:11 |
| ezod | hey llnz | 20:12 |
| llnz | hi ezod | 20:12 |
| Agon | hi llnz | 20:14 |
| llnz | hi Agon | 20:14 |
| llnz | Agon: how are you going? | 20:14 |
| Agon | llnz: Good, I understand now how to get ObjectParameters. But I have a question about what ObjectParameter::getName() returns? | 20:17 |
| Agon | I want to identify what ObjectParameter I have. | 20:17 |
| llnz | ok, first a couple of things: | 20:19 |
| llnz | did you know the libtpprotocol had doxygen documentation? | 20:19 |
| llnz | did you know that documentation is online | 20:19 |
| llnz | ? | 20:19 |
| Agon | oh ok, thanks, found it | 20:21 |
| Agon | well, "Gets the name of this ObjectParameter. " is not really helpful. Is it the class name or some protocol name? | 20:24 |
| *** null_000 has joined #tp | 20:28 | |
| null_000 | hi all | 20:29 |
| llnz | it's the name the server has said that the particular object parameter is called | 20:29 |
| llnz | so it could be called "Position" and be a Position3dObjectParam | 20:29 |
| llnz | hi null_000 | 20:29 |
| null_000 | llnz: hi | 20:29 |
| null_000 | llnz: did my answers help? | 20:31 |
| llnz | just reading it now | 20:31 |
| null_000 | ok | 20:33 |
| *** bisc has joined #tp | 20:51 | |
| llnz | null_000: reply sent | 20:55 |
| null_000 | reply read | 20:56 |
| null_000 | if you need any more info just ping me | 20:56 |
| llnz | yeah, will do | 20:57 |
| null_000 | llnz: thanks for taking your time to check this out | 21:00 |
| llnz | found it | 21:11 |
| llnz | objectview doesn't get updated | 21:11 |
| llnz | will fix it tonight | 21:11 |
| *** StupidIncarnate has joined #tp | 21:24 | |
| null_000 | great! | 21:43 |
| StupidIncarnate | great indeed? | 21:43 |
| alanp | nice | 22:36 |
| StupidIncarnate | does anyone know how to get the name of an object type if you have the typeid? | 23:01 |
| StupidIncarnate | tried this, but wants more arguments objdesc = objects.ObjectDesc()[obj.subtype] | 23:01 |
| *** Vadtec has quit IRC | 23:10 | |
| *** Vadtec has joined #tp | 23:13 | |
| *** Epyon has quit IRC | 23:16 | |
| *** Epyon has joined #tp | 23:16 | |
| *** bisc has quit IRC | 23:22 | |
| StupidIncarnate | bah, nvm. Mispelled | 23:25 |
| *** null_000 has quit IRC | 23:51 | |
| *** alanp has quit IRC | 23:53 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!