In SVN trunk there is currently lots of MSG_Write errors. Perhaps we should devise a strict typing for MSG_Write? How to do it? Here is a preliminary discussion. Respond here, please.
<Bandobras> hi ssianky, you were right all along!
<ssianky> i know this.
<angel_7th> :) [09:50]
<Bandobras> so now I know this too ;) [09:52]
<CIA-18> tlh2000 * r1933 /ufoai/trunk/contrib/intl.dll: * intl.dll: Update to
version 0.14.5.0 [09:53]
<Bandobras> despite your msvc 2005
<ssianky> but nobody found this bug before. so msvc helped much more than
other debuggers. [09:57]
<CIA-18> tlh2000 * r1934 /ufoai/trunk/contrib/jpeg62.dll: * jpeg62.dll: Update
to version 6.2.1473.36469 [09:58]
<Bandobras> ok, I admit
<Bandobras> I hope no more looping lists after yesterday's party [09:59]
* Bandobras dances around
<CIA-18> tlh2000 * r1935 /ufoai/trunk/base/pics/armor/ (4 files): * new armor
images for blue and ortnok [10:13]
<CIA-18> tlh2000 * r1936 /ufoai/trunk/base/models/aliens/ (12 files in 4 dirs):
[10:26]
<CIA-18> * renamed dirs alien4_* to blue_*
<CIA-18> * exported the 3dsmax files to md2
<CIA-18> NOTE: Skinpaths needs to be set (see md2.pl)
<ssianky> i think next step is to change all MSG_Write* to typesafe
MSG_Write(U)Int8/16/32 [10:27]
<ssianky> and Msg_Read* too. [10:28]
<Bandobras> what would that do?
<Bandobras> currently there are tons of MSG_Write errors in my logs... [10:29]
<ssianky> fix type range problems. [10:30]
<ssianky> and tons of possible bugs.
<Bandobras> so I won't get MSG_Write errors in my logs?
<Bandobras> instantly?
<Bandobras> they even crash the game...
<Bandobras> or something with them
<ssianky> instantly what? fix possible bugs? no, not instantly but this will
greatly help to find them. [10:34]
<ssianky> now i dont know if a value is good or not.
<Bandobras> so will compiler tell? [10:35]
<Bandobras> or will this cause more readable runtime bugs?
<ssianky> both. [10:36]
<Bandobras> oh [10:37]
<Bandobras> good
<ssianky> msvc compiler have a good option for this - "smaller type check",
that perform runtime check if a value is truncated when
assigned. but it dosnot work because all values are ints.
[10:41]
<Bandobras> is the MSG_Write change a hard work and does mattn approve? [11:11]
<Bandobras> perhaps we could start it right now...
<Bandobras> the inventory code is still very buggy [11:12]
* Bandobras cringes
<Bandobras> is it possible in C to make MSG_Write even more typesafe than
MSG_Write(U)Int8/16/32? [11:35]
<Bandobras> for example type it so that only given structs can be send...
[11:36]
<Bandobras> then we would need separate types for separate events that can be
sent
<Bandobras> the types would describe the struts that have to be supplied
[11:37]
<Bandobras> together with the even
<Bandobras> _that_ would be type-safe...
<ssianky> i agree that structs are better. much better. [11:38]
<Bandobras> lots of writing, but should pay off [11:40]
<Bandobras> what do we do to start this?
<Bandobras> hey, mattn, come over here! [11:43]
* Bandobras waves [11:44]
<ssianky> structs should have also a begin and end magic numbers. [11:46]
<Bandobras> ssianky, should we post this on the Coding subforum?
<Bandobras> to get things started
<Bandobras> magic what for?
<Bandobras> so that they are incompatible between one another? [11:47]
<ssianky> like a guid for each struct.
<Bandobras> what is guid?
<ssianky> ID
<ssianky> typeID [11:48]
<Bandobras> ok, id for each struct type?
<ssianky> yes.
<angel_7th> uhm... if you want type safety... why not port part of it to c++ ?
<Bandobras> c++ sucks
<Bandobras> lots
<Bandobras> porting sucks
<ssianky> c sucks much more.
* angel_7th agrees with ssianky :)
<Bandobras> depends what for
<ssianky> for big projects.
<angel_7th> c++ is quite an improvement over c, if you ask me...
<Bandobras> frankly, I'd port it to OCaml
<Bandobras> fight that! [11:49]
<Bandobras> I'm not sure Object Oriented is especially good here
<Bandobras> Java, OTOH is too slow
<Bandobras> what else? [11:50]
<angel_7th> c++ isn't necessarily OO? it has some other nice features as
well... such as templates :)
<Bandobras> oh, come on
<Bandobras> perhaps c++ without OO
<Bandobras> but what are advantages of c++ without OO?
<Bandobras> better typing? [11:51]
<Bandobras> (I don't know either C or C++, so I ask)
<angel_7th> well, it's a bit easier to split your project in modules using
namespace etc. as well [11:53]
<Bandobras> k
<angel_7th> anyways, I'm back to work again, bbl~
<Bandobras> don't you need typeID magic?
<angel_7th> (btw, it has a standard collection framework as well, saves a lot
of home-brew lists/arrays/maps etc. etc.)
<Bandobras> k
<Bandobras> ssianky, why begin and end magic numbers? [11:54]
<Bandobras> why not just one?
<Bandobras> they would induce some more net traffic... [11:55]
<Bandobras> if structs have differently named fields
<Bandobras> cannot compiler catch their incompatibility?
<Bandobras> do we need typeID magic anyway?
<Bandobras> oh, I see [11:57]
<Bandobras> this is serialized over the network
<Bandobras> and the magic number is manual way of doing intelligent
deserialization [11:58]
<Bandobras> aren't there nice libraries for that, though?
<Bandobras> why would I implement serialization manually?
<Bandobras> that's stone age...
<ssianky> who cres about trafic? [12:03]
<ssianky> cares, i mean. [12:04]
<Bandobras> sure
*** fatty (n=rotkaepp@W05f2.w.pppool.de) has joined channel #ufo:ai
<Bandobras> UFO:AI over telephone modem ;>
<Bandobras> anyway, one typeID or two does not matter [12:05]
<Bandobras> that's a tiny fraction of data
<Bandobras> so [12:08]
<Bandobras> are there any good serialization libraries for C?
<Bandobras> or any mod of q2 or q3 with civilized protocol at the cost of
magic? [12:12]
* Bandobras sniffs [12:15]
* Bandobras coughs [12:23]
<Bandobras> so I guess I'll post it on the Coding subforum... [12:29]
<Bandobras> smile, you are on the Coding subforum :) [12:30]
http:-------a_hack_to_let_the_log_format_better--------------------------------
