| Time |
Nick |
Message |
| 00:01 |
Fixer |
related to https://github.com/minetest/minetest/issues/3577 |
| 00:35 |
|
DI3HARD139 joined #minetest-dev |
| 00:40 |
|
Megal joined #minetest-dev |
| 01:24 |
|
KaadmY joined #minetest-dev |
| 01:32 |
|
DI3HARD139 joined #minetest-dev |
| 01:55 |
|
Miner_48er joined #minetest-dev |
| 02:04 |
|
Void7 joined #minetest-dev |
| 02:32 |
|
STHGOM joined #minetest-dev |
| 02:47 |
|
Puka joined #minetest-dev |
| 03:22 |
|
Void7 joined #minetest-dev |
| 03:35 |
|
Sockbat joined #minetest-dev |
| 03:45 |
|
wkmanire joined #minetest-dev |
| 04:55 |
|
Zeno` joined #minetest-dev |
| 05:03 |
|
Hunterz joined #minetest-dev |
| 05:14 |
|
Miner_48er joined #minetest-dev |
| 05:45 |
|
yang2003 joined #minetest-dev |
| 05:52 |
|
nrzkt joined #minetest-dev |
| 06:42 |
|
paramat joined #minetest-dev |
| 06:46 |
paramat |
please can anyone review #4163 ? hmmmm Zeno` ? |
| 06:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/4163 -- Sky: Darker, bluer sky and improved horizon haze at night by paramat |
| 06:46 |
hmmmm |
paramat, that PR is all about personal taste |
| 06:56 |
paramat |
aesthetic decisions still need to be made, so opinions are welcome |
| 06:57 |
hmmmm |
i don't really have an opinion |
| 06:57 |
paramat |
ok no problem |
| 07:02 |
Zeno` |
paramat: https://www.flickr.com/photos/australimage/5469880177/ |
| 07:03 |
Zeno` |
that's the colour of the milky way |
| 07:03 |
Zeno` |
(on a moonless night) |
| 07:03 |
paramat |
lovely |
| 07:03 |
Zeno` |
Almost froze getting that photo :( |
| 07:04 |
hmmmm |
you took that pic? |
| 07:04 |
Zeno` |
yeah |
| 07:04 |
hmmmm |
sweet |
| 07:04 |
paramat |
nice |
| 07:04 |
hmmmm |
why'd you put it on flicker though |
| 07:04 |
Zeno` |
:) |
| 07:04 |
hmmmm |
it does that goofy thing with the image so that you can't save it |
| 07:04 |
hmmmm |
and it makes me have to view source and track down the actual image url |
| 07:04 |
Zeno` |
gcflora is me. At the time I did a photo a day for 1 year and flickr was convenient |
| 07:05 |
Zeno` |
at that time direct links to flickr worked fine (it was before they "improved" it) |
| 07:05 |
paramat |
i'm actually half ozzy, although i live in the UK |
| 07:05 |
hmmmm |
http://c2.staticflickr.com/6/5295/5469880177_211740f02d_b.jpg |
| 07:06 |
Zeno` |
those pools of water in the foreground were frozen the morning after I took the photo |
| 07:06 |
hmmmm |
paramat: ozzy ozborne? |
| 07:06 |
paramat |
lol yes |
| 07:07 |
paramat |
english parents, so dual national |
| 07:07 |
hmmmm |
garbage collecting flora |
| 07:09 |
hmmmm |
sweet |
| 07:10 |
hmmmm |
zeno you went on a trip to africa? |
| 07:10 |
Zeno` |
no |
| 07:10 |
Zeno` |
papua new guinea you're probably looking at |
| 07:10 |
hmmmm |
ahh |
| 07:10 |
hmmmm |
cause i was gonna say, a friend of mine lived in ghana for a year |
| 07:10 |
hmmmm |
it's... quite an experience |
| 07:10 |
Zeno` |
yeah I'd love to go there |
| 07:11 |
Zeno` |
gc is for Gold Coast btw hhehe |
| 07:11 |
hmmmm |
ahh |
| 07:11 |
hmmmm |
whenever I see GC i automatically think of garbage collection |
| 07:11 |
Zeno` |
hehe, well I do that as well |
| 07:11 |
hmmmm |
probably thanks to lua_gc |
| 07:15 |
Zeno` |
most likely :P |
| 07:18 |
paramat |
Zeno` https://github.com/minetest/minetest/issues/2685#issuecomment-223508189 |
| 07:19 |
Zeno` |
paramat, but you can't use the index to do anything can you? |
| 07:19 |
paramat |
? |
| 07:19 |
Zeno` |
I mean... what can you do with the invalid index? |
| 07:20 |
paramat |
if it's within lvm array size it's just a weird location within the lvm |
| 07:21 |
paramat |
if it's outside array size i guess MT throws an error? |
| 07:21 |
Zeno` |
yeah |
| 07:21 |
Zeno` |
e.g. make up and index... let's say -13013010 and try it |
| 07:21 |
Zeno` |
ok not that small |
| 07:21 |
Zeno` |
-1300 |
| 07:21 |
Zeno` |
maybe -13000 ... I dunno something reasonable heh |
| 07:21 |
paramat |
will do |
| 07:21 |
hmmmm |
that issue is dumb |
| 07:22 |
hmmmm |
the person who created it did not bother to do any debugging whatsoever and jump to the conclusion that it must be the fault of the API |
| 07:22 |
hmmmm |
LVM is safe... there is no out-of-bounds memory access happening |
| 07:23 |
paramat |
good |
| 07:23 |
Zeno` |
my point is basically that the lua mod should be making sure it's not sending silly values to s32 index(s16 x, s16 y, s16 z) const in the first place |
| 07:23 |
paramat |
that bug happened to me a few times |
| 07:23 |
|
damiel joined #minetest-dev |
| 07:23 |
Zeno` |
just as they should not make up their own indexes like -1300 and expect it to work |
| 07:23 |
hmmmm |
i'm pretty sure there's a contains() for the lua implementation of VoxelArea |
| 07:24 |
hmmmm |
there's really no excuse |
| 07:24 |
Zeno` |
there is, and also all the functions that actually modify something do do bounds checking |
| 07:25 |
paramat |
it would be odd though to write a mod and include a check for out of bounds, might as well write the mod properly instead |
| 07:25 |
Zeno` |
well, that's up to the mod :) |
| 07:26 |
Zeno` |
if someone wants to write a crappy mod that does unnecessary checks I guess that's up to them haha |
| 07:26 |
paramat |
logical conclusion: add error checks for absolutely everything in a mod |
| 07:26 |
paramat |
so, i feel i was right to close it |
| 07:27 |
hmmmm |
hmmm |
| 07:27 |
hmmmm |
does the bulk set operations of LVM iterate through each table value, or does it specifically check for index 0 and so on |
| 07:28 |
hmmmm |
the latter |
| 07:28 |
hmmmm |
yeah, sorry bug reporter guy, LVM looks solid |
| 07:31 |
nore |
my opinion on this is that the VoxelArea *shouldn't* do any checks |
| 07:31 |
nore |
this was precisely done to get the maximum speed in mapgens |
| 07:31 |
paramat |
exactly |
| 07:31 |
nore |
and there is no security hole, so it is the modder's responsibility |
| 07:32 |
nore |
however, if would be possible to add a setting to do checks, but with the setting enabled, it would be slower |
| 07:32 |
nore |
(to help with mod debugging) |
| 07:33 |
Zeno` |
the mod can check itself can't it? |
| 07:33 |
Zeno` |
using contains() or whatever it's called |
| 07:33 |
paramat |
not a setting, a seperate 'area:' method |
| 07:33 |
Zeno` |
so if they want to debug then they can add debug code... |
| 07:33 |
nore |
Zeno`: it can, the question is, do we want to add a global setting to help with mod debugging? |
| 07:34 |
nore |
yeah, probably |
| 07:34 |
|
nrzkt joined #minetest-dev |
| 07:34 |
nore |
anyway, final two exams today, see you later! |
| 07:35 |
paramat |
actually voxelarea already has 'contains()' |
| 07:35 |
paramat |
will update issue |
| 07:36 |
paramat |
duh if only i'd looked in the first place |
| 07:37 |
paramat |
great last exam day! |
| 07:38 |
Zeno` |
sapier's kludge for connection.cpp should probably be merge |
| 07:38 |
Zeno` |
d |
| 07:38 |
nrzkt |
Zeno`: agreed |
| 07:38 |
nrzkt |
nore: gl&hf |
| 07:39 |
nore |
Zeno`: agreed too |
| 07:39 |
nore |
thanks paramat and nrzkt :) |
| 07:41 |
Zeno` |
someone is having an examination? |
| 07:41 |
Zeno` |
oh! |
| 07:41 |
Zeno` |
gl nore |
| 07:53 |
hmmmm |
dammit zeno |
| 07:53 |
hmmmm |
you pushed the network patch without fixing the -> |
| 08:00 |
Zeno` |
I like the quirky style |
| 08:00 |
Zeno` |
lol |
| 08:00 |
Zeno` |
the strange this is that the first time I looked at that code the -> was the first thing I noticed :/ |
| 08:01 |
Zeno` |
you can fix it when you rewrite connection.cpp I guess |
| 08:02 |
hmmmm |
we keep saying that connection.cpp needs a rewrite but what actually needs the rewrite? |
| 08:03 |
hmmmm |
i guess the basic design is okay |
| 08:03 |
Zeno` |
writeU8(&(b[0]) |
| 08:03 |
hmmmm |
yeah |
| 08:03 |
Zeno` |
it's probably worth doing just a style update for that file |
| 08:04 |
hmmmm |
hmm |
| 08:04 |
hmmmm |
no one particular thing is 'wrong', just the whole thing is wrong |
| 08:04 |
Zeno` |
just to get it consistent at leaset and "out of the way" |
| 08:04 |
hmmmm |
i'll keep the fundamental design of having a send thread and receive thread |
| 08:04 |
hmmmm |
or should I get rid of the separate send/recv threads |
| 08:06 |
Zeno` |
Peer* PeerHelper::operator->() const |
| 08:06 |
Zeno` |
for some reason that scares me |
| 08:06 |
hmmmm |
he tried to make his own smart pointer |
| 08:06 |
hmmmm |
but yea |
| 08:06 |
Zeno` |
hmm ok |
| 08:07 |
hmmmm |
from what i've personally seen, whenever you decide that you need to use a shared pointer for some reason, your object ownership design is probably flawed or you're confused about lifetimes |
| 08:09 |
|
jin_xi joined #minetest-dev |
| 08:09 |
Zeno` |
probably |
| 08:09 |
Zeno` |
and also overloading -> is just something I don't like lol |
| 08:10 |
hmmmm |
i don't like overloading any operators except for stuff where it makes sense like vectors or matricies |
| 08:11 |
Zeno` |
well yes, but in those cases the *use* of them is obvious even in the src code if you're not aware they're overloaded |
| 08:11 |
hmmmm |
overloaded =s are all hidden minefields |
| 08:12 |
hmmmm |
yet people keep adding them |
| 08:12 |
paramat |
=s |
| 08:12 |
hmmmm |
no, you're not making your interface more 'complete' by adding some operator overloading functions |
| 08:12 |
hmmmm |
you're just making it more error-prone when somebody who didn't write it tries to use it |
| 08:23 |
|
davisonio joined #minetest-dev |
| 08:36 |
|
Zeitgeist_ joined #minetest-dev |
| 08:38 |
|
jomat_ joined #minetest-dev |
| 08:39 |
|
ElectronLibre_ joined #minetest-dev |
| 08:40 |
|
AnotherBrick joined #minetest-dev |
| 09:02 |
|
paramat left #minetest-dev |
| 10:14 |
|
sfan5_ joined #minetest-dev |
| 10:49 |
|
Sokomine joined #minetest-dev |
| 11:02 |
|
Samson1 joined #minetest-dev |
| 11:29 |
|
Hunterz joined #minetest-dev |
| 11:46 |
|
lisac joined #minetest-dev |
| 11:46 |
|
davisonio joined #minetest-dev |
| 12:27 |
|
troller joined #minetest-dev |
| 12:28 |
|
Samson1_ joined #minetest-dev |
| 12:32 |
|
davisonio joined #minetest-dev |
| 12:57 |
|
nrzkt joined #minetest-dev |
| 13:16 |
|
davisonio joined #minetest-dev |
| 13:31 |
|
rubenwardy joined #minetest-dev |
| 13:40 |
|
swift110 joined #minetest-dev |
| 13:49 |
|
rubenwardy joined #minetest-dev |
| 13:54 |
|
Megaf joined #minetest-dev |
| 13:55 |
|
Fixer joined #minetest-dev |
| 13:56 |
|
STHGOM joined #minetest-dev |
| 14:02 |
|
Zeno` joined #minetest-dev |
| 14:11 |
|
Wuzzy joined #minetest-dev |
| 14:11 |
Wuzzy |
Okay, people. I am seriously confused. What do you want when you ask for a “rebase†in a PR but there is only 1 commit? |
| 14:13 |
kahrl |
Wuzzy: a rebase on top of master |
| 14:13 |
Wuzzy |
ahhhhhhhhh |
| 14:13 |
Wuzzy |
I see |
| 14:13 |
Wuzzy |
I always thought you are just interested in having commits squashed |
| 14:14 |
kahrl |
yeah, that's also sometimes part of what rebasing means |
| 14:14 |
nrzkt |
Wuzzy, a commit should be rebased to be mergeable often |
| 14:15 |
Wuzzy |
rebasing is kind of dangerous, i don't like to do it often. only when all things are settled |
| 14:15 |
* kahrl |
agrees with that |
| 14:16 |
kahrl |
I usually don't rebase when it's not clear yet that my PR is wanted |
| 14:17 |
nrzkt |
Wuzzy, rebasing is not dangerous except if your PR is too huge |
| 14:17 |
kahrl |
(I might rebase if the conflicts are trivially resolved, or if a rebased version is needed for the discussion) |
| 14:19 |
Zeno` |
I'm not sure it's dangerous; resolving conflicts might be but that's gotta be done anyway |
| 14:19 |
Wuzzy |
why are rebases a thing in minetest, actually? i never understood that |
| 14:19 |
Wuzzy |
like, ALL prs must go through this,right? |
| 14:19 |
kahrl |
not all |
| 14:20 |
kahrl |
only those that conflict with something that happened in master |
| 14:20 |
Zeno` |
Wuzzy, If there are no conflicts then it's not necessary |
| 14:20 |
kahrl |
and in that case, you'd have to resolve those conflicts in any project |
| 14:20 |
Wuzzy |
so basically you are asking the committer to resolve all conflicts on his own? |
| 14:21 |
Wuzzy |
isnt that what merges are for...? |
| 14:21 |
|
troller joined #minetest-dev |
| 14:21 |
Wuzzy |
or did i miss something |
| 14:23 |
kahrl |
if a dev resolved the conflicts during merge, then there would be no way to review those final changes before it's too late |
| 14:23 |
|
Hunterz joined #minetest-dev |
| 14:25 |
Wuzzy |
ah, so thats the rationale |
| 14:25 |
Wuzzy |
ok thanks |
| 14:26 |
Zeno` |
If they're trivial to fix I will /sometimes/ rebase as I merge but... |
| 14:26 |
Wuzzy |
hmmm wait. when you ask for rebase, do you actually ever mean to squash commits as well? or is that not what you want? |
| 14:26 |
Zeno` |
no, rebasing and squash are two different things |
| 14:27 |
Wuzzy |
fun thing is you can do both in git rebase ... |
| 14:27 |
Zeno` |
you'd (well, I) would normally rebase before squashing |
| 14:28 |
Zeno` |
yeah, but if there are lots of commits... I dunno. Often it takes a variety of ways/approaches and every situation is usually different |
| 14:33 |
|
Grandolf joined #minetest-dev |
| 14:53 |
|
electrodude512 joined #minetest-dev |
| 14:57 |
|
celeron55 joined #minetest-dev |
| 15:05 |
|
electrodude512 joined #minetest-dev |
| 15:18 |
|
celeron55 joined #minetest-dev |
| 15:20 |
|
hmmmm joined #minetest-dev |
| 15:47 |
|
Krock joined #minetest-dev |
| 15:57 |
|
electrodude512 joined #minetest-dev |
| 15:59 |
|
BrandonReese joined #minetest-dev |
| 16:06 |
|
paramat joined #minetest-dev |
| 16:07 |
|
Void7 joined #minetest-dev |
| 16:08 |
|
KaadmY joined #minetest-dev |
| 16:20 |
|
troller joined #minetest-dev |
| 16:20 |
paramat |
#4185 |
| 16:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/4185 -- Biomes: Add biome-definable riverbed material by paramat |
| 16:38 |
|
troller joined #minetest-dev |
| 17:06 |
|
troller joined #minetest-dev |
| 17:07 |
|
electrodude512 joined #minetest-dev |
| 17:26 |
hmmmm |
paramat, I would prefer that you don't get into the habit of adding new biome node types for specific scenarios |
| 17:26 |
hmmmm |
this is precisely where i imagined the direction of things will go when you announced "river" water |
| 17:27 |
|
est31 joined #minetest-dev |
| 17:27 |
hmmmm |
what if a river is its own biome? |
| 17:27 |
hmmmm |
then it wouldn't need any "special" node definitions at all |
| 17:27 |
hmmmm |
the logic right now is looking like this: |
| 17:28 |
hmmmm |
we define the abstract concept of biomes, where a biome has a specific amount of filler, a specific type of filler node, a type of rock, a type of liquid |
| 17:28 |
hmmmm |
but now you are tacking on top of all this, "but what if there's the special case of a river inside of this biome!" |
| 17:28 |
hmmmm |
a river is a non-abstract concept specific to some mapgens that could be defined as a biome to begin with |
| 17:29 |
hmmmm |
"but now inside of this special case there's a special type of node!" |
| 17:29 |
hmmmm |
big -1 from me. |
| 17:29 |
hmmmm |
in fact i want to remove "river water" as well. |
| 17:29 |
paramat |
yeah defining it as a biome is another way, but unsure that is better |
| 17:29 |
est31 |
okay lets talk about #4173 |
| 17:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/4173 -- Initial Gamepad support by est31 |
| 17:29 |
est31 |
what do you think? |
| 17:29 |
hmmmm |
this is going way against the entire concept of user-definable biomes |
| 17:30 |
est31 |
Zeno`, sofar ready for merge? |
| 17:30 |
hmmmm |
this kind of logic is absolutely killing it |
| 17:30 |
paramat |
nope |
| 17:30 |
Zeno` |
est31, yes |
| 17:30 |
paramat |
well, you mean if river was a biome then it's 'water' would be enough? |
| 17:31 |
hmmmm |
exactly |
| 17:31 |
Zeno` |
est31 it's a brand new feature... the sooner it's merged the better IMO |
| 17:31 |
hmmmm |
and if river was a biome you wouldn't need to define its own "riverbed" node |
| 17:31 |
hmmmm |
this is why i think it's silly |
| 17:31 |
paramat |
ok worth considering |
| 17:31 |
hmmmm |
you keep tacking on special cases on top |
| 17:31 |
est31 |
Zeno`, great |
| 17:31 |
est31 |
merging it then |
| 17:31 |
Zeno` |
cool |
| 17:35 |
paramat |
i'll think on it, but i feel it's quite possible my approach works better overall. river as biome may have it's own problems |
| 17:36 |
paramat |
i've spent a lot longer on this biome system than anyone else and it seems quite possible i have chosen this direction for good reason |
| 17:37 |
paramat |
but i want to consider the alternative too |
| 17:37 |
hmmmm |
okay that's a great appeal to authority, but you didn't add any reasons |
| 17:37 |
hmmmm |
the biome system as it exists right now is extremely static |
| 17:37 |
paramat |
well it might be an intuitive thing, not easy to immediately verbalise right now |
| 17:38 |
hmmmm |
i'm trying to fix this as we speak but you keep cementing in special cases that are hard to abstract away |
| 17:38 |
paramat |
maybe you're abstracting too much? |
| 17:39 |
hmmmm |
my goal is, by the end of the year, have a space mapgen |
| 17:39 |
paramat |
=) |
| 17:39 |
hmmmm |
not because i like space and i want to make a space world |
| 17:40 |
est31 |
in the ideal case one would have voxel area objects for planets |
| 17:40 |
hmmmm |
but because i think it represents a lofty goal and a huge departure from the standard minetest world types |
| 17:40 |
est31 |
with custom gravity |
| 17:40 |
paramat |
heh |
| 17:40 |
hmmmm |
right |
| 17:40 |
hmmmm |
and you can have "nebulas" as biomes |
| 17:40 |
hmmmm |
with a different type of air |
| 17:40 |
hmmmm |
(or really, water) |
| 17:40 |
paramat |
c55 would approve of this |
| 17:41 |
hmmmm |
this is what i want |
| 17:41 |
hmmmm |
i don't want more of the same |
| 17:41 |
paramat |
ok well i want to investigate the river as biome thing then, i hope to be convinced |
| 17:42 |
hmmmm |
i can tell you're probably not going to give it a fair chance |
| 17:42 |
paramat |
i will |
| 17:42 |
hmmmm |
it takes more effort up front |
| 17:42 |
paramat |
btw working on mapgen is lovely now since your changes |
| 17:42 |
hmmmm |
god forbid you need to code new stuff instead of adding a new parameter to a Biome object :) |
| 17:43 |
hmmmm |
freaking parameters/config/settings should not take up the majority of the code |
| 17:43 |
hmmmm |
it's so mundane and trivial of a task - passing around data |
| 17:43 |
hmmmm |
why are we spending so much time on this |
| 17:44 |
paramat |
well i'm glad you're around and active now, it was scary without you, i became the mapgen authority (!) |
| 17:44 |
hmmmm |
that's partly because i got bored with the mapgen |
| 17:45 |
hmmmm |
i still haven't achieved what i set out to do but i don't want to be a one-trick pony at the same time |
| 17:45 |
paramat |
i'll close that PR then |
| 17:45 |
hmmmm |
you could keep it open for discussion |
| 17:45 |
paramat |
ok |
| 17:57 |
|
ssieb joined #minetest-dev |
| 17:58 |
hmmmm |
i think mapgens are too much like the rendering pipeline of the olde days |
| 17:59 |
hmmmm |
you can have any color you want as long as it's black |
| 17:59 |
hmmmm |
and then a lua on_generated callback is the equivalent to shaders, except it's not fast at all... |
| 17:59 |
hmmmm |
heh |
| 18:02 |
|
Thomas-S joined #minetest-dev |
| 18:03 |
|
electrodude512 joined #minetest-dev |
| 18:04 |
* sofar |
peeks in |
| 18:24 |
|
est31 joined #minetest-dev |
| 18:24 |
hmmmm |
alright so while i was taking a shit i thought about the whole biome thing a bit more |
| 18:25 |
hmmmm |
1). i've decided on how to implement the biome cache, i'm going to use 3d coordinates. if a specific biome system happens to be 2d, they can still utilize the biomecache by passing one of the coordinates as a constant |
| 18:26 |
hmmmm |
2). yes there will be 2d and 3d biomegens, what we currently have is like 2.5D (like overlapping sectors in the BUILD engine!) |
| 18:26 |
hmmmm |
a pure 3d biome system will be necessary for a space biome |
| 18:27 |
hmmmm |
3). we can't reasonably expect biomes and terrain to be divorced from each other because much of the time it's necessary for them to correlate. minecraft solves this by generating biomes first, and then determining terrain shape from the biome |
| 18:27 |
hmmmm |
since we don't have this luxury, instead what we can do is tell the biomegen about the terrain we created |
| 18:28 |
hmmmm |
i had ideas about this in the past such as sending an edge detection map as the "terrain variance" to be a factor in determining biomes |
| 18:28 |
hmmmm |
this can still be done in a separate biomegen |
| 18:28 |
hmmmm |
but what i think would be the best solution is to have a mechanism where the mapgen (or really anything that uses a biomegen) can tell the biomegen that it wants certain nodes to be certain biomes |
| 18:29 |
hmmmm |
so the mapgen can generate rivers, caves, etc. like it does normally, and then tell the biomegen "hey btw this node is supposed to be part of a river" and so it (depending on biomegen implementation) could allow this additional information to either influence in part or determine in whole the biome at that pos |
| 18:30 |
hmmmm |
now i'm not saying that we should hardcode rivers and caves in the biomegen, but rather come up with a generic mechanism for directly assigning a certain biome id to a certain node based on the presence of a certain voxel flag |
| 18:31 |
hmmmm |
this way the concern of what a "river" or a "cave" is still made the responsibility of the mapgen, not some other component |
| 18:38 |
* sofar |
tries to follow |
| 18:39 |
|
proller joined #minetest-dev |
| 18:40 |
sofar |
est31: did you manage to fix the player animations in the gamepad patch? |
| 18:40 |
est31 |
yes |
| 18:40 |
sofar |
nice |
| 18:40 |
sofar |
so I think it's just inventory/formspec stuff left, then |
| 18:40 |
est31 |
yeah |
| 18:48 |
sofar |
hmmmm: it sounds like an improvement, but I'm wondering if allowing biomes to generate their own terrain wouldn't be the solution you'd actually want |
| 18:50 |
hmmmm |
sofar: that was my earliest attempt and it was a total wreck |
| 18:50 |
hmmmm |
i'd need to interpolate all the bits of terrain together |
| 18:50 |
sofar |
doesn't surprise me |
| 18:50 |
sofar |
right |
| 18:54 |
hmmmm |
i think it might be doable though |
| 18:54 |
paramat |
reading |
| 18:55 |
hmmmm |
here's an idea for a mapgen that doesn't fit the standard mold: makeChunk generates biomes, calls an on_biome callback, a lua-defined terrain function will generate a column of terrain, then the core mapgen will interpolate that piece together :) |
| 18:56 |
hmmmm |
will be extremely slow until script locking gets 'solved' though |
| 19:27 |
paramat |
any comments or reviews for #4163 ? |
| 19:27 |
ShadowBot |
https://github.com/minetest/minetest/issues/4163 -- Sky: Darker, bluer sky and improved horizon haze at night by paramat |
| 19:48 |
|
xunto joined #minetest-dev |
| 20:28 |
|
bugzapper joined #minetest-dev |
| 20:32 |
|
rubenwardy joined #minetest-dev |
| 20:38 |
|
ElectronLibre joined #minetest-dev |
| 20:51 |
|
Miner_48er joined #minetest-dev |
| 20:54 |
|
DFeniks joined #minetest-dev |
| 21:21 |
Fixer |
who has ubuntu 16.04? anyone can compile newest debug 64bit build to help tenplus1? |
| 21:22 |
Fixer |
network patch did not help |
| 21:22 |
|
Puka joined #minetest-dev |
| 21:30 |
|
Zeitgeist_ joined #minetest-dev |
| 21:43 |
|
Void7 joined #minetest-dev |
| 21:44 |
|
STHGOM joined #minetest-dev |
| 21:51 |
|
paramat joined #minetest-dev |
| 21:57 |
|
damiel joined #minetest-dev |
| 22:06 |
|
torgdor joined #minetest-dev |
| 22:13 |
|
proller joined #minetest-dev |
| 22:51 |
|
paramat left #minetest-dev |
| 22:51 |
|
STHGOM joined #minetest-dev |
| 23:38 |
|
est31 joined #minetest-dev |
| 23:39 |
Calinou |
est31: :( can we stop overcaring about legacy? |
| 23:39 |
Calinou |
https://github.com/minetest/minetest/issues/4184#issuecomment-223714393 |
| 23:39 |
Calinou |
this is how you create another OpenGL or Windows |
| 23:40 |
est31 |
Calinou, i dont overcare |
| 23:40 |
est31 |
i dont care for stuff that isnt installed in the wild |
| 23:40 |
est31 |
if sb wants to remove compat to clients that are installed by less than 5% active users, fine |
| 23:41 |
est31 |
but I want to avoid major breakages |
| 23:43 |
est31 |
Calinou, its also totally contrary to how minetest was built |
| 23:43 |
est31 |
minetest has lots of backwards compat features inside |
| 23:43 |
est31 |
I'm just taking the legacy and trying not to fuck up everything :) |
| 23:46 |
|
Puka joined #minetest-dev |
| 23:47 |
est31 |
But maybe we can now default send_pre_v25_init to false |
| 23:48 |
Calinou |
[01:43:16] <est31> minetest has lots of backwards compat features inside |
| 23:48 |
Calinou |
way too much IMO |
| 23:48 |
Calinou |
only map format really needs to be compatible |
| 23:48 |
Calinou |
that's about it |
| 23:48 |
Calinou |
nobody cares if we can connect to Linux 0.1-running servers |
| 23:51 |
est31 |
agreed, we should not give compat for too old versions |
| 23:52 |
est31 |
but the way godot does it is IMO totally wrong |
| 23:52 |
est31 |
devising new formats every version |
| 23:52 |
est31 |
then breaking them in between |
| 23:52 |
est31 |
etc |
| 23:53 |
est31 |
Calinou, the more interesting question in that thread is whether we should use that library or not |
| 23:53 |
est31 |
do you know of any projects using it? |
| 23:57 |
est31 |
Calinou, part of why many minetest servers are so popular is because any client can connect to them |
| 23:58 |
est31 |
Calinou, what would you say if 90% of your players can't connect to minetest CTF? |
| 23:59 |
est31 |
Calinou, also it would split the community between users of the nightly builds and users of the stable versions |
