| *** tpb has joined #tp | 00:00 | |
| *** ChanServ sets mode: +o tpb | 00:00 | |
| *** mithro has joined #tp | 00:28 | |
| mithro | howdy people | 00:29 |
|---|---|---|
| mithro | TBBle: do you have a sf.net account? | 00:30 |
| nash | heyo mithro | 00:38 |
| mithro | hey nash | 00:38 |
| nash | how is life? | 00:38 |
| mithro | tirering | 00:42 |
| nash | Sleep more ;-) | 00:43 |
| *** mithro has quit IRC | 01:38 | |
| *** mithro has joined #tp | 01:55 | |
| mithro | howdy people | 02:03 |
| mithro | br | 02:11 |
| mithro | b | 02:11 |
| * jotham drops a pin | 02:40 | |
| jotham | *plink* | 02:40 |
| * nash hands jotham his pin. | 02:52 | |
| nash | You dropped this | 02:52 |
| jotham | :\ | 02:52 |
| nash | It's on the floor - it could be dangerous. | 02:55 |
| mithro | nash: you'll like this probably | 03:03 |
| nash | mithro: I hate it allready | 03:03 |
| nash | And I don't know what it is | 03:03 |
| mithro | http://www.thousandparsec.net/tp/dev/documents/protocol4.php | 03:03 |
| tpb | <http://ln-s.net/JqO> (at www.thousandparsec.net) | 03:04 |
| nash | mithro: Sweet | 03:05 |
| mithro | nash: the patches seem to be taking a while to pus | 03:05 |
| nash | mithro: Things are a bit wacky at the moment - partially through moving to command line processing | 03:07 |
| CIA-20 | [email protected] * web/dev/documents/protocol4.php : Added first dump of Object Properties. | 03:10 |
| CIA-20 | [email protected] * web/dev/documents/protocol4.php : More small additions from the Object properties thread. | 03:10 |
| CIA-20 | [email protected] * web/ (18 files in 2 dirs): Added more from the Object Properties thread. | 03:10 |
| CIA-20 | [email protected] * web/dev/documents/ (17 files): Lots of updates to the Metaserver section. | 03:10 |
| CIA-20 | [email protected] * web/dev/documents/protocol4.php : Added meeting email. | 03:10 |
| CIA-20 | [email protected] * web/ (6 files in 5 dirs): Inital Page. | 03:10 |
| CIA-20 | [email protected] * web/dev/documents/ (17 files): Added Lees stuff and reformatted a little | 03:10 |
| nash | So it currently connects without a gui... but things don't work until turn 2... | 03:11 |
| nash | Is there protocol support for multiple games on the same server yet? | 03:27 |
| *** Demitar has quit IRC | 03:27 | |
| nash | mithro: Packet versioning is wrong - either the format or the example is wrong | 03:31 |
| mithro | nash: protocol support? | 03:32 |
| nash | mithro: Ahh - is that what the @ is for? You need to document that. | 03:32 |
| mithro | nash: yes | 03:33 |
| mithro | it's kind of an undocumented tpserver-py extension | 03:33 |
| * nash notes you guys need to spend less time on undocumented extensions, and more time on implementing documented things | 03:34 | |
| mithro | nash: it was added a long long time ago | 03:34 |
| CIA-20 | [email protected] * web/dev/documents/protocol4.php : Start of actual specification of Object Description. | 03:34 |
| mithro | nash: bah, atleast we have a protocol document :) | 03:35 |
| nash | No you don't. | 03:35 |
| nash | You have a draft one. | 03:35 |
| nash | How do I send the filters request for starters? | 03:35 |
| mithro | nash: tp03 is pretty well documented | 03:36 |
| nash | So is MTSec | 03:36 |
| mithro | nash: any idea how to fix combat in MTSec? I tried to adapt minisec type combat but it didn't work | 03:37 |
| CIA-20 | [email protected] * web/dev/documents/protocol4.php : Make it more clear for Nash. | 03:37 |
| nash | mithro: I could put one together | 03:38 |
| nash | mtsec is easy - just make ships fire simultaneously... | 03:39 |
| nash | foreach ($ship in @ships) { | 03:39 |
| mithro | yes, but how do you determin damage assignment | 03:39 |
| mithro | thats the problem i ran into | 03:39 |
| nash | Ahh... Well multiple order queues woudl be nice so you can assign. | 03:40 |
| mithro | the Resolving Damage section needs to be rewritten | 03:40 |
| nash | However otherwise a missle targets the largest ship it can destroy OR the least healthy armed ship | 03:41 |
| mithro | armor+dodge break the idea of "assign it to least damaged ship first) | 03:41 |
| nash | (in that order) | 03:41 |
| mithro | assigning what to attack is not something I want in MTSec | 03:42 |
| nash | mithro: I can understand the protocol - just what you wrote it wrong: | 03:42 |
| mithro | brb | 03:42 |
| nash | TP<major byte><minor byte> then you say TP03 -> Major 3 | 03:42 |
| mithro | ahh your reading it wrong | 03:45 |
| mithro | tp03 == version string | 03:46 |
| mithro | so tp03 is tp\0x03\0x00 | 03:46 |
| mithro | how can I make that clearer? | 03:48 |
| nash | So if the version is tp<03><00> what is the version? | 03:51 |
| nash | Is the major the first or the second byte? | 03:52 |
| nash | Because you say TP<major><minor> then use TP<0><4> as tp<minor><major> | 03:52 |
| mithro | the major bytes is the first byte, the minor byte is the second byte - so in the protocol you would have \0x84\0x80\0x03\0x00 for the version 3 of the protocol | 03:55 |
| mithro | and \0x84\0x80\0x04\0x00 for the version 4 of the protocol | 03:55 |
| mithro | you can do a s/tp03/Thousand Parsec Protocol Version 3/ in the document | 03:56 |
| nash | Right... Now look at the example "tp04 with major 4 and minor 0". So that reads to me as TP<minor == 0><major == 4> | 03:57 |
| nash | Unless of course you subtract 4 from the major version, and add 4 to the minor version just for kicks... | 03:58 |
| mithro | you should read that as "Thousand Parsec protocol version 0.4 has a major byte 4 and a minor 0" | 03:58 |
| mithro | 0.<major>.<minor == frame version> | 03:59 |
| nash | Nope.. still doesn't make sense. | 04:01 |
| nash | Seriously - look at what those paragraphs say - carefully - not what you think it says - what it actually says | 04:02 |
| * mithro rewrites it | 04:03 | |
| mithro | The TP03 header will be changed to a "TP<protocol version byte>< frame version byte>". The bytes are in binary not ASCII. | 04:04 |
| mithro | As new versions of frames are added the frame version byte will be incremented. (They all start at zero for the first release of a major protocol version.) A frame will not change in an non-backwards compatible way within a major protocol. | 04:04 |
| mithro | Although this frame type versioning was only introduced in tp04 protocol. The method can be used by tp03 clients with a protocol version byte set to 3 and frame version byte set to 0. | 04:04 |
| mithro | that better? | 04:05 |
| nash | thats fine... now DON'T use an example which has the minor and major fields swapped | 04:05 |
| CIA-20 | [email protected] * web/ (4 files in 2 dirs): Try to make this make more sense to other people. | 04:16 |
| mithro | nash: btw that page is very much a mish mash of emails at the moment | 04:21 |
| mithro | anyway I have to run | 04:22 |
| mithro | see ya | 04:22 |
| *** mithro has quit IRC | 04:32 | |
| *** nash has quit IRC | 04:46 | |
| *** tpb has joined #tp | 06:01 | |
| *** ChanServ sets mode: +o tpb | 06:01 | |
| *** Demitar has joined #tp | 06:06 | |
| *** Demitar has quit IRC | 07:52 | |
| *** Demitar has joined #tp | 07:54 | |
| *** llnz has joined #tp | 08:07 | |
| *** mithro has joined #tp | 08:53 | |
| mithro | howdy people | 08:53 |
| jotham | hey man | 08:53 |
| mithro | jotham: how goes our wonderful battleviewer? | 08:54 |
| jotham | ok | 08:55 |
| mithro | so where are we at atm? | 08:55 |
| jotham | final bit of the event stuff, then asking piman to optimise my laser code, then put in the forward/back/reward and summary screen | 08:56 |
| jotham | and after that add a starfield and something from the nasa site | 08:56 |
| jotham | for a bit of atmosphere | 08:56 |
| jotham | and when thats all done and you are ok with it, add a battle start animation/graphical build sequence i have in mind, and maybe have a crack at doing osme new ship graphics | 08:57 |
| jotham | anywya it's bath time | 08:57 |
| mithro | have fun | 08:58 |
| CIA-20 | [email protected] * web/dev/documents/ (16 files): | 08:58 |
| CIA-20 | Trying to get the Object Description stuff working.: | 08:58 |
| CIA-20 | Added some examples. Added a crappy graph example. | 08:58 |
| *** tuna-fish has quit IRC | 10:16 | |
| *** mithro has quit IRC | 11:20 | |
| * llnz wanders off | 12:40 | |
| llnz | later all | 12:40 |
| *** llnz has quit IRC | 12:40 | |
| *** tuna-fish has joined #tp | 19:07 | |
| *** tuna-fish has quit IRC | 21:07 | |
| *** tuna-fish has joined #tp | 21:11 | |
| *** nash has joined #tp | 22:27 | |
| *** mithro has joined #tp | 22:55 | |
| mithro | howdy | 22:55 |
| nash | heyo | 22:59 |
| nash | how is life? | 22:59 |
| mithro | still tirering | 23:02 |
| mithro | feel free to add too [tp-devel] Protocol 4 discussion document issues | 23:02 |
| nash | I am as we speak | 23:03 |
| mithro | okay | 23:06 |
| mithro | the object description stuff needs a lot of work | 23:13 |
| nash | I haven't looked at that yet. There is no contecxt to how it works | 23:19 |
| * nash also worries it is uimplementable in a sane way | 23:19 | |
| mithro | sane way? | 23:20 |
| nash | I just worry to much meta information will need to be in the clients to understand it. | 23:20 |
| mithro | well, what does a client really need to understand? | 23:21 |
| mithro | an AI needs lots to understand, a human interface isn't that bad | 23:23 |
| nash | Not if you want a decent interface I think... but at this point I'm talking out of my arse... | 23:24 |
| mithro | well, i'm intrested to know what a "decent" interface is | 23:24 |
| nash | Well decent probably means really good in this case ;-) | 23:25 |
| mithro | nash: and "not bad" too! | 23:25 |
| nash | Basically it would be nice if the client would take care of some of the micromanagement, to do that it needs to `know' what a lot of the orders mean | 23:25 |
| nash | So for instance if I set a fleet to colonise a planet, if the client knows that you need to orbit a world to colonise it, it can quickly slip in the move order for you... Bombing would be similar... However using the 'JumpTo' order it shouldn't add a moveto order. | 23:27 |
| mithro | that could be done server side? | 23:27 |
| mithro | any others? | 23:29 |
| nash | I agree it could be done server side, but the advantage of doing it client side is I can tweak it after the code has done it. So I see the new move order and maybe jiggle it to avoid mine fields or interception or fuel usage or something | 23:30 |
| nash | As for others.. I could come up with a list, but I don't think it would change anything | 23:31 |
| mithro | nash: could you come up with the list anyway? | 23:31 |
| nash | Colonisation, bombing, mine laying, remote mining, cargo transport, cargo transfer, | 23:32 |
| nash | umm... I'm sure I can think of a case for basically every order which has an argument. | 23:32 |
| nash | The other thing if we have the code in the server it needs to be defined for every game... | 23:33 |
| nash | One thing I like about my client setup at the moment is I can get the AI to do some micromanagement for me... which i htink is cool. | 23:35 |
| mithro | it would be good if you could come up with some "users stories" | 23:36 |
| nash | Well you have 2 | 23:36 |
| nash | Anyway, I'll wait to I see it. One of the dangers of a general protocol is taht the specifics need to be somewhere. | 23:37 |
| nash | bbs | 23:37 |
| mithro | okay | 23:38 |
| nash | and back | 23:40 |
| mithro | nash: well, those are good, but I'm going to forget them if you don't send them somewhere :) | 23:40 |
| CIA-20 | [email protected] * web/ (21 files in 2 dirs): | 23:41 |
| CIA-20 | Small updates.: | 23:41 |
| CIA-20 | Fail frame - extra error codes, note about leaking information, GRS addition | 23:41 |
| CIA-20 | meta protocol - ln/sn update | 23:41 |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!