| Time |
Nick |
Message |
| 00:07 |
|
Piggybear87 joined #minetest-dev |
| 00:07 |
|
Piggybear87 left #minetest-dev |
| 00:11 |
|
sapier joined #minetest-dev |
| 01:03 |
sapier |
hmmmm I don't understand how this code results in user placed nodes to do mud flowing |
| 01:05 |
hmmmm |
sapier, huh? |
| 01:05 |
sapier |
doesn't makeChunk always create a new block based only on seed? |
| 01:06 |
hmmmm |
based off of seed and mapgen parameters |
| 01:06 |
hmmmm |
why worry about that, though? we know the issue is in block unloading |
| 01:06 |
hmmmm |
i took a nap before and I actually dreamt that I was looking for calls to updateTimer |
| 01:06 |
hmmmm |
lol |
| 01:07 |
sapier |
I start to believe it's not the reason |
| 01:07 |
hmmmm |
what? why |
| 01:07 |
sapier |
I'm more about loading the block |
| 01:07 |
hmmmm |
all logic and reason points to the block unloading |
| 01:07 |
sapier |
not only, a block unloaded has to be loaded again too |
| 01:07 |
sapier |
so the error could happen there too |
| 01:08 |
hmmmm |
yeah, but we're clearly seeing blocks that had just been generated getting unloaded. |
| 01:08 |
hmmmm |
that's the problem. |
| 01:08 |
sapier |
thats ONE problem maybe we have more |
| 01:09 |
sapier |
think about following scenario, block is loaded user manipulates that block, it's unloaded ... and on loading the mud flow is aplied to the user modified block |
| 01:09 |
sapier |
because that's what I see, I see my placed nodes to flow |
| 01:09 |
hmmmm |
yes |
| 01:10 |
hmmmm |
that's because that block is inside of a chunk that gets a request to be generated again |
| 01:10 |
sapier |
yes but my data is present |
| 01:10 |
hmmmm |
and it so happens that when it loads, m_generated is false because it wasn't able to get reloaded in finishBlockMake to set that |
| 01:10 |
hmmmm |
your data being present only means it's not a dummy block |
| 01:11 |
sapier |
yes but if it's generated from scratch how can my nodes be still present and flow |
| 01:11 |
hmmmm |
no no no |
| 01:11 |
hmmmm |
you're not understanding |
| 01:11 |
hmmmm |
makeChunk does not always create the same exact result given any block |
| 01:11 |
sapier |
that's why I'm asking |
| 01:12 |
sapier |
I'm not talking about some random variation |
| 01:12 |
hmmmm |
if you give a chunk of already generated land terrain to mapgen v6, it'll re-do all the steps that it had already done |
| 01:12 |
sapier |
oh |
| 01:12 |
hmmmm |
one of the steps, adding mud, involves doing a downward probe to find the ground (after things had been re-added) |
| 01:13 |
hmmmm |
then TO THE GROUND LEVEL IT FOUND it'll add the dirt nodes |
| 01:13 |
hmmmm |
so if the first non-air block it hits is dirt with grass, or maybe a brick block, it'll start adding another dirt node on top of that |
| 01:13 |
sapier |
so we give generated data to mapgen? |
| 01:13 |
hmmmm |
that is the result of giving already-generated map to mapgen |
| 01:14 |
sapier |
why is this even possible? |
| 01:14 |
hmmmm |
i experienced the same problem when I went to make my minecraft classic -> minetest map converter. i wrote the blocks manually to the database but i forgot to set generated = true |
| 01:15 |
hmmmm |
and mapgen v6 kept shitting all over my buildings with mud |
| 01:15 |
hmmmm |
it's possible because base terrain (stone and air) aren't written if the content isn't content_ignore |
| 01:16 |
hmmmm |
however, the mud adding and flowing phase places the blocks on the ground level that it found regardless of the previous content type (air or not) |
| 01:16 |
hmmmm |
luckily for you, this behavior allowed us to find such a horrible issue |
| 01:17 |
sapier |
I'm not as sure as you are we really found it |
| 01:20 |
hmmmm |
if it weren't for the mud adding, you would've never known about this and we'd just wonder why the Android version has such horrible performance and write it off as the hardware sucking, when in fact blocks are getting unloaded and reloaded and regenerated every millisecond |
| 01:22 |
sapier |
true |
| 01:23 |
sapier |
still we don't have any idea why it happens |
| 01:23 |
sapier |
and we don't know what's wrong if this happens ... I'd guess this happens on pc too but there blocks aren't unloaded very often |
| 01:24 |
hmmmm |
well obviously after the first unloading interval the block unloader starts going insane |
| 01:24 |
hmmmm |
so i know where to start looking at least |
| 01:24 |
sapier |
who's supposed to reset the timer? |
| 01:24 |
sapier |
block unloader is correct they really time out |
| 01:25 |
sapier |
but why |
| 01:25 |
hmmmm |
that's the part we still need to figure out! |
| 01:28 |
sapier |
hmm at least reseting that timer may have concurrency issues |
| 01:28 |
hmmmm |
what timer, m_map_timer_and_unload_interval? |
| 01:29 |
sapier |
m_usage_timer in block |
| 01:29 |
hmmmm |
oh |
| 01:29 |
hmmmm |
there are no other threads that write to m_usage_timer though |
| 01:30 |
hmmmm |
that one call is literally the only call that increments the usage timer |
| 01:30 |
sapier |
no I was wrong the lock is just taken five levels above |
| 01:31 |
sapier |
this way of locking is crap you never know what lock is used to do what |
| 01:31 |
hmmmm |
OH |
| 01:31 |
hmmmm |
you're talking about resetUsageTimer |
| 01:32 |
sapier |
yes that's what's causing the block to unload ... at least if I'm not towards completely wrong direction ... which is perfectly possible too |
| 01:33 |
hmmmm |
GetNextBlocks is envlocked iirc |
| 01:33 |
kahrl |
does what you are talking about have anything to do with the comment at the beginning of ServerEnvironment::activateBlock? |
| 01:34 |
hmmmm |
lol what |
| 01:35 |
sapier |
hmm nanoseconds ... on what machine? |
| 01:36 |
hmmmm |
I don't understand that comment... the block unloading is envlocked as well as anything that calls activateBlock |
| 01:36 |
kahrl |
is CiaranG around sometimes? |
| 01:37 |
sapier |
haven't seem him for a while |
| 01:40 |
sapier |
maybe the locks in emerge are to small |
| 01:40 |
hmmmm |
they're not |
| 01:40 |
hmmmm |
they're perfectly where they should be |
| 01:42 |
hmmmm |
I think it would be a smarter design to add the finished blocks straight to map instead of doing it in initBlockMake |
| 01:45 |
hmmmm |
sapier, to confirm the issue, at least, you should enclose everything inside of the try statement in emergethread in an envlock |
| 01:45 |
hmmmm |
that should in theory fix the bug |
| 01:45 |
hmmmm |
(but it's not a solution) |
| 01:47 |
sapier |
map.cpp L2310 that 3d loop we should be able to get all blocks there shouldn't we? |
| 01:48 |
hmmmm |
yes, if the second parameter were true |
| 01:49 |
sapier |
ohh ok |
| 01:49 |
hmmmm |
I really dislike how it's been overridden by ServerMap and has a second boolean parameter with a completely different meaning |
| 01:51 |
hmmmm |
if you change that to true, then in theory you should start seeing a lot of blocks popping up with CONTENT_IGNORE rather than blocks covered with mud 8) |
| 01:51 |
sapier |
using try catch block for lock isn't a good idea :-/ causes deadlock |
| 01:51 |
hmmmm |
that loop is pretty stupid and it shouldn't be there, but it is because apparently this problem has been around a while there blocks suddenly start falling out of the sky and get unloaded before finishing the make |
| 01:51 |
hmmmm |
oh |
| 01:52 |
hmmmm |
you obviously need to remove the other cases where envlock is done |
| 01:52 |
hmmmm |
or make it into a recursive mutex |
| 01:53 |
sapier |
hopefully those functions taking the lock aren't called by someone else |
| 01:53 |
hmmmm |
they aren't. they are separate functions for code clarity |
| 01:54 |
hmmmm |
in any case, recursive pthread mutexes for JMutex has been added to my wishlist (windows mutexes are already recursive by default) |
| 01:55 |
sapier |
where I work we've got a saying if you need recursive mutexes you're just to lazy to do it correct ;) |
| 01:56 |
hmmmm |
or you're interested in modular code where you don't need to worry about who holds a lock where |
| 01:57 |
sapier |
usually a big lock is already a mistake |
| 01:57 |
hmmmm |
talk is cheap, show me the mapblock transaction code! |
| 01:58 |
sapier |
hmmmm I don't need to write minetest on my own ;-) |
| 01:58 |
hmmmm |
heh |
| 01:59 |
sapier |
I'll gladly leave some parts for others ;-) |
| 02:01 |
sapier |
ok it's time to get some sleep this is not gonna give any results tonight (at least not by me) |
| 02:01 |
|
sapier left #minetest-dev |
| 02:01 |
hmmmm |
b-b-b-ut you're the only one who has an android setup :( |
| 03:11 |
|
kaeza joined #minetest-dev |
| 03:31 |
|
us`0gb joined #minetest-dev |
| 03:36 |
|
OldCoder joined #minetest-dev |
| 03:54 |
|
diemartin joined #minetest-dev |
| 03:54 |
|
OldCoder joined #minetest-dev |
| 04:25 |
|
blaaaaargh joined #minetest-dev |
| 04:32 |
|
CraigyDavi joined #minetest-dev |
| 04:48 |
|
BrandonReese joined #minetest-dev |
| 04:49 |
|
Taoki joined #minetest-dev |
| 04:55 |
|
deltib joined #minetest-dev |
| 06:08 |
|
Taoki[mobile] joined #minetest-dev |
| 06:51 |
|
nore joined #minetest-dev |
| 06:54 |
|
CraigyDavi joined #minetest-dev |
| 07:03 |
|
SmugLeaf joined #minetest-dev |
| 07:03 |
|
SmugLeaf joined #minetest-dev |
| 07:08 |
|
Weedy joined #minetest-dev |
| 07:08 |
|
Weedy joined #minetest-dev |
| 07:11 |
|
Hunterz joined #minetest-dev |
| 07:12 |
|
us`0gb joined #minetest-dev |
| 07:20 |
|
Weedy joined #minetest-dev |
| 07:20 |
|
Weedy joined #minetest-dev |
| 07:26 |
|
grrk-bzzt joined #minetest-dev |
| 07:48 |
|
tomreyn joined #minetest-dev |
| 08:11 |
|
BlockMen joined #minetest-dev |
| 08:23 |
|
LemonLake joined #minetest-dev |
| 08:34 |
|
PenguinDad joined #minetest-dev |
| 08:41 |
|
proller joined #minetest-dev |
| 08:49 |
|
grrk-bzzt joined #minetest-dev |
| 09:05 |
|
grrk-bzzt joined #minetest-dev |
| 09:05 |
|
grrk-bzzt joined #minetest-dev |
| 09:14 |
|
PilzAdam joined #minetest-dev |
| 09:14 |
|
sapier joined #minetest-dev |
| 09:22 |
PilzAdam |
sfan5, https://github.com/minetest/minetest/issues/1445 |
| 09:22 |
sfan5 |
not an engine issue |
| 09:22 |
|
Calinou joined #minetest-dev |
| 09:23 |
PilzAdam |
see my comment |
| 09:23 |
sfan5 |
:/ |
| 09:24 |
sfan5 |
so you want the server to check for all of the ActiveObjects in the sourrounding blocks whether one of them is attached to the removed ActiveObject? |
| 09:25 |
|
Calinou joined #minetest-dev |
| 09:25 |
sfan5 |
^ PilzAdam |
| 09:25 |
PilzAdam |
how did it work in 0.4.9? |
| 09:25 |
sfan5 |
dunno |
| 09:26 |
PilzAdam |
also https://github.com/minetest/minetest/issues/1158 |
| 09:26 |
|
Calinou joined #minetest-dev |
| 09:27 |
sfan5 |
PilzAdam: are you using gcc? gcc sucks |
| 09:27 |
PilzAdam |
you cant close issues because you think a compiler sucks |
| 09:28 |
PilzAdam |
"minetest/po/be/minetest.po: warning: Charset "CHARSET" is not a portable encoding name." <- this can be fixed by just writing UTF-8 in the .po file |
| 09:28 |
sfan5 |
PilzAdam: were you using gcc or not? |
| 09:28 |
PilzAdam |
yes |
| 09:29 |
Calinou |
about compilers… https://github.com/minetest/minetest/issues/143 |
| 09:30 |
PilzAdam |
sapier, https://github.com/minetest/minetest/issues/786#issuecomment-48107058 |
| 09:31 |
sfan5 |
Calinou: gcc isn't any better https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902 |
| 09:33 |
sapier |
can someone check if this was in formspecs as long as they exist? |
| 09:34 |
sapier |
sfan5: Calinou I'm not sure if this was a compiler issue at all cause on android same effect occured on race condition |
| 09:36 |
sapier |
can someone else have a look at those? I'm busy trying to find the mapgen issue right now |
| 09:36 |
|
ImQ009 joined #minetest-dev |
| 09:36 |
PilzAdam |
sapier, I guess the intlGUIEditBox was there for a reason: https://github.com/minetest/minetest/commit/c0e4551249dcc1e09ee09877f136ce12fe359520 |
| 09:37 |
sapier |
no it's been just crap |
| 09:37 |
sapier |
if it had a reason it's been a hack not a solution |
| 09:39 |
PilzAdam |
I'm resetting to the previous commit and check if signs support äöü |
| 09:39 |
sapier |
resetting is not an option |
| 09:39 |
PilzAdam |
just checking if it's really the cause |
| 09:40 |
sapier |
hmm guess we don't have other formspec fields to check |
| 09:40 |
sapier |
well I think you'll find a sane way to fix it ... not that sure about the mapgen/emerge/whatever issue |
| 09:41 |
BlockMen |
for me umlauts work |
| 09:42 |
PilzAdam |
sapier, yep, signs only have umlauts if using the old "hack:sign_text_input" |
| 09:42 |
PilzAdam |
(which uses the intlGUIEditBox) |
| 09:44 |
PilzAdam |
sapier, IMO this should be fixed before the release |
| 09:44 |
PilzAdam |
and I wonder why nobody tested this before |
| 09:44 |
sapier |
well I wonder same about the mapgen bug on android ... seems everyone did test on multiplayer only |
| 09:46 |
sapier |
If I haven't found a solution by about 4 o'clock this afternoon that's gonna be the "solution" for 0.4.10 too ... disable singleplayer |
| 09:46 |
sapier |
on android of course |
| 09:46 |
|
us`0gb joined #minetest-dev |
| 09:47 |
sapier |
PilzAdam could this be another variant of the irrlicht i18n issues we experienced in file select dialog? |
| 09:48 |
PilzAdam |
umm... dunno? |
| 09:49 |
sapier |
we had issues there for hmmm 0.4.8 ... irrlicht did mess up localization so we disabled the local install feature |
| 09:54 |
sapier |
did anyone ever have thread safety in mind on writing that code :-( |
| 09:56 |
|
casimir joined #minetest-dev |
| 10:04 |
Taoki |
Hey. How many hours from now is the release taking place? Curious when new features can start flowing in GIT again :D |
| 10:05 |
Taoki |
Considering there are any waiting to be merged and only on hold due to the feature freeze, of course |
| 10:06 |
PilzAdam |
Taoki, apparently people did not test enough in the feature freeze; and all the bugs that appear now need to be fixed more or less |
| 10:07 |
Taoki |
Ah. Great, a delay :P |
| 10:08 |
Taoki |
I use latest GIT all the time also. Didn't notice any bugs. Depends what mods / features are tested of course |
| 10:23 |
|
vifino joined #minetest-dev |
| 10:31 |
|
lemonlake_ joined #minetest-dev |
| 10:35 |
|
us`0gb joined #minetest-dev |
| 10:44 |
Taoki |
So, no chance of it being released today any more? When is it expected to be released then? |
| 10:45 |
sfan5 |
Taoki: who said it isn't going to get released today? |
| 10:45 |
sapier |
by now nothing is decided |
| 10:45 |
Taoki |
sfan5: Misunderstood PilzAdam then. Thought he meant there are a lot of bugs left so a delay is needed |
| 10:46 |
sapier |
sfan5 we've got major issues so questioning release isn't that far |
| 10:47 |
sfan5 |
the issues have been known for a long time |
| 10:47 |
sfan5 |
it's not like we've only known about them since yesterday |
| 10:49 |
PilzAdam |
sfan5, the attachment bug we talked about earlier; the waving water by RealBadAngel; the broken umlauts in chat |
| 10:49 |
PilzAdam |
thats all bugs we know since yesterday (or today) |
| 10:49 |
sfan5 |
the broken umlauts in chat |
| 10:49 |
sfan5 |
uh no |
| 10:49 |
sfan5 |
we know of that since at least one year |
| 10:50 |
RealBadAngel |
whats the issue with waving water?? |
| 10:50 |
BlockMen |
PilzAdam, the attachment bug is not a blocker |
| 10:50 |
sapier |
yes ... and the android singleplayer issue ... which seems to be a generic issue just happening way more often on android |
| 10:50 |
PilzAdam |
RealBadAngel, that you apply waving to all liquids |
| 10:50 |
PilzAdam |
we talked about that yesterday |
| 10:51 |
BlockMen |
^ that is not even issued on github |
| 10:51 |
PilzAdam |
sfan5, they worked for me until sapier replaced intlGUIEditBox with generic formspec |
| 10:51 |
PilzAdam |
thats like a few weeks ago |
| 10:51 |
BlockMen |
and thats and improvement, not a bug at all |
| 10:51 |
RealBadAngel |
you have waving liquids since months already and you call it an issue just now? |
| 10:51 |
sfan5 |
PilzAdam: I'm pretty sure you've noticed that earlier |
| 10:51 |
PilzAdam |
RealBadAngel, months? was it in the last release? |
| 10:52 |
BlockMen |
^ yes |
| 10:52 |
PilzAdam |
sfan5, the chat? no |
| 10:52 |
|
casimir joined #minetest-dev |
| 10:52 |
BlockMen |
the chat seems to be linux exclusive |
| 10:53 |
PilzAdam |
BlockMen, so what? |
| 10:53 |
BlockMen |
that is called "feedback", PilzAdam |
| 10:53 |
sfan5 |
PilzAdam: then you haven't; but we know that non-ASCII chat is basically broken since >1 year |
| 10:53 |
PilzAdam |
RealBadAngel, still, there needs to be way for me to turn it off, since waving liquids don't make sense in Nodetopia |
| 10:53 |
sapier |
instead of discussing could someone plz try to find it? |
| 10:54 |
PilzAdam |
its not generally an "improvement" |
| 10:54 |
BlockMen |
but not a bug too^ |
| 10:55 |
RealBadAngel |
3 Dec 2013 |
| 10:55 |
sapier |
there is a bug but it's not in chat but in formspec text input handling ... that bug was there before ... but didn't occur on that location by now |
| 10:55 |
BlockMen |
IMO we should release anyway, especially in the sense, that 0.4.9 stable is damn unstable |
| 10:55 |
RealBadAngel |
waving water is here for more than half a year |
| 10:55 |
PilzAdam |
sfan5, I just rechecked it; umlauts in chat are broken since 23 days |
| 10:56 |
BlockMen |
and this are (except mapgen bug) minor issues |
| 10:56 |
PilzAdam |
I dont understand how you can know that for over a year |
| 10:56 |
RealBadAngel |
PilzAdam, and even more, you have pushed that code in |
| 10:56 |
sfan5 |
PilzAdam: https://github.com/minetest/minetest/issues/786 we know that it was broken anyway, even without the formspec change |
| 10:57 |
PilzAdam |
RealBadAngel, maybe I got confused because I always had that setting turned off |
| 10:57 |
sfan5 |
PilzAdam: 2 people (megaf & calinou) reported it being broken before sapier made the formspec change |
| 10:57 |
PilzAdam |
sfan5, it worked with freetype |
| 10:57 |
PenguinDad |
PilzAdam: it didn't work with freetype for me |
| 10:57 |
PilzAdam |
sfan5, there seem to be 2 issues; at least one is caused by sapier's changes |
| 10:58 |
PilzAdam |
the other affects Calinou and Megaf |
| 10:58 |
sapier |
wtf how can a abm be called for a not loaded position |
| 10:59 |
PilzAdam |
sfan5, and the fact that something is broken for some people doesn't justify to break it for more people |
| 11:00 |
RealBadAngel |
PilzAdam, thats not my fault then. You had enough time to notice that feature. Calling that an issue right now is kinda bad joke. |
| 11:00 |
PilzAdam |
RealBadAngel, yes, so we move that to after the release |
| 11:02 |
RealBadAngel |
PilzAdam, ok. i will make an open issue on water and other liquids, because i wanna change that anyway |
| 11:03 |
sapier |
ok what about the mapgen issue ... I'm almost sure it's there in pc version too but results in something different, maybe the occasional crashes we still have |
| 11:03 |
sapier |
I call it mapgen issue knowing it's not exactly mapgen |
| 11:08 |
sfan5 |
incoming commit in 5 minutes: http://sprunge.us/ieRT |
| 11:09 |
sapier |
stop ... why do remove the const? |
| 11:10 |
sapier |
what does clang complain about it? |
| 11:11 |
sfan5 |
it complains because GenericCAO::isPlayer has const and ClientActiveObject::isPlayer doesn't |
| 11:11 |
sfan5 |
if you were to call isPlayer on a GenericCAO casted to ClientActiveObject it would not find the method |
| 11:12 |
sapier |
any reason not to add the const to ClientActiveObject too? |
| 11:12 |
sfan5 |
(or something like that) |
| 11:12 |
sfan5 |
I don't think there is any |
| 11:12 |
sfan5 |
I think I'll do that instead |
| 11:12 |
sapier |
is CLientActiveObject modified by isPlayer? |
| 11:13 |
sapier |
adding is always better then removing |
| 11:13 |
sapier |
reduced risk someone does bad things |
| 11:13 |
sfan5 |
why would it? |
| 11:13 |
sapier |
I don't know ... there are strange things happening in mt sometimes ;-) |
| 11:17 |
sfan5 |
sapier: http://sprunge.us/hFQB better? |
| 11:19 |
sapier |
yes |
| 11:19 |
sfan5 |
ok, pushing |
| 11:22 |
Taoki |
RealBadAngel: Hey. I'm around and available for the next hours, if you want to work on that shader issue now (you said next morning). |
| 11:22 |
Taoki |
Kinda hoping it could make it into 4.10, so other people with ATI cards won't get the flicker |
| 11:24 |
RealBadAngel |
Taoki, i do have code almost rdy, need half an hour or so |
| 11:24 |
Taoki |
oh, ok |
| 11:31 |
sapier |
argh ... we really should fix that damn loging concurrency issue ... it always results in memory curruption |
| 11:53 |
celeron55 |
may i suggest getting the release out ASAP? |
| 11:53 |
celeron55 |
we still have a ton of traffic coming from the reddit post |
| 11:54 |
celeron55 |
and everyone who downloads stuff gets 0.4.9 while they could be getting 0.4.10 |
| 11:54 |
celeron55 |
and by asap i mean "preferably 20 hours ago but that's not possible" |
| 11:55 |
BlockMen |
should i build with leveldb? |
| 11:55 |
celeron55 |
why? |
| 11:55 |
BlockMen |
then ppl an use if they want? |
| 11:55 |
BlockMen |
but idc, im just asking |
| 11:56 |
Taoki |
celeron55: As far as I'm concerned, I only suggest waiting until I fix the shader flickering with RBA. It's possible that shaders cause an annoying flicker on all ATI cards... at least on mine they do |
| 11:56 |
celeron55 |
i think that's not needed, also if you do that, then everyone doing official windows builds would have to do it from now on |
| 11:56 |
Taoki |
But we'll probably figure it out in a few |
| 11:56 |
celeron55 |
which is a useless burden |
| 11:56 |
RealBadAngel |
Taoki, thats not ati issue |
| 11:56 |
BlockMen |
celeron55, k |
| 11:56 |
Taoki |
oh |
| 11:56 |
RealBadAngel |
im on radean card and dont have it |
| 11:56 |
Taoki |
Might be an issue with Mesa / Gallium then. I'm one of the few people who game on free video drivers in Linux :P |
| 11:57 |
RealBadAngel |
it is issue that also nore has, but fix that works for him, apparently doesnt work for you |
| 11:58 |
RealBadAngel |
trying to google something on possible reason |
| 11:58 |
Taoki |
I see. Strange then |
| 12:01 |
nore |
Taoki: I also use free drivers |
| 12:02 |
Taoki |
Ok. That explains why we both had it then |
| 12:02 |
Taoki |
Nvidia or ATI? |
| 12:02 |
nore |
amd == ati, right? |
| 12:02 |
nore |
so yes, ati |
| 12:03 |
nore |
and also using mesa/gallium |
| 12:06 |
RealBadAngel |
what drivers paramat is using? anybody knows? |
| 12:12 |
|
Jordach joined #minetest-dev |
| 12:26 |
Taoki |
nore: Interesting. ATI too and I still get it |
| 12:26 |
Taoki |
After RBA's suggestions so far |
| 12:27 |
VanessaE |
what issue are we talking about exactly? |
| 12:28 |
RealBadAngel |
problems with gl_Normal vector on open source drivers |
| 12:28 |
Taoki |
VanessaE: Apparently, shaders cause surfaces to flicker between dark and bright on the free video driver |
| 12:28 |
sfan5 |
<Taoki> celeron55: As far as I'm concerned, I only suggest waiting until I fix the shader flickering with RBA. It's possible that shaders cause an annoying flicker on all ATI cards... at least on mine they do |
| 12:28 |
sfan5 |
that one |
| 12:28 |
VanessaE |
oh that |
| 12:28 |
VanessaE |
yeah, not an issue on my box |
| 12:28 |
RealBadAngel |
apparently not all ati cards |
| 12:28 |
VanessaE |
AMD+fglrz here |
| 12:29 |
VanessaE |
fglrx* |
| 12:29 |
RealBadAngel |
this seems to happen only on open source ones |
| 12:30 |
Taoki |
Yeah, you won't get it on fglrx |
| 12:30 |
RealBadAngel |
this seems to be related: http://lists.freedesktop.org/archives/mesa-commit/2014-March/048733.html |
| 12:30 |
RealBadAngel |
Despite not correctly converting normal vectors from |
| 12:30 |
RealBadAngel |
+ * GLbyte[3] to float[4], the rendering looks OK. |
| 12:55 |
sfan5 |
I am just running minetest in valgrind |
| 12:56 |
sfan5 |
and my (fullscreen) console overflows with text before the mainmenu even appears |
| 12:56 |
sapier |
if you find anything except "invalid access of length 4" it's worth looking for it |
| 12:57 |
sfan5 |
>invalid access of length 4 |
| 12:57 |
sfan5 |
not a bug or what? |
| 12:57 |
sapier |
it is a bug ... but in valgrind |
| 12:57 |
sfan5 |
suuurrreee |
| 12:58 |
sapier |
I didn't believe that when I was told first too ;-) |
| 12:58 |
sfan5 |
==21522== Invalid read of size 2 |
| 12:58 |
sfan5 |
better? |
| 12:58 |
sfan5 |
it does not even start |
| 12:58 |
sfan5 |
but that is probably the fault of the intel driver being so broken |
| 12:59 |
sfan5 |
oh right.. I have to disable luajit |
| 12:59 |
PilzAdam |
at least there are no memory leaks when starting to the menu and then exiting |
| 13:01 |
sapier |
well known issues are overlapping memcpy in openal too ... but we can't do a lot about this |
| 13:01 |
sfan5 |
fork OpenAL |
| 13:02 |
sfan5 |
RealBadAngel: is this shader bug your fault? https://forum.minetest.net/viewtopic.php?f=21&t=9676 |
| 13:02 |
sapier |
if you wanna do it and sign a contract you're gonna fix all bugs within 4 weeks within the next 10 years ;-) |
| 13:02 |
sfan5 |
pff |
| 13:02 |
sfan5 |
you can't simply fix "all" bugs |
| 13:03 |
sapier |
did I said "simply"? ;-) |
| 13:03 |
sfan5 |
you can't do it non-simply either |
| 13:05 |
sfan5 |
==23182== definitely lost: 2,272 bytes in 18 blocks |
| 13:05 |
sfan5 |
gg |
| 13:08 |
sfan5 |
sapier: I did not find a single "invalid read of size 4" |
| 13:09 |
sapier |
64 bit? |
| 13:09 |
sfan5 |
yes |
| 13:09 |
sapier |
did you find size 8? |
| 13:09 |
sfan5 |
yes |
| 13:09 |
sapier |
there it is |
| 13:10 |
sapier |
native read size is 8 so compiler tries to read 8 bytes even if only a single one is required |
| 13:10 |
sfan5 |
can you link me the bug in valgrind? (I'm sure they have a bug reporting system) |
| 13:10 |
sapier |
so in worst case 7 bytes are out of range while you're actually only interested in first one |
| 13:10 |
sfan5 |
it would be a compiler bug if it would read more than requested |
| 13:10 |
sapier |
no I'm not a human link collection ;-) |
| 13:10 |
sfan5 |
or a bug in the code |
| 13:13 |
RealBadAngel |
sfan5, im not sure what i can see here |
| 13:14 |
RealBadAngel |
it looks like weird textures for me |
| 13:14 |
RealBadAngel |
also he complains about not waving stuff, outdated game? |
| 13:14 |
sapier |
no it's not reading 8 bytes is way faster on those machines as long as only those bytes within allocated memory are used it's perfectly fine to read more |
| 13:16 |
sfan5 |
RealBadAngel: he says "this [shaders not working] is sad, because I would like to have waving plants" in his 2nd post |
| 13:17 |
sfan5 |
sapier: if the compiler does not know whether that memory area is useable, it would be a bug if it were to read 8 bytes |
| 13:17 |
RealBadAngel |
to have waving plants game has to define waving property |
| 13:17 |
RealBadAngel |
enabling shaders option is not enough |
| 13:18 |
sapier |
but copiler knows about intel having 8 bytes access available |
| 13:18 |
sapier |
and amd64 too |
| 13:18 |
sapier |
bus width is 64 bits so there's no way the first byte can be available and one of the others not |
| 13:19 |
sfan5 |
are you telling me my CPU can't read just a single byte? |
| 13:19 |
sapier |
it can but it's horribly slow compared to 64 bit access |
| 13:27 |
sfan5 |
wtf |
| 13:27 |
sfan5 |
WTF |
| 13:28 |
PilzAdam |
sfan5, why do you keep closing this if the warning is not fixed for me? https://github.com/minetest/minetest/issues/1158#issuecomment-48107614 |
| 13:29 |
sfan5 |
why do you keep opening this if the warning is fixed for me? |
| 13:29 |
sfan5 |
how is this not giving a warning? https://github.com/minetest/minetest/blob/master/src/nodedef.cpp#L859 |
| 13:29 |
sfan5 |
getId expects a reference |
| 13:30 |
sapier |
seems to be ok but quite ugly |
| 13:31 |
sfan5 |
you can't pass a value to a reference |
| 13:31 |
PilzAdam |
sfan5, so you think that if a issue is fixed for a single person it can be closed? |
| 13:31 |
sapier |
you can |
| 13:31 |
sfan5 |
PilzAdam: since when are you multiple persons? |
| 13:31 |
PilzAdam |
btw, memory leak fix: https://gist.github.com/PilzAdam/34358b9e90c4cf7e13dc |
| 13:31 |
PilzAdam |
sfan5, what? |
| 13:32 |
sfan5 |
PilzAdam: who else confirmed this is an issue right now (= with latest git)? |
| 13:32 |
PilzAdam |
why do you want someone else to confirm it? |
| 13:33 |
sfan5 |
<PilzAdam> sfan5, so you think that if a issue is fixed for a single person |
| 13:33 |
sfan5 |
"so you think if an issue is not fixed for a single person it can't be closed" |
| 13:34 |
sfan5 |
and this is just a compiler warning |
| 13:34 |
PilzAdam |
yes, an issue can only be closed if its fixed for everyone |
| 13:35 |
sapier |
argh .... MapgenV6 is a perfect example for WHY you SHOULD use m_ prefixes ... did anyone of you ever read a 1000 line function mixing local and member variables? |
| 13:36 |
sapier |
btw MapgenV6 is singlethreaded only never ever try to generate multiple chunks a once |
| 13:37 |
PilzAdam |
sfan5, yes, since compilers are different you can't close issues about them just because you can't reproduce them |
| 13:38 |
sfan5 |
PilzAdam: does that mean we support building with gcc 3.1.2? |
| 13:38 |
PilzAdam |
you need to verify that its fixed for the one who originally opened / reopened the issue |
| 13:38 |
sfan5 |
did you originally report it? no |
| 13:38 |
sapier |
well if that one doesn't anwer within reasonable time you can close it for old age |
| 13:38 |
PilzAdam |
sfan5, read one word more |
| 13:41 |
sfan5 |
<PilzAdam> btw, memory leak fix: https://gist.github.com/PilzAdam/34358b9e90c4cf7e13dc |
| 13:41 |
sfan5 |
^ you can push that |
| 13:50 |
sfan5 |
sapier: I changed an offset and all "invalid read of size {2,8}" disappeared, didn't you say there were a valgrind bug? |
| 13:50 |
sfan5 |
they* |
| 13:51 |
sapier |
what offset? |
| 13:52 |
sfan5 |
of some memset |
| 13:52 |
sapier |
show me |
| 13:52 |
|
Jordach joined #minetest-dev |
| 13:52 |
sfan5 |
I'll do that after I've investigated something |
| 13:53 |
sapier |
so how am I supposed to change my opinion because of you did something and something did happen ;-) |
| 13:59 |
sapier |
but if you really found a way to stop valgrind from running insane that'd be great as it's been a mess to find the real bugs in there |
| 14:00 |
sfan5 |
why is chartowchar_t not using mbstowcs? |
| 14:01 |
sapier |
because mbstowcs isn't available on some architectures and behaves quite different on about any architecture/os |
| 14:02 |
sapier |
if you change something there you've to be very carefully chances to break something are about ... hmm ... 90% ;-) |
| 14:04 |
|
Anchakor_ joined #minetest-dev |
| 14:05 |
sfan5 |
sapier: just correcting the memset seems to have silented the errors |
| 14:05 |
sapier |
which memset? |
| 14:06 |
sfan5 |
sapier: someone did a memset(something, 0, length); without multiplying with sizeof(something) |
| 14:06 |
sfan5 |
and there were sizeof(wchar_t)*1 too many bytes |
| 14:07 |
sfan5 |
s/$/ copied/ |
| 14:07 |
sapier |
can you show me? not sure but this realy seems to be an error |
| 14:08 |
sfan5 |
http://sprunge.us/AZCS?diff |
| 14:08 |
sapier |
why +1? |
| 14:09 |
sfan5 |
size_t l = strlen(str)+1; |
| 14:09 |
sfan5 |
I moved that +1 to the individual ones |
| 14:09 |
sapier |
ah you remove it up |
| 14:09 |
sfan5 |
(except the last one) |
| 14:09 |
sfan5 |
this ensures there is a zero wchar_t at the end |
| 14:10 |
sapier |
hmm that code seems familiar, if it wasn't me I may have been at least last one touching it without noticing |
| 14:13 |
sapier |
but if I read correct that code won't cause bug, it's just a incomplete memset ... which could be removed anyway |
| 14:14 |
sfan5 |
valgrind complained |
| 14:15 |
sapier |
blind trust in tools ... |
| 14:15 |
sapier |
see l is strlen +1 |
| 14:16 |
sapier |
so nstr has one char more then required |
| 14:16 |
|
Piggybear87 joined #minetest-dev |
| 14:16 |
|
Piggybear87 left #minetest-dev |
| 14:16 |
sapier |
memset initilizes first bytes (most likely half of array) to 0 |
| 14:17 |
sapier |
later memcpy copys length * sizeof(wchar) (the exact size of that array) memory |
| 14:17 |
sfan5 |
you don't need to explain |
| 14:18 |
sapier |
I'd hope for someone to explain why valgrind is supposed to complain about that ;-) |
| 14:18 |
sfan5 |
because memcpy might do a read on that uninitalised part |
| 14:18 |
sfan5 |
modern memcpy implementations may use xor for speed |
| 14:18 |
sapier |
why? |
| 14:20 |
sapier |
wait length +1 ... does lenght contain the null terminator or not? |
| 14:20 |
sapier |
according to man page not |
| 14:21 |
sfan5 |
strlen is only the number of chars |
| 14:21 |
sfan5 |
http://sprunge.us/GjLH?diff may I push this? |
| 14:21 |
sapier |
hmm guess for wchar a null terminator is still 1 byte only |
| 14:22 |
sfan5 |
that would make no sense |
| 14:22 |
sfan5 |
1 byte can't be a wchar_t |
| 14:22 |
sfan5 |
and functions couldn't do while(*p != 0) ... |
| 14:22 |
sfan5 |
I don't think someone would design it this complicated |
| 14:23 |
sapier |
ok so this isn't a explanation too |
| 14:23 |
sfan5 |
http://stackoverflow.com/questions/12305868/wchar-ends-with-single-null-byte-or-two-of-them |
| 14:23 |
sfan5 |
>Since a wide string is an array of wide characters, it couldn't even end in an one-byte NUL. |
| 14:23 |
sfan5 |
basically what I said |
| 14:24 |
sapier |
yes that's what I expected too but results in this code should be perfectly fine |
| 14:24 |
sapier |
except of the half memset of course |
| 14:24 |
sfan5 |
soo.. I can push this? |
| 14:25 |
sapier |
if it's the memset only why not fix it by removing it? |
| 14:25 |
sapier |
instead of changing the way to count too |
| 14:25 |
sfan5 |
the memset is needed because of the forced 0 wchar_t |
| 14:26 |
sfan5 |
the memcpy only copies (l) bytes while memset sets (l+1) |
| 14:26 |
|
us`0gb joined #minetest-dev |
| 14:26 |
sapier |
for what reason? the array is as big as thestring? |
| 14:26 |
sfan5 |
no |
| 14:26 |
|
casimir joined #minetest-dev |
| 14:26 |
sfan5 |
the array is the string + terminator |
| 14:26 |
sapier |
then there's a bug anyway ;-) |
| 14:27 |
sapier |
array should be created after creating the intermediate string using it's length |
| 14:27 |
sfan5 |
wide strings are guaranteed to be length*sizeof(wchar_t) |
| 14:27 |
sapier |
then we don't need a memset |
| 14:28 |
sapier |
because wstring is guaranteed to be 0-terminated |
| 14:28 |
sfan5 |
the compiler will optimize it away anyway |
| 14:28 |
sfan5 |
leave the memset alone :( |
| 14:28 |
sapier |
why? |
| 14:28 |
sapier |
we don't need to write things that aren't required, especially if we know it ;-) |
| 14:29 |
sfan5 |
kk, I'll remove it |
| 14:29 |
sapier |
you should check if this fixes it too ;) |
| 14:30 |
celeron55 |
so what is the status of 0.4.10? |
| 14:30 |
sapier |
depends on how problematic you see the mapgen bug |
| 14:31 |
sapier |
for what I know now the reason is there in pc code too but doesn't cause the bug to appear (by now) |
| 14:31 |
celeron55 |
has anyone seen it happen anywhere else than android? |
| 14:31 |
BlockMen |
IMO we should release anyway |
| 14:31 |
sfan5 |
sapier: valgrind is complaining again |
| 14:31 |
BlockMen |
and no, only on android |
| 14:31 |
celeron55 |
then it is not a problem |
| 14:31 |
sfan5 |
^ |
| 14:31 |
sapier |
then we haven't understood what's happening there sfan5 |
| 14:31 |
|
rubenwardy joined #minetest-dev |
| 14:31 |
sfan5 |
maybe it is really a bug in valgrind |
| 14:31 |
celeron55 |
any other large issues? |
| 14:32 |
sapier |
BlockMen: you don't know it's android only .... we just know it happens there way more often |
| 14:32 |
sfan5 |
I'll just push http://sprunge.us/GjLH?diff (the inital thing) |
| 14:32 |
celeron55 |
did the amd open source driver thing end up in something? |
| 14:32 |
sapier |
I hate fixes without having understood what happens |
| 14:32 |
BlockMen |
he asked wheather anyone seen somewhere else |
| 14:32 |
sfan5 |
^ commit incoming right now |
| 14:32 |
BlockMen |
not if it is android only, spaier |
| 14:32 |
BlockMen |
*sapier, sry |
| 14:32 |
sapier |
IT ISNT ANDROID ONLY |
| 14:33 |
BlockMen |
reread what i said |
| 14:33 |
|
Calinou joined #minetest-dev |
| 14:33 |
sapier |
this has been seen on pc too but way les often |
| 14:33 |
|
werwerwer joined #minetest-dev |
| 14:33 |
BlockMen |
issue?^ |
| 14:33 |
celeron55 |
the question is, is it going to get a fix soon |
| 14:33 |
celeron55 |
if not, then we will release |
| 14:33 |
sapier |
obsucure crashes and segfaults |
| 14:33 |
|
vifino joined #minetest-dev |
| 14:34 |
celeron55 |
if it will get a fix, then we will fait for the fix |
| 14:34 |
celeron55 |
wait* |
| 14:34 |
sapier |
ok then I'll stop investigating now and disable singleplayer for android for this release |
| 14:34 |
BlockMen |
you dont know if this is caused by same issue, sapier |
| 14:34 |
BlockMen |
do you? |
| 14:35 |
celeron55 |
fixing this should be top priority after release though |
| 14:35 |
sapier |
so we're going to release because of not having proove a major issue happens on pc too ... great way of doing a release blockmen ;-P |
| 14:35 |
PilzAdam |
celeron55, here is a large issue: https://github.com/minetest/minetest/issues/1445 |
| 14:35 |
celeron55 |
and a new release should happen once it is solved |
| 14:35 |
BlockMen |
what? since when i can decide when and how we do releases? |
| 14:35 |
sapier |
I have no proove true but it's more then likely it's there in pc too |
| 14:37 |
celeron55 |
are people going to fix this stuff if the release is pushed to next weekend or will everyone just go to sleep and we have the exact same situation then? |
| 14:37 |
sapier |
I know about that bug since yesterday |
| 14:37 |
sapier |
I can't guarante to have a fix till next weekend but I'm working at it |
| 14:38 |
celeron55 |
i think we will move the release by one week then |
| 14:38 |
sapier |
I don't know a lot about mapgen code so I'm still trying to find out how it's supposed to work |
| 14:40 |
|
Krock joined #minetest-dev |
| 14:40 |
celeron55 |
i moved the milestone to 2014-07-13 |
| 14:41 |
celeron55 |
as it seems it's impossible to get a release out without major bugs otherwise |
| 14:42 |
BlockMen |
the bugs are smaller than in current "stable" |
| 14:42 |
celeron55 |
how much smaller? |
| 14:43 |
PilzAdam |
BlockMen, current stable was released without notifying everyone and without a feature freeze |
| 14:43 |
BlockMen |
PilzAdam, even worse |
| 14:44 |
BlockMen |
celeron55, i would say it does as randomly as 0.4.9 does (at least for win) |
| 14:44 |
BlockMen |
see the news thread for 0.4.9 about that |
| 14:44 |
celeron55 |
what |
| 14:44 |
celeron55 |
that sentence didn't make any sense |
| 14:45 |
BlockMen |
*doesnt crash as 0.4.9 does randomly |
| 14:45 |
BlockMen |
better? |
| 14:46 |
BlockMen |
well, w/e. i guess one week makes no big difference |
| 14:46 |
celeron55 |
having a map generator bug is quite serious though, and having a reliable way to segfault a client by the server is kind of... just not good |
| 14:46 |
celeron55 |
if these can be gotten rid of in a week, it's a win for everyone |
| 14:47 |
Calinou |
if mods are modified, won't the bug be fixed? by making the mentioned boat undiggable while there's a rider, or by making it detach when dug |
| 14:47 |
BlockMen |
i ment "no big difference" in term of "providing 0.4.9" ;) |
| 14:47 |
BlockMen |
Calinou, its already fixed in next |
| 14:47 |
|
arsdragonfly joined #minetest-dev |
| 14:48 |
celeron55 |
Calinou: it should be possible to segfault anything from mod code; so no |
| 14:48 |
celeron55 |
shouldn't* |
| 14:57 |
|
diemartin joined #minetest-dev |
| 15:03 |
BlockMen |
celeron55, mergin _next also moved to next week i guess? |
| 15:04 |
celeron55 |
i guess it can be done already if people are bored otherwise |
| 15:05 |
celeron55 |
i'm not going to change my mind on that anymore |
| 15:05 |
PilzAdam |
BlockMen, you break my farming_plus mod by doing that, right? |
| 15:05 |
BlockMen |
PilzAdam, i already told you how to easily fix |
| 15:06 |
BlockMen |
you just need to rename your function(s) |
| 15:07 |
PilzAdam |
:-/ |
| 15:13 |
BlockMen |
ok, last change to scream, i will push following in 10 min https://github.com/BlockMen/minetest_game |
| 15:16 |
rubenwardy |
When were boats added to minetest_game? |
| 15:16 |
BlockMen |
they were added to minetest_next and this get merged into _game now |
| 15:17 |
rubenwardy |
ah! |
| 15:17 |
PilzAdam |
BlockMen, have you at least created proper boat models? |
| 15:17 |
BlockMen |
PilzAdam, do you want say you are providing a bad model with your mod? |
| 15:18 |
PilzAdam |
I can imagine better models |
| 15:18 |
BlockMen |
make a pull^ |
| 15:19 |
VanessaE |
I thought the model looked fine, frankly. just the textures need improvement |
| 15:19 |
|
hmmmm joined #minetest-dev |
| 15:24 |
BlockMen |
pushing now |
| 15:35 |
Jordach |
if someone has the blend for said model, i'll improve it into a real boat |
| 15:35 |
hmmmm |
09:22 sfan5 not an engine issue |
| 15:35 |
hmmmm |
WTF |
| 15:35 |
hmmmm |
a segfault is ALWAYS an engine issue |
| 15:35 |
sfan5 |
it was 09:22 |
| 15:35 |
sfan5 |
maybe I didn't have my coffee yet |
| 15:43 |
sapier |
hmmmm new information for mapgen bug, it doesn't require makeChunk to be called twice |
| 15:43 |
hmmmm |
it what? |
| 15:44 |
sapier |
for same area |
| 15:44 |
hmmmm |
that wouldn't make any sense |
| 15:44 |
sapier |
the bug happens even without overlapping areas |
| 15:44 |
hmmmm |
this would be a lot easier if i were able to debug it myself... |
| 15:44 |
hmmmm |
erm anyway |
| 15:44 |
sapier |
I know this doesn't make sense but that's what I see |
| 15:44 |
hmmmm |
so what were the results of extending the envlock to the entire try-catch block and removing the other locks? |
| 15:45 |
|
cenegd joined #minetest-dev |
| 15:45 |
hmmmm |
the two locks you needed to remove were the one in getBlockOrStartGen() and then another one in the scope after makeChunk |
| 15:53 |
sapier |
hmm it's not regenerated ... because it's not generated at all :-( |
| 15:54 |
sapier |
emerge thread is waiting in queue so no deadlock there |
| 15:54 |
hmmmm |
oh oh |
| 15:55 |
hmmmm |
start the lock underneath the queue wait |
| 15:55 |
sapier |
server thread is waiting for lock |
| 15:55 |
hmmmm |
the point of this is to include getBlockOrStartGen, makeChunk, and the block after makeChunk all inside of the same lock |
| 15:55 |
sapier |
ahhh silly me |
| 15:56 |
sapier |
guess I should take a break :-/ |
| 16:01 |
|
Calinou_ joined #minetest-dev |
| 16:02 |
|
rubenwardy joined #minetest-dev |
| 16:04 |
sapier |
hmmmm still happening |
| 16:04 |
hmmmm |
what does the piece of code look like after you modified it? |
| 16:07 |
sapier |
https://gist.github.com/sapier/3db8d19cfac358446294 |
| 16:09 |
|
LemonLake joined #minetest-dev |
| 16:10 |
|
cenegd left #minetest-dev |
| 16:16 |
sapier |
but in this scenario we get double generation again so maybe the lock fixes one bug but not all |
| 16:17 |
hmmmm |
what was the one bug it fixed? |
| 16:17 |
sapier |
split locks? |
| 16:17 |
sapier |
the bug happening without double generation? |
| 16:17 |
hmmmm |
the double generation is the main bug |
| 16:18 |
sapier |
well doesn't matter if there's a main bug if another one causes same to happen ;-) |
| 16:18 |
hmmmm |
let's reason out this result: |
| 16:19 |
hmmmm |
because the map generation was locked from initblockmake (the point at which the MapBlocks were actually created and added to Map), the time in between actual generation, to the setGenerated(true) and the blit back |
| 16:19 |
hmmmm |
it should be logically impossible for you to ever see blocks with block == true but generated == false |
| 16:21 |
hmmmm |
which means that the only error case that should happen would be for the block to be seemingly nonexistant |
| 16:21 |
|
EvergreenTree joined #minetest-dev |
| 16:22 |
hmmmm |
but then it doesn't find it in the db for some reason ... before a block is unloaded, it is saved |
| 16:22 |
sapier |
whttps://gist.github.com/gists this is a full map generation till the bug happened once |
| 16:22 |
sapier |
wait |
| 16:22 |
sapier |
https://gist.github.com/sapier/1ead5784c5bb1c339004 here |
| 16:23 |
|
Megaf joined #minetest-dev |
| 16:24 |
hmmmm |
how is it possible for m_generated to be false |
| 16:24 |
sapier |
there are even two blocks double generated in there first is (1,0,-2) ... first occurance of that blockpos is unload |
| 16:24 |
hmmmm |
there is absolutely no gap in between the time the block is created and generated is set to true |
| 16:24 |
sapier |
have a look at my code I initialize it to false for printing |
| 16:24 |
sapier |
those values are irrelevant if block is false |
| 16:24 |
hmmmm |
yes, but block is clearly true |
| 16:25 |
sapier |
oops |
| 16:25 |
hmmmm |
so anyway I think you're not going to get anywhere by just printfing things and guessing |
| 16:26 |
hmmmm |
perhaps it's time to run it under a debugger |
| 16:26 |
sapier |
btw on unloading the mentioned block "isGenerated" is set to true |
| 16:26 |
hmmmm |
set memory breakpoints on m_generated |
| 16:26 |
sfan5 |
warnings I got while building windows -rc1 builds: 32: http://sprunge.us/fAiN 64: http://sprunge.us/ZfLh |
| 16:26 |
hmmmm |
so it's re-loaded with isGenerated set to false?? |
| 16:26 |
sapier |
memory breakpoints on android? ;-) |
| 16:26 |
sfan5 |
maybe someone cares enough to fix those |
| 16:27 |
sapier |
if they didn't add it this release that's not gonna be available |
| 16:27 |
hmmmm |
humm |
| 16:27 |
hmmmm |
sapier, looking at your log there seems to be an even spread of blocks getting unloaded with isGenerated true and false |
| 16:28 |
hmmmm |
lol |
| 16:28 |
sapier |
yes, have a look at 18:12:13 there the block to be reloaded is unloaded with generated true |
| 16:28 |
hmmmm |
sapier, just for the hell of it, explicitly perform block->setGenerated(true) on the block that is being unloaded |
| 16:29 |
sapier |
and in 18:13:24 it's loaded with isgenerated is false |
| 16:30 |
sapier |
well actually it's not loaded at all as block is false too |
| 16:32 |
sapier |
hmm |
| 16:32 |
hmmmm |
did that fix it? |
| 16:32 |
sapier |
it's not saved if it's not modified |
| 16:32 |
hmmmm |
ahh |
| 16:33 |
sapier |
let's print that info too |
| 16:33 |
hmmmm |
I think the block modification is set in finishBlockMake, the same as setGenerated |
| 16:34 |
hmmmm |
so it's likely the blocks have isGenerated == false are going to have no reason and not get saved |
| 16:34 |
sapier |
yes but I fail to read a block having isGenerated set to true |
| 16:34 |
hmmmm |
hmm |
| 16:41 |
Megaf |
as days goes by more seg faults I get |
| 16:41 |
Megaf |
Irrlicht log: GLSL version: 1.3 |
| 16:41 |
Megaf |
Segmentation fault |
| 16:41 |
Megaf |
client side |
| 16:41 |
Megaf |
segfaults turned to be really often since the merge of android thing |
| 16:41 |
Megaf |
sometimes I will get this |
| 16:41 |
Megaf |
Font size: 8 15 |
| 16:41 |
Megaf |
^\Quit |
| 16:41 |
hmmmm |
that's nice to know.... but do you have any information about them? |
| 16:42 |
Megaf |
nope |
| 16:42 |
hmmmm |
=/ |
| 16:42 |
Megaf |
It happens on a really random manner |
| 16:42 |
hmmmm |
if they're really as common as you say, you should start running minetest in a debugger and taking a backtrace of it. |
| 16:42 |
sapier |
https://gist.github.com/sapier/cf5eac763cf96a15aef1 any idea why I get same node range for different block positions? |
| 16:42 |
Megaf |
but it seems to be more often when alternating tasks/windows or in background |
| 16:43 |
hmmmm |
sapier, wher? |
| 16:43 |
sapier |
18:38:18: <-> 18:40:11: |
| 16:44 |
hmmmm |
both of those are the same block positions |
| 16:44 |
VanessaE |
hmmmm: I didn't take a backtrace of it, but I can give you a reproducible one: start a cryptocoin mining app that runs on your GPU, crank it up fairly high until your desktop starts to "lag" a little, then start minetest and quickly take your focus away from the minetest window to something else. 80% chance Minetest will segfault. |
| 16:44 |
hmmmm |
-2, -2, -2, to 2, 2, 2 |
| 16:44 |
sapier |
but 1,0, -1 isn't 2,0,2 |
| 16:44 |
|
werwerwer_ joined #minetest-dev |
| 16:44 |
Megaf |
Curiosity: Time to compile minetest + minetestserver without redis nor leveldb support real2m24.487s |
| 16:44 |
hmmmm |
oh oh oh |
| 16:45 |
VanessaE |
(I suggest the crypto mining app only because it's easy to heavily-load the GPU and cause Minetest to be slow to start. makes it easy to spot this crash. that's all) |
| 16:45 |
hmmmm |
whoops, sorry, I was looking at blockpos-min and blockpos-max |
| 16:45 |
Megaf |
time to compile it with redis + leveldb support real2m33.429s |
| 16:45 |
hmmmm |
sapier, that's because (1, 0, -1) is contained in the same 5x5x5 block chunk as (2, 0, 2) |
| 16:45 |
sapier |
ok so we're actually looking for chunk regen |
| 16:46 |
hmmmm |
when you go to generate a block, the entire chunk it's being contained in gets generated |
| 16:46 |
hmmmm |
you probably thought that the chunk being generated is centered around pos |
| 16:46 |
hmmmm |
which is false |
| 16:46 |
sapier |
I thought something like that but you know there's a whole in emerge queue |
| 16:47 |
sapier |
if that block is already taken from queue but not completed yet you can request same chunk again |
| 16:47 |
sapier |
even if the blocks aren't unloaded as it happens in our case |
| 16:47 |
hmmmm |
but why does this happen on android only if that's the real problem |
| 16:48 |
sapier |
android is a quite slow device and most likely does way more scheduling |
| 16:48 |
|
tomreyn joined #minetest-dev |
| 16:48 |
sapier |
and it's arm so even memory access may be different |
| 16:49 |
hmmmm |
so you push a block onto the emerge queue |
| 16:49 |
hmmmm |
you find it's not generated |
| 16:49 |
hmmmm |
you go to generate the entire containing chunk |
| 16:49 |
sapier |
ok those blocks are generated but not modified on unloading |
| 16:50 |
hmmmm |
ohhh... |
| 16:51 |
sapier |
doesn't seem like they ever get set modified |
| 16:51 |
hmmmm |
this might be caused by your voxelmainpulator optimization |
| 16:51 |
sapier |
possible but how? |
| 16:51 |
hmmmm |
that i am looking at right now |
| 16:51 |
sapier |
memory result after all is done should be identical |
| 16:56 |
|
zat joined #minetest-dev |
| 16:57 |
hmmmm |
did MapVoxelManipulator use to define an addArea? |
| 16:58 |
sapier |
yes |
| 16:58 |
hmmmm |
er rather emerge |
| 16:58 |
sapier |
I know what you meant |
| 16:58 |
hmmmm |
so you removed MapVoxelManipulator, and then set it to addArea |
| 16:59 |
sapier |
which was used before too |
| 16:59 |
hmmmm |
ManualMapVoxelManipulator doesn't define an addArea though so it falls back to VoxelManipulator::addArea |
| 16:59 |
hmmmm |
which does very different things from what MapVoxelManipulator::emerge did |
| 17:00 |
sapier |
let me check |
| 17:02 |
sapier |
no ManualMapVoxelManipulator had an emerge before just calling addArea from VoxelManipulator |
| 17:02 |
|
rubenwardy joined #minetest-dev |
| 17:03 |
hmmmm |
yeah but addArea does not load map the same way emerge does |
| 17:04 |
sapier |
but emerge in ManualMapVoxelManupulator did just call addArea and didn't do anything else how could this result in an error if it's called directly? |
| 17:04 |
sapier |
not sure if I understand what you wanna tell me :-/ |
| 17:04 |
hmmmm |
oh you're right |
| 17:04 |
hmmmm |
i didn't realize it just called addArea and set flags |
| 17:05 |
hmmmm |
i thought it loaded map |
| 17:05 |
celeron55 |
ManualMapVoxelManupulator is called Manual because it actually doesn't do any of the automation that VoxelManipulator's emerge is allowed to do |
| 17:07 |
celeron55 |
(MapVoxelManipulator did do that) |
| 17:08 |
celeron55 |
the optimization changes there seem insanely error prone 8) |
| 17:08 |
sapier |
well removing MapVoxelManipulator was your idea ;-) |
| 17:10 |
sapier |
ok right now I see blocks getting unloaded that have been generated before and are flagged "not modified" some seconds later those blocks are tried to be loaded and I'm told "not generated" |
| 17:12 |
|
Calinou joined #minetest-dev |
| 17:16 |
Megaf |
Hm, it seems like pipeworks/mesecons are not respecting the max range of active objects, there are a machine working even when theres no one nearby nor online |
| 17:16 |
Megaf |
thats not good |
| 17:16 |
Megaf |
14:16:21: ACTION[ServerThread]: :pipeworks takes stuff from chest at (-41,-2,748) |
| 17:16 |
Megaf |
and I'm at 0,10,0 |
| 17:16 |
VanessaE |
why are you reporting that here? |
| 17:17 |
Megaf |
because is the server who activate them? |
| 17:18 |
celeron55 |
are you using forceloading |
| 17:19 |
Megaf |
kind of |
| 17:19 |
Megaf |
http://paste.debian.net/108400/ |
| 17:19 |
Megaf |
thats my actual minetest.conf |
| 17:19 |
celeron55 |
"kind of" <- WTF? |
| 17:19 |
Megaf |
celeron55; max_forceloaded_blocks = 1 |
| 17:20 |
celeron55 |
just file an issue on github |
| 17:20 |
celeron55 |
nobody cares now |
| 17:20 |
celeron55 |
and include more information than this |
| 17:21 |
Megaf |
disable forceloading, and as soon as the server starts pipeworks will start too |
| 17:21 |
BlockMen |
ShadowNinja, could you check the privs at forum? devs cant post topics on new |
| 17:21 |
BlockMen |
+s |
| 17:22 |
ShadowNinja |
BlockMen: I just fixed that. |
| 17:22 |
BlockMen |
great |
| 17:22 |
hmmmm |
hey sapier, what happens if you move the block->raiseModified and expireDayNightDiff things in finishBlockMake to the loop that sets the blocks as generated |
| 17:22 |
sapier |
setGenerated already sets the modified flag |
| 17:23 |
hmmmm |
ah true |
| 17:23 |
hmmmm |
hmmm |
| 17:23 |
sapier |
question fails saving or loading? |
| 17:23 |
hmmmm |
...check both? |
| 17:23 |
hmmmm |
I'd say saving |
| 17:24 |
hmmmm |
i don't think this behavior should happen if a save fails though |
| 17:25 |
sapier |
hmm what if this isn't permanent error but the block just not loadable on checking if it's present |
| 17:25 |
sapier |
that'd explain why user placed nodes flow |
| 17:28 |
sapier |
great ... sqlite still resets the modified flag if it failed to write the block |
| 17:32 |
celeron55 |
if it fails to write it, chances are it will fail forever and it will just overload a broken filesystem |
| 17:33 |
celeron55 |
there'd need to be a controlled failure state that is reported to the user (there isn't) |
| 17:33 |
sapier |
it's not even considered to be an error and written to infostream only ;-) |
| 17:34 |
sapier |
"hey we couldn't write your map but don't bother that's not a problem" ;-) |
| 17:35 |
celeron55 |
so is the issue that sapier's phone's memory is full or broken |
| 17:35 |
sfan5 |
how about both? |
| 17:35 |
hmmmm |
so wait |
| 17:35 |
hmmmm |
it's confirmed that the map saving is busted? |
| 17:35 |
sapier |
happens on at least 3 different devices ;-) all of them have enough memory left to write tons of debug.txt info ;-) |
| 17:35 |
|
vifino joined #minetest-dev |
| 17:35 |
sapier |
I don't know about sqlite yet |
| 17:36 |
sapier |
I just added debug code there to see it |
| 17:38 |
|
kaeza joined #minetest-dev |
| 17:41 |
sapier |
19:38:48: ERROR[ServerThread]: saveBlock: written=false there it is |
| 17:44 |
hmmmm |
so wait, the save fails, but how does the block get re-requested and found in memory as not-generated |
| 17:45 |
hmmmm |
the isGenerated = false part makes this odd |
| 17:45 |
sapier |
it's not found in memory |
| 17:46 |
sapier |
maybe saving doesn't fail but just tell "please wait" ;-) |
| 17:46 |
hmmmm |
then block should be false |
| 17:46 |
sapier |
let's see what sqlite tells about it |
| 17:46 |
sapier |
it is false |
| 17:47 |
hmmmm |
yeah but some of those blocks have block = true but isgenerated = false |
| 17:47 |
sapier |
true so some piece is still missing |
| 17:48 |
celeron55 |
reference for sqlite's result codes: https://www.sqlite.org/c3ref/c_abort.html |
| 17:48 |
sapier |
SQL logic error or missing database |
| 17:49 |
celeron55 |
are you printing those out there? |
| 17:49 |
sapier |
argh I should have printed the number not sqls error message |
| 17:49 |
sapier |
now I do |
| 17:50 |
sapier |
imho database errors should go to errorstream not infostream |
| 17:51 |
celeron55 |
probably so 8) |
| 17:52 |
sapier |
we would have had that information about 24 hours ago :-( |
| 17:53 |
sapier |
wtf: // TODO this mught not be the right length |
| 18:02 |
sapier |
can someone explain to me why out main database code isn't sure if it's saving the right data ? |
| 18:03 |
celeron55 |
i can't understand why it uses ostringstream::tellp |
| 18:03 |
celeron55 |
it should use tmp.size() |
| 18:04 |
sapier |
I changed it that way but I don't really believe thats the error |
| 18:04 |
celeron55 |
it probably isn't the error |
| 18:06 |
|
casimir joined #minetest-dev |
| 18:06 |
sapier |
errorcode os 1 |
| 18:08 |
celeron55 |
sqlite error 1? |
| 18:09 |
sapier |
yes |
| 18:09 |
sapier |
so most simple SQLITE_ERROR |
| 18:09 |
|
GhostDoge joined #minetest-dev |
| 18:10 |
celeron55 |
https://www.sqlite.org/c3ref/c_abort_rollback.html https://www.sqlite.org/c3ref/extended_result_codes.html |
| 18:10 |
celeron55 |
try this |
| 18:14 |
Krock |
hmm sqlite error? https://github.com/minetest/minetest/issues/1450 |
| 18:15 |
celeron55 |
Krock: that's not an sqlite error, go away |
| 18:15 |
* Krock |
hides |
| 18:15 |
|
Krock left #minetest-dev |
| 18:19 |
sapier |
same |
| 18:21 |
celeron55 |
umm... so it's an sql error? |
| 18:21 |
celeron55 |
can you get that out as some kind of useful readable text |
| 18:22 |
celeron55 |
it looks like this probably cannot happen on PC in practice and is something to do with the android sqlite port or its version or something |
| 18:22 |
celeron55 |
so maybe 0.4.10 today? 8) |
| 18:22 |
sapier |
I hope this way but It's same sqlite code as used on pc |
| 18:22 |
celeron55 |
maybe if it's made to not fuck up things when sqlite fails we can release it |
| 18:23 |
celeron55 |
so that it will just cease to work instead of messing up worlds |
| 18:23 |
celeron55 |
messing up a random user's world is almost the worst thing that can happen and that's why this release is hanging |
| 18:23 |
sapier |
assuming it's really android only the most easy way would be just disable singleplayer on android |
| 18:24 |
celeron55 |
i |
| 18:24 |
celeron55 |
i'm thinking of the case that this may happen on PC in some case |
| 18:24 |
sapier |
if map can't be saved it's not worth releasing |
| 18:24 |
celeron55 |
i'm not concerned of android; for all that matters to me we could just skip android |
| 18:24 |
sapier |
talking about android right now and releasing that feature only |
| 18:25 |
sapier |
hmm If it's sqlite ... I've got leveldb too ... I disabled it to not reduce size ... reenabling it and making it default for android might help |
| 18:25 |
|
Jordach_ joined #minetest-dev |
| 18:34 |
celeron55 |
https://github.com/minetest/minetest/issues/1436 |
| 18:34 |
celeron55 |
wtf is up with this? |
| 18:34 |
celeron55 |
why is it broken |
| 18:35 |
Calinou |
make Android multiplayer-only |
| 18:35 |
|
OldCoder joined #minetest-dev |
| 18:36 |
Calinou |
people could host a server on their PC anyway… also gives higher performance |
| 18:36 |
sapier |
I may have a backup solution |
| 18:36 |
sapier |
I already have leveldb support and just need to enable it |
| 18:36 |
sfan5 |
not using sqlite3 seems to solve many android problems |
| 18:36 |
sapier |
if it works this is a proove for it to be a sqlite issue only too |
| 18:37 |
celeron55 |
does someone know which commit caused #1436? |
| 18:37 |
sfan5 |
probably the shading rework |
| 18:38 |
celeron55 |
this is annoying |
| 18:38 |
celeron55 |
when someone makes something high-end, then low-end breaks |
| 18:38 |
celeron55 |
and the other way around |
| 18:38 |
celeron55 |
why can't people test properly after making things for themselves |
| 18:39 |
sapier |
because there's to many possible build variants we have ;-) |
| 18:39 |
celeron55 |
am i supposed to fix this? |
| 18:40 |
celeron55 |
i don't want to |
| 18:40 |
celeron55 |
but i don't want this to be broken |
| 18:40 |
celeron55 |
where is RBA again |
| 18:40 |
sapier |
prior blaming we should first try to find out what broke it ... I fixed a bug I made but I could still have missed something |
| 18:40 |
celeron55 |
i'm going to ask him for money for the time i use for fixing this |
| 18:42 |
RealBadAngel |
im trying to find a solution for issues with mesa/gallium drivers |
| 18:42 |
RealBadAngel |
but still havent found anything |
| 18:43 |
PilzAdam |
RealBadAngel, haven't we talked about why builtin:item shouldn't use "wielditem" drawtype a while ago? |
| 18:43 |
|
Piggybear87 joined #minetest-dev |
| 18:44 |
|
Piggybear87 left #minetest-dev |
| 18:44 |
Calinou |
I could try each commit one by one |
| 18:44 |
celeron55 |
i'm going to bisect this |
| 18:45 |
celeron55 |
i have the fastest computer anyway for compiling it again and again... |
| 18:45 |
Calinou |
which CPU? ;) |
| 18:45 |
celeron55 |
i7-4800MQ |
| 18:45 |
Calinou |
by the way, things seem OK to me, both with shaders and without shaders, on the latest commit |
| 18:46 |
celeron55 |
disable smooth lighting |
| 18:46 |
Calinou |
that should be as fast as mine |
| 18:46 |
Calinou |
it's off indeed |
| 18:46 |
Calinou |
for testing I use a pure white block (maptools:white) |
| 18:46 |
Calinou |
trying with sand, looks OK too |
| 18:48 |
Calinou |
oh, wait, I was using the “debug†light table; with the default one, the variation is literally invisible |
| 18:48 |
Calinou |
we can conclude: there's variation but it's invisible |
| 18:48 |
celeron55 |
[a0f78659f31abdce973bc6641b5b5a58f2ba9afc] Improved faces shading with and without shaders. |
| 18:48 |
celeron55 |
that breaks it |
| 18:48 |
|
gustav1 joined #minetest-dev |
| 18:49 |
celeron55 |
working: http://c55.me/random/2014-07/mt/tscrot-2014-07-06_21-49-13.png |
| 18:50 |
celeron55 |
broken: http://c55.me/random/2014-07/mt/tscrot-2014-07-06_21-48-50.png |
| 18:50 |
celeron55 |
RealBadAngel: ^ |
| 18:51 |
Calinou |
first one is with debug light table, second one with normal light table: https://mediacru.sh/6f227a55246c |
| 18:51 |
Calinou |
shaders off |
| 18:52 |
celeron55 |
yes, that is too dark |
| 18:52 |
celeron55 |
just as reported https://github.com/minetest/minetest/issues/1436 |
| 18:52 |
sapier |
https://gist.github.com/sapier/a3e0e767771567ebd904 this fixes that mapregen issue for me |
| 18:58 |
celeron55 |
umm... how are shaders without smooth lighting supposed to look like? |
| 18:59 |
celeron55 |
currently the sides of nodes are really dark |
| 19:00 |
celeron55 |
well it has never been tweaked to look good so whatever |
| 19:04 |
celeron55 |
okay so, can we now release despite of the segfault bugs? |
| 19:04 |
celeron55 |
https://github.com/minetest/minetest/issues?milestone=3&state=open |
| 19:04 |
celeron55 |
and the one other blocker |
| 19:04 |
celeron55 |
nobody is interested in fixing them |
| 19:05 |
celeron55 |
do we wait until tomorrow and see if people report something of rc1? |
| 19:05 |
sfan5 |
#1445 could be fixed if the server were to check all SAOs in adjacent MapBlocks whether they are attached to the removed SAO |
| 19:05 |
sapier |
celeron55 prior addition of leveldb modified flag wasn't set back on save error ... and the error was sent to errorstream |
| 19:05 |
sapier |
so how is it supposed to be? |
| 19:06 |
sapier |
ttps://github.com/minetest/minetest/commit/58841ef12f6cba1bb622353c1fcaa0e3c6fb46c9 map.cpp lines 3807... |
| 19:07 |
hmmmm |
so changing the database works |
| 19:07 |
hmmmm |
hmmm |
| 19:07 |
hmmmm |
okay, there are still a number of bugs... |
| 19:08 |
hmmmm |
we need to find the problem with sqlite3 on android, of course, but also block saving and loading needs to be revamped so that this sort of problem can never happen again and it'd be totally obvious that some saves failed |
| 19:09 |
sapier |
h ttps://github.com/minetest/minetest/commit/58841ef12f6cba1bb622353c1fcaa0e3c6fb46c9 map.cpp lines 3807... |
| 19:09 |
sapier |
argh |
| 19:09 |
sapier |
https://github.com/minetest/minetest/commit/58841ef12f6cba1bb622353c1fcaa0e3c6fb46c9 map.cpp lines 3807... |
| 19:09 |
sapier |
it would've been obvious if it wasn't changed on leveldb addition |
| 19:10 |
sapier |
question is shall we change it back? |
| 19:11 |
sapier |
we've got reports about similar behaviour of leveldb ... guess the underlying error (unable to save) is same in those cases |
| 19:12 |
sfan5 |
http://sprunge.us/ATGc?diff can I merge this? (aka does this count as bugfix?) |
| 19:12 |
sfan5 |
s/merge/push/ |
| 19:13 |
sapier |
looks more like maintenance then bugfix |
| 19:13 |
sfan5 |
yes or no? |
| 19:13 |
sapier |
push it but be prepared to have your head cut of if it breaks something ;-) |
| 19:14 |
sfan5 |
the bug is "leveldb backend does not give useful errors", so it's a bugfix |
| 19:14 |
sfan5 |
k, pushed |
| 19:16 |
sapier |
have you pushed it? |
| 19:18 |
sfan5 |
yes |
| 19:18 |
sfan5 |
oshit |
| 19:18 |
sfan5 |
it does not compile |
| 19:19 |
sapier |
lol :-) |
| 19:19 |
sfan5 |
:) |
| 19:19 |
PilzAdam |
lets release now! |
| 19:19 |
sfan5 |
^ |
| 19:19 |
hmmmm |
what I still can't understand is how not being able to save a mapblock causes such an error. so the save fails, so that means future loadBlocks fail as well. a new, blank block should be prepared for generation then |
| 19:20 |
hmmmm |
unless it was that particular block that didn't get re-generated |
| 19:21 |
hmmmm |
nevermind, i get it |
| 19:21 |
hmmmm |
that had to be the case, logically. |
| 19:22 |
sapier |
still how to behave on map save fail, reset the modified flag or not |
| 19:22 |
sapier |
original code didn't reset it |
| 19:22 |
hmmmm |
it's designed that way so it doesn't keep trying to save the failed block |
| 19:22 |
BlockMen |
cant reproduce the bug either with whatever sapier gave me to test |
| 19:23 |
hmmmm |
if the save fails, though, the usage timer should be reset and the unload should be canceled |
| 19:23 |
sapier |
at least failing to save map should result in a error message not a info message ;-) |
| 19:23 |
hmmmm |
yes, indeed, that would fix up the inappropriate behaviors observed in finishBlockMake as well |
| 19:24 |
hmmmm |
as for the re-generation for blocks that had already been generated... |
| 19:25 |
hmmmm |
how should that be tackled? would it be wise to not blit back mapblocks that have already been marked as generated? |
| 19:25 |
hmmmm |
(rather, make blitBackAll take a boolean parameter specifying whether or not generated blocks should be blitted back as well) |
| 19:26 |
sapier |
oops |
| 19:26 |
hmmmm |
this happened before with vanessae |
| 19:26 |
sapier |
that branch was not supposed to end up on minetest repository |
| 19:26 |
hmmmm |
she manually deleted a couple of erronoeous blocks |
| 19:26 |
sapier |
I'll delete it soon |
| 19:26 |
hmmmm |
and then the mapgen kept regenerating things like ores back in mid air |
| 19:26 |
hmmmm |
and other oddities |
| 19:27 |
hmmmm |
alright |
| 19:27 |
hmmmm |
three corrective actions to take |
| 19:27 |
hmmmm |
perhaps four if I want to combine block insertion and write |
| 19:27 |
hmmmm |
this will be for the next version though |
| 19:29 |
|
Tom-s joined #minetest-dev |
| 19:31 |
sapier |
I'm pushing the leveldb switch now |
| 19:31 |
sapier |
android only of course |
| 19:32 |
sapier |
any news on #1445? |
| 19:33 |
sfan5 |
<sfan5> #1445 could be fixed if the server were to check all SAOs in adjacent MapBlocks whether they are attached to the removed SAO |
| 19:33 |
sfan5 |
somebody do that |
| 19:33 |
sapier |
hmm hopefully there'll never be a lot of attached entities |
| 19:34 |
celeron55 |
sfan5: wtf? it's a client-side segfault, you can't fix it in the server |
| 19:35 |
celeron55 |
a malicious server could re-enable it |
| 19:35 |
sfan5 |
celeron55: only the server can cause the player to de-attach |
| 19:35 |
sfan5 |
oh.. you are viewing it from that point |
| 19:35 |
sfan5 |
then.. |
| 19:35 |
celeron55 |
the client should never crash, no matter what is sent to it and no matter where it connects |
| 19:35 |
sfan5 |
client should make sure removed CAO is not attached to LocalPlayer |
| 19:36 |
celeron55 |
(or, it can crash, but not uncontrollably like segfault) |
| 19:36 |
celeron55 |
sfan5: implement that |
| 19:36 |
|
proller joined #minetest-dev |
| 19:36 |
sfan5 |
-ENOTIME |
| 19:37 |
sfan5 |
I have to prepare something for OldCoder and then help Jordach |
| 19:37 |
sfan5 |
after that I could.. |
| 19:37 |
celeron55 |
i guess the client could just disconnect and go to the menu if that happens |
| 19:37 |
celeron55 |
because... basically the client was deleted from the game |
| 19:37 |
OldCoder |
Hi |
| 19:38 |
celeron55 |
umm or |
| 19:38 |
OldCoder |
Working on it with sfan5 today |
| 19:38 |
celeron55 |
well yes, that's what the client should do if the server behaves like it does now |
| 19:38 |
sfan5 |
celeron55: it's not the client that is deleted but the object the client is attached to |
| 19:38 |
hmmmm |
a segfault is a possible remote execution vulnerability. |
| 19:38 |
hmmmm |
i can't believe you don't have time to fix that |
| 19:39 |
celeron55 |
well, it's not sfan5's bug in any way |
| 19:39 |
sfan5 |
don't forget that everyone here does this voluntarily |
| 19:39 |
celeron55 |
i took a quick look at it previously but didn't know where the check should go |
| 19:39 |
sapier |
object attachements are quite messed up too |
| 19:40 |
sfan5 |
and it's "just" a segfault by accessing freed memory anyway |
| 19:40 |
sfan5 |
there is no possiblity of code exec there |
| 19:40 |
sapier |
maybe instead of adding a quick hack we should schedule a real fix ... fixing new clients not beeing notified about existing attachements too |
| 19:40 |
sfan5 |
hm.. maybe there is |
| 19:41 |
sfan5 |
anyway, someone should fix it |
| 19:44 |
celeron55 |
this would need some kind of a weak pointer |
| 19:44 |
celeron55 |
which requires the original pointers to be shared pointers |
| 19:44 |
|
grrk-bzzt joined #minetest-dev |
| 19:45 |
celeron55 |
or alternatively there should be no direct pointer to the parent object but instead just the id, which is always re-fetched |
| 19:45 |
sfan5 |
I don't think code exec would be possible as the segfault occurrs directly after the packet was received and you're not able to put any code there before the crash occurrs |
| 19:45 |
sfan5 |
and there is NX, and ASLR |
| 19:45 |
sfan5 |
... |
| 19:45 |
celeron55 |
manually syncing this is pretty much impossible for a human being to implement |
| 19:45 |
sapier |
not sure if fetching that one is a good idea |
| 19:45 |
sapier |
for what I remember it's used in main draw loop |
| 19:46 |
sapier |
hmm funny we already have that code |
| 19:46 |
celeron55 |
well... it's bearable, but for the same effort a better solution can be made |
| 19:46 |
sapier |
ClientActiveObject* GenericCAO::getParent() |
| 19:47 |
celeron55 |
anyway, this is the only bug that can be reasonably fixed for 0.4.10 |
| 19:48 |
celeron55 |
the rest will have to be handled later |
| 19:49 |
sapier |
bug is CAO being already deleted isn't it? |
| 19:49 |
celeron55 |
no |
| 19:49 |
sapier |
then I'm looking wrong direction :-/ |
| 19:50 |
celeron55 |
the bug is this: the server tells the client (as controlled by a mod) that the client's player is attached to an object, and then deletes the object, which is synced to the client and the client then deletes the object from its memory |
| 19:50 |
celeron55 |
this leaves a dangling pointer to the local player |
| 19:50 |
celeron55 |
which is then accessed in the next frame in a camera update, and possibly would be in other places too |
| 19:51 |
sapier |
ahh |
| 19:52 |
celeron55 |
are you taking the challenge? 8) |
| 19:52 |
sapier |
I'll try it ... but only for an hour |
| 19:54 |
sapier |
local player pointer isn't saved |
| 19:54 |
sapier |
it's always read from player list |
| 19:55 |
celeron55 |
it's "ClientActiveObject *parent;" in localplayer.h:43 |
| 19:55 |
sapier |
that's a cao not a player ;-) |
| 19:55 |
celeron55 |
the trivial fix is that every time ClientEnvironment::removeActiveObject is called (in client.cpp:1280), the local player should be checked for whether it has that parent set, and whether the parent is the thing being removed, and if so, the removal to be synced there |
| 19:56 |
celeron55 |
well that is in the player class, pointing to a cao |
| 19:56 |
|
vifino joined #minetest-dev |
| 19:56 |
celeron55 |
replacing the pointer with an object id could be a solid fix for now, leaving optimization for later? |
| 19:57 |
celeron55 |
i guess even hmmmm values no segfaults more than performance |
| 19:57 |
sapier |
https://gist.github.com/sapier/2e98e2dca334c1f2a5ec this should cause it to do a clean assert :-) |
| 19:58 |
sapier |
added in void GenericCAO::removeFromScene(bool permanent) |
| 19:58 |
celeron55 |
is setCAO(NULL) called in that case? |
| 19:58 |
celeron55 |
umm wait |
| 19:58 |
sapier |
if the cao is unloaded it should be called |
| 19:59 |
sapier |
that doesn't stop mt from crashing ... but it will crash in a more "clean" way |
| 19:59 |
celeron55 |
that won't do anythin |
| 19:59 |
celeron55 |
+g |
| 19:59 |
celeron55 |
the player's CAO isn't being removed |
| 20:00 |
celeron55 |
an object to which the player's CAO is attached is being removed |
| 20:00 |
celeron55 |
s/object/CAO/ |
| 20:00 |
sapier |
ok so the pointer in localplayer should be still valid |
| 20:00 |
celeron55 |
no, the localplayer pointer isn't pointing to the player CAO but the attachment parent CAO |
| 20:00 |
celeron55 |
the cao pointer is m_cao there at the bottom of the file |
| 20:00 |
sapier |
ahhh wrong cao |
| 20:01 |
celeron55 |
goddamnit |
| 20:01 |
sapier |
argh |
| 20:01 |
celeron55 |
now fix it and don't make me explain it more 8D |
| 20:02 |
celeron55 |
these could use a bit more comments in the code |
| 20:02 |
sapier |
https://gist.github.com/sapier/2e98e2dca334c1f2a5ec |
| 20:02 |
celeron55 |
also player->isAttached = false |
| 20:03 |
sapier |
do we have someone to test? |
| 20:03 |
celeron55 |
(why the hell that even exists, the pointer being not NULL already means it...) |
| 20:03 |
* sfan5 |
can test |
| 20:03 |
sapier |
as I said attachement code is completely messed up |
| 20:04 |
sapier |
add the upper gist to void GenericCAO::removeFromScene(bool permanent) content_cao.cpp L737 |
| 20:04 |
sapier |
preferably withing the if (( m_env != 0 block ;-) |
| 20:04 |
sfan5 |
shouldn't that code only get called if permanent == true |
| 20:05 |
sapier |
yes if ((m_env != 0 block ;-) |
| 20:05 |
celeron55 |
so L741 |
| 20:08 |
sfan5 |
works |
| 20:08 |
celeron55 |
now everyone hope that this doesn't cause some crazy regression |
| 20:09 |
sapier |
I'll push it |
| 20:13 |
|
us`0gb joined #minetest-dev |
| 20:14 |
hmmmm |
I do value no segfaults more |
| 20:14 |
celeron55 |
are we then good to go for 0.4.10? |
| 20:14 |
hmmmm |
it needs to work and be safe |
| 20:14 |
hmmmm |
yeah pretty much |
| 20:14 |
* sfan5 |
says yes |
| 20:15 |
celeron55 |
has there been any feedback from the rc1 builds? |
| 20:15 |
sfan5 |
not much |
| 20:15 |
sfan5 |
we should wait a few days |
| 20:15 |
celeron55 |
well, we probably don't have to wait |
| 20:15 |
sfan5 |
what about https://github.com/minetest/minetest/issues/1397 ? |
| 20:16 |
celeron55 |
many people have been playing the dev builds during this week, that's enough |
| 20:16 |
sapier |
it's an sqlite error sfan5 most likely it doesn't even happen on pc and for android we're switching to leveldb |
| 20:17 |
celeron55 |
well the original reporter of that bug probably isn't on android |
| 20:17 |
sapier |
https://github.com/minetest/minetest/issues/1425 so only this one is left not a crash but a dos by broken mod |
| 20:18 |
celeron55 |
that isn't important |
| 20:18 |
sapier |
I should read titles more carefully ... I'm gonna unflag 1425 from blocker |
| 20:19 |
celeron55 |
yes, do that |
| 20:19 |
sapier |
and delete the milestone |
| 20:20 |
sapier |
so only "random segfaults" is left |
| 20:20 |
celeron55 |
you mean close? |
| 20:20 |
sapier |
no |
| 20:20 |
celeron55 |
milestones shouldn't be deleted |
| 20:20 |
sapier |
I removed the milestone from that issue |
| 20:20 |
celeron55 |
oh that, whatever then |
| 20:20 |
sapier |
shall I do same for segfaults? |
| 20:21 |
sapier |
once I do this 0.4.10 autocloses |
| 20:21 |
celeron55 |
it's quite obscure, we can't fix it in time |
| 20:21 |
celeron55 |
i don't think anyone has the energy for that |
| 20:21 |
sapier |
ok so I'll remove milestone and make it a ordinary bug |
| 20:22 |
sapier |
no autoclosing milestone? ... I'm disapointed |
| 20:22 |
celeron55 |
autoclosing would be annoying |
| 20:23 |
sapier |
ok so what to do for release ... version number, android version code ... what else? |
| 20:23 |
sapier |
guess I'm starting with version code |
| 20:23 |
celeron55 |
http://dev.minetest.net/Releasing_Minetest |
| 20:23 |
celeron55 |
this should be somewhat up-to-date |
| 20:23 |
celeron55 |
if it isn't, it should be updated in the process |
| 20:24 |
sfan5 |
are we going to wait till 13th or release earlier? |
| 20:25 |
celeron55 |
no, we'll release now |
| 20:25 |
sfan5 |
>22:25 |
| 20:25 |
sfan5 |
>tired |
| 20:25 |
sfan5 |
who updates the changelog? |
| 20:25 |
sfan5 |
not me |
| 20:25 |
celeron55 |
hmm, well we can't release if everyone isn't available |
| 20:26 |
celeron55 |
BlockMen? |
| 20:26 |
BlockMen |
hm? |
| 20:27 |
celeron55 |
are you available for making builds during the next hour |
| 20:27 |
BlockMen |
sure |
| 20:28 |
sapier |
I'm changing the version numbers |
| 20:29 |
celeron55 |
go ahead then |
| 20:31 |
PilzAdam |
don't forget lua_api.txt and menu_api.txt |
| 20:31 |
sapier |
menu api? |
| 20:32 |
PilzAdam |
doc/menu_lua_api.txt |
| 20:32 |
celeron55 |
those are well listed on the wiki page |
| 20:32 |
celeron55 |
just read it and work like a robot |
| 20:32 |
sapier |
menu api is already at 0.4.10 :-) |
| 20:32 |
celeron55 |
(i |
| 20:32 |
celeron55 |
(i'm updating it a bit) |
| 20:34 |
sapier |
I'm doing a testbuild and push once completed |
| 20:35 |
sfan5 |
ShadowNinja: are you around to update the changelog? |
| 20:37 |
PilzAdam |
is the changelog for 0.4.9 even up to date? |
| 20:37 |
sfan5 |
no |
| 20:38 |
BlockMen |
should _next changelog be added aswell? |
| 20:38 |
sfan5 |
yes |
| 20:38 |
sfan5 |
BlockMen: can you do that? |
| 20:38 |
sfan5 |
I'll try to do the rest |
| 20:38 |
PilzAdam |
make a visible difference between game and engine changelog |
| 20:39 |
BlockMen |
^ how? |
| 20:39 |
BlockMen |
until now it was always mixed |
| 20:39 |
celeron55 |
put minetest_game stuff under "Game Content Changes" |
| 20:39 |
celeron55 |
"Game Content Changes (minetest_game)" |
| 20:39 |
celeron55 |
that way it's understandable to everyone |
| 20:40 |
BlockMen |
k |
| 20:41 |
sapier |
shouldn't there be Minetest 0.4.10 written in upper left corner? |
| 20:42 |
PilzAdam |
yes |
| 20:42 |
sapier |
after changing cmakelists.txt I still have date git there |
| 20:42 |
PilzAdam |
"Comment out the line that sets VERSION_PATCH to ${VERSION_PATCH}-dev. " did you do that? |
| 20:43 |
sapier |
yes |
| 20:43 |
celeron55 |
you have to add the git tag i guess |
| 20:43 |
sapier |
ahh |
| 20:43 |
celeron55 |
it's mentioned later on the wiki page, if this works i'll update wiki |
| 20:44 |
ShadowNinja |
sfan5: Yes. |
| 20:45 |
ShadowNinja |
I see the release date was moved back... |
| 20:46 |
sapier |
yes after finding out what's been really wrong with mapgen we found a workaround too |
| 20:46 |
celeron55 |
waiting a week more would just kill everyone |
| 20:48 |
sapier |
oops guess I just pushed more tags then I wanted to push ... deleting them again |
| 20:49 |
ShadowNinja |
BlockMen: Are you working on the changelog now or should I start on it? |
| 20:49 |
BlockMen |
ShadowNinja, give me 4 min, then im done with game changes |
| 20:50 |
sfan5 |
..damn ubuntu |
| 20:50 |
ShadowNinja |
Alright, I'll finish up these datastorage and UI changes... |
| 20:50 |
|
EvergreenTree joined #minetest-dev |
| 20:51 |
sfan5 |
ShadowNinja: are you going to do the rest of the changelog? |
| 20:52 |
ShadowNinja |
sfan5: Yes, once BM finishes. |
| 20:52 |
sfan5 |
ok, thanks |
| 20:52 |
sapier |
https://github.com/minetest/minetest/releases/tag/0.4.10 |
| 20:53 |
sfan5 |
sapier: you could've changed the tag for the untagged one, I'll do that |
| 20:54 |
sapier |
no idea what you're talking about :-) |
| 20:54 |
sfan5 |
oops |
| 20:54 |
sfan5 |
looks like I released it already |
| 20:54 |
BlockMen |
ShadowNinja, done |
| 20:54 |
sfan5 |
note to self: don't press enter |
| 20:55 |
* sfan5 |
made it into a draft again |
| 20:55 |
sfan5 |
hmmm |
| 20:56 |
sfan5 |
sapier: the tag will get created when https://github.com/minetest/minetest/releases/tag/untagged-17a201e222ba300265b9 is published |
| 20:56 |
celeron55 |
so, now according to the wiki page we're waiting for windows packages |
| 20:56 |
PilzAdam |
who's gonna tag _game? |
| 20:56 |
* sfan5 |
starts building |
| 20:57 |
sapier |
nice feature |
| 20:57 |
sapier |
sfan5 you can't build without tag |
| 20:57 |
sfan5 |
I can |
| 20:57 |
sapier |
a local one? |
| 20:57 |
sfan5 |
yes |
| 20:57 |
sapier |
ok ok :-) |
| 20:57 |
PilzAdam |
celeron55, now "tag" is 2 times on the wiki page |
| 20:58 |
celeron55 |
PilzAdam: i know, it needs to be |
| 20:58 |
celeron55 |
the tag shouldn't be pushed to github initially but only after the builds are checked to be working |
| 20:59 |
celeron55 |
but it needs to be created before so that the cmake version scripts can be checked |
| 20:59 |
sfan5 |
-- *** Will build version 0.4.10 *** |
| 20:59 |
PilzAdam |
does the win build run on windows xp? if yes then we can say we have better support for win than microsoft |
| 20:59 |
sfan5 |
this is right, isn't it? |
| 20:59 |
sfan5 |
we don't need a tag |
| 20:59 |
sfan5 |
it seems to be enough to set VERSION_EXTRA to '' |
| 21:00 |
sfan5 |
PilzAdam: mine should run on XP |
| 21:00 |
BlockMen |
yes, it runs under xp |
| 21:02 |
PilzAdam |
be sure to add that to the forum post |
| 21:02 |
sapier |
minetest_next is already merged to minetest_game? |
| 21:02 |
PilzAdam |
yes |
| 21:04 |
OldCoder |
sfan5 and others: Meowtest (sfan5 0.4.10) server is built. If people will explain setup of minetest_next and/or other changes, I will provide a testbed as requested by sfan5. |
| 21:05 |
sapier |
LOL ... I'm gonna kill those irrlicht guys |
| 21:05 |
celeron55 |
this sounds good |
| 21:06 |
BlockMen |
done with build can i upload it to github or is it better just one person does? |
| 21:06 |
PilzAdam |
where is the "Pray that nothing breaks" instruction in the wiki page? |
| 21:06 |
BlockMen |
oh, wait. damn version string was not updated |
| 21:06 |
celeron55 |
we don't believe in god, we belive in hard work and clueless users! |
| 21:06 |
BlockMen |
*grmbl* |
| 21:07 |
PilzAdam |
celeron55, for releases we need all help we can get! ;-) |
| 21:07 |
celeron55 |
it's implied between each step |
| 21:07 |
celeron55 |
writing it there would scare everyone away |
| 21:08 |
PilzAdam |
the quote at the top does that already |
| 21:08 |
sapier |
anyone continuing after reading "<celeron55> horrible, horrible work" is tough |
| 21:09 |
sfan5 |
BlockMen: upload to github named 'minetest-0.4.10-msvc-win(32|64).zip' |
| 21:09 |
BlockMen |
why not just minetest-0.4.10? |
| 21:09 |
BlockMen |
like minetest 0.4.9 |
| 21:10 |
celeron55 |
i removed the quote a moment ago |
| 21:10 |
sfan5 |
BlockMen: just add the msvc thing, allows distinguishing them easier |
| 21:11 |
celeron55 |
now i added a new text at the top |
| 21:11 |
PilzAdam |
celeron55, so you want to trick us into releasing more often |
| 21:11 |
BlockMen |
msvc says the most user nothing |
| 21:11 |
celeron55 |
PilzAdam: yes |
| 21:12 |
sapier |
guess I'm gonna archive that android source tree to be able to rebuild it case one of our library dependencys break |
| 21:12 |
BlockMen |
dont confuse win users more than neccessary ;) |
| 21:12 |
celeron55 |
PilzAdam: my plan isn't working very well |
| 21:12 |
|
cheapie joined #minetest-dev |
| 21:13 |
celeron55 |
BlockMen: i think it should be included, the windows user will just click it anyway |
| 21:14 |
sapier |
"run and check if the thing seems to be working" I'm going to have a problem to do tis on android mips and x86 version ;-) |
| 21:17 |
BlockMen |
i still think its more confusing user, but hey, then with msvc |
| 21:17 |
* BlockMen |
uploading right now |
| 21:18 |
sfan5 |
now for uploading... |
| 21:19 |
|
alexxss joined #minetest-dev |
| 21:21 |
BlockMen |
ok, msvc builds uploaded |
| 21:21 |
* sfan5 |
still uploading |
| 21:21 |
sapier |
who did the leveldb changes? |
| 21:21 |
sfan5 |
leveldb? |
| 21:21 |
sapier |
V/Minetest(10424): 23:21:25: ERROR[ServerThread]: ERROR: An unhandled exception occurred: LevelDB error: NotFound: |
| 21:22 |
sfan5 |
that is just leveldb providing your with a sane error |
| 21:22 |
sapier |
well it did work before ;) |
| 21:23 |
cheapie |
Speaking of databases, is it normal for a --migrate redis to take a ~3GB LevelDB world and turn it into something like 10GB? |
| 21:23 |
sfan5 |
sapier: the only place where I added error handling is saveBlock |
| 21:23 |
sfan5 |
cheapie: leveldb may use compression, so yes |
| 21:24 |
cheapie |
OK. |
| 21:24 |
BlockMen |
celeron55, saw you already did some change on mainpage. guess you want do it when done again? |
| 21:24 |
* cheapie |
wanders back off |
| 21:25 |
celeron55 |
BlockMen: feel free to do it |
| 21:25 |
celeron55 |
i just added the 0.4.10 teaser :P |
| 21:25 |
BlockMen |
k |
| 21:26 |
celeron55 |
(and played around with an unrelated joke thing) |
| 21:27 |
sfan5 |
random thing: minetest.net could use a new header image that isn't jpg |
| 21:27 |
PilzAdam |
random thing: minetest.net should load way faster |
| 21:28 |
sfan5 |
random suggestion: nginx |
| 21:28 |
PilzAdam |
who tests the win builds currently? |
| 21:28 |
* sfan5 |
won't get up to find a Windows laptop |
| 21:29 |
PilzAdam |
Ill ask in #minetest |
| 21:29 |
celeron55 |
i'm probably going to redo and rehost minetest.net at some point |
| 21:30 |
OldCoder |
Meowtest 0.4.10 "SEGFAULTY!" is now open for business at sfan5 request. Server minetest.org Port 30018 and direct questions to sfan5. Have fun. |
| 21:30 |
BlockMen |
i will add "androi"d section before "other" on /download |
| 21:30 |
sfan5 |
nice adjective |
| 21:30 |
sfan5 |
and you should probably post this to #minetest |
| 21:30 |
OldCoder |
kk |
| 21:31 |
* OldCoder |
obeys |
| 21:31 |
sapier |
at least android version is broken |
| 21:32 |
sapier |
can someone check if leveldb is broken on pc too? |
| 21:32 |
PilzAdam |
is it just me or do other people wince too when they get pinged during a release? |
| 21:34 |
|
us`0gb joined #minetest-dev |
| 21:35 |
celeron55 |
i tested the win32-msvc build on wine on 64bit fedora (nothing seems broken) |
| 21:35 |
sapier |
changes in loadBlock seem to cause it |
| 21:36 |
PilzAdam |
sfan5, shouldnt it be "win32-mingw" instead of "mingw-win32"? |
| 21:36 |
sfan5 |
PilzAdam: I'm not reuploading them |
| 21:36 |
ShadowNinja |
Changelog updated |
| 21:36 |
celeron55 |
i realized a thing though: the default font size is still overly small |
| 21:36 |
celeron55 |
it could be set a few pixels larger without breaking any of the UI at all (and i personally have it set so) |
| 21:37 |
PilzAdam |
shit, what about translations? |
| 21:37 |
* OldCoder |
is prepared to offer his own 32 bit and 64 bit Windows buildings using the MaxGW framework |
| 21:37 |
sfan5 |
PilzAdam: I'll rename them after I've finished uploading |
| 21:37 |
OldCoder |
builds, not buildings; damn typos |
| 21:43 |
sapier |
hmm oldcoder always want to have the full set ... minimal isn't enough for him ;-) |
| 21:44 |
sfan5 |
wtf github |
| 21:44 |
sfan5 |
why does it keep releasing 0.4.10 |
| 21:44 |
celeron55 |
i'm going to sleep now, i guess you can handle the release |
| 21:44 |
PilzAdam |
sfan5, there is this big green button "RELEASE!", and the little gray button "Save draft" |
| 21:45 |
sfan5 |
PilzAdam: it releases if I press enter |
| 21:45 |
sfan5 |
UI wasn't designed after principle of least surprise |
| 21:45 |
PilzAdam |
celeron55, no! I dont want to do launchpad |
| 21:45 |
celeron55 |
PilzAdam: i'll do it in the morning then |
| 21:46 |
celeron55 |
i will enjoy my breakfast with a bunch of launchpad rage |
| 21:47 |
celeron55 |
or, umm... |
| 21:47 |
celeron55 |
well i'll try to do it now |
| 21:48 |
celeron55 |
if something doesn't work, i'll just sleep |
| 21:49 |
PilzAdam |
sapier, so, whats up with android? |
| 21:49 |
sapier |
:-/ no mips build for leveldb ... that's been the reason why I switched back to sqlite ... most devices are arm |
| 21:49 |
sapier |
https://gist.github.com/sapier/3e91c0ce6c23e8e134b6 this patch fixes it ... for what I understand that error should be on pc too |
| 21:49 |
sapier |
so no leveldb for 0.4.10 official release |
| 21:50 |
sfan5 |
then it's broken, who cares |
| 21:51 |
sfan5 |
wasn't 0.4.11 supposed to be a bugfix release anyway? |
| 21:52 |
sapier |
sfan5 you shouldn't shout that loud I might remember my threat with head and things like that ;-P |
| 21:52 |
sfan5 |
I'm not shouting |
| 21:52 |
PilzAdam |
we almost had a release without problems... |
| 21:52 |
sfan5 |
not a single letter was caps |
| 21:52 |
celeron55 |
can minetest_game be tagged with 0.4.10 now? |
| 21:53 |
sfan5 |
yes |
| 21:53 |
sapier |
that's been a german saying ;-) |
| 21:53 |
celeron55 |
it wouldn't be a release if it didn't have problems |
| 21:53 |
celeron55 |
i base this on the fact that i have never seen a release with no problems |
| 21:53 |
PilzAdam |
let us dream |
| 21:54 |
sapier |
if it's only android I'll just build those packages slightly next to 0.4.10 ... if it's pc too ... well I don't use leveldb |
| 21:54 |
PilzAdam |
BlockMen, care to test leveldb on windows? |
| 21:54 |
sfan5 |
technically 0.4.10 is not released yet |
| 21:55 |
sfan5 |
if you insist I'll build my packages again |
| 21:55 |
BlockMen |
already doing.... |
| 21:55 |
PilzAdam |
sfan5, by looking at the github timeline you released it already 2 times ;-) |
| 21:55 |
sapier |
and android mips is dropped for 0.4.10 |
| 21:55 |
sapier |
I can live with that |
| 21:55 |
celeron55 |
launchpad is now building |
| 21:55 |
celeron55 |
hopefully most of them succeed |
| 21:56 |
PilzAdam |
celeron55, I can test them in 24 hours |
| 21:56 |
sfan5 |
I guess this means leveldb stays broken in 0.4.10 |
| 21:57 |
PilzAdam |
sfan5, lets wait for BlockMen's test results first |
| 21:57 |
sfan5 |
PilzAdam: i can guarantee you that it will not work on windows either |
| 21:58 |
sapier |
I guess it's gonna work as long as you don't leave generated area :-) |
| 22:00 |
BlockMen |
i dont get it. two times clean build with level db, both time "unkown map format" |
| 22:00 |
BlockMen |
like its not included |
| 22:01 |
BlockMen |
i can build it a third time |
| 22:01 |
BlockMen |
or it stays as is |
| 22:01 |
PilzAdam |
sfan5, is it broken on linux too? |
| 22:01 |
sfan5 |
PilzAdam: lemme test |
| 22:01 |
PilzAdam |
in that we case we shouldn't release with broken leveldb |
| 22:02 |
sfan5 |
00:01:47: ERROR[main]: cannot open /home/stefan/minetest/bin/../games/minetest_game/mods/legacy/init.lua: Datei oder Verzeichnis nicht gefunden |
| 22:02 |
sfan5 |
wtf |
| 22:02 |
BlockMen |
legacy is doch weg?! |
| 22:02 |
PilzAdam |
wtf |
| 22:02 |
BlockMen |
*oh, sry. i ment legacy is removed |
| 22:03 |
PilzAdam |
thats not good |
| 22:03 |
sfan5 |
BlockMen: nope, was just a bug on my side |
| 22:04 |
sfan5 |
PilzAdam: leveldb broken on linux too |
| 22:04 |
BlockMen |
ofc it is https://github.com/minetest/minetest_game/tree/master/mods |
| 22:05 |
PilzAdam |
we cant release like that |
| 22:05 |
sapier |
shall I push the fix? |
| 22:05 |
sfan5 |
sapier: yes |
| 22:08 |
PilzAdam |
should I cancel the launchpad builds? |
| 22:09 |
sfan5 |
ffs, I need to re-compile |
| 22:09 |
BlockMen |
^ without leveldb |
| 22:10 |
PilzAdam |
I need to sleep too |
| 22:16 |
OldCoder |
sapier, I don't use Windows. This is for others. Oh, you mean MaxGW? This is an experiment of mine. |
| 22:19 |
sfan5 |
sapier: whe n |
| 22:19 |
sfan5 |
sapier: are the android builds ready? |
| 22:21 |
sapier |
I'm trying to upload right now |
| 22:22 |
BlockMen |
i need at least 5 min. |
| 22:22 |
ShadowNinja |
G+ release post is ready. |
| 22:24 |
sapier |
argh ... need to build again |
| 22:25 |
sapier |
deleting "minimal" causes git to believe it's dirty |
| 22:26 |
sfan5 |
BlockMen: the pkgs that are at GH currently are the wrong ones, right? |
| 22:26 |
BlockMen |
wait a sec |
| 22:27 |
BlockMen |
screw it, leave this builds |
| 22:27 |
BlockMen |
leveldb doesnt want complile right now, idk why |
| 22:29 |
sapier |
nope .. build system issue ... I'll hardcode the number for this release and fix it later |
| 22:31 |
sfan5 |
sapier: .apk.zip |
| 22:31 |
sfan5 |
wtf |
| 22:31 |
sfan5 |
an .apk is essentially a .zip |
| 22:31 |
sapier |
githu doesn't allow apk files |
| 22:31 |
sfan5 |
ok, then |
| 22:31 |
sapier |
I think this is stupid too |
| 22:32 |
sapier |
maybe we should mention it in release notes |
| 22:32 |
sfan5 |
maybe |
| 22:32 |
BlockMen |
that makes no sense at all, leveldb enabled in cmake, lib is also linked correct, it builds but it always say "unknown map backend" |
| 22:41 |
sapier |
ok uploading android packages now |
| 22:41 |
sfan5 |
I thought they already were uploaded |
| 22:42 |
sapier |
no had to rename them |
| 22:42 |
sfan5 |
you can rename them without re-uploading |
| 22:42 |
sfan5 |
https://github.com/minetest/minetest/releases/edit/untagged-0ebfb8cc5c9296415c8e |
| 22:42 |
sapier |
but not the file within the zip |
| 22:43 |
sfan5 |
oh.. |
| 22:43 |
sapier |
and uploading multiple files is broken too argh |
| 22:44 |
sapier |
at least on drag and drop |
| 22:49 |
BlockMen |
i got it :D |
| 22:49 |
BlockMen |
it works |
| 22:49 |
BlockMen |
ok, in ~5 min i can update my builds |
| 22:49 |
sfan5 |
finally |
| 22:49 |
sfan5 |
I'll release it now |
| 22:50 |
sapier |
ok uploaded |
| 22:50 |
sfan5 |
I'll also do the news post |
| 22:52 |
sfan5 |
https://forum.minetest.net/viewtopic.php?f=18&t=9688 |
| 22:52 |
sapier |
can we mention the android forum thread in changelog? |
| 22:53 |
BlockMen |
ey, what? |
| 22:53 |
BlockMen |
i said 5 min |
| 22:53 |
sfan5 |
which thread? |
| 22:53 |
sfan5 |
BlockMen: idc, I want to sleep |
| 22:54 |
sapier |
https://forum.minetest.net/viewtopic.php?f=3&t=9389 |
| 22:54 |
sfan5 |
BlockMen: you can update them, just make sure to use the same file name |
| 22:55 |
sfan5 |
sapier: added link |
| 22:55 |
BlockMen |
its buggy |
| 22:56 |
BlockMen |
its say "dont support that file type" |
| 22:56 |
sfan5 |
then just don't update them |
| 22:56 |
* sfan5 |
finally goes to sleep |
| 22:56 |
BlockMen |
fuck you |
| 22:56 |
sfan5 |
not my fault |
| 22:57 |
BlockMen |
5 min more or less |
| 22:58 |
BlockMen |
so yes, its yours |
| 23:04 |
|
GhostDoge joined #minetest-dev |
| 23:04 |
ShadowNinja |
minetest.net/download needs to be updated. |
| 23:05 |
ShadowNinja |
I'll do it. |
| 23:06 |
ShadowNinja |
BlockMen: What's the difference between msvc and msvc2 packages? |
| 23:07 |
BlockMen |
none, it was temporary |
| 23:08 |
BlockMen |
and i was right now finiesh with mainpage update |
| 23:08 |
BlockMen |
how can you even lock it when im editing? |
| 23:09 |
BlockMen |
ShadowNinja^ |
| 23:09 |
BlockMen |
can i just save it now? |
| 23:09 |
sapier |
if he did change it that might be dangerous |
| 23:09 |
ShadowNinja |
BlockMen: Did you add the 64-bit builds? And remove the temporary one. |
| 23:10 |
BlockMen |
yes |
| 23:10 |
BlockMen |
and they are |
| 23:11 |
BlockMen |
its still locked |
| 23:12 |
BlockMen |
ShadowNinja^ |
| 23:12 |
ShadowNinja |
BlockMen: Released. |
| 23:12 |
ShadowNinja |
(As in un-loaked ;-) ) |
| 23:12 |
ShadowNinja |
un-locked* |
| 23:14 |
BlockMen |
done |
| 23:14 |
BlockMen |
better titel for the android releases? |
| 23:14 |
ShadowNinja |
BlockMen: More than one link is bolded. |
| 23:14 |
ShadowNinja |
Also, add Android links somewhere with a note that they're still very buggy. |
| 23:15 |
ShadowNinja |
Er, you did, but without the note. |
| 23:15 |
BlockMen |
so just 32 bit bold? |
| 23:15 |
sapier |
buggy ... yes very ... I don't think so |
| 23:15 |
ShadowNinja |
BlockMen: Yes, since it works with both. |
| 23:16 |
ShadowNinja |
sapier: ? |
| 23:16 |
BlockMen |
arm bold? |
| 23:16 |
BlockMen |
yes/no? |
| 23:16 |
ShadowNinja |
sapier: Do you aggree that they're buggy or not? |
| 23:16 |
sapier |
if I'd consider android to be very buggy I'd not have released it ... and buggy .. well depends on pov ... it's for sure not polished |
| 23:17 |
ShadowNinja |
BlockMen: Yes. Also remove the ':' and the full link to the x86 one. |
| 23:17 |
sapier |
but by now the only severe issue left is highdpi screens |
| 23:17 |
sapier |
and that one most likely would be fixed if not someone would've removed the sqlite error message ;-) |
| 23:18 |
ShadowNinja |
sapier: Lots of things don't scale, inventory images are messed up, and there's still some chat-flooding debug statements. |
| 23:18 |
sapier |
where are inventory images messed up? |
| 23:18 |
sapier |
and what debug messages? |
| 23:18 |
ShadowNinja |
sapier: On aforementioned N7. Engine-generated cube ones are upside-down. |
| 23:19 |
BlockMen |
ok, then i add "very buggy" to android caption |
| 23:19 |
sapier |
why don't you tell those things? I basicaly have to fix this for each device as they behave different |
| 23:20 |
ShadowNinja |
Also, pressing PWR+VolDn for screenchot sometimes prints something like "unrecignozed key code 00000000". Possibly one of those keys gets pressed first and MT gets that event. |
| 23:20 |
sapier |
I can only fix things I know and especially for android it's very likely to not happen for me |
| 23:21 |
ShadowNinja |
sapier: And it printed some debug info when using formspecs. "fields = {...}" or some such. |
| 23:21 |
BlockMen |
ok, mainpage is updated now (old releases aswell) |
| 23:22 |
ShadowNinja |
(In chat) |
| 23:22 |
sapier |
if you mentioned those things about 4h ago they most likely would be fixed now ... and they haven't been added the last days |
| 23:22 |
ShadowNinja |
G+ post published. |
| 23:23 |
ShadowNinja |
sapier: And I noticed a mapgen bug, one minute... |
| 23:27 |
Jordach |
hold it! |
| 23:27 |
ShadowNinja |
sapier: http://imgur.com/eDLbCcd,y1hO4QL,yS1QFUL #1=chat messages #2=World corruption (same map as before, but world reloaded) #3=Loading bar scaling. |
| 23:28 |
sapier |
that's minimal game not android version |
| 23:28 |
Jordach |
http://paste.debian.net/108454/ |
| 23:28 |
sapier |
the fields |
| 23:28 |
Jordach |
^ bug |
| 23:28 |
ShadowNinja |
sapier: Ah, but the 00000000 thing? |
| 23:29 |
sapier |
that's a bug |
| 23:29 |
ShadowNinja |
Jordach: Mod error? |
| 23:31 |
Jordach |
ShadowNinja, register_item_raw(itemdef) from builtin/game/register.lua seems to be the cause |
| 23:33 |
Jordach |
or i put quotes around a group |
| 23:33 |
sapier |
still anyone finding android bugs please report it's not very likely they happen for someone else having a different device |
| 23:34 |
|
cg72 joined #minetest-dev |
| 23:34 |
sapier |
ShadowNinja: that screenshot isn't n7 is it? |
| 23:34 |
sapier |
because there the inventory images are fine |
| 23:36 |
|
sapier left #minetest-dev |
| 23:39 |
ShadowNinja |
saIt's N10. |
| 23:39 |
ShadowNinja |
:-| |
| 23:44 |
|
kaeza joined #minetest-dev |
| 23:50 |
|
stormchaser3000 joined #minetest-dev |
| 23:51 |
VanessaE |
*sigh& |
| 23:51 |
VanessaE |
*sigh* |
| 23:51 |
VanessaE |
yet another rushed release, I see |
| 23:52 |
VanessaE |
not that it's more buggy than usual but from reading the backlog, G*d damn you guys got yourselves all in a tizzy about it. |
| 23:54 |
VanessaE |
and why the fuck was #1425 taken off the milestone? that is a bad bug regardless of what brought it on. Any time the engine auto-deletes excess entities, it risks deleting and disconnecting in those blocks. |
| 23:54 |
VanessaE |
what the fuck are you guys thinking? |
| 23:55 |
|
stormchaser3000_ joined #minetest-dev |
| 23:55 |
ShadowNinja |
I'll remove minor changes such as code style changes from the changelog if nobody objects. I'll add a link to the commit log with a note about changes that aren't mentioned. |
| 23:58 |
Taoki |
Yay, 4.10 was released today after all :) |
