| Time |
Nick |
Message |
| 00:01 |
|
spreeuw joined #minetest-dev |
| 00:01 |
|
spreeuw left #minetest-dev |
| 00:11 |
|
hoodedice left #minetest-dev |
| 00:20 |
|
HLuaBot joined #minetest-dev |
| 00:21 |
ShadowNinja |
''tell sapier I was having the scaling issues on a Nexus 10, not a Nexus 7. |
| 00:21 |
HLuaBot |
I'll tell that to "sapier" next time I see them around. |
| 00:26 |
|
alexxs joined #minetest-dev |
| 00:27 |
|
Megaf joined #minetest-dev |
| 02:51 |
|
cheapie joined #minetest-dev |
| 03:00 |
|
domtron joined #minetest-dev |
| 03:51 |
|
us`0gb joined #minetest-dev |
| 03:57 |
|
Miner_48er joined #minetest-dev |
| 04:22 |
|
SoniEx2 joined #minetest-dev |
| 06:35 |
|
CraigyDavi joined #minetest-dev |
| 06:36 |
|
nore joined #minetest-dev |
| 06:39 |
|
Garmine joined #minetest-dev |
| 06:40 |
|
tomreyn joined #minetest-dev |
| 06:43 |
|
CraigyDavi` joined #minetest-dev |
| 06:52 |
|
CraigyDavi joined #minetest-dev |
| 07:02 |
|
CraigyDavi` joined #minetest-dev |
| 07:05 |
|
CraigyDavi`` joined #minetest-dev |
| 07:10 |
|
CraigyDavi joined #minetest-dev |
| 07:14 |
|
CraigyDavi` joined #minetest-dev |
| 07:32 |
|
Hunterz joined #minetest-dev |
| 07:36 |
|
Jordach joined #minetest-dev |
| 08:07 |
|
SmugLeaf joined #minetest-dev |
| 08:07 |
|
SmugLeaf joined #minetest-dev |
| 08:10 |
|
Zeno` joined #minetest-dev |
| 08:10 |
Zeno` |
hi |
| 08:14 |
VanessaE |
RealBadAngel: https://github.com/minetest/minetest/issues/1469 |
| 08:15 |
* darkrose |
pokes VanessaE |
| 08:16 |
VanessaE |
hey darkrose :) |
| 08:16 |
darkrose |
hi :) |
| 08:16 |
darkrose |
you poked me a couple of days ago? |
| 08:16 |
RealBadAngel |
hi all |
| 08:17 |
VanessaE |
darkrose: yeah, I was trying to see if that was you on a certain 0.4.x server - I assumed not but I wanted to be sure. |
| 08:17 |
darkrose |
yeah, I don't play 0.4 |
| 08:17 |
RealBadAngel |
VanessaE, one side effect of my changes to cracks, one will be able to disable the effect just by removing (not supporting) the texture |
| 08:19 |
RealBadAngel |
so it could be used to speedup the game on slower machines, digging wont be causing meshupdates then |
| 08:19 |
VanessaE |
RealBadAngel: interesting. well the game will always have the cracks texture anyway so that's no big deal |
| 08:20 |
RealBadAngel |
by now the file is required, after it COULD be used |
| 08:20 |
RealBadAngel |
and file is supported by game not the engine |
| 08:21 |
VanessaE |
darkrose: that's what I thought. |
| 08:22 |
VanessaE |
RealBadAngel: read the above bug report please. you fucked up either in lua_api.txt or in the C++ code. :) |
| 08:22 |
VanessaE |
also optional cracks imagery might actually be a good thing in some random game. |
| 08:22 |
RealBadAngel |
i already did |
| 08:22 |
VanessaE |
(imagine some game where there's just no need for it) |
| 08:23 |
VanessaE |
oh, so you did :) |
| 08:27 |
RealBadAngel |
i want to finish that crack/animation stuff now, then i will fix the trees |
| 08:28 |
RealBadAngel |
what im doing right now is makin meshupdates as fast as possible |
| 08:28 |
RealBadAngel |
which means all the code that plays with strings, file access etc get kicked outter space from here |
| 08:31 |
|
Calinou joined #minetest-dev |
| 08:32 |
VanessaE |
good. :) |
| 08:37 |
|
grrk-bzzt joined #minetest-dev |
| 08:37 |
|
grrk-bzzt joined #minetest-dev |
| 08:45 |
Zeno` |
RealBadAngel, I also wondered if ps.next() was intentionally omitted in the first loop |
| 08:46 |
Zeno` |
:range() doesn't update the next random number |
| 08:46 |
RealBadAngel |
how im supposed to remember that after year or something like that? ;) |
| 08:46 |
Zeno` |
nfi |
| 08:46 |
Zeno` |
lol |
| 08:46 |
Zeno` |
that's what comments are for :p~ |
| 08:47 |
RealBadAngel |
random stuff was working correctly but then PA insisted on generating the very same trees depending on seed |
| 08:47 |
RealBadAngel |
which is nonsense for me, but i added that |
| 08:47 |
RealBadAngel |
maybe then i broke something |
| 08:48 |
Zeno` |
well, I think the seed is correct (just not initialised so it's undefined behaviour) but the chances are definately wrong (>= conditional instead of <=) |
| 08:49 |
Zeno` |
generating the same tree given the same seed would be expected |
| 08:50 |
Zeno` |
It needs to be stressed in the docs though... I suppose I could do that |
| 08:50 |
RealBadAngel |
i suck creating any docs ;) |
| 08:52 |
Zeno` |
it's not really nonsense (same seed making same tree) :p Same as rand() will return the same sequence if srand() is given the same seed or not at all |
| 08:53 |
Zeno` |
I think PA was correct in saying that, but yeah |
| 08:58 |
|
PenguinDad joined #minetest-dev |
| 09:13 |
|
sapier joined #minetest-dev |
| 09:15 |
sapier |
seems like mapgen somehow manages to delay mainloop, does anyone know how this happens? |
| 09:16 |
sapier |
result is a runaway mainloop delay causing visible stutter in game |
| 09:16 |
sapier |
as delay builds up to an extent where network packets are dropped |
| 09:18 |
sapier |
you can see it in plain game too, enable profiler, stand still wait till all is done ... them move around and look at incoming packets ... you'll see wholes and spikes in there as packets haven't been handled and get handled at once |
| 09:19 |
sapier |
in a new world of course |
| 09:29 |
|
proller joined #minetest-dev |
| 09:32 |
|
Garmine joined #minetest-dev |
| 09:34 |
|
cerulean256 joined #minetest-dev |
| 09:35 |
cerulean256 |
Hi guys, is there a plan regarding how lag is going to be dealt with. It is really a problem when compared to other games like minecraft. |
| 09:36 |
sapier |
read up about 10 lines |
| 09:36 |
sapier |
in history ;-) |
| 09:36 |
cerulean256 |
I just joined so I can't |
| 09:36 |
sapier |
http://irc.minetest.ru/minetest-dev/ you can |
| 09:36 |
cerulean256 |
ahha.. ok :) |
| 09:37 |
sapier |
short ... seems to be a bug |
| 09:38 |
cerulean256 |
a long lived bug :) |
| 09:38 |
cerulean256 |
the jumping characters around the map is quite disruptive |
| 09:38 |
sapier |
well that's not really a bug |
| 09:39 |
cerulean256 |
I think the discussion of "try to follow someone in minetest" is a perfect example of a problem. |
| 09:39 |
sapier |
that's just result of minetest accepting player position from client and not controling it server side (within boundarys) |
| 09:39 |
cerulean256 |
it may be a design choice - hence not a bug - but it may not have been the best choice. |
| 09:40 |
sapier |
maybe but chances to change this aren't that big ... depends on how much needs to be changed of course |
| 09:41 |
cerulean256 |
when it comes to player position it would be possible to have the client send the position updates and the server confirm them before updating the other connected clients with the new location |
| 09:42 |
sapier |
that'd increase network load by factor 2 |
| 09:42 |
cerulean256 |
it may be considered added overhead.... but it should smoothout the gameplay |
| 09:43 |
sapier |
how is this supposed to smooth gameplay? there'd be a change for player itself only but not for others? |
| 09:44 |
cerulean256 |
well each update does rely on the client doing some of the work in smoothing things over, like processing the animations, etc. right? |
| 09:45 |
cerulean256 |
we could also use TCP and make sure everything arrives in order and that will smooth the traffic stream substatailly |
| 09:46 |
cerulean256 |
substantially* |
| 09:46 |
sapier |
we already ensure everything arrives in order |
| 09:47 |
sapier |
tcp may even increase lag effect as any single client position update has to be received in order to receive the important data |
| 09:47 |
sapier |
and client sends a lot of them |
| 09:47 |
cerulean256 |
ok... then why can one follow another player in games like Halflife with little / no jumpiness and minetest not? |
| 09:47 |
sapier |
guess they're smoothing client side |
| 09:48 |
sapier |
and send less position updates then we do |
| 09:48 |
sapier |
but as said that's a guess |
| 09:48 |
cerulean256 |
less?? I have to disagree |
| 09:48 |
cerulean256 |
it's a shooter.. how would less make the game playable? |
| 09:48 |
sapier |
have you ever had a look at network packets? |
| 09:48 |
cerulean256 |
yes |
| 09:49 |
sapier |
client sends tremendous amounts of packets once a player moves |
| 09:49 |
cerulean256 |
you mean minetest packets imparticular? |
| 09:49 |
sapier |
that might even be the problem as those packets are passed to each player on server |
| 09:50 |
sapier |
thus multiplying by player count |
| 09:51 |
cerulean256 |
but that shouldn't be a problem for server grade hardware |
| 09:51 |
|
PilzAdam joined #minetest-dev |
| 09:51 |
|
proller joined #minetest-dev |
| 09:51 |
sapier |
it is |
| 09:51 |
celeron55 |
if people prefer smoothness in place of low latency, the minetest client could buffer movement data for like a second or two |
| 09:51 |
cerulean256 |
are you suggesting that the lag the I see on the nummerous minetest servers out there are just home run vms? |
| 09:51 |
celeron55 |
Taoki's post seems to refer to this |
| 09:52 |
cerulean256 |
celeron55: I think that would be a nice compromise |
| 09:52 |
sapier |
cerulean256: lots of them |
| 09:52 |
celeron55 |
but the real problem is the server's design; all of this are just workarounds |
| 09:52 |
Zeno` |
cerulean256, for the most part, yes |
| 09:52 |
celeron55 |
so you have to first choose between whether you want to make a workaround or actually make the server not laggy |
| 09:52 |
Taoki |
celeron55: Yeah, I mentioned buffering movement client-side a few times. IMO that's very necessary to get good movement |
| 09:53 |
cerulean256 |
Taoki: I agree with that assessment. |
| 09:53 |
sapier |
I think there are multiple flaws resulting in this issue |
| 09:53 |
celeron55 |
it's possible to not make the server laggy, but there's no quick way for achieving that; it's a long process of improving the architecture that has already started |
| 09:53 |
Taoki |
It's good if it already started |
| 09:53 |
celeron55 |
the server of eg. quake or stuff like that does almost nothing compared to the MT server |
| 09:54 |
celeron55 |
they just check some physics and route position packets around |
| 09:54 |
Taoki |
celeron55: For me it was just a visual problem mostly. But some players said you can't even follow someone else in multiplayer, because the player is seen snapping all over the place. So someone can barely even show you to their house |
| 09:54 |
Taoki |
Yeah... I hope someday we'll have Quake engine quality movement prediction |
| 09:54 |
celeron55 |
the MT server runs a huge amount of all kinds of crap that currently interferes with the basic operation like quake's |
| 09:54 |
cerulean256 |
celeron55: it's good to know if it's on the roadmap |
| 09:55 |
cerulean256 |
Taoki: The "snapping" problem is something I see constantly and even worse.. I'll be building and put down say 20 blocks and the they disappear.. then show up 3 seconds later |
| 09:55 |
celeron55 |
so to me this seems that decoupling the basic interaction loop from the heavy lifting should be achieved ASAP |
| 09:55 |
sapier |
one of my next major tasks is spliting game physics from player interaction |
| 09:55 |
celeron55 |
that could still imply a year of development though |
| 09:55 |
Taoki |
ouch |
| 09:55 |
Zeno` |
I doubt that many MT servers are running on server grade hardware. Correct me if I'm wrong. |
| 09:55 |
Taoki |
@cerulean256 |
| 09:55 |
Taoki |
Zeno`: Not all Quake / etc servers are either |
| 09:56 |
celeron55 |
cerulean256: that's caused by the server running some mod code and stopping everything else while doing it, and then resuming from where it left off |
| 09:56 |
VanessaE |
Zeno`: and even if they are, the problem still persists. |
| 09:56 |
sapier |
a year ... yes I was hoping to get it done a little bit more fast but it's in same range I expected it to be |
| 09:56 |
celeron55 |
cerulean256: nothing about network or any kind of conventional lag that people generally talk about |
| 09:56 |
Zeno` |
Taoki, true. But I think Quake has movement prediction |
| 09:56 |
Zeno` |
same with projectile paths |
| 09:56 |
Taoki |
true |
| 09:57 |
sapier |
we've got projectile path prediction too ;-) |
| 09:57 |
cerulean256 |
what are the minimum system requirement for a good performing minetest server? |
| 09:57 |
sapier |
cerulean256: depends |
| 09:58 |
sapier |
it's more about the mods you wanna run |
| 09:58 |
cerulean256 |
related to this discussion ;) |
| 09:58 |
sapier |
for some mods there's no "good enough" hardware |
| 09:58 |
celeron55 |
and the amount of players you want to host |
| 09:58 |
proller |
i want 1000 |
| 09:59 |
celeron55 |
almost any hardware can run a vanilla minetest_game with a couple of players; then everything else is up from there |
| 09:59 |
Taoki |
Also, I think another problem is we don't network movement fast enough perhaps. Server step is still 0.1 I believe. I suggested (and still do) using at least 0.05 |
| 09:59 |
Taoki |
I mean does it eat that much CPU? |
| 09:59 |
celeron55 |
Taoki: stop talking about that crap; you don't gain anything from it |
| 09:59 |
cerulean256 |
if what celeron55 is saying is true about the mods delaying server execution then maybe registering mods with the main minetest loop needs to be done with care by mod developers |
| 10:00 |
Taoki |
aha, ok |
| 10:00 |
celeron55 |
Taoki: the only things we need are decoupling of fast and slow processing and better interpolation |
| 10:00 |
Taoki |
I agree about that |
| 10:00 |
Taoki |
Yeah, aht the classic yaw interpolation too heh |
| 10:00 |
Taoki |
**and |
| 10:01 |
sapier |
cerulean256: excactly but most mod developers don't care and blame engine ;-) |
| 10:01 |
celeron55 |
cerulean256: yes, writing mods carefully certainly helps; but it's a lot of work |
| 10:01 |
Zeno` |
To be fair, at least some of the blame belongs with the engine |
| 10:01 |
celeron55 |
yes, because the engine's job is to make writing content easy |
| 10:01 |
cerulean256 |
Zeno`: sure, to a certain degree |
| 10:01 |
Taoki |
Yes, mods also need to be optimized. The engine can't do much if a Lua script is used badly. I always try to optimize mine the most |
| 10:02 |
Zeno` |
I mean the main game loop is 4000 fucking lines long (or something like that) |
| 10:02 |
celeron55 |
currently writing processing-heavy content is not easy |
| 10:02 |
sapier |
yes but it's allways gonna be if you abuse tomethin result will be bad |
| 10:02 |
Zeno` |
no scheduling (last I looked), nothing |
| 10:02 |
cerulean256 |
celeron55: can you clarify what heavy content is? |
| 10:02 |
sapier |
anything accessing more then one node on map |
| 10:03 |
celeron55 |
cerulean256: like a lua-based map generator or a mob mod making heavy use of pathfinding |
| 10:03 |
sapier |
pathfinding for more then about 10 nodes distance will most likely be uusable |
| 10:04 |
sapier |
not in regular case, there it's quite fast, but worst case is the problem |
| 10:04 |
cerulean256 |
ok.. here's another question that I haven't even looked at... is the minetest-server multithreaded? |
| 10:04 |
sapier |
that part isn't |
| 10:04 |
cerulean256 |
I know trying to code multitrhreaded processes in C/C++ is a bitch :) |
| 10:04 |
celeron55 |
some parts are, some aren't |
| 10:04 |
sapier |
and that's the improvement celeron is talking about |
| 10:04 |
Zeno` |
reentrant and mutex-locked code isn't /that/ hard in C or C++ |
| 10:05 |
sapier |
Zeno`: that doesn't help anything if you lock your code down to be singlethreaded again |
| 10:05 |
sapier |
except adding locking overhead |
| 10:05 |
cerulean256 |
sapier: :) |
| 10:05 |
Zeno` |
sapier, correct, which is why I mentioned scheduling earlier |
| 10:06 |
Zeno` |
I may be stupid but the main server loop is in my eyes an atrocity |
| 10:07 |
sapier |
yes celeron I know I'm using locks very much too :-) |
| 10:08 |
sapier |
I'd prefere to use "atomic" for most of those locations but as long as we don't have c++11 ... |
| 10:08 |
sapier |
having to protect a variable increment by mutex is just overkill |
| 10:09 |
sfan5 |
<sapier> I'd prefere to use "atomic" for most of those locations but as long as we don't have c++11 ... |
| 10:09 |
sfan5 |
#if ENABLE_CXX11 |
| 10:09 |
sfan5 |
do c++11 stuff |
| 10:09 |
sfan5 |
#else |
| 10:09 |
sfan5 |
do c++03 stuff |
| 10:09 |
sfan5 |
#endif |
| 10:09 |
sapier |
I won't do that for sure |
| 10:09 |
proller |
lol |
| 10:09 |
sfan5 |
why not |
| 10:09 |
sapier |
cause code will be unreadable |
| 10:10 |
cerulean256 |
it'll also become more difficult to maintian in general |
| 10:10 |
Zeno` |
I disagree. Most pre c++11 (or C) code works fine with mutexes and it doesn't cause considerable processing |
| 10:10 |
sfan5 |
how about writing a generic class for mutexes, locks, etc. and varying the implementation of those between C++11 and C++03? |
| 10:11 |
Zeno` |
Does the Linux kernel use C++11 atomic ops? |
| 10:11 |
proller |
time to https://github.com/minetest/minetest/pull/1390 |
| 10:11 |
celeron55 |
mutexes do have overhead; you can only do like tens of thousands of lockings per second with those without making them a bottleneck |
| 10:11 |
sapier |
for sure not kernel is C |
| 10:11 |
Zeno` |
yeah of course there is overhead, but it should not be a bottleneck |
| 10:12 |
Zeno` |
ok, so the Linux kernel doesn't use atomic ops (it may in some places with ASM, but in general no) and it's not what I'd call inefficient |
| 10:13 |
Zeno` |
Anyway, I am tired :) |
| 10:13 |
Zeno` |
maybe that main loop will be looked at one day |
| 10:13 |
sfan5 |
so.. does anyone want to react to my suggestion? |
| 10:14 |
celeron55 |
sfan5: we have generic classes for those |
| 10:14 |
Zeno` |
sfan5, #ifdef... yuck |
| 10:14 |
celeron55 |
sfan5: it's called our fork of jthread |
| 10:14 |
celeron55 |
sfan5: so feel free to |
| 10:14 |
celeron55 |
as long as you are testing it |
| 10:14 |
* sfan5 |
adds to TODO list |
| 10:14 |
|
LemonLake joined #minetest-dev |
| 10:14 |
Calinou |
<Taoki> Also, I think another problem is we don't network movement fast enough perhaps. Server step is still 0.1 I believe. I suggested (and still do) using at least 0.05 |
| 10:15 |
Calinou |
we used to use 0.05, for some time (how much time?) |
| 10:15 |
Zeno` |
I don't agree that using C++11 crap is the solution |
| 10:16 |
sfan5 |
who said that it is the solution? |
| 10:16 |
Zeno` |
the solution is to refactor the main game loop so it's not so sequential |
| 10:16 |
Calinou |
cerulean256, map generation can use multiple threads (num_emerge_threads = N where N is number of threads, default is 1), but concurrency often happens and the speedup is small |
| 10:16 |
Zeno` |
sfan5, I dunno :) |
| 10:16 |
Calinou |
(and since there's lots of concurrency, you waste power) |
| 10:16 |
sapier |
nooooooo |
| 10:16 |
sapier |
don't use emerge thread multithreaded |
| 10:16 |
sapier |
it's broken |
| 10:16 |
sapier |
hmmmm is working on it but it's not completed |
| 10:18 |
sapier |
and won't help too |
| 10:18 |
Zeno` |
many, many, many games are not multithreaded |
| 10:18 |
sapier |
we're working at main server loop but it's nothing that can be fixed in no time |
| 10:19 |
Zeno` |
I will bet $1 that changes to the main server loop will/can solve 90% of the problems |
| 10:20 |
Calinou |
…and by tweaking server settings |
| 10:20 |
sapier |
and cause about 20% new issues |
| 10:20 |
Calinou |
http://paste.ubuntu.com/7784138/ |
| 10:20 |
Calinou |
(-: |
| 10:20 |
Calinou |
tweak max block sends depending on your bandwidth |
| 10:21 |
Zeno` |
if refactoring the main server loop causes 20% more issues then that's a problem :p |
| 10:22 |
celeron55 |
Zeno`: an MT server without mods doesn't cause "server lag" |
| 10:22 |
celeron55 |
Zeno`: mods cause it by doing a lot of processing during a single tick |
| 10:22 |
sapier |
if refactoring means just moving aroun then it's not gonna fix any issue too |
| 10:22 |
celeron55 |
they run in the same thread |
| 10:23 |
Zeno` |
fair enough then |
| 10:23 |
sapier |
I was talking about spliting async (player related) from sync(mod/game/world) stuff |
| 10:23 |
Zeno` |
and I didn't mean "just moving stuff around" |
| 10:23 |
celeron55 |
really the only built-in heavy processing on the server is the map generator / loader, which is run in a separate thread for that exact reason |
| 10:23 |
Zeno` |
but I guess moving stuff around would at least make it more comprehensible heh |
| 10:23 |
sapier |
and mods ;-) |
| 10:24 |
Zeno` |
I refuse to blame the mods |
| 10:25 |
Zeno` |
Mods are an integral part of MT... to blame them is kind of passing the buck |
| 10:25 |
celeron55 |
sapier: yes, mods, that aren't run in a separate thread |
| 10:25 |
celeron55 |
Zeno`: knowing an issue doesn't mean blaming anyone |
| 10:25 |
sfan5 |
we should really add threading for lua |
| 10:25 |
celeron55 |
Zeno`: this is a completely objective thing |
| 10:25 |
Zeno` |
that might help yeah |
| 10:25 |
Zeno` |
celeron55, maybe |
| 10:26 |
celeron55 |
sfan5: only if it's done properly with added locks in the engine so that it isn't effectively singlethreaded if any api calls are made |
| 10:26 |
sfan5 |
yeah, otherwise there wouldn't be any benefit |
| 10:26 |
celeron55 |
this is again what sapier is aiming for |
| 10:26 |
celeron55 |
and which will take long to achieve |
| 10:27 |
sfan5 |
goal for 0.5.0? |
| 10:27 |
sapier |
nope |
| 10:27 |
celeron55 |
no goal |
| 10:27 |
sapier |
it's a evulutionary process |
| 10:28 |
sapier |
if I change it once everything will be broken |
| 10:28 |
sapier |
my next step towards is adding async api for mods (quite limited in first step but already helpfull for mapgens) |
| 10:29 |
sapier |
as a mapgen doesn't need to interact to map while generating it this can be done completely async |
| 10:30 |
Zeno` |
why not take a step back before doing that? |
| 10:30 |
Zeno` |
I agree that that is a good thing to do, but... hmm |
| 10:31 |
Zeno` |
Even if there is a penalty (speed-wise) for refactoring that horrible main loop I'd do that first |
| 10:31 |
sapier |
because I do this in my freetime and fixing it is about half a year full time work |
| 10:32 |
Zeno` |
I understand that completely sapier and am truly grateful. I did not mean to imply otherwise. |
| 10:32 |
sapier |
guess how long it's gonna be broken if you try to do that much work in free time ;-) ... minetest will work again in ... hmmm ... 2016 |
| 10:33 |
sapier |
I know this isn't perfect but as long as there's noone having that much time available |
| 10:34 |
Zeno` |
I didn't mean to offend, honestly. I just say it as I see it (without consideration of the things you rightfully mention heh) |
| 10:34 |
Zeno` |
Maybe I'll rewrite the loop *shrug* |
| 10:35 |
Zeno` |
I don't need to sleep anyway |
| 10:36 |
sapier |
for this point we know what to do for about a year now |
| 10:36 |
sapier |
ok last half year was spent for getting android port fly ... anyone willing to polish it? so I can focus on server improvement? |
| 10:40 |
Zeno` |
I'll call my for ZenoTest! |
| 10:40 |
Zeno` |
fork* |
| 10:40 |
Zeno` |
android? errr. /me hides |
| 10:43 |
RealBadAngel |
sapier, i will take care of opengles shaders, for sure |
| 10:45 |
celeron55 |
there's probably infinite polishing in it, i can't really suggest anything as i am not in the target audience |
| 10:45 |
celeron55 |
well i can suggest not focusing on it anymore |
| 10:46 |
celeron55 |
maybe try to fix things based on user requests |
| 10:50 |
sapier |
actually that's been my current plan to, fix the bugs but don't do changes like "improved controls" or things like that |
| 10:51 |
sapier |
e.g. a new main menu for small devices would be nice too but I don't think it's fun to play on those devices anywa |
| 10:51 |
sapier |
y |
| 11:01 |
sfan5 |
>maybe try to fix things based on user requests |
| 11:01 |
sfan5 |
this is a very good idea |
| 11:01 |
cerulean256 |
Minetest on PC is best! |
| 11:01 |
cerulean256 |
:) |
| 11:02 |
sfan5 |
request after building bridges over lava for 6 hours: if I place a node somewhere it should stay there and not momentarily disappear |
| 11:02 |
sapier |
the difference between what you understood and what is meant is "fix" isn't same as "implement" sfan5 ;-) |
| 11:03 |
sfan5 |
ik |
| 11:04 |
sapier |
if someone complains "hey my icons are messed up" I'll fix it for sure but if it's "hey controls aren't same as in xzy" ... nope |
| 11:05 |
sapier |
btw can someone reproduce ShadowNinja's issues on Nexus10 and Nexus7? at least on emulator with nexus7 skin (new variant) it doesn#t happen |
| 11:05 |
Zeno` |
my icons are messed up |
| 11:05 |
sapier |
cleanup your desktop ;-P |
| 11:06 |
Zeno` |
oh |
| 11:06 |
Zeno` |
yes, good point |
| 11:06 |
sapier |
no without joking is there a issue with minetest? ;-) |
| 11:06 |
Zeno` |
nope :) |
| 11:07 |
sfan5 |
sapier: yes, icons are messed up on windows |
| 11:08 |
sapier |
sfan5 a screenshot would help ;-) |
| 11:08 |
sfan5 |
the inventory image for cobble is just blank |
| 11:10 |
sapier |
any errors in log? |
| 11:14 |
sfan5 |
no |
| 11:18 |
sapier |
what graphics card? |
| 11:19 |
sfan5 |
AMD |
| 11:19 |
|
asl joined #minetest-dev |
| 11:19 |
sfan5 |
with Direct3D9 btw |
| 11:23 |
sapier |
hmm |
| 11:24 |
sapier |
other inventorycubes are ok? |
| 11:24 |
|
ImQ009 joined #minetest-dev |
| 11:24 |
|
ImQ009 joined #minetest-dev |
| 11:25 |
sfan5 |
sometimes, sometimes not |
| 11:26 |
sapier |
hmm sadly my invenctorycube render fix for android isn't compiled on pc |
| 11:26 |
sapier |
tile.cpp L832 you could try to compile this on py and then set "inventory_image_hack" to true in config |
| 11:27 |
sfan5 |
I'll consider that |
| 11:30 |
Zeno` |
Is inventory pronounced "invent oree" or "inven toree"? |
| 11:30 |
|
vifino joined #minetest-dev |
| 11:32 |
Zeno` |
"invent oree" would suggest a list of items that you invent things with |
| 11:32 |
Zeno` |
"inven toree" would suggest... I dunno |
| 11:33 |
Zeno` |
or isn't it important? |
| 11:36 |
Zeno` |
Maybe it's like "factory" which has nothing at all to do with facts (it stems from "manufactory") |
| 12:06 |
|
Piggybear87 joined #minetest-dev |
| 12:12 |
|
Piggybear87 left #minetest-dev |
| 12:12 |
|
asl joined #minetest-dev |
| 12:12 |
|
LemonLake joined #minetest-dev |
| 12:12 |
|
proller joined #minetest-dev |
| 12:12 |
|
cerulean256 joined #minetest-dev |
| 12:12 |
|
PenguinDad joined #minetest-dev |
| 12:12 |
|
grrk-bzzt joined #minetest-dev |
| 12:12 |
|
Zeno` joined #minetest-dev |
| 12:12 |
|
Hunterz joined #minetest-dev |
| 12:12 |
|
CraigyDavi` joined #minetest-dev |
| 12:12 |
|
nore joined #minetest-dev |
| 12:12 |
|
SoniEx2 joined #minetest-dev |
| 12:12 |
|
us`0gb joined #minetest-dev |
| 12:12 |
|
alexxs joined #minetest-dev |
| 12:12 |
|
HLuaBot joined #minetest-dev |
| 12:12 |
|
kahrl joined #minetest-dev |
| 12:12 |
|
crazyR joined #minetest-dev |
| 12:12 |
|
khonkhortisan joined #minetest-dev |
| 12:12 |
|
Ritchie joined #minetest-dev |
| 12:12 |
|
AnotherBrick joined #minetest-dev |
| 12:12 |
|
Taoki joined #minetest-dev |
| 12:12 |
|
VanessaE joined #minetest-dev |
| 12:12 |
|
deltib joined #minetest-dev |
| 12:12 |
|
VargaD joined #minetest-dev |
| 12:12 |
|
psedlak joined #minetest-dev |
| 12:12 |
|
ShadowNinja joined #minetest-dev |
| 12:12 |
|
hax404 joined #minetest-dev |
| 12:12 |
|
Robby joined #minetest-dev |
| 12:12 |
|
sfan5 joined #minetest-dev |
| 12:12 |
|
harrison joined #minetest-dev |
| 12:12 |
|
eeew joined #minetest-dev |
| 12:12 |
|
netchip joined #minetest-dev |
| 12:12 |
|
Anchakor_ joined #minetest-dev |
| 12:12 |
|
darkrose joined #minetest-dev |
| 12:12 |
|
pitriss joined #minetest-dev |
| 12:12 |
|
celeron55 joined #minetest-dev |
| 12:12 |
|
dzho joined #minetest-dev |
| 12:12 |
|
daswort joined #minetest-dev |
| 12:12 |
|
Gethiox joined #minetest-dev |
| 12:12 |
|
catninja_ joined #minetest-dev |
| 12:12 |
|
RealBadAngel joined #minetest-dev |
| 12:14 |
|
CraigyDavi joined #minetest-dev |
| 13:04 |
sapier |
>>>// Reset periodically to workaround for some bugs or stuff<<<< I hate comments like that causing bugs to be hidden instead of fixed |
| 13:05 |
sapier |
in this special case we send map to player each 20 seconds ... no mater if necessary or not |
| 13:17 |
|
MichaelRpdx joined #minetest-dev |
| 13:30 |
|
Jordach joined #minetest-dev |
| 13:32 |
celeron55 |
sapier: it's not exactly for bugs, it's more about the quirks of the design of the algorithm |
| 13:33 |
celeron55 |
and, well, implementation too; it's just not designed or implemented to be perfect |
| 13:34 |
sapier |
I'm not quite sure but what I think this was necessary because of player modifications may not have been sent soon enough |
| 13:34 |
sapier |
at least that's my current state of investigation |
| 13:34 |
celeron55 |
wait, where is that comment |
| 13:34 |
sapier |
code detecting which blocks to send next |
| 13:35 |
celeron55 |
yes it's where i thought it is |
| 13:35 |
sapier |
I think if I mark blocks modified by player and queue them prior doing the geometry based sending that hack might be unneccessary |
| 13:36 |
celeron55 |
if you want to remvoe that, then it needs proper and solid reset mechanisms for when map has been generated in the area it has skipped, when the player has moved a large distance (i don't know about the exact details involved in doing this) and so on |
| 13:36 |
celeron55 |
it just forces the algorithm to restart to catch all possible things it might not be accounting for |
| 13:36 |
celeron55 |
which in my opinion is the right thing to do instead of making it fail if someone has forgotten to account for some situation |
| 13:37 |
sapier |
right now that code results in nodes having been dug reappearing and vanishing |
| 13:37 |
celeron55 |
because there are many rare and extremely hard to test situations it can run into |
| 13:38 |
celeron55 |
that isn't a problem in the algorithm |
| 13:39 |
sapier |
it seems to me like node mofifications not getting accounted soon enough |
| 13:39 |
celeron55 |
the correct way to fix that is not to remove the ability to send blocks near the player in situations where it is actually needed |
| 13:40 |
celeron55 |
but by doing something else to disallow it handling the state in two places and then mixing them up |
| 13:40 |
celeron55 |
including block modification timestamps in the protocol comes to mind |
| 13:40 |
sapier |
player moving wouldn't be a problem as this can be detected ... not generated blocks ... puuhh not sure about that one |
| 13:41 |
sapier |
when you say blocks you really mean blocks and not nodes true? |
| 13:42 |
sapier |
I don't really understand "(15:39:25) celeron55: the correct way to fix that is not to remove the ability to send blocks near the player in situations where it is actually needed" who does remove the ability to send blocks? |
| 13:42 |
|
LemonLake joined #minetest-dev |
| 13:43 |
celeron55 |
the issue likely is that when the client is placing nodes, it predicts the placement; then the server may have been doing something during that time and as a result of that, it for some reason sends and updated full mapblock to the client not yet containing the placements made by the client to it; then it proceeds to read what the client placed and handles them in whatever way it does it |
| 13:43 |
|
kaeza joined #minetest-dev |
| 13:44 |
sapier |
maybe but that's not what I experience, I dig a lot of nodes in creative mode |
| 13:44 |
celeron55 |
and the client does not know that its actions weren't yet accounted on the data it received while it received the data after its actions |
| 13:44 |
sapier |
on network I see client sending the interact packets as I dig, |
| 13:44 |
sapier |
but block updates are somehow stuffed |
| 13:45 |
celeron55 |
what? |
| 13:45 |
sapier |
I get wholes in update stream ... most likely due to congestion as block information is sent on low priority |
| 13:46 |
sapier |
making the issue even worse |
| 13:46 |
sapier |
basicaly I need a way to handle player originated block changes at higher priority then regular map transmission ... well that's my current working thesis |
| 13:47 |
celeron55 |
oh, so the block update is de-synced from the single-node digging updates and then the client receives it late from some congestion buffer? |
| 13:47 |
sapier |
yes |
| 13:47 |
celeron55 |
this is very likely to be fixed with modification timestamps |
| 13:47 |
sapier |
ok "yes" as I know so far |
| 13:48 |
sapier |
but I'd either have to sync them client server or stop player from changing a block till I got result ... last one is quite laggy |
| 13:48 |
celeron55 |
this is actually caused by your network changes, because the previous code didn't send anything with differing priority |
| 13:49 |
sapier |
I know :-/ |
| 13:49 |
celeron55 |
it might need some weird way of merging past changes into data that is newer than the past changes |
| 13:49 |
celeron55 |
or you could be lazy and just disable differing priorization |
| 13:49 |
sapier |
yes but that'd reintroduce lag |
| 13:49 |
sapier |
well another sort of lag |
| 13:50 |
celeron55 |
so the client needs to be able to see "oh i applied these updates to this block already, but the server is now telling that the block actually was this way so i'll apply all nodes from this block except the ones i updated after its timestamp" 8) |
| 13:50 |
sapier |
that's why I prefere to move the player originated changes ot a higher priority .... as it's supposed to be, sadly for blocks it's not that easy to decide |
| 13:50 |
sapier |
actually server doesn't even send an update if it's fine |
| 13:51 |
sapier |
making it even worse as the outdated block is visible on client till next regular update is received |
| 13:51 |
celeron55 |
usually diggings and placings are handled as single-node updates but we always need to have a functional fallback case of updating the whole mapblock if there is no single-node packet for doing the needed synchronization that the action caused (it can cause anything) |
| 13:52 |
celeron55 |
and that reset in the block sending code enables us to see the bugs in this system |
| 13:52 |
sapier |
for what I've seen that's not correct, client sends single node updates yes |
| 13:52 |
sapier |
but server sends whole block if the result is not as expected by client |
| 13:52 |
sapier |
for digging |
| 13:53 |
sapier |
haven't had a look at placing by now |
| 13:53 |
celeron55 |
yes, that's how it works |
| 13:53 |
proller |
want commit https://github.com/minetest/minetest/pull/1390 |
| 13:54 |
sapier |
I think I know what to do, serve remembers what blocks are on wire, in case a player modifies a block on wire we need to send it too even if the result is as expected |
| 13:55 |
celeron55 |
could work |
| 13:55 |
sapier |
I'll try it that way |
| 13:57 |
celeron55 |
proller: the comments in there seem somewhat reasonable |
| 13:58 |
proller |
nobody never use it |
| 13:59 |
proller |
its outdated and useless |
| 13:59 |
celeron55 |
i think the indev mapgen should be removed too if math is removed |
| 14:00 |
|
hmmmm joined #minetest-dev |
| 14:00 |
proller |
its other pull |
| 14:01 |
proller |
i can remove both |
| 14:02 |
celeron55 |
hmmmm: https://github.com/minetest/minetest/pull/1390 |
| 14:03 |
proller |
and https://github.com/minetest/minetest/pull/1407 |
| 14:06 |
hmmmm |
sounds great |
| 14:07 |
proller |
merge? |
| 14:10 |
hmmmm |
yep |
| 14:10 |
proller |
both? |
| 14:10 |
hmmmm |
yep |
| 14:10 |
proller |
okay |
| 14:16 |
sapier |
celeron55 thanks for discussing that issue just flaging a block being transmitted solves the issue on digging and is way less change then what I first wanted to do :-) |
| 14:19 |
sapier |
I'll check placing too |
| 14:24 |
sapier |
that's strange ... for placing logic is exactly opposite, if there's a prediction block is sent, if not, we'll wait for at max 20 seconds |
| 14:24 |
proller |
done |
| 14:25 |
sapier |
are you done with removing your work by now proller? ;-) |
| 14:26 |
proller |
maybe need to remove json lib too |
| 14:26 |
proller |
but.. |
| 14:26 |
proller |
sapier, write small xml replacement please |
| 14:26 |
sapier |
nope not my issue |
| 14:38 |
|
Calinou joined #minetest-dev |
| 14:39 |
|
diemartin joined #minetest-dev |
| 14:39 |
|
Megaf joined #minetest-dev |
| 14:46 |
sfan5 |
proller: not XML |
| 14:46 |
sfan5 |
xml sucks |
| 14:46 |
|
LemonLake left #minetest-dev |
| 14:46 |
proller |
mtml |
| 14:47 |
sfan5 |
how about YAML? |
| 14:48 |
kahrl |
isn't YAML = JSON + stuff? |
| 14:52 |
sfan5 |
yes |
| 14:58 |
|
crazyR_ joined #minetest-dev |
| 14:59 |
|
Megaf_ joined #minetest-dev |
| 14:59 |
sapier |
I don't see any reason to do any work just because of "proller wants to extinguish his help" |
| 14:59 |
|
CraigyDavi` joined #minetest-dev |
| 15:01 |
proller |
but json is too bad |
| 15:02 |
sapier |
bad ... yes ... bad enough to justify the work? ... no |
| 15:16 |
sfan5 |
so.. what about merging https://github.com/minetest/minetest/pull/1461 ? |
| 15:17 |
sapier |
did you check it with all those databases? |
| 15:19 |
proller |
whats about disabling compression for leveldb |
| 15:19 |
sapier |
for what reason? |
| 15:21 |
sfan5 |
sapier: yes, I even tested migration |
| 15:21 |
proller |
leveldb compress data |
| 15:21 |
|
domtron joined #minetest-dev |
| 15:21 |
proller |
block->searialize too |
| 15:21 |
proller |
why to compress 2 times? |
| 15:22 |
sapier |
serialization does compress block? |
| 15:22 |
sfan5 |
only node data |
| 15:22 |
sfan5 |
nothing else is compressed by ser. |
| 15:22 |
sfan5 |
leveldb can still compress things like node mappings |
| 15:23 |
proller |
so mt compression must be disabled when use leveldb |
| 15:24 |
sfan5 |
why? |
| 15:25 |
proller |
because leveldb will compress anything |
| 15:30 |
sapier |
if there's a resonable amount of additional data to nodes that might still be acceptable |
| 15:30 |
|
werwerwer joined #minetest-dev |
| 15:32 |
sfan5 |
sapier: can we merge #1461 then? |
| 15:35 |
sapier |
ok merge it |
| 15:36 |
* sfan5 |
yays |
| 15:38 |
sfan5 |
k, pushed |
| 15:48 |
|
Jordach_ joined #minetest-dev |
| 15:54 |
|
zat joined #minetest-dev |
| 16:01 |
|
LemonLake joined #minetest-dev |
| 16:03 |
|
us`0gb joined #minetest-dev |
| 16:15 |
hmmmm |
lol |
| 16:15 |
hmmmm |
in a random text file I have "minetest TODOs" |
| 16:15 |
hmmmm |
that obviously hasn't been updated for about a year |
| 16:15 |
sapier |
just for curiosity what's been on that list? ;-) |
| 16:16 |
hmmmm |
"TODO: Un-fuck proller's getHeat/getHumidity bullshit; define an 'unset' value to use as a placeholder when weather is disabled" |
| 16:16 |
hmmmm |
"look into possibility of removing client-side knowledge of heat/humidity" |
| 16:18 |
sapier |
guess that's been done |
| 16:19 |
hmmmm |
ehm. I have an entirely different list of personal todos now, namely "merge some initBlockMake tasks into finishBlockMake" "add a std::set containing the chunk positions currently being generated or queued" |
| 16:19 |
hmmmm |
once this moving BS is done I should be able to finally make progress |
| 16:20 |
hmmmm |
I am glad Freeminer exists as an outlet for features we don't think fit into minetest or have poor implementations well below standards |
| 16:23 |
sapier |
well if fm was lgpl I'd agree but the way it it now it's quite annoying |
| 16:24 |
hmmmm |
there are a couple memory leak fixes that are great to backport but for the most part I don't feel like it affects us too much |
| 16:24 |
hmmmm |
and again, we can circumvent that problem by doing a clean-room implementation of the same fixes by having one person describe the issue and somebody who hasn't seen freeminer's code fix it |
| 16:25 |
sapier |
puuhh ... sounds like a lot of work ... ;-) |
| 16:35 |
|
BlockMen joined #minetest-dev |
| 16:37 |
BlockMen |
sfan5, https://github.com/minetest/minetest_game/issues/273 im fine with. but please not with fencelike drawtype |
| 16:37 |
hmmmm |
so anyway I've settled on a bloom filter to store blocks generated in memory |
| 16:38 |
hmmmm |
only issue is you can't unset elements, but that's O.K. because you're almost never deleting a block from the database, and if you are, the performance penalty of having to do the actual fetch is worth it |
| 16:39 |
hmmmm |
thing is, now I need to compare it to the performance of the various databases doing a query to see if the block is simply present or not |
| 16:39 |
BlockMen |
nore, since all other but not you answered: i think a darker steel texture makes it harder to differ between the stone and steel tools. |
| 16:40 |
BlockMen |
and if you/all want those darker texture change all steel-ting textures aswell before mergin |
| 16:41 |
nore |
hm... hadn't thought about the tools |
| 16:41 |
kaeza |
regarding fences: would it be possible to adapt the collision box to fit the node box (and optionally make it so you can't jump over fences?) |
| 16:42 |
kaeza |
?>>1 |
| 16:42 |
nore |
but anyway, I don't have opinion on dark/light textures being better than the other |
| 16:43 |
BlockMen |
kaeza, you can already add a nodebox to def to prevent jumping over it |
| 16:43 |
kaeza |
BlockMen, hm? |
| 16:43 |
BlockMen |
IIRC PA did that in minitest |
| 16:44 |
kaeza |
BlockMen, yes, but the collision is still kinda "full-node" |
| 16:44 |
kaeza |
+box |
| 16:44 |
kaeza |
i.e. you can't actually go near the fence |
| 16:44 |
kaeza |
I was saying something like xyz's xfences |
| 16:45 |
kaeza |
(but those are implemented kinda like mesecons wires/technic cables) |
| 16:45 |
BlockMen |
kaeza, oh. umm...try out? ;) |
| 16:45 |
BlockMen |
maybe it uses the nodebox at all for collision detetction then |
| 16:46 |
kaeza |
MT doesn't compile under cygwin :/ |
| 16:47 |
kaeza |
or rather, it requires a high amount of hackery in the Irrlicht makefiles |
| 16:49 |
|
LemonLake joined #minetest-dev |
| 16:58 |
|
rubenwardy joined #minetest-dev |
| 16:58 |
|
Calinou joined #minetest-dev |
| 17:01 |
|
Calinou joined #minetest-dev |
| 17:32 |
|
Krock joined #minetest-dev |
| 17:53 |
crazyR_ |
did someone create a swim model for minetest? |
| 17:53 |
crazyR_ |
i remember it but cnt remember where i saw it |
| 17:54 |
LemonLake |
just get lay and rotate it 180 |
| 17:56 |
|
cheapie joined #minetest-dev |
| 18:13 |
|
proller joined #minetest-dev |
| 18:13 |
|
troller joined #minetest-dev |
| 18:13 |
|
proller__ joined #minetest-dev |
| 18:23 |
sapier |
https://github.com/minetest/minetest/pull/1475 is supposed to fix most of the creative node digging lag |
| 18:24 |
sapier |
not exactly all as the updated block is still sent after receiving ack for "on wire" block |
| 18:24 |
|
Amaz_ joined #minetest-dev |
| 18:41 |
|
kaeza joined #minetest-dev |
| 18:58 |
ShadowNinja |
I got this message about the launchpad builds, can someone more knowledgable with launchpad fix this?: http://pastebin.ubuntu.com/7785873/ |
| 18:59 |
ShadowNinja |
It seems like you just have to increment a revision mumber and initiate a re-build. |
| 19:00 |
|
Calinou joined #minetest-dev |
| 19:07 |
|
kaeza joined #minetest-dev |
| 19:09 |
|
Miner_48er joined #minetest-dev |
| 19:59 |
celeron55 |
sapier: at least one comment is quite inaccurate |
| 19:59 |
celeron55 |
sapier: "make sure client knows this block was updated" |
| 20:00 |
celeron55 |
that's not really a useful comment at all |
| 20:00 |
celeron55 |
also client->SetBlockUpdated is a bad method name |
| 20:01 |
celeron55 |
actually, the method name might be fine, but it needs a comment to describe what it exists for |
| 20:02 |
celeron55 |
the comment in where it is used from should say something like "make sure to re-send block to client in case outdated data is still being sent on the wire" |
| 20:03 |
celeron55 |
otherwise it's just wtf and nobody will understand why it's there |
| 20:10 |
sapier |
ok I'll change the comments |
| 20:11 |
sapier |
what about calling the function "MarkBlockUpdated"? |
| 20:12 |
sapier |
or better NotifyBlockModified |
| 20:13 |
Megaf_ |
[17:12:50] <Megaf_> sfan5; sapier; Can you please make a link that points to the latest Androids builds? |
| 20:13 |
sapier |
they're released ;-) |
| 20:13 |
sapier |
github releases |
| 20:17 |
Megaf_ |
sapier; I mean, something like, http://downloadlink,com/latestx86.apk |
| 20:17 |
Megaf_ |
and latestarm.apk |
| 20:18 |
Megaf_ |
like the builds for windows here http://minetest.megaf.info/index.php?id=download-minetest |
| 20:19 |
Megaf_ |
^ PenguinDad |
| 20:20 |
Megaf_ |
Like this http://sfan5.pf-control.de/minetest-builds/latest.php?b=minetest |
| 20:20 |
Megaf_ |
but for apks |
| 20:37 |
|
proller__ joined #minetest-dev |
| 20:52 |
sapier |
why? |
| 20:52 |
sapier |
there's no newer version |
| 20:52 |
sapier |
once there's something usefull I'll build a new version but by now there is none |
| 20:52 |
|
LemonLake left #minetest-dev |
| 20:55 |
sfan5 |
<BlockMen> sfan5, https://github.com/minetest/minetest_game/issues/273 im fine with. but please not with fencelike drawtype |
| 20:55 |
sfan5 |
why not? |
| 20:56 |
VanessaE |
sfan5: I dunno what BlockMen has in mind but I could see a "jersey wall" type of "fence" being useful perhaps, if made of cobble. |
| 20:56 |
sfan5 |
"jersey wall" |
| 20:56 |
VanessaE |
http://static.artfagcity.com/wordpress/wp-content/uploads/2012/05/new_jersey_barrier_2000.jpg |
| 20:56 |
sfan5 |
whats that? |
| 20:57 |
VanessaE |
it's a type of barrier commonly used to separate two sides of a high-speed motorway |
| 20:57 |
sfan5 |
ah |
| 20:57 |
VanessaE |
something like this, made of cobble, might make sense perhaps |
| 20:57 |
VanessaE |
if the cobble were combined with some kind of mortar in the crafting recipe anyway |
| 20:58 |
sfan5 |
what I want is something like those stone things in MC |
| 20:58 |
|
proller__ joined #minetest-dev |
| 20:58 |
VanessaE |
those stone things? |
| 20:58 |
sfan5 |
I don't want a thing this 'heavy' to seperate a walkway from lava.. |
| 20:58 |
sfan5 |
.. |
| 20:58 |
sfan5 |
http://minecraft.gamepedia.com/Cobblestone_Wall |
| 20:58 |
VanessaE |
ah |
| 20:58 |
VanessaE |
I think the castles mod has something like this |
| 21:04 |
VanessaE |
hm, no. strike that, it doesn't. |
| 21:04 |
VanessaE |
still, I like that general idea, but honestly not that form. it's too medieval imho |
| 21:49 |
|
Megaf joined #minetest-dev |
| 22:17 |
|
domtron joined #minetest-dev |
| 23:23 |
|
domtron joined #minetest-dev |
