| Time |
Nick |
Message |
| 00:05 |
Taoki |
What the? In minetest.sound_play, toplayer is being ignored |
| 00:05 |
Taoki |
A sound that was supposed to be triggered for another player was triggered for me |
| 00:05 |
Taoki |
Any idea what is wrong? |
| 00:06 |
Taoki |
minetest.sound_play(def.ambience, {toplayer = name, loop = true}) |
| 00:06 |
Taoki |
That didn't loop for player with name "name", also for me |
| 00:09 |
BlockMen |
its "to_player" https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L219 |
| 00:09 |
Taoki |
oh |
| 00:09 |
Taoki |
My mistake then, sorry |
| 00:10 |
Taoki |
BlockMen: It takes a player name as an argument also, right? Not necessarily the player entity |
| 00:11 |
Taoki |
Sorry, the API said that already >.> |
| 00:22 |
Taoki |
celeron55: Something caused your server to shut down. I could only see the **Server shutting down** message as an user. But from what I know, that typically happens when it crashes. |
| 00:22 |
Taoki |
It wasn't my mod though, honest! It's his fault *points to random other dev* (don't think it was Creatures though, but if it was let me know the error please) |
| 00:23 |
|
BlockMen left #minetest-dev |
| 02:46 |
ShadowNinja |
sfan5: So, the _game rules are largely identical to the core rules. Mostly just approval changes by the look of it. |
| 03:06 |
|
alexxs joined #minetest-dev |
| 03:25 |
|
kaeza joined #minetest-dev |
| 03:37 |
|
cg72 joined #minetest-dev |
| 04:10 |
Megaf |
well, I managed to compile minetest for android here, thing is, I think it compile only the ARM version, how and where I change the CPU architecture I want to support? |
| 04:14 |
|
Piggybear87 joined #minetest-dev |
| 04:24 |
|
Piggybear87 left #minetest-dev |
| 05:10 |
hmmmm |
I'm wondering how beneficial it would be to check for the presence of a block in the db using a bloom filter |
| 05:11 |
hmmmm |
could somebody who has LevelDB and/or Redis check the average amount of time it takes to check the presence of a block (e.g. average time a loadBlock failure takes) |
| 05:11 |
|
proller joined #minetest-dev |
| 05:12 |
hmmmm |
if a similar structure is constructed by the databases and maintained in memory, it wouldn't be beneficial, and instead i should use the database to check for the presence of a block in the db |
| 05:13 |
hmmmm |
it'd also be nice to find the amount of blocks popular servers have in their maps. |
| 05:16 |
hmmmm |
according to wikipedia, m = (n * ln p) / (ln 2)^2, where p = desired probability, n = number of items, m = optimal array size |
| 05:16 |
hmmmm |
given a sane value of n, i can optimize for the perfect compromise between speed and memory usage |
| 05:41 |
|
Hunterz joined #minetest-dev |
| 05:57 |
|
nore joined #minetest-dev |
| 06:17 |
|
LemonLake joined #minetest-dev |
| 06:29 |
|
Garmine joined #minetest-dev |
| 06:29 |
celeron55 |
Taoki: i didn't have yet time to make a restart script; i'm now making one and it will be soon up again |
| 06:35 |
celeron55 |
up |
| 06:36 |
celeron55 |
copied error message on #minetest (a bug in worldedit, probably) |
| 06:37 |
|
Guest28706 joined #minetest-dev |
| 06:57 |
|
Garmine joined #minetest-dev |
| 07:07 |
sfan5 |
ShadowNinja: yes |
| 07:17 |
|
BlockMen joined #minetest-dev |
| 07:18 |
BlockMen |
ShadowNinja, well, sfan5 forgot to mention that _game is maintained (for now) just by nore, him and me. |
| 07:18 |
* BlockMen |
adds that to wiki |
| 07:27 |
VanessaE |
I'm starting to see the occasional "ERROR[MeshUpdateThread]: Waiting for texture xxxxxxxx timed out." (always seems to be some normalmap, and always different each time) |
| 07:27 |
VanessaE |
someone asked the other day if others had seen this happening. I had not... until today. |
| 07:27 |
VanessaE |
with these timeouts come HUGE mesh generation lag spikes |
| 07:33 |
VanessaE |
(the lag spikes started earlier, but today's the first time I noticed the timeout message) |
| 07:46 |
|
BlockMen left #minetest-dev |
| 08:05 |
|
PenguinDad joined #minetest-dev |
| 08:07 |
RealBadAngel |
VanessaE, i will move that file access outta meshupdate, same as i did with shaders |
| 08:11 |
celeron55 |
could we make a second official download recommended to newcomers which contains carbone instead of minetest_game? does anyone else than me feel that this is a good idea? |
| 08:12 |
celeron55 |
granted, it doesn't have much deeper gameplay, but it generally looks better and has more stuff, and isn't broken |
| 08:13 |
VanessaE |
RealBadAngel: ok |
| 08:13 |
celeron55 |
(and sounds better) |
| 08:13 |
VanessaE |
celeron55: seems fine to me; I haven't played it, but from the screenshots, it looks like a good game. for sure, I like the HUD :) |
| 08:14 |
celeron55 |
and it's also mostly compatible with minetest_game (most mods work) |
| 08:14 |
RealBadAngel |
whats wrong with one download and many games included? |
| 08:15 |
VanessaE |
celeron55: there's one caveat: keeping that download up-to-date with upstream Carbone. |
| 08:15 |
celeron55 |
RealBadAngel: it doesn't make sense to me because minetest_game and carbone overlap so much |
| 08:16 |
celeron55 |
and there is nothing in the engine or in the games to help users understand why there are two and how they differ and why it is so |
| 08:16 |
celeron55 |
and the name of the other one is "Minetest" so which are the ones not knowing anything going to choose? |
| 08:16 |
celeron55 |
minetest_game of course |
| 08:16 |
celeron55 |
so it completely beats the purpose |
| 08:17 |
RealBadAngel |
well, there are tooltips, there could be added text area with more detailed game descriptio, kinda "about" |
| 08:17 |
celeron55 |
yes, if there was an about screen, it could make me think otherwise |
| 08:18 |
celeron55 |
one that new users will see without clicking anything |
| 08:18 |
RealBadAngel |
thats pretty easy to add |
| 08:19 |
RealBadAngel |
i can agree on carbone and mt being pretty the same, but there are also games to come totally differnt, and those definitely will require some about and how-to |
| 08:19 |
celeron55 |
simply anything that is bundled in the official package must make sense to new users - it's the main criterion, because old users know how and where to download a mod or a subgame and what they are and why they would do so and what exacty they can find in them that isn't found in minetest_game |
| 08:20 |
|
smoke_fumus joined #minetest-dev |
| 08:20 |
celeron55 |
RealBadAngel: that's kind of a different thing, because a howto for eg. nodetopia or realtest isn't going to fit in an "about" box 8) |
| 08:20 |
VanessaE |
hah |
| 08:20 |
RealBadAngel |
at least simplified |
| 08:21 |
VanessaE |
celeron55: a howto for Realtest wouldn't fit in a FORUM post for that matter :P |
| 08:21 |
RealBadAngel |
i have creatures by taoki in mind |
| 08:21 |
celeron55 |
of course it could say "you don't know how to play this; please use google now" |
| 08:21 |
RealBadAngel |
text area could display pages, thats not problem, just flip the pages if text is bigger |
| 08:22 |
sfan5 |
nobody wants to read a 7 page howto in the main menu |
| 08:22 |
celeron55 |
well, make a prototype for such a thing with new users in mind and show it here |
| 08:22 |
celeron55 |
let's see if we can make it good |
| 08:22 |
RealBadAngel |
sfan5, ofc most wont read it, but then you can just say rtfm ;) |
| 08:22 |
nore |
well, some kind of in-game tutorial could be made |
| 08:23 |
nore |
detecting when a player has "completed" a step, and displaying tutorial for the next one |
| 08:23 |
celeron55 |
nore: that's not important for now; the game about text in the menu is important |
| 08:23 |
RealBadAngel |
nore, that seems to be related to achievements rather |
| 08:24 |
nore |
RBA: it's between a tutorial and achievements :) |
| 08:24 |
nore |
celeron55, so in the "about" text, there should be a short description of the game? |
| 08:25 |
RealBadAngel |
but info "use pick to mine stone" in main menu would be more than stupid ;) |
| 08:25 |
celeron55 |
nore: yes, optimized for new users to understand the difference between minetest_game and carbone |
| 08:25 |
celeron55 |
that should be good for many other things too then |
| 08:28 |
RealBadAngel |
btw, one could start adding tooltips for main menu |
| 08:29 |
RealBadAngel |
that is definitely needed imho, labels and text on buttons is sometimes just not enough |
| 08:31 |
RealBadAngel |
i cant for example put in "bumpmapping' label an explanation whats that and what it needs to work |
| 08:34 |
celeron55 |
tooltips are fine too, but not that useful for the purpose of making new users understand multiple similar subgames |
| 08:34 |
RealBadAngel |
ofc |
| 08:35 |
RealBadAngel |
btw, im thinkin where to put button to read info buout subgame |
| 08:35 |
RealBadAngel |
any ideas? |
| 08:35 |
RealBadAngel |
in world configuration menu? |
| 08:36 |
celeron55 |
it might require menu redesign, now that i think of it |
| 08:37 |
celeron55 |
like, when opening MT, ideally the user should be faced with a choice between connecting a server, and choosing between locally installed subgames |
| 08:38 |
celeron55 |
and then the choice is locked in the next screen |
| 08:38 |
celeron55 |
(with a back button) |
| 08:39 |
celeron55 |
this is what everyone is already really doing, but the menu just doesn't represent it well at all |
| 08:40 |
celeron55 |
the "connect to server" option would have a hardcoded about box explaining it, and the games would have whatever they specify in a file added for this purpose |
| 08:42 |
RealBadAngel |
an idea, i could display info bout game on double click its icon |
| 08:42 |
RealBadAngel |
then above the games bar open textarea with back button |
| 08:43 |
celeron55 |
oh god no, nobody will know how to do that |
| 08:43 |
RealBadAngel |
tooltip? |
| 08:44 |
celeron55 |
i'm going to say nothing else would really be user-friendly except that i just described |
| 08:44 |
celeron55 |
s/that/what/ |
| 08:45 |
VanessaE |
bbl |
| 08:56 |
RealBadAngel |
celeron55, http://i.imgur.com/r2TpDP6.png |
| 08:57 |
celeron55 |
the issue is, new users probably won't go and hover their mouse over those icons |
| 08:57 |
celeron55 |
so they just end up with whatever game happened to be selected and be like "oh, this is minetest i guess" |
| 08:57 |
|
Calinou joined #minetest-dev |
| 08:58 |
celeron55 |
they have to be faced with an explicit choice, then they will take the 5 seconds to read the about box and immediately see what the choice is about |
| 08:58 |
RealBadAngel |
its already worthy to click that button, it changes backgroud, could play also subgame music |
| 08:59 |
celeron55 |
you don |
| 08:59 |
celeron55 |
*you don't understand |
| 08:59 |
sfan5 |
new users don't know they can click those buttons |
| 08:59 |
sfan5 |
+might |
| 08:59 |
sfan5 |
not* |
| 09:00 |
RealBadAngel |
oh cmon, users are not as that stupid, then can see those buttons ;) |
| 09:00 |
celeron55 |
this is the first thing a user sees in minetest; it must give them as good a start as possible |
| 09:01 |
celeron55 |
we can slack in UI design elsewhere |
| 09:04 |
RealBadAngel |
so you mean game button bar because user may not know they can click it? |
| 09:04 |
RealBadAngel |
*is unusable |
| 09:05 |
RealBadAngel |
so what for we do have it? |
| 09:05 |
sfan5 |
for people who know how to use it? |
| 09:06 |
RealBadAngel |
remove ugly lookin game selection pop up list, and make game button bar common for windows where user can select game |
| 09:07 |
RealBadAngel |
that would be way nicer |
| 09:07 |
|
kaeza joined #minetest-dev |
| 09:21 |
|
alexxs joined #minetest-dev |
| 09:22 |
celeron55 |
no, the game selection should only be in a single place |
| 09:22 |
celeron55 |
and the place is "at first, before the other UI is entered" |
| 09:44 |
|
alexxs joined #minetest-dev |
| 10:23 |
RealBadAngel |
celeron55, http://i.imgur.com/GVMSMDC.png |
| 10:23 |
RealBadAngel |
what do you think about such way? |
| 10:23 |
celeron55 |
those icons are horrible |
| 10:23 |
sfan5 |
aside from the icons being horrible it looks ok |
| 10:24 |
RealBadAngel |
icons are quick find, just examples |
| 10:24 |
RealBadAngel |
but, thx to that we can have lotsa space, tooltips ofc will explain them better for those who cant think ;) |
| 10:25 |
RealBadAngel |
also, another buttons like gamebar will become obvious they are clickable too ;) |
| 10:26 |
celeron55 |
this does not fix the UI flow problem |
| 10:27 |
RealBadAngel |
but allows to add extra button with ? next to another world related buttons |
| 10:28 |
RealBadAngel |
and there will be still lotsa place |
| 10:29 |
RealBadAngel |
not to mention such buttons would be way better than current ones for android menus imho |
| 10:56 |
|
proller joined #minetest-dev |
| 11:07 |
|
ImQ009 joined #minetest-dev |
| 11:35 |
|
proller joined #minetest-dev |
| 11:39 |
|
casimir joined #minetest-dev |
| 11:54 |
|
proller joined #minetest-dev |
| 12:00 |
|
PilzAdam joined #minetest-dev |
| 12:08 |
|
proller joined #minetest-dev |
| 12:10 |
|
Megaf_ joined #minetest-dev |
| 12:11 |
RealBadAngel |
i do have one thought about that: |
| 12:11 |
RealBadAngel |
os<<tsrc->getTextureName(p.tile.texture_id)<<"^[crack"; |
| 12:11 |
RealBadAngel |
this means that we are producing new textures by adding cracks to it?? |
| 12:12 |
RealBadAngel |
so each texture is multiplied by number of crack frames? |
| 12:12 |
celeron55 |
yes; also it causes the mapblock mesh to be regenerated |
| 12:13 |
celeron55 |
it's crude but works well in practice |
| 12:13 |
RealBadAngel |
but are those textured stored or dropped? |
| 12:14 |
celeron55 |
no; minetest has no mechanism for determining whether textures have references to them and it cannot know whether any of them can be safely dropped |
| 12:14 |
RealBadAngel |
so thats why our textures demands so much ram, yes? |
| 12:14 |
celeron55 |
probably no |
| 12:15 |
celeron55 |
you won't be digging most kinds of nodes in a single game session |
| 12:15 |
RealBadAngel |
it becomes a real problem for HD textures |
| 12:15 |
RealBadAngel |
it multiplies them by 16 |
| 12:16 |
celeron55 |
of course you can fix it, but it's not going to be easy |
| 12:16 |
RealBadAngel |
i think i do have a solution |
| 12:16 |
celeron55 |
well it's easy for the shader implementation |
| 12:16 |
RealBadAngel |
same as i used for glasslike framed |
| 12:16 |
celeron55 |
the other one you probably want to skip |
| 12:16 |
RealBadAngel |
add separete mesh with offseted slightly textures |
| 12:17 |
celeron55 |
i consider that a worse hack |
| 12:17 |
RealBadAngel |
it will work without problems and for sure will remove need to multipy textures |
| 12:18 |
RealBadAngel |
and it doesnt look like a hack, just copy vertices of dug node, add them to meshbuffer, with other textures |
| 12:18 |
celeron55 |
make sure it works well for partially transparent things like grass |
| 12:18 |
celeron55 |
the current implementation is really good for those |
| 12:19 |
RealBadAngel |
im rewriting now mapblock_mesh anyway |
| 12:19 |
RealBadAngel |
most of things that could be done once (mostly shader stuff) got kicked off there |
| 12:20 |
celeron55 |
oh god |
| 12:20 |
celeron55 |
i'm so sure there will be awful regressions that you are too lazy to fix |
| 12:20 |
RealBadAngel |
rather not |
| 12:22 |
RealBadAngel |
last time problems were so hard to fix because there were 4 pieces of code trying to do the same. Plus fucked up open source drivers. |
| 12:42 |
|
vifino joined #minetest-dev |
| 12:45 |
* VanessaE |
wonders how the result will perform |
| 13:06 |
RealBadAngel |
definitely it will use less memory |
| 13:06 |
RealBadAngel |
btw, when digging particles are here, who needs cracks? will code it, its just a side note |
| 13:12 |
|
kaeza joined #minetest-dev |
| 13:14 |
VanessaE |
RealBadAngel: frankly I like seeing both :) |
| 13:15 |
VanessaE |
however, for many people, particles perform poorly, which is probably why they can be turned off in the menu I guess. |
| 13:15 |
RealBadAngel |
you dont like current cracks, like really ;) how big grass and dirt texture HDX has? |
| 13:15 |
VanessaE |
wat |
| 13:15 |
RealBadAngel |
ok, lets say just stone, how big it is? |
| 13:15 |
VanessaE |
Grammar FAIL |
| 13:18 |
RealBadAngel |
lets see, dirt is 512kb, how many frames crack has? 16? |
| 13:19 |
RealBadAngel |
so once you dig a single dirt node, it will 8704kb in memory |
| 13:19 |
RealBadAngel |
*take |
| 13:19 |
sfan5 |
VanessaE: where was the world I could reproduce this with again? https://github.com/minetest/minetestmapper/issues/8 |
| 13:20 |
|
SmugLeaf joined #minetest-dev |
| 13:20 |
|
SmugLeaf joined #minetest-dev |
| 13:21 |
VanessaE |
sfan5: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/worlds/Creative_World.tar.bz2 |
| 13:21 |
VanessaE |
warning, that's a big file |
| 13:21 |
sfan5 |
wasn't there a smaller one? |
| 13:21 |
sfan5 |
.. |
| 13:21 |
sfan5 |
wasn't it the nostalgia map? |
| 13:21 |
Megaf_ |
Hi everyone |
| 13:21 |
VanessaE |
the Nostalgia map might be enough too, s/Survival/Nostalgia/ |
| 13:21 |
* Megaf_ |
roars |
| 13:21 |
VanessaE |
it's about 258 MB |
| 13:22 |
VanessaE |
fark, s/Creative/Nostalgia/ rather :) |
| 13:22 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/worlds/Nostalgia_World.tar.bz2 |
| 13:22 |
|
CraigyDavi`` joined #minetest-dev |
| 13:22 |
* Megaf |
need to learn to see the chanel he is talking in |
| 13:22 |
VanessaE |
really any map that exceeds ±2048 in the Z direction should do it. |
| 13:22 |
|
rubenwardy joined #minetest-dev |
| 13:25 |
Megaf |
1.3Gmap.sqlite |
| 13:28 |
Megaf |
It seems like maps dont get as big now a days as they used to get |
| 13:28 |
Megaf |
Was that some optimization or something? |
| 13:29 |
Megaf |
I had a server with a 5 GB map |
| 13:30 |
VanessaE |
Megaf: my worlds are all leveldb, which is why they're notably smaller than they used to be |
| 13:30 |
VanessaE |
maybe levelsb uses some kind of compression, or just that it's database format is more efficient. idk. |
| 13:30 |
VanessaE |
leveldb* |
| 13:32 |
sfan5 |
VanessaE: GD Warning: product of memory allocation multiplication would exceed INT_MAX, failing operation gracefully |
| 13:32 |
sfan5 |
:( |
| 13:33 |
sfan5 |
damn libgd |
| 13:33 |
VanessaE |
eep |
| 13:33 |
Megaf |
VanessaE; indeed leveldb use compression by default, yes |
| 13:33 |
Megaf |
VanessaE; but even sqlite maps seems to be smaller |
| 13:33 |
sfan5 |
INT_MAX is only 4GB |
| 13:33 |
sfan5 |
I have more then 4GB memory.. |
| 13:36 |
sfan5 |
than* |
| 13:37 |
sfan5 |
VanessaE: can't reproduce, can you? |
| 13:37 |
VanessaE |
I haven't tried |
| 13:37 |
VanessaE |
not since the initial report, I went back to using a different branch just to make sure I had good imagery |
| 13:37 |
VanessaE |
different fork( |
| 13:38 |
VanessaE |
close it for now, if it crops up again, I'll report it. |
| 13:38 |
sfan5 |
I would like you to try too |
| 13:38 |
VanessaE |
lemme see.. |
| 13:39 |
sfan5 |
VanessaE: https://cdn.mediacru.sh/oJd1LQNj6hDE.png |
| 13:39 |
VanessaE |
hm |
| 13:39 |
VanessaE |
I seem to be using the official fork already |
| 13:39 |
VanessaE |
and the maps generated with it are good |
| 13:39 |
VanessaE |
what commit am I at? hm., |
| 13:40 |
sfan5 |
<MinetestBot> GIT: sfan5 commited to minetest/minetestmapper: Fix --drawalpha e85a498 2014-07-08T15:08:07+02:00 http://git.io/dajduw |
| 13:40 |
sfan5 |
that one probably fixed it |
| 13:40 |
VanessaE |
commit dff45891521b8fd299f68f1ca1c36124e3b6616b |
| 13:40 |
sfan5 |
actually let me try |
| 13:40 |
VanessaE |
is where I'm at. |
| 13:40 |
|
EvergreenTree joined #minetest-dev |
| 13:41 |
VanessaE |
I must have bisected it back to this point and stayed here. |
| 13:41 |
|
Jordach joined #minetest-dev |
| 13:41 |
sfan5 |
hm, no |
| 13:41 |
VanessaE |
*scratches head* |
| 13:41 |
sfan5 |
it does not happen even with the commit before "Fix --drawalpha" |
| 13:41 |
VanessaE |
odd, because I'm also not using --drawalpha |
| 13:42 |
sfan5 |
I tried both with and without |
| 13:42 |
VanessaE |
well lemme update to HEAD and just see what happens. |
| 13:44 |
* VanessaE |
adds --drawalpha and runs the mapper script... |
| 13:48 |
VanessaE |
wat |
| 13:48 |
VanessaE |
--backend is no longer recognized? |
| 13:49 |
VanessaE |
guess it isn't needed anyway |
| 13:49 |
VanessaE |
perhaps you should just ignore that switch rather than fail with an error. |
| 13:58 |
VanessaE |
ok, it seems good now. |
| 13:58 |
VanessaE |
if you reload the Creative World map from the main link, http://digitalaudioconcepts.com/vanessa/hobbies/minetest/worldmaps/Creative_World.png , it looks good. |
| 13:58 |
VanessaE |
and that alpha in the water is just plain beautiful |
| 13:58 |
VanessaE |
kodus, sfan5 |
| 13:59 |
VanessaE |
kudos, too :) |
| 13:59 |
sfan5 |
:) |
| 13:59 |
sfan5 |
<VanessaE> and that alpha in the water is just plain beautiful |
| 13:59 |
sfan5 |
this why I added that feature |
| 14:01 |
|
hmmmm joined #minetest-dev |
| 14:06 |
VanessaE |
I'd call it good, sfan5. |
| 14:15 |
|
rubenwardy joined #minetest-dev |
| 14:16 |
|
troller joined #minetest-dev |
| 14:24 |
|
BlockMen joined #minetest-dev |
| 14:24 |
BlockMen |
https://github.com/minetest/minetest/pull/1328#issuecomment-48342751 |
| 14:25 |
|
LemonLake joined #minetest-dev |
| 14:26 |
|
BrandonReese joined #minetest-dev |
| 14:30 |
VanessaE |
BlockMen: as long as it's a new drawtype with new texture filenames, I'm okay with it. |
| 14:30 |
BlockMen |
VanessaE, yes, as new drawtype |
| 14:31 |
VanessaE |
_with new filenames_ |
| 14:31 |
sfan5 |
new filenames? |
| 14:31 |
sfan5 |
you mean for the textures? |
| 14:32 |
VanessaE |
yes |
| 14:32 |
sfan5 |
this has nothing to do with the engine changve |
| 14:32 |
sfan5 |
change* |
| 14:32 |
|
LemonLake joined #minetest-dev |
| 14:32 |
VanessaE |
sfan5: well from an engine standpoint no, but when it gets applied to the default game, which it will, that's where I'm talking about. |
| 14:34 |
BlockMen |
VanessaE, if you want support the new drawtype you need other textures for your pack anyway? |
| 14:34 |
BlockMen |
sfan5, nore: what you think about removing this line: https://github.com/minetest/minetest_game/blob/master/minetest.conf#L4 ? |
| 14:35 |
sfan5 |
BlockMen: if it fixes the not-being-able-to-jump-place annoyance, yes |
| 14:35 |
VanessaE |
BlockMen: correct. I just want to avoid a style conflict. Clearly what works for a flat torch won't work for a 3d torch in most cases. |
| 14:38 |
BlockMen |
sfan5, yes it does. pushing it then |
| 14:48 |
|
nore joined #minetest-dev |
| 14:50 |
|
asl joined #minetest-dev |
| 14:57 |
BlockMen |
VanessaE, ok. new drawtype and other texture name |
| 14:57 |
VanessaE |
good :) |
| 14:58 |
BlockMen |
more comments on #1328 ? |
| 14:58 |
VanessaE |
hyave you decided how you're gonna handle the flames/animation? |
| 14:58 |
VanessaE |
have* |
| 14:59 |
BlockMen |
by texture. you can set a not animated texture when someone finds a nice way for other kind of flames, e.g. particles |
| 15:00 |
VanessaE |
ok |
| 15:00 |
VanessaE |
gonna do four separate sides for the texture? |
| 15:01 |
VanessaE |
(well four parts of one image, UV map) |
| 15:03 |
BlockMen |
i prefer a simple image instead uv nodes. that could be done if we get meshnodes IMO |
| 15:04 |
BlockMen |
*uv nodes = uv maps ^^ |
| 15:04 |
VanessaE |
well I mean mapped like a fencepost is |
| 15:04 |
VanessaE |
you know, 1/4 of the image on one side, another 1/4 on the next side, retc. |
| 15:04 |
VanessaE |
etc* |
| 15:05 |
VanessaE |
so that the burning flame isn't copied around all four sides + top/bottom ;) |
| 15:05 |
VanessaE |
it'd be rather nice to make all four sides of the torch look different. |
| 15:06 |
BlockMen |
no. doing that you cant make that for example http://i.imgur.com/e5CGz.png |
| 15:06 |
BlockMen |
(the metal on the top of the torch) |
| 15:06 |
BlockMen |
for fences it might be nice, but for the torch its done better this way |
| 15:06 |
VanessaE |
sure you can |
| 15:07 |
BlockMen |
you only have 1/4 for that. with 16px you cant |
| 15:07 |
VanessaE |
make the default texture 32px then |
| 15:07 |
VanessaE |
there's no law that says it HAS to be 16px is there? |
| 15:07 |
BlockMen |
so everything is 16 px and just torches 32px? no |
| 15:07 |
VanessaE |
especially in a case like this one |
| 15:08 |
|
nore joined #minetest-dev |
| 15:08 |
BlockMen |
let the uv maps for meshnodes, not this |
| 15:08 |
|
rubenwardy joined #minetest-dev |
| 15:08 |
VanessaE |
I dunno... |
| 15:09 |
VanessaE |
then give multiple images per side |
| 15:09 |
VanessaE |
you know, like any other node |
| 15:09 |
VanessaE |
er that reads wrong. |
| 15:09 |
VanessaE |
give 6 images, like any other node I mean |
| 15:09 |
VanessaE |
it'll keep the 16px resolution for default and give maximum flexibility for texture pack artists. |
| 15:09 |
VanessaE |
won't add more than 1k or 2k or so to the game |
| 15:10 |
BlockMen |
3 dirs would make sense |
| 15:10 |
BlockMen |
top bottom sides |
| 15:10 |
VanessaE |
four. top, bottom, N/S, E/W. |
| 15:11 |
BlockMen |
different textures on side? |
| 15:11 |
BlockMen |
we are talking aabout a torch drawtype ;) |
| 15:11 |
VanessaE |
yeah, because at least the flames could be mirrored |
| 15:11 |
BlockMen |
they are already mirrored |
| 15:11 |
VanessaE |
oh |
| 15:11 |
VanessaE |
hm. |
| 15:12 |
VanessaE |
well at least make it so that the drawtype can be given a full 6-texture treatment |
| 15:12 |
VanessaE |
even if the GAME doesn't do it |
| 15:12 |
VanessaE |
then we can decide later if more than 3 textures are needed. |
| 15:24 |
|
troller joined #minetest-dev |
| 15:34 |
RealBadAngel |
VanessaE, here? |
| 15:34 |
|
troller joined #minetest-dev |
| 15:34 |
VanessaE |
yes |
| 15:37 |
|
Piggybear87 joined #minetest-dev |
| 15:37 |
|
Piggybear87 left #minetest-dev |
| 15:37 |
casimir |
Blockmen, does this replace 2D torches? I don't understand the code. |
| 15:38 |
sfan5 |
casimir: no, that code just adds a 2d torch drawtype IIRC |
| 15:38 |
BlockMen |
currently yes, but since that wont go in i will change it if other agree to merge (in general) |
| 15:38 |
BlockMen |
sfan5, no |
| 15:39 |
BlockMen |
casimir, since you use fm, look there |
| 15:39 |
BlockMen |
they took my code and gave credit someone else |
| 15:41 |
casimir |
I don't use fm, but I'll take a look. |
| 15:44 |
|
troller joined #minetest-dev |
| 15:46 |
|
Calinou joined #minetest-dev |
| 15:48 |
BlockMen |
casimir, oh..ok. had in mind your game supports fm |
| 15:49 |
|
Eater4 joined #minetest-dev |
| 15:55 |
|
sapier joined #minetest-dev |
| 16:00 |
|
grrk-bzzt joined #minetest-dev |
| 16:03 |
sfan5 |
wtf |
| 16:04 |
sfan5 |
wtf |
| 16:04 |
sfan5 |
each Database class basically duplicated the code from ServerMap::loadBlock(std::string *blob, v3s16 p3d, MapSector *sector, bool save_after_load) |
| 16:04 |
sfan5 |
who designed this shit? |
| 16:04 |
sapier |
I don't know who designed it but I know who committed ;-) |
| 16:05 |
sfan5 |
I commited it, and? |
| 16:05 |
sapier |
Megaf have a look at top of android makefile |
| 16:05 |
sapier |
ok then I meant who wrote it |
| 16:06 |
sapier |
VanessaE Waiting for texture xxxxxxxx timed out should actually be a assert cause |
| 16:06 |
sapier |
if this happens memory may or may not be corrupted |
| 16:06 |
sfan5 |
sapier: don't you dare to make that an assert(0), it happens when using valgrind too |
| 16:07 |
sapier |
If I'd wanted to do that I already would've done still if you see this anything happening after it might be result of it |
| 16:07 |
VanessaE |
sapier: see what RBA said about it earlier. |
| 16:07 |
|
zat joined #minetest-dev |
| 16:08 |
VanessaE |
it's partly due to normalmap file access while in the middle of a mesh update. it'll be moved out of mesh generation to somewhere else. |
| 16:08 |
sapier |
it's just crap to abort an action having passed a stack pointer to some other thread before that pointer returns |
| 16:09 |
sapier |
http://i.imgur.com/GVMSMDC.png imho that's extremely ugly |
| 16:10 |
VanessaE |
ew. |
| 16:10 |
sfan5 |
<RealBadAngel> icons are quick find, just examples |
| 16:10 |
VanessaE |
the icons have to fit the theme, too |
| 16:10 |
VanessaE |
those don't. |
| 16:11 |
sapier |
then it's a quite stupid example |
| 16:11 |
sapier |
as this featuee comes and falls with icon quality |
| 16:11 |
VanessaE |
yes |
| 16:12 |
VanessaE |
but if the icons are clear, simple, and they fit the grey/black/green theme, then they'll work fine |
| 16:12 |
sapier |
and increase main menu height |
| 16:12 |
VanessaE |
those icons look like the belong in something like LinCity or something. |
| 16:13 |
sapier |
ok they don't increase |
| 16:13 |
sapier |
problem with bitmap icons is they always have to be scaled |
| 16:13 |
VanessaE |
use SVG ;) |
| 16:13 |
sapier |
tell irrlicht |
| 16:14 |
sapier |
and usually you need tooltips |
| 16:14 |
sapier |
no offence RealBadAngel but your inventory is a perferct proof for this |
| 16:14 |
VanessaE |
really though, if scaling is an issue, there's only one solution and that's oversized icons. No, I think it may be better to stick to buttons with text. |
| 16:16 |
|
Hunterz joined #minetest-dev |
| 16:18 |
sapier |
https://github.com/minetest/minetest/issues/1455 is because of mainmenu set to fixed size. For what I remember that "workaround" was only there because of formspecs didn't scale correct by that time. So what about dropping that strange fixed size formspec feature and just let mainmenu scale as it's supposed to ? |
| 16:18 |
sapier |
ok to be precise as all other formspecs do |
| 16:26 |
|
LemonLake joined #minetest-dev |
| 16:30 |
RealBadAngel |
sapier, those icons were about to show it can be readable, using less space and gaining more space |
| 16:31 |
RealBadAngel |
it was not about my f**ing taste ;) |
| 16:31 |
RealBadAngel |
i just asked google for some icons |
| 16:31 |
sapier |
well I wouldn't understand the "play" button if I didn't know there was one before |
| 16:32 |
sapier |
I've never seen the triangle being used for starting a game |
| 16:32 |
RealBadAngel |
think about another one then |
| 16:32 |
sapier |
to me the triangle is playing audio or video only |
| 16:33 |
Megaf |
sapier; Not really, Thanks |
| 16:33 |
sapier |
but of course that's personal as any image associations are |
| 16:33 |
RealBadAngel |
all can think about it |
| 16:33 |
celeron55 |
i think that text-based menu buttons are the best we can have; it's stupid to consciously make things harder to understand |
| 16:33 |
celeron55 |
most games have text-based buttons |
| 16:33 |
RealBadAngel |
point is that text on buttons are wrong |
| 16:33 |
celeron55 |
why? well maybe because they work |
| 16:33 |
celeron55 |
in their menu |
| 16:33 |
RealBadAngel |
most of translations doesnt fit the provided size anyway :P |
| 16:34 |
celeron55 |
why are people discussing these stupid icons instead of my best ever menu modification? |
| 16:34 |
sapier |
hmm maybe because that one wasn't even noticed ;-) |
| 16:35 |
VanessaE |
celeron55: screenshot of said menu? :) |
| 16:35 |
celeron55 |
http://irc.minetest.ru/minetest-dev/2014-07-08#i_3802944 |
| 16:35 |
celeron55 |
VanessaE: only description |
| 16:35 |
VanessaE |
hm |
| 16:36 |
VanessaE |
you know, that's not such a bad idea |
| 16:36 |
sapier |
sounds like apples workaround single thread pardigma and microsofts metro gui |
| 16:36 |
celeron55 |
i think MT needs that before it can bundle multiple games in releases |
| 16:36 |
RealBadAngel |
btw, tellin that folks wont use image_buttons because they wont know if theyre clickable is most stupid answer ever |
| 16:36 |
VanessaE |
RealBadAngel: people are afraid to click. |
| 16:37 |
VanessaE |
believe it or not, as stupid as that sounds. |
| 16:37 |
RealBadAngel |
sure |
| 16:37 |
RealBadAngel |
all the modern OSes are not clicklable then |
| 16:37 |
RealBadAngel |
because using of icons |
| 16:37 |
VanessaE |
my mom, G*d rest her, used to be afraid of confusing the computer from clicking stuff she didn't understand |
| 16:37 |
sapier |
basicaly celerons suggestion is increasing menu depth in order to reduce width (I don't talk about physical dimensions) |
| 16:37 |
RealBadAngel |
ROTFL |
| 16:37 |
celeron55 |
sapier: yes, you can describe it like that |
| 16:38 |
sapier |
as it's formspec there's no reason not to do it |
| 16:38 |
celeron55 |
the current menu has zero depth and that makes it kind of convoluted |
| 16:38 |
VanessaE |
c55's idea is sound. |
| 16:38 |
VanessaE |
too much shit on one screen can confuse people |
| 16:39 |
celeron55 |
and i'm not thinking about this only for new users; i would prefer it myself too |
| 16:40 |
sapier |
on the other hand switching from one mode to another is less comfortable for experienced users |
| 16:40 |
sapier |
but I guess this depends on how good it is made |
| 16:41 |
celeron55 |
changing the game should be a matter of hitting esc and clicking another one |
| 16:41 |
VanessaE |
now the question is, who gets to refactor the main menu? ;) |
| 16:41 |
sapier |
twice escape to get to multiplayer mode |
| 16:42 |
VanessaE |
sapier: unintuitive. |
| 16:42 |
celeron55 |
that doesn't make sense |
| 16:42 |
sapier |
I wont :-) I'm still recovering from last time |
| 16:42 |
celeron55 |
but for example "m" in the first screen could go to multiplayer |
| 16:42 |
celeron55 |
and 1...9 could be games |
| 16:42 |
sapier |
then you need more then mainmenu refactoring |
| 16:42 |
celeron55 |
then you can just hit those quickly when you get used to it |
| 16:42 |
celeron55 |
well it's something to consider in the future, not a priority |
| 16:43 |
sapier |
well someone already asked for having access to all keys from formspec |
| 16:43 |
RealBadAngel |
since its lua, and VanessaE has good taste, imho she shall do that |
| 16:43 |
VanessaE |
fuck no |
| 16:43 |
celeron55 |
lol |
| 16:43 |
VanessaE |
I suck at formspecs. |
| 16:43 |
sapier |
well if noone wants to do it it's not worth discussing ;-) |
| 16:44 |
sfan5 |
VanessaE: no, formspecs suck |
| 16:44 |
VanessaE |
sfan5: +1 |
| 16:44 |
sapier |
that complaint is as old as minetest |
| 16:44 |
sapier |
almost |
| 16:44 |
celeron55 |
i might try it, but i probably have to prioritize it under a million other things so in practice i won't in the near future |
| 16:44 |
sfan5 |
sapier: before you say anything, no I'm currenctly making the Database class not suck; I don't have time to develop better formspecs |
| 16:45 |
celeron55 |
could we recruit some non-coredev modder to do it? :3 |
| 16:45 |
sapier |
I wont tell anyone to replace formspecs because imho they're by far not most important point |
| 16:45 |
RealBadAngel |
so maybe different way, VanessaE, could you propably make a set icons we could use? just as proposal, we could see if it could look a bit better |
| 16:45 |
sapier |
they do what they're supposed to do ... that's not true for other components |
| 16:47 |
RealBadAngel |
its not about formscpecs by now, we already know how to use them |
| 16:47 |
RealBadAngel |
now its point how to make clear and nice lookin menu |
| 16:47 |
RealBadAngel |
without making players being too scared to click something :) |
| 16:48 |
sapier |
why do ppl always wanna do the "visible" stuff only (exept sfan5 right now) ? |
| 16:48 |
sfan5 |
RealBadAngel: players are too scared to click things because double clicking somewhere would exit the menu |
| 16:48 |
* sfan5 |
looks at sapier |
| 16:48 |
sfan5 |
that damn gesture is not needed for PC |
| 16:49 |
sapier |
ok next questions why do ppl complain after release if they coudl've complained 6 weeks before? |
| 16:49 |
sfan5 |
it only annoyed me today |
| 16:50 |
celeron55 |
releases come and go, who cares |
| 16:50 |
sapier |
it's in there for about 6 weeks if someone would've told adding a setting would've been a matter of 5 min |
| 16:50 |
sfan5 |
<celeron55> [...] who cares |
| 16:50 |
sapier |
yes once a year celeron55 ;-) |
| 16:50 |
celeron55 |
well... okay, they *should* come and go |
| 16:51 |
sapier |
maybe we get twice this year ... anyone against scheduling next release for end of novemer? |
| 16:51 |
sapier |
(hoping to get it done till christmas) |
| 16:53 |
celeron55 |
i would suggest a month or two earlier |
| 16:54 |
sapier |
end of october? |
| 16:55 |
sapier |
ok 1st november is saturday, I set milestone 0.4.11 to this date |
| 16:56 |
Calinou |
that's about 4 months from now, sounds OK |
| 16:56 |
Calinou |
shouldn't be too long to keep community alive |
| 16:57 |
Calinou |
I think the ideal is every 3-8 weeks (what Minecraft Alpha/Beta did as well as earlier Minetest versions), but then you need to feature freeze more often |
| 16:57 |
sapier |
sfan5 if you want doubleclick changed plz write a issue |
| 16:57 |
sfan5 |
sapier: later |
| 16:57 |
sapier |
we can't compete to minecraft they have way more manpower |
| 16:58 |
Calinou |
current versions of Minecraft have releases every 3-6 months… |
| 16:58 |
Calinou |
yes we can. |
| 16:59 |
Calinou |
we don't need to pack 15 large new features with each release |
| 16:59 |
Calinou |
even having one medium-size feature and a bunch of fixes and tweaks at every release is good enough |
| 16:59 |
sapier |
our problem isn't writing features but testing them |
| 17:00 |
sapier |
especially the background changes are hard to get done |
| 17:02 |
BlockMen |
Calinou, nodeboxes are not usable for wallmounted 3d torches |
| 17:05 |
|
us`0gb joined #minetest-dev |
| 17:06 |
Calinou |
why not? it's predicted client-side and is not any heavier |
| 17:06 |
Calinou |
this is fully Lua, no C++ change required |
| 17:08 |
|
troller joined #minetest-dev |
| 17:10 |
celeron55 |
yes the issue with fast releases is feature freezes when software grows and it needs more time for testing and fixing |
| 17:10 |
celeron55 |
things like web browsers have multiple versions being developed at the same time so that they can have a steady flow of releases despite the huge workload and delay |
| 17:11 |
celeron55 |
no feature freeze in the development branch |
| 17:11 |
celeron55 |
just a snapshot and then fixes in a separate to-be-stable branch |
| 17:11 |
|
troller joined #minetest-dev |
| 17:11 |
sapier |
that'd require ppl to do fixes too |
| 17:12 |
RealBadAngel |
BlockMen, think about extruding torch and use it as model |
| 17:12 |
celeron55 |
we don't have so many developers that we could be making new features and fixing things in an another branch at the same time |
| 17:12 |
RealBadAngel |
thist would work for any texture given |
| 17:13 |
|
rubenwardy joined #minetest-dev |
| 17:14 |
BlockMen |
RealBadAngel, IMO it doesnt look that good. furthermore a blocky torch makes sense in a block world ;) |
| 17:14 |
sapier |
and to be honest I'm a little bit disapointed about last release, there's beeon only hmmmm and celeron who did help finding the database issue all other bugs have been left untouched |
| 17:14 |
sapier |
and there are some other core devs who could've fixed in between |
| 17:15 |
sapier |
+them |
| 17:15 |
celeron55 |
well i also fixed the lighting issue that paramat reported |
| 17:15 |
celeron55 |
but yes, people weren't very active |
| 17:15 |
sapier |
yes and you did help for the other bug too |
| 17:15 |
RealBadAngel |
BlockMen, you pick a texture pack and drop whole stack of torches on the ground |
| 17:15 |
RealBadAngel |
you will see 3d model |
| 17:16 |
celeron55 |
bug fixing is idel for large teams to do |
| 17:16 |
BlockMen |
RealBadAngel, ik what you mean |
| 17:16 |
celeron55 |
features not |
| 17:16 |
celeron55 |
ideal* |
| 17:16 |
sapier |
as of 30th june there's been no bugfix form team (except docs) |
| 17:16 |
sapier |
oh 2nd july |
| 17:16 |
BlockMen |
but IMO torches should be blocky node, not a texture with deepth |
| 17:17 |
RealBadAngel |
but that approach makes 3d model out of any texture |
| 17:17 |
RealBadAngel |
if you want better one just make a stick 3d and use irrlicht particles to make fire |
| 17:17 |
celeron55 |
"this device makes nuclear waste from absolutely anything you feed in!" |
| 17:17 |
celeron55 |
it's not always such a great idea 8) |
| 17:17 |
sapier |
and with this support I really fear doing a release branch could result in "me or noone" fixing rrelease branch bugs |
| 17:19 |
BlockMen |
RealBadAngel, my torches pull dont hinder anyone from adding irrlicht particles (and use them as flames) |
| 17:19 |
BlockMen |
it will be still useable/extendable with that |
| 17:20 |
RealBadAngel |
if done 3d, should come with particles |
| 17:20 |
RealBadAngel |
do it right or dont touch |
| 17:20 |
BlockMen |
^ y? are we minecraft? |
| 17:20 |
RealBadAngel |
no, they dont have such nice particles |
| 17:20 |
BlockMen |
they use particles for flaes |
| 17:20 |
BlockMen |
*flames |
| 17:20 |
RealBadAngel |
have you seen irrlicht ones? |
| 17:21 |
BlockMen |
yes |
| 17:21 |
BlockMen |
implement it if you want it |
| 17:21 |
BlockMen |
also those can be added later aswell |
| 17:21 |
RealBadAngel |
ok |
| 17:22 |
RealBadAngel |
btw, i posted yesterday some pics, but not here |
| 17:22 |
RealBadAngel |
http://i.imgur.com/T8wf2tp.png |
| 17:22 |
RealBadAngel |
http://i.imgur.com/b3usu4B.png |
| 17:24 |
sapier |
sfan5 do you have experience with sqlite3? |
| 17:25 |
sfan5 |
RealBadAngel: add shadows, then everyone will love you |
| 17:25 |
sfan5 |
sapier: no |
| 17:25 |
sapier |
sad ... I'd really wanna know why REPLACE fails on android |
| 17:25 |
RealBadAngel |
btw, irrlicht lights can be of any color |
| 17:25 |
sfan5 |
ask the sqlite3 devs |
| 17:25 |
sfan5 |
19:25:44: ERROR[EmergeThread0]: Invalid block data in database (-122,1,-32) (SerializationError): MapBlock::deSerialize: no enough input data |
| 17:25 |
sfan5 |
lol |
| 17:25 |
sfan5 |
my rewrite is coming along good |
| 17:27 |
sapier |
didn't someone else do a rewrite of sqlite db backend too? |
| 17:28 |
sfan5 |
note to self: don't do sqlite3_reset before data is copied somewhere |
| 17:29 |
sfan5 |
oh god what |
| 17:29 |
sfan5 |
I think it's broken |
| 17:30 |
sapier |
fix it :-Ü |
| 17:30 |
sfan5 |
I think I should backup my worlds before letting this code touch them... |
| 17:32 |
sfan5 |
ok, yes it is broken |
| 17:34 |
sfan5 |
19:34:00: INFO[EmergeThread0]: WARNING: Could not bind block position for load: library routine called out of sequence |
| 17:34 |
sfan5 |
wat |
| 17:34 |
sfan5 |
why does this go to infostream |
| 17:34 |
sapier |
I'd guess you didn't reset the prepared statement before |
| 17:34 |
sfan5 |
it's a fatal error |
| 17:35 |
sfan5 |
maybe I deleted that code |
| 17:35 |
sapier |
good morning sfan |
| 17:35 |
* sfan5 |
looks at git digg |
| 17:35 |
sfan5 |
diff* |
| 17:35 |
sapier |
I've been searching for two days because of that sort of error beeing warning only ;-Ü |
| 17:35 |
sapier |
-Ü+P |
| 17:37 |
sfan5 |
I didn't delete a single sqlite3_ statement |
| 17:38 |
|
tomreyn joined #minetest-dev |
| 17:39 |
sfan5 |
do we have a warnstream? |
| 17:39 |
sfan5 |
I don't think we do.. |
| 17:39 |
sapier |
no |
| 17:42 |
sfan5 |
doing s/infostream/errorstream/ seems to have fixed it |
| 17:42 |
sfan5 |
I think database-sqlite3.cpp is cursed.. |
| 17:43 |
sapier |
then don't touch it |
| 17:44 |
sfan5 |
I can't not touch it if I change the Database class methods |
| 17:44 |
sapier |
well you just started ... I already spent 2 full days at db code so you've got some time left to finish ;-) |
| 17:45 |
sfan5 |
I'm already finished with code |
| 17:45 |
sfan5 |
I just need to test it now |
| 17:45 |
sapier |
please don't break the android fix or merge it |
| 17:46 |
sapier |
hmm of course I meant you should merge it if you can't stop from breaking ;-) |
| 17:48 |
sapier |
btw I don't know how you changed but >begin< .... a lot of operations ... >commit< is way more fast then >begin< one operation >commit< ... or even doing the ops without begin |
| 17:48 |
sfan5 |
I changed something? |
| 17:48 |
sapier |
I don't know I haven't seen your code by now |
| 17:49 |
sfan5 |
I only changed functions args and deduplicated code |
| 17:49 |
sapier |
I just mention because shadowninja suggested using begin commit |
| 17:49 |
sfan5 |
we use that |
| 17:49 |
sfan5 |
beginSave() and endSave() do that |
| 17:50 |
sapier |
yes he suggested using it within save block .. which doesn't work because of beeing a nested transaction in this case |
| 17:50 |
sfan5 |
why within saveBlock() ? |
| 17:50 |
sapier |
https://github.com/minetest/minetest/pull/1457 this fix |
| 17:51 |
sapier |
didn't you have a look to pull requests prior changing code beeing worked on by others the last days? |
| 17:51 |
sfan5 |
ShadowNinja's suggestion is not about speed |
| 17:51 |
sapier |
no but mine was |
| 17:51 |
sfan5 |
no |
| 17:51 |
sapier |
that's something you should do in cases like that |
| 17:52 |
|
BlockMen left #minetest-dev |
| 17:53 |
sapier |
as long as noone finds out why REPLACE doesn't work I need that fix for android |
| 18:08 |
|
celeron55 joined #minetest-dev |
| 18:11 |
sfan5 |
Database_SQLite3::listAllLoadableBlocks is broken |
| 18:11 |
sfan5 |
noooo |
| 18:11 |
sfan5 |
and I didn't even touch it |
| 18:11 |
sapier |
lol did anyone use it before? |
| 18:11 |
sfan5 |
yes |
| 18:11 |
sfan5 |
it is used for migrating from sqlite3 |
| 18:12 |
sapier |
then you most likely changed something |
| 18:12 |
sfan5 |
I did not |
| 18:13 |
sfan5 |
sapier: https://github.com/sfan5/minetest/commit/537e63005a5f1da1907bcb0d5b1a1b73fa49c5be |
| 18:13 |
sfan5 |
I did not even touch that function |
| 18:17 |
sfan5 |
WAT |
| 18:17 |
sfan5 |
oh |
| 18:17 |
sfan5 |
--world did not do what I expected it to do |
| 18:19 |
sfan5 |
ok, migrating works |
| 18:23 |
sfan5 |
please test: https://github.com/minetest/minetest/pull/1461 |
| 19:28 |
|
Miner_48er joined #minetest-dev |
| 20:02 |
|
LemonLake joined #minetest-dev |
| 20:11 |
|
us`0gb joined #minetest-dev |
| 20:22 |
|
lemonlake_ joined #minetest-dev |
| 20:23 |
|
alexxss joined #minetest-dev |
| 20:24 |
|
proller joined #minetest-dev |
| 20:35 |
|
alexxs joined #minetest-dev |
| 20:37 |
|
Mimilus joined #minetest-dev |
| 20:57 |
|
us`0gb joined #minetest-dev |
| 21:03 |
|
daswort joined #minetest-dev |
| 21:19 |
|
alexxss joined #minetest-dev |
| 21:23 |
ShadowNinja |
There are a lot of assert(0)s in Minetest. These may cause issues in release builds if we remove our custom assert. |
| 21:26 |
ShadowNinja |
BlockMen, sfan5, nore: Why only you maintaining _game? Why isn't it under a seperate _game team or under a seperate organization/user if only you can change it? |
| 21:29 |
|
alexxs joined #minetest-dev |
| 21:32 |
celeron55 |
ShadowNinja: why are you rambling about that |
| 21:33 |
celeron55 |
ShadowNinja: this team proved by _next that they can handle it better than it was handled previously |
| 21:33 |
celeron55 |
ShadowNinja: you have no basis for your whining at all |
| 21:35 |
celeron55 |
ShadowNinja: show some respect |
| 21:35 |
ShadowNinja |
celeron55: As far as I can tell there's no difference other than that it isn't considered frozen and the approval isn't nearly as thorough. |
| 21:35 |
ShadowNinja |
celeron55: And I'm not whining. |
| 21:36 |
celeron55 |
and why is that automatically considered worse? |
| 21:36 |
ShadowNinja |
hmmmm: My server has about 8171422 blocks in it's DB. |
| 21:36 |
ShadowNinja |
celeron55: Bad code is let in. |
| 21:36 |
celeron55 |
the approval is different but works in practice; i'm going to whine if i start seeing bad results |
| 21:38 |
|
alexxss joined #minetest-dev |
| 21:39 |
ShadowNinja |
Also, TNT shouldn't be enabled by default. It's a huge greifing tool. And BlockMen, sfan5, nore: check this please http://ix.io/dhK/diff It cleans up the TNT mod a lot and disables it by default. |
| 21:39 |
ShadowNinja |
My server's running that now. |
| 21:41 |
ShadowNinja |
Some of the code is lifted from my unpublished nuke mod. It can make 256-wide holes in a minute, but this will be much slower because of drops. |
| 21:41 |
ShadowNinja |
I might be able to speed it up by using the VM more, but I'd need content IDs for all nodes. |
| 21:43 |
ShadowNinja |
I also overwrote the entity physics code without looking at it too closely. It should be better, but the damage calculation is different, which you may or may not like. |
| 21:46 |
ShadowNinja |
Converting from set_node to the VM will break rollback's rollback scope though, like with trees (hence why I removed treegen from my server). |
| 21:48 |
proller |
... and you kill main idea of freeminer's modifications.. |
| 21:51 |
hmmmm |
celeron55, I asked the other day if there was any rationale behind the design decision to place mapblocks into the map before the map has actually been generated |
| 21:52 |
ShadowNinja |
proller: Which was? |
| 21:53 |
hmmmm |
which was to break out of calculations every X amount of loops to "improve" performance |
| 21:53 |
hmmmm |
:\ |
| 21:53 |
proller |
ShadowNinja, you like rewriting anything without understanding what it does |
| 22:35 |
|
Eater4 joined #minetest-dev |
| 22:45 |
|
MichaelRpdx joined #minetest-dev |
| 22:45 |
|
sapier left #minetest-dev |
| 23:05 |
ShadowNinja |
http://i.imgur.com/UTGmV1y.png This is what the tnt mod's explosions look like now. It might be a bit big though... |
| 23:06 |
crazyR |
not big enough lol |
| 23:06 |
ShadowNinja |
Explosion time is roughly 0.03 seconds for a filled area like that. Airy areas are faster. |
| 23:08 |
ShadowNinja |
crazyR: http://shadowninja.minetest.net/mods/nuke.tgz A bit old, but if you modify it you can get explosions with a radius of 128 to work in about a minute. For comparison the above shot is with a radius of 4. |
| 23:09 |
crazyR |
lol, was joking. i kinda had a play with tnt in sp world, they are quite fun, especially when you stack hundreds fo them |
| 23:11 |
|
ImQ009 joined #minetest-dev |
| 23:50 |
|
werwerwer joined #minetest-dev |
| 23:53 |
|
casimir joined #minetest-dev |
