Time  Nick       Message
02:04 paramat    merging game#1835 game#1950
02:04 ShadowBot  https://github.com/minetest/minetest_game/issues/1835 -- Expose open_chests and chest_lid_obstructed by ForbiddenJ
02:04 ShadowBot  https://github.com/minetest/minetest_game/issues/1950 -- Flowers: Add black tulip, green chrysanthemum by paramat
02:13 paramat    nah, 1835 has a conflict, will do these later
03:06 paramat    +1 for game#1955
03:06 ShadowBot  https://github.com/minetest/minetest_game/issues/1955 -- Improve burn times by Ezhh
03:36 ashtrayoz  Two questions on #6604
03:36 ShadowBot  https://github.com/minetest/minetest/issues/6604 -- Preserve node metadata as item metadata. by ashtrayoz
03:37 ashtrayoz  It works under my testing, it does what it says on the tin.
03:37 ashtrayoz  It specifically does NOT set metadata on placed nodes, even if there is metadata on the item being placed.
03:39 ashtrayoz  My thought is that the mod placing the item should handle that in after_place.
03:40 ashtrayoz  My questions are:
03:40 ashtrayoz  1)  Do other people think that we should "Preserve item metadata when placing as a node", which this pull request does NOT do.
03:41 ashtrayoz  2)  If the answer to (1) is yes, should it be part of the same pull request, or developed separately?
05:32 paramat    game#1956
05:32 ShadowBot  https://github.com/minetest/minetest_game/issues/1956 -- Binoculars: Update to use 'zoom_fov' player property by paramat
16:17 Krock      So what's going to happen with #5920 and #6666? Both are about the same feature
16:17 ShadowBot  https://github.com/minetest/minetest/issues/5920 -- Show more infos in debug screen
16:17 ShadowBot  https://github.com/minetest/minetest/issues/6666 -- Debug/F5 Information Formatting Issues
16:23 sfan5      close one as dup
16:23 Shara      Leave mine please
16:23 Shara      Mine is the one paramat is currently working on
16:23 Shara      And the other one has completely different aims.
18:04 rubenwardy #6401
18:04 ShadowBot  https://github.com/minetest/minetest/issues/6401 -- Add check to pause game on lost window focus by rubenwardy
18:04 rubenwardy it has some support in the PR
18:04 rubenwardy I frankly don't care that much about it, just wanted to see how it was done
18:45 Hijiri     #6688 particle thing
18:45 ShadowBot  https://github.com/minetest/minetest/issues/6688 -- (WIP) Custom particle generators for particle spawners by raymoo
19:24 ensonic    hi, can a texture-pack override textures from mods? did not find anything about this on the wiki (https://wiki.minetest.net/Texture_Packs and https://wiki.minetest.net/Help:Creating_texture_packs)
19:24 Krock      that's what texture packs do. they override the textures that are sent by the server
19:25 Krock      just ensure you use the same texture names in your pack to override them
19:28 sofar      Hijiri: please, NO flash for example videos
19:29 sofar      Hijiri: upload to youtube or some sane video platform, of even imgur (video to gif)
19:30 sofar      wait, it's a <video>
19:30 sofar      I wonder why my firefox shows the "block flash" overlay, maybe it's noscript
19:32 ensonic    Krock, so as long as the filename matches they replace them, cool - I was wondering if the path plays any role or if mods better prefix their texture names to be unique without a path
19:32 ensonic    thanks
19:33 Krock      no, paths are irrelevant. texture packs usually only have one directory, as the support for nested ones was missing
19:35 Krock      sofar, that seems to be a raw video file.
19:35 sofar      no, it is embedded somehow in html
19:35 sofar      well
19:35 sofar      idk, probably noscript label wrong
19:36 Krock      FF does that for you automatically to display the video
19:57 Hijiri     I think travis is failing on my PR because particles.cpp isn't being built before minetestserver is linked, but I don't know what I would need to change.
20:06 ashtrayoz  What is the best way to get people to comment upon/test/review my pull request?
20:06 rubenwardy ashtrayoz, post it here
20:06 rubenwardy like #6666
20:06 ShadowBot  https://github.com/minetest/minetest/issues/6666 -- Debug/F5 Information Formatting Issues
20:06 ashtrayoz  #6604
20:06 ShadowBot  https://github.com/minetest/minetest/issues/6604 -- Preserve node metadata as item metadata. by ashtrayoz
20:07 ashtrayoz  I posted two questions around 03:30Z - maybe everybody was asleep.
20:07 paramat    #6675 is updated with requests, it's now only a cleanup, rubenwardy
20:07 ShadowBot  https://github.com/minetest/minetest/issues/6675 -- F5 Debug info: More compact, return to 2 lines by paramat
20:07 paramat    i was awake but busy =)
20:08 rubenwardy it has 4 down votes
20:08 rubenwardy not sure if they're up to date
20:08 paramat    those are out of date
20:08 paramat    1 is kilbith
20:08 paramat    =D
20:09 paramat    i've responded to almost all requests
20:10 ashtrayoz  Noob questions:  where on github do I see no votes?
20:10 Krock      ashtrayoz, in the graveyard of forgotten PRs
20:10 rubenwardy ashtrayoz, what do you mean?
20:10 rubenwardy usually :-1: or more recently the review system
20:11 Hijiri     #6688 adds some objects with methods, but it also adds non-method functions closely related to those objects. Where should I put their documentation?
20:11 ShadowBot  https://github.com/minetest/minetest/issues/6688 -- (WIP) Custom particle generators for particle spawners by raymoo
20:11 paramat    see for what i changed https://github.com/minetest/minetest/pull/6675#issuecomment-346962360
20:11 Hijiri     Should I just separately document the object in the classes area and the functions somewhere else?
20:12 ashtrayoz  I can see 3 reviewers (sfan5, SmallJoker, rubenwardy), I can see suggested code changes (mainly from sfan5, good advice there).  But I do not see a "no vote".  I assume I am looking in the wrong place.
20:12 paramat    a yellow thumbs-down icon in a comment from a core dev is a disapproval
20:13 paramat    6604 has no approvals yet, those will appear in 'labels'
20:17 ashtrayoz  Yes, it seems to have no labels at all.  Not "improvement needed" or "duplicate" or "stupid idea".  Just nothing :-(  *sigh*
20:18 ashtrayoz  Oops - it has "bugfix" (thanks paramat)
20:18 paramat    that's normal unfortunately, sorry, dev time is very limited currently
20:18 Hijiri     reviewer time*
20:19 paramat    well it's dev review, testing and approvals that counts for a merge
20:26 paramat    aw thanks
20:26 rubenwardy :D
20:28 paramat    i updated the first post to describe the changes made, in case it helps others
20:30 sfan5      ashtrayoz: i'm not exactly sold on copying the entire metadata to the item but i guess this is what one would call "elegant solution"
20:30 sfan5      other than that i don't see anything wrong with your PR
20:31 sfan5      i should probably approve it
20:37 paramat    should it be optional to keep metadata in the item?
20:37 paramat    since metadata may be for the position rather than the node object itself
20:38 ashtrayoz  It would be easy to add a metadata key which says "please copy this metadata to the node when dropped".
20:38 sfan5      why would a "position" have metadata?
20:38 paramat    when you place the item again, does metadata then get added to the new position?
20:38 sfan5      i wouldn't disapprove of a key indicating this though
20:38 ashtrayoz  Of course, that means we have more "magic" metadata keys...
20:39 ashtrayoz  I have currently left putting the metadata back onto a node as a job for modders.
20:39 ashtrayoz  They have all the support that they need for this right now from the engine.
20:39 paramat    ok. more what i mean is, it's likely that metadata should be destroyed on digging in some situations, and not carried around in the node item
20:40 paramat    seeing as that's the current behaviour
20:40 paramat    much likely relies on that or is built around that
20:41 paramat    so this feature should be optional and default off
20:41 paramat    (possibly)
20:41 ashtrayoz  What about "preserve_metadata_on" as a key, and one or more of "fall, dig, place" as values?
20:41 sfan5      i don't think it needs to be that fine grained
20:42 ashtrayoz  A blank or nil value means "do not preserve metadata".
20:42 paramat    these are just my initial thoughts, i don't have a depp understanding of he issues
20:42 paramat    *deep
20:43 paramat    plus, preserving metadata in a node item may unnecessarily preserve data when it is not needed
20:44 paramat    so it seems to me it should be optional and default off
20:44 paramat    sorry for the late opinion
20:44 ashtrayoz  Could also have "always" for modders who do not know what the different situations mean.  I would not use that, but other people might.
20:44 sfan5      a "preserve_metadata" -> bool is fine IMO
20:45 Hijiri     #6689 bugfix to sofar's thing
20:45 ShadowBot  https://github.com/minetest/minetest/issues/6689 -- Shut down mapgen threads before other shutdown tasks by raymoo
20:46 paramat    what i meant with 'metadata for a position' is: the metadata may only be relevant for that node in that position, such that it should be deleted on dig
20:46 sfan5      do you have an example for that
20:47 Hijiri     I agree but I have no example
20:47 paramat    looking
20:47 Hijiri     I have an example
20:48 Hijiri     You could have a power system consisting of nodes (literally nodes, but also nodes in a power graph) where you connect them together with some tool
20:48 Hijiri     and each node keeps track of what nodes it's connected to
20:49 Hijiri     there is a limit to how far you can connect two nodes, so you shouldn't save the connections
20:49 Hijiri     plus you will probably update the nodes it's connected to to say that they aren't connected anymore, and then you would need to reconnect them when you placed the node down again
20:49 Hijiri     which would be weird behavior
20:49 Hijiri     can items with unequal metadatas be stacked?
20:50 sfan5      no
20:50 Hijiri     ok, thanks
20:50 sfan5      ideally there would be a way for mods to filter what gets persisted to items
20:50 Hijiri     maybe a function that takes a metadata as input and returns a metadata?
20:50 Hijiri     not sure if that would work, since I don't think there are independent metadatas in case you wanted to create a completely new one
20:51 sfan5      that would work, inside the nodedef?
20:51 Hijiri     yeah
20:51 sfan5      Hijiri: you could just give it the new meta and let it :set() all stuff
20:51 Hijiri     by not sure if it would work, I just meant it felt somewhat bad because you would just be clearing all the fields you don't like
20:51 ashtrayoz  If we had a boolean behaviour, do you think it should apply to placing items as nodes, as well as to converting nodes to items?
20:51 Hijiri     oh, that makes sense
20:51 Hijiri     so it would take the old and new metas?
20:51 ashtrayoz  This is not needed, but it just seems obvious.
20:51 Hijiri     Then you could store it in a completely different way, in case you wanted to
20:51 sfan5      ashtrayoz: that would make sense yes
20:55 paramat    yes, i can't see why you would prerve metadata in an item if not placing it again (maybe?)
20:56 Hijiri     paramat: You might want to use the metadata in the item form for something else
20:56 Hijiri     maybe you can put the node / item in a workbench and modify it in some way
20:56 paramat    hmm
20:56 paramat    perhaps 2 bools are better
20:57 sfan5      ideally there would just be a callback for persisting nodemeta -> itemmeta and one for readding itemmeta -> nodemeta
20:58 sfan5      though the latter might be doable with on_place?
20:58 ashtrayoz  Itemmeta to nodemeta can be done via on_place.  My mods do that now.
20:59 ashtrayoz  They get the itemstack used to place the node.  Falling nodes have no idea what itemstack (if any) they will land in, which is the original impetus for this change.
21:00 sfan5      hmm i think a callback for nodemeta -> itemmeta is really needed
21:00 Hijiri     ideally for me the item use, node dig callbacks etc. would be composable enough that you could just do it as part of those
21:01 Hijiri     then you wouldn't need extra fields
21:01 Hijiri     but I don't know how feasible that is
21:01 sfan5      mesecons FPGAs would not be able to use this function at all otherwise, since the current state of the ports is saved in metadata, so two fpgas with identical code but dug in different "port situations" would not stack
21:01 sfan5      ^ example why a callback is very needed
21:02 ashtrayoz  A callback, rather than a metadata key, is entirely doable.  Will take a while to write and test, but that is fine.
21:03 ashtrayoz  I think that the callback would be called whether the node has metadata or not, so that a node could insert a "description" item if it wanted.
21:03 ashtrayoz  If the callback is not defined, no metadata is preserved.
21:04 sfan5      yeah
21:05 paramat    "Itemmeta to nodemeta can be done via on_place." no need for a bool for that then, it seems
21:05 ashtrayoz  paramat:  largely a question of convenience for modders.
21:06 sfan5      you need an on_place to initialize the meta anyway, so not doing it in builtin actually makes more sense
21:06 paramat    "I think that the callback would be called whether the node has metadata or not" seems better to not, extra callbacks on every node dig is not good
21:07 ashtrayoz  Most of the time the callback will not exist, so it will not be called.
21:07 sfan5      ^
21:07 ashtrayoz  It is probably no slower to check for the existence of the callback than to load the metadata.
21:07 paramat    ok
21:07 paramat    i'm no expert in this
21:09 ashtrayoz  I think that the return value of the callback should be a table.  Keys are strings, values are strings or numbers.  Anything else is ignored.
21:09 ashtrayoz  (possibly with a logged warning)
21:09 sfan5      <sfan5> Hi​jiri: you could just give it the new meta and let it :set() all stuff
21:10 sfan5      oh wait wrong one
21:10 sfan5      though i don't think just passing the itemstack meta would be a bad idea
21:10 ashtrayoz  Yes, generating the new MetaRef first is easy to do.
21:15 ashtrayoz  So the callback would look like:  preserve_metadata(itemmeta) -- itemmeta is an ItemStackMetaRef
21:17 sfan5      you're missing at least the pos
21:17 sfan5      could this be done as an additional "meta" argument to on_dig?
21:21 paramat    i'll merge game#1835 game#1950 game#1955 in 1-2 hours
21:21 ShadowBot  https://github.com/minetest/minetest_game/issues/1835 -- Expose open_chests and chest_lid_obstructed by ForbiddenJ
21:21 ShadowBot  https://github.com/minetest/minetest_game/issues/1950 -- Flowers: Add black tulip, green chrysanthemum by paramat
21:21 ShadowBot  https://github.com/minetest/minetest_game/issues/1955 -- Improve burn times by Ezhh
21:22 ashtrayoz  Yes, pos is needed.  node could be passed as well, to make it look like on_dig.
21:23 ashtrayoz  If this was made an argument to on_dig, then we would have to add an on_fall callback.
21:23 sfan5      hm true, a new callback is fine then
21:33 ashtrayoz  Probably be back in about 12 hours with new code then :-)
21:43 sfan5      ashtrayoz: <nodedef>.persist_metadata(oldmeta, newmeta) would probably work (with <oldmeta> being in table form and <newmeta> a MetaRef)
22:52 paramat    sofar are you happy with #6639 ? it matches your 0.4.16 curve well and we can always tweak it later
22:52 ShadowBot  https://github.com/minetest/minetest/issues/6639 -- Light curve: Add and tune mid boost by paramat
23:30 sofar      yeah, I think it's OK
23:30 sofar      like I said, we'll tune this again :D
23:47 paramat    ok will merge later, thanks
23:55 Fixer      also forgot how that tin thing ended, it has some uses now?
23:58 Fixer      wrong channel