Time |
Nick |
Message |
00:07 |
_Megaf |
needs rebase https://github.com/minetest/minetest/pull/4420 |
00:25 |
paramat |
it says no conflicts though |
01:00 |
|
ElectronLibre joined #minetest-dev |
01:06 |
|
turtleman joined #minetest-dev |
01:21 |
OldCoder |
There is no way to set the frame delay on a node animation, correct? Just for sprites? |
02:18 |
|
ElectronLibre joined #minetest-dev |
03:07 |
|
hmmmm joined #minetest-dev |
03:26 |
|
gregorycu joined #minetest-dev |
03:56 |
gregorycu |
So |
03:56 |
gregorycu |
What seems to cause a lot of jitter is processing block data inside the GUI thread |
03:58 |
|
DI3HARD139 joined #minetest-dev |
03:59 |
gregorycu |
I'm thinking of moving that to the update thread |
04:01 |
paramat |
interesting. need to omnom, back in an hour |
04:22 |
|
SloanOnLinux joined #minetest-dev |
04:22 |
|
SloanOnLinux joined #minetest-dev |
04:49 |
|
kaeza joined #minetest-dev |
04:56 |
gregorycu |
A little bit of code churn here, but if I can get this right... |
05:04 |
gregorycu |
What is a sector? |
05:05 |
gregorycu |
Looks to be a vertical slice of the world |
05:19 |
|
paramat joined #minetest-dev |
05:21 |
paramat |
a complete vertical column of mapblocks, i think |
05:23 |
gregorycu |
The longer I go, the more I know this change will never get approved |
05:23 |
gregorycu |
Do other people notice the jittery graphics? |
05:24 |
gregorycu |
Is it a known issue? |
05:31 |
paramat |
yes well known and irritating |
05:32 |
paramat |
it really bothers me and many others |
05:33 |
paramat |
any work on it will be very much appreciated |
05:35 |
paramat |
can't find an issue but i think there's a forum thread about it |
05:35 |
gregorycu |
I think I've reduced it, but I'm trying to eliminate it |
05:35 |
gregorycu |
I've done the analysis, I know what causes most of it |
05:35 |
paramat |
for me seems to get worse around forests: complex meshes |
05:42 |
gregorycu |
I'm testing with Just Test |
05:42 |
gregorycu |
Which has a lot of stuff going on |
05:42 |
paramat |
Fixer has looked into this, see https://forum.minetest.net/viewtopic.php?f=6&t=13360 |
05:47 |
paramat |
issue #3602 |
05:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/3602 -- Serious stuttering (large instantenious fps drop) (rendering) |
06:22 |
gregorycu |
Well, it works well until it crashes |
06:27 |
gregorycu |
Speed or stability, chose 1 |
06:29 |
* paramat |
grabs both and runs |
06:39 |
gregorycu |
paramat: Did you want to have a look at my jitter changes? |
06:39 |
gregorycu |
I'll revert the crashing code |
06:42 |
paramat |
no need, i won't understand it, thanks though |
06:44 |
gregorycu |
I meant, look at the effect, not the code :) |
06:45 |
gregorycu |
Fixer is going to take a look i think |
06:45 |
gregorycu |
Give me the validation I need |
06:47 |
paramat |
oh, yeah i'll test it, in a day or so |
06:58 |
|
paramat left #minetest-dev |
06:58 |
|
Krock joined #minetest-dev |
07:22 |
gregorycu |
!tell Fixer I've fixed the build. I was depending on a C++11 feature. I've also included another changeset to remove some jitter when it's calculating what to draw |
07:22 |
ShadowBot |
gregorycu: O.K. |
07:41 |
|
AcidNinjaFWHR joined #minetest-dev |
07:46 |
|
nrzkt joined #minetest-dev |
07:57 |
nrzkt |
Krock, fixed the code style on #4604 thanks. A coredev can review this change please ? :) |
07:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/4604 -- Environment cleanup by nerzhul |
08:00 |
Krock |
nrzkt, "can you fixe thoses indents" - they're fine. |
08:01 |
Krock |
perfectly lined up with the one above |
08:01 |
Krock |
namely "ID_soundExitButton" |
08:04 |
nrzkt |
but this is spaces, strange, you talk about RUI's PR ? |
08:07 |
|
Hunterz joined #minetest-dev |
08:12 |
Krock |
yes. Spaces are good for this purpose |
08:13 |
nrzkt |
oki |
08:22 |
gregorycu |
So, we used tabs + spaces right? |
08:23 |
gregorycu |
As god intended |
08:26 |
Krock |
[tab][tab]int somevar[space ..]= value; |
08:26 |
Krock |
tabs in front, spaces afterwards. because tabs have no fixed size |
08:28 |
OldCoder |
There is no way to set the frame delay on a node animation, correct? Just for sprites? |
08:28 |
OldCoder |
So, the only way to slow down an animation is to double each frame? |
08:30 |
Krock |
there's the parameter "length" in nodefed.tiles.animation |
08:30 |
Krock |
and it's the time for the whole animations |
08:30 |
Krock |
-s |
08:30 |
gregorycu |
Krock: It's amazing how many people don't get it |
08:31 |
gregorycu |
Tabs for indention, spaces for alignment |
08:33 |
nrzkt |
OldCoder, #3307 is fixed no ? |
08:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/3307 -- 'RE-SENDING timed-out RELIABLE' causes server timeout/lockup |
08:35 |
nrzkt |
merging #4605 as it's trivial fix |
08:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/4605 -- Remove unused parameter of GUIVolumeChange by Rui-Minetest |
08:55 |
|
ElectronLibre joined #minetest-dev |
09:01 |
Krock |
#4606 [ @ Startup / Config / Util ] [ @ Translation ] |
09:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/4606 -- Add missing languages to the settings by SmallJoker |
09:06 |
|
Zeno` joined #minetest-dev |
09:15 |
nrzkt |
hi Zeno` :) |
09:18 |
Zeno` |
hi Krock, nrzkt |
09:21 |
Zeno` |
#4551 can probably be merged since it's so trivial |
09:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/4551 -- Trim whitespaces from the input of the `/privs` command. by red-001 |
09:22 |
Krock |
we sohuld keep "name" consistent IMO |
09:22 |
Zeno` |
? |
09:22 |
Krock |
well, the param "name" was renamed to "caller" |
09:23 |
Zeno` |
https://github.com/minetest/minetest/pull/4551/files |
09:23 |
Zeno` |
oh i see |
09:24 |
Krock |
but eh, that's a small issue |
09:24 |
Zeno` |
*shrug* it's all local and seems like a non-issue to me |
09:24 |
Zeno` |
just trying' to close PRs where possible ;) |
09:25 |
Krock |
merge it then it's closed ^^ |
09:26 |
nrzkt |
Zeno`, please review #4604 :) |
09:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/4604 -- Environment cleanup by nerzhul |
09:26 |
|
HonoredGlory joined #minetest-dev |
09:26 |
Krock |
4606 too, if you're already in the mud :P |
09:26 |
Krock |
or sauce, or wherever you can be in. |
09:29 |
Zeno` |
I have a few things to do, but I'll look at them all when I get back ;) |
09:34 |
nrzkt |
ty :) |
09:41 |
|
jin_xi joined #minetest-dev |
09:43 |
|
yyt16384 joined #minetest-dev |
10:09 |
|
Fixer joined #minetest-dev |
10:16 |
Fixer |
!tell gregorycu yes, I will try it today |
10:16 |
ShadowBot |
Fixer: O.K. |
10:27 |
|
red-001 joined #minetest-dev |
10:33 |
Fixer |
!tell gregorycu tried, i think it is still not smooth and stutters on chunk loading a bit |
10:33 |
ShadowBot |
Fixer: O.K. |
10:40 |
|
gregorycu joined #minetest-dev |
10:40 |
|
Fixer_ joined #minetest-dev |
10:40 |
gregorycu |
!tell Fixer But is it any better? |
10:40 |
ShadowBot |
gregorycu: O.K. |
10:40 |
Fixer_ |
irc client crashed |
10:41 |
Fixer_ |
gregorycu: maybe slightly better, but difference is small |
10:41 |
gregorycu |
Yeah, I can still see stuttering myself |
10:41 |
Fixer_ |
gregorycu: there was this warning during compilation http://pastebin.com/raw/gqmft9gr |
10:41 |
|
xunto joined #minetest-dev |
10:42 |
gregorycu |
Oh, that's easily fixed |
10:42 |
gregorycu |
Thanks |
10:42 |
Fixer_ |
gregorycu: turn on F5 graphs and look at draw time, start walking and you see stuttering parts |
10:42 |
gregorycu |
Yep |
10:42 |
gregorycu |
It's so hard to get rid of all of them |
10:42 |
gregorycu |
Without large changes |
10:42 |
Fixer_ |
just now started moving it shoots up from 0.033 to 0.112 |
10:42 |
gregorycu |
A lot of processing is done on the main thread |
10:42 |
Fixer_ |
and back to 0.033 |
10:50 |
Fixer_ |
gregorycu: one time stutter was close to eliminated when celeron55 made a bug in farmap PR that caused slow sending of mapblocks %) |
10:51 |
Fixer_ |
it really made a difference |
10:51 |
Fixer_ |
it was a bug though |
10:52 |
gregorycu |
The thing is, the architecture of this game is such that the main thread doesn't only handle display and input |
10:52 |
gregorycu |
It handles a lot of stuff |
10:52 |
celeron55 |
the architecture of irrlicht is such |
10:52 |
celeron55 |
when i measured the stuttering some years ago, i noticed that the processing was done by irrlicht when drawing newly loaded things, not when loading them |
10:52 |
gregorycu |
Some stuff can't be moved out |
10:52 |
gregorycu |
Like the mesh generation |
10:53 |
gregorycu |
An example is receiving block data and updating the world |
10:53 |
gregorycu |
Deserialisation is done on the GUI thread |
10:53 |
gregorycu |
GUI thread = main thread |
10:56 |
Fixer_ |
maybe load meshes in small batches, not like now 50-60... in one spike? spread it out? |
10:58 |
gregorycu |
Isn't there a setting for that? |
10:59 |
celeron55 |
there is a setting for that |
10:59 |
celeron55 |
it's nothing new |
11:00 |
gregorycu |
Maybe we need to retire irrlicht |
11:01 |
celeron55 |
minecraft at least historically has had the same kind of stutter on the same hardwares that minetest has had stutter on; it could be a hardware or driver issue that isn't easily solved by switching opengl wrappers |
11:01 |
celeron55 |
it would be good if somebody figured it out some day |
11:02 |
gregorycu |
I vote you |
11:03 |
celeron55 |
wait |
11:03 |
celeron55 |
i realized there actually is no direct setting for mesh generation per frame |
11:03 |
celeron55 |
and there's a reason for it |
11:04 |
celeron55 |
the setting that can be used in singleplayer is max_simultaneous_block_sends_per_client |
11:04 |
celeron55 |
it's server-side |
11:04 |
celeron55 |
if there was a client-side limit, you would cause mesh update lag if the server sends more per frame than the setting is |
11:05 |
gregorycu |
Yeah, but there are ways around that |
11:05 |
celeron55 |
i don't even remember anymore but the farmap branch might have ended up having a mechanism for easing this |
11:05 |
gregorycu |
I've been focusing on things that are not that |
11:06 |
celeron55 |
>I vote you |
11:06 |
celeron55 |
i don't have hardware that has the issue |
11:06 |
gregorycu |
For instance, the non-drawing time |
11:06 |
gregorycu |
How do you not have stutter? |
11:07 |
gregorycu |
Do you play singleplayer? |
11:07 |
celeron55 |
it's well known that not all computers have the problem |
11:08 |
celeron55 |
or, well |
11:08 |
gregorycu |
For instance, mainloop_other, just shot up to be above 100ms for me |
11:08 |
gregorycu |
And that has nothing to do with drawing |
11:08 |
celeron55 |
if i use the nvidia GPU in this laptop and cause massive amounts of mesh updates, then it can get noticeable |
11:08 |
celeron55 |
in normal operation there are no issues |
11:08 |
celeron55 |
and on intel, no issues no matter what |
11:09 |
celeron55 |
on the laptop i originally developed minetest on, there are never any of these issues; not then, not now |
11:09 |
gregorycu |
You also didn't really benefit from my shader stuff |
11:10 |
gregorycu |
Actually, sorry, I think you did a little |
11:10 |
celeron55 |
a shitty desktop that i stopped using for many reasons had the issue on its intel HD3000 GPU, but i don't remember if it was only on windows |
11:10 |
celeron55 |
what i'm saying is, it varies, and the way it varies doesn't make any sense |
11:11 |
gregorycu |
Problem is, i know nothing about graphics stuff |
11:11 |
gregorycu |
I know how to speed up CPU processing |
11:11 |
celeron55 |
and that's why i have zero interest in trying to figure it out |
11:12 |
celeron55 |
and also, no actual graphics programmers want to look at it, because minetest is so archaic compared to any kind of respectable ways of doing modern graphics |
11:13 |
gregorycu |
You mean because it uses ilight? |
11:13 |
celeron55 |
i mean, just the idea of being able to run fixed pipeline makes them run right away and never come back |
11:13 |
gregorycu |
See, I don't even know what those words mean |
11:13 |
celeron55 |
i.e. without shaders |
11:14 |
gregorycu |
We got shaders |
11:14 |
celeron55 |
yes but the architecture is based on having no shaders |
11:14 |
gregorycu |
Don't most games, even AAA titles allow you to turn off shaders |
11:14 |
celeron55 |
a shader-based architecture is quite different |
11:14 |
celeron55 |
no |
11:15 |
celeron55 |
maybe 15 or 20 years ago |
11:15 |
gregorycu |
What you are saying isn't exactly inspiring |
11:15 |
celeron55 |
these days even 2D games *require* shaders |
11:16 |
celeron55 |
nothing in this is inspiring, frankly |
11:16 |
gregorycu |
So, wanna write a new game? |
11:16 |
gregorycu |
Maybe a new game with a better name |
11:17 |
celeron55 |
no? |
11:17 |
gregorycu |
I think, together, we can write a kickarse game |
11:17 |
gregorycu |
We'll get Fixer in to consult |
11:18 |
gregorycu |
hmm can be the motivation |
11:18 |
gregorycu |
motivator |
11:18 |
celeron55 |
well, actually, i've done that, but whether they'll ever be release-worthy is questionable; and they are not minetest clones |
11:18 |
gregorycu |
Fair enough |
11:18 |
gregorycu |
Stick it on git so I can laugh at them |
11:18 |
gregorycu |
I mean |
11:18 |
gregorycu |
Work on them |
11:21 |
celeron55 |
i'd kind of fancy being able to sell them if they're ever finished |
11:25 |
|
nrzkt joined #minetest-dev |
11:26 |
|
SloanOnLinux joined #minetest-dev |
11:26 |
|
SloanOnLinux joined #minetest-dev |
11:33 |
Fixer_ |
celeron55: i disagree, I tried MC 1.10 and I have stutter only on initial map loading few seconds or in areas with loooots of redstone/chunk updates, in usual gameplay there is practically no stutter and very smooth play |
11:34 |
Fixer_ |
celeron55: chunk loading in minetest causes visible stutter, in minecraft - practically no stutter |
11:35 |
Fixer_ |
celeron55: iirc minecraft does not require shaders and uses OGL 2.2 or smth |
11:37 |
Calinou |
OpenGL 2.0 (which is what Minecraft uses) is a shader pipeline |
11:37 |
|
Foghrye4 joined #minetest-dev |
11:37 |
Calinou |
but they did use fixed-function OpenGL 1.2 in the past, and it worked well for them |
11:38 |
Fixer_ |
gregorycu: stutter is both in singleplayer and multiplayer, occurs when at chunk load/refresh time imo |
12:42 |
_Megaf |
any idea when 0.4.15 will be released? |
12:46 |
Fixer_ |
_Megaf: ~December 16 or later |
12:46 |
Fixer_ |
2016* |
12:46 |
_Megaf |
ok |
12:51 |
gregorycu |
All this talk about pipelines makes me want to understand |
12:52 |
gregorycu |
If we were to migrate to, say ogre3d, or something else |
12:53 |
gregorycu |
Would that assist in us moving from a fixed-functoin pipeline to a shader pipeline |
13:03 |
celeron55 |
the first question in migrating to anything is which is the lowest version of opengl that we want to support |
13:03 |
celeron55 |
then you basically just code for that, or use a library that is coded for that |
13:06 |
celeron55 |
it basically dictates the model of rendering and uploading and whatever you can use, and libraries are built to primarily support they way things are done in some version |
13:06 |
nrzkt |
gregorycu, urho could be a better solution but there will be very very huge work on client side :) |
13:07 |
_Megaf |
[14:03:16] <celeron55> the first question in migrating to anything is which is the lowest version of opengl that we want to support |
13:07 |
_Megaf |
OpenGL 2.0 Of course |
13:07 |
gregorycu |
I don't know |
13:07 |
gregorycu |
We couldnt' move to a new compiler because 10 year old operating systems didn't support it |
13:08 |
_Megaf |
And then use every single thing it has to offer |
13:08 |
gregorycu |
(Apparently) |
13:09 |
Calinou |
if you want to use a fully shader-based pipeline, you want to use OpenGL 3.3 Core Profile or later |
13:09 |
Calinou |
(no deprecated APIs) |
13:09 |
gregorycu |
So, it's decided then |
13:10 |
gregorycu |
OpenGL 3.3 it is |
13:10 |
celeron55 |
i bet even 2.0 can be a disaster as people use minetest on absolutely ancient hardware |
13:10 |
gregorycu |
I'm glad this decision is locked in now |
13:10 |
gregorycu |
How about we say "fuck em" |
13:10 |
gregorycu |
I'm a brutal bastard |
13:10 |
celeron55 |
fuck half of the userbase? well i guess so |
13:11 |
gregorycu |
I'm also just a bastard |
13:11 |
gregorycu |
We've been fucking over half the userbase by keeping my shader fixes on the shelf |
13:12 |
gregorycu |
I think we have the potential here to make a quarter of our users happy |
13:12 |
Calinou |
literally everyone has GL 3.3 nowadays |
13:12 |
Calinou |
(more than people who have GLES 3.0 for example) |
13:13 |
Calinou |
but people with toasters *will* complain and accuse you to be part of a conspiracy |
13:13 |
Calinou |
GL 3.3 was released in like, 2010 |
13:13 |
celeron55 |
well i don't really mind; it would be nice if the toaster users would be able to maintain an otherwise up-to-date version for themselves alongside the modern one |
13:13 |
Calinou |
even ancient hardware like GeForce 9600 GT supports it |
13:13 |
Calinou |
(which is no longer supported by NVIDIA) |
13:14 |
gregorycu |
That's actually a good point |
13:14 |
gregorycu |
Minetest and Minetest classic |
13:14 |
gregorycu |
Both compatable |
13:15 |
sfan5 |
nobody wants to maintain that |
13:15 |
celeron55 |
that's about twice the amount of work you're suggesting, or more |
13:15 |
sfan5 |
also has anyone ever looked at gles support on android? |
13:15 |
gregorycu |
It's only twice the work when it comes to graphical stuff |
13:15 |
gregorycu |
If you want feature parity |
13:15 |
Calinou |
sfan5: Irrlicht seems to not like GLES very much |
13:16 |
Calinou |
it has only GLES 1.0 and 2.0, both are heavily out of date by now |
13:16 |
Calinou |
GLES 3.0 is the shit but it was released in 2012, only 55% of Android devices support it |
13:16 |
sfan5 |
if you start requiring gles 3 then say goodbye to android |
13:16 |
gregorycu |
I think ogre is a bit too heavy |
13:16 |
Calinou |
Android 5.0 or later supports it, sfan5 |
13:16 |
gregorycu |
What was the other good one? |
13:16 |
sfan5 |
the android version doesn't matter |
13:16 |
sfan5 |
what matters is graphics drivers |
13:16 |
celeron55 |
i would have built minetest on ogre if ogre had an open enough license back then |
13:16 |
Calinou |
so does the iPhone 5S and later, by the way |
13:16 |
sfan5 |
and those are absolutely bad on mobile |
13:17 |
celeron55 |
back then it had GPL or something like that, or some other license that i didn't like |
13:17 |
Calinou |
celeron55: well you used LGPL on Minetest anyway, why would it have mattered |
13:17 |
Calinou |
OGRE used to be LGPL indeed |
13:17 |
nrzkt |
merging #4604 thanks sfan5 |
13:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/4604 -- Environment cleanup by nerzhul |
13:18 |
celeron55 |
well whatever, that was the only reason i went with irrlicht; i didn't know much about licenses back then and wanted to play safe |
13:18 |
gregorycu |
Open Scene Graph? |
13:19 |
celeron55 |
gregorycu: when doing that choice, you need to consider that irrlicht does much more than graphics for minetest; it fully does windowing, wraps input devices, does user interface stuff and even does copy-paste on windows |
13:20 |
Calinou |
time to remake Minetest in Godot ;) |
13:20 |
Fixer_ |
my itty lenovo laptop from 2008 has OGL 2.1 iirc |
13:20 |
Calinou |
frameworks have disappointed people quite a lot, so I'm not surprised general-purpose engines are on the rise |
13:20 |
Fixer_ |
with intel integrated garbage |
13:20 |
Calinou |
Fixer_: all my hardware has GL 4.5 :P |
13:20 |
Fixer_ |
my desktop is 4.5 |
13:21 |
gregorycu |
My toaster is GL 3.3 |
13:21 |
gregorycu |
I don't fuck around when it comes to toasters |
13:21 |
gregorycu |
Anyway, I'm off to bed |
13:22 |
celeron55 |
afaik many libraries that say they support 2.1 actually require some extensions not included in 2.1 |
13:22 |
celeron55 |
then they sometimes don't work on 2.1 hardware |
13:22 |
celeron55 |
same for other opengl versions |
13:23 |
Fixer_ |
i already had some weird red block below player on that OGL |
13:25 |
celeron55 |
anyway, i don't really care |
13:27 |
sfan5 |
_Megaf: how are you determining that a pr needs a rebase? |
13:28 |
_Megaf |
sfan5: I may be mistaken, I will review my rebase assumptions in a couple of minutes |
13:28 |
_Megaf |
sfan5: basically, I downloaded minetest from master and tried to apply the patch for PR |
13:28 |
sfan5 |
i don't know whether you can see that but github says: |
13:28 |
sfan5 |
This branch has no conflicts with the base branch |
13:28 |
sfan5 |
Merging can be performed automatically. |
13:28 |
sfan5 |
(for e.g. #4425) |
13:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/4425 -- Assertion failure: sanitize some values obtained from mods (yaw, velocity, etc.) by Rogier-5 |
13:28 |
_Megaf |
if the git apply .patch worked, I asusmed it was fine |
13:28 |
_Megaf |
if it failed, I assumed it needs rebase |
13:29 |
sfan5 |
git apply? |
13:29 |
sfan5 |
don't you usually use git am for patches? |
13:29 |
_Megaf |
wget url/pr.patch |
13:29 |
_Megaf |
git apply pr.patch |
13:29 |
_Megaf |
by pr I mean, pr number |
13:29 |
Calinou |
try https://hub.github.com/ |
13:29 |
sfan5 |
i always use git am ¯\_(ツ)_/¯ |
13:29 |
_Megaf |
let me double check just in case |
13:30 |
_Megaf |
I apologize in advance if I'm mistaken in rebase assumptions |
13:33 |
_Megaf |
sfan5: http://git.megaf.info/Megaf/GitPaste/raw/master/GitApplyPatch |
13:33 |
_Megaf |
thats how I do |
13:34 |
sfan5 |
try git am -3 foobar.patch |
13:34 |
_Megaf |
in this example it failed to apply the patch |
13:34 |
_Megaf |
hm |
13:34 |
nrzkt |
or patch -p0 < foobar.patch |
13:34 |
sfan5 |
no |
13:34 |
sfan5 |
that's not a correct way to apply a git patch |
13:35 |
_Megaf |
git am -3 failed as well |
13:35 |
sfan5 |
well then it definitely needs a rebase |
13:36 |
_Megaf |
patch too failes with "can't find file to patch at input line 16" |
13:36 |
_Megaf |
to me it clearly needs rebase |
13:36 |
sfan5 |
it doesn't matter what patch says |
13:36 |
_Megaf |
because something changed in master that makes it fail to get the patch |
13:36 |
sfan5 |
because patch is not the correct way to apply git patches |
13:37 |
_Megaf |
Ok, I undestand, is not what I use |
13:37 |
_Megaf |
I use a git tool designed to apply patchs, its called, wait for it, apply |
13:37 |
_Megaf |
or, I may be mistaken |
13:37 |
* _Megaf |
reads the doc |
13:37 |
_Megaf |
there https://git-scm.com/docs/git-apply |
13:37 |
* _Megaf |
is not mistaken |
13:40 |
|
yang2003 joined #minetest-dev |
13:41 |
Zeno` |
errr... I always use git am also |
13:41 |
_Megaf |
How you learned about git am? |
13:42 |
Zeno` |
I can't recall now |
13:42 |
Zeno` |
it's just git am file.patch |
13:42 |
_Megaf |
but please, do double check my assumtion that it needs rebase. It's not hard to do so... I already did the hardest part... |
13:42 |
_Megaf |
xP |
13:43 |
_Megaf |
and do finally merged the PRs I commented |
13:43 |
_Megaf |
they are very important |
13:43 |
_Megaf |
I'd say crucial |
13:43 |
sfan5 |
did you actually read the docs or just link them? |
13:43 |
sfan5 |
This command applies the patch but does not create a commit. Use git-am[1] to create commits from patches generated by git-format-patch[1] and/or received by email. |
13:44 |
sfan5 |
if you want to merge patches you obviously need to preserve the commit metadata |
13:44 |
sfan5 |
also the .patch files created by github are exactly those you'd get from git-format-patch |
13:44 |
_Megaf |
"This command applies the patch but does not create a commit" |
13:45 |
_Megaf |
precisely |
13:45 |
_Megaf |
I'm just testing if the patch works |
13:45 |
sfan5 |
you're testing whether the diff applies |
13:45 |
_Megaf |
That is correct |
13:45 |
sfan5 |
not whether you can create a commit based on the diff |
13:46 |
sfan5 |
but probably those two are equivalent in this case |
13:46 |
_Megaf |
Because IMHO you can't create a commit if the patch doesnt work. |
13:47 |
sfan5 |
no but maybe you can apply the diff but not create a commit |
13:47 |
_Megaf |
So? |
13:47 |
_Megaf |
sfan5: I'm testing if the thing needs rebease or not. If the diff doesnt work, than I believe is safe to assume that rebase is needed. Am I correct? |
13:48 |
_Megaf |
s/is/it is |
13:49 |
_Megaf |
And about commiting, myself use git commit command if the git apply worked. But on my projects, I test the patch with git apply and then use merge button on the web interface to merge. |
13:50 |
sfan5 |
yes yes it doesn't matter in this case |
13:57 |
|
STHGOM joined #minetest-dev |
14:04 |
Foghrye4 |
Hey, right now i catch 'void LocalPlayer::setCAO(GenericCAO*): Assertion `m_cao == __null' failed.' on my game with fresh Minetest version. But it works perfectly fine yesterday. |
14:04 |
Foghrye4 |
*on yesterday version of Minetest. |
14:05 |
Krock |
^ nrzkt |
14:07 |
nrzkt |
when did you trigger that Foghrye4 ? i tested fresh game and remote server without esperience this |
14:08 |
Foghrye4 |
Using Minetest Saturn game i'm working on. |
14:08 |
nrzkt |
this i strange i didn't modify the CAO set |
14:08 |
Foghrye4 |
Indeed. |
14:11 |
Foghrye4 |
Here is gdb output: http://pastebin.com/saphcxDm |
14:13 |
nrzkt |
ty looking for this |
14:14 |
nrzkt |
okay i triggered the bug i know how, now i need to fix it |
14:16 |
_Megaf |
sfan5: I know we have kinda of a music player built in now, where can I get information about that? Or how to use it |
14:16 |
sfan5 |
dunno |
14:17 |
nrzkt |
Foghrye4, how have you triggered the bug ? |
14:17 |
_Megaf |
:S |
14:18 |
_Megaf |
Can anyone give me info on the music player we have? |
14:18 |
nrzkt |
the function is called at CAO initialization and link localplayer with CAO, if this occurs this mean you init player CAO twice |
14:19 |
Foghrye4 |
By starting a game (Minetest Saturn). On player join event an entity spawn triggered immediately. |
14:20 |
Foghrye4 |
OW! |
14:20 |
Foghrye4 |
A pull request merged yesterday! |
14:20 |
Foghrye4 |
My pull request. |
14:21 |
nrzkt |
strange, is there any remote server doing this ? |
14:21 |
Foghrye4 |
Its contain part, when parent entity attached to something initialised in area, it reinitialised all childs as well. |
14:22 |
nrzkt |
are you on current master ? |
14:23 |
nrzkt |
because the only commit which can change the behaviour is currently merged commit, but i didn't know how |
14:23 |
Foghrye4 |
https://github.com/Foghrye4/minetest/blob/ad2c1b8cb402b2546983742b31deaa3b1ab8b095/src/content_cao.cpp#L1763 |
14:24 |
nrzkt |
you are not in current master, then not my commit |
14:24 |
nrzkt |
:) |
14:24 |
nrzkt |
https://github.com/minetest/minetest/blob/70f104be076321330a0827010704761a040d8ec7~2/src/content_cao.cpp#L665 |
14:25 |
nrzkt |
here is the line in current master |
14:25 |
nrzkt |
can you pull rebase master and retry ? maybe this has been fixed by my patch |
14:30 |
Foghrye4 |
I don't get it. I used 'git clone' on master branch a hour ago. |
14:30 |
nrzkt |
Foghrye4, i don't know how your code works, but your CAO is a player CAO like the original player, then you are setting a second time the CAO attached to LocalPlayer |
14:32 |
nrzkt |
i will push a missing little trivial code cleanup to master i forgot in previous commit |
14:33 |
nrzkt |
Foghrye4, just pull rebase to current master and tell us if your crash is already there |
14:33 |
fling |
Foghrye4: children |
14:36 |
Foghrye4 |
nrzkt: You asking me to do "git pull --rebase origin master" |
14:36 |
Foghrye4 |
? |
14:37 |
Zeno` |
git fetch upstream; git rebase upstream/master |
14:37 |
Zeno` |
but I don't think your current repo state will allow that |
14:38 |
Zeno` |
origin is (well, should be) *your* fork, so rebasing to that will just make things worse I think |
14:39 |
Zeno` |
if it does anything at all |
14:40 |
|
Player_2 joined #minetest-dev |
14:40 |
Foghrye4 |
There is no my code in tested version of Minetest. |
14:40 |
Foghrye4 |
Except Lua code. |
14:42 |
nrzkt |
Foghrye4, yes git pull --rebase origin master if origin is minetest origin repo |
14:43 |
Foghrye4 |
nrzkt, done. Bug still exist. |
14:43 |
Zeno` |
Foghrye4, what URL is your origin? |
14:43 |
nrzkt |
okay then i'm happy to see it doesn't seems to be my PR :) |
14:43 |
nrzkt |
Foghrye4, you said that the bug wasn't present before ? |
14:43 |
Foghrye4 |
foghrye4foghrye4-GA-A75-D3H:~/minetest-branches/freshiest/minetest$ git remote -v |
14:43 |
Foghrye4 |
originhttps://github.com/minetest/minetest.git (fetch) |
14:43 |
Foghrye4 |
originhttps://github.com/minetest/minetest.git (push) |
14:44 |
_Megaf |
du -k ../MinetestMinSizeRel/bin/minetest |
14:44 |
_Megaf |
4556 ../MinetestMinSizeRel/bin/minetest |
14:44 |
_Megaf |
du -k ../MinetestRelease/bin/minetest |
14:44 |
_Megaf |
7188 ../MinetestRelease/bin/minetest |
14:44 |
Foghrye4 |
nrzkt, wasn't presented yesterday. |
14:44 |
nrzkt |
did you find the problematic commit ? |
14:44 |
nrzkt |
maybe do a bissect could help us |
14:45 |
_Megaf |
why dont we make MinSizeRel the default? |
14:49 |
|
turtleman joined #minetest-dev |
14:52 |
sfan5 |
_Megaf: why would we? |
14:55 |
Calinou |
minimal size isn't important for 99% of users |
14:56 |
Calinou |
most people don't ever distribute their builds |
14:56 |
Calinou |
and if they do, they should compress them anyway |
14:59 |
|
rubenwardy joined #minetest-dev |
15:00 |
|
Hunterz joined #minetest-dev |
15:04 |
nrzkt |
Foghrye4, can you bissect ? i'm unable to reproduce your problem |
15:05 |
Foghrye4 |
<nrzkt> I need to learn how to use bissect first. |
15:06 |
nrzkt |
find the correct commit |
15:06 |
nrzkt |
git bissect |
15:07 |
|
blaze joined #minetest-dev |
15:08 |
|
STHGOM joined #minetest-dev |
15:09 |
Foghrye4 |
foghrye4foghrye4-GA-A75-D3H:~/minetest-branches/freshiest/minetest$ git bisect start 067766e 1b45086 |
15:09 |
Foghrye4 |
foghrye4foghrye4-GA-A75-D3H:~/minetest-branches/freshiest/minetest$ cmake . -DCMAKE_BUILD_TYPE=Debug -DRUN_IN_PLACE=TRUE |
15:09 |
Foghrye4 |
Am i doing it right? |
15:13 |
Foghrye4 |
Probably no. |
15:13 |
nrzkt |
cmake command isn't useful if you already done it, just rebuild and if works git bissect good or git bissect bad if not |
15:15 |
Krock |
nrzkt, it's "bisect" :) |
15:17 |
Foghrye4 |
foghrye4foghrye4-GA-A75-D3H:~/minetest-branches/freshiest/minetest$ git bisect good 067766eec213918b6cb5b2533d0c78eceb3949ec |
15:17 |
Foghrye4 |
fatal: Needed a single revision |
15:17 |
Foghrye4 |
Bad rev input: 067766eec213918b6cb5b2533d0c78eceb3949ec |
15:17 |
Foghrye4 |
WTF? |
15:17 |
Foghrye4 |
What should I input? |
15:20 |
|
KaadmY joined #minetest-dev |
15:20 |
nrzkt |
you don't need to set commit id |
15:21 |
nrzkt |
https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git |
15:27 |
Foghrye4 |
So, 'git bisect good stable-0.4' ? |
15:27 |
nrzkt |
don't set argument after good bad |
15:27 |
nrzkt |
no arg = current commit |
15:30 |
Foghrye4 |
So, you tell me I should go back to certain commit first and then 'git bisect good'? How I do so? |
15:30 |
nrzkt |
after start, git checkout bissection, compile, test, tell him if it's good or not |
15:30 |
nrzkt |
then, after good/bad, new checkout, compile ... etc |
15:31 |
Foghrye4 |
git checkout bissection |
15:31 |
Foghrye4 |
error: pathspec 'bissection' did not match any file(s) known to git. |
15:31 |
nrzkt |
no ! |
15:31 |
nrzkt |
don't checkout yourself |
15:31 |
nrzkt |
git do it for you |
15:32 |
nrzkt |
git bisect start => make => test => good/bad => make test => good/bad => tec |
15:32 |
nrzkt |
etc* |
15:33 |
nrzkt |
then, the assertion can occur if: active object was added to environment or child object with (name = LocalPlayer name && m_is_player == true) |
15:33 |
nrzkt |
i think the problem is with child objects, incorrect data was sent to client |
15:35 |
Foghrye4 |
git bisect visualize |
15:35 |
Foghrye4 |
You need to give me at least one good and one bad revision. |
15:35 |
Foghrye4 |
I think it tells me something. |
15:35 |
nrzkt |
https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git |
15:35 |
nrzkt |
look at this tutorial |
15:36 |
Foghrye4 |
Yes, i read it whole. And it tells, i need to set 'git bisect good <something>' first. |
15:37 |
nrzkt |
no |
15:37 |
nrzkt |
yes |
15:37 |
nrzkt |
git bisect start / git bisect bad / git bisect good <good-commit-id> |
15:37 |
nrzkt |
it's the process init |
15:37 |
_Megaf |
so, I need to recompile the whole thing to change from -DRUN_IN_PLACE=0 to -DRUN_IN_PLACE=1 |
15:37 |
_Megaf |
interesting... |
15:37 |
nrzkt |
after you don't need to set commit ids anymore |
15:38 |
Foghrye4 |
commit-id!=sha1 TRUE? |
15:38 |
_Megaf |
can we have a flag to tell the game where the data is located? ./minetest --gamedata=./ ? |
15:38 |
nrzkt |
commit id = the sha 1 |
15:39 |
sfan5 |
_Megaf: run_in_place doesnot than just change the location where you look for game data |
15:39 |
sfan5 |
s/doesnot/does more/ |
15:39 |
_Megaf |
s/game/engine |
15:40 |
_Megaf |
engine files, like the directory builtin |
15:43 |
_Megaf |
just got this error "2016-10-09 16:43:12: ERROR[Main]: No future without mainmenu" |
15:43 |
_Megaf |
Very cool error message actually :) |
15:44 |
_Megaf |
(Not a BUG) |
15:45 |
|
hmmmm joined #minetest-dev |
16:04 |
red-001 |
_Megaf I have seen that error message too many times |
16:05 |
_Megaf |
red-001: so you were messing with things inside builtin |
16:06 |
red-001 |
yeah |
16:18 |
Foghrye4 |
Hey, nrzkt, are you here? I know, what i did wrong. I cloned repository with "--depth 1". Thats why bisect did not get SHA1 as parameter. |
16:18 |
red-001 |
whats the new way of dectecting if enter was pressed? |
16:18 |
red-001 |
^ rubenwardy |
16:19 |
rubenwardy |
same as before, fields.key_enter |
16:19 |
rubenwardy |
just now if you press enter in a field, fields.key_enter_field is sent as well with the name of the field |
16:20 |
rubenwardy |
and there's also field_close_on_enter[name;enabled_bool] which you can use to disable the default behaviour of closing when enter is pressed |
16:41 |
nrzkt |
Foghrye4, i see, maybe now you should find the problematic commit :) |
16:42 |
|
ElectronLibre joined #minetest-dev |
16:42 |
Foghrye4 |
nrzkt, bissect tell me its 9978d07, but i think its ad163ee |
16:42 |
nrzkt |
what is the output ? |
16:43 |
nrzkt |
yes i think it's ad163ee because 9978d07 is a pure lua non related change |
16:43 |
nrzkt |
you should not call initialize there in fact |
16:44 |
nrzkt |
initialize iscalled by addActiveObject, doing it manually will trigger a CAO reinit, i think it's what triggers the bug you mentionned |
16:44 |
Foghrye4 |
nrzkt, I will run it one more time. |
16:44 |
Foghrye4 |
foghrye4foghrye4-GA-A75-D3H:~/minetest-branches/freshiest/minetest$ git bisect good |
16:44 |
Foghrye4 |
ad163ee5c3f7d6ca31e0add052fb76466a9bfcc8 is the first bad commit |
16:44 |
Foghrye4 |
commit ad163ee5c3f7d6ca31e0add052fb76466a9bfcc8 |
16:44 |
Foghrye4 |
Author: Foghrye4 <foghrye4gmail.com> |
16:44 |
Foghrye4 |
Date: Sat Oct 8 16:51:25 2016 +0400 |
16:44 |
Foghrye4 |
Prevent attached models from disappearing during parent reload (#4128) |
16:44 |
Foghrye4 |
:040000 040000 236196b3819b88db97eaea894965faf4e223e368 6d828be828a403f4d536f30173303a4f4e7884da Msrc |
16:44 |
nrzkt |
you did all good/bad and git point this commit, right ? |
16:45 |
nrzkt |
the problem is : childobj->initialize(deSerializeLongString(is)); |
16:45 |
nrzkt |
you should not use it |
16:45 |
nrzkt |
only ClientEnvironment should do it |
16:46 |
nrzkt |
if PlayerCAO is already inited you will retrigger the init and trigger assertion, which demonstrate bad code usage, it's exactly waht you done there :( |
16:47 |
|
twoelk joined #minetest-dev |
16:48 |
Foghrye4 |
If you can't remove this commit without disturbing others, please comment this line. I will think about problem. |
16:51 |
nrzkt |
this is not the wrong way, can you open a blocker issue referencing the problem ? |
16:52 |
Foghrye4 |
I can open issue. |
16:58 |
Foghrye4 |
nrzkt, done https://github.com/minetest/minetest/issues/4610 |
17:12 |
|
Darcidride joined #minetest-dev |
17:17 |
|
Darcidride joined #minetest-dev |
17:37 |
Foghrye4 |
Good news, everybody! http://pastebin.com/YBGmX4jD Using this shorten function instead of initialize will fix issue 4610 and still fix dissapearing child models! |
17:38 |
nrzkt |
seems good, then only replace initliaze with refresh in your PR ? |
17:38 |
Foghrye4 |
Yes. But PR is already merged, so i need to start new PR i guess? |
17:39 |
nrzkt |
it's okay for me, using refresh will remove the player->setCAO(this) because it's not in reresh logic |
17:39 |
nrzkt |
yes, please do a new pr and link it with previous, and bug |
17:39 |
nrzkt |
also, i see refresh and initialize are very similar functions, can you factorize code ? |
17:40 |
nrzkt |
initialize has only one more thing as it seems |
17:40 |
nrzkt |
oh i see, in fact refresh was done by you |
17:42 |
Foghrye4 |
Factorize? Using "#define blablabla" and stuff? |
17:42 |
nrzkt |
no no |
17:42 |
nrzkt |
don't take my comment , just do the PR we will look for the review after :) |
17:42 |
Foghrye4 |
Ok. |
17:47 |
|
Foghrye4_ joined #minetest-dev |
17:48 |
Foghrye4_ |
Ready: #4611 |
17:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/4611 -- Fix crash on attaching player to entity by Foghrye4 |
17:55 |
red-001 |
could someone review #4472 ? |
17:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/4472 -- Make serverlist searchable. by red-001 |
17:55 |
red-001 |
I rewrote a large part of the code |
17:58 |
|
Player-2 joined #minetest-dev |
18:22 |
|
rubenwardy joined #minetest-dev |
18:29 |
|
paramat joined #minetest-dev |
18:43 |
not_a_bot |
does the dev wiki document the latest stable version? |
18:43 |
not_a_bot |
or latest dev? |
18:44 |
paramat |
heh |
18:45 |
paramat |
it's often very out of date |
18:45 |
paramat |
very unreliable |
18:46 |
ShadowNinja |
Theoretically latest dev, but it isn't really coonsistently used. I'd recommend depending on lua_api.txt instead. |
18:46 |
ShadowNinja |
^ That's also versioned with the project so you know what version it's documenting. |
18:46 |
not_a_bot |
where can I get a dev wiki account? |
18:54 |
ShadowNinja |
not_a_bot: You just have to ask, one sec. |
18:56 |
ShadowNinja |
not_a_bot: PM me Username, Email, and (optional) Real name. |
18:56 |
|
Calinou joined #minetest-dev |
18:59 |
Fixer_ |
hmm~~~, mt have another gameplay annoyance |
19:00 |
Fixer_ |
when you got to much slabs/stairs you can drop through them |
19:00 |
sfan5 |
nah |
19:00 |
sfan5 |
the way worse problem with stairs is the missing smooth lightning |
19:00 |
Fixer_ |
yes |
19:00 |
sfan5 |
*lighting |
19:00 |
Fixer_ |
stairs and everything |
19:00 |
Fixer_ |
nodeboxes, slabs, water |
19:00 |
Fixer_ |
can use white slabs/stairs because they look like shit in presence of nearby torch |
19:00 |
Fixer_ |
can't* |
19:01 |
Fixer_ |
but still, it was fullblock_slab_fullblock higher kind of step and I managed to stuck in it |
19:03 |
Fixer_ |
https://i.imgur.com/u7kzziZ.png example of those slabs |
19:20 |
Fixer_ |
i really miss mob sounds in minetest |
19:21 |
Fixer_ |
no wait, i was wrong, mobs redo has sound, it is just simple mobs |
19:37 |
|
T4im joined #minetest-dev |
19:38 |
paramat |
game#1319 good point i might work on this |
19:38 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1319 -- Disable destroying default:river_water_source by empty bucket |
19:44 |
paramat |
nore sfan5 ShadowNinja any opinions on game#1308 ? |
19:44 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1308 -- TNT Performance Tweaks by tenplus1 |
19:53 |
sfan5 |
paramat: seems useful to me |
19:56 |
paramat |
the controversy is over passing 'nodename' instead of 'node' |
19:56 |
T4im |
or doing any api change at all for premature optimization :) |
19:57 |
T4im |
not sure it's that important to upset sofar over; there are more important things to upset him about |
19:57 |
T4im |
ok, perhaps i could have phrased that a bit differently |
19:58 |
paramat |
i'm still unsure about the nodename/node thing, the other 2 things done are good though |
19:59 |
paramat |
so because i'm unsure i'm asking for more input |
20:00 |
paramat |
perhaps for now the other 2 things can go ahead |
20:02 |
paramat |
i might make a PR for the other 2 things |
20:03 |
ShadowNinja |
nodename is appropriate, there isn't always a full node table available. |
20:04 |
ShadowNinja |
(although I prefer node_name...) |
20:05 |
ShadowNinja |
The TNT pull looks O.K., although the regular nodeupdate may be necessary for the border nodes. |
20:05 |
paramat |
yeah, i thought it worth not bothering with that for performance |
20:06 |
paramat |
the border can still be 1000+ nodes |
20:08 |
paramat |
ok how about we merge it, it can always be tweaked later |
20:08 |
ShadowNinja |
Er: local s = vector.add(pos, {x = x, y = y, z = z}) local r = vector.distance(pos, s) isn't this the same as just the 3D hypot of x, y, z? |
20:10 |
ShadowNinja |
I.E., local r = vector.length({x=x,y=y,z=z}) |
20:11 |
sfan5 |
nice |
20:12 |
sfan5 |
yes that translates to | (pos + (x,y,z)) - pos | |
20:12 |
sfan5 |
which is | (x,y,z) | obviously |
20:18 |
paramat |
yeah |
20:19 |
paramat |
i'll line comment |
20:21 |
|
Darcidride joined #minetest-dev |
20:22 |
paramat |
ninja'd |
20:22 |
ShadowNinja |
sfan5: Why does the master-server guest check need changing? |
20:23 |
red-001 |
some clients call guests players |
20:23 |
sfan5 |
because nobody uses Guest nicks anymore |
20:23 |
red-001 |
e.g Player34762 instead of Guest34762 |
20:26 |
paramat |
i can't see math.hypot in the Lua manual |
20:31 |
paramat |
the hypot stuff is less clear too |
20:32 |
|
troller joined #minetest-dev |
20:36 |
Fixer_ |
pr#3848 who remember this? :} |
20:36 |
Fixer_ |
https://github.com/minetest/minetest/pull/3848 |
20:40 |
|
STHGOM joined #minetest-dev |
20:40 |
|
STHGOM joined #minetest-dev |
20:43 |
ShadowNinja |
sfan5: Do you mean that people are making builds with a modified guest name so that they can get in? |
20:44 |
ShadowNinja |
sfan5: If so, they'll probably just change it again. We have to kill guest nicks once and for all by removing them from the client. |
20:45 |
red-001 |
why hasn't anyone done that yet? |
20:49 |
paramat |
wow 3848 |
20:50 |
paramat |
^ est31 |
20:50 |
paramat |
added to milestone to be considered |
21:08 |
paramat |
red the answer is obvious :] |
21:08 |
|
est31 joined #minetest-dev |
21:09 |
est31 |
ha! ninja'd paramat by reading the IRC logs :) |
21:09 |
paramat |
:] |
21:10 |
est31 |
but yeah sorry I don't really have time for it |
21:10 |
paramat |
ok |
21:24 |
paramat |
sofar game#1285 is updated with your request, +1? |
21:24 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1285 -- Destroy flammable items when in fire or lava by Ferk |
21:29 |
|
Samson1 joined #minetest-dev |
21:32 |
|
rubenwardy joined #minetest-dev |
21:36 |
red-001 |
in what category on the dev wiki should I put HTTPApiTable ? |
21:37 |
red-001 |
objects? |
21:41 |
|
ElectronLibre joined #minetest-dev |
22:03 |
|
est31 joined #minetest-dev |
22:04 |
sfan5 |
est31: how does the zstd code work without unget? |
22:05 |
est31 |
well probably it should do unget at the end |
22:05 |
est31 |
either way, should only happen once per stream |
22:05 |
est31 |
dunno what the zlib code is doing, but unget should not be the bottleneck |
22:06 |
sfan5 |
why not |
22:06 |
est31 |
My guess is its the zstd context creation or something, when the array API is used it may use a static context |
22:07 |
est31 |
read an issue in the zstd repo about the context creation being super slow |
22:07 |
sfan5 |
that's possible |
22:07 |
sfan5 |
have you re-done the benchmarks with the streaming api? |
22:08 |
est31 |
only the unit tests |
22:08 |
sfan5 |
those don't cover the unget requirement |
22:09 |
est31 |
the unit tests scared me off doing any more tests with the streaming API |
22:09 |
est31 |
:) |
22:09 |
|
STHGOM joined #minetest-dev |
22:09 |
est31 |
also, the unit test framework is very bad , you cant run single unit tests |
22:12 |
est31 |
sfan5, https://github.com/facebook/zstd/issues/408 |
22:13 |
sfan5 |
well have you tried creating only once? |
22:14 |
est31 |
no not yet |
22:14 |
sfan5 |
i can probably also do that for brotli |
22:14 |
est31 |
thats what I meant about "fixing" the bug :) |
22:14 |
sfan5 |
yeah but if you do that then your benchmarks can't be compared to anything |
22:14 |
est31 |
sfan5, if you can provide general infrastructure to share a context between multiple compression calls, it would be really great |
22:16 |
est31 |
I could adopt it for zstd |
22:16 |
sfan5 |
first let me prove that your streaming api commit doesn't ork |
22:16 |
sfan5 |
+w |
22:16 |
est31 |
its not doing unget at the end of the stream, thats an obvious bug |
22:18 |
sfan5 |
the fundamental problem in your streaming decompress code is that the stream ends when there's no data left |
22:18 |
sfan5 |
which is a wrong assumption |
22:19 |
est31 |
yes |
22:19 |
est31 |
it needs to do unget |
22:19 |
sfan5 |
2016-10-10 00:19:35: ERROR[Main]: decompressZstd: decompression failed: Context should be init first |
22:19 |
sfan5 |
uh |
22:20 |
est31 |
that means the init call was not called before using the context |
22:20 |
est31 |
does that appear with my code, or have you modified it? |
22:21 |
sfan5 |
your code, no modification |
22:23 |
sfan5 |
hm |
22:23 |
sfan5 |
(de)compress can be called from multiple different threads though |
22:26 |
|
turtleman joined #minetest-dev |
22:28 |
est31 |
mhh |
22:29 |
est31 |
sorry, I have to recompile entire minetest from scratch so trying to reproduce your issue will take a bit time |
22:29 |
est31 |
what exactly were you doing sfan5 ? |
22:29 |
Fixer |
paramat: i wonder if this will go forward some day https://github.com/minetest/minetest/pull/2561 and https://github.com/minetest/minetest/pull/3696 or maybe kind of minecraft kind of mapgen configurator |
22:29 |
sfan5 |
compile, open client, create world, join world |
22:29 |
est31 |
and which commit of my branch the latest one? |
22:29 |
sfan5 |
yes |
22:30 |
paramat |
maybe. as always it's down to dev time |
22:31 |
Fixer |
paramat: another idea, mapgen presets |
22:31 |
paramat |
however, we do now have advanced settings menu |
22:32 |
paramat |
so not high priority |
22:32 |
Fixer |
paramat: with usual stuff like "mega ocean world with few islands", "amplified terrain", "lowered terrain", "swamp", "lava world" + single biome selection to this etcetc |
22:32 |
est31 |
okay I can reproduce it |
22:34 |
sfan5 |
est31: the decompress code is missing half the functionality it should have, shouldn't be hard to reproduce :P |
22:34 |
Fixer |
"endless desert" |
22:34 |
Fixer |
"arctic world" etc |
22:37 |
est31 |
it is calling the init call, thats the weird thing about it |
22:40 |
est31 |
and the init call is actually supposed to set the state at least according to zstd source code |
22:41 |
est31 |
weird weird |
22:42 |
paramat |
game#1320 |
22:42 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1320 -- Bucket: Add 'force-renew' bool to registration by paramat |
22:43 |
paramat |
mapgen presets were an idea hmmmmm had, these can now be in the form of mods, as mods can now alter all mapgen parameters |
22:52 |
est31 |
seems I found the cause |
22:52 |
est31 |
but triggered another bug xD |
23:09 |
est31 |
fixed that one, an triggering new bug |
23:10 |
est31 |
and* |
23:10 |
|
kaeza joined #minetest-dev |
23:36 |
|
yang2003 joined #minetest-dev |
23:51 |
est31 |
sfan5, okay now zstd should work |
23:52 |
est31 |
sfan5, also, the streaming API should be as fast as zlib if the level 2 is use |
23:52 |
est31 |
d |
23:52 |
est31 |
maybe it has different views on how the compression level should look like |
23:52 |
est31 |
dunno |
23:53 |
est31 |
sfan5, either way feel free to do the benchmark for zstd + vanessa's world + streaming api now |
23:54 |
* est31 |
gotta go |