| Time |
Nick |
Message |
| 00:07 |
KaadmY |
What's the tangent vertex buffer for? |
| 00:08 |
|
octacian joined #minetest-dev |
| 00:14 |
rubenwardy |
KaadmY, it was added by RBA to do things like water shaders etc |
| 00:15 |
KaadmY |
rubenwardy: I'm studying it, it looks like it's for normalmapping |
| 00:15 |
KaadmY |
Or at least that's the only use for it |
| 00:16 |
KaadmY |
Trying to see if I can salvage the binormal and tangent for an artificial light factor |
| 00:16 |
rubenwardy |
ah cool |
| 00:17 |
rubenwardy |
I know that RBA did something like adding tangents which would be needed by water shaders later on |
| 00:17 |
KaadmY |
Having water reflect the sky would be really neat :D |
| 00:17 |
KaadmY |
(You'd need to render a cubemap though) |
| 00:18 |
rubenwardy |
there's also raytraced reflections |
| 00:18 |
KaadmY |
Those are a lot more expensive |
| 00:19 |
rubenwardy |
yeah, I guessed |
| 00:19 |
rubenwardy |
they sound it |
| 00:19 |
KaadmY |
And you can't do raytracing in a shader without knowing the entire geometry |
| 00:19 |
KaadmY |
The common way to do water reflection is to just render a cubemap and project it no |
| 00:19 |
KaadmY |
on* |
| 00:19 |
KaadmY |
Having refraction alone would be really nice |
| 00:35 |
lisac |
hey KaadmY your PR doesn't add actual shadows does it? |
| 00:36 |
|
proller__ joined #minetest-dev |
| 00:36 |
KaadmY |
lisac: no it doesn't |
| 00:37 |
KaadmY |
(Although it would be nice if realtime shadows magically just *worked* without anyone intervening :P) |
| 00:38 |
lisac |
:( |
| 00:38 |
lisac |
would it be possible to just flip the model and draw it on the surface under it, but dark? |
| 00:39 |
KaadmY |
That's hacky, and that's called reflections :P |
| 00:39 |
KaadmY |
1. It's hacky. |
| 00:39 |
KaadmY |
2. It's hacky. |
| 00:39 |
KaadmY |
3. It's still hacky no matter how many times you ask |
| 00:39 |
KaadmY |
... |
| 00:39 |
KaadmY |
4. Seriously.. Answer's not gonna change :P |
| 00:40 |
lisac |
:P |
| 00:40 |
lisac |
just wondering |
| 00:40 |
lisac |
i've got no idea about shaders |
| 00:40 |
KaadmY |
Also that would be completely wrong shadows |
| 00:40 |
lisac |
beyond loading them from copy-pasted GL code |
| 00:40 |
lisac |
how do others do it? |
| 00:40 |
KaadmY |
With shadowmaps |
| 00:41 |
KaadmY |
Which I don't want to do yet since Minetest has a rendering wrapper, on top of Irrlicht's |
| 00:41 |
KaadmY |
And both are hard to add shadowmaps |
| 00:43 |
* lisac |
reads up on shadow mapping |
| 00:43 |
lisac |
"This concept was introduced by Lance Williams in 1978" :O that is old |
| 00:43 |
lisac |
did they even have GPUs then? |
| 00:43 |
KaadmY |
Not really :D |
| 00:43 |
lisac |
lol what was the use of that creatively named book then? |
| 00:43 |
|
octacian_ joined #minetest-dev |
| 00:44 |
KaadmY |
:shrug: |
| 00:44 |
lisac |
:P |
| 00:45 |
|
paramat joined #minetest-dev |
| 00:48 |
lisac |
alright this whole wiki page sounds like gibberish |
| 00:48 |
lisac |
it's 2:48 |
| 00:48 |
lisac |
I should go sleep |
| 00:48 |
lisac |
cya all tomorrow |
| 01:08 |
KaadmY |
Gaaaaah |
| 01:09 |
KaadmY |
It seems that Irrlicht automatically generates tangent and binormal vectors, so I can't mess with them manually... |
| 01:15 |
|
jcalve joined #minetest-dev |
| 01:17 |
|
jin_xi joined #minetest-dev |
| 01:30 |
|
Miner_48er joined #minetest-dev |
| 01:32 |
|
Miner_48er joined #minetest-dev |
| 01:39 |
paramat |
will merge #6167 and #6173 in a moment |
| 01:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/6167 -- Mgv7: Add 'mount_zero_level' parameter by paramat |
| 01:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/6173 -- Create_schematic documentation: Update for per-node force-place by paramat |
| 01:44 |
paramat |
merging |
| 01:47 |
paramat |
done |
| 02:19 |
|
dzho_ joined #minetest-dev |
| 02:29 |
|
Tmanyo joined #minetest-dev |
| 03:11 |
|
octacian joined #minetest-dev |
| 04:38 |
|
deep-book-gk_ joined #minetest-dev |
| 04:45 |
|
deep-book-gk_ left #minetest-dev |
| 05:13 |
|
nerzhul joined #minetest-dev |
| 05:23 |
nerzhul |
hello, merging #6169 in ~10 mins |
| 05:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/6169 -- VoxelManip cleanups (const ref, const move) + function removal by nerzhul |
| 05:28 |
|
Hunterz joined #minetest-dev |
| 05:33 |
KaadmY |
LOL |
| 05:33 |
KaadmY |
If you search for "FindVorbis.cmake", the first result is the one in the Minetest repository: https://encrypted.google.com/search?&q=FindVorbis.cmake |
| 05:39 |
|
ssieb joined #minetest-dev |
| 05:46 |
Hijiri |
KaadmY: are you sure it's not because of your browsing / search history |
| 05:46 |
Hijiri |
it doesn't show up when I use startpage, which uses anonymized google results |
| 05:47 |
KaadmY |
Hijiri: lemme check with incognito, I don't think so though |
| 05:47 |
KaadmY |
It showed up as #2 in DuckDuckGo also |
| 05:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/2 -- Burned wood |
| 05:47 |
KaadmY |
First result in an incognito window also |
| 05:47 |
KaadmY |
Second result in DDG |
| 05:47 |
Hijiri |
minetest doesn't show up for me in DDG |
| 05:48 |
Hijiri |
oh it does |
| 05:48 |
Hijiri |
second result |
| 05:48 |
Hijiri |
I guess startpage just has different results for some reason |
| 05:48 |
KaadmY |
(Startpage kinda sucks for search TBH) |
| 05:54 |
KaadmY |
Would it be possible to see mods having a way to change the velocity of players? |
| 05:54 |
KaadmY |
player:set_velocity() (or something like that) doesn't work on player objects |
| 06:08 |
Hijiri |
it's been discussed a few times around different places |
| 06:09 |
Hijiri |
main substantial argument against it imo is that it would be weird for knockback because the server has outdated current player velocity info, so it would be better to have add_velocity |
| 06:09 |
Hijiri |
but you could make a hacky set_velocity using add_velocity anyway so I think you might as well have both |
| 06:09 |
Hijiri |
but if the engine was going to have only one I think it should be add_velocity, which is more useful |
| 06:10 |
nerzhul |
we have an opened pr by Dumbeldor for a real knockback feature but it's not finished yet |
| 06:10 |
nerzhul |
#5679 |
| 06:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/5679 -- Knockback by Dumbeldor |
| 06:10 |
Hijiri |
I thought it implemented knockback in some convoluted way |
| 06:10 |
Hijiri |
instead of just applying an impulse |
| 06:10 |
nerzhul |
lol it's exactly that |
| 06:10 |
Hijiri |
oh |
| 06:10 |
nerzhul |
vector + duration |
| 06:11 |
Hijiri |
uh |
| 06:11 |
Hijiri |
that's not just applying an impulse |
| 06:11 |
nerzhul |
if you apply velocity without a maximum duration you will continue infinitely |
| 06:11 |
Hijiri |
player should just get an instantaneous velocity change and let gravity do the rest |
| 06:11 |
nerzhul |
it doesn't work like that |
| 06:12 |
Hijiri |
I don't see why it needs to be complicated with timed pushing and things |
| 06:12 |
Hijiri |
nerzhul: why not |
| 06:12 |
nerzhul |
because velocity should be reset |
| 06:12 |
nerzhul |
it's an attribute |
| 06:12 |
Hijiri |
what do you mean by reset velocity |
| 06:12 |
Hijiri |
set it to 0? |
| 06:12 |
nerzhul |
yes |
| 06:12 |
Hijiri |
when? |
| 06:13 |
Hijiri |
I don't see why it should be reset at any point of knockback |
| 06:13 |
nerzhul |
A ---> B + gravity means: A vector distance B, and just after a short amount of time, reset velocity to make player use gravity and stop moving due to velocity |
| 06:13 |
nerzhul |
because velocity doesn't decrease over time |
| 06:13 |
Hijiri |
why is that better than just modifying the velocity once and have gravity apply the whole time |
| 06:13 |
KaadmY |
Hijiri: for example right now if you jump while getting in a bed, you'll fly up infinitely |
| 06:14 |
KaadmY |
That is, until you rejoin since velocity is reset |
| 06:14 |
nerzhul |
once mean you don't understand what is a runtime loop |
| 06:14 |
nerzhul |
KaadmY, good example |
| 06:14 |
KaadmY |
In Pixture, I just save state on where the player was, then every 2 seconds in globalstep, I put them back in the bed |
| 06:14 |
Hijiri |
nerzhul: isn't the loop already applying gravity? |
| 06:14 |
KaadmY |
It's really hacky but it's all I can do |
| 06:15 |
nerzhul |
Hijiri, no if velocity is stronger than gravity |
| 06:15 |
Hijiri |
gravity is an acceleration though |
| 06:15 |
Hijiri |
how can there be a "stronger" |
| 06:15 |
Hijiri |
the player will have to fall eventually |
| 06:15 |
nerzhul |
you don't understand the event loop |
| 06:15 |
nerzhul |
velocity is acceleration on a model with direction |
| 06:16 |
Hijiri |
so it's not really velocity? |
| 06:16 |
Hijiri |
maybe the player movement model should be changed then |
| 06:16 |
KaadmY |
Ummm... |
| 06:16 |
Hijiri |
by model I don't mean that model |
| 06:17 |
KaadmY |
Every frame: |
| 06:17 |
KaadmY |
velocity = velocity + (acceleration) * delta |
| 06:17 |
KaadmY |
position = position + (velocity * delta) |
| 06:18 |
Hijiri |
that doesn't sound like what nerzhul said |
| 06:18 |
Hijiri |
it looks like something that matches what I said |
| 06:18 |
nerzhul |
it is but badly explained |
| 06:18 |
Hijiri |
I think "velocity is acceleration with direction" is just wrong, not badly explained |
| 06:18 |
nerzhul |
if you never reset velocity you will move infitinitely |
| 06:19 |
Hijiri |
but the movement step already dampens player velocity doesn't it? |
| 06:19 |
nerzhul |
no |
| 06:19 |
Hijiri |
then how does it slow down the player gradually when they stop moving forward |
| 06:19 |
nerzhul |
it is not gradual |
| 06:20 |
Hijiri |
yes it is |
| 06:20 |
nerzhul |
key is pressed => velocity, key is unpressed => reset |
| 06:20 |
nerzhul |
acceleration maybe changed but not velocity |
| 06:20 |
KaadmY |
Hijiri: velocity is dampened |
| 06:20 |
Hijiri |
nerzhul: I thought you said that velocity needed to be reset? isn't that changing? |
| 06:21 |
nerzhul |
in a knockback feature we have 2 things to manage: 1: velocity + kill velocity after a short amount of time to prevent infinite movement, second we manage a stun timer to drop movement key events during the knockback |
| 06:21 |
Hijiri |
velocity isn't reset when a key is unpressed, the velocity just is pulled toward zero (not instantaneously) when no keys are pressed |
| 06:22 |
Hijiri |
there's no need to kill velocity because velocity already gets dampened |
| 06:24 |
Hijiri |
KaadmY: do you know what file player movement is in |
| 06:24 |
Hijiri |
nevermind, it's in src/localplayer.cpp |
| 06:24 |
KaadmY |
https://github.com/minetest/minetest/blob/fafa51202c3bd6e46a44eacbc7f42ef697835945/src/localplayer.cpp |
| 06:24 |
KaadmY |
Hijiri: ^ you already found it though |
| 06:28 |
Hijiri |
nerzhul: this is the code used in player movement to change the player's velocity according to controls: https://github.com/minetest/minetest/blob/fafa51202c3bd6e46a44eacbc7f42ef697835945/src/localplayer.cpp#L696 |
| 06:29 |
Hijiri |
It doesn't set velocity immediately. It nudges the player's current speed toward the target speed (which is an input to the function) |
| 06:29 |
Hijiri |
So knockback can just set the current speed directly instead of doing what player controls do |
| 06:30 |
Hijiri |
And then accelerateHorizontal and accelerateVertical will ensure that the player speed goes back to whatever they control it towards |
| 06:30 |
nerzhul |
yeah it's used like this |
| 06:30 |
nerzhul |
https://github.com/minetest/minetest/pull/5679/files#diff-efb51cde4bb3c805a95dc31b2b1781d0R796 |
| 06:30 |
nerzhul |
the problem is the return back it seems |
| 06:33 |
Hijiri |
the problem is that it is calling this every frame |
| 06:33 |
Hijiri |
it wouldn't have this problem if it just set the velocity once |
| 06:33 |
KaadmY |
Why not just allow servers to AT LEAST set velocity, and allow damping still |
| 06:33 |
nerzhul |
knockback should not be like that because prediction is important |
| 06:33 |
nerzhul |
it's why the knockback PR is important |
| 06:34 |
nerzhul |
we predict knockbacked movement |
| 06:34 |
Hijiri |
prediction of what |
| 06:34 |
KaadmY |
Not just knockback, but allow setting the player's velocity in general |
| 06:34 |
nerzhul |
else you have a huge movement lag |
| 06:34 |
Hijiri |
I think movement lag is acceptable |
| 06:34 |
nerzhul |
no |
| 06:34 |
KaadmY |
Some examples would be: beds, TNT cannons |
| 06:34 |
nerzhul |
it's not acceptable |
| 06:34 |
nerzhul |
i tested it it's not acceptable |
| 06:34 |
Hijiri |
you can't make knockback prediction better |
| 06:34 |
Hijiri |
the badness is when it starts |
| 06:34 |
nerzhul |
lol just test the PR |
| 06:35 |
Hijiri |
are you saying the PR is not acceptable or something else |
| 06:35 |
nerzhul |
no the badness is all the movement |
| 06:35 |
Hijiri |
because I don't agree with how the PR dose it |
| 06:35 |
Hijiri |
does* |
| 06:35 |
nerzhul |
you don't agree because you want simple shit which lags :p |
| 06:35 |
Hijiri |
I want something that is knockback |
| 06:35 |
KaadmY |
I like how all idTech games have server-side movement and client prediction, and they feel butter smooth |
| 06:35 |
nerzhul |
here we have knockback + prediction of movement, it's smooth for all |
| 06:35 |
nerzhul |
the knockback PR block movement sending to server |
| 06:35 |
Hijiri |
it's not predicting knockback because it's not knockback |
| 06:35 |
nerzhul |
all clients seing the knockback run the "animation" |
| 06:36 |
KaadmY |
Plus having server side movement means you can't cheat |
| 06:36 |
Hijiri |
it's predicting some janky other thingt |
| 06:36 |
nerzhul |
did you looked at the video ? |
| 06:36 |
Hijiri |
I just read sfan5's description, I'll watch the video |
| 06:36 |
Hijiri |
I think it looks bad, just not as bad as I imagined |
| 06:37 |
nerzhul |
the PR is enhanceable i agree, but the general code is here |
| 06:37 |
Hijiri |
But I don't see why that is more well predicted than just changing velocity |
| 06:37 |
nerzhul |
now it's just formula correction |
| 06:37 |
Hijiri |
oh, does this simulate movement on remote players? |
| 06:37 |
nerzhul |
exact |
| 06:37 |
Hijiri |
but there's no prediction for any other movement |
| 06:37 |
Hijiri |
of players |
| 06:37 |
nerzhul |
for input movements it's normal |
| 06:37 |
nerzhul |
here it's a controlled movement |
| 06:38 |
nerzhul |
it's a sort of contract between clients |
| 06:38 |
nerzhul |
also it applies to every CAO not only players |
| 06:38 |
nerzhul |
you knockback a SAO (player or not) a knockback order is sent to all clients seing this SAO |
| 06:38 |
nerzhul |
if it's you, input are blocked during knockback, movement packet sending too |
| 06:39 |
nerzhul |
and everybody move its CAO |
| 06:39 |
nerzhul |
it's not just sending a velocity without nothing, you should block inputs, else the movement packets make it crazy |
| 06:39 |
nerzhul |
and this permits to have no lag, because everybody receive the order at the same moment |
| 06:40 |
Hijiri |
It won't really scale up to bigger knockback pushes though |
| 06:40 |
Hijiri |
it will look worse the bigger the push |
| 06:40 |
nerzhul |
then maybe the formula or implementation of the movement client side is not perfect, but the server part and movement block is correct |
| 06:40 |
nerzhul |
why ? |
| 06:40 |
nerzhul |
it just work well |
| 06:40 |
nerzhul |
the movement is identical for all clients |
| 06:41 |
Hijiri |
I don't mean it won't be predicted fine |
| 06:41 |
Hijiri |
I mean that it will look bad |
| 06:41 |
Hijiri |
It won't feel like knockback |
| 06:41 |
Hijiri |
let's say you want to make a player cannon, so you push with a really big force |
| 06:41 |
nerzhul |
look at the video |
| 06:41 |
Hijiri |
then the player will float up diagonally for 100 nodes then fall |
| 06:41 |
Hijiri |
I did look at the video |
| 06:41 |
Hijiri |
I didn't see any knockbacks |
| 06:42 |
Hijiri |
big* |
| 06:42 |
nerzhul |
then it's just fixing the movement on client side |
| 06:42 |
Hijiri |
sorry |
| 06:42 |
Hijiri |
I didn't see any big knockbacks |
| 06:42 |
nerzhul |
take the PR, send a bigger order and see |
| 06:42 |
Hijiri |
nerzhul: fixing how? doesn't it just send the player up diagonally? |
| 06:43 |
nerzhul |
yeah it's the case, and as you said there is gravity, but i cannot remember if it's applied during this phase |
| 06:46 |
nerzhul |
if you find a better movement implementation client side i'm fine, but you must have prediction like this PR, input blocking |
| 06:47 |
nerzhul |
this PR seems stale, maybe someone can take it and fix the remaining points and we merge |
| 08:38 |
|
jin_xi joined #minetest-dev |
| 08:42 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:15 |
|
jin_xi joined #minetest-dev |
| 09:21 |
|
nerzhul joined #minetest-dev |
| 09:22 |
|
Shara joined #minetest-dev |
| 09:23 |
|
est31 joined #minetest-dev |
| 09:25 |
|
est31 left #minetest-dev |
| 09:28 |
|
SaTa joined #minetest-dev |
| 09:46 |
|
SaTa joined #minetest-dev |
| 10:21 |
|
DI3HARD139 joined #minetest-dev |
| 10:26 |
|
nerzhul joined #minetest-dev |
| 11:06 |
|
Fixer joined #minetest-dev |
| 11:32 |
|
ThomasMonroe joined #minetest-dev |
| 11:37 |
|
CalebDavis joined #minetest-dev |
| 11:56 |
|
DS-minetest joined #minetest-dev |
| 12:11 |
|
lisac joined #minetest-dev |
| 12:16 |
|
Beton joined #minetest-dev |
| 12:23 |
|
RobbieF joined #minetest-dev |
| 12:29 |
proller__ |
nerzhul, not all freminer optimizations is just schange one container type to another ;) |
| 12:30 |
nerzhul |
i know, but it makes slight difference atm :p it's the first step heh |
| 12:30 |
nerzhul |
i have finished my client optimizations, with the last PR merged we switched from 65% 35% load to 50% 50% between minetest and irrlicht |
| 12:33 |
|
Warr1024 joined #minetest-dev |
| 12:35 |
|
shalmezad joined #minetest-dev |
| 13:00 |
|
Fixer joined #minetest-dev |
| 13:01 |
|
Karazhan joined #minetest-dev |
| 13:33 |
|
antims joined #minetest-dev |
| 13:56 |
|
DS-minetest joined #minetest-dev |
| 14:41 |
|
CalebDavis joined #minetest-dev |
| 15:06 |
|
jin_xi joined #minetest-dev |
| 15:11 |
|
behalebabo joined #minetest-dev |
| 15:39 |
|
proller__ joined #minetest-dev |
| 15:42 |
|
CalebDavis joined #minetest-dev |
| 15:45 |
|
Taoki joined #minetest-dev |
| 16:20 |
|
paramat joined #minetest-dev |
| 16:21 |
|
octacian_ joined #minetest-dev |
| 16:28 |
|
Qbiq joined #minetest-dev |
| 16:42 |
|
Krock joined #minetest-dev |
| 16:50 |
|
Beton joined #minetest-dev |
| 17:02 |
ThomasMonroe |
well i have to go for today |
| 17:06 |
paramat |
! |
| 17:07 |
|
nerzhul joined #minetest-dev |
| 17:08 |
paramat |
~tell ThomasMonroe please don't post unnecessary goodbyes in this channel, you haven't been in a conversation here today and are not ending a conversation, please keep it to the other channels |
| 17:08 |
ShadowBot |
paramat: O.K. |
| 17:13 |
paramat |
~tell ThomasMonroe i have asked before, when you did this twice in a day, next time: channel ban |
| 17:13 |
ShadowBot |
paramat: O.K. |
| 17:27 |
paramat |
game#1848 is tested, can anyone +1? |
| 17:27 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1848 -- reexport player model by DS-Minetest |
| 17:31 |
|
ssieb joined #minetest-dev |
| 17:38 |
nerzhul |
hi, merging #6171 in ~1 hour |
| 17:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/6171 -- TileLayer: use shared_ptr for FrameSpec vector by nerzhul |
| 17:40 |
Krock |
btw, the black model is a known thing. even dropped items turn black when their centre position is inside a solid node |
| 17:41 |
Krock |
will test it now |
| 17:41 |
KaadmY |
It'd be nice to have lighting interpolate over a second or so |
| 17:42 |
KaadmY |
Even if it doesn't fix the issue, it'd make lighting look more consistent |
| 17:42 |
KaadmY |
Right now players have lighting depending on their node position's lighting, which isn't smoothed |
| 17:42 |
KaadmY |
So the lighting jumps in steps |
| 17:46 |
Krock |
why not simply use ^[colorize for this? |
| 17:46 |
Krock |
oops, wrong channel |
| 18:00 |
Krock |
merging game#1848 in 5 minutes |
| 18:00 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1848 -- reexport player model by DS-Minetest |
| 18:02 |
paramat |
good |
| 18:03 |
paramat |
no the black player model is a new thing caused by the offset removal, i'll make a bugfix PR |
| 18:05 |
|
behalebabo joined #minetest-dev |
| 18:08 |
|
CalebDavis joined #minetest-dev |
| 18:11 |
Krock |
paramat, where's the consistency with #1853 ? Players might want to use the minimap - if forbid something, then the radar |
| 18:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/1853 -- Add name of node 'pointed at' to debug by Zeno- |
| 18:11 |
Krock |
game #1853 |
| 18:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/1853 -- Add name of node 'pointed at' to debug by Zeno- |
| 18:11 |
Krock |
game#1853 okay, now I've got it finally right :P |
| 18:11 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1853 -- Minimap: Disable by default in survival mode by paramat |
| 18:15 |
|
octacian__ joined #minetest-dev |
| 18:22 |
rubenwardy |
paramat: game#1849 |
| 18:22 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1849 -- Separate player code into new mod by rubenwardy |
| 18:23 |
paramat |
ok |
| 18:23 |
rubenwardy |
there was no API documentation before |
| 18:23 |
rubenwardy |
I've added a list of function |
| 18:23 |
rubenwardy |
+s |
| 18:23 |
paramat |
do we have a separate HUD flag for radar? |
| 18:23 |
rubenwardy |
I'm now going to write some more docs |
| 18:23 |
rubenwardy |
I believe so |
| 18:24 |
rubenwardy |
huh |
| 18:24 |
rubenwardy |
apparently not |
| 18:24 |
paramat |
'players might want to use the minimap' is not an argument, of course they do, but the radar function at least should be earnt |
| 18:24 |
Krock |
paramat, I thought we had but no.. |
| 18:25 |
paramat |
ah could add it |
| 18:25 |
paramat |
normal minimap allows seeing things hidden behind obstacles, but isn't quite as cheaty as radar |
| 18:27 |
rubenwardy |
I think that the minimap flag should be set at the same time and place as the other default flags, in players.lua or players/init.lua after my PR |
| 18:27 |
paramat |
ok i was uncertain of the right place |
| 18:28 |
paramat |
will wait and do that |
| 18:33 |
paramat |
ok looks like we need a radar HUD flag, anyone good at that code? |
| 18:35 |
Fixer |
nerzhul: shared_ptr is that optimisation commit? |
| 18:38 |
paramat |
anyway i'll now make the fix for dark player model |
| 18:39 |
KaadmY |
Well the server could have an option to force enable the minimap |
| 18:39 |
KaadmY |
Right now even it players earn it, most players won't know how to enable it |
| 18:42 |
|
RobbieF left #minetest-dev |
| 19:02 |
paramat |
#6175 |
| 19:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/6175 -- GenericCAO: Fix dark model below y = 0 by paramat |
| 19:06 |
paramat |
players know how to enable it, it's listed in control keys. server 'enabling' mnimap doesn't make it visible, a player still has to press F9 to see it |
| 19:18 |
|
behalebabo joined #minetest-dev |
| 19:21 |
|
Qbiq joined #minetest-dev |
| 19:26 |
nerzhul |
paramat, exact, except if he had a CSM mod to do it |
| 19:45 |
|
YuGiOhJCJ joined #minetest-dev |
| 19:48 |
|
lisac joined #minetest-dev |
| 19:48 |
|
octacian joined #minetest-dev |
| 20:04 |
|
XtremeHacker joined #minetest-dev |
| 20:11 |
|
paramat joined #minetest-dev |
| 20:24 |
|
bigfoot547 joined #minetest-dev |
| 20:29 |
paramat |
rubenwardy https://github.com/minetest/minetest_game/pull/1849#issuecomment-318172895 |
| 20:49 |
nerzhul |
guyz i found a very very nice optimization to reduce generated blocks loading after decompression |
| 20:49 |
nerzhul |
on my test server without optimization 15% CPU is spent in one function which correct block not ids |
| 20:50 |
nerzhul |
after optimization only 1% CPU time is spent here |
| 20:50 |
nerzhul |
it's because i'm happy :p |
| 20:50 |
nerzhul |
yeah |
| 20:51 |
nerzhul |
i need to test on a release build to see if there is a noticeable difference, but compiler cannot save us here :p |
| 20:51 |
KaadmY |
I don't think it'll be trivial, but I'd LOVE to see near instant meshgen |
| 20:51 |
KaadmY |
And/or mapgen |
| 20:51 |
nerzhul |
i don't found any solution to optimize mapgen |
| 20:51 |
nerzhul |
i looked at the code it's nearly optimized in the current algorithm |
| 20:51 |
KaadmY |
Mapgen time is limited by noise algorithms basically |
| 20:52 |
KaadmY |
Which can't be improved much |
| 20:54 |
CalebDavis |
i got the dev right before the colisionbox redo but my inventory items wont spin why? |
| 20:56 |
nerzhul |
bigfoot547, #6176 |
| 20:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/6176 -- Massive performance improvement on correctBlockNodeIds by nerzhul |
| 20:56 |
CalebDavis |
i have the setting for inventory animations set to true |
| 20:57 |
nerzhul |
look at callgrind output |
| 20:57 |
nerzhul |
it's crazy |
| 20:57 |
nerzhul |
MapBlock::deSerialize : 16% CPU usage, after 0.53% |
| 20:57 |
nerzhul |
:p |
| 20:59 |
paramat |
excellent, thanks |
| 20:59 |
nerzhul |
on generated maps, the load from DB will be slightly improved, now we need to change comprssion algorithm and it will be just, crazy heh |
| 21:00 |
paramat |
'near instant meshgen and mapgen' that's not really realistic |
| 21:00 |
nerzhul |
agreed |
| 21:01 |
CalebDavis |
paramat do you have any ideas on why my inventory items arent rotating |
| 21:01 |
paramat |
CalebDavis no idea why, maybe open an issue? |
| 21:01 |
CalebDavis |
i think it might just be me idk |
| 21:02 |
CalebDavis |
ill try the latest dev |
| 21:07 |
nerzhul |
i'm pushing removal of Map::getDayNightDiff(v3s16 blockpos) which is unused since ages |
| 21:14 |
|
elinor joined #minetest-dev |
| 21:18 |
paramat |
ok |
| 21:19 |
elinor |
paramat: Regarding #1456, does the maxlevel for the axe mese really need to remain higher than the maxlevel for the diamond axe? |
| 21:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/1456 -- Faces shading fixes by RealBadAngel |
| 21:20 |
paramat |
game#1456 |
| 21:20 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1456 -- Diamond axe breaks earlier than mese axe |
| 21:20 |
VanessaE |
imho mese ought to always be the most powerful of the default tools |
| 21:20 |
paramat |
maxlevel seems important to define what it can chop? |
| 21:20 |
VanessaE |
(since it's unique to minetest and always used to be) |
| 21:21 |
paramat |
i'm not sure but diamond may actually be the most powerful now |
| 21:21 |
VanessaE |
imho that ought to change then |
| 21:21 |
elinor |
Yes, but I would expect a diamond axe to be able to chop more things than a mese axe. |
| 21:22 |
elinor |
All the diamond and mese tools have maxlevel=3. |
| 21:23 |
elinor |
Except the axe, so to make it consistent the diamond axe should have maxlevel=3. Otherwise the mese axe can chop more things than the diamond axe—which I don't think applies to anything in Minetest Game right now, but theoretically a mod could register a tree node with a higher level. |
| 21:23 |
paramat |
oh |
| 21:23 |
paramat |
ok good point |
| 21:24 |
elinor |
So I would change the maxlevel for the diamond axe to 3, then adjust the tool capabilities so that the dig params make sense. |
| 21:24 |
paramat |
i wasn't aware of that |
| 21:25 |
elinor |
VanessaE: Maybe it should, but mese should at least be rarer than diamond if that was to become the case. |
| 21:25 |
VanessaE |
perhaps |
| 21:26 |
paramat |
well i have changes for ore depths coming |
| 21:26 |
paramat |
making mese ore as deep as diamond |
| 21:27 |
paramat |
elinor want to make a PR for diamond axe? |
| 21:27 |
* elinor |
nods |
| 21:28 |
paramat |
generally it seems mese and diamond are roughly equal in MTG, which seems ok to me |
| 21:30 |
elinor |
They aren't, diamond tools always dig faster and can always be used more times. |
| 21:33 |
VanessaE |
either way, mese should be the most powerful. it's just the right way to do it :) |
| 21:33 |
VanessaE |
diamonds being rarer makes them useful as currency anyway |
| 21:40 |
paramat |
rubenwardy sfan5 any thoughts on #1850 ? seems a possible close |
| 21:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/1850 -- Add gettext to Travis build by ShadowNinja |
| 21:40 |
nerzhul |
hop a 2nd commit on 6167 which reduce mapblock save memory usage (& cpu cost when mapblocks are dup in memory in some areas) |
| 21:42 |
paramat |
ok so a consistent PR that makes diamond axe more capable than mese axe is fine |
| 21:42 |
paramat |
game#1850 |
| 21:42 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1850 -- rename junglewood to rosewood by DS-Minetest |
| 21:42 |
nerzhul |
rosewood ? lol |
| 21:44 |
VanessaE |
wat |
| 21:45 |
VanessaE |
nfw |
| 21:45 |
|
Taoki joined #minetest-dev |
| 21:46 |
paramat |
it's likely to be closed :] |
| 21:46 |
VanessaE |
good. :) |
| 21:47 |
Raven262 |
I found a minor error in mtg, clay brick texture is 16x17 instead of 16x16. |
| 21:47 |
Raven262 |
Is this intended? |
| 21:48 |
KaadmY |
Awwwwwwwwww why |
| 21:48 |
KaadmY |
Probably needed an odd pixel size |
| 21:48 |
VanessaE |
doubt it |
| 21:49 |
|
Fixer joined #minetest-dev |
| 21:49 |
Raven262 |
It does affect the brick's display in the inventory. |
| 21:49 |
Raven262 |
Causes it to appear lower |
| 22:01 |
|
Qbiq joined #minetest-dev |
| 22:14 |
nerzhul |
i push a trivial removal on a unused variable |
| 22:15 |
paramat |
Raven262 not intended, could you open an issue or make a PR? |
| 22:15 |
Raven262 |
I'll do an issue |
| 22:16 |
Raven262 |
I'll also check if there are other texture in default mod that have this error |
| 22:20 |
Raven262 |
Okay, brick is the only one. |
| 22:22 |
Raven262 |
https://github.com/minetest/minetest_game/issues/1855 |
| 22:22 |
Raven262 |
there you have it. |
| 22:22 |
nerzhul |
i push a second commit un perlinMap3D noise call, replace a loop with a memset |
| 22:38 |
paramat |
game#1851 is ready, nice feature |
| 22:38 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1851 -- Make underwater torches drop by ForbiddenJ |
| 22:43 |
KaadmY |
paramat: isn't that like a 1 line change... |
| 22:44 |
paramat |
what is? |
| 22:44 |
KaadmY |
Making torches drop when underwater |
| 22:45 |
KaadmY |
floodable = true |
| 22:46 |
|
Fritigern joined #minetest-dev |
| 22:47 |
|
twoelk joined #minetest-dev |
| 22:56 |
paramat |
nope |
| 22:56 |
paramat |
floodable removes a node |
| 23:42 |
|
proller joined #minetest-dev |
