Time  Nick      Message
13:36 ANAND     Does MT support the RelWithDebInfo CMake build type?
13:36 ANAND     Would be interesting if it does
13:45 ANAND     It seems to work! :O
17:51 Krock     !tell Zughy Why on items? There can be multiple recipes for one item
17:51 ShadowBot Krock: O.K.
19:18 Zughy     Krock, why tho a recipe of the same item should call a function and another recipe of the same item shouldn't? Can you provide a practical example?
19:19 Krock     yes. when you want to trigger actions on the ingredients
19:20 Zughy     huh, like.. diamond now became coal?
19:21 Krock     maybe. I rather thought about penalties
19:22 Krock     if you have the hunger mod installed, it would be possible to offer variants which take different amounts of hunger
19:22 Krock     more expensive recipes might be easier to craft (using chemicals, for example)
19:22 Krock     doing it manually takes lots of effort, thus more hunger is consumed
19:23 Krock     the crafted item is the same, but the recipe may vary a lot
19:24 Krock     triggering on crafted items would also break the logic of crafting. you register a craft recipe, but don't get triggers when it's used?
19:26 Krock     serialization functions are a PITA. why the hell is NetworkPacket not used as a base class?
19:27 Krock     time to refactor that a bit
19:28 Krock     also lots of time seems to be wasted in resizing vectors
19:29 sfan5     base class for what?
19:30 Krock     i/ostream
19:30 Zughy     PITA = ?
19:30 Krock     Pain In The Ass
19:30 Zughy     oh, nice. Because it's a Greek dish
19:30 sfan5     you mean NetworkPacket should be a child class of ostream?
19:31 Krock     as of now there's read*() for u8* (raw), read*() for istream& and NetworkPacket alone
19:31 Krock     ignoring the unused vector and bufreader functions
19:32 Krock     yes. NetworkPacket to inherit from istream and ostream
19:32 Krock     using it as a base (after renaming) for serialization
19:34 Krock     serializeLongString() and alike would then be moved into that class aswell
19:34 Krock     istream and ostream inheritance would guarantee compatibility during the migration phase (too many lines to replace)
19:36 sfan5     what if methods want to serialize something that doesn't go in a NetworkPacket?
19:36 Krock     for example?
19:36 Krock     in any way, conversion to i/ostream would be possible
19:36 sfan5     mapblocks?
19:37 sfan5     serializing them into a NetworkPacket only to retrieve the string would be weird
19:37 Krock     ah. cases where ostream is an input
19:39 Krock     well.. change the arguments to NetworkPacket (or however its name would be)
19:40 Krock     will write an example to clean up confusions
19:40 sfan5     oh of course
19:40 Krock     though that'll take a while
19:40 sfan5     you can put all the serialization stuff into a BufWriter class, and then NetworkPacket inherits from that and also contains peer_id, command type, etc.
19:41 Krock     yes, that's what I meant. NetworkPacket just happens to contain all needed functions already
19:41 Krock     including the desired structure
19:41 sfan5     I fear that having a third way of serialization will just make things worse
19:42 Krock     if it's not fully adopted - yes.
19:42 Krock     but that would be the case for all attempts to bring a new structure into it
19:43 Krock     even currently there are some ugly istream/NetworkPacket conversions around
19:43 Krock     those would simply disappear
21:11 Zughy     if I add a new file, do I need to mention it in some building file?
21:12 Zughy     in order to have it compiled
21:12 sfan5     you do yes
21:12 sfan5     pick the nearest CMakeLists.txt
21:14 Zughy     ty
21:24 sfan5     pushing http://sprunge.us/RSzX65?diff in 5 minutes
21:31 sfan5     pushed