| Time |
Nick |
Message |
| 00:00 |
Exio4 |
hmmmm: ^ |
| 00:23 |
|
djdduty joined #minetest-dev |
| 00:23 |
|
djdduty joined #minetest-dev |
| 00:44 |
hmmmm |
Exio4, that's what I was thinking, but I'd still need to maintain reverse compatibility somehow |
| 00:46 |
sapier1 |
ok I guess I found a solution ... but it's quite ugly |
| 00:46 |
Exio4 |
what i thought was "hardcoding" for some time the flat option = flat mapgen, and say that option is deprecated and remove that "compat" in two releases or so, adding a notice about how-to change the mapgen in a world, like when creative/survival games got removed |
| 00:47 |
Exio4 |
when parsing options |
| 00:47 |
Exio4 |
but i don't know how that could be done, didn't check that code |
| 00:51 |
|
Sokomine joined #minetest-dev |
| 01:16 |
|
jojoa1997 joined #minetest-dev |
| 01:37 |
hmmmm |
Exio4, unlike sapier I'm not very big on those "WARNING WARNING DEPRECATED!" messages |
| 01:40 |
sapier1 |
:-) yea I'm the only one that's why deprecated code stays in codebase forever ;-P |
| 01:40 |
Exio4 |
i don't like useless code just for supporting old stuff |
| 01:41 |
hmmmm |
I mean what I could do is hard code in some check for MG_FLAT and set the mapgen to flat |
| 01:41 |
hmmmm |
but would that be encouraging people to do it either way? |
| 01:41 |
sapier1 |
yes but you can't avoid that code for some time ... with those ugly warnings you force ppl to switch to new mechanism ... not very polite ... true |
| 01:44 |
hmmmm |
the code that would need to be added for the 'kludge' is hardly anything |
| 01:44 |
hmmmm |
like 3 lines.. which is why I think I should forego the warning and just offer another more intuitive way to do the same thing |
| 01:45 |
sapier1 |
if you don't declare it deprecated you don't need a warning anyway ;-) |
| 01:46 |
hmmmm |
right, but before talking about doing more stuff, i ought to finish up what I started working on 3 months ago |
| 01:46 |
hmmmm |
ugh |
| 01:46 |
Exio4 |
hehe |
| 01:46 |
Exio4 |
irl stuff? :P |
| 01:46 |
hmmmm |
no, mapgen menu parameter configuration |
| 01:47 |
hmmmm |
I think I need to pause, more carefully determine what I am trying to accomplish with this, and *then* continue on rather than just coding some shit up and committing it |
| 01:48 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 01:48 |
hmmmm |
also, I don't like to admit it, but that prestowhatever guy was on the right track in the sense that some higher quality noise should be added |
| 01:49 |
hmmmm |
you notice it more with 3d I'd say |
| 01:49 |
hmmmm |
prestidigitator |
| 01:52 |
sapier1 |
does anyone have a problem with compilerswitches to make minetest compatible to different compilers? :-) |
| 01:52 |
hmmmm |
sure, as long as it doesn't involve slipping in a change to -O0 for debug like I caught that one time |
| 01:53 |
sapier1 |
so disabling unit tests won't be accepted too? ;-) |
| 01:53 |
sapier1 |
quite useless to have those things in a DEBUG build ... |
| 01:53 |
sapier1 |
crashes instantly |
| 01:53 |
sapier1 |
maybe we should add something like Real_Debug |
| 01:54 |
sapier1 |
you guys can't use a debugger for sure if you are fine with -O1 and unittests :-) |
| 01:56 |
hmmmm |
what's wrong with unit tests |
| 01:56 |
sapier1 |
they fail |
| 01:57 |
hmmmm |
they do? |
| 01:57 |
hmmmm |
i thought it was just that network related one that was fixed by increasing the delay |
| 01:58 |
sapier1 |
doesn't seem to help if you run within debugger |
| 01:58 |
hmmmm |
shrug |
| 02:10 |
|
hax404 joined #minetest-dev |
| 02:18 |
|
werwerwer joined #minetest-dev |
| 02:56 |
VanessaE |
https://github.com/minetest/minetest/pull/967 makes THIS possible --> http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/screenshot_4157666916.png ~~ http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/screenshot_4157907066.png ~~ http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/screenshot_4157692488.png |
| 02:56 |
VanessaE |
very straightforward to texture for - sun/moon need to be grayscale or close to it, and are tinted in realtime with a tone map, very similar to how MC does some of its in-world textures. |
| 02:57 |
VanessaE |
(those screenshots show actual in-game imagery from HDX) |
| 02:58 |
VanessaE |
\by default, the sun and moon are made to look about the same as they were before, most users probably won't notice the difference. |
| 02:59 |
VanessaE |
Taoki: can you try that pull alongside your tinted fog patch? I'm curious how that'll look |
| 02:59 |
VanessaE |
(it has been revised since your initial comment) |
| 03:07 |
NakedFury |
this can hopefuly lead to using it with grass, leaves, water. |
| 03:08 |
VanessaE |
possibly |
| 03:08 |
VanessaE |
there was some talk about that yes |
| 03:13 |
pitriss |
this new sun and moon should be more cubic:) |
| 03:13 |
VanessaE |
they are by defult. |
| 03:13 |
VanessaE |
default*( |
| 03:14 |
VanessaE |
they look about the same as before. |
| 03:14 |
VanessaE |
those ^^ screenshots just show what it looks like with a texture pack. |
| 03:17 |
VanessaE |
that patch is purely client-side btw |
| 03:18 |
sapier1 |
https://github.com/sapier/minetest/tree/fix_windows_i18n schould fix the localization issues added due to gettext usage from lua |
| 03:48 |
|
sapier1 left #minetest-dev |
| 04:26 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 05:26 |
|
werwerwer_ joined #minetest-dev |
| 07:04 |
|
nore joined #minetest-dev |
| 07:36 |
nore |
what do you think of https://github.com/minetest/minetest/pull/966 ? |
| 07:40 |
nore |
I have a suggestion for inventories too, that could fix many things |
| 07:41 |
nore |
instead of storing the stack that is being moved in the inventory, store it somewhere |
| 07:42 |
nore |
and when a player takes an item, store it there, when he puts it a chest, move the stack from there to the chest, etc. |
| 07:43 |
kaeza |
nore, that would mean that e.g. if several on_craft are registered, each successive one is passed the "new" itemstack (in case one of them returns the itemstack) |
| 07:43 |
kaeza |
is this intended? |
| 07:43 |
nore |
yes, of course |
| 07:44 |
nore |
so you can have a mod that checks for a player crafting something (e.g. achievements, etc) |
| 07:44 |
nore |
and a craft that will give some random item |
| 07:44 |
nore |
if they are registered in the correct order, the random item will trigger the craft thing |
| 07:45 |
nore |
however, the objective for most callbacks is either a little modification of the crafted item |
| 07:45 |
nore |
(i.e., add metadata) |
| 07:45 |
nore |
or a modification of a carft grid (wear a tool, for example) |
| 07:46 |
VanessaE |
moretrees coconuts + axe == coconut pieces + slightly worn axe |
| 07:46 |
VanessaE |
(+ milk) |
| 07:47 |
nore |
^ that way, you can also make multiple-output recipes |
| 07:48 |
|
Calinou joined #minetest-dev |
| 07:48 |
kaeza |
hmm... not sure about it, but could be usable |
| 07:48 |
kaeza |
let's see what modders come up with :P |
| 07:49 |
nore |
I need another core dev to clearly agree... sapier it ok with it |
| 08:17 |
|
darkrose joined #minetest-dev |
| 08:20 |
nore |
about that: https://github.com/minetest/minetest/issues/944 |
| 08:20 |
nore |
bug causing item loss with inventories |
| 08:20 |
nore |
I have a suggestion: |
| 08:21 |
nore |
when the player selects an item, store it somewhere else instead of leaving it where it is |
| 08:21 |
nore |
i.e.: the selected item should be an item stored in only one place, instead of having that "selected item" behaviour |
| 08:32 |
|
Ritchie joined #minetest-dev |
| 08:39 |
|
ImQ009 joined #minetest-dev |
| 08:42 |
|
Gethiox joined #minetest-dev |
| 08:42 |
|
ImQ009 joined #minetest-dev |
| 08:44 |
|
PilzAdam joined #minetest-dev |
| 08:51 |
|
RealBadAngel joined #minetest-dev |
| 08:57 |
nore |
RealBadAngel, do you agree with the new version of https://github.com/minetest/minetest/pull/966 ? |
| 09:02 |
|
sapier joined #minetest-dev |
| 09:04 |
nore |
sapier, are you still ok for #966? |
| 09:06 |
PilzAdam |
nore, do you really need to include inventory.h and inventorymanager.h in s_item.h? |
| 09:06 |
nore |
yes, I need inventorylist and inventorylocation |
| 09:07 |
PilzAdam |
clas InventoryList; class InventoryLocation; should work too |
| 09:08 |
sapier |
nore you only need pointers to them not the content (that's what pilzadam says) |
| 09:08 |
nore |
just writing that should work? |
| 09:08 |
PilzAdam |
yea, and include the headers in s_item.cpp then |
| 09:09 |
sapier |
if you do it the way pilzadam suggests cpp files including inventorymanager.h don't need to be rebuilt if inventory.h is changed |
| 09:09 |
sapier |
what pa suggests is called forward declaration it works as long as you don't need to access any "subelement" of a pointer |
| 09:09 |
nore |
wait, it uses inventorylist->getSize |
| 09:10 |
nore |
and ->getItem |
| 09:10 |
sapier |
ok then it wont work |
| 09:10 |
PilzAdam |
yea, but not in th s_item.h |
| 09:10 |
nore |
so, include the headers in the cpp |
| 09:10 |
PilzAdam |
you only need to include it for s_item.cpp |
| 09:10 |
sapier |
:-) I guess I should look at that file |
| 09:10 |
nore |
and define dummy classes in the header |
| 09:10 |
PilzAdam |
that would save us some compile time |
| 09:11 |
sapier |
exactly nore if you don't actually need the members in the header do only use forward declarations in there and include the real headers in cpp files where you can't avoid using it |
| 09:13 |
nore |
ok, done, it looks like it compiles correctly |
| 09:14 |
sapier |
hmm does anyone have an idea why gettext initialization is done as inline function? |
| 09:14 |
PilzAdam |
nore, "is should normally be the same as" |
| 09:15 |
sapier |
I understand why the char conversion functions are inline but for init it seems like someone didn't want to add a cpp file |
| 09:15 |
PilzAdam |
nore, the lua-api.txt part seems rather long, can you shorten it a bit? |
| 09:17 |
nore |
PilzAdam, done |
| 09:22 |
nore |
so, now is it ok for merging? |
| 09:22 |
PilzAdam |
https://gist.github.com/PilzAdam/7179556 |
| 09:23 |
nore |
Should I change lua_api.txt with that? |
| 09:23 |
nore |
(perhaps add a warning: do not assume that the crafting width is 3 too) |
| 09:24 |
PilzAdam |
modified it a bit, reload |
| 09:25 |
PilzAdam |
hm.. dunno if that warning is needed; it could go into the devwiki |
| 09:26 |
nore |
pushed, with the warning (after all, it costs nothing to put it here) |
| 09:28 |
PilzAdam |
I dont like to bloat lua-api.txt like this |
| 09:30 |
nore |
are 6 lines bloating? |
| 09:31 |
sapier |
due to size of lua-api.txt each additional line that isn't absolutely necessary has to be considered bloating ;-) |
| 09:31 |
nore |
so, I remove those last 2 lines? |
| 09:32 |
sapier |
just to throw this idea in again what about splitting lua-api.txt pa? ;-) |
| 09:32 |
PilzAdam |
sapier, you would break my way of using it by this |
| 09:32 |
sapier |
e.g. map related, object/entity related, generic |
| 09:32 |
PilzAdam |
because Ctrl+F wouldnt work anymore |
| 09:33 |
sapier |
I know but it does only work if you already know what your looking for either |
| 09:33 |
nore |
PA: removed those lines |
| 09:34 |
sapier |
and it'd be easy to concatenate thos splitted files withing build so a lua-api.txt full file is built for those actling like you ;-) |
| 09:34 |
nore |
PilzAdam, no need for Ctrl+F, grep -R works well |
| 09:50 |
nore |
so, will it be merged? |
| 09:53 |
sapier |
Mingw32 Build: http://a.pomf.se/f20eh.7z |
| 09:53 |
sapier |
MSVC Build: http://a.pomf.se/cf2ds.7z |
| 09:53 |
sapier |
hope I didn' forget a dll this time ;-) |
| 09:59 |
RealBadAngel |
anybody has an opinion on https://github.com/minetest/minetest/pull/967 ? |
| 10:01 |
nore |
RealBadAngel, it looks good, but I'd like a Lua function that can change the textures for a player only |
| 10:02 |
RealBadAngel |
this is meant for texture packs |
| 10:02 |
nore |
or perhaps even best: add more objects for a player (i.e. 2 suns, etc) |
| 10:02 |
nore |
yes, I know |
| 10:03 |
nore |
perhaps as a separate pull request, then |
| 10:03 |
nore |
RBA, do you still agree on #966? |
| 10:03 |
RealBadAngel |
such thing could as you suggesting could be made with api c55 is coding |
| 10:04 |
nore |
not yet (IIRC, the sky doesn't move, does it?) |
| 10:04 |
RealBadAngel |
but core of my change will remain intact, with api you could just change texture names or add another instances |
| 10:05 |
sapier |
what api celeron is coding are you talking about rba? |
| 10:05 |
RealBadAngel |
#960 |
| 10:06 |
sapier |
ahh :-) |
| 10:06 |
nore |
sapier, RBA, can #966 be merged? |
| 10:07 |
nore |
(if you both agree, that makes 2 core devs, doesn't it?) |
| 10:07 |
sapier |
I'm not the one to ask nore ;-) |
| 10:07 |
nore |
why? |
| 10:07 |
nore |
what do you mean? |
| 10:07 |
sapier |
I'm not a core dev ;) |
| 10:08 |
nore |
I thought you were... :( |
| 10:08 |
nore |
so I will have to ask someone else |
| 10:08 |
sapier |
rba and pa are as far as I know ;) |
| 10:08 |
nore |
PilzAdam, are you ok with it? |
| 10:09 |
RealBadAngel |
i havent checked the code, so i cant say if its rdy to merge. but i agree on that it is needed for many cases |
| 10:09 |
PilzAdam |
someone still needs to test it |
| 10:10 |
RealBadAngel |
if some1 will check codestyle i can write a mod to test it |
| 10:10 |
RealBadAngel |
i have in mind a few ideas |
| 10:11 |
PilzAdam |
its ok to merge if it works |
| 10:11 |
RealBadAngel |
so i will write simple mod with a tool wearing out after crafting |
| 10:11 |
RealBadAngel |
saw to cut block into slabs |
| 10:12 |
nore |
PilzAdam, https://gist.github.com/Novatux/7179966 |
| 10:12 |
nore |
to test |
| 10:12 |
nore |
(very basic) |
| 10:12 |
nore |
what it checks is that all parameters are really what they should be |
| 10:13 |
nore |
and that the itemstack returned is correctly changed |
| 10:15 |
sapier |
It's not really important but shouldn't it be "// do the callback" instead of "// make the callback" .. any natives in here? ;-) |
| 10:15 |
nore |
not be |
| 10:15 |
nore |
s/be/me |
| 10:16 |
nore |
and anyway, anyone can understand that |
| 10:16 |
sapier |
if you need to do other changes too I suggest removing that comment completely |
| 10:16 |
RealBadAngel |
is the callback registered for just itemstack? |
| 10:16 |
nore |
what do you mean, for just itemstack? |
| 10:16 |
PilzAdam |
there is a bug |
| 10:16 |
nore |
PilzAdam, what? |
| 10:17 |
RealBadAngel |
i mean what about multiple recipes to craft an item |
| 10:17 |
nore |
RealBadAngel, the callback is global |
| 10:17 |
RealBadAngel |
will the callback be called in every case? |
| 10:17 |
PilzAdam |
return ItemStack("default:wood"); <- this is not stackable, that means it doesnt matter how often you click, you only get one wood in your "hand" |
| 10:17 |
nore |
PilzAdam, that is normal |
| 10:17 |
PilzAdam |
so you basically lose the recipe |
| 10:17 |
PilzAdam |
I consider this a bug |
| 10:18 |
nore |
because you try to pick an item in the "craftresult" that is not the same as the one you're holding |
| 10:18 |
nore |
however, if you're crafting wood, you will see that you should be able to craft |
| 10:18 |
PilzAdam |
but both items are default:wood, I expect them to stack |
| 10:19 |
nore |
nope, in craftpreview, there is something else than default:wood |
| 10:19 |
nore |
so when you click on it while holding default:wood, crafting is not triggered |
| 10:20 |
nore |
and so the callback is not run, and the engine can't know that it will magically turn into default:wood |
| 10:20 |
RealBadAngel |
nore, if the callback is called for each and every recipe resulting with itemstack, maybe callbacks shall be given unique ID's |
| 10:20 |
PilzAdam |
the engine could know it by running the Lua function |
| 10:21 |
RealBadAngel |
for different recipes |
| 10:21 |
nore |
PilzAdam, but what about what the function will do? |
| 10:21 |
nore |
RealBadAngel, what I mean is that all registered callbacks are run when a craft in done |
| 10:22 |
RealBadAngel |
otherwise you cannot have two different callbacks for 2 recipes resulting in same crafted item |
| 10:22 |
nore |
so if you want something to trigger on wood or stone, you do |
| 10:22 |
nore |
if itemstack:get_name() == "default:wood" or itemstack;get_name()=="default:stone" then |
| 10:22 |
nore |
-- do what you want |
| 10:22 |
nore |
end |
| 10:23 |
nore |
and you can check the old_craft_grid to know what recipe was done |
| 10:23 |
RealBadAngel |
wouldnt it be better to register a callback for the recipe, not resulting item? |
| 10:24 |
nore |
what do you mean, for the recipe? |
| 10:24 |
nore |
if you want something specific to a recipe, you can check the old_craft_grid |
| 10:24 |
RealBadAngel |
if recipe is used and got crafting result then trigger it |
| 10:24 |
nore |
to see if that was the recipe |
| 10:24 |
nore |
and if so, run your callback |
| 10:25 |
nore |
the advantage of that is that it is much more powerful |
| 10:25 |
RealBadAngel |
this way we will have to check for crafting grid if something is there |
| 10:25 |
nore |
so you can make a global callback that will collect statistics, for example |
| 10:25 |
RealBadAngel |
to distinct which recipe was used to get the result |
| 10:26 |
RealBadAngel |
on the other hand, when you will trigger it on recipe usage, you will know for sure which case it is |
| 10:26 |
RealBadAngel |
lemme give you an example: we have saws. iron, mese, diamond ones |
| 10:26 |
nore |
well, with a recipe-specific callback, how do you make a mod that collects statistics to know how many times you've crafted each thing? |
| 10:27 |
RealBadAngel |
and resulting 2 stone slabs on use |
| 10:27 |
nore |
and? |
| 10:27 |
RealBadAngel |
your way callback will be called whenever saws were used, it was crafted or whatever |
| 10:28 |
RealBadAngel |
you will have to find out who the f... trigerred that |
| 10:28 |
RealBadAngel |
callback on recipe usage will bring you straightforward to your code |
| 10:28 |
nore |
well, for that you could check the craft grid to see if there is a saw in it |
| 10:29 |
nore |
yes, but what about my previous question? |
| 10:29 |
nore |
<nore> well, with a recipe-specific callback, how do you make a mod that collects statistics to know how many times you've crafted each thing? |
| 10:30 |
nore |
PilzAdam, about the fact that is does not stack: |
| 10:30 |
nore |
most mods will not change the output, or only add metadata to it |
| 10:30 |
nore |
so there will be no problem with that |
| 10:30 |
RealBadAngel |
nore, simply, increase +1 table with result item |
| 10:31 |
RealBadAngel |
or with quantity of it |
| 10:31 |
RealBadAngel |
on every callback |
| 10:31 |
nore |
yes, but you need a callback for every craft recipe... |
| 10:31 |
nore |
what do you do with other mod's craft recipes, then? |
| 10:32 |
RealBadAngel |
have default callback to handle the statistics and eventually call user defined one |
| 10:32 |
nore |
PilzAdam, what about if the function has side effects too? (such as doing statistics) |
| 10:33 |
PilzAdam |
thats the problem |
| 10:33 |
nore |
yes, but you still need a callback for every craft recipe |
| 10:33 |
nore |
PilzAdam, most mods will not change the output |
| 10:33 |
nore |
and among those that will do, it will mostly be to set some metadata in a tool or somthing like that |
| 10:34 |
PilzAdam |
you dont know what mods will do |
| 10:34 |
nore |
so it will be possible to stack |
| 10:34 |
nore |
PilzAdam, of course I don't |
| 10:34 |
nore |
but really, what mod will make a craft recipe give something, and *always* change it with something else. |
| 10:34 |
nore |
? |
| 10:35 |
nore |
that's not coherent! |
| 10:35 |
nore |
and if they do that, it is their problem |
| 10:35 |
nore |
i.e.: if I want to do a craft recipe that gives a random amount of something |
| 10:36 |
RealBadAngel |
btw, i can see another side effect. if i do register callbacks for cutting, with different tools, will have too old crafting ones it means that all the callbacks will be run |
| 10:36 |
RealBadAngel |
instead of just one |
| 10:36 |
RealBadAngel |
for the correct case |
| 10:36 |
nore |
RealBadAngel, you still have only one callback to register if you do it correctly |
| 10:37 |
RealBadAngel |
one can have many ways to get one item. provided by many mods |
| 10:37 |
nore |
I would set the output to that something, and then randomly change the itemstack count |
| 10:37 |
RealBadAngel |
that means multiple callbacks |
| 10:37 |
nore |
RealBadAngel, not with the current way |
| 10:37 |
RealBadAngel |
not? |
| 10:37 |
nore |
you only need to check that the output is your item in the single callback |
| 10:38 |
nore |
if itemstack:get_name() == "myitem" then |
| 10:38 |
nore |
--do what you need to do |
| 10:38 |
nore |
end |
| 10:38 |
PilzAdam |
nore, imagine a mod that modifies craft results based on player classes |
| 10:38 |
RealBadAngel |
im talkin about case that multiple recipes defined by different mods leads to the very same item |
| 10:38 |
nore |
so I should add a predict_craft_result function? |
| 10:39 |
nore |
RealBadAngel, that's exactly what my code detects |
| 10:39 |
nore |
if the output is that item, then do something |
| 10:39 |
RealBadAngel |
what if two mods calls for the very same item |
| 10:40 |
nore |
then the two callbacks are run |
| 10:40 |
RealBadAngel |
what if there are lets say 20 ways to get stone slab |
| 10:40 |
nore |
PilzAdam, so perhaps some minetest.register_craft_prediction? |
| 10:40 |
RealBadAngel |
we do have 20 callbacks then |
| 10:40 |
nore |
all 20 ways would trigger the same callback |
| 10:41 |
RealBadAngel |
hold on, the same? |
| 10:41 |
RealBadAngel |
i defined two callbacks |
| 10:41 |
nore |
say, if I do: |
| 10:41 |
RealBadAngel |
will they override each other? |
| 10:42 |
nore |
no, of course! |
| 10:42 |
nore |
the first registered will be run, then the second registered will be run too |
| 10:43 |
RealBadAngel |
huh, it may work, but coding all the cases will be time consuming |
| 10:43 |
nore |
PilzAdam, what about what I said? |
| 10:43 |
PilzAdam |
nore, the problem with that is that it runs on the server, so it would be quite laggy |
| 10:43 |
nore |
craft already runs on the server |
| 10:44 |
nore |
my pull request does not change that |
| 10:44 |
RealBadAngel |
identyfing the recipe will be time consuming |
| 10:45 |
nore |
RealBadAngel, perhaps some function can be written in builtin for that |
| 10:45 |
nore |
recipe_matches_craft_grid, or somthing like that |
| 10:46 |
RealBadAngel |
register craft could return recipe id, callback should provide it |
| 10:46 |
RealBadAngel |
maybe something like that |
| 10:47 |
RealBadAngel |
but this would require extra code |
| 10:47 |
RealBadAngel |
imho callback on recipe is easier and way faster |
| 10:47 |
nore |
no, it is not easier to code |
| 10:47 |
nore |
and it is less powerful |
| 10:48 |
RealBadAngel |
why less powerful? |
| 10:48 |
nore |
for the very reason I said above |
| 10:54 |
|
Calinou joined #minetest-dev |
| 10:54 |
RealBadAngel |
you will have your callback for the itemstack, it could be default one |
| 10:54 |
RealBadAngel |
but the user defined could be taken from recipe |
| 10:55 |
RealBadAngel |
so call your one as by now, take user's from recipe if provided and call it |
| 10:56 |
nore |
so you mean, one global callback that checks for recipes callbacks |
| 10:56 |
RealBadAngel |
huh, wait |
| 10:57 |
RealBadAngel |
one global with possible global user defined (for the statistics or whatever) |
| 10:57 |
RealBadAngel |
and then recipe dependent if provided |
| 10:57 |
RealBadAngel |
that would be perfect |
| 10:57 |
nore |
could do that later |
| 10:58 |
nore |
for now, I'm working on PilzAdam's thing |
| 11:00 |
RealBadAngel |
that will combine yours and mine way and minimalize code needed to identify recipes used |
| 11:01 |
RealBadAngel |
so for example i could get directly to diamond saw code, you will still have global callbacks for another stuff |
| 11:07 |
nore |
how do you get an inventorylocation from a player? |
| 11:07 |
nore |
I have a player, and I want its inventory location |
| 11:07 |
nore |
how do I do that? |
| 11:21 |
RealBadAngel |
hold on |
| 11:22 |
RealBadAngel |
in engine? |
| 11:23 |
nore |
nvm, I found it |
| 11:29 |
nore |
PilzAdam, could you look at the latest commit and tell me what you think of it? |
| 11:32 |
nore |
PilzAdam, are you still there? |
| 11:43 |
|
evorios joined #minetest-dev |
| 11:48 |
nore |
PilzAdam, example use: https://gist.github.com/Novatux/7179966 |
| 12:17 |
sapier |
https://github.com/minetest/minetest/pull/968 use mingw zlib on mingw builds |
| 12:20 |
nore |
sapier, have you seen the last version of #966? |
| 12:22 |
sapier |
overriding predicion too ... :-) guess now we need an additional function to fetch dynamic recieps too ;-) |
| 12:22 |
nore |
https://gist.github.com/Novatux/7179966 <--look at that |
| 12:23 |
nore |
this makes steel blocks with a single stack of steel ingots |
| 12:24 |
sapier |
do we actually need recieps any longer? |
| 12:26 |
nore |
way easier than that |
| 12:26 |
nore |
and what you can do too is: |
| 12:26 |
nore |
minetest.register_craft{output = "placeholder"... |
| 12:27 |
nore |
and then check if itemstack is placeholder to do your things |
| 12:27 |
sapier |
I'm not convinced this is right way to do it as it seems to me we now have two almost unrelated ways of specifying recieps |
| 12:27 |
sapier |
maybe whole reciep mechanics should be reworked |
| 12:28 |
nore |
the objective is to be able to do things that were not possible, e.g., make a block with metadata, depending on which items your craft it with |
| 12:28 |
nore |
etc. |
| 12:28 |
sapier |
don't get me wrong imho your additions are far more advanced than the old ones ... maybe your version should replace the old way of doing it ... but I'm not sure if it's already capable of replacing it completely |
| 12:28 |
nore |
recipes are for normal things |
| 12:29 |
sapier |
that doesn't matter "normal" is just a special case of complex ;-) |
| 12:29 |
nore |
I reckon it is, by adding a Lua function able to detect if something is a craft recipe |
| 12:30 |
nore |
and then adding the first callback to check for those registered craft recipes |
| 12:30 |
nore |
however, I don't think it should be changed now, since minetest.get_craft_result would become *slow* |
| 12:31 |
nore |
and crafting too |
| 12:32 |
sapier |
ok so at least entry point needs to stay as is .. but you should have a look at those functions returning craft reciep list. In best case find way to make them show the changes added by those lua callbacks |
| 12:33 |
sapier |
or if not possible add some special marker so a mod can recognize a reciep may not be valid the way it's listed |
| 12:48 |
|
Gethiox2 joined #minetest-dev |
| 12:54 |
|
hmmmm joined #minetest-dev |
| 13:01 |
|
evorios joined #minetest-dev |
| 13:12 |
nore |
hmmmm, what do you think now of #966? |
| 13:12 |
nore |
with that https://gist.github.com/Novatux/7179966 to test it |
| 13:41 |
|
jojoa1997 joined #minetest-dev |
| 14:25 |
|
jojoa1997 joined #minetest-dev |
| 14:25 |
|
jojoa1997 left #minetest-dev |
| 14:26 |
|
Zeitgeist_ joined #minetest-dev |
| 14:41 |
|
zat joined #minetest-dev |
| 14:49 |
nore |
is anyone here ok for #966? |
| 14:59 |
|
zat joined #minetest-dev |
| 15:00 |
nore |
I had a question about perlins: how costly are they? |
| 15:26 |
|
evorios joined #minetest-dev |
| 15:32 |
|
Miner_48er joined #minetest-dev |
| 15:43 |
|
dysoco joined #minetest-dev |
| 15:43 |
dysoco |
Can I import minetest into an IDE? What do you use? |
| 15:43 |
dysoco |
I guess I could just use Emacs + ctags but |
| 15:48 |
ShadowNinja |
zat: Any progress on SQLite rollback? |
| 15:49 |
nore |
ShadowNinja, did you add entities to #856? |
| 15:49 |
nore |
cause I reckon that is why it is not merged yet |
| 15:50 |
nore |
btw, have you seen what it is possible to do with #966? |
| 15:50 |
nore |
https://gist.github.com/Novatux/7179966 |
| 15:51 |
ShadowNinja |
nore: I updated the docs to mention the fact that someone might use the functions with entities. But they always worked, as long as you rounded the position of course. |
| 15:52 |
nore |
I reckon they wished it for taking builtin_item, IIRC |
| 15:52 |
nore |
perhaps dropping too |
| 15:54 |
ShadowNinja |
nore: Neat. |
| 15:54 |
zat |
ShadowNinja: not so far but I want to finish it soon |
| 15:54 |
zat |
I am going to make it more storage optimizing |
| 15:54 |
ShadowNinja |
Ok, sounds good. |
| 15:55 |
zat |
And I hope not to be complained much for my code... |
| 15:57 |
dysoco |
Does Minetest have any kind of automated tests to see if the build is OK? |
| 15:58 |
nore |
there are unit tests, but not everything can be tested automatically |
| 15:59 |
dysoco |
Well I'll search for the unit tests |
| 15:59 |
nore |
I have heard that some of them fail, so... |
| 16:01 |
|
NakedFury joined #minetest-dev |
| 16:01 |
ShadowNinja |
dysoco: We have automatic travis builds. See https://travis-ci.org/minetest/minetest |
| 16:02 |
|
Calinou joined #minetest-dev |
| 16:02 |
nore |
well, I reckon what he asked was to check if the build worked correctly, not if if built correctly |
| 16:04 |
dysoco |
Yeah, I mean, the code builds, but how do I know I haven't broke anything |
| 16:04 |
dysoco |
that's what I mean |
| 16:47 |
ShadowNinja |
Just compile it and run the executable. If it works it works. There are some unit tests in test.cpp that run unless ou use --disable-unittests |
| 16:51 |
|
Jordach joined #minetest-dev |
| 16:54 |
dysoco |
Alright, thanks. |
| 16:58 |
|
NakedFury joined #minetest-dev |
| 16:59 |
|
rubenwardy joined #minetest-dev |
| 17:01 |
|
Anchakor joined #minetest-dev |
| 17:33 |
|
iqualfragile joined #minetest-dev |
| 17:47 |
dysoco |
Is there a coding standard? Can't find one, and the code is written in different ways all arround |
| 17:47 |
dysoco |
style guide* |
| 17:48 |
ShadowNinja |
dysoco: http://dev.minetest.net/Code_style_guidelines |
| 17:48 |
rubenwardy |
This is open source, there is no style! [/jokes] I think there might be an article on dev.minetest.net |
| 17:49 |
dysoco |
ShadowNinja: thanks! |
| 17:52 |
dysoco |
Looks a bit too broad though, like doesn't specify wether to use Allman or BSD style. |
| 17:52 |
Calinou |
try to follow the most guidelines you can :) |
| 17:52 |
Calinou |
no idea what's the difference between these |
| 17:53 |
dysoco |
opening brace goes either in the same line as declaration of the function (or if statement, or whatever) or in a new line |
| 17:53 |
dysoco |
but I'm just too perfectionist, everything must be perfect and the same :P |
| 17:55 |
celeron55 |
well those guidelines partly conflict with what is actually used because they've been written by hmmmm |
| 17:56 |
nore |
celeron55, what do you think of https://github.com/minetest/minetest/pull/966 ? |
| 17:57 |
hmmmm |
indeed |
| 17:57 |
hmmmm |
that's the style I follow, but it's somewhat acceptable if you follow the code style of what's already prevalent in that source file |
| 17:57 |
celeron55 |
they should be adjusted a bit; for example that thing about switches at the start hasn't been and isn't followed at all |
| 17:57 |
hmmmm |
yeah, that's true, I've been meaning to fix that actually |
| 17:59 |
nore |
what do you think of #966? |
| 17:59 |
nore |
(craft callback) |
| 18:02 |
celeron55 |
wait wtf https://github.com/prestidigitator/minetest/blob/objnoise/src/noise.h |
| 18:02 |
celeron55 |
i hadn't looked at this file before |
| 18:03 |
|
iqualfragile joined #minetest-dev |
| 18:03 |
nore |
what is the problem with that file? |
| 18:03 |
|
sapier1 joined #minetest-dev |
| 18:03 |
nore |
(except that it is perhaps a bit too much OO) |
| 18:04 |
celeron55 |
...it's so utterly ridiculously verbose that it's not even funny anymore |
| 18:04 |
dysoco |
that identation |
| 18:04 |
dysoco |
appropiate file name: noise.h :P |
| 18:04 |
nore |
yeah, some of the comments are useless |
| 18:07 |
nore |
that should be called noise.comments |
| 18:07 |
nore |
that would be a correct file name |
| 18:08 |
nore |
so, any thought on #966? |
| 18:09 |
celeron55 |
i don't know, i need to focus on something else |
| 18:14 |
|
iqualfragile joined #minetest-dev |
| 18:28 |
PilzAdam |
lol "@param x \n The point's x coordinate." <- why we dont like doxygen |
| 18:29 |
thexyz |
why? |
| 18:31 |
PilzAdam |
what why? |
| 18:33 |
thexyz |
why don't we like doxygen? |
| 18:35 |
thexyz |
having too much documentation is better than having no docs at all, isn't it? |
| 18:35 |
dysoco |
You can use doxygen without having stupid comments |
| 18:42 |
thexyz |
and since we're talking about noise.h anyway why do this? https://github.com/minetest/minetest/blob/master/src/noise.h#L48 |
| 18:44 |
ShadowNinja |
VanessaE is having a issue where the assert() statements in vector.lua don't generate a backtrace. I haven't reproduced it. Does anyone know why this might happen? |
| 18:54 |
|
loggingbot_ joined #minetest-dev |
| 18:54 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 19:01 |
|
ImQ009 joined #minetest-dev |
| 19:28 |
|
ImQ009 joined #minetest-dev |
| 19:29 |
celeron55 |
thexyz: it's basically not implemented |
| 19:29 |
celeron55 |
feel free to implement |
| 19:34 |
|
smoke_fumus joined #minetest-dev |
| 20:17 |
VanessaE |
celeron55: did you see RBA's latest pull? |
| 20:18 |
VanessaE |
https://github.com/minetest/minetest/pull/967 -- with that plus HDX, you get --> https://forum.minetest.net/viewtopic.php?pid=115811#p115811 |
| 20:23 |
VanessaE |
(he figured out how to do what you said you weren't sure could be easily done ;) ) |
| 20:52 |
celeron55 |
VanessaE: uhm |
| 20:52 |
celeron55 |
VanessaE: so what have i said is easily done that is in there? |
| 20:52 |
celeron55 |
+not |
| 20:53 |
VanessaE |
celeron55: some time back we discussed doing this, and you mentioned that it would be either cumbersome, or would not look right. Just syaing. |
| 20:53 |
VanessaE |
saying* |
| 20:55 |
celeron55 |
yeah and you left out what is "it" |
| 20:56 |
VanessaE |
oh, the idea of tinting a texture |
| 20:56 |
VanessaE |
you were rather convinced that there was no easy way to do it. |
| 20:57 |
VanessaE |
anyways, it works well. |
| 20:57 |
VanessaE |
or more specifically, the idea of tinting it in realtime to match the general color progression of a sunrise |
| 20:58 |
celeron55 |
i don't recall anything about this so whatever |
| 20:58 |
VanessaE |
no matter :P |
| 21:08 |
|
Pietrko joined #minetest-dev |
| 21:25 |
|
Pietrko left #minetest-dev |
| 22:50 |
|
Gethiox3 joined #minetest-dev |
| 22:59 |
|
iqualfragile joined #minetest-dev |
| 23:19 |
|
iqualfragile joined #minetest-dev |
| 23:37 |
Sokomine |
i want to return diffrent types of drops depending on which tool is used. any recommended way of doing so? else i'll probably set drops to nothing and handle out the drops in after_dig_node manually |
| 23:37 |
|
Miner_48er joined #minetest-dev |
| 23:38 |
Sokomine |
perhaps there's a better way i'm currently not seeing |
| 23:48 |
|
sapier1 left #minetest-dev |
