| Time |
Nick |
Message |
| 00:02 |
sapier |
https://github.com/minetest/minetest/pull/2044 |
| 00:08 |
Wayward_One |
https://github.com/minetest/minetest/issues/2045 |
| 00:08 |
ShadowNinja |
VanessaE: Right. I assumed that was intentional. Does it detach the mouse on Windows? |
| 00:09 |
VanessaE |
ShadowNinja: I'm not sure, but I think so. how else would people copy&paste from the chat console? :) |
| 00:09 |
ShadowNinja |
VanessaE: And C&P should work in the console now, although it's never worked on Linux, so that's not an issue. |
| 00:09 |
ShadowNinja |
VanessaE: C-a C-c C-v |
| 00:10 |
ShadowNinja |
Or Shift-direction C-c |
| 00:10 |
VanessaE |
ShadowNinja: nope, I can't highlight to copy out from the console. |
| 00:10 |
VanessaE |
neither c-a nor shift-arrows cause a highlight. |
| 00:11 |
VanessaE |
nor can I paste in from e.g. hexchat. |
| 00:11 |
VanessaE |
but I can at least c-a, c-c and copy out from the old command line back to here. |
| 00:11 |
ShadowNinja |
VanessaE: Well, pasting has never worked. Copying should be fixed though. Make a comment on this usse so that this isn't forgoten. |
| 00:12 |
ShadowNinja |
the issue* |
| 00:13 |
VanessaE |
done. |
| 00:18 |
hmmmm |
so I think I got a pretty solid idea down, going with a slightly modified version of alternative lighting method #2 as discussed. i can make light spread further, i'll save 8 bits per mapnode, i can speed up lighting calculations, and i can have 24-bit colored lighting this way |
| 00:18 |
* VanessaE |
updates just to make sure about the console C&P |
| 00:18 |
hmmmm |
:D yay |
| 00:18 |
VanessaE |
hmmmm: very nice indeed. and it works okay with mods that check light levels in the usual way? |
| 00:18 |
sapier |
speed up light calculations? *Jumping up* |
| 00:18 |
hmmmm |
vanessae: nope |
| 00:18 |
sapier |
wanna have this! ;-) |
| 00:18 |
Wayward_One |
hmmm, can't wait to try it! :D |
| 00:18 |
VanessaE |
hmmmm: boooo :( |
| 00:19 |
Wayward_One |
*hmmmm |
| 00:19 |
hmmmm |
mods are gonna have to calculate light the 'hard' way |
| 00:19 |
hmmmm |
well |
| 00:19 |
sapier |
hard way? |
| 00:19 |
hmmmm |
nah i can just modify the api for it |
| 00:19 |
sapier |
you're kidding, I once wrote that in lua it's gonna take all the speed benefit and reverse it ;-P |
| 00:19 |
hmmmm |
but it'll be way, way, way more computationally expensive to get the light at a specific point |
| 00:20 |
hmmmm |
because i won't store it in the node any longer |
| 00:20 |
VanessaE |
ShadowNinja: ok, at git HEAD now and still can't c-a, c-c (doesn't highlight on c-a). |
| 00:20 |
sapier |
so any mapgen or spawning mod requireing light information will get drastically slower |
| 00:20 |
hmmmm |
pretty much yep |
| 00:20 |
VanessaE |
hmmmm: um |
| 00:20 |
sapier |
not good |
| 00:20 |
hmmmm |
:) |
| 00:20 |
VanessaE |
that breaks like half of plantlife. |
| 00:21 |
sapier |
I have some mobs spawning only in areas where almost no light is there .. e.g. vombies |
| 00:21 |
hmmmm |
I think there is a better way to do the thing you'd like to do |
| 00:21 |
hmmmm |
rather than check light levels |
| 00:21 |
sapier |
suggestions hmmmm? |
| 00:21 |
sapier |
I never found a way to do same thing another less expensive way |
| 00:21 |
hmmmm |
have a bit present in the mapnode for 'has_sunlight' |
| 00:21 |
sapier |
won't work |
| 00:22 |
sapier |
because spawning doesn't care about sunlight but actual light |
| 00:22 |
VanessaE |
hmmmm: torches triggering solar panels to act as node sensors. |
| 00:22 |
VanessaE |
(think: automated tree farms using pipeworks and mesecons) |
| 00:22 |
hmmmm |
that's a hacky way to do things to begin with though |
| 00:23 |
hmmmm |
so what do we actually need light levels for |
| 00:23 |
sapier |
it's not hacky to check for light if something doesn't have to spawn once light is around ;-) |
| 00:23 |
ShadowNinja |
VanessaE: "Doing this would leave the ESC/Pause menu as the only way to release the keyboard/mouse." -- not true, opening formspecs also releases the mouse. |
| 00:23 |
hmmmm |
is it absolutely necessary to know that (x, y, z) == 13 or something |
| 00:23 |
VanessaE |
ShadowNinja: oh right. /me fixes. |
| 00:23 |
hmmmm |
or is it more like |
| 00:23 |
hmmmm |
"i need to know where in the mapblock i can place this" |
| 00:23 |
sapier |
no but I need to know if light at xyz is > a |
| 00:24 |
hmmmm |
so if you're doing a bulk query then calculating light levels in a mapblock probably isn't too expensive |
| 00:24 |
sapier |
if you can provide the max light level within a certain area that'd be enough |
| 00:24 |
hmmmm |
yeah that too |
| 00:24 |
hmmmm |
that would be extremely quick |
| 00:24 |
sapier |
if light in (x1,y1,z1) (x2,y2,z2) > a |
| 00:24 |
VanessaE |
that would NOT be enough |
| 00:24 |
VanessaE |
you'll break everything that relies on light levels at specific locations. |
| 00:24 |
sapier |
how do you intend to make this quick? |
| 00:25 |
hmmmm |
VanessaE: yes, and minetest moves forward as a whole |
| 00:25 |
sapier |
in worst case x2 == x1+1 |
| 00:25 |
hmmmm |
well |
| 00:25 |
sapier |
that's not moving forward thats moving backward ;-) |
| 00:25 |
hmmmm |
hopefully your radius is conveniently the size of a mapblock |
| 00:25 |
sapier |
you're removing a feature because it's to slow for you |
| 00:25 |
* VanessaE |
grumbles |
| 00:25 |
sapier |
nope |
| 00:25 |
sapier |
a mapblock is way to big for spawning |
| 00:26 |
VanessaE |
hmmmm: why can't the light at a given point be calculated the "old" way on demand? |
| 00:26 |
sapier |
especally as usually no more then a few blocks are even loaded |
| 00:26 |
hmmmm |
because that takes up 8 bits |
| 00:26 |
hmmmm |
well |
| 00:26 |
VanessaE |
on the server? |
| 00:26 |
hmmmm |
on both |
| 00:27 |
sapier |
hmmm it's not gonna work on mapblock granularity I already tried this |
| 00:27 |
VanessaE |
you're gonna trifle over one byte?! |
| 00:27 |
hmmmm |
that's not just one byte |
| 00:27 |
sapier |
I had to add a separate spawn position storage with all issues to get rare mobs spawning correct |
| 00:27 |
hmmmm |
that's 25% of the most commonly used data structure in the entire engine |
| 00:27 |
VanessaE |
ok fine, 4k then |
| 00:27 |
VanessaE |
(per block) |
| 00:27 |
sapier |
I know hmmmm but that's like "let's remove the screen update it's causing most load" |
| 00:27 |
hmmmm |
besides, with RGB lights, how are you even going to get brightness? you'd need to do YCrCb conversion |
| 00:28 |
sapier |
who did add rgb lights? |
| 00:28 |
VanessaE |
ok we have maybe 2000 blocks loaded at once in worst case. that's not even 8 MB. |
| 00:28 |
hmmmm |
so what's the largest radius we're looking at here |
| 00:28 |
VanessaE |
(I'm pretty sure I've seen my server's count get close to that a few times) |
| 00:28 |
hmmmm |
larger than a mapblock? smaller than a mapblock? |
| 00:29 |
VanessaE |
hmmmm: for a light radius test? |
| 00:29 |
sapier |
largest light radius I'm looking for is about 3 nodes |
| 00:29 |
hmmmm |
for the radius tests you commonly do |
| 00:29 |
VanessaE |
hmmmm: I would say 3x3x3 nodes off the top of my head |
| 00:29 |
hmmmm |
note this isn't absolutely horrible |
| 00:29 |
sapier |
yes but block granularity is way to big |
| 00:29 |
VanessaE |
judging by what I've seen done in practice in actual users' builds |
| 00:29 |
VanessaE |
and what I've done myself |
| 00:30 |
sapier |
having only about 9 blocks loaded in singleplayer some mobs would never ever spawn |
| 00:30 |
VanessaE |
but even THAT will be too coarse for some fine tuning |
| 00:30 |
VanessaE |
(e.g. making "unit tests" so to speak, in-game) |
| 00:30 |
hmmmm |
how many of these radiuses would happen in the same mapblock |
| 00:30 |
sapier |
a lot |
| 00:30 |
hmmmm |
then it'd be worth it |
| 00:31 |
VanessaE |
depends. in a typical pipeworks/mesecons apparatus, probably 20-30. |
| 00:31 |
sapier |
if you find a way NOT to break light per node and still speed it up it'd be worth it |
| 00:31 |
VanessaE |
(usually far less) |
| 00:31 |
sapier |
mobf uses up to 20% cpu load to do this if you make it 10 times slower about 10 times less mobs will spawn |
| 00:32 |
VanessaE |
in plantlife, probably hundreds of such checks per mapblock are done |
| 00:32 |
sapier |
and of course lag issues will increase as spawning will take time from more valuable tasks |
| 00:32 |
VanessaE |
(I've never counted) |
| 00:34 |
sapier |
hmm vombie does use a radius of 0 (only spawn location) |
| 00:36 |
sapier |
big red uses 2, 10 retries, each 60 seconds, with half this time if not beeing able to spawn at least 3 within a range of 100 nodes ... which already requires separate spawn point storage |
| 00:36 |
hmmmm |
the problem i have is that the engine itself storing light information is quite useless since it's only used at one point, at mesh render time |
| 00:36 |
VanessaE |
for plantlife, knowing the light level within 2 nodes of the target would be sufficient |
| 00:37 |
hmmmm |
on the other hand mods are storing it and reading it much more often |
| 00:37 |
sapier |
no it's a basic feature used by mods |
| 00:37 |
VanessaE |
it's not useless because it's used by dozens of mods |
| 00:37 |
sapier |
light is a property of a noded it's not only something client has to display |
| 00:37 |
VanessaE |
so calculate it your fancy way, store it, and don't fret over the extra storage it takes. |
| 00:37 |
sapier |
e.g corn growing |
| 00:37 |
hmmmm |
well, it's never explicitly written to |
| 00:38 |
sapier |
most nodes never write a node type too |
| 00:38 |
sapier |
mobf for example usually doesn't modifiy exisiting nodes |
| 00:38 |
ShadowNinja |
hmmmm: Maybe you could cache the light level in a param3 that's only compiled in on the server and isn't sent to the client? |
| 00:38 |
hmmmm |
yeh but light information is implicit along with the content type |
| 00:38 |
sapier |
removing per node light information is a big step backward |
| 00:39 |
hmmmm |
ShadowNinja, that would stop working the minute we add client side scripting |
| 00:39 |
ShadowNinja |
(Or "light", since that's a lot less cryptic. |
| 00:39 |
hmmmm |
i'd rather focus on ways to get computing this very fast |
| 00:39 |
VanessaE |
hmmmm: well the client will eventually do some kind of hardware-assisted lighting rendering, right? |
| 00:40 |
hmmmm |
thought about it, no, hardware lighting doesn't help much with minetest's use case |
| 00:40 |
VanessaE |
at that point, all it needs to know is where all the light *sources* are. it doesn't have to care what the server says are the per-node light levels |
| 00:40 |
hmmmm |
sunlight can be done by hardware lighting but light sources not so much |
| 00:40 |
VanessaE |
hrm |
| 00:40 |
* VanessaE |
pokes RealBadAngel |
| 00:40 |
|
deezl joined #minetest-dev |
| 00:41 |
hmmmm |
the issue is that our world is dynamic |
| 00:41 |
deezl |
sapier, are you here? |
| 00:41 |
VanessaE |
yeah I know |
| 00:41 |
hmmmm |
this is simply something that games never did |
| 00:41 |
sapier |
yes deezl |
| 00:41 |
VanessaE |
meaning a user could potentially place thousands of light sources, while opengl et al. are limited on how many they can render. |
| 00:41 |
sapier |
is anyone about to fix the particle spawner memory leak? |
| 00:42 |
deezl |
hi, just had someone log into one of my servers with your name, was wondering if it was you |
| 00:42 |
hmmmm |
calculating light correct way is very difficult, you basically need to solve the radiosity problem each time you add a light |
| 00:42 |
deezl |
(I was doubting it) |
| 00:42 |
hmmmm |
which is like 5 differential equations |
| 00:42 |
VanessaE |
sapier: what about jin_xi/SN's irrlicht particles code? shouldn't that be finished/merged first? |
| 00:42 |
hmmmm |
the minecraft light calculation method is so cheap on the other hand |
| 00:42 |
sapier |
if it's been the big... server yes I'm trying to pinpoint a memory leak |
| 00:43 |
deezl |
oh ok, well that's good |
| 00:43 |
ShadowNinja |
sapier: No. The particles code is a mess though, and jin_xi's code needs a lot of work. |
| 00:43 |
deezl |
yes, that was my server |
| 00:43 |
sapier |
loosing about 2k on processing each particle packet? |
| 00:43 |
sapier |
that's a huge issue ;-) |
| 00:43 |
VanessaE |
sapier: you really want to see that in effect, I seem to recall the just test server had an active spawner near the spawnpoint that really set it off. |
| 00:44 |
deezl |
sapier, if it helps any, or matters at all, BigPappa's is not standard minetest_game, it is a modified version of carbone. |
| 00:44 |
sapier |
who wrote this code? |
| 00:44 |
sapier |
client has no chance to cleanup the spawners |
| 00:44 |
VanessaE |
particle spawners? jeija did I think. |
| 00:44 |
hmmmm |
that's mirciakitsune |
| 00:45 |
VanessaE |
oh right |
| 00:45 |
|
johnnyjoy joined #minetest-dev |
| 00:45 |
hmmmm |
it's so sloppy |
| 00:45 |
hmmmm |
i'm not sure why i approved that |
| 00:47 |
sapier |
hmm at least there's a clear_particles() function ... let's hope it's doing what I expect it to do ... well actually it's clearing the spawners not the particles |
| 00:47 |
sapier |
deezle thanks for this information but memory leaks still shouldn't happen ;-) |
| 00:48 |
deezl |
agreed. |
| 00:49 |
hmmmm |
so on a lighter note (pun intended) what do you guys say about merging some options in the pause menu |
| 00:49 |
hmmmm |
change password, sound volume, change keys -> Options |
| 00:49 |
VanessaE |
er... |
| 00:50 |
ShadowNinja |
hmmmm: That sounds good. |
| 00:50 |
sapier |
agreed |
| 00:50 |
VanessaE |
yeah, sounds good. |
| 00:59 |
paramat |
hmmmm sounds okay, personally i wouldn't much miss light as param2, i've written a variety of mods and have rarely used it. when it's occasionally needed in mods a slower method would be okay |
| 01:04 |
sapier |
as I said paramat for spawning a slower method would be a desaster current method is already a big problem |
| 01:06 |
|
compunerd joined #minetest-dev |
| 01:06 |
paramat |
yes this will be unpopular with those who use light level a lot, i would suggest perhaps triggering spawning a different way |
| 01:07 |
sapier |
there's no way to replace it |
| 01:07 |
sapier |
if there's no way to spawn mobs based uppon light level the only option is removing those mobs |
| 01:07 |
sapier |
meaning almost all hostile mobs dying in sunlight |
| 01:08 |
sapier |
dieing |
| 01:08 |
|
Wayward_One joined #minetest-dev |
| 01:09 |
paramat |
i'm suggesting spawn or kill them dependant on something else then, time of day .. |
| 01:09 |
sapier |
not very usefull |
| 01:09 |
hmmmm |
we don't need to copy minecraft into our grave |
| 01:09 |
sapier |
it's already hard to spawn a mob below ground |
| 01:09 |
hmmmm |
they don't have RGB light or any of the other cool stuff because they store it all in the node information |
| 01:09 |
sapier |
we don't need to remove features just because you think theyre slow either |
| 01:09 |
paramat |
i would still like to have sunlight with simple shadows (low res shadows?) by hardware lighting |
| 01:10 |
paramat |
i guess hmmmmm's method would mean a usable system without hardware sunlight, so it's not essential |
| 01:10 |
sapier |
you could use your calculation for rgb and just store brightness in node |
| 01:10 |
paramat |
(for slow computers) |
| 01:11 |
hmmmm |
no, sunlight would still be hardware lighting |
| 01:11 |
hmmmm |
sapier, how about 4 bits |
| 01:11 |
hmmmm |
or 3 |
| 01:11 |
hmmmm |
3 is the best I can do |
| 01:12 |
sapier |
3 is way to limited |
| 01:12 |
hmmmm |
8 levels of light?? |
| 01:12 |
paramat |
sorry i mean, with hmmmmm's suggestion hardware sunlight becomes optional instead of essential, so this would be good |
| 01:12 |
hmmmm |
of brightness rather |
| 01:12 |
sapier |
it's half we have now |
| 01:12 |
hmmmm |
4 of them are pretty much wasted |
| 01:12 |
sapier |
2 and those will still be wasted |
| 01:12 |
hmmmm |
why you'd need 16 levels of light for deciding where mobs spawn is beyond me... why can't you do the same with 8 |
| 01:13 |
paramat |
8 levels is good enough |
| 01:13 |
sapier |
so you have 6 levels only |
| 01:13 |
paramat |
for plant spawning too, 4 would be fine |
| 01:13 |
hmmmm |
lemme call up my buddy who's an expert at lighting |
| 01:14 |
sapier |
no they wouldn't it's like ohhh seee rendering my screen is slow lets draw everything black only to get it more fast |
| 01:14 |
hmmmm |
lol |
| 01:14 |
hmmmm |
what are you complaining about. |
| 01:14 |
sapier |
basicaly you diminish mods making decisions based uppon day night cycle |
| 01:15 |
sapier |
as well as artificial lighting |
| 01:15 |
hmmmm |
the only noticable difference here is that you'd only be able to choose between 8 levels of light instead of 16 |
| 01:15 |
|
shadowzone joined #minetest-dev |
| 01:15 |
sapier |
8 is as good as 640kb are enough memory for any application ever beeing programmed |
| 01:15 |
sapier |
and it's still 6 levels not 8 |
| 01:16 |
hmmmm |
that's like saying "there are 254 shades of gray" |
| 01:16 |
hmmmm |
"not 256" |
| 01:16 |
sapier |
why don't we just switch to monochrom mode we'd never have to cope with colors ;-) |
| 01:16 |
paramat |
6 is more than enough for a rough light level |
| 01:16 |
sapier |
no it's not |
| 01:16 |
hmmmm |
also keep in mind this is a rough light level estimate |
| 01:17 |
hmmmm |
to get a more accurate light level it'd be a bit slower |
| 01:17 |
hmmmm |
but possible |
| 01:18 |
sapier |
if you get at least a two digit percentage fps increase by doing this I'd think about it but if it's only 0.5 forget it |
| 01:18 |
hmmmm |
what about all the other advantages |
| 01:18 |
paramat |
also, i don't see coloured light as a priority, if there's a gain from not implementing that i would choose to not have it |
| 01:18 |
sapier |
I see no other advantages |
| 01:18 |
hmmmm |
truecolor lighting |
| 01:18 |
sapier |
for me it's just rendering some way to spawn mobs way less conveniant then before |
| 01:18 |
hmmmm |
indefinite light spread distance |
| 01:19 |
sapier |
if I'd get light color per node too I'd have at least another benefit do i get this information? |
| 01:19 |
hmmmm |
yes |
| 01:19 |
sapier |
so I can ask per node brightness as well as color? and this ain't horribly slow? |
| 01:20 |
hmmmm |
best part is, if the node you're querying happens to be a light source, you can do an O(1) lookup of the brightness/color :) |
| 01:20 |
hmmmm |
color is just a function of brightness |
| 01:20 |
hmmmm |
rather other way around |
| 01:20 |
sapier |
for what I know most nodes aren't light sources so don't tell optimized cases not happening very often ;-) |
| 01:21 |
sapier |
usually next light source is quite far away |
| 01:21 |
paramat |
i don't consider mob spawning a priority importance in minetest compared to general lighting, sorry =) |
| 01:21 |
sapier |
paramat as everyone does that's why mobs suffer that much |
| 01:22 |
sapier |
and mob spwaning is by far the most cpu consuming part so if you make any part of it slower it's gonna cause a huge penalty |
| 01:22 |
|
VargaD_ joined #minetest-dev |
| 01:22 |
hmmmm |
how is mob spawning so cpu consuming |
| 01:23 |
sapier |
because you have to check a lot of nodes around in regular intervals |
| 01:23 |
sapier |
light is one of the most time consuming things but checking for node types isn't much faster if it's not a single node only you have to check |
| 01:24 |
paramat |
mob spawn/kill seems only an occasionally done thing so okay to to have a slower light check. just check less often |
| 01:24 |
sapier |
e.g. if you wanna spawn a fish you need to make sure there's enough water around |
| 01:24 |
sapier |
no it's not ocassional if you have about 20 different mobs |
| 01:25 |
sapier |
even if you only do this once per 60 seconds |
| 01:25 |
sapier |
most time you don't find a valid location for the first time |
| 01:25 |
sapier |
I'd guess about 5-10 tries to find a suitable location |
| 01:26 |
sapier |
if you wanna keep population stable you don't spawn a single mob only so you're doing this more then once per spawn event |
| 01:27 |
sapier |
20*7.5*2 |
| 01:27 |
sapier |
and the 7.5 is only true on surface, to find a suitable location below ground you often need way more tries |
| 01:27 |
paramat |
i guess we need to consider the strongest arguments against, mob checks is one, spawning every plant by light level is overkill IMO so not important (sorry Vanessa), any others? |
| 01:27 |
sapier |
of course that count happens for about each mapblock |
| 01:28 |
VanessaE |
paramat: mesecons. |
| 01:28 |
paramat |
ah lght sensors |
| 01:28 |
paramat |
*light |
| 01:28 |
sapier |
paramat if you find a working faster way we can think about it but by now everyone claimed it's bad but noone did find better |
| 01:29 |
sapier |
I once tried spawning on mapgen only but ppl aren't happy if mobs don't regenerate |
| 01:30 |
paramat |
to be clear i'm playing devil's advocate a little, i'm actually undecided but think hmmmmm's idea should be seriously considered |
| 01:31 |
sapier |
I do consider it but only if it provides really good benefit, I'd not accept this for a 1fps increase |
| 01:32 |
sapier |
and if those colors he suggests can't be used because reading a single nodes color is 100 times more expensive then reading current light level it's basicaly useless for mods anyway |
| 01:35 |
|
shadowzone joined #minetest-dev |
| 01:42 |
kahrl |
sapier, why not do only 1 spawn attempt per mapblock but if successful, spawn a pack instead of a single mob |
| 01:43 |
sapier |
any suggestions how to spawn at a matching location at once? |
| 01:43 |
|
Megaf_ joined #minetest-dev |
| 01:44 |
sapier |
I already use spawn eggs doing the spawning but they still need to find locations for different mobs |
| 01:44 |
sapier |
each spawner spawns all possible mobs distributing cpu time across them |
| 01:45 |
kahrl |
for i = 1..rand(1,4) { pos = original pos + v3s16(rand(-3,3),rand(-1,1),rand(-3,3)); if pos is a suitable spawn location { spawn mob at pos }} |
| 01:45 |
kahrl |
something like that? |
| 01:45 |
sapier |
and how do you expect that random pos to match immediatly? |
| 01:46 |
kahrl |
since you already checked the original position, the new position is more likely to be valid |
| 01:46 |
sapier |
why? |
| 01:46 |
kahrl |
because if the original position is dark then the new one will be too most likely |
| 01:46 |
kahrl |
replace "dark" with "water" or whatever |
| 01:46 |
|
MinerDad joined #minetest-dev |
| 01:47 |
sapier |
I see no reason for this to be true in generic case |
| 01:47 |
sapier |
if some position is stone why should next position be stone too? |
| 01:47 |
kahrl |
because noise is continuous |
| 01:47 |
sapier |
it'd be more likely to check for height above ground |
| 01:48 |
sapier |
but It's useless to create a specialized spawner for every single mob I once had it it just didn't work so I need generic spawning |
| 01:48 |
sapier |
and making it more likely always has to make assumptions which may or may not be true |
| 01:49 |
sapier |
e.g. in vanessae's heavyly modified worls not even noise continuity is correct |
| 01:50 |
sapier |
and even if there's a way to improve hit chances it's not gonna compensate a 100 times slower light calculation in situations where you don't find a single suiteable position and still have to try |
| 01:51 |
kahrl |
if you don't find a position, don't spawn a mob |
| 01:51 |
kahrl |
on first try* |
| 01:51 |
kahrl |
simple as that |
| 01:51 |
sapier |
and then? |
| 01:51 |
sapier |
not spawn any mob at all? |
| 01:51 |
sapier |
there's always a second third .. try |
| 01:52 |
kahrl |
not in this spawn event |
| 01:52 |
kahrl |
perhaps the next one will be successful |
| 01:52 |
sapier |
which is already configurable and will cause drastically less mobs to be spawned in total |
| 01:52 |
paramat |
i don't see mesecons light sensors being particularly important either (with apologies to the authors/users) |
| 01:52 |
VanessaE |
so what you're really saying is mods aren't important at all. |
| 01:53 |
sapier |
in worst case (lots of different mobs) you won't ever get a certain mob because a block is never active long enough to even try to spawn it |
| 01:53 |
kahrl |
personally I think guaranteeing exactly one mob of each type being spawned per event is pretty boring |
| 01:53 |
kahrl |
too predictable |
| 01:53 |
sapier |
that's not a new issue it's there right now too but making spawning slower causes it to be way more of a problem |
| 01:53 |
sapier |
I don't do this karl |
| 01:53 |
sapier |
I try to spawn x mobs of one type |
| 01:54 |
sapier |
if I have cpu time left in this spawn event |
| 01:54 |
sapier |
if there's not time left nothing is spawned at all |
| 01:54 |
kahrl |
ah, okay |
| 01:55 |
sapier |
so if spawning becomes more time consuming overall mob spawn chance is reduced |
| 01:55 |
sapier |
that's why I'm oposing to making some heavyly used function drastically slower |
| 01:56 |
kahrl |
but for some reason MC can do a spawning cycle every tick (i.e. 20 per second) without completely locking up the CPU, which is why I'm wondering why it's so much more expensive in mobf |
| 01:56 |
sapier |
and at night for example light checking uses almost full cpu time |
| 01:57 |
sapier |
I don't lock up cpu too |
| 01:57 |
sapier |
problem ain't mobf but the way minetest calculates light |
| 01:58 |
sapier |
for mobf it's just reading a value that should be there |
| 01:58 |
kahrl |
I mean they are doing 1200x as many spawn cycles than mobf |
| 01:58 |
sapier |
I don't have any knowledge about minetest recalculating this each step |
| 01:58 |
kahrl |
if the default interval is 60s as you said |
| 01:58 |
kahrl |
s/than/as |
| 01:58 |
sapier |
if e.g. minetest did recalculate light in regular intervals instead of each step you could save a lot of time too |
| 01:59 |
sapier |
interval depends on mob |
| 01:59 |
Wayward_One |
ShadowNinja, just finished running minetest through valgrind's massif tool, but i have no idea how to read the results lol. should i pastebin the results here...? |
| 01:59 |
sapier |
there are mobs with 300 or more too |
| 01:59 |
sapier |
my spawning mechanism is highly configurable |
| 02:00 |
kahrl |
oh right, in MC the "once per tick" is only for hostile mobs |
| 02:00 |
kahrl |
other mobs have an interval of 20s afaik |
| 02:00 |
sapier |
I don't know how much about mc |
| 02:00 |
sapier |
well as I said I have some way less then this |
| 02:02 |
sapier |
still this is already an open issue so making it even more slow is wrong direction ;-) |
| 02:03 |
kahrl |
well this is the algorithm pretty much if you want to know: http://minecraft.gamepedia.com/Spawn#Mob_spawning |
| 02:04 |
sapier |
well I'd be glad if I could spawn in 240x240 range |
| 02:04 |
sapier |
usually I can only spawn in 32x32 |
| 02:05 |
sapier |
because everything else is out of activity range |
| 02:05 |
kahrl |
yeah that's a big difference too |
| 02:05 |
sapier |
spawning a entity just to be unloaded is useless |
| 02:05 |
sapier |
and causes lots of trouble |
| 02:06 |
sapier |
128 blocks activity range is about 4 times as much as we have |
| 02:06 |
sapier |
it'd make spawning way more easy if we did have that range |
| 02:07 |
kahrl |
I'm not sure all of those count as active |
| 02:07 |
kahrl |
could be the case those mobs just spawn and don't move or do anything until you get nearer |
| 02:08 |
sapier |
"However, hostile mobs (and some others) that move farther than 128 blocks from the nearest player will soon despawn" I'd understand this as similar concept then our activity range |
| 02:08 |
sapier |
well they have different activity ranges for different mobs so it's not exactly same |
| 02:08 |
kahrl |
not completely the same |
| 02:08 |
kahrl |
they are not saved to the mapblock/chunk (hostile mobs, anyway) |
| 02:09 |
sapier |
true |
| 02:09 |
sapier |
but I don't think this is an issue for us |
| 02:09 |
|
DuDraig joined #minetest-dev |
| 02:10 |
sapier |
why do we have a memory leak in mapblock? |
| 02:10 |
kahrl |
huh? |
| 02:10 |
sapier |
nodemetalist seems not to be freed correct |
| 02:10 |
kahrl |
ohh.. I thought that was fixed |
| 02:10 |
kahrl |
but have imagined that |
| 02:10 |
kahrl |
must have* |
| 02:11 |
sapier |
well valgrind says it's not fixed ;-) |
| 02:11 |
kahrl |
yeah, I saw that in valgrind ages ago |
| 02:11 |
kahrl |
wonder why Zeno never noticed it even though he valgrinded a lot |
| 02:12 |
sapier |
and particle spawners are still a mess ... not sure how they get lost |
| 02:12 |
sapier |
ahh |
| 02:12 |
sapier |
ok the add function doesn't even check if it already exists ... could be a chance to loose something |
| 02:13 |
Wayward_One |
speaking of valgrind, i just ran mt through massif, and i'm not sure what to do with the output, or if it's even needed still |
| 02:17 |
sapier |
well if you're looking for a memory leak valgrind would be more helpfull then massif |
| 02:17 |
|
paramat left #minetest-dev |
| 02:19 |
Wayward_One |
hmm... SN suggested massif on github, so that's what i used lol |
| 02:19 |
sapier |
hmm well post the output maybe he knows where to look at :-) |
| 02:19 |
sapier |
heap profiler usually is required if it's not a real leak |
| 02:22 |
Wayward_One |
ok, here it is: http://pastebin.com/jamrtjsj |
| 02:43 |
|
sapier left #minetest-dev |
| 03:00 |
|
Miner_48er joined #minetest-dev |
| 03:02 |
|
Tablet_One joined #minetest-dev |
| 03:33 |
|
Zeno` joined #minetest-dev |
| 03:53 |
* kahrl |
wonders what the deal with #1505 was |
| 03:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/1505 -- Update to SQLite 3.8.5 by SmallJoker |
| 03:53 |
kahrl |
why was the bundled sqlite neither updated nor removed? |
| 04:00 |
Miner_48er |
what updates are missing from it? |
| 04:01 |
kahrl |
the one we're bundling is several years old |
| 04:01 |
kahrl |
from 2011 to be exact |
| 04:02 |
Zeno` |
Isn't it because of potential compatibility problems with LuaJIT? |
| 04:03 |
kahrl |
does sqlite interact with LuaJIT in any meaningful way? |
| 04:03 |
Zeno` |
lol |
| 04:03 |
Zeno` |
of course not. I misread :) |
| 04:04 |
Zeno` |
bundled sqlite not updated... no idea why not |
| 04:05 |
kahrl |
SN discourages using it for this reason: http://irc.minetest.ru/minetest-dev/2014-07-20#i_3823030 |
| 04:05 |
kahrl |
(but not everyone knows, as the discussion at that link shows) |
| 04:06 |
Zeno` |
hmm |
| 04:06 |
Zeno` |
not really sure how updating the bundled version can hurt though, even though I see SN's point. |
| 04:06 |
kahrl |
I think we should update it for now, we can still remove it |
| 04:07 |
Zeno` |
yeah, that's what I mean |
| 04:08 |
hmmmm |
+1 for updating bundled sqlite |
| 04:11 |
kahrl |
https://github.com/kahrl/minetest/commit/dc90dd1d051ba62789df4224f92dfe47c4af75d7 |
| 04:11 |
kahrl |
will push ^ in a few minutes then |
| 04:37 |
|
MinerDad joined #minetest-dev |
| 04:42 |
hmmmm |
hmm |
| 04:42 |
hmmmm |
paramat, i think i see the problem with the light |
| 04:44 |
hmmmm |
nope, i know *exactly* what the issue is |
| 04:44 |
hmmmm |
grr |
| 04:45 |
hmmmm |
this is tough |
| 04:47 |
hmmmm |
those ores not lighting up completely are in a part of a cave carved into the upper bordering block of the chunk directly below the one the ore exists in |
| 04:47 |
hmmmm |
they never git hit by calcLighting() |
| 04:47 |
hmmmm |
because I don't pass that upper border plane of blocks to calcLighting since that needs to be the overtop for sunlight propogation |
| 04:48 |
hmmmm |
so if you calcLighting the entire full area, you'll get complete darkness because the overtop will never exist since it's outside of the vmanip |
| 04:48 |
hmmmm |
but the ores will light up correctly |
| 04:57 |
hmmmm |
so technically the ore has a param1 of 0, it's just that the mesh making code takes the light value of the content instead of the param1 if it's a light source |
| 05:00 |
|
MinerDad joined #minetest-dev |
| 05:01 |
|
MinerDad joined #minetest-dev |
| 05:40 |
|
paramat joined #minetest-dev |
| 05:40 |
paramat |
hmmmm i'm not so sure |
| 05:41 |
paramat |
in my mapgen https://github.com/paramat/noisegrid every light source has the problem, where-ever it is within a mapchunk, above or below sea level |
| 05:43 |
paramat |
if you disable the ABMs that spread the light you can see. lights in road tunnel roofs and luxore in fissures below ground |
| 05:44 |
paramat |
the 'spread light' ABMs are in functions.lua |
| 05:45 |
hmmmm |
paramat, try it yourself. |
| 05:45 |
hmmmm |
change calc_lighting to calculate the entire voxelmanip area, not just the central chunk |
| 05:45 |
hmmmm |
no sunlight but your ores sure will work |
| 05:46 |
paramat |
ah okay perhaps i misunderstood |
| 05:47 |
paramat |
it sounded like you were saying the only affected nodes were in particular parts of a mapchunk, which is untrue |
| 05:50 |
paramat |
will try |
| 06:07 |
paramat |
i edited the mod to have vm:calc_lighting({x=minp.x-16, y=minp.y-16, z=minp.z-16},{x=maxp.x+16, y=maxp.y+16, z=maxp.z+16}) but still doesn't work |
| 06:08 |
paramat |
landscape is dark with occasional light patches |
| 06:10 |
paramat |
is it because i have 'vm:set_lighting({day=0, night=0})' just before calc_lighting? |
| 06:10 |
paramat |
^ that seems to be essential for lua mapgen lighting to work properly |
| 06:10 |
hmmmm |
no, but it's recommended that you set mapgen flags to nolight instead of zeroing the light out |
| 06:11 |
hmmmm |
saves some execution time by doing less work |
| 06:12 |
paramat |
okay will do in future, but that shouldn't make a difference? |
| 06:12 |
hmmmm |
nope, it shouldn't |
| 06:13 |
paramat |
i can confirm every light soure node in every possible position in a mapchunk is still buggy |
| 06:13 |
paramat |
*source |
| 06:13 |
hmmmm |
by "is still buggy", what do you mean exactly |
| 06:13 |
hmmmm |
like what was happening with the ore in the screenshot you pasted or what? |
| 06:13 |
paramat |
yeah |
| 06:14 |
paramat |
light source node looks bright but light doesnt spread more than say 0.5 nodes |
| 06:14 |
|
selat joined #minetest-dev |
| 06:14 |
hmmmm |
i'll have to check it out but i think something might be going wrong with the mod itself because the code being executed is identical to internal mapgen code |
| 06:15 |
paramat |
this bug happens in several of my mapgens, could be my way of coding i guess |
| 06:26 |
hmmmm |
hey paramat, i was looking at your mapgen a little closer and i noticed that in the definition of your ore you don't have light_propgates = true |
| 06:26 |
hmmmm |
that could be the issue here |
| 06:26 |
paramat |
oh man i'll try |
| 06:27 |
paramat |
okay for singlenode mapgens i will use minetest.set_mapgen_params({mgname="singlenode", flags="nolight"}) |
| 06:28 |
paramat |
i got into the habit of 'vm:set_lighting({day=0, night=0})' because my earlier mapgens created a layer above a normal v6 world |
| 06:29 |
paramat |
where that is essential |
| 06:30 |
paramat |
.. to set no light only in the mapchunks i was generating |
| 06:32 |
hmmmm |
yeah I think it would be a huge problem if you don't set your light to propagate because your mapgen would actually have the same problem if you tried the old calcLighting() |
| 06:33 |
paramat |
paramtype = "light" is in torch and lava definitions, that sets light to propagate |
| 06:37 |
paramat |
phew it's fixed, thanks |
| 06:37 |
paramat |
big relief |
| 06:38 |
paramat |
one less bug for you to tackle |
| 06:38 |
|
leat joined #minetest-dev |
| 06:44 |
hmmmm |
hmm.. VoxelManipulator::spreadLight() doesn't have the problem i was explaining earlier because it doesn't respect the specified area boundaries, it'd just try to propogate the light 'upstrairs' and if it fails (blows an InvalidPositionException) just continues on |
| 06:44 |
hmmmm |
but predictably it misses out on light sources in the overtop |
| 06:46 |
paramat |
when originally creating my glowing nodes i must have not realised the importance of 'paramtype = "light"' and left that out, despite it being in the torch definition |
| 06:46 |
hmmmm |
I can fix your river light problem, the V7 caves, and the ore light issue |
| 06:49 |
paramat |
great. yes river water at y = 47 is dark |
| 06:51 |
paramat |
i will add a note to lua-api.txt about setting paramtype = "light" for light sources |
| 06:53 |
paramat |
lua-api.txt was just beginning to look good and readable, now it's in horrible MD format |
| 06:53 |
hmmmm |
i don't think the md format is too horrible |
| 06:53 |
hmmmm |
it reads mostly like regular text |
| 06:58 |
paramat |
guess it's a personal thing, i am very visually sensitive and prefer simplicity, i get visually overwhelmed easily |
| 06:58 |
hmmmm |
ahhh the v5 overtop thing |
| 06:58 |
hmmmm |
hrmmmmmm |
| 06:59 |
hmmmm |
i know how to solve this |
| 07:03 |
|
T4im joined #minetest-dev |
| 07:05 |
hmmmm |
haha |
| 07:05 |
hmmmm |
dungeons really wreak havoc on mapgens |
| 07:07 |
hmmmm |
awesome! it works perfectly |
| 07:16 |
paramat |
https://cdn.mediacru.sh/I/I4nkyaIHgODw.png 'levels' mod with a 1kn spiky tower |
| 07:17 |
hmmmm |
cool stuff |
| 07:17 |
hmmmm |
i'm going to work on sunlight producing shadows that fade out rather than the opposite |
| 07:18 |
hmmmm |
i am aware that "fixLight()" would break this effect but in the common case it'd work as intended |
| 07:20 |
paramat |
shadow decay yes please |
| 07:21 |
paramat |
https://cdn.mediacru.sh/-/-k6m-ogUBmkF.png small spike nicely merging with nearby terrain |
| 07:21 |
hmmmm |
do they normally merge? |
| 07:27 |
paramat |
i wasn't expecting the spike to melt into the terrain like that |
| 07:31 |
paramat |
it seems the spikes have a cylindrical volume around them which increases the node 'densities', and so inflate any nearby terrain causing a merge .. |
| 07:32 |
hmmmm |
alright i sufficiently tested this BS |
| 07:40 |
hmmmm |
:)!!!!! https://github.com/minetest/minetest/commit/54713cbb475f9dcf5b59dd3d0b0dc52cf62d25e2 |
| 07:43 |
|
chchjesus joined #minetest-dev |
| 07:44 |
paramat |
good work, very productive night |
| 07:46 |
paramat |
will test this later |
| 08:00 |
|
chchjesus joined #minetest-dev |
| 08:09 |
|
paramat left #minetest-dev |
| 08:09 |
|
leat joined #minetest-dev |
| 08:12 |
hmmmm |
wooh |
| 08:12 |
hmmmm |
i just cleared like 7 issues |
| 08:13 |
|
Calinou joined #minetest-dev |
| 08:24 |
chchjesus |
neat! |
| 08:24 |
chchjesus |
hmmmm++ |
| 08:25 |
hmmmm |
:) |
| 08:25 |
hmmmm |
https://github.com/minetest/minetest/commit/ef8ed5d127f2c698586efdfd254c8e5c7ba66f19 |
| 08:25 |
hmmmm |
https://github.com/minetest/minetest/commit/8eb9cebdd058c7df0c1735cd083f09d962c7bb84 |
| 08:30 |
hmmmm |
https://github.com/minetest/minetest/commit/6fdb32361a01ed385b36f941f4ad0d7e32ea288d |
| 08:31 |
hmmmm |
oh shoot, that last one is going to change the protocol version, isn't it |
| 08:31 |
|
selat joined #minetest-dev |
| 08:31 |
hmmmm |
well it's a good time for that anyway |
| 08:32 |
|
Hunterz joined #minetest-dev |
| 08:32 |
hmmmm |
actually nevermind, it never gets serialized |
| 08:33 |
Calinou |
“nonsense†|
| 08:33 |
Calinou |
I agree it was too game-specific, but respect other developers please |
| 08:33 |
hmmmm |
he doesn't respect any of us |
| 08:34 |
hmmmm |
i don't see why i should afford him any respect. and none of that "be the bigger man" stuff. |
| 08:59 |
chchjesus |
hmmmm: Who? |
| 09:08 |
|
Krock joined #minetest-dev |
| 09:21 |
|
kilbith joined #minetest-dev |
| 09:22 |
|
nore joined #minetest-dev |
| 09:47 |
|
ImQ009 joined #minetest-dev |
| 09:56 |
|
ImQ009 joined #minetest-dev |
| 10:27 |
|
jluc joined #minetest-dev |
| 10:52 |
|
Zeno` joined #minetest-dev |
| 10:54 |
|
jin_xi joined #minetest-dev |
| 11:18 |
|
roniz joined #minetest-dev |
| 12:16 |
|
Ritchie joined #minetest-dev |
| 12:38 |
|
kilbith joined #minetest-dev |
| 13:43 |
|
ImQ009 joined #minetest-dev |
| 13:44 |
|
Zeno` joined #minetest-dev |
| 13:53 |
|
Wayward_One joined #minetest-dev |
| 13:59 |
|
alexxs joined #minetest-dev |
| 14:01 |
|
roniz joined #minetest-dev |
| 14:01 |
|
PilzAdam joined #minetest-dev |
| 14:08 |
|
ImQ009 joined #minetest-dev |
| 14:20 |
Zeno` |
PilzAdam, Some of the aliases in the alias.lua files are not there for backwards compatibility (e.g. STSword), so putting them in legacy.lua is wrong. |
| 14:20 |
Zeno` |
What are they in there for? |
| 14:21 |
PilzAdam |
the /giveme command |
| 14:25 |
|
Wayward_One joined #minetest-dev |
| 14:44 |
|
rubenwardy joined #minetest-dev |
| 14:49 |
|
roniz joined #minetest-dev |
| 14:58 |
Zeno` |
I think version numbers (of the engine) should be available to mods |
| 14:58 |
Zeno` |
This is how every other engine/lib in the world works |
| 14:59 |
Zeno` |
engine/game/lib |
| 14:59 |
Zeno` |
If other software did not allow querying of the version the whole makefile/cmake/etc/etc would fall apart and be useless |
| 15:00 |
Zeno` |
Even minetest queries the OpenGL version |
| 15:23 |
|
ImQ009 joined #minetest-dev |
| 15:34 |
celeron55 |
Zeno`: it's a political issue; i don't want to centralize minetest development in a way that breaks forks; everything that has a version has a central authority who decides what goes to which version |
| 15:34 |
celeron55 |
s/everything/every API/g |
| 15:35 |
celeron55 |
cutting off competition by political means is always a very bad idea for general progress |
| 15:35 |
celeron55 |
and you can't even seriously disagree with that |
| 15:35 |
Zeno` |
no, I can't |
| 15:36 |
Zeno` |
that makes sense. Thanks |
| 15:37 |
|
sapier joined #minetest-dev |
| 15:38 |
sapier |
https://github.com/minetest/minetest/pull/2043 merging in a few minutes (Android only change) |
| 15:39 |
celeron55 |
Zeno`: currently minetest's modding api and mods are such that anyone can fork mientest and continue development to a better way without having to do *any* tricks whatsoever to maintain compatibility |
| 15:40 |
celeron55 |
i belive this forces people including me to "keep it real" |
| 15:40 |
Zeno` |
yep, I understand the argument now that you've made it clear |
| 15:41 |
celeron55 |
also, as you mentioned opengl, it actually partly does the same: no program ever checks whether it supports the drivers by checking the opengl version number; they check if the particular extensions are supported that they need (and the extensions can be added by anyone and then later adopted by others) |
| 15:41 |
celeron55 |
(or, they can, but it's bad behavior) |
| 15:42 |
celeron55 |
the version just gives a general idea |
| 15:42 |
|
kilbith joined #minetest-dev |
| 15:44 |
|
Calinou joined #minetest-dev |
| 15:51 |
sapier |
on opengl the version number is almost useless as most features are "optional" |
| 15:53 |
|
selat joined #minetest-dev |
| 15:54 |
|
hmmmm joined #minetest-dev |
| 16:06 |
sapier |
ShadowNinja if I ever meet you in person I'm gonna kick your ass this is the 3 time you break the android menu by doing some nonsense cleanup without testing |
| 16:07 |
sapier |
there's been a reason why it was a separate menu, this way you could test it on pc where debugging is way more easy then on android devices |
| 16:14 |
sapier |
And who the hell tells simple menu is android only?! |
| 16:15 |
sapier |
I never seen a rule pc menus have to be overloaded and complex ;-P |
| 16:19 |
|
DFeniks joined #minetest-dev |
| 16:29 |
|
puhfa joined #minetest-dev |
| 16:53 |
|
roniz joined #minetest-dev |
| 16:54 |
Zeno` |
sapier, I have a cunning plant |
| 16:54 |
Zeno` |
err plan |
| 16:55 |
Zeno` |
Add comments to sections that sections of code that are the for a reason but maybe not obvious :p |
| 16:55 |
sapier |
I can't do more then telling him this in person |
| 16:55 |
sapier |
if someone doesn't understand it this way more text wont help |
| 16:55 |
sapier |
ls |
| 16:55 |
Zeno` |
You can't add a comment in the code? |
| 16:56 |
sapier |
we're talking about a full file not some part of code |
| 16:58 |
Zeno` |
so? |
| 16:58 |
Zeno` |
Is a file not some part of code? :p |
| 16:58 |
sapier |
well is there a line in game.cpp about this file beeing required? |
| 16:58 |
Zeno` |
no idea off the top of my head. Is there? |
| 16:59 |
sapier |
have a look at it |
| 17:01 |
|
ImQ009 joined #minetest-dev |
| 17:02 |
Zeno` |
not really sure what I'm looking for. The pause menu? |
| 17:02 |
|
PilzAdam joined #minetest-dev |
| 17:04 |
Zeno` |
are we talking about https://github.com/minetest/minetest/commit/c4e393deea4f1a6d242a3fdf392c463ed5a3b58d ? |
| 17:04 |
sapier |
yes |
| 17:04 |
sapier |
which is a non sense change as the simple menu is not by defininition android only |
| 17:06 |
Zeno` |
hmm, fair enough |
| 17:06 |
sapier |
so now we have a perfectly fine simplified menu which can only be used if you claim to run on android :-( |
| 17:08 |
Zeno` |
yes :( |
| 17:08 |
Zeno` |
Anyway I must sleep |
| 17:08 |
sapier |
good night |
| 17:14 |
|
kaeza joined #minetest-dev |
| 17:44 |
|
Lugal joined #minetest-dev |
| 18:01 |
|
Wuzzy joined #minetest-dev |
| 18:02 |
Wuzzy |
Hi there. I wonder if something in the auth.txt format has changed lately significantly so that it breaks 0.4.11 worlds |
| 18:03 |
Krock |
a timestamp has been added but that shouldn't be a problem |
| 18:05 |
Calinou |
apparently it is for Wuzzy |
| 18:05 |
Calinou |
<Gael-de-Sailly> 11:51:45: ERROR[main]: /usr/share/minetest/builtin/game/auth.lua:48: Invalid line in auth.txt: "singleplayer::" |
| 18:05 |
Wuzzy |
My Tutorial World does not load in 663e42ca… but it loads in 0.4.11. |
| 18:06 |
Wuzzy |
I shall post error output soon |
| 18:07 |
Wuzzy |
Here it is: http://lpaste.net/raw/117753 |
| 18:07 |
Wuzzy |
This is the error I get when I try to load Tutorial World in 663e42ca… |
| 18:08 |
rubenwardy |
https://github.com/minetest/minetest/blob/master/builtin/game/auth.lua#L48 |
| 18:09 |
rubenwardy |
It's because there is no password specified, it seems |
| 18:09 |
rubenwardy |
Did it work after last_login was added? |
| 18:09 |
Wuzzy |
what is this? |
| 18:10 |
rubenwardy |
what? |
| 18:10 |
Wuzzy |
oh, for you, here is the content of auth.txt of Tutorial World |
| 18:10 |
Wuzzy |
“singleplayer::†|
| 18:10 |
rubenwardy |
yes |
| 18:10 |
Wuzzy |
that's all |
| 18:10 |
rubenwardy |
singleplayer:password:privs:last_login |
| 18:10 |
Wuzzy |
I tried deleting auth.txt and reload |
| 18:10 |
Wuzzy |
it loaded again o_O |
| 18:11 |
rubenwardy |
It is because there is no password string there. |
| 18:11 |
Wuzzy |
and generated a new auth.txt |
| 18:11 |
PilzAdam |
its probably because string.split() is used instead of match() |
| 18:11 |
Wuzzy |
Generated auth.txt is “singleplayer::interact,shout:1420398524†|
| 18:11 |
Wuzzy |
plus a line break |
| 18:11 |
rubenwardy |
And does that work? |
| 18:11 |
Wuzzy |
yes |
| 18:12 |
Wuzzy |
But why did “singleplayer::†ever work in 0.4.11 in the first place? xD |
| 18:13 |
Wuzzy |
anyways, I think I provided enough proof to show that 0.4.11 and older worlds are currently not compatible with the bleeding edge |
| 18:15 |
rubenwardy |
https://github.com/minetest/minetest/commit/ab55da589c27e65e54956b32a1550e21169447ae |
| 18:15 |
rubenwardy |
That's the problem |
| 18:15 |
rubenwardy |
Changed string:split |
| 18:15 |
rubenwardy |
* probably the problem |
| 18:15 |
PilzAdam |
it seems that string.split() with include_empty does not return an empty string after the last delimiter |
| 18:15 |
PilzAdam |
^ ShadowNinja |
| 18:16 |
Wuzzy |
ok. Say my name if you fixed the bug so I can pull it and test it on Tutorial World |
| 18:17 |
|
Gethiox joined #minetest-dev |
| 18:19 |
ShadowNinja |
kaeza: ^ |
| 18:19 |
rubenwardy |
Lol |
| 18:19 |
ShadowNinja |
sapier: Include things like this in your local tree: https://github.com/minetest/minetest/commit/21ee434832126f288c58f5a9cd2a3b509946319c |
| 18:20 |
ShadowNinja |
sapier: Or just modify init.lua. It's a temporary change after all. |
| 18:20 |
ShadowNinja |
And my commit was definitely an improvement, seing as you added that back with two lines of code instead of copying the whole file.. |
| 18:21 |
sapier |
no I will not do this because I already know how often this gonna be merged |
| 18:21 |
sapier |
especially as your change is crap |
| 18:21 |
sapier |
you made something not beeing android specific artificially android specific |
| 18:22 |
sapier |
there'*s not a single reason why a simple menu shouldn't be used on pc mac or any other os |
| 18:23 |
ShadowNinja |
sapier: init_android.lua doesn't suggest Android-specific to you? Because it sure does to me. |
| 18:24 |
sapier |
well if you did one time read what you change you'd have relaized that filename is wrong and not content |
| 18:24 |
ShadowNinja |
sapier: And I agree, a lot of Android-specific things shouldn't depend on that particular OS. |
| 18:24 |
ShadowNinja |
But I didn't write the Android stuff. |
| 18:25 |
PilzAdam |
ShadowNinja, I agree with sapier, init_android.lua should have just been renamed to init_simple.lua or so |
| 18:25 |
sapier |
tell me where I used ANDROID where it ain't required? because I specially did look at which features are specific to android and which could be used elsewhere |
| 18:25 |
ShadowNinja |
sapier: You can change it to use simple_menu = true/false in minetest.txt. |
| 18:25 |
ShadowNinja |
sapier: Please make it false on Android though. |
| 18:25 |
rubenwardy |
s/minetest.txt/minetest.conf ? |
| 18:25 |
sapier |
ShadowNinja: because of what reason? we already have a setting where you can enable any menu not only those provided in builtin |
| 18:26 |
ShadowNinja |
PilzAdam: Have you seen the old init_android.lua? It was just `cp init.lua init_android.lua` with minor modifications. |
| 18:26 |
ShadowNinja |
PilzAdam: Not only that, but it bypassed the builtin init.lua, breaking things like print() and the locale. |
| 18:26 |
sapier |
ShadowNinja: true because simple menu did provide similar things |
| 18:26 |
ShadowNinja |
rubenwardy: Yes. |
| 18:26 |
PilzAdam |
ah, didn't see that |
| 18:26 |
rubenwardy |
ok |
| 18:27 |
sapier |
new one will fake android switch wich is just crap but best without resplitting it again |
| 18:27 |
PilzAdam |
ShadowNinja, there should still be 2 different init_*.lua, since you can choose your menu script in minetest.conf |
| 18:27 |
PilzAdam |
no need to check any OS for that |
| 18:27 |
ShadowNinja |
sapier: Please make a PR, or at least post a patch here, before changing ti further. |
| 18:28 |
sapier |
I already changed it so I can fix the bugs in there again if you don't break this a 4th time I don't intend do change anything there |
| 18:28 |
PilzAdam |
ShadowNinja, maybe move the duplicated parts to a init_all.lua or so? |
| 18:28 |
ShadowNinja |
PilzAdam: Just have simple_menu = true/false or menu_type = normal/simple in minetest.conf instead, no need to change the file loaded. |
| 18:29 |
sapier |
ShadowNinja: NO |
| 18:29 |
sapier |
why ANOTHER menu config setting |
| 18:29 |
PilzAdam |
why provide extra settings for functionality that is already provided? |
| 18:29 |
sapier |
next time we have a new menu for tablets then we add tablet_menu= true false? |
| 18:29 |
ShadowNinja |
sapier: It was broken to begin with, and http://xkcd.com/1172/ |
| 18:29 |
PilzAdam |
add a comment that you can point it to the simple.lua file, thats enough |
| 18:30 |
ShadowNinja |
PilzAdam: that's a lot simpler than telling users to set the script path to a different file. |
| 18:30 |
hmmmm |
yeehaw... |
| 18:31 |
sapier |
still the script path is already there and provides the required functionality |
| 18:31 |
ShadowNinja |
sapier: Or menu_type = tablet, or better yet just make the menu adapt by itself. |
| 18:31 |
sapier |
AND script path is the better way doing it because it enables total conversions to write their own menu |
| 18:31 |
sapier |
why two settings for same thing? |
| 18:32 |
sapier |
still if you want to ADD your nonsense menu_type, do it but don't expect me to consider it as a sane solution |
| 18:32 |
hmmmm |
maybe there should be a device profile setting that's a setting and gets autodetected if not present |
| 18:32 |
ShadowNinja |
sapier: Yes, but that's only intended for anvanced users that want to replace the whole menu. It's a much more complicated setting than what I'm proposing. |
| 18:32 |
hmmmm |
device_type = tablet, device_type = smartphone, etc.. in addition to setting the menu stuff it'll load performance profiles to enable/disable certain things |
| 18:32 |
ShadowNinja |
IMO wo shouldn't have two menu styles in the first place. |
| 18:32 |
hmmmm |
I think it's a good idea |
| 18:32 |
ShadowNinja |
we* |
| 18:33 |
sapier |
same as last time as long as you don't break things I don't really care ... sadly you did it again |
| 18:33 |
hmmmm |
the alternative is to have one menu that works with both mobile and desktop and lots of things that work for desktop don't work for mobile |
| 18:33 |
sapier |
that's not gonna work |
| 18:33 |
hmmmm |
this is how you get firefox-type fuckups |
| 18:33 |
ShadowNinja |
hmmmm: Some smartphones are really powerfull, some are weak, some have big screens, others tiny... |
| 18:33 |
hmmmm |
say no to australis for minetest |
| 18:33 |
sapier |
range of screen sizes and dpi is just to big |
| 18:33 |
VanessaE |
jesus fuck. stop arguing and just fix the problem, guys |
| 18:34 |
|
roniz joined #minetest-dev |
| 18:34 |
VanessaE |
two menu files. a config option to select which one is used for the platform in question. default to the "complex"/PC one if no config option is specified. |
| 18:34 |
VanessaE |
it does NOT need to be more complicated than that. |
| 18:34 |
rubenwardy |
"Jesus fuck" |
| 18:34 |
hmmmm |
what, I say that sometimes |
| 18:34 |
Wuzzy |
by the way, how is “singleplayer::†in auth.txt supposed to work/what does it mean? |
| 18:35 |
ShadowNinja |
hmmmm: The desktop menu works fine on Android AFAIK, and I prefer it because the Android(/"simple") one only lets you manage one world. |
| 18:35 |
hmmmm |
VanessaE: I think it should autodetect if not present |
| 18:35 |
sapier |
we already have two menus and default to the complex one |
| 18:35 |
PilzAdam |
ShadowNinja, kaeza, about that auth.txt thing: I just tested it, and ab55da589c27e65e54956b32a1550e21169447ae definetly broke the old behaviour that returned an additional "" after the last ":" |
| 18:35 |
hmmmm |
ShadowNinja, does that hold true for lower-DPI devices? |
| 18:35 |
VanessaE |
hmmmm: I'd prefer that too but as we've seen in the past, auto-detect isn't as graceful as one would like it to be. |
| 18:35 |
hmmmm |
it should be pretty easy to detect mobile |
| 18:35 |
hmmmm |
and reliable |
| 18:35 |
ShadowNinja |
Wuzzy: user="singleplayer", password="", privs = {} |
| 18:35 |
sapier |
ShadowNinja: desktop menu doesn't work at all at low screensize android devices |
| 18:36 |
VanessaE |
hmmmm: that's the keyword, "should" :-) |
| 18:36 |
ShadowNinja |
hmmmm: It will probably be hard to use, but the Android menu is the same size IIRC. |
| 18:36 |
sapier |
hmmmm I agree it "should" but in practice it's almost impossible to always find correct settings automaticaly |
| 18:36 |
ShadowNinja |
hmmmm: (or at least very close) |
| 18:36 |
PilzAdam |
Wuzzy, you could test your world with 86cfbc21da10e9984a1b9f8f2f5bf259fba5efb9 and then with ab55da589c27e65e54956b32a1550e21169447ae to confirm that the latter one broke it |
| 18:36 |
VanessaE |
rubenwardy: that's a short form of "jesus fucking christ". |
| 18:37 |
sapier |
ShadowNinja: no because of important buttons aren't visible on some low screen size devices |
| 18:37 |
rubenwardy |
I believe that's called masturbation |
| 18:37 |
VanessaE |
lol |
| 18:37 |
hmmmm |
I always thought it was when you had a situation where you need to say "jesus christ" but you're super flabbergasted at whatever it is |
| 18:37 |
Wuzzy |
ShadowNinja: Weird. That would mean no interact either. But I know in Tutorial World I amsolutely can interact with “singleplayer::†as auth.txt |
| 18:37 |
Wuzzy |
PilzAdam: I am on my way |
| 18:37 |
VanessaE |
hmmmm: indeed. |
| 18:37 |
rubenwardy |
Wuzzy, default_privs in minetest.conf |
| 18:38 |
hmmmm |
ugh |
| 18:38 |
Wuzzy |
oh shit. This means I need to update. |
| 18:38 |
hmmmm |
really hate typing |
| 18:38 |
ShadowNinja |
Wuzzy: You get all privs that aren't give_to_singleplayer=false, even if they're not in auth.txt. |
| 18:38 |
hmmmm |
ManualMapVoxelManipulator |
| 18:38 |
sapier |
crap new ssl version doesn't work after cleaning all |
| 18:38 |
hmmmm |
AbstractManualMapVoxelManipulatorManagerFactory |
| 18:38 |
Wuzzy |
ShadowNinja, rubenwardy: WTF? |
| 18:39 |
sapier |
<< leaving to fix the ssl issue ... DONT break menu again! |
| 18:39 |
Wuzzy |
You gave me 2 different answers |
| 18:39 |
|
sapier left #minetest-dev |
| 18:39 |
ShadowNinja |
Wuzzy: -> #minetest |
| 18:39 |
hmmmm |
what's the most efficient way to break the menu? |
| 18:39 |
rubenwardy |
oh |
| 18:39 |
rubenwardy |
ShadowNinja is right |
| 18:39 |
rubenwardy |
hmmmm: core = core / 0 |
| 18:39 |
ShadowNinja |
hmmmm: error() in init.lua |
| 18:39 |
hmmmm |
:D |
| 18:41 |
VanessaE |
stick a spurious comma somewhere ;) |
| 18:41 |
VanessaE |
if you wanna both break it and be evil about it ;) |
| 18:41 |
ShadowNinja |
hmmmm: Actually, running ./bin/minetest-noexist is even faster :-P |
| 18:41 |
rubenwardy |
IMO, the menu is currently too techie and not enough gamie. Most games use buttons instead of tabs.https://jarime.files.wordpress.com/2011/12/terraria6.png |
| 18:42 |
rubenwardy |
But it doesn't matter that much |
| 18:45 |
hmmmm |
https://github.com/kwolekr/minetest/commit/10d24b48f387a642ceea85d3703748c46f34c78e |
| 18:49 |
|
Miner_48er joined #minetest-dev |
| 18:50 |
|
n4x joined #minetest-dev |
| 18:50 |
Wuzzy |
PilzAdam: I tested it for both commits. It works in the first one but it fails in the second one. |
| 18:51 |
PilzAdam |
q.e.d. |
| 18:53 |
Wuzzy |
ok, just tell my name in chat when you fixed it yadda yadda. Or should I open an issue on GitHub? |
| 18:53 |
|
ElectronLibre joined #minetest-dev |
| 18:58 |
ShadowNinja |
#2046 |
| 18:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/2046 -- Remove included SQLite3 by ShadowNinja |
| 18:59 |
ShadowNinja |
I also wrote a version for JsonCpp, but I had trouble getting it to work (CMake couldn't find the include directory, but it found the library fine) |
| 19:11 |
|
shadowzone joined #minetest-dev |
| 20:21 |
|
MinetestForFun joined #minetest-dev |
| 20:26 |
|
DFeniks joined #minetest-dev |
| 20:38 |
|
ImQ009 joined #minetest-dev |
| 20:38 |
|
Player_2 joined #minetest-dev |
| 21:00 |
|
prozacgod joined #minetest-dev |
| 21:09 |
|
Amaz joined #minetest-dev |
| 21:10 |
|
zat joined #minetest-dev |
| 21:22 |
|
ImQ009 joined #minetest-dev |
| 21:25 |
|
ElectronLibre left #minetest-dev |
| 21:35 |
ShadowNinja |
http://sprunge.us/ZVPa?diff |
| 21:36 |
ShadowNinja |
Any objections? |
| 21:36 |
hmmmm |
nope |
| 21:36 |
sfan5 |
looks good |
| 21:36 |
hmmmm |
probably should do the same thing for decorations though |
| 21:41 |
ShadowNinja |
Alright, I'll do that. I'll see if there's a make_redistration_storer or similar or make it though. |
| 21:45 |
|
blaise joined #minetest-dev |
| 22:00 |
|
cib0 joined #minetest-dev |
| 22:02 |
|
blaise joined #minetest-dev |
| 22:46 |
|
exio4 joined #minetest-dev |
| 22:52 |
|
kaeza joined #minetest-dev |
| 22:53 |
kaeza |
PilzAdam, hm? |
| 22:54 |
PilzAdam |
kaeza, string.split(":", ":", true) should return {"", ""} instead of just {""} |
| 23:06 |
kaeza |
PilzAdam, oops |
| 23:06 |
kaeza |
PilzAdam, https://github.com/minetest/minetest/blob/master/builtin/common/misc_helpers.lua#L181 --> s/len/len+1/ |
| 23:06 |
kaeza |
guess the test suite missed some cases... |
| 23:08 |
|
MichaelRpdx joined #minetest-dev |
| 23:11 |
kaeza |
ShadowNinja, https://github.com/minetest/minetest/pull/2047 |
| 23:19 |
|
paramat joined #minetest-dev |
| 23:20 |
paramat |
hmmmm, https://github.com/minetest/minetest/issues/1727#issuecomment-68627007 |
| 23:21 |
|
younishd joined #minetest-dev |
| 23:29 |
paramat |
any mod that uses lvm to add mapchunks to a v5/6/7 world has to use vm:set_lighting({day=0, night=0}) i'll test such a mod v. soon |
| 23:35 |
paramat |
https://cloud.githubusercontent.com/assets/3686677/5607999/557f6c48-946a-11e4-8c51-e8c93dafb629.png closeup |
| 23:39 |
|
proller joined #minetest-dev |
