Time |
Nick |
Message |
00:52 |
|
ANAND joined #minetest-dev |
01:20 |
|
erlehmann joined #minetest-dev |
01:25 |
|
nephele_ joined #minetest-dev |
01:44 |
|
Miner_48er joined #minetest-dev |
01:48 |
|
Syntaxxor joined #minetest-dev |
03:23 |
|
reductum joined #minetest-dev |
04:02 |
|
Taoki joined #minetest-dev |
04:52 |
|
calcul0n joined #minetest-dev |
06:05 |
|
NetherEran joined #minetest-dev |
07:11 |
|
reductum joined #minetest-dev |
07:14 |
|
YuGiOhJCJ joined #minetest-dev |
07:58 |
|
NetherEran joined #minetest-dev |
07:59 |
|
QwertyDragon joined #minetest-dev |
08:00 |
|
ShadowNinja joined #minetest-dev |
08:58 |
|
jas_ joined #minetest-dev |
09:57 |
|
T^4im joined #minetest-dev |
10:26 |
|
Beton joined #minetest-dev |
10:42 |
|
troller joined #minetest-dev |
10:53 |
|
Fixer joined #minetest-dev |
11:16 |
|
erlehmann joined #minetest-dev |
11:47 |
|
Powi joined #minetest-dev |
12:45 |
|
Powi joined #minetest-dev |
12:46 |
|
Taoki joined #minetest-dev |
12:54 |
|
Powi joined #minetest-dev |
13:14 |
|
Powi joined #minetest-dev |
13:24 |
|
NetherEran joined #minetest-dev |
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 |
13:49 |
|
Wuzzy joined #minetest-dev |
13:52 |
|
Guest23688 joined #minetest-dev |
13:55 |
|
fluxflux joined #minetest-dev |
14:13 |
|
erlehmann joined #minetest-dev |
14:41 |
|
NetherEran joined #minetest-dev |
14:41 |
|
ANAND joined #minetest-dev |
16:18 |
|
bigfoot547 joined #minetest-dev |
17:51 |
Krock |
!tell Zughy Why on items? There can be multiple recipes for one item |
17:51 |
ShadowBot |
Krock: O.K. |
18:14 |
|
erlehmann joined #minetest-dev |
18:22 |
|
mizux joined #minetest-dev |
18:29 |
|
NetherEran joined #minetest-dev |
19:05 |
|
kaeza joined #minetest-dev |
19:11 |
|
erlehmann joined #minetest-dev |
19:16 |
|
Zughy joined #minetest-dev |
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 |
20:13 |
|
Syntaxxor joined #minetest-dev |
20:22 |
|
Fixer joined #minetest-dev |
20:28 |
|
Fixer joined #minetest-dev |
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 |
21:45 |
|
T4im joined #minetest-dev |
21:57 |
|
T4im joined #minetest-dev |
22:09 |
|
Fixer joined #minetest-dev |
22:11 |
|
T4im joined #minetest-dev |
22:28 |
|
T4im joined #minetest-dev |
22:42 |
|
proller joined #minetest-dev |
22:45 |
|
T4im joined #minetest-dev |
22:57 |
|
erlehmann joined #minetest-dev |
23:09 |
|
Miner_48er joined #minetest-dev |
23:28 |
|
Lunatrius joined #minetest-dev |
23:34 |
|
Jdog joined #minetest-dev |