| Time |
Nick |
Message |
| 00:40 |
|
Cornelia joined #minetest-dev |
| 01:13 |
ANAND |
pmp-p: See where registered_on_sending_chat_message is invoked, and continue to backtrace until you get to the part of the code you want. ;) |
| 01:14 |
|
Cornelia joined #minetest-dev |
| 01:23 |
|
clownfishhuman joined #minetest-dev |
| 01:25 |
|
clownfishhuman left #minetest-dev |
| 01:30 |
|
Cornelia joined #minetest-dev |
| 02:06 |
|
pauloue joined #minetest-dev |
| 02:12 |
pauloue |
Krock: if I understand your question correctly: if the original itemstack has a count of 1, it is completely consumed during crafting, so the replacement itemstack can take its place. Otherwise, the replacement item is put in output.replacements so that it can be placed somewhere else. |
| 02:18 |
pauloue |
oops, hopefully he checks the logs |
| 02:25 |
|
Cornelia joined #minetest-dev |
| 02:58 |
|
Lone-Star joined #minetest-dev |
| 03:47 |
|
ssieb joined #minetest-dev |
| 06:08 |
ANAND |
~tell Krock <pauloue> Krock: if I understand your question correctly: if the original itemstack has a count of 1, it is completely consumed during crafting, so the replacement itemstack can take its place. Otherwise, the replacement item is put in output.replacements so that it can be placed somewhere else. |
| 06:08 |
ShadowBot |
ANAND: O.K. |
| 06:28 |
ANAND |
#8817 |
| 06:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/8817 -- All Settings: Prevent unnecessary writes by checking for modification by ClobberXD |
| 07:07 |
|
SteveT joined #minetest-dev |
| 07:09 |
|
kaeptmblaubaer joined #minetest-dev |
| 07:30 |
rdococ |
If an issue is closed but I have come up with a simple way to implement something that is similar to that issue, should I put it in a new issue? |
| 07:30 |
|
kaeptmblaubaer joined #minetest-dev |
| 07:30 |
rdococ |
Sorry, this probably isn't the right place to ask. It's hard to tell. |
| 07:33 |
|
kaeptmblaubaer joined #minetest-dev |
| 07:39 |
|
kaeptmblaubaer joined #minetest-dev |
| 08:55 |
|
Wuzzy joined #minetest-dev |
| 08:59 |
|
Player-2 joined #minetest-dev |
| 09:24 |
p_gimeno |
it's not a bad place to ask, but perhaps not the best time, and I guess it depends on what it's about but in general, if it's not the same thing, opening a new issue is probably best (I'm not a core dev though so don't take this as an official statement) |
| 10:58 |
|
proller joined #minetest-dev |
| 11:27 |
|
Fixer joined #minetest-dev |
| 11:33 |
|
calcul0n joined #minetest-dev |
| 12:12 |
|
calcul0n joined #minetest-dev |
| 13:38 |
|
Megaf joined #minetest-dev |
| 13:42 |
|
Cornelia joined #minetest-dev |
| 15:33 |
ANAND |
Would someone tell me what #8819 actually fixes? |
| 15:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/8819 -- Restore intended functionality to minimap markers by theviper121 |
| 15:36 |
sfan5 |
seeing other players on them minimap, I guess |
| 15:37 |
ANAND |
I see. I haven't used the minimap ever before, so I wanted to know what to look for. Thanks |
| 15:37 |
ANAND |
I never even knew players are marked on the minimap lol |
| 15:37 |
sfan5 |
i'm just guessting I haven't actually tested it |
| 15:38 |
ANAND |
Ah ok |
| 15:55 |
pmp-p |
if i do: lua_getglobal(L, "core"); do i get the client or server lua context ( when in non dedi mode ) ? |
| 15:57 |
pmp-p |
i want to add a shortcut from Client::step() from stdin to lua server side |
| 15:57 |
sfan5 |
you get the context of whatever scripting environment 'L' refers to |
| 15:58 |
pmp-p |
well i don't see where L is coming from ( when i s_client.pp ) sorry to bother with c++ |
| 15:59 |
pmp-p |
i tried to base my shortcut on ScriptApiClient::on_receiving_message() |
| 16:01 |
pmp-p |
i actually can send stdin/pipe data in json and lua server side is able to decode that but it's convoluted |
| 16:01 |
|
pauloue joined #minetest-dev |
| 16:13 |
ANAND |
ScriptApiClient is client-side |
| 16:14 |
pmp-p |
ANAND: yeah i want to interect with client side |
| 16:15 |
pmp-p |
in case of android passing certains app lifecycle events directly to lua |
| 16:15 |
ANAND |
I was actually answering > if i do: lua_getglobal(L, "core"); do i get the client or server lua context ( when in non dedi mode ) ? |
| 16:15 |
pmp-p |
ho fine |
| 16:15 |
ANAND |
But you prolly already figured it out though :) |
| 16:16 |
pmp-p |
but i get a strange warning about "WARNING[Main]: Client side scripting is disabled by client." |
| 16:16 |
pmp-p |
i would like to activate client side, and provide events via the pipe |
| 16:17 |
pmp-p |
but can't find doc about client side scripting |
| 16:17 |
pmp-p |
( i've read that https://dev.minetest.net/Client_scripting_plans ) |
| 16:19 |
rubenwardy |
doc/client_lua_api.txt |
| 16:20 |
pmp-p |
thx that's what i need :) |
| 16:38 |
pmp-p |
parameter --go leave the button [exit to menu] in interface though it leads to exit to os instead |
| 16:48 |
pmp-p |
rubenwardy: i don't find the way to active the client side scripting described, does it work on 5.0.1 ? |
| 16:49 |
pmp-p |
i've created folder but still have the warning and nothing more in game config mods list |
| 16:52 |
|
Krock joined #minetest-dev |
| 17:11 |
Krock |
will merge #8819 in 5 minutes |
| 17:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/8819 -- Restore intended functionality to minimap markers by theviper121 |
| 17:12 |
ANAND |
Re: #8812 I don't see any difference from master. I'll re-test after uncommenting the wireframe-blinky |
| 17:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/8812 -- [NO SQUASH] Occlusion: Code cleanup and better checks using "light_propagates" by SmallJoker |
| 17:14 |
|
proller joined #minetest-dev |
| 17:15 |
pmp-p |
hmm i don't have warning when conf "enable_client_modding" is true but i'm still not sure it's loading |
| 17:17 |
Krock |
merging |
| 17:17 |
Krock |
ANAND: I highly recommend doing that because it's unlikely to notice much |
| 17:18 |
Krock |
also test on servers where copmlex structures occur |
| 17:18 |
Krock |
you're probably testing this in a plain world |
| 17:18 |
Krock |
merged |
| 17:18 |
Krock |
game#2448 in 5 minutes |
| 17:18 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2448 -- Verify object is player before checking privs by coil0 |
| 17:19 |
Krock |
no, nvm. |
| 17:19 |
ANAND |
Good idea, I'll test this out on a couple of public servers |
| 17:19 |
Krock |
weird is that can_interact_with_node could accept player names for check_player_privs |
| 17:19 |
ANAND |
I'd also get some good references to compare this PR with master |
| 17:19 |
Krock |
but then it will fail due to player:get_player_name() |
| 17:21 |
ANAND |
Rebased #8513 |
| 17:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/8513 -- [NO SQUASH; KETCHUP OK] Disable autoforward if player is dead by ClobberXD |
| 17:21 |
Krock |
ANAND: close mapblocks will still be rendered due to the optimization where the occlusion check stops a mapblock's diagonal |
| 17:21 |
ANAND |
I'll keep that in mind, thanks |
| 17:21 |
Krock |
will merge game#2448. passing string as "player" does currently not work either |
| 17:21 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2448 -- Verify object is player before checking privs by coil0 |
| 17:23 |
Krock |
ANAND: how could HP go below 0? (m_hp <= 0) |
| 17:23 |
Krock |
merging game PR |
| 17:26 |
Krock |
!tell paramat Sorry, forgot to remove the PR number in the commit title again. Too bad there's no format option in GitHub to change the permanently |
| 17:26 |
ShadowBot |
Krock: O.K. |
| 17:27 |
pmp-p |
client side scripting is not very well documented and does not seem to be working for me atm, i'll offer android support when and if it works |
| 17:27 |
ANAND |
Krock, maybe it could in the future? |
| 17:28 |
Krock |
Also the hp property of LocalPlayer could now be replaced by a reference to ContentCAO, since the HP bars are now entirely based on server-sent HUDs |
| 17:28 |
Krock |
negative HP is like negative side lengths of node boxes. obscure |
| 17:29 |
ANAND |
True, not much scope or usecases |
| 17:29 |
ANAND |
Will remove |
| 17:29 |
Krock |
ANAND: while you're at it, please also remove the line-up in https://github.com/minetest/minetest/pull/8513/files#diff-9cd6a333639e48a63a4a92bbf1c7ed10R1252 |
| 17:30 |
Krock |
it's tab-dependant and will not look right depending on the tab sizes |
| 17:31 |
Krock |
ANAND: are you sure the PR works? `hp` seems to be unused |
| 17:32 |
ANAND |
It did, after the previous rebase |
| 17:32 |
Krock |
hmm https://github.com/minetest/minetest/blob/master/src/client/clientenvironment.cpp#L434-L439 |
| 17:32 |
ANAND |
I'll test again after making the changes you requested |
| 17:32 |
Krock |
wonder where's it synced with the ContentCAO HP |
| 17:32 |
ANAND |
GenericCAO doesn't have any getters for HP! :O |
| 17:33 |
ANAND |
ContentCAO::m_hp is updated via AOMs |
| 17:33 |
Krock |
lines up with what I've seen in https://github.com/minetest/minetest/blob/master/src/network/clientpackethandler.cpp#L522 |
| 17:33 |
Krock |
players have different packets |
| 17:38 |
sfan5 |
Krock: minetest still doesn't feel like hiding this cave https://0x0.st/zWci.png |
| 17:38 |
pmp-p |
there's also a bug in mouse grabbing when switch app under x11 |
| 17:39 |
Krock |
sfan5: the upper coordinate is closer to the camera than the mapblock diagonal |
| 17:39 |
Krock |
I'm more worried about the cave in the rear |
| 17:40 |
* Krock |
does more testing |
| 17:40 |
Krock |
it would be more precise (but more time-consuming) to check whether the position is inside the mapblock to abort the occlusion culling loop |
| 17:42 |
Krock |
instead of enabling the blink mode it's also possible to dive into a ground node and up again to see what changes |
| 17:44 |
ANAND |
RIP #8409 - merge conflicts in 10 files :( |
| 17:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/8409 -- Rewrite camera modes; implement per-player camera modes by ClobberXD |
| 17:48 |
Krock |
ANAND: to test on servers without debug priv: either 1) "hack" the client or 2) enable_local_saving = true |
| 17:48 |
ANAND |
That's exactly what I was trying to figure out, lol |
| 17:49 |
ANAND |
Map saving seems to be the better option ;) |
| 17:50 |
sfan5 |
Krock: what do you mean by that? why does that matter? |
| 17:51 |
Krock |
sfan5: the occlusion check stop a mapblock's diagonal length before the destination point, this is to prevent that the mapblock causes its own occlusion |
| 17:52 |
Krock |
since there are yet no inside-of-target-mapblock coordinate checks |
| 17:52 |
sfan5 |
oh, that's what you mean |
| 17:53 |
Krock |
question is whether what would perform better: bounds checks for each node lookup or fast approximation |
| 17:53 |
sfan5 |
there are 21 nodes between the surface and that cave though, that should be more than enough |
| 17:55 |
Krock |
displaying the mapblock borders would be helpful here :/ |
| 17:55 |
sfan5 |
it doesn't occlude even with step=1.0, stepfac=1.0 which is seriously broken if you ask me |
| 17:56 |
Krock |
what's the distance from the cave to you until it disappears? |
| 17:56 |
sfan5 |
it doesn't disappear even at y=270 so I don't think that matters |
| 17:57 |
Krock |
off |
| 17:57 |
Krock |
*off |
| 17:57 |
Krock |
weird |
| 17:57 |
sfan5 |
it makes sense though |
| 17:57 |
Krock |
in what way? it's not supposed to show up |
| 17:58 |
sfan5 |
end_offset is 27.712 * BS, so nothing will occlude if the the "ground" is just 21 nodes |
| 17:58 |
Krock |
"there are 21 nodes between the surface" oh right, yes. |
| 17:59 |
sfan5 |
so what I'm seeing is working as intended, but the occlusion check is still stupid |
| 17:59 |
Krock |
could be smarted with the said bounds checks |
| 17:59 |
Krock |
actually |
| 17:59 |
Krock |
I only need to check the bounds as soon the predicted end distance has been reached |
| 17:59 |
sfan5 |
since the check as for the center position shouldn't end_offset be half actually? |
| 18:00 |
sfan5 |
s/ as / are / |
| 18:01 |
Krock |
sorry? |
| 18:01 |
sfan5 |
oh the code does that already |
| 18:01 |
Krock |
yes, center is checked first |
| 18:01 |
sfan5 |
line 1100 |
| 18:01 |
sfan5 |
it uses end_offset / 2.0f for the center check |
| 18:02 |
pmp-p |
hmmm now client_side suddenly works and i have now idea why, is it really stable ? |
| 18:02 |
Krock |
client_side what? |
| 18:02 |
pmp-p |
client_side lua api |
| 18:03 |
pmp-p |
i think something's missing from docs |
| 18:03 |
Krock |
client_lua_api.txt also states that the API may break any time |
| 18:04 |
pmp-p |
i think it's maybe missing something about the mods.conf in client side folder i don't remember what else i poked into |
| 18:10 |
pmp-p |
unless i'm wrong nothing mentions enable_client_modding = true and mods.conf settings to tune |
| 18:11 |
Krock |
no, minetest.conf |
| 18:29 |
pmp-p |
Krock: both minetest.conf for the former parameter and mods.conf for eg a mod called mod_cli "load_mod_cli = true" |
| 18:30 |
pmp-p |
( the mods.conf in ~/.minetest/clientmods/ ) |
| 18:31 |
Krock |
sfan5: do you think "std::pair<v3s16, v3s16>" is okay for a boundary minp/maxp pair? |
| 18:31 |
Krock |
it's a pair, but usually not used in that way |
| 18:32 |
sfan5 |
yes |
| 18:32 |
ANAND |
pmp-p: If the name of the mod is mod_cli, then the key would be called load_mod_mod_cli, bc the syntax is load_mod_<modname>, AFAIK |
| 18:33 |
pmp-p |
yeah you're right typo |
| 18:33 |
ANAND |
Krock: Would a struct be more performant? |
| 18:33 |
Krock |
ANAND: a pair is also some kind of struct |
| 18:33 |
ANAND |
It has a wee bit of extra overhead though |
| 18:33 |
ANAND |
make_pair |
| 18:33 |
Krock |
stl_pair.h: struct pair |
| 18:35 |
ANAND |
Hm, they seem to be the same |
| 18:35 |
ANAND |
nvm |
| 18:42 |
Krock |
accurate mapblock bounds checks can hide two or three more mapblocks |
| 18:42 |
Krock |
sure, why not. updating the PR. |
| 18:47 |
Krock |
ANAND: doing settings optimizations like in #8817 is task of settings.cpp |
| 18:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/8817 -- All Settings: Prevent unnecessary writes by checking for modification by ClobberXD |
| 18:50 |
ANAND |
Argh, thought so... >.> |
| 18:51 |
Krock |
the idea is good, but solving the problem at its roots is the perfect solution |
| 18:51 |
ANAND |
Totally agreed |
| 18:54 |
|
fwhcat joined #minetest-dev |
| 18:54 |
|
DS-minetest joined #minetest-dev |
| 18:58 |
Krock |
Old: https://i.imgur.com/EbQuEGH.png Accurate positions: https://i.imgur.com/rq9kEsF.png |
| 18:58 |
sfan5 |
Krock: i'd renamed pos_block to block_bounds |
| 18:58 |
Krock |
ok sir |
| 18:59 |
Krock |
anything else before I push? |
| 19:00 |
sfan5 |
"Anything smaller than the mapblock diagonal results in self-occlusion" -> could result in |
| 19:00 |
sfan5 |
and the end_offset comment is not needed anymore |
| 19:00 |
sfan5 |
in fact you could just add v3s16(0,0,0) to dir8[] |
| 19:00 |
Krock |
where's end_offset? |
| 19:01 |
sfan5 |
> // For the central point of the mapblock 'end_offset' can be halved |
| 19:02 |
Krock |
oh, that happens when you read the bottom comment first, code and wonder what's happening now |
| 19:03 |
Krock |
thank you. Updated the PR accordingly |
| 19:04 |
sfan5 |
"// Check occlusion for all 8 edges of the mapblock" -> center and all 8 edges |
| 19:07 |
sfan5 |
pos_block also needs renaming in the function definition |
| 19:08 |
Krock |
hopes are lost for today I guess |
| 19:13 |
sfan5 |
now you just need to update the PR title/description |
| 19:15 |
Krock |
trivial |
| 19:18 |
sfan5 |
it's still not occluding the cave from before :/ |
| 19:20 |
Krock |
strange indeed |
| 19:26 |
Krock |
Q: Is there a demand for bitmap-fonts with shadows and colors? |
| 19:26 |
Krock |
especially important for weaker devices |
| 19:28 |
Krock |
demo https://i.imgur.com/dPsy96z.png |
| 19:33 |
sfan5 |
Krock: BS is multiplied in once too much |
| 19:33 |
|
behalebabo joined #minetest-dev |
| 19:34 |
Krock |
step and offset |
| 19:35 |
Krock |
both need BS since direction is normalized |
| 19:35 |
sfan5 |
well not exactly |
| 19:36 |
sfan5 |
hmm |
| 19:36 |
Krock |
s16 may not be multiplied by BS, and all float values must be multiplied by BS (or normalized) |
| 19:37 |
Krock |
stepfac is the exception here for being a multiplicator |
| 19:42 |
sfan5 |
Krock: http://paste.debian.net/plainh/3a47c3c6 debug output |
| 19:42 |
sfan5 |
there are about 30 nodes between the camera and the target mapblock, yet it checks 3 air nodes and exits |
| 19:45 |
Krock |
will check that tomorrow. thanks for debugging so far |
| 19:46 |
sfan5 |
>block_bounds=(64,0,-144) to (79,15,-129) |
| 19:46 |
sfan5 |
I don't quite think (69,34,-143) is inside that ? |
| 19:46 |
Krock |
so it exits inside the block bounds check?! |
| 19:47 |
sfan5 |
yes |
| 19:47 |
Krock |
wtf irrlicht |
| 19:48 |
Krock |
>= apparently only compares X, Y and Z, whereas one match is enough to return true |
| 19:49 |
sfan5 |
*claps* |
| 19:49 |
Krock |
claps for me or irrlicht? |
| 19:50 |
sfan5 |
latter |
| 19:50 |
sfan5 |
now that i think about it, block_bounds should be an aabbox3d<s16> anyway |
| 19:51 |
sfan5 |
or a VoxelArea (from src/voxel.h) |
| 19:52 |
Krock |
aabbox3d was the thing I was looking for, but lazy enough to just head over to std::pair heh |
| 19:52 |
Krock |
as in: didn't know the type name |
| 19:52 |
sfan5 |
there's even this |
| 19:52 |
sfan5 |
src/mapblock.h:inline core::aabbox3d<s16> getBox() |
| 19:53 |
Krock |
bool isPointInside(const vector3d<T>& p) const nice |
| 19:53 |
sfan5 |
but getBox() uses m_pos_relative ?! |
| 19:55 |
Krock |
should be named "Absolute" but it makes sense to cache that |
| 19:55 |
sfan5 |
ok I don't think getBox is the right thing |
| 19:55 |
Krock |
it is |
| 19:55 |
sfan5 |
but the naming is extremely weird, it should be getRelativeBox() |
| 19:55 |
Krock |
https://github.com/minetest/minetest/blob/master/src/mapblock.cpp#L72 |
| 19:55 |
Krock |
it's an absolute position |
| 19:56 |
Krock |
the heck whoever wrote that |
| 19:56 |
sfan5 |
>have an absolute position >name it pos_relative |
| 19:56 |
sfan5 |
such is life in the minetest engine |
| 19:56 |
Krock |
maybe I'm mistaken and this MapBlock is used in some weird way (like map sectors) but I really doubt that |
| 19:57 |
sfan5 |
no this does look correct |
| 20:02 |
sfan5 |
yeah fixing that comparison makes the whole thing work as expected |
| 20:14 |
DS-minetest |
is there a reason why the checked corner pos_targets are not all inside the mapblock? (I hope I understand the algorithm correctly now) |
| 20:15 |
DS-minetest |
in the +x, +y and +z directions, they are inside the block, but not in the other directions |
| 20:33 |
|
EvergreenTree joined #minetest-dev |
| 20:35 |
|
EvergreenTree joined #minetest-dev |
| 20:35 |
|
EvergreenTree left #minetest-dev |
| 20:37 |
|
proller joined #minetest-dev |
| 20:45 |
|
troller joined #minetest-dev |
| 20:56 |
DS-minetest |
(forget what I wrote) |
| 21:28 |
|
Taoki joined #minetest-dev |
| 21:56 |
|
behalebabo joined #minetest-dev |
| 22:32 |
|
Lone_Wolf joined #minetest-dev |
