Time |
Nick |
Message |
00:06 |
paramat |
phew complete |
00:56 |
|
paramat left #minetest-dev |
01:15 |
|
kaeza joined #minetest-dev |
01:54 |
|
sloantothebone joined #minetest-dev |
03:11 |
|
AnxiousInfusion joined #minetest-dev |
03:57 |
|
sloantothebone_ joined #minetest-dev |
04:56 |
|
swaaws joined #minetest-dev |
06:03 |
|
Calinou joined #minetest-dev |
06:16 |
|
Hunterz joined #minetest-dev |
06:28 |
|
nrzkt joined #minetest-dev |
07:03 |
|
Darcidride joined #minetest-dev |
07:06 |
|
Darcidride_ joined #minetest-dev |
07:13 |
|
leat joined #minetest-dev |
07:24 |
|
rubenwardy joined #minetest-dev |
08:00 |
|
Yepoleb_ joined #minetest-dev |
08:02 |
|
alket_ joined #minetest-dev |
08:17 |
|
GunshipPenguin joined #minetest-dev |
08:26 |
|
Amaz joined #minetest-dev |
08:31 |
|
bluegreen joined #minetest-dev |
08:37 |
|
Ardonel joined #minetest-dev |
08:37 |
|
kaeza joined #minetest-dev |
08:37 |
|
blaise joined #minetest-dev |
08:37 |
|
selat joined #minetest-dev |
08:37 |
|
ShadowBot joined #minetest-dev |
08:37 |
|
Kray joined #minetest-dev |
08:47 |
TBC_x |
man... single-threaded emerging takes forever |
08:48 |
|
bluegreen joined #minetest-dev |
09:01 |
|
deltib joined #minetest-dev |
09:12 |
|
sfan5 joined #minetest-dev |
09:43 |
|
Darcidride joined #minetest-dev |
09:55 |
|
leat joined #minetest-dev |
10:14 |
|
blaze joined #minetest-dev |
10:15 |
|
twoelk joined #minetest-dev |
10:19 |
|
lag01 joined #minetest-dev |
10:22 |
TBC_x |
TSan warnings printed for server running for over 12 hours http://sprunge.us/FGFP |
10:23 |
est31 |
good old connection.cpp |
10:29 |
|
OldCoder joined #minetest-dev |
10:33 |
|
FR^2 joined #minetest-dev |
10:38 |
twoelk |
just found out that a more recent client seems to have scrambled my account password on a server. after connecting into the old account with a new client I can not connect with an old one, roughly preminimap, anymore |
10:39 |
nrzkt |
twoelk: SRP related |
10:41 |
twoelk |
whatever - just reporting something that might be considered a sort of compatabilty breackage and therefore might be of importance when regarding the naming of the next stable version |
10:46 |
celeron55 |
is there no proper error message for that situation? |
10:46 |
celeron55 |
there should be |
10:47 |
twoelk |
it seems to be once you have decided to use a newer client you cannot go back and use an older because you cannot use the same nick-password set anymore |
10:49 |
twoelk |
this may be of concern when you use different devices to connect to the same account at different times |
10:49 |
VanessaE |
no offense to est31 but SRP needs to be completely disabled (both client and server) by default until stuff like ^^^^ that, and irc_commands compatibility works properly. |
10:57 |
sfan5 |
yeah |
10:58 |
sfan5 |
SRP should be disabled until all problems and issues with it are solved |
11:00 |
nrzkt |
celeron55, no you only have a login failed because a password mismatch |
11:00 |
celeron55 |
that's pretty bad |
11:01 |
TBC_x |
anyone looked into GNU/Hurd bug? https://lists.debian.org/debian-hurd/2014/10/msg00020.html |
11:02 |
TBC_x |
hmm... when I look at the code it looks fixed |
11:03 |
VanessaE |
Hurd still exists? :) |
11:06 |
RealBadAngel |
im about to fix all the fsaa/non tileable textures issues |
11:07 |
RealBadAngel |
question: have we switched to protocol 26 already? |
11:07 |
VanessaE |
a wild RBA appears! |
11:07 |
TBC_x |
probably, yes |
11:07 |
TBC_x |
git log says so |
11:08 |
RealBadAngel |
i was waitin for it |
11:08 |
VanessaE |
RealBadAngel: note that we're in feature freeze now |
11:08 |
RealBadAngel |
thats a bunch of bugfixes |
11:08 |
RealBadAngel |
not a feature |
11:08 |
VanessaE |
I know. |
11:09 |
VanessaE |
just saying you'll have to be extra careful :) |
11:09 |
RealBadAngel |
i know i know, valgrind has to show no more errors after my commits ;) |
11:10 |
VanessaE |
TBC_x: including some of the harder stuff like address and thread sanitizing?\ :) |
11:10 |
TBC_x |
at least address sanitizing |
11:10 |
TBC_x |
thread sanitizing makes the code running single-core |
11:10 |
VanessaE |
otherwise hmmmm will kick your ass ;) |
11:11 |
TBC_x |
and disables OpenGL |
11:11 |
VanessaE |
ok so forget that part :P |
11:11 |
TBC_x |
I pointed out that we should disable minimap radar mode when it is `broken` |
11:12 |
TBC_x |
unless you want to fix it before release |
11:12 |
RealBadAngel |
TBC_x, i will fix it |
11:12 |
TBC_x |
you got six days |
11:12 |
RealBadAngel |
they have deleted too much |
11:12 |
RealBadAngel |
in wild hunt for leaks |
11:13 |
VanessaE |
I suggesting pushing what you have to your own fork now so that others have time to review |
11:13 |
RealBadAngel |
scanner is receiving too few data thx to deleting whatever they thought is not necesary |
11:13 |
VanessaE |
there's really no time for your usual "I'm fixing/polishing and will have it out in some days" |
11:14 |
RealBadAngel |
minimap is broken thx to sanitizing it |
11:14 |
RealBadAngel |
i wont allow minimap in its current state be a part of a release |
11:15 |
RealBadAngel |
there should be a rule: dont understand the code, dont touch |
11:15 |
RealBadAngel |
ask first for christ sake |
11:15 |
TBC_x |
that's bullshit |
11:15 |
RealBadAngel |
no its not |
11:16 |
RealBadAngel |
breaking a funcionality and fixing leaks are two different things |
11:16 |
TBC_x |
introducing `broken` functionality is another |
11:16 |
TBC_x |
and I don't like ho mapper utilizes CPU |
11:16 |
TBC_x |
s/ho/how/ |
11:16 |
RealBadAngel |
for the leaks im sorry. for the functionality im not to blame |
11:17 |
RealBadAngel |
TBC_x, so you would expect some bunch of magic dwarves doing the scans instead of cpu? |
11:17 |
|
Puma_rc joined #minetest-dev |
11:17 |
VanessaE |
strange, I don't see anything wrong with the minimap in HEAD. |
11:18 |
RealBadAngel |
radar mode on surface is broken |
11:18 |
TBC_x |
at first, mapper shouldn't generate minimap blocks for mapblocks that are not in range |
11:18 |
RealBadAngel |
it should look like night vision googles effect |
11:18 |
VanessaE |
yeah I see now. |
11:18 |
RealBadAngel |
TBC_x, mapper doesnt genereate any blocks |
11:18 |
TBC_x |
well... pixels |
11:18 |
RealBadAngel |
no |
11:19 |
VanessaE |
underground there is another issue - visible mapblock borders |
11:19 |
VanessaE |
or rather, chunk borders I think |
11:19 |
RealBadAngel |
whatever is loaded is in the cache |
11:19 |
TBC_x |
yes |
11:19 |
RealBadAngel |
thats not going to change |
11:19 |
TBC_x |
even if it never gets to the screen at all |
11:20 |
RealBadAngel |
you seems to not understand one fundamental rule |
11:20 |
TBC_x |
i listen |
11:20 |
RealBadAngel |
block is minimapped on load or on change only |
11:20 |
RealBadAngel |
so basically once |
11:21 |
RealBadAngel |
factor of calculations needed is reduced by 16 |
11:21 |
RealBadAngel |
its 8,5kk nodes divided by 16 |
11:21 |
RealBadAngel |
to get full scan |
11:22 |
TBC_x |
you don't have to scan the entire universe when you're making a minimap |
11:22 |
RealBadAngel |
ONLY because of that we are able to make it run realtime |
11:22 |
RealBadAngel |
i dont |
11:22 |
RealBadAngel |
i scan the cache selecting visible blocks |
11:23 |
TBC_x |
I don't think that realtime minimap is better than fast minimap |
11:23 |
TBC_x |
well... I want to see your results when you're done with your modifications |
11:23 |
RealBadAngel |
realtime means it have to be fast |
11:23 |
RealBadAngel |
i want to make it even faster |
11:24 |
VanessaE |
RealBadAngel: you need to make your modifications available NOW. |
11:24 |
RealBadAngel |
but not the way you think |
11:24 |
VanessaE |
in your own repo or something |
11:24 |
RealBadAngel |
no |
11:24 |
RealBadAngel |
its a long term goal |
11:24 |
VanessaE |
no |
11:24 |
RealBadAngel |
i need to rewrite whole core |
11:24 |
TBC_x |
too poor someone pushed your minimap to master |
11:24 |
VanessaE |
we don't have time for "long term" here. feature freeze --> release in 6 days. |
11:24 |
RealBadAngel |
TBC_x, its not poor. it is fast already |
11:25 |
RealBadAngel |
on the other hand theres no code that is perfect from the begining |
11:25 |
TBC_x |
you want me to make comparisons? |
11:25 |
RealBadAngel |
moreover it will never be propably |
11:25 |
RealBadAngel |
i just have an idea how to make things faster |
11:25 |
TBC_x |
minecraft minimaps decrease performance just by around 10% |
11:26 |
RealBadAngel |
but thats have nothing to do with general algorithm for scanning |
11:26 |
RealBadAngel |
TBC_x, you must be joking |
11:26 |
RealBadAngel |
i was playing mc |
11:26 |
TBC_x |
well, ok 15% |
11:26 |
RealBadAngel |
on my box minimap caused like 50% fps drop |
11:27 |
TBC_x |
on my box, your minimap caused like 75% fps drop |
11:27 |
RealBadAngel |
on mine theres no visible drop :P |
11:27 |
TBC_x |
too poor you're not developing on an average supported box |
11:28 |
RealBadAngel |
only thing that slows down minimap is not scanning but preparation of textures to be shown |
11:28 |
|
OldCoder joined #minetest-dev |
11:28 |
TBC_x |
and why all textures are so slow anyway? |
11:28 |
RealBadAngel |
TBC_x, im developing on a box thats worth circa 250$ |
11:28 |
RealBadAngel |
dare to call it high end one? |
11:29 |
RealBadAngel |
my new tablet cost me way more than that :P |
11:29 |
TBC_x |
I'm on a box worth of $400 |
11:29 |
TBC_x |
eight years ago |
11:30 |
RealBadAngel |
have you found it while lookin for some burried treasures? |
11:30 |
VanessaE |
RealBadAngel: I'm on a box that cost me $700 (a few years ago) and which is objectively faster than yours, yet as you well know you get better performance than me... so value/cost != speed. |
11:30 |
VanessaE |
(not in minetest anyway) |
11:31 |
TBC_x |
then you should know what I had before this one |
11:31 |
RealBadAngel |
8yrs old computer is worth only throwing away |
11:31 |
TBC_x |
it was Toshiba with 486, 32MB RAM and 4GB HDD |
11:31 |
RealBadAngel |
its way before dinosaurs :P |
11:31 |
VanessaE |
8yrs-old computer is perfectly functional and is what minetest is supposed to be targeted at. |
11:31 |
RealBadAngel |
lol |
11:32 |
RealBadAngel |
sorry but most of what im coding is targeting nowadays effects |
11:32 |
Calinou |
the game can be played without minimap anyway |
11:32 |
RealBadAngel |
ofc |
11:32 |
Calinou |
if performance is too low, just disable it |
11:32 |
VanessaE |
RealBadAngel: that's why you make sure that you have adequate fallbacks |
11:32 |
RealBadAngel |
just dont enable it if box is too slow |
11:32 |
RealBadAngel |
fallback for minimap is to disable it |
11:32 |
Calinou |
also, why not update the minimap less often? |
11:33 |
RealBadAngel |
maybe there should be a setting for it in main menu |
11:33 |
TBC_x |
not acceptable for other people |
11:33 |
Calinou |
wouldn't that reduce resource usage by a lot? |
11:33 |
VanessaE |
I mean in general. there's nothing even remotely "nowadays" about a minimap |
11:33 |
TBC_x |
that's what I was proposing |
11:33 |
VanessaE |
I've seen games on the C64 do that. |
11:33 |
TBC_x |
probably in a wrong way |
11:33 |
Calinou |
Doom had a minimap, VanessaE :P |
11:33 |
Calinou |
very basic one, but then source ports made it textured and such |
11:33 |
VanessaE |
Calinou: case in point. |
11:34 |
TBC_x |
doom minimap was wireframe |
11:34 |
RealBadAngel |
doom didnt have to check 8,500,000 nodes to get single frame :P |
11:34 |
TBC_x |
mt minimap does not either |
11:34 |
RealBadAngel |
well it does 8,500,000 / 16 |
11:34 |
TBC_x |
In what order are you processing the mapblocks? |
11:34 |
RealBadAngel |
thx to the mapblock_mesh trick |
11:35 |
RealBadAngel |
in a column you need to get highest non-air node |
11:36 |
RealBadAngel |
you check cached blocks to get that node |
11:36 |
RealBadAngel |
for each block stored in cache you have relative height and node stored |
11:36 |
TBC_x |
too bad the server don't send mapblocks in such order |
11:36 |
RealBadAngel |
TBC_x, what sending has to do with it? |
11:37 |
RealBadAngel |
its only client side thing |
11:37 |
RealBadAngel |
server is not aware of existence of minimap |
11:37 |
TBC_x |
I know |
11:37 |
RealBadAngel |
so i can respond after you |
11:37 |
RealBadAngel |
bullshit |
11:38 |
TBC_x |
but minimap probably doesn't check whether the opaque mapblocks sits beneath unloaded mapblock |
11:38 |
RealBadAngel |
you havent spent any time to get the logic behind it and yet comment it |
11:38 |
RealBadAngel |
....propably.... |
11:38 |
TBC_x |
I'm just describing what I see is happening |
11:39 |
RealBadAngel |
see the code, then comment it |
11:39 |
RealBadAngel |
you dont get how it works at all, sorry |
11:39 |
RealBadAngel |
if something is not loaded, its not in cache |
11:40 |
TBC_x |
... |
11:40 |
TBC_x |
Just finish your minimap already |
11:41 |
TBC_x |
at least into release-able state |
11:41 |
VanessaE |
TBC_x: what do you mean "opaque-below-unloaded"? you mean like how minetest mapper sometimes shows a lower, stone mapblock where you'd expect grass? |
11:41 |
sfan5 |
<TBC_x> anyone looked into GNU/Hurd bug? https://lists.debian.org/debian-hurd/2014/10/msg00020.html |
11:41 |
|
Amaz joined #minetest-dev |
11:41 |
sfan5 |
hm |
11:41 |
RealBadAngel |
basically i need to move scanning into propably completely new thread |
11:41 |
sfan5 |
wouldn't s/__MACH__/__APPLE__/ make more sense there? |
11:41 |
TBC_x |
VanessaE: yes |
11:41 |
RealBadAngel |
main problem with mapblock_mesh updates is that it is triggered way to often |
11:42 |
RealBadAngel |
client is flooded with mesh updates |
11:42 |
VanessaE |
TBC_x: well honestly I don't see a problem there, since the client can't force the missing block to be loaded. |
11:42 |
TBC_x |
then you shouldn't depend on that RBA |
11:42 |
VanessaE |
TBC_x: are you suggesting that the entire column below the not-yet-loaded part just not be added to the minimap image? |
11:42 |
RealBadAngel |
TBC_x, frankly that was c55 idea |
11:43 |
RealBadAngel |
i didnt realized how much often is mesh update thread called |
11:43 |
TBC_x |
well, now you see how it runs in practice |
11:43 |
RealBadAngel |
on modern pcs, good enough |
11:44 |
RealBadAngel |
having 60fps usually with all the gfx settings on, and minimap is quite good |
11:44 |
TBC_x |
VanessaE: partly, yes |
11:45 |
RealBadAngel |
but anyway, i will make that code faster |
11:45 |
VanessaE |
RealBadAngel: again, there's NO time for long-term stuff. you have to fix and push your code to your repo right away or you will miss the release |
11:45 |
RealBadAngel |
but please dont push me to do it in a few days. i had a break lately, because of my health |
11:46 |
RealBadAngel |
just need some time to finish it |
11:46 |
TBC_x |
I thought that in master are allowed only finished features |
11:46 |
RealBadAngel |
it is finished |
11:47 |
VanessaE |
TBC_x: at this point yes, but generally apparently not :) |
11:47 |
RealBadAngel |
but it doesnt mean it cannot be made faster |
11:47 |
RealBadAngel |
but its not polishing a piece of code |
11:47 |
RealBadAngel |
its rewritting some core parts of it |
11:47 |
TBC_x |
RBA: Go search trash cans for a piece of hardware that you can test the minimap on |
11:47 |
RealBadAngel |
lol |
11:48 |
RealBadAngel |
go play that mc again and check of different mappers how much they cost |
11:48 |
RealBadAngel |
before complaining mine is too slow |
11:49 |
RealBadAngel |
our is capable of runnin the same frame rate as whole world :P |
11:49 |
VanessaE |
stop comparing to MC |
11:49 |
TBC_x |
I'm comparing minimaps |
11:49 |
VanessaE |
just because A is slower than B doesn't mean B isn't also slow. |
11:50 |
RealBadAngel |
so just disable the fuckin minimap for the release :P |
11:50 |
TBC_x |
mapblock emerging could also use a culling algorithm |
11:50 |
RealBadAngel |
i simply have not enough time before release to make it faster |
11:51 |
RealBadAngel |
and get the sticker "486x ready" for 0.4.13 :P |
11:51 |
VanessaE |
forget about making it faster! |
11:51 |
VanessaE |
just fix whatever bugs it has |
11:51 |
TBC_x |
support for 8086 would suffice |
11:51 |
RealBadAngel |
meanwhile im fixing the bugs |
11:52 |
VanessaE |
faster == feature. |
11:52 |
RealBadAngel |
fsaa broken many things |
11:52 |
TBC_x |
fix bugs, prepare for release, then make it god damn faster |
11:52 |
VanessaE |
TBC_x: echo...echo...echo... ;) |
11:52 |
RealBadAngel |
idk yet it will be faster. i just believe it will be |
11:52 |
TBC_x |
just setting up RBA's TODO list |
11:53 |
RealBadAngel |
what i know theres shitload of things to change |
11:53 |
RealBadAngel |
mostly not related to minimap |
11:53 |
RealBadAngel |
but bounded to FPS |
11:54 |
RealBadAngel |
point is all those changes are effecting how the game overall feels |
11:55 |
RealBadAngel |
"luckily" im coding VISIBLE changes, so im the boy to kick his ass when fps drops |
11:55 |
TBC_x |
I think I already mentioned what milestones for the next release should be |
11:55 |
|
Puma_rc joined #minetest-dev |
11:55 |
TBC_x |
if it is either 0.5.0 or 0.4.14 |
11:56 |
RealBadAngel |
i can understand kicks when i screw something, like leaks. but not when im adding functionality that requires cpu or gpu power to work |
11:56 |
RealBadAngel |
got trashcan pc? just turn them off for christ sake |
11:56 |
RealBadAngel |
or buy yourself new box |
11:57 |
TBC_x |
If I do that I can't afford food |
11:57 |
TBC_x |
hmm |
11:57 |
TBC_x |
screw food |
11:57 |
RealBadAngel |
keeping compability with 9 yrs old standards is pain in the ass |
11:57 |
RealBadAngel |
see opengl 2.1 |
11:57 |
TBC_x |
opengl 2.1 is ok |
11:58 |
RealBadAngel |
no its not |
11:58 |
RealBadAngel |
its a museum |
11:58 |
TBC_x |
opengl 1.x is not |
11:58 |
RealBadAngel |
nothing more than lighting and waving will be supported for <3.0 |
11:58 |
RealBadAngel |
instructions pipeline is too short in 2.1 |
11:58 |
TBC_x |
I don't care about reflections and stuff |
11:59 |
RealBadAngel |
even parallax wont work there |
11:59 |
RealBadAngel |
reflections? forget bout it |
11:59 |
TBC_x |
tesselation on 16x16 is creepy |
12:00 |
RealBadAngel |
such old gpus are simply not capable to have more than 512 instructions per shader |
12:00 |
RealBadAngel |
and loops are unrolled, if you would like to know |
12:01 |
RealBadAngel |
same applies to android devices |
12:01 |
RealBadAngel |
im not sure yet about android watches and fridges :P |
12:01 |
TBC_x |
well If people can't run minetest on their android fridges, we're totally screwed |
12:02 |
TBC_x |
you definitely must support android watches and fridges |
12:03 |
RealBadAngel |
:) |
12:03 |
RealBadAngel |
i will try to do my best ;) |
12:03 |
TBC_x |
well then... stop talking and go work! |
12:04 |
TBC_x |
;) |
12:04 |
TBC_x |
I have at least three data races to fix |
12:08 |
|
blaise joined #minetest-dev |
12:12 |
TBC_x |
what is the purporse of RemoteClient::SetBlockNotSent? |
12:15 |
TBC_x |
and why are two threads touching it? |
12:20 |
|
Gael-de-Sailly joined #minetest-dev |
12:25 |
|
blaze joined #minetest-dev |
12:25 |
TBC_x |
oh, because the second call don't lock a mutex over it |
12:25 |
|
proller joined #minetest-dev |
12:35 |
|
Sketch2 joined #minetest-dev |
12:35 |
Calinou |
<TBC_x> opengl 1.x is not |
12:35 |
Calinou |
<leilol> heresy!!! |
12:36 |
Sketch2 |
there's someone name Faker on Australia Skyblock claiming to be a dev. using a hacked client |
12:37 |
TBC_x |
don't you know banhammers in australia? |
12:38 |
Sketch2 |
he says he's testing for bugs in the game |
12:38 |
TBC_x |
haha |
12:38 |
Sketch2 |
anybody know the admin? |
12:39 |
sfan5 |
!server skyblock |
12:39 |
ShadowBot |
sfan5: server [--{name,address,ip,players,ping,port} <value>] |
12:39 |
sfan5 |
oh right we have ShadowBot here |
12:39 |
sfan5 |
Sketch2: this is something for #minetest, not this channel |
12:39 |
sfan5 |
nothing we can do |
12:41 |
Sketch2 |
sorry sfan5, I kinda realized that after I typed it. I was originally thinking bcause he claimed to be a dev I'd verify in here first |
12:48 |
RealBadAngel |
Sketch2, use a smoked kangooroo to smash that imposter |
12:58 |
RealBadAngel |
Sketch2, but it can be that was cornernote, skyblock creator ;) |
12:59 |
Sketch2 |
lols |
13:00 |
RealBadAngel |
was it cornernote? |
13:02 |
RealBadAngel |
Sketch2, i was also banned from VE's server a few days ago ;) |
13:02 |
RealBadAngel |
was just testing my new tablet lol |
13:05 |
|
H-H-H joined #minetest-dev |
13:09 |
RealBadAngel |
ok. https://imgrush.com/GAIRcVrUFHVf <- after |
13:09 |
RealBadAngel |
https://imgrush.com/w0AgWWov1350.png <- before |
13:09 |
|
johnnyjoy joined #minetest-dev |
13:10 |
RealBadAngel |
i solved fsaa problems, but it requires some lua changes to node defs |
13:10 |
RealBadAngel |
same problem as we had before with grass |
13:11 |
RealBadAngel |
we do need definition in node def saying if tile is tileable |
13:11 |
RealBadAngel |
quite change for mod makers |
13:13 |
RealBadAngel |
code is ready for that, just defs in game shall be updated |
13:19 |
|
Gael-de-Sailly joined #minetest-dev |
13:21 |
|
blaze joined #minetest-dev |
13:37 |
TBC_x |
why can't this be for all plantlikes? |
13:37 |
nrzkt |
RealBadAngel i want to run minetest on my TI-82, can you fix your minimap please |
13:37 |
Sketch2 |
that's great |
13:37 |
TBC_x |
default |
13:39 |
RealBadAngel |
target is to run it on ZX-81 |
13:41 |
nrzkt |
perfect, thanks :D |
13:41 |
TBC_x |
ClientInterface in clientiface.cpp was not designed to be multithreaded |
13:41 |
RealBadAngel |
https://upload.wikimedia.org/wikipedia/commons/thumb/9/93/ZX81_kit.jpg/220px-ZX81_kit.jpg |
13:42 |
RealBadAngel |
thats a pretty decent piece of hardware |
13:42 |
RealBadAngel |
just twice as old as open gl 2.1 ;) |
13:43 |
RealBadAngel |
nrzkt, https://upload.wikimedia.org/wikipedia/commons/thumb/1/14/Sinclair_ZX81_Setup_PhotoManipped.jpg/1280px-Sinclair_ZX81_Setup_PhotoManipped.jpg |
13:44 |
RealBadAngel |
are you sure our network protocol supports tape recorders? ;) |
13:44 |
TBC_x |
it will get rewritten anyway |
13:46 |
Sketch2 |
I remember my Commodore64 had a 300 baud modem, wonder if that's fast enough to run a server |
13:46 |
TBC_x |
we can then add support for pack mules |
13:46 |
TBC_x |
that carry packets |
13:48 |
Sketch2 |
I'd imagine it'd be possible. what print them out, then scan them back in with OCR when they reach their destination? |
13:49 |
Sketch2 |
wonder what the ping would be on that route |
13:49 |
TBC_x |
we'll need to raise timeout a little |
13:50 |
TBC_x |
if we make a clever mule deserialization, I think we can skip the OCR part |
13:51 |
RealBadAngel |
ive seen c64 running web browser |
13:51 |
TBC_x |
and WebGL |
13:51 |
TBC_x |
;) |
13:51 |
Sketch2 |
They were pretty mean little machines |
13:54 |
RealBadAngel |
and thats why i do want in the future one in |
13:55 |
RealBadAngel |
exactly this one: http://libz80.sourceforge.net/ |
13:56 |
RealBadAngel |
nowadays pcs are able to make 15yrs old computers in a node |
13:56 |
Sketch2 |
no kiddin |
13:56 |
RealBadAngel |
eloraam made 6502 |
13:57 |
RealBadAngel |
i want z80 and cp/m |
13:57 |
RealBadAngel |
*eloraam is creator of RedPower mod for mc |
13:58 |
RealBadAngel |
computers there are fully programmable and able to control logic in the world |
13:58 |
TBC_x |
mt should allow native code mods |
13:58 |
TBC_x |
at least source-compatible |
13:58 |
RealBadAngel |
fully means they are real computers with own IO, RAM and video |
13:59 |
RealBadAngel |
once such lib is merged theres no problem |
14:00 |
RealBadAngel |
z80lib is open source, compatible with us |
14:00 |
Calinou |
native code mods suck |
14:00 |
TBC_x |
gpl not lgpl |
14:00 |
RealBadAngel |
this wont be a mod |
14:00 |
Calinou |
not only it provokes people into making their mods proprietary, they are also a huge pain to make platform-independent |
14:00 |
RealBadAngel |
but a feature |
14:01 |
Calinou |
people should not be taught into trusting random .dll's and .so's |
14:01 |
RealBadAngel |
no |
14:01 |
TBC_x |
have you seen c55's buildat? |
14:01 |
RealBadAngel |
i mean including the sources |
14:01 |
RealBadAngel |
later on you can run whatever z80 soft you like |
14:02 |
VanessaE |
RealBadAngel: I removed that ban when you reported it. |
14:02 |
RealBadAngel |
https://www.youtube.com/watch?v=vb0Q9htsbBI |
14:02 |
RealBadAngel |
VanessaE, i know, thx |
14:03 |
RealBadAngel |
TBC_x, watch that vid |
14:03 |
RealBadAngel |
its quite old |
14:03 |
TBC_x |
i know that, I was playing with RP a lot |
14:03 |
RealBadAngel |
its 6502 and forth interpreter build on top of it |
14:04 |
RealBadAngel |
point is that this forth is an app |
14:04 |
TBC_x |
i know |
14:04 |
RealBadAngel |
for an engine feature |
14:04 |
RealBadAngel |
z80 is lightweight |
14:05 |
RealBadAngel |
as for nowadays cpus |
14:05 |
RealBadAngel |
but can be lotsa fun |
14:06 |
RealBadAngel |
we do lack such features, like wireing and computers |
14:06 |
RealBadAngel |
mods cannot do that properly |
14:06 |
RealBadAngel |
we had nearly perfect circuits PR there |
14:06 |
RealBadAngel |
even c55 said its brilliant |
14:07 |
RealBadAngel |
what happened to it? |
14:07 |
TBC_x |
circuits in minetest_game? |
14:07 |
RealBadAngel |
no |
14:07 |
RealBadAngel |
in core |
14:07 |
RealBadAngel |
no game can handle such thing |
14:07 |
TBC_x |
like support for connections in core? |
14:07 |
RealBadAngel |
not connections |
14:07 |
RealBadAngel |
wires logic |
14:08 |
RealBadAngel |
how could it be you have not seen that PR? |
14:08 |
TBC_x |
core needs generic implementation |
14:08 |
RealBadAngel |
there was one |
14:08 |
RealBadAngel |
fm took it |
14:09 |
RealBadAngel |
guy spent lotsa time on it |
14:09 |
RealBadAngel |
SHAME we havent it merged |
14:10 |
RealBadAngel |
now rebasing stuff propably could take ages |
14:10 |
TBC_x |
we need at least smooth animations, smooth inventory handling and rewrite connection.cpp for next release |
14:12 |
TBC_x |
and smarter node selection box that don't cause mesh updates |
14:12 |
RealBadAngel |
youre all attempting ass side |
14:12 |
RealBadAngel |
while basics are broken you do care bout face lifting :P |
14:13 |
TBC_x |
is there a todo list of things to do? |
14:13 |
RealBadAngel |
before i could get my ideas to work like parallax it took me over a year to get what ive imagined |
14:13 |
RealBadAngel |
after such period you can see results of my work |
14:14 |
RealBadAngel |
what i do plan is always long term |
14:14 |
RealBadAngel |
even if im making stupid mistakes from time to time |
14:15 |
TBC_x |
also... mesh generator needs occlusion culling |
14:25 |
TBC_x |
why server thread calls SetBlocksNotSent? |
14:42 |
|
Amaz joined #minetest-dev |
14:50 |
|
COINTELBRO joined #minetest-dev |
14:50 |
TBC_x |
it is more intertwinned that I expected |
14:58 |
TBC_x |
that's a gordian knot |
14:59 |
|
hmmmm joined #minetest-dev |
15:00 |
|
Hunterz joined #minetest-dev |
15:00 |
TBC_x |
hi hmmmm |
15:05 |
|
blaze joined #minetest-dev |
15:17 |
|
COINTELBRO joined #minetest-dev |
15:19 |
|
sloantothebone joined #minetest-dev |
15:25 |
|
rubenwardy joined #minetest-dev |
15:37 |
|
H-H-H joined #minetest-dev |
15:46 |
hmmmm |
hey |
15:47 |
hmmmm |
looking through the logs |
15:47 |
hmmmm |
dammit est |
15:47 |
hmmmm |
this is exactly why I wanted unit tests added |
15:49 |
hmmmm |
TBC_x: I just looked through your thread sanitizer logs. it seems like shared access of UDPPeer is the only current issue, which we haven't seen because modifications to the UDPPeer list are incredibly incommon network events |
15:50 |
hmmmm |
TBC_x: collecting more crash logs isn't going to help diagnose the actual problem sooner, just change the SharedBuffer to Buffer and be done with it |
15:50 |
hmmmm |
so at least people won't crash |
15:56 |
|
amadin joined #minetest-dev |
15:56 |
amadin |
Please help server crashed every 3-6 hours https://forum.minetest.net/viewtopic.php?f=6&t=12962 |
16:21 |
|
leat joined #minetest-dev |
16:21 |
amadin |
buggest server in the world |
16:42 |
|
twoelk joined #minetest-dev |
16:45 |
|
Gael-de-Sailly joined #minetest-dev |
16:57 |
hmmmm |
hrmm |
16:58 |
hmmmm |
we should've told him to try disabling mods |
16:58 |
hmmmm |
i'm not quite sure how, but it seems like his mod is corrupting Lua's internal state to the point where it has a runtime error attempting to generate a backtrace |
17:09 |
|
lag01 joined #minetest-dev |
17:30 |
|
leat joined #minetest-dev |
17:40 |
|
FR^2 left #minetest-dev |
17:43 |
celeron55 |
in case someone is following the github code of conduct bullshit and their recommendations for projects to have a CoC, here's a good one for us so this doesn't have to discussed at any point: https://github.com/ciafwywcoc/ciafwywcoc/blob/master/CODE_OF_CONDUCT |
17:44 |
sfan5 |
wtfpl for for CoC |
17:44 |
sfan5 |
:D |
17:44 |
celeron55 |
yes; this wins the internet |
17:45 |
sfan5 |
i like this one too: https://github.com/domgetter/NCoC |
17:45 |
COINTELBRO |
nothing cuter than geeks being macho |
17:45 |
celeron55 |
that works too |
17:54 |
|
nrzkt joined #minetest-dev |
17:59 |
|
alket joined #minetest-dev |
18:04 |
|
COINTELBRO joined #minetest-dev |
18:12 |
|
kilbith joined #minetest-dev |
18:24 |
|
luizrpgluiz joined #minetest-dev |
18:34 |
|
twoelk|2 joined #minetest-dev |
18:35 |
|
GunshipPenguin joined #minetest-dev |
18:45 |
|
luizrpgluiz left #minetest-dev |
18:46 |
|
MinetestForFun joined #minetest-dev |
18:52 |
|
twoelk|2 joined #minetest-dev |
18:55 |
|
FR^2 joined #minetest-dev |
19:06 |
TBC_x |
what is code of conduct about anyways? |
19:06 |
Calinou |
"promoting diversity" |
19:06 |
Calinou |
and avoiding harrassment |
19:06 |
COINTELBRO |
basically a way of eliminating people who are shitheads in public without any further discussion |
19:07 |
nrzkt |
where did you see this code of conduct ? |
19:07 |
sfan5 |
<celero​n55> in case someone is following the github code of conduct bullshit and their recommendations for projects to have a CoC, here's a good one for us so this doesn't have to discussed at any point: https://github.com/ciafwywcoc/ciafwywcoc/blob/master/CODE_OF_CONDUCT |
19:08 |
COINTELBRO |
alternatively, a plot by the united nations to steal our guns and with it our freedoms |
19:08 |
sfan5 |
>guns |
19:08 |
sfan5 |
do you live in usa? |
19:08 |
TBC_x |
apperntly |
19:09 |
TBC_x |
ICAN'T SPEEL |
19:09 |
TBC_x |
... |
19:17 |
TBC_x |
I don't feel like having a CODE_OF_CONDUCT file |
19:18 |
TBC_x |
strlen(CODE_OF_CONDUCT) |
19:18 |
TBC_x |
too long |
19:27 |
|
Gael-de-Sailly joined #minetest-dev |
19:29 |
TBC_x |
looks like setBlocksNotSent is causing the heap corruption |
19:31 |
|
COINTELBRO1 joined #minetest-dev |
19:35 |
TBC_x |
how does std::vector<T> copy constructor work? deep copy or shallow copy? |
19:39 |
kahrl |
TBC_x: deep in the sense it invokes the copy constructor for each element |
19:39 |
|
H-H-H joined #minetest-dev |
19:39 |
kahrl |
you can make it shallow by making T a pointer type |
19:40 |
TBC_x |
changing Server::SetBlocksNotSent(std::map<v3s16, MapBlock *>& block) to Server::setBlocksNotSent(std::vector<u16>& clients, MapBlock *>& block) |
19:41 |
TBC_x |
hmm |
19:41 |
TBC_x |
this is inconsistent, type& var or type &var? |
19:42 |
kahrl |
what < is closed by the last >? |
19:43 |
TBC_x |
std::map<v3s16, MapBlock *> &block vs std::map<v3s16, MapBlock *>& block |
19:44 |
kahrl |
doesn't make a difference to me |
19:44 |
TBC_x |
look at & position |
19:44 |
TBC_x |
&-space-variable or space-&-variable |
19:44 |
kahrl |
that's just code style |
19:44 |
TBC_x |
yes |
19:45 |
kahrl |
I thought you were fixing the heap corruption |
19:45 |
TBC_x |
well... yeah |
19:45 |
TBC_x |
but I don't want to mess up code style |
19:45 |
kahrl |
the guidelines recommend space-& |
19:46 |
TBC_x |
ok |
19:46 |
kahrl |
(I personally don't care, not even if it's inconsistent) |
19:47 |
hmmmm |
TBC_x: type &var |
19:47 |
TBC_x |
kk |
19:47 |
hmmmm |
but |
19:47 |
hmmmm |
you don't have to change existing code |
19:47 |
hmmmm |
just don't use non-const references in new code |
19:48 |
hmmmm |
if you're modifying some kind of value, use type *val; |
19:48 |
hmmmm |
if you want to do a zero-copy pass of some kind of value, use const type &val |
19:48 |
hmmmm |
never use "type &val" |
19:48 |
hmmmm |
it's so misleading |
19:48 |
TBC_x |
ok |
19:49 |
hmmmm |
iirc, most other code standards ban non-const reference parameters as well |
19:49 |
hmmmm |
with great reason! |
19:50 |
TBC_x |
hmm... should I avoid method overloading? |
19:51 |
TBC_x |
because I want to rename a method to setBlocksNotSentToAll |
19:51 |
TBC_x |
or just setBlocksNotSentAll |
19:55 |
|
kaeza joined #minetest-dev |
19:55 |
RealBadAngel |
damn, i hate coding changes to tile.cpp it recompiles then all the shit around ;) |
19:57 |
hmmmm |
TBC_x, try to avoid it if you can |
19:57 |
hmmmm |
I don't think it's explicitly prohibited |
20:01 |
TBC_x |
removing ClientInterface::getClientNoEx |
20:02 |
TBC_x |
the mutex in there comes too late |
20:02 |
|
nore joined #minetest-dev |
20:04 |
TBC_x |
damn... the entire thing is wrong |
20:04 |
RealBadAngel |
question: fsaa textures fix for plants requires defining if texture is tileable or not. shall i make plantlike non-tileable by default or mods shall have to define that in nodedefs? |
20:05 |
RealBadAngel |
the second means all the existing nodedefs will have to be changed to get rid of a glitch |
20:05 |
TBC_x |
clients get mutexed, but the whole list does not and clients can be freed at any time while other threads may be working on them |
20:06 |
RealBadAngel |
hmmmm, what do you think? |
20:06 |
TBC_x |
can't there be any default? |
20:07 |
RealBadAngel |
default was tileable |
20:07 |
RealBadAngel |
and when it comes to fsaa or any effect that modifies textures thats not so good |
20:07 |
TBC_x |
what tileable exactly mean? |
20:08 |
RealBadAngel |
that two tiles placed next to each other are tiling seamlessly |
20:08 |
TBC_x |
so, every node using drawtypes is wrong? |
20:09 |
RealBadAngel |
no, the problem is with just some of them |
20:09 |
RealBadAngel |
but all the plants for example |
20:10 |
TBC_x |
can't a drawtype define a default tileability? |
20:10 |
RealBadAngel |
thats what im asking for, but that could create a mess if some of drawtypes will have another defaults |
20:11 |
TBC_x |
what happens when you define all drawtypes nontileable? |
20:11 |
RealBadAngel |
without fsaa, mipmapping and parallax - nothing propably |
20:12 |
|
luizrpgluiz joined #minetest-dev |
20:12 |
RealBadAngel |
but with any of the effects above connections between tileable nodes will be broken |
20:12 |
TBC_x |
then go and take measurements |
20:12 |
RealBadAngel |
i did |
20:12 |
RealBadAngel |
^^ |
20:12 |
TBC_x |
why did you say probably? |
20:13 |
RealBadAngel |
well, forget "propably" ;) |
20:13 |
RealBadAngel |
for sure |
20:13 |
RealBadAngel |
in such case we shall define then which nodes have seamless faces |
20:14 |
RealBadAngel |
and that could be even worse imho |
20:14 |
RealBadAngel |
because most of the nodes are seamless |
20:15 |
RealBadAngel |
http://pastie.org/10330112 |
20:16 |
RealBadAngel |
^^ above shows whats needed to define which face is not seamless - in case of dirt with grass it cannot tile vertically, but can horizontally |
20:17 |
RealBadAngel |
defaults are true - so only one face has to be modified |
20:17 |
RealBadAngel |
erm, one tile - it goes for 4 faces in this case |
20:21 |
TBC_x |
do Server class really span of several files? |
20:29 |
RealBadAngel |
https://imgrush.com/OA94MUbCowIk.png |
20:30 |
RealBadAngel |
jungle sapling has defined flags for its tiles |
20:30 |
RealBadAngel |
so dirt with grass too |
20:32 |
|
alket_ joined #minetest-dev |
20:35 |
RealBadAngel |
ive found a bug while playing with those saplings |
20:36 |
RealBadAngel |
https://imgrush.com/IF7Gb2fTsbBt.png |
20:37 |
RealBadAngel |
accacia tree replaces node below the sapling with trunk node |
20:37 |
TBC_x |
unfortunate for skyblockers |
20:37 |
RealBadAngel |
not sure about other trees, going to check now |
20:37 |
|
luizrpgluiz left #minetest-dev |
20:42 |
|
nore joined #minetest-dev |
20:43 |
TBC_x |
which thread handles server packets? |
20:46 |
TBC_x |
Server and ClientInterface are pretty messed up |
20:46 |
|
werwerwer joined #minetest-dev |
20:49 |
|
crazyR_ joined #minetest-dev |
21:02 |
|
OldCoder joined #minetest-dev |
21:06 |
|
Taoki joined #minetest-dev |
21:08 |
|
dzho joined #minetest-dev |
21:31 |
|
lag01 joined #minetest-dev |
21:36 |
RealBadAngel |
so, only accacia tree is bugged |
21:36 |
RealBadAngel |
rest of the trees seems to be fine |
21:37 |
TBC_x |
I wish I had your problems right now |
21:37 |
RealBadAngel |
this is not mine but paramat's problem rather |
21:38 |
RealBadAngel |
propably the schematic for the tree is wrong |
21:49 |
TBC_x |
it is a problem of whoever the tree mod maintains |
22:04 |
|
GunshipPenguin joined #minetest-dev |
22:15 |
TBC_x |
Thos are my changes so far http://sprunge.us/NfEH |
22:17 |
|
cvtsx joined #minetest-dev |
22:18 |
TBC_x |
and I don't know whether it fixes the problem completely |
22:19 |
TBC_x |
because EmergeThread may get into its way when Server is handling packets |
22:19 |
TBC_x |
fixing that would require a rewrite |
22:19 |
TBC_x |
probably |
22:21 |
|
VanessaE joined #minetest-dev |
22:22 |
TBC_x |
hi VanessaE |
22:22 |
|
sloantothebone joined #minetest-dev |
22:22 |
TBC_x |
got any new crash reports? |
22:23 |
VanessaE |
hey |
22:23 |
VanessaE |
*looks at stats* |
22:23 |
TBC_x |
I think I may have partially fixed the problem |
22:24 |
VanessaE |
I don't see anything in the past 24h |
22:24 |
TBC_x |
partially because to fix it completely it probably will need a rewrite |
22:25 |
VanessaE |
( http://digitalaudioconcepts.com/vanessa/hobbies/minetest/stats.html -- 6am is the scheduled restart. The big spike right after is just routine - either minetestmapper or tar'ing up the downloadable worlds, I forget which) |
22:25 |
VanessaE |
oh yeah? |
22:25 |
TBC_x |
I haven't made a PR yet |
22:25 |
VanessaE |
(er 6am my time, 12:00 noon on the graph) |
22:25 |
TBC_x |
http://sprunge.us/NfEH |
22:25 |
TBC_x |
this is the patch |
22:26 |
VanessaE |
you said "partially".. what's missing? |
22:26 |
TBC_x |
it is a gordian knot |
22:27 |
VanessaE |
heh ok |
22:27 |
VanessaE |
patch applied, recompiling now. |
22:27 |
TBC_x |
the problem is, that packet handler is modifing client data structures directly |
22:28 |
TBC_x |
and emergeThread may step in |
22:28 |
TBC_x |
and trample each other's work |
22:28 |
VanessaE |
ah |
22:28 |
TBC_x |
in an undefined way |
22:29 |
TBC_x |
I said `it may`, because I don't have it in logs and I don't believe it |
22:29 |
TBC_x |
I mean, I don't believe the code |
22:31 |
TBC_x |
I have removed ClientInterface::getClientNoEx because It potentially leaks clients outside of the Interface mutex |
22:31 |
TBC_x |
which is happening anyway with the packet handler code |
22:32 |
TBC_x |
so the problem still persists |
22:32 |
TBC_x |
I just blocked one entry point |
22:32 |
VanessaE |
you know, I think I actually understood that :) |
22:33 |
TBC_x |
I would like to fix the problem once and for all, but given feature freeze won't allow me to do It without very very very nasty hacks |
22:34 |
TBC_x |
and I refuse to be a nasty person |
22:34 |
VanessaE |
well to be fair, |
22:34 |
VanessaE |
you're fixing a bug here, not adding a feature |
22:34 |
VanessaE |
so I'd say it's fair game |
22:34 |
VanessaE |
(the real problem isn't the advent of the freeze, it's more the length of it - time required for testing any fixes_) |
22:35 |
TBC_x |
yeah |
22:35 |
|
proller joined #minetest-dev |
22:35 |
TBC_x |
but I don't know how others will react to refactored code within freeze window |
22:36 |
TBC_x |
on the other side, I don't want to have this bug sitting in the released version |
22:41 |
VanessaE |
well if worse comes to worst, extend the freeze window long enough to iron out any new bugs caused by a refactor, seeing as how you'd need to do that ANYway to fix the original bug |
22:43 |
TBC_x |
also, a RC could be released instead |
22:45 |
VanessaE |
that's a thought |
22:45 |
VanessaE |
we haven't done an RC-alike release since....um.. 0.4.0-d1? |
22:45 |
VanessaE |
maybe once more since then |
22:46 |
kilbith |
no, 0.4.12 had a RC |
22:46 |
kilbith |
https://forum.minetest.net/viewtopic.php?f=18&t=11227 |
22:48 |
VanessaE |
it did? |
22:48 |
VanessaE |
huh. |
22:48 |
VanessaE |
I'd quite forgotten about those builds. |
22:48 |
VanessaE |
still, they weren't actually *tagged* as -rc in the repo were they? |
22:51 |
TBC_x |
does minetest have any vertical content yet? |
22:53 |
TBC_x |
except caves |
22:53 |
VanessaE |
nope. |
22:54 |
VanessaE |
there are mods that add bedrock and some Nether-like region, and a couple that add stuff up in the sky like nyanland and floatlands |
22:54 |
VanessaE |
but nothing in-core or in minetest_game |
22:54 |
VanessaE |
(excuse me, nyancat heaven I think the first was called) |
22:54 |
TBC_x |
I would really welcome something from df universe |
22:54 |
VanessaE |
df? |
22:54 |
TBC_x |
dwarf fortress |
22:54 |
VanessaE |
dwarf? |
22:55 |
VanessaE |
right |
22:55 |
TBC_x |
hmm |
22:56 |
TBC_x |
because I've got heap-use-after-free in my log, I doubt that the patch fixed the problem |
22:56 |
TBC_x |
as I said, it fixed single entry point |
22:56 |
* TBC_x |
is looking at the logs again |
22:57 |
TBC_x |
I've just fixed concurrent write |
22:57 |
TBC_x |
from not-a-packet-handler |
23:00 |
TBC_x |
expanded template parameter is so unhelpful |
23:10 |
TBC_x |
the solution is to remove any RemoteClient *getClient() from ClientInterface |
23:10 |
TBC_x |
because that is not how interfaces work |
23:19 |
TBC_x |
https://github.com/t0suj4/minetest/commit/3449f8df5592f98c115c3884b6ac74a636feb2cd |
23:20 |
TBC_x |
I'm not gonna create a PR from that though |
23:20 |
VanessaE |
should I nuke the previous patch and pull ^^^^ that? |
23:20 |
TBC_x |
it's the same |
23:21 |
TBC_x |
I put it up just for educational purporses |
23:21 |
TBC_x |
:) |
23:22 |
VanessaE |
oh heh, ok |
23:32 |
TBC_x |
ok, lets get hands dirty |
23:32 |
VanessaE |
uh oh. |
23:56 |
TBC_x |
wtf is setting full_block_send_enable_min_time_from_building? |
23:56 |
VanessaE |
an anti-lag measure |
23:57 |
VanessaE |
if a player places a node, wait ^^^^ that amount of time before sending new mapblocks to them |
23:57 |
VanessaE |
or something similar anyway. not sure if that function still does anything now though |
23:58 |
TBC_x |
max_simul_sends_usually is awesome variable name |
23:58 |
VanessaE |
hah |