Luanti logo

IRC log for #minetest-dev, 2020-05-18

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Enable nick filtering
Time Nick Message
26 more elements. Show/hide.
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
7 more elements. Show/hide.
17:51 Krock !tell Zughy Why on items? There can be multiple recipes for one item
17:51 ShadowBot Krock: O.K.
6 more elements. Show/hide.
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
3 more elements. Show/hide.
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
11 more elements. Show/hide.

| Channels | #minetest-dev index | Today | | Google Search | Plaintext