| Time |
Nick |
Message |
| 00:11 |
|
troller joined #minetest-dev |
| 00:21 |
|
troller joined #minetest-dev |
| 01:19 |
|
troller joined #minetest-dev |
| 01:25 |
|
paramat joined #minetest-dev |
| 01:40 |
|
Flitzpiepe joined #minetest-dev |
| 01:44 |
|
EvergreenTree joined #minetest-dev |
| 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 |
| 02:39 |
|
troller joined #minetest-dev |
| 02:56 |
|
troller joined #minetest-dev |
| 03:06 |
paramat |
+1 for game#1955 |
| 03:06 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1955 -- Improve burn times by Ezhh |
| 03:16 |
|
ThomasMonroe joined #minetest-dev |
| 03:29 |
|
troller joined #minetest-dev |
| 03:30 |
|
paramat joined #minetest-dev |
| 03:35 |
|
ashtrayoz joined #minetest-dev |
| 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? |
| 04:26 |
|
troller joined #minetest-dev |
| 05:20 |
|
troller joined #minetest-dev |
| 05:32 |
|
Fritigern joined #minetest-dev |
| 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 |
| 05:55 |
|
troller joined #minetest-dev |
| 06:06 |
|
troller joined #minetest-dev |
| 06:38 |
|
troller joined #minetest-dev |
| 07:03 |
|
troller joined #minetest-dev |
| 07:05 |
|
troller joined #minetest-dev |
| 07:58 |
|
Wuzzy joined #minetest-dev |
| 08:09 |
|
troller joined #minetest-dev |
| 08:10 |
|
Hunterz joined #minetest-dev |
| 08:29 |
|
Fritigern joined #minetest-dev |
| 08:41 |
|
nerzhul joined #minetest-dev |
| 08:59 |
|
troller joined #minetest-dev |
| 10:12 |
|
troller joined #minetest-dev |
| 10:19 |
|
troller joined #minetest-dev |
| 10:46 |
|
geospeck joined #minetest-dev |
| 11:09 |
|
ensonic joined #minetest-dev |
| 11:24 |
|
Krock joined #minetest-dev |
| 11:44 |
|
Fixer joined #minetest-dev |
| 11:47 |
|
troller joined #minetest-dev |
| 11:59 |
|
troller joined #minetest-dev |
| 12:11 |
|
ashtrayoz joined #minetest-dev |
| 12:24 |
|
troller joined #minetest-dev |
| 12:36 |
|
EvergreenTree joined #minetest-dev |
| 13:13 |
|
turtleman joined #minetest-dev |
| 13:34 |
|
proller__ joined #minetest-dev |
| 13:51 |
|
proller__ joined #minetest-dev |
| 14:09 |
|
nerzhul joined #minetest-dev |
| 14:48 |
|
troller joined #minetest-dev |
| 14:59 |
|
geospeck joined #minetest-dev |
| 15:34 |
|
Jordach joined #minetest-dev |
| 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 joined #minetest-dev |
| 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:30 |
|
Krock joined #minetest-dev |
| 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 |
| 18:51 |
|
ensonic joined #minetest-dev |
| 18:54 |
|
EvergreenTree joined #minetest-dev |
| 19:10 |
|
Jordach joined #minetest-dev |
| 19:10 |
|
ensonic joined #minetest-dev |
| 19:20 |
|
YuGiOhJCJ joined #minetest-dev |
| 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:51 |
|
CalebDavis joined #minetest-dev |
| 19:53 |
|
Warr1024 joined #minetest-dev |
| 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:02 |
|
torgdor joined #minetest-dev |
| 20:04 |
|
paramat joined #minetest-dev |
| 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 |
|
ThomasMonroe joined #minetest-dev |
| 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:20 |
|
AntumDeluge joined #minetest-dev |
| 20:25 |
|
Jordach joined #minetest-dev |
| 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 |
|
proller__ joined #minetest-dev |
| 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:19 |
|
YuGiOhJCJ joined #minetest-dev |
| 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:29 |
|
book` joined #minetest-dev |
| 21:33 |
ashtrayoz |
Probably be back in about 12 hours with new code then :-) |
| 21:36 |
|
book` joined #minetest-dev |
| 21:43 |
sfan5 |
ashtrayoz: <nodedef>.persist_metadata(oldmeta, newmeta) would probably work (with <oldmeta> being in table form and <newmeta> a MetaRef) |
| 21:49 |
|
Icedream joined #minetest-dev |
| 21:57 |
|
troller joined #minetest-dev |
| 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 |
| 23:58 |
|
Xio joined #minetest-dev |
