| *** tpb has joined #tp | 00:00 | |
| *** ChanServ sets mode: +o tpb | 00:00 | |
| nash_ | anyone around? | 00:49 |
|---|---|---|
| *** nash has quit IRC | 02:38 | |
| *** nash has joined #tp | 02:39 | |
| mithro | nash: am now | 03:29 |
| nash_ | still there? | 03:53 |
| * nash_ pokes mithro | 03:54 | |
| mithro | yes | 03:54 |
| mithro | if you say my name my xchat flashes madly at me :) | 03:55 |
| nash_ | They generally do... ;-) | 03:56 |
| nash_ | Anyway... silly question... why is the server sending me multiple objects which are the same? | 03:58 |
| mithro | hrm? | 03:58 |
| mithro | example? | 03:59 |
| nash_ | I'm sending the server a request (0.4.0) for all objects. | 03:59 |
| mithro | how? | 03:59 |
| tpb | Somebody said how is the test, mithro | 03:59 |
| nash_ | I then take the response, and send it straight back to the server asking for details of all the objects in the list... | 03:59 |
| nash_ | And I get many objects back... | 04:00 |
| nash_ | Including 5 object '0's (name: The Universe), and 2 "Milky Way Galaxys" | 04:00 |
| mithro | did you check your list of get objects | 04:00 |
| nash_ | I haven't yet, but as I said, I litterally pass the list of objects I get from the server and hand it straight back. | 04:01 |
| mithro | nash: what arguments did you give the get object ids? | 04:01 |
| nash_ | The list from the server has 9 objects. I get 6 back, and three 'message failed' messages | 04:01 |
| mithro | Get ID Sequence Frame | 04:02 |
| mithro | Get ID Sequence frame consist of: | 04:02 |
| mithro | * a SInt32, the sequence key | 04:02 |
| mithro | * a UInt32, the starting number in the sequence | 04:02 |
| mithro | * a SInt32, the number of IDs to get | 04:02 |
| mithro | so you sent (-1, 0, -1) | 04:03 |
| nash_ | Oh I'm ignoring the sequence frame... | 04:03 |
| mithro | ? | 04:03 |
| nash_ | MsgListOfObjectIDs | 04:04 |
| nash_ | number 31 | 04:04 |
| nash_ | Wait a second... hmm.. | 04:04 |
| mithro | my recommendation is to print out a list of ids | 04:06 |
| nash_ | This really doesn't make sense then... | 04:06 |
| mithro | btw remeber the id sequence returns a list of (id, last mod time) | 04:07 |
| mithro | ie | 04:07 |
| mithro | [[0, 0], [1, 3456734], [5, 2345677543]] | 04:07 |
| mithro | not | 04:07 |
| mithro | [[0, 1, 5], [0, 3456734, 2345677543]] | 04:08 |
| nash_ | this is weird. | 04:08 |
| nash_ | Okay - startup, I just want to get the lot... | 04:09 |
| mithro | so your sending a Get Object ID Sequence Frame? | 04:09 |
| nash_ | No, it's a GetByID frame | 04:10 |
| mithro | id 28 | 04:10 |
| nash_ | meg #5 | 04:10 |
| nash_ | msg #5 that is | 04:10 |
| mithro | first you need to get which ids exist right? | 04:11 |
| nash_ | yes | 04:12 |
| mithro | which you are using the Get Object ID Sequence Frame to do | 04:13 |
| mithro | (ID 28) | 04:13 |
| nash_ | which is MsgGetObjectIDs... which returns a sequence frame? | 04:13 |
| mithro | which returns an ID Sequence frame (ID 31) | 04:14 |
| nash_ | Right... damn, I need to expand my message parser. | 04:16 |
| nash_ | Out of curisity, has anyone tried to port the server to a platform that doesn't emulate unaligned loads? | 04:16 |
| mithro | unaligned loads? | 04:16 |
| mithro | you mean on a platform which doesn't have bytes as it's smallest value? | 04:17 |
| nash_ | An int which is not aligned to a address which is a multiple of sizeof(int) is illegal operation at the hardware level. Archs like x86 catch it in microcode, do two loads, align and producde something that works. | 04:18 |
| nash_ | The reason I ask is that strings in the middle of messages mean you have values which aren't aligned from then on (75% of the time) | 04:18 |
| nash_ | And it's expensive to emulate on x86, on archs like MIPS it generates a bus error, unless the kernel emulates (which is ~1000x slower) | 04:19 |
| mithro | it's only a real problem if you are trying to use the same datastructures for in-memory as sending over the wire (which is bad in my opinion) | 04:19 |
| nash_ | Not quite... You need to de-serialise, and since you are sending in binary formats | 04:19 |
| nash_ | So you are doing something like <int><3char><int>. | 04:20 |
| mithro | yes, but de-serialising is simple bit/byte shifting really | 04:20 |
| nash_ | The only wat to get that second int safely in C (or C++) is to do a memcpy or two integer accesses, and a annoying shifting | 04:20 |
| mithro | de-serialising by using memcpy and a C struct is bad | 04:20 |
| * nash_ never mentioned structs | 04:21 | |
| nash_ | What is wrong with memvpy (aside from performance)? | 04:21 |
| mithro | because the format on the wire might change but your internal data structures shouldn't necesarily | 04:22 |
| nash_ | Yes, but that has nothing to do with my point/question. | 04:22 |
| mithro | well the only reason that non-aligned stuff should byte you is if you are trying to use the same right? | 04:23 |
| mithro | s/byte/bite/ | 04:23 |
| mithro | because otherwise your internal data structures would be all aligned correctly? | 04:23 |
| nash_ | For instance on the wire for objects you have <int (type)><int (oid)><int strlen)>strlen*<char><otherdata> | 04:23 |
| nash_ | Internal data structures are fine... I'm talking about parsing the data that arrives from a message. | 04:24 |
| mithro | get 4 bytes -> put in internal data structure at type | 04:24 |
| mithro | get x bytes -> put in internal data structure at xyz | 04:25 |
| mithro | ? | 04:25 |
| nash_ | So copy from buffer one byte at a time, aligning as you go? | 04:25 |
| mithro | how else would you do it? | 04:25 |
| mithro | (you could copy strings a whole bunch at a time I guess) | 04:25 |
| nash_ | Well if everything was aligned to 32bits, on 98% of modern archs, you can just seek in the buffer to get what you want, and don't need to process the whole thing... | 04:26 |
| nash_ | The only that ruins this is strings | 04:26 |
| nash_ | If they were padded, it would all be good | 04:26 |
| mithro | why can't you seek as is? most modern archs have some form of byte access support (it's just so important for strings) | 04:27 |
| mithro | and wouldn't it be tempting to use the same structures if you could just use a memcpy :) | 04:28 |
| nash_ | No, must modern archs emulate anything smaller then the hardware bus width, unaligned loads may or may not be emulated | 04:28 |
| * nash_ is looking at tpserver-cpp now... | 04:28 | |
| nash_ | And packInt* uses memcpy | 04:29 |
| nash_ | You have an x86 I assume | 04:30 |
| nash_ | ? | 04:30 |
| mithro | yes | 04:30 |
| mithro | and ppc | 04:30 |
| mithro | o and amd 64 | 04:30 |
| nash_ | amd64 == x84 for this context | 04:30 |
| nash_ | On x86 the following may be allowed: | 04:30 |
| nash_ | short a[10]; | 04:31 |
| nash_ | int i = *((int *)a[3]); | 04:31 |
| nash_ | depending on if the unaligned register is set on the bus register. | 04:31 |
| nash_ | If it's not set... SIGBUS on linux | 04:31 |
| nash_ | Other archs always genrate or never generate... | 04:32 |
| mithro | okay, so where is that used? | 04:32 |
| nash_ | If the protocol is adjusted so that strings are padded to the nearest 4, means you don't need to memcpy data out (4 bytes at a time!) you can just assign it out... | 04:32 |
| mithro | but you waste bytes then :) | 04:33 |
| nash_ | Pfft | 04:33 |
| nash_ | MTU is 80+ bytes anyway - most of the messages are smaller - who cares? | 04:34 |
| mithro | who cares about byte alignment, only some weird person would be using an archic language like C ;) | 04:34 |
| nash_ | or C++... | 04:35 |
| nash_ | Which has exactly the same problem | 04:35 |
| * nash_ notes tpserver is using realloc and memcpy to pack and unpack data... | 04:35 | |
| * mithro notes he didn't write tpserver-cpp :) | 04:35 | |
| * nash_ notes he avoids the reallocs ;-) | 04:35 | |
| * mithro notes he doesn't like C/C++ :) | 04:36 | |
| mithro | btw, is it really bothering you that much? | 04:36 |
| nash_ | It just seems silly. Most protocols either are string based to avoid the problem all together, or are aligned for fast acess. tp03 as it is written has neither property | 04:37 |
| mithro | because I could make you cry by pointing out that in protocol version 1 it was word aligned :) | 04:37 |
| nash_ | I know | 04:38 |
| mithro | from protocol.php | 04:38 |
| mithro | All data will be 32 bit aligned. Strings will be prefixed by the 32 bit integer length (include null terminator) and then padded with nulls ('\0') to the next 32 bit boundary (if necessary). | 04:38 |
| nash_ | Which is kinda why I was curious why it took a step backwards | 04:38 |
| nash_ | (and requiring at least one null means you can strdup straight out of a message too ;-) | 04:39 |
| mithro | you have a length, you shouldn't be tempted to use a null terminater too | 04:40 |
| nash_ | Sorry, that should be 'nil' terminated... NULLs are (sizeof(void*), NIL is the first ASCII character | 04:40 |
| nash_ | strndup gives you best of both worlds ;-) | 04:40 |
| nash_ | But the termination issue is minor compared to the alignment issue | 04:40 |
| mithro | how often does unalignment occur? | 04:41 |
| nash_ | 100% of packets containing a string | 04:42 |
| nash_ | Which includes all Objects for instance | 04:42 |
| mithro | couldn't you just pad right after a string till it aligns again? | 04:43 |
| mithro | and what happens if the smallest unit is 64? | 04:44 |
| nash_ | That would make the protocol aligned again - yes.. all good. | 04:44 |
| mithro | wouldn't it break on that? | 04:44 |
| mithro | s/you/*you*/ | 04:44 |
| nash_ | As for 64bit archs... nope... loading an 4 byte align type if it is 4 byte aligned is safe. | 04:45 |
| nash_ | Same as loading a 16 bit short ona 32 bit arch... all fine | 04:45 |
| * nash_ notes you have 64 bit types mixed in there as well, which means you should really 8 byte align everything.. but they are relatively rare | 04:46 | |
| mithro | why? | 04:46 |
| mithro | wouldn't the 64 bytes be aligned to 8 byte boundaries? | 04:46 |
| nash_ | Not in the current protocol | 04:47 |
| nash_ | Or just fixing what we have been talking about | 04:47 |
| mithro | what happens if we add a 128bit int, would we then need to align to 16 byte boundaries? | 04:47 |
| nash_ | Yep... | 04:47 |
| nash_ | Now you see why string protocols are popular ;-) | 04:47 |
| nash_ | Still safe 32 bit access is going to be with us for a long time just to support existing software... *cough* *windows* *cough* *packed* *cough* *structs* | 04:48 |
| mithro | it's just a "packed" format, just because it bears some reseamblance to memory organisation doesn't mean it is :) | 04:48 |
| nash_ | Yes, but my point s your format is as slow as string format, but as annoying to access as a binary one... Worst of both worlds | 04:49 |
| mithro | i find it less annoying then string formats - as you know exactly where everything will be | 04:50 |
| mithro | (ie you know a int is exactly 4 bytes long) | 04:50 |
| mithro | but i guess each to their own | 04:51 |
| nash_ | Yes, it is even better if you can use that int as int, not a set of 4 random bytes that can;t access | 04:51 |
| nash_ | without a memcpy into another buffer | 04:52 |
| mithro | nash: when your client becomes really popular you'll then be able to force us to do word aligned stuff :) | 04:52 |
| nash_ | The earlier it is fixed the better... | 04:53 |
| mithro | btw what performance problems is this causing you? | 04:53 |
| nash_ | I've already mostly solved the problem... but memcpys are annoying | 04:53 |
| nash_ | And slow | 04:53 |
| nash_ | With one line 'aligned to 4 bytes' most archs can be quick on everything but 64bit types... | 04:54 |
| nash_ | And it saves casting and alignment issues on bigger types | 04:54 |
| mithro | but i bet you'll see the following, memcpy(<my data structure>, <network buffer>) | 04:55 |
| nash_ | So? I can do the same now: attribute(packed,0); | 04:56 |
| mithro | adding padding is annoying from my end :) | 04:56 |
| nash_ | It's not portable in either case... There is nothing you can do to stop people writing bad code... So why put up barrier to make sure everyone writes bad code? | 04:56 |
| mithro | why not call it a "packed string" format then? :) | 04:57 |
| nash_ | Why not use nil termination, so you can save 0-3 bytes on every string sent? | 04:58 |
| mithro | s/everyone/everyone who is silly enough to use C or C++/ ;) | 04:58 |
| mithro | nash: because nil termination is horrible and doesn't tell you how much you have to get | 04:59 |
| * nash_ notes your python interpreter is written in C... | 04:59 | |
| mithro | PyPy will fix that ;) | 04:59 |
| nash_ | Which will be compiled with a conmpiler written in which language? | 04:59 |
| mithro | asm ;) | 04:59 |
| * mithro pretend language | 05:00 | |
| * nash_ notes it is not particularly portable... | 05:01 | |
| * nash_ also notes the problems he is talking about are going to have most affect on your most complete server ;-) | 05:01 | |
| mithro | nash: the most complete server uses memcpy which works does it not? | 05:02 |
| mithro | http://sourceforge.net/projects/cleese/ <- muahahaha | 05:02 |
| tpb | Title: SourceForge.net: Cleese - An Operating System in Python (at sourceforge.net) | 05:02 |
| nash_ | Yes, but you most complete server could be faster and use less code if you changed your protocol by 10 or so words... | 05:02 |
| mithro | nash: and not work on 64bit aligned platforms? and still need to special case 64bit ints? | 05:03 |
| nash_ | No, it works fine on 64bit platforms as I said... But all platforms need to handle 64bit types carefully | 05:04 |
| nash_ | ie: Method which is currently in place | 05:04 |
| nash_ | But then again they need to take care with 64 bit types and endian issues, as endian on the wire for > 32 is not defined by TCP | 05:05 |
| mithro | nash: how often are you going to write a protocol library? | 05:06 |
| nash_ | s/TCP/IP/ | 05:06 |
| nash_ | mithro: Not often, which is why it is worth the time to make sure it si simple and fast | 05:06 |
| mithro | once it's out of your protocol library it's all aligned however the CPU prefers right? | 05:08 |
| nash_ | Yes | 05:08 |
| mithro | so if we decided 0.4.0 should be 32 bit aligned then it makes no difference to the user of your library (or any of the other libraries) | 05:09 |
| mithro | but it we decided otherwise, it still makes no difference | 05:09 |
| mithro | except speedwise of your library? | 05:09 |
| nash_ | This is mostly correct, although my lib allows peple to get raw messages if they want them | 05:10 |
| mithro | and as 0.3.0 is deemed "complete" we aren't going to be adding it to 0.3.0 | 05:10 |
| nash_ | Not just speed, also simplifies the code. | 05:10 |
| nash_ | I'll agree with not changind tp03 | 05:10 |
| nash_ | That would be stupid ;-) | 05:10 |
| mithro | so you have to impliment it anyway | 05:11 |
| nash_ | mithro: I have | 05:11 |
| nash_ | Which is why I know how dumb it is ;-) | 05:11 |
| nash_ | I jsut hate to see code like: | 05:12 |
| mithro | so I assume you have written some nice code so that you only have to worry about this problem in 1 place | 05:12 |
| nash_ | memcpy(tmp,idata,8); | 05:12 |
| nash_ | (*adest)[i].updates = ntohll(tmp); | 05:12 |
| nash_ | Yep | 05:12 |
| nash_ | Still hurts me to know I could save up to 3 emulated loads per data item. | 05:13 |
| * nash_ notes he often optimises memory accesss for video codecs... and this makes him cringe. | 05:13 | |
| * mithro notes nash isn't writing a video codec | 05:14 | |
| mithro | out of intrest don't you need the memcpy (or atleast some type of copy anyway) ? | 05:14 |
| nash_ | No reason for this to be slower however ;-) | 05:14 |
| mithro | IE you can't keep the data around in the incoming network buffer? | 05:15 |
| nash_ | Only for types larger then alignment guarantee... otherwise you can assign individual elements out (or use them directly if you only need them once) | 05:15 |
| nash_ | For instance the time message I use remaining seconds directly (wrapped in a ntohl()) | 05:15 |
| nash_ | For things like sequence messages you only need the messages transitory, so you can read the values directly, and update other structures as you need. | 05:16 |
| nash_ | Currently however I need to run along hte whole message, copy into a new structure, use the structure once, then free it. | 05:17 |
| mithro | i sure if you wanted you could optomise that to only use a memcpy when needed :) | 05:17 |
| nash_ | It's not worth it - only can avoid 25% of the time. | 05:17 |
| nash_ | The extra complexity of code is a maintanance nightmare | 05:17 |
| nash_ | Things like lists of ints are particularly annoying - all the data is there, but I need to copy it before the bulk of the application can use it. | 05:18 |
| mithro | nash: well just count it down to us being stupid :) | 05:19 |
| nash_ | mithro: Or not experienced enough C programmers ;-) | 05:19 |
| nash_ | Will you consider it for tp04? | 05:19 |
| mithro | nash: or caring about C programmers ;) | 05:19 |
| nash_ | mithro: No, it slows down your python programs too | 05:19 |
| mithro | nash: i think you'll find that Int's being real objects in python programs make it lost in that noise | 05:20 |
| mithro | and strings being imutable would also hurt | 05:21 |
| nash_ | If so python is worse then I thought... I know it's not that bad, and the real cost of Int's vs ints is small in a decent language | 05:21 |
| mithro | infact I think the cost of an extra if might make it slower :P | 05:21 |
| nash_ | Also immutable data is a reason to care... it means extra copies can hurt - a lot | 05:21 |
| nash_ | This doesn't add any ifs | 05:22 |
| mithro | if i % 4 != 0: <add padding> | 05:22 |
| nash_ | bah... | 05:23 |
| mithro | btw in Python Ints are first class objects - so they are really quite slow | 05:23 |
| mithro | anyway I've yet to encounter speed problems with the network code | 05:23 |
| nash_ | Just use a int aligned buffer and update by strlen(x) >> 2 | 05:24 |
| nash_ | Wait to you get bigger games | 05:24 |
| nash_ | with non-trivial objects etc | 05:24 |
| mithro | most of the speed problems come from the fact that pipelining is a brain fuck :) | 05:24 |
| nash_ | Really? | 05:24 |
| nash_ | protocol for it gives me grief.. but otherwise... whatever... | 05:24 |
| mithro | yes, because things have dependecies | 05:25 |
| nash_ | example? | 05:25 |
| mithro | ie have to send get_ids before get_x | 05:25 |
| mithro | I know a better way to do it, I just havn't implimented it yet | 05:25 |
| mithro | nash: btw just send an email to the list with good reasons why you think it should be 32bit aligned | 05:26 |
| mithro | (code examples and real stats would be nice too :) | 05:27 |
| nash_ | code examples are easy... real stats are a little harder, but I could probably quote from intel's literature on the x86 which says "don't do this" ;-) | 05:28 |
| nash_ | As an aside... I'm still curious why there is an htonl and ntohl | 05:29 |
| mithro | hrm? | 05:29 |
| nash_ | Why two different byte swap commands... h(ost)t(o)n(etwork)l(ong) and ntohl | 05:29 |
| nash_ | both do the same thing | 05:30 |
| mithro | host -> network | 05:30 |
| mithro | network -> host | 05:30 |
| mithro | because it makes more sense :) | 05:31 |
| mithro | (even if they are implimented in the same code) | 05:31 |
| nash_ | Yes, but they are the same byte swapping either way does the same thing htonl(htonl(x)) is a NOP | 05:31 |
| nash_ | It is the same code ;-) | 05:31 |
| mithro | nash: htonl is probably an alias for ntohl | 05:31 |
| nash_ | It is - they are the same macro | 05:32 |
| mithro | but it makes more sense to a programmer who doesn't care what ntohl | 05:32 |
| mithro | does | 05:32 |
| nash_ | swap32, swap64, swap16 would make more sense | 05:32 |
| mithro | on a bigendian system the macro's evalutate to nothing | 05:32 |
| nash_ | I know | 05:32 |
| nash_ | nswap32 then | 05:32 |
| mithro | so swap32 is stupid name | 05:33 |
| mithro | because on a bigendian system swap32 does nothing | 05:33 |
| nash_ | nswap (netswap) | 05:33 |
| mithro | netswap is also stupid, because swap impliese it does something | 05:33 |
| nash_ | true I guess | 05:34 |
| mithro | plus why are you swapping on a bigendian system? | 05:34 |
| nash_ | Portable code? | 05:34 |
| mithro | hence the name network2host and host2network | 05:34 |
| mithro | nash: but swapping on a bigendian system is wrong - you want a noop | 05:35 |
| nash_ | I know | 05:36 |
| mithro | good coding is about hiding implimentation details from people who don't need to know | 05:36 |
| nash_ | true (as long as you really hide it) | 05:36 |
| mithro | hence a person doesn't need to know what htonl does in reality | 05:36 |
| mithro | (ie on little endian it does byte swap, on big endian it does a nop and on middle endian is does something else) | 05:37 |
| nash_ | I have to say... middle endian deserves all the pain it gets | 05:37 |
| mithro | what happens if you had a weird computer which stored all data as BCD, then htonl would do quite a bit of work | 05:37 |
| mithro | anyway i'll be back in a bit | 05:37 |
| mithro | have to go have a shower and stuff | 05:37 |
| nash_ | that is somnething I hadn't thought od | 05:38 |
| nash_ | okay | 05:38 |
| mithro | and btw machines which work prodminately with BCD actually exist <shudder> they are/where used for banking | 05:45 |
| mithro | intresting story about them, it turned out that converting to/from decmial was more costly (cpu wise) then just keeping everything in decimal in the first place | 05:48 |
| mithro | which is why CPU's have BCD instructions (when you think, WTF who would want that :) | 05:51 |
| *** tpb has joined #tp | 06:00 | |
| *** ChanServ sets mode: +o tpb | 06:00 | |
| nash_ | mithro: I know they used to exist... i'd forgotten all about them.. ;-) | 06:10 |
| nash_ | And x86 has instructions for bcd.. 'aaa' (ascii adjust for addition) comes to mind | 06:11 |
| mithro | nash: your brain is most probably trying to protect you ;) | 06:11 |
| nash_ | blanked out I | 06:12 |
| nash_ | 'm sure | 06:12 |
| nash_ | Still not exactly a unique example... eg Java processors... | 06:13 |
| nash_ | Pure stack architectures. | 06:13 |
| nash_ | bingo... Parsing sequences, and Objects fine... | 06:16 |
| mithro | nash: cool | 06:22 |
| CIA-11 | Lee Begg <[email protected]> * tpserver-cpp/modules/games/minisec/fleet.cpp : | 06:24 |
| CIA-11 | Fixed removing ships so that when zero the key is deleted from the map: | 06:24 |
| CIA-11 | Before this fix, it was possible for a fleet with a frigate to have colonise orders | 06:24 |
| CIA-11 | after the frigate had been used to colonise | 06:24 |
| CIA-11 | Lee Begg <[email protected]> * tpserver-cpp/tpserver/ (playertcpconn.cpp playertcpconn.cpp): | 06:24 |
| CIA-11 | Removed compile warning, and get error type on failed read: | 06:24 |
| CIA-11 | So now read and write both record the failure error. | 06:24 |
| *** llnz has joined #tp | 06:24 | |
| CIA-11 | Just a newline at the end of the file to get rid of the compile warning. | 06:24 |
| mithro | howdy Lee | 06:25 |
| llnz | hi mithro | 06:25 |
| mithro | nash has been complaining about the non-32bit aligned protocol :) | 06:26 |
| llnz | hehehe | 06:26 |
| llnz | nash: blame mithro | 06:27 |
| llnz | grrr... still can't figure out what is going wrong in minisec combat | 06:44 |
| * llnz adds more logging | 06:47 | |
| mithro | llnz: i'm thinking of upgrading the memory in verbal | 06:55 |
| llnz | ahhh | 06:55 |
| llnz | found it | 06:55 |
| llnz | ok | 06:55 |
| mithro | llnz: going to cost a once of $US 75 | 06:56 |
| llnz | ouch | 06:56 |
| mithro | the LA grant request got turned down too :/ | 06:57 |
| llnz | oh dear | 06:57 |
| llnz | damn, going to have to break minisec persistence to fix this bug | 06:58 |
| llnz | humm... actually.... | 06:58 |
| mithro | o, what did you do? | 06:58 |
| llnz | spelling mistake in property name | 06:59 |
| llnz | which is in the db | 06:59 |
| llnz | actually, there is a way for me to not break the db persistence.... | 07:00 |
| mithro | llnz: do you still have a "blog" | 07:09 |
| llnz | vaguely | 07:09 |
| llnz | hehe, minisec combat has been broken since July 13 last year | 07:14 |
| llnz | 7 months | 07:14 |
| mithro | ouch :) | 07:16 |
| mithro | hopefully we'll have AI's playing so we don't have this problem | 07:17 |
| CIA-11 | Lee Begg <[email protected]> * tpserver-cpp/modules/games/minisec/ (7 files): | 07:20 |
| CIA-11 | Fixed spelling of property name, but accept both in Fleet::hit: | 07:20 |
| CIA-11 | This fixes the bug in minisec combat, and has been present for 7 months. | 07:20 |
| CIA-11 | It is hard to pick up these problems sometimes. | 07:20 |
| CIA-11 | Lee Begg <[email protected]> * tpserver-cpp/modules/games/minisec/ (7 files): | 07:22 |
| CIA-11 | Logging in RSPCombat for debugging minisec combat: | 07:22 |
| CIA-11 | Might come in useful in future. | 07:22 |
| CIA-11 | Lee Begg <[email protected]> * tpserver-cpp/modules/games/minisec/rspcombat.cpp : rspcombat copyright | 07:31 |
| mithro | combat working now? | 07:38 |
| CIA-11 | Lee Begg <[email protected]> * tpserver-cpp/tpserver/ (prng.cpp prng.cpp): | 07:39 |
| CIA-11 | Fix getInRange methods to include the max number: | 07:39 |
| CIA-11 | Should make combat a little more even. | 07:39 |
| llnz | mithro: yes | 07:39 |
| mithro | maybe time for a point release? | 07:39 |
| mithro | llnz: your website is a bit out of date :) | 07:40 |
| llnz | hehe | 07:40 |
| mithro | setting up a blog/personal website | 07:43 |
| llnz | cool | 07:43 |
| mithro | updating my Resume too | 07:44 |
| mithro | I'm going to need a job in ~6 months :) | 07:45 |
| llnz | hehe | 07:45 |
| * llnz is still waiting to hear about a job | 07:45 | |
| mithro | llnz: is that the teaching/assistance stuff at uni you where talking about? | 07:46 |
| llnz | yeah | 07:46 |
| mithro | would you think a "muse" relationship is "romantic"? | 07:50 |
| llnz | somewhat, but not always or exactly | 07:51 |
| llnz | more about inspiration | 07:51 |
| mithro | I just found it intresting that WordPress puts "muse" relationship under "romatic" category | 07:53 |
| llnz | hehe | 07:55 |
| llnz | i know where that classification comes from, let me see if i can find the page | 08:01 |
| llnz | http://gmpg.org/xfn/11 | 08:05 |
| tpb | Title: XFN 1.1 profile (at gmpg.org) | 08:05 |
| mithro | I really need to redo my resume | 08:11 |
| nash_ | Is the universe always square? | 08:30 |
| llnz | nash_: it's actually a sphere | 08:30 |
| nash_ | So... is the universe always a perfect sphere? | 08:31 |
| llnz | well, the universe object has a centre, and a diameter, so yes | 08:31 |
| nash_ | okay - just working out how to display things sanely always... | 08:32 |
| nash_ | I want to avoid using 64 bit types, and trying to ind nice ways to simplyfy things... | 08:32 |
| * llnz checks something | 08:34 | |
| llnz | you could, with checks, assume that the universe, and the galaxy, are "very large" and just deal with the contents of the galaxy | 08:35 |
| nash_ | indeed | 08:35 |
| nash_ | I'm just trying to work out the best way to do it | 08:36 |
| nash_ | Next thing to deal with is precision of objects | 08:37 |
| nash_ | y = 1784964813 is still bloody big | 08:37 |
| nash_ | What does a distance of '1' represent? | 08:37 |
| nash_ | Can I make any assumptions about that for displaying? | 08:38 |
| llnz | it doesn't make a lot of difference, but when i was originally doing it, it was 1 unit was 10,000km | 08:39 |
| mithro | nash: I would work out the biggest number and then scale using it | 08:39 |
| nash_ | Yeah, but that can change... | 08:39 |
| * nash_ can't help but feel the distances are a little 'over-precise' | 08:40 | |
| llnz | there are reasons for it | 08:41 |
| llnz | such as slowing down jump ships | 08:41 |
| nash_ | ? | 08:41 |
| mithro | nash: i mean dynamicly find the biggest number | 08:41 |
| nash_ | mithro: I know | 08:41 |
| nash_ | Just later a new object might appear at a higher number, and I need to tweak. | 08:42 |
| mithro | nash: an object with a higher number will only appears at a new turn | 08:42 |
| mithro | (ie objects can't appear in the middle of a turn) | 08:42 |
| nash_ | True. Objects will only change on a new turn. | 08:42 |
| nash_ | Still... irritating... If I had a bounding box to begin with it would be useful | 08:43 |
| llnz | everything is inside the universe | 08:43 |
| llnz | that could be your bounding sphere | 08:44 |
| llnz | (or circle, if you only want to deal with 2d | 08:44 |
| llnz | ) | 08:44 |
| mithro | however the universe could be much bigger then it's actual contents | 08:44 |
| nash_ | The ones I'm seeing, the universe is >> then the objects inside | 08:45 |
| mithro | your best bet is to work it out yourself :) | 08:48 |
| mithro | why don't you want to use int64's? | 08:51 |
| nash_ | Slow... | 08:53 |
| nash_ | Annoying... have to be careful to promote everywhere. | 08:53 |
| nash_ | Can't be passed to var_args without care | 08:53 |
| nash_ | Can't be stored in void*'s (not that I need that now) | 08:53 |
| nash_ | in short... ugly | 08:54 |
| mithro | storing in void*!? | 08:54 |
| nash_ | ;-) You need to use more C. | 08:54 |
| llnz | mithro: nash_ is using C | 08:54 |
| mithro | yes but a void* is a pointer to something, not a storage for an integer | 08:55 |
| llnz | particularly on 64bit systems | 08:55 |
| mithro | or any system | 08:56 |
| nash_ | mithro: You may store a uintptr_t value in a void * pointer... It normally ain't 64 bit | 08:57 |
| nash_ | _very_ useful for callbacks - since they normally pass you an void *, if you can use a uintptr_t value there is no need to alloc anything | 08:58 |
| mithro | nash: why are you storing anything apart from a pointer to something in a void pointer!? | 08:58 |
| nash_ | mithro: callbacks | 08:58 |
| nash_ | I don't need it yet in this program... but you never know | 08:58 |
| mithro | callbacks are pointers to functions? | 08:59 |
| nash_ | In any case... 64 bit values are _slow_ | 08:59 |
| nash_ | callbacks use pointers to functions, yes | 08:59 |
| mithro | so what does that have to do with ints? | 08:59 |
| nash_ | so I tell a particualr object, hey when you are done, call this function, and pass me this void * back too... | 08:59 |
| nash_ | Cause uintptr_t's can be stored in void*s portably and safely. | 09:00 |
| nash_ | sizeof(int64_t) >> sizeof(uintptr_t) on all 32bit archs | 09:00 |
| * nash_ cares not about porting to 16bit archs | 09:00 | |
| mithro | nash: your definition of portable is dubous | 09:01 |
| nash_ | mithro: Probably not as dubious as you think | 09:01 |
| mithro | sizeof(void *) >> sizeof(uint) is not guarenteed | 09:01 |
| mithro | and it seems of dubious usefulness anyway? | 09:02 |
| nash_ | mithro: I never said uint, I said uintptr_t, which is something differnt | 09:02 |
| mithro | what is it? | 09:02 |
| nash_ | An integer type which can be safely stored in a void*, part of C99 | 09:03 |
| nash_ | On all archs BTW. I can use it a 16bit arch, it will most likely be 15bits in storage size | 09:03 |
| mithro | he he - a google of uintptr_t gives a whole bunch of pages about how it isn't portable :) | 09:04 |
| nash_ | It's on the internet, so it must be true? | 09:04 |
| mithro | nash: sure! | 09:04 |
| mithro | google is the master of all knowledge ;) | 09:05 |
| nash_ | based on what I saw... mostly related to the fact most places don't implement C99... | 09:05 |
| mithro | well it's your grave as they say ;) | 09:06 |
| nash_ | In anycase... back to the original point... still like to stcik to 'int' - whatever size that is, and ignore int64_t. The canvas I am using is limited to 65000 pixels in width and height in the current version, so passing it raw 64bit values probably won't work as well as expected | 09:06 |
| nash_ | So my original problem still stands... is there a nice way to drop precision, without a random divider... | 09:07 |
| mithro | nash: your divider would be related to zoom level, no? | 09:08 |
| nash_ | Yes | 09:08 |
| nash_ | base zoom would be 'everything currently in the universe on the screen' | 09:08 |
| mithro | so all you need to find is a default zoom level? | 09:08 |
| mithro | and you already have to loop over all objects to get them from the wire? | 09:09 |
| mithro | why not just store x, y, z min/max | 09:09 |
| nash_ | I am storing a bounding box as I see objects... | 09:09 |
| nash_ | So I can use that. | 09:09 |
| * nash_ was wondering if there was a canonical method, rather then every client coming up with their own path to chaos | 09:10 | |
| mithro | so... the problem is? :) | 09:10 |
| mithro | nope | 09:10 |
| mithro | hopefully the most sane path to chaos will end up being the default ;) | 09:11 |
| * nash_ likes mithro's idea, and would like to subscrbe to his newsletter | 09:11 | |
| mithro | btw, you'll most probably want a LOD culler | 09:11 |
| nash_ | mithro: You think? | 09:11 |
| mithro | nash: well it's a little be harder then it would first seem, the universe "tree" doesn't exactly match a LOD tree | 09:12 |
| nash_ | Well at least some thresholding to turn systems into point objects | 09:12 |
| nash_ | I know | 09:12 |
| nash_ | But my hope is to use pretty much the code I had for the freestars client | 09:12 |
| mithro | which caught me of guard a few times | 09:13 |
| mithro | s/of/off | 09:13 |
| nash_ | http://nash.id.au/Software/FreeStars/images/loadmapzoomin.png | 09:13 |
| tpb | <http://ln-s.net/J2i> (at nash.id.au) | 09:13 |
| nash_ | http://nash.id.au/Software/FreeStars/images/loadmapzoomout.png | 09:13 |
| tpb | <http://ln-s.net/J2k> (at nash.id.au) | 09:13 |
| mithro | nash: do you have a blog btw? | 09:14 |
| nash_ | Not currently | 09:14 |
| nash_ | I probably will in a week or two | 09:14 |
| nash_ | Ay particualr reason | 09:15 |
| mithro | me and JLP are planing to setup a planet.tp.net :) | 09:15 |
| nash_ | right | 09:15 |
| nash_ | I'll let you know then | 09:15 |
| * nash_ says bugger it... zoom by factors of 2, he can fix it later | 09:22 | |
| nash_ | Ohh.. divide by zero... all good | 09:27 |
| nash_ | BTW: I have no intention of showing anything but fleets in space, and stars on the map at this point | 09:31 |
| *** mithro has quit IRC | 10:04 | |
| *** mithro has joined #tp | 10:44 | |
| *** mithro has quit IRC | 11:20 | |
| *** mithro has joined #tp | 11:47 | |
| JLP | hi all | 13:09 |
| * JLP has enough of translation for today :) | 13:09 | |
| llnz | hi JLP | 13:10 |
| JLP | llnz: i've submited an ebuild for libtprl to Gentoo | 13:13 |
| llnz | cool | 13:13 |
| JLP | now i'm going to do one for tpserver-cpp | 13:13 |
| JLP | and after that for client stuff | 13:13 |
| JLP | libtprl bug report is here: http://bugs.gentoo.org/show_bug.cgi?id=167426 | 13:15 |
| tpb | Title: Gentoo Bug 167426 - libtprl-0.1.2.ebuild (New Package) (at bugs.gentoo.org) | 13:15 |
| JLP | oh nice, ti looks like ranting at my ISP helped, now they offer Upload Speed Booster, doubles the speed of UL | 13:19 |
| JLP | for 4? i'll can now get UL speed for my package doubled from 768k to 1,5M | 13:20 |
| llnz | nice | 13:23 |
| JLP | btw, should the packages with ebuilds also be added to sourceforge files and to TP Downloads page? | 13:33 |
| llnz | i guess so | 13:34 |
| JLP | ok, when i make ebuild for c++ server i will add both to SF and TP | 13:37 |
| JLP | i wil also add some default configuration file so that it can work out of the box | 13:46 |
| JLP | what dou you think would be the best way to do this? | 13:46 |
| JLP | should I just include AI competition conf file and install it? | 13:47 |
| llnz | yeah, that might be the best | 13:47 |
| JLP | you posted it into forums/MLs right? | 13:47 |
| llnz | yeah | 13:48 |
| llnz | there is a link on the competition page | 13:49 |
| JLP | ok, i think i have enough info now, let's try to make ebuild for tpserver-cpp now | 13:49 |
| JLP | llnz: what is the minimum mysql version that is supported | 13:54 |
| llnz | umm.... | 13:54 |
| llnz | probably 4.0.0 or something like that, it is fairly basic | 13:54 |
| JLP | ok i'll set it ot >=virtual/mysql-4.0 | 13:55 |
| *** Demitar has joined #tp | 14:09 | |
| llnz | i should sleep, 3:42am here | 14:40 |
| * llnz wanders off | 14:41 | |
| *** llnz has quit IRC | 14:41 | |
| *** JLP has quit IRC | 20:17 | |
| *** nash_ has quit IRC | 20:38 | |
| *** Demitar has quit IRC | 21:13 | |
| *** Demitar has joined #tp | 21:17 | |
| *** Demitar has quit IRC | 21:24 | |
| *** Demitar has joined #tp | 21:25 | |
| *** Demitar has quit IRC | 21:32 | |
| *** Demitar has joined #tp | 21:33 | |
| *** mithro has quit IRC | 21:40 | |
| * nash waves | 22:04 | |
| *** JLP has joined #tp | 22:19 | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!
