*** tpb has joined #tp | 00:00 | |
*** ChanServ sets mode: +o tpb | 00:00 | |
*** greywhind has joined #tp | 00:56 | |
*** greywhind_ has quit IRC | 00:56 | |
*** mithro has quit IRC | 02:25 | |
*** mithro has joined #tp | 03:22 | |
*** llnz has joined #tp | 04:53 | |
*** greywhind_ has joined #tp | 04:56 | |
*** greywhind has quit IRC | 04:56 | |
CIA-10 | llnz tpserver-cpp * rc6dc9564d40f /tpserver/playerconnection.cpp: | 05:36 |
---|---|---|
CIA-10 | Check for enough bytes for login frame. | 05:36 |
CIA-10 | Closes bug 1825830. Thanks for the bug nash. | 05:36 |
*** mithro has quit IRC | 06:15 | |
* llnz wanders off | 07:37 | |
llnz | later all | 07:37 |
*** llnz has quit IRC | 07:37 | |
*** greywhind has joined #tp | 08:56 | |
*** greywhind_ has quit IRC | 08:56 | |
tpb | levitation[A] has quit worldforge (Ping timeout: 369 seconds) | 10:15 |
tpb | levitation[A] has joined on worldforge | 10:22 |
*** greywhind_ has joined #tp | 10:56 | |
*** greywhind has quit IRC | 10:56 | |
*** Erroneous has joined #tp | 12:38 | |
*** tuna has quit IRC | 12:42 | |
*** tuna-fish has joined #tp | 14:04 | |
*** tuna-fish is now known as tuna | 14:04 | |
*** greywhind has joined #tp | 14:56 | |
*** greywhind_ has quit IRC | 14:56 | |
*** mithro has joined #tp | 16:19 | |
mithro | nash: looks like llnz closed your bug last night | 16:20 |
nash | heyo mithro | 16:23 |
nash | Yeah | 16:23 |
nash | mithro: Of course I've found some other issues | 16:27 |
mithro | with tpserver-cpp? | 16:27 |
nash | Yeah | 16:28 |
nash | Basically I'm connecting with tp04 | 16:29 |
nash | Partially through implementing at my end... | 16:30 |
nash | but I hit a snag | 16:30 |
nash | Some sequences are in tp04 sequence style, some are int tp03 | 16:30 |
nash | :-( | 16:30 |
mithro | that sounds highly likely | 16:30 |
mithro | anyway have to head to work! | 16:31 |
mithro | see ya later | 16:31 |
nash | Okay - I'll show you code later then ;-) | 16:31 |
*** mithro has quit IRC | 16:52 | |
CIA-10 | nash galaxie * r43b089e82f71 / (tpe_obj.c tpe_obj.h tpe_sequence.c tpe_ship.c): More work for msg and tp04 rewrite. | 17:11 |
CIA-10 | nash galaxie * r710109d40b97 /tpe_orders.c: Update orders for new msg callback. | 17:11 |
CIA-10 | nash galaxie * rd4ea2f237eae /tpe_board.c: Fix board for new msg callback | 17:11 |
CIA-10 | nash galaxie * r8b36e69048c5 /tpe_resources.c: Update resources for new msg callbacks. | 17:11 |
CIA-10 | nash galaxie * r3a032f406c42 /tpe_board.c: Update boards for new msg callback. | 17:11 |
CIA-10 | nash galaxie * r8258551799a1 /tpe_util.c: Fix "limit" on string lengths for rfts. | 17:11 |
CIA-10 | nash galaxie * r8dba335b8271 /tpe_obj.c: Partial support for to04 and tp04 in tpe_obj for receiving objects. | 17:11 |
*** mithro has joined #tp | 17:25 | |
mithro | greywhind: ping? | 17:32 |
nash | mithro: Compare: PlayerAgent::processGetObjectIds vs PlayerView::processGetDesignIds | 17:37 |
mithro | nash: I think I might like to preserve my sanity ;) | 17:38 |
nash | Note GetDesignIds uses teh tp04 protocol for tp04, but GetObjectIds uses tp03 for both | 17:38 |
nash | It's not that insane | 17:38 |
mithro | nash: I'm sure Lee would appreciate a patch | 17:42 |
nash | mithro: Yeah, but he wouldn't appreciate my C++ | 17:42 |
nash | mithro: Besides why the hell is the same code processing sequences in multiple locations? | 17:43 |
nash | Like seriously... | 17:43 |
mithro | nash: that is what I was thinking | 17:43 |
nash | The big "feature" of C++ is OO, and code resuse and crap | 17:43 |
nash | galaxie has one place where sequences are handled: tpe_sequence.c | 17:44 |
nash | Which is why I can't easily work around it in galaxie - as I don't handle different sequences differently | 17:44 |
mithro | I have one place IDSequence.py | 17:52 |
nash | Oh well... time for more bugs | 17:52 |
mithro | nash: yay! :P | 17:58 |
mithro | nash: there is a lot of things in tpserver-cpp which could be made much more OO and nicer | 18:01 |
*** Epyon_ has joined #tp | 18:07 | |
mithro | yay, we have two Epyon's so we can get twice as much cool artwork! | 18:10 |
*** Epyon has quit IRC | 18:21 | |
nash | productivity just halved again | 18:25 |
nash | mithro: See my time post | 18:27 |
mithro | nash: hrm... | 18:28 |
mithro | you mean the bug report? | 18:28 |
nash | Yes | 18:29 |
mithro | nash: have meeting now | 18:29 |
mithro | will talk to you it later | 18:29 |
mithro | just one word, time is "local" to a server | 18:29 |
nash | It should really be defined as such | 18:30 |
nash | And it needs to be tied to turns | 18:30 |
nash | Personally I thing 90% of the timestamps should be either turn numbers or related to turn numbers (eg 32bit turn, 32bit sub-turn) | 18:30 |
Erroneous | only 32 bits!? but what happens on turn 4,294,967,296? :P | 18:46 |
nash | Easy... whoever has the most "type 1 scouts" is declared the winner | 18:50 |
*** greywhind_ has joined #tp | 18:56 | |
*** greywhind has quit IRC | 18:56 | |
nash | mithro: Next thing I need to do for galaxie is support the new object format for TP04 | 19:11 |
mithro | nash: the reason it is a timestamp rather then a turn indicator is for multiple reasons | 19:18 |
mithro | 1 - The timestamp might not change each turn | 19:18 |
mithro | 2 - The timestamp can change multiple times during a turn | 19:18 |
mithro | IE Each time an order changes the timestamp on the associated object changes | 19:19 |
nash | Hence why I said split it | 19:19 |
nash | Second granularity is useless | 19:19 |
mithro | technically it could just be an increasing number | 19:19 |
nash | Even better, since it has NOTHING to do with real time then - make it a monotomically increasing number | 19:19 |
nash | Exactly - the unix time stamp craft just makes it seem like you cna do real time events with it | 19:19 |
mithro | nash: it is easier to use unix time stamps for debugging | 19:20 |
mithro | (IE you can see when the change happened) | 19:20 |
nash | Lovely, for debugging a sever can send what the hell it likes | 19:20 |
nash | But it has NOTHING to do with the protocol definition | 19:20 |
nash | That's like saying "the server must use this format printf" | 19:20 |
nash | It doesn't - don't confuse the issues | 19:20 |
mithro | why is "32bit turn, 32bit sub-turn" any better then "64bit timestamp" ? | 19:22 |
mithro | I like being able to present to the user that the object changed at XYZ | 19:23 |
Epyon_ | Ah, mithro | 19:25 |
nash | Don't - make it an abstract type | 19:26 |
nash | Get rid of the whole "it is a unix timestamp" cruft | 19:26 |
nash | It's just got bad context | 19:26 |
nash | And then you need to define how they are related | 19:26 |
nash | It is universal, or per object or what | 19:26 |
mithro | I'm not sure what you mean by bad context | 19:29 |
mithro | why make it an abstract type? It should be the same on everything | 19:29 |
nash | By saying "it's a unix timestamp" you commit the server to having some relationship to real time | 19:30 |
nash | It also means you are wasting 50 odd bits of data for games | 19:30 |
nash | If it is just a counter of some sort, it means clients implementers know it's general, and servers can choose useful types and useful numbers to put into it | 19:31 |
nash | eg each time and object updates, update the time | 19:31 |
nash | Clients then have fine grained control of what they get | 19:31 |
Epyon_ | mithro, talking about media, what is currently needed? | 19:32 |
mithro | Epyon_: A good start is to look at the following lists, | 19:33 |
mithro | - http://www.thousandparsec.net/tp/dev/documents/mtsec.php#ships_types | 19:33 |
mithro | - http://www.thousandparsec.net/wiki/Art_for_MTSec | 19:33 |
tpb | <http://ln-s.net/18p1> (at www.thousandparsec.net) | 19:33 |
tpb | <http://ln-s.net/TwQ> (at www.thousandparsec.net) | 19:33 |
Epyon_ | Missiles torps too? | 19:33 |
mithro | Epyon_: yeah | 19:34 |
Epyon_ | mithro, http://chaosforge.org/files/tp-missiles-wip.png | 19:34 |
mithro | oh, RFTS could use some graphics too -> http://www.thousandparsec.net/wiki/TP_RFTS | 19:34 |
tpb | Title: TP RFTS - Thousand Parsec Wiki (at www.thousandparsec.net) | 19:34 |
mithro | Epyon_: they are looking cool | 19:34 |
Epyon_ | Torpedoes will either have minimal, or no fins at all | 19:35 |
mithro | Epyon_: I was thinking that Torpedoes should be "fat" | 19:35 |
Epyon_ | Yeah they will | 19:35 |
mithro | they hold so much more explosives | 19:36 |
Epyon_ | Take the last one from the link above and imagine it getting fatter, | 19:36 |
mithro | http://www.thousandparsec.net/tp/dev/documents/mtsec.php#ships_weapons | 19:36 |
tpb | <http://ln-s.net/18p5> (at www.thousandparsec.net) | 19:36 |
mithro | nash: if we define it as an arbitrary type, how do clients have finer grained control? | 19:37 |
mithro | I could see some tiny benefit of letting a server choose what it uses at the "modify counter" - but it seems there is benefits of it being consistent across servers | 19:41 |
mithro | I could see some tiny benefit (*to the server*) of letting a server choose what it uses at the "modify counter" - but it seems there is benefits of it being consistent across servers | 19:41 |
mithro | nash: there must be something I am missing? | 19:42 |
nash | Obviously ;-) | 19:54 |
nash | first: It is currently a unix time stamp | 19:54 |
nash | Which means second granulatiry for events. | 19:54 |
nash | Based on the way turns generate... hopefully servers can do the turn in about 1 seconds | 19:55 |
nash | So essentially it is currently equal to turns anyway | 19:55 |
nash | Even if only a few seconds the granularity is very low | 19:55 |
nash | So there is immediatly something to gain by moving to something more precise... gettimeofday jumps to mind | 19:56 |
mithro | nash: did you miss the "it changes every time a client changes an order (such as added/inserted/modified)" | 19:56 |
nash | Then how is it a "unix timestamp" | 19:56 |
nash | So in that case the bug needs to be updated to "protocol document doesn't make any sense" | 19:56 |
nash | unix timestamp == seconds since epoc | 19:56 |
nash | To implement it correctly then the server can accept no more then one client order per second | 19:57 |
nash | I know my AI can fire off 100+ orders in 1 second | 19:57 |
mithro | nash: yes, I just thought about that problem | 19:58 |
mithro | nash: you are right - that is borked | 19:58 |
nash | Hence it shoudl be a #updates on server or similar | 19:58 |
nash | It's still a security risk... but still | 19:59 |
nash | better then unusable ;-) | 19:59 |
mithro | security risk? | 20:00 |
nash | I can work out information about other players by watching the timestamp | 20:00 |
mithro | nash: why - the timestamp is per-player | 20:01 |
nash | So timestamp changes == # orders added this turn | 20:01 |
nash | Is it | 20:01 |
nash | Okay | 20:01 |
mithro | nash: well, it should be - most servers don't impliment that yet :P | 20:01 |
nash | Then the unix timestamp is even more borked ;-) | 20:01 |
mithro | nash: the reason it changes each time the order is updated is if you use two clients to access a single account | 20:03 |
mithro | hence for caching to work properly the each client needs to know when the other client makes a change | 20:03 |
mithro | anyway - I have another meeting | 20:05 |
nash | That makes sense | 20:07 |
*** Erroneous has quit IRC | 20:24 | |
Epyon_ | mithro, http://chaosforge.org/files/tp-torpedoes-wip.png | 20:33 |
tpb | <http://ln-s.net/18pu> (at chaosforge.org) | 20:33 |
*** greywhind has joined #tp | 20:56 | |
*** greywhind_ has quit IRC | 20:56 | |
*** matthewd has joined #tp | 21:28 | |
mithro | hey matthewd | 21:47 |
mithro | Epyon_: I like them | 21:47 |
* mithro is back btw :P | 21:47 | |
mithro | Epyon_: btw I gave you commit access to SVN right? | 21:48 |
mithro | Epyon_: feel free to commit WIP stuff | 21:50 |
mithro | greywhind: ping? | 21:51 |
greywhind | mithro: pong | 21:59 |
mithro | greywhind: hows the final stuff go? | 21:59 |
mithro | I've got a "intro to the overlay stuff" email half done | 22:00 |
greywhind | mithro: i haven't been able to find the cause of the gap on the side | 22:00 |
mithro | but I have lots of work to do today - so I might not be able to send it until later tonight | 22:00 |
greywhind | the hide commands are working correctly, so i don't know why it's not taking the empty space | 22:00 |
mithro | greywhind: it's a flexible grid sizer? | 22:01 |
mithro | can you force the column width to zero? | 22:01 |
greywhind | mithro: hmm... i can try | 22:01 |
mithro | can you see if the column has any children left? | 22:01 |
greywhind | mithro: will it not show them as children if they're hidden? | 22:01 |
mithro | greywhind: true | 22:01 |
mithro | layout is called after hiding? | 22:01 |
greywhind | yes | 22:02 |
greywhind | unfortunately i have an unexpected 2 page essay to do tonight and a calculus quiz tomorrow, so i'm not sure i can work on this today | 22:02 |
mithro | greywhind: okay | 22:04 |
nash | I like the torps | 22:21 |
nash | Epyon_: that was to you ;-) | 22:21 |
Epyon_ | Well, I like fins, so I really didn't want torps not to have them. But luckily I think I made them distinctive enough from the missiles :P | 22:25 |
Epyon_ | mithro, yeah, I've got SVN access :) | 22:26 |
mithro | Epyon_: commit early and commit often applies to artwork too :P | 22:27 |
mithro | nash: A guy over the other side of the office was talking about RFTS, I went and gave him a Thousand Parsec card | 22:28 |
nash | Cool | 22:33 |
mithro | small world :P | 22:35 |
nash | mithro: It was an australian game don't forget | 22:36 |
mithro | nash: I had no idea | 22:36 |
nash | So it's your patriotic duty to play and anjoy ;-) | 22:36 |
mithro | ahh | 22:43 |
mithro | brb | 22:46 |
*** greywhind_ has joined #tp | 22:56 | |
*** greywhind has quit IRC | 22:56 | |
*** Epyon_ has quit IRC | 23:36 | |
*** tuna has quit IRC | 23:36 | |
*** TBBle_ has quit IRC | 23:36 | |
*** TBBle has joined #tp | 23:37 | |
*** Epyon_ has joined #tp | 23:38 | |
*** tuna has joined #tp | 23:38 | |
*** TBBle_ has joined #tp | 23:38 | |
*** TBBle_ has quit IRC | 23:39 | |
nash | mithro: IS there any documentation on getting object properties in tp04 | 23:48 |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!