| Time |
Nick |
Message |
| 00:51 |
|
Neological joined #minetest-dev |
| 01:03 |
|
AllegedlyDead joined #minetest-dev |
| 03:16 |
|
Zacrath joined #minetest-dev |
| 03:18 |
|
Zacrath joined #minetest-dev |
| 05:56 |
|
nore joined #minetest-dev |
| 06:17 |
|
kaeza joined #minetest-dev |
| 06:17 |
|
darkrose joined #minetest-dev |
| 06:17 |
|
darkrose joined #minetest-dev |
| 06:27 |
|
kaeza joined #minetest-dev |
| 06:38 |
nore |
is anyone here? I have 2 suggestions |
| 06:50 |
VanessaE |
make your suggestions anyway, if only for the log. |
| 06:52 |
nore |
those are already in #minetest... |
| 06:54 |
VanessaE |
some folks are in here that aren't in #minetest |
| 07:02 |
nore |
so those suggestions are minetest.swap_node (instead of using haky_swap_nodes, which causes formspec problems on the client) |
| 07:02 |
nore |
and minetest.get_loaded_blocks, minetest.register_on_block_load, minetest.register_on_block_unload |
| 07:03 |
sfan5 |
get_loaded_blocks returns something like {{x=-2, y=1, z=2}, {x=-1, y=1, z=1}} ? |
| 07:04 |
nore |
yes, that could be good |
| 07:05 |
nore |
on perhaps minp,maxp |
| 07:05 |
sfan5 |
minetest.register_on_block(un)?load is called with (blockpos) ? |
| 07:05 |
sfan5 |
s/(blockpos)/func/(blockpos)/ |
| 07:05 |
sfan5 |
woops |
| 07:05 |
sfan5 |
s/(blockpos)/func(blockpos)/ |
| 07:06 |
sfan5 |
we don't need minp or maxp |
| 07:06 |
nore |
yes, it should be ok |
| 07:08 |
sfan5 |
it would just be "minp = vector.new(blockpos) * 16; maxp = minp + 16" for minp and maxp |
| 07:10 |
sfan5 |
hm |
| 07:11 |
sfan5 |
minp, maxp would actually be better for both functions |
| 07:11 |
sfan5 |
mods shouldn't depends on BLOCK_SIZE being 16 |
| 07:13 |
nore |
yes, that's why I thought minp, maxp would be better |
| 07:14 |
nore |
about what about a minetest.swap_node that would avoid hacky_swap_node, which is, as its name says, hacky |
| 07:17 |
celeron55 |
we don't expose blocks to mods |
| 07:17 |
celeron55 |
so it would be get_loaded_positions() that returns a list of {minp, maxp} pairs or something |
| 07:19 |
celeron55 |
i think swap_node could exist, but someone needs to see if there are problems in such |
| 07:58 |
|
Calinou joined #minetest-dev |
| 08:13 |
nore |
and another suggestion: one more parameter to ABM that would be "time_since_last_executed" |
| 08:44 |
proller |
nore, updated |
| 08:44 |
nore |
thanks |
| 08:55 |
|
darkrose joined #minetest-dev |
| 09:31 |
|
Calinou joined #minetest-dev |
| 09:50 |
sfan5 |
I've got a table way of representing formspecs now that works and supports all features of the current formspecs: http://sfan5.duckdns.org/minetest-formspec-luatable.txt |
| 09:52 |
|
proller joined #minetest-dev |
| 10:20 |
|
Zeitgeist_ joined #minetest-dev |
| 10:24 |
|
PilzAdam joined #minetest-dev |
| 10:32 |
proller |
sfan5, cool |
| 10:37 |
proller |
sfan5, then make searialize in json, and using json struct in c++ -> much less code |
| 10:37 |
sfan5 |
no |
| 10:38 |
VanessaE |
proller: please don't go lamefun on us :P |
| 10:40 |
sfan5 |
it is intended to be a lua side things |
| 10:40 |
sfan5 |
-s |
| 10:41 |
sfan5 |
because its confusing which field in dropdown[1,2;3,5;abc;def;foo,bar,foo;2] is which |
| 10:46 |
proller |
its must be key-value |
| 10:47 |
proller |
idea here - http://dev.minetest.net/Formspec_json |
| 11:14 |
|
Jordach joined #minetest-dev |
| 11:51 |
|
Calinou joined #minetest-dev |
| 12:09 |
thexyz |
objections? https://gist.github.com/xyzz/2bf7e9144b2f76599996 |
| 12:10 |
sfan5 |
I don't think you need to ask to commit that :P |
| 12:11 |
PilzAdam |
thexyz, seems good |
| 12:12 |
thexyz |
sfan5: PA could get angry |
| 13:18 |
|
Calinou joined #minetest-dev |
| 13:24 |
|
kaeza joined #minetest-dev |
| 13:26 |
|
Zeg9 joined #minetest-dev |
| 13:52 |
|
Akien joined #minetest-dev |
| 14:03 |
|
hax404 joined #minetest-dev |
| 15:49 |
|
loggingbot_ joined #minetest-dev |
| 15:49 |
|
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/ |
| 16:08 |
|
Zeg9 joined #minetest-dev |
| 17:28 |
|
Miner_48er joined #minetest-dev |
| 17:29 |
|
thexyz joined #minetest-dev |
| 18:04 |
|
proller joined #minetest-dev |
| 18:05 |
celeron55 |
>I don't think you need to ask to commit that |
| 18:05 |
celeron55 |
one doesn't need to ask, but notifying a reasonable time before pushing is always right |
| 18:07 |
nore |
I have something that is more-or-less a bug report |
| 18:08 |
sfan5 |
any new opinions on using lua tables for formspecs but keeping the string format internally? |
| 18:08 |
nore |
if I am correct, inv:remove_item called with stack count>stack max will only remove stack_max items, even if there are enough items |
| 18:09 |
nore |
when I say more-or-less bug report, it is because it is perhaps normal |
| 18:09 |
PilzAdam |
sfan5, just add minetest.table_to_formspec({...}) |
| 18:09 |
celeron55 |
nore: sounds like a bug |
| 18:10 |
celeron55 |
nore: altough... yes, it's kind of arguable, because it'd need to return an itemstack that is too large 8) |
| 18:11 |
nore |
that causes a bug with pipeworks :( |
| 18:11 |
celeron55 |
but my opinion is that changing it would make it less clumsy as an interface which is how interfaces should work |
| 18:12 |
nore |
because I use it to remove a number of items from an inventory, but I don't care about the returned stack |
| 18:19 |
proller |
https://github.com/minetest/minetest/pull/895 https://github.com/minetest/minetest/pull/892 https://github.com/minetest/minetest/pull/883 |
| 18:19 |
proller |
https://github.com/minetest/minetest/pull/882 |
| 18:20 |
proller |
celeron55, btw, 2 weeks of asking agree - reasonable time ? |
| 18:24 |
celeron55 |
well what can i say? it doesn't matter 8) |
| 18:27 |
|
Yepoleb joined #minetest-dev |
| 18:28 |
celeron55 |
if nobody is interested, there are exactly three options: 1) talk enough to get them interested (posting links is not talking); 2) give up; 3) code more to have a more impressive bunch of stuff |
| 18:29 |
nore |
celeron55, I use the first option with my pulls... |
| 18:30 |
celeron55 |
i recommend the first option :P |
| 18:31 |
nore |
btw, what do you thinkof #688? |
| 18:31 |
nore |
It adds a tool callback instead of wearing the tool out |
| 18:32 |
nore |
if the callback is defined for that tool |
| 18:47 |
|
sapier joined #minetest-dev |
| 18:52 |
|
Jordach_ joined #minetest-dev |
| 18:57 |
celeron55 |
nore: i guess it's good |
| 18:57 |
celeron55 |
i wonder though what the action should be if it returns nil |
| 18:57 |
celeron55 |
an another one that would make sense would be to normally wear the tool in that case |
| 18:57 |
nore |
it does not wear the tool if it returns nil |
| 18:58 |
celeron55 |
so that if someone wants to eg. add a particle effect or something else like that not related to the wear, he doesn't need to take care about wear |
| 18:58 |
celeron55 |
or is there some reasoning against this |
| 18:59 |
nore |
the digparams is given to the callback, and PilzAdam said that to be compatible to the other api calls, we should not change the stack if return is nil |
| 19:00 |
kahrl |
nore: doc/lua_api.txt:1953 -- shouldn't this line have 'if not minetest.setting_getbool("creative_mode")' around it? |
| 19:00 |
|
BrandonReese joined #minetest-dev |
| 19:00 |
celeron55 |
nore: well that isn't really related to whether to wear it or not in case of nil? |
| 19:00 |
nore |
idk |
| 19:01 |
celeron55 |
PilzAdam: ^ |
| 19:02 |
nore |
but if you want, I can change it, it is a 30-second change |
| 19:03 |
|
proller joined #minetest-dev |
| 19:03 |
nore |
kahrl, yes, you're right, the pull was before that... |
| 19:04 |
celeron55 |
nore: i want PilzAdam to consider it |
| 19:04 |
PilzAdam |
its a matter of documentation |
| 19:04 |
celeron55 |
PilzAdam: it's also a matter of having sane defaults |
| 19:04 |
PilzAdam |
currently there is "should wear out tool", so it shouldnt wear it out if its nil |
| 19:05 |
celeron55 |
defaults should never surprise even if documentation isn't read properly |
| 19:05 |
PilzAdam |
I wonder if we should rather use minetest.after_place() and set that as default in the nodedef |
| 19:05 |
sfan5 |
PilzAdam: thats not how it should be, tables should be used as replacement for text formspec |
| 19:06 |
nore |
so, do you want me to change that, or not? |
| 19:06 |
PilzAdam |
this "if not minetest.setting_getbool("creative_mode") then" seems a bit wrong to me, it should be done by the game, not the engine |
| 19:07 |
PilzAdam |
the engine doesnt change anything else if creative_mode is on |
| 19:07 |
nore |
yes it does: minetest.item_place |
| 19:08 |
PilzAdam |
nore, I dont see anything else than the wearing out of the tool being different in creative_mode |
| 19:08 |
PilzAdam |
if we would add minetest.after_use(), then creative could override it to handle the creative_mode |
| 19:09 |
nore |
aren't the infinite items in builtin? |
| 19:09 |
PilzAdam |
nope |
| 19:09 |
kahrl |
btw, should it be called after_dig? |
| 19:09 |
kahrl |
otherwise I'd think it has to do with on_use |
| 19:10 |
nore |
so, a per-tool callback, + a global callback? |
| 19:11 |
nore |
kahrl: it has, since it is same as on_use, but after the node has been dug |
| 19:11 |
kahrl |
but if you define on_use the item can't dig at all |
| 19:12 |
nore |
yes, and that's why I added this callback... |
| 19:13 |
proller |
ok.. https://github.com/minetest/minetest/pull/883/files - small change, fixes unreal temps, want to commit |
| 19:14 |
kahrl |
proller, why hardcode these noiseparams values? |
| 19:16 |
proller |
they in m_emerge->biomedef->np_heat in ugly 50 +-50 format now, better to change it and get ftom them |
| 19:16 |
proller |
but hmmmm doesnt allow to touch |
| 19:17 |
proller |
in this function not noiseparams, its just normalize to reasonable values |
| 19:20 |
kahrl |
what about mods that use minetest.get_heat/minetest.get_humidity? (are there any?) |
| 19:20 |
kahrl |
would they have to change? |
| 19:21 |
hmmmm |
no, it's the biome definitions |
| 19:21 |
hmmmm |
i know pilztest uses them at least |
| 19:21 |
sapier |
heat/humidity haven't been in any stable version by now (as far as I know) |
| 19:21 |
|
jojoa1997 joined #minetest-dev |
| 19:21 |
proller |
no, values was good, but sometimes can increase to like 90c |
| 19:21 |
hmmmm |
they *have*, but, they really weren't doing anything much except selecting biomes for essentially what is an experimental mapgen |
| 19:22 |
hmmmm |
alright |
| 19:22 |
hmmmm |
i promise i'm going to fix that up tonight |
| 19:23 |
hmmmm |
proller, i'll give the values you normalized the heat/humidity to some consideration, but i'm looking for some properties in particular with the heat/humidity gradients |
| 19:24 |
hmmmm |
like for one i'm probably going to add more octaves to them and increase the scale |
| 19:25 |
proller |
i can commit my patch now, and fix after your |
| 19:26 |
proller |
and want make HELL in last 1000: |
| 19:26 |
proller |
if (p.Y < -30000) heat += 6000 * (1-((float)(p.Y - -31000)/1000)); //hot core |
| 19:26 |
hmmmm |
lol |
| 19:26 |
hmmmm |
yeah see.... there's no way i'd agree to hardcoding that |
| 19:26 |
hmmmm |
remember i was talking about the realm idea |
| 19:27 |
proller |
i can make configurable |
| 19:27 |
hmmmm |
there would be a nether 'realm type' and a sky 'realm type' and whatever |
| 19:27 |
hmmmm |
no, don't |
| 19:27 |
hmmmm |
for now that's fine, it doesn't really matter |
| 19:27 |
nore |
proller, you can make a lua function that will modify minetest.get_heat |
| 19:27 |
hmmmm |
it's just that i'm gonna have to modify that at some point |
| 19:27 |
hmmmm |
proller, give me a little while to look over your commits first |
| 19:28 |
proller |
nore, no, cant, it used by core |
| 19:28 |
nore |
then allow modifications ;) |
| 19:28 |
nore |
the core should re-call lua |
| 19:29 |
proller |
i think about it, like storing u16 heat_add in block, and allow modify it from lua |
| 19:29 |
kahrl |
lua shouldn't know about mapblocks |
| 19:30 |
hmmmm |
yes^ |
| 19:30 |
hmmmm |
stop it with the block idea |
| 19:30 |
proller |
it can access by x,y,z coord, like get_heat now |
| 19:30 |
proller |
but store per block |
| 19:31 |
hmmmm |
er, well whatever |
| 19:31 |
hmmmm |
i see what you mean |
| 19:31 |
hmmmm |
if you're going to do that, please name it heat_offset or something instead |
| 19:32 |
proller |
ok |
| 19:34 |
|
Tom-s joined #minetest-dev |
| 19:40 |
proller |
idea "hot core" was for making unreachable -31000 with melting stone |
| 19:41 |
proller |
like anything melting and burning and you cant dig deeper |
| 20:22 |
proller |
still want to commit https://github.com/minetest/minetest/pull/883/files before peoples start it using |
| 20:23 |
proller |
tested 1/5 weeks on server |
| 20:23 |
proller |
1.5 |
| 20:33 |
hmmmm |
that one's fine |
| 20:37 |
proller |
ok, commiting |
| 20:37 |
proller |
other much harder |
| 21:10 |
|
jojoa1997 joined #minetest-dev |
| 21:19 |
|
proller joined #minetest-dev |
| 21:52 |
|
salamanderrake joined #minetest-dev |
| 22:12 |
|
smoke_fumus joined #minetest-dev |
| 22:51 |
|
jojoa1997 joined #minetest-dev |
| 23:25 |
|
hmmmmm joined #minetest-dev |
