Time |
Nick |
Message |
00:01 |
hmmmm |
how does regular glass overcome this problem? (note: at this point the only thing i'm doing is using EMT_TRANSPARENT_ALPHA_CHANNEL and drawing it with glasslike) |
00:03 |
hmmmm |
http://ompldr.org/vaTZ1aw |
00:17 |
hmmmm |
erm, it doesn't, nevermind |
00:18 |
hmmmm |
from what i understand, irrlicht does have transparency sorting but it's just broken |
00:19 |
kaeza |
how old is Irrlicht? because it seems pretty bugged for a project so widespread |
00:19 |
hmmmm |
*shrug* |
00:20 |
kaeza |
it just strikes me odd |
00:21 |
kaeza |
well, it's no surprise when MT is about 3yrs old and there are tons of bugs lol |
00:23 |
hmmmm |
note: EMT_TRANSPARENT_ADD_COLOR needs to be used for mobs shooting things, it looks awesome |
00:30 |
hmmmm |
ah, irrlicht does do transparency sorting, but only per-node, but the entire minetest world is a node |
00:30 |
|
dzho joined #minetest-dev |
00:30 |
hmmmm |
well crap this is dumb |
00:31 |
hmmmm |
how do we fix this.... what if we put all transparent nodes (water, this new node type, clouds, etc.) into their own separate irrlicht scene nodes |
00:32 |
hmmmm |
obviously this wouldn't work too well if someone were to mix and match transparent nodes with solid nodes |
00:33 |
hmmmm |
am i mistaken about this? should irrlicht be able to do transparency sorting with varius materials on a single node |
00:34 |
|
Taoki joined #minetest-dev |
00:37 |
kaeza |
https://github.com/minetest/minetest/pull/679 |
00:45 |
|
dexter0 joined #minetest-dev |
00:52 |
|
jojoa1997|Tablet joined #minetest-dev |
01:02 |
hmmmm |
you know this might be a dumb suggestion but... doesn't metology use hardware lighting? what if we just go and check out what they're doing for light occlusion? i know they're not the greatest, but if they have this sorted out, i'd like to see how |
01:05 |
kaeza |
https://dl.dropboxusercontent.com/u/100008207/screenshot_doomtest.jpg |
01:05 |
kaeza |
:D |
01:07 |
hmmmm |
erm, not metology, terasology* |
01:07 |
hmmmm |
the hell is with the *ologies |
01:07 |
hmmmm |
hah |
01:07 |
hmmmm |
i assume you did that with the hud api |
01:08 |
kaeza |
yep :P |
01:09 |
kaeza |
with those changes much more flexible layout is possible |
01:10 |
kaeza |
you can even fake "wielditems" by using an overlay and fully transparent (i.e. empty) wield images |
01:36 |
RealBadAngel |
thats why we are having problems with too many vertices/indices sometimes. i guess mt way is an abuse of irrlicht. in their forums ive read an answer about this limit |
01:36 |
RealBadAngel |
"who would need so many indices/vertices for a single model??" |
01:37 |
|
mrtux_ joined #minetest-dev |
01:37 |
RealBadAngel |
by now it is like we are displayin world same way as other irrlicht apps single mob or player model for example |
01:38 |
|
ssieb joined #minetest-dev |
02:16 |
hmmmm |
let's just try hiding transparent faces that are behind other transparent faces |
02:21 |
|
kaeza1 joined #minetest-dev |
02:24 |
VanessaE |
hi all. |
02:24 |
VanessaE |
hmmmm: what's news? figured out the alpha channel issue? |
02:25 |
hmmmm |
i guess you can use it if you accept that it won't look right around water |
02:25 |
VanessaE |
(I saw the screeshot) |
02:25 |
VanessaE |
+n |
02:25 |
VanessaE |
not right, how? |
02:25 |
hmmmm |
thought you saw the screenshot |
02:26 |
VanessaE |
http://ompldr.org/vaTZ1aA\ |
02:26 |
VanessaE |
http://ompldr.org/vaTZ1aA |
02:26 |
VanessaE |
this one, yes. |
02:26 |
hmmmm |
this http://ompldr.org/vaTZ1aw |
02:26 |
VanessaE |
ah, didn't see that one |
02:26 |
VanessaE |
that could be an issue :) |
02:27 |
VanessaE |
same thing that causes clouds to appear in front of water fountains and the like, I guess |
02:27 |
hmmmm |
yes, except this is much more irritating |
02:27 |
VanessaE |
lol |
02:27 |
hmmmm |
and since this entire thing was to be for ice, that make it pretty much unsuitable |
02:27 |
VanessaE |
rigt |
02:28 |
VanessaE |
I bet you'll figure it out though, given adequate time |
02:28 |
hmmmm |
[10:16 PM] <hmmmm> let's just try hiding transparent faces that are behind other transparent faces |
02:28 |
VanessaE |
right |
02:30 |
RealBadAngel |
http://i.imgur.com/t2HpgHT.jpg |
02:30 |
RealBadAngel |
this is where i am at the moment |
02:30 |
RealBadAngel |
im pretty done with it, just a single issue to solve |
02:31 |
VanessaE |
beautiful |
02:32 |
VanessaE |
*looks at screenshot again*... what issue? |
02:33 |
RealBadAngel |
you cant see it there ;) sometimes, dunno why on the edges of the block check for neighbours doesnt see glasslike nodes |
02:34 |
VanessaE |
oh |
02:34 |
RealBadAngel |
then you need to punch it to update and form correct connections |
02:35 |
RealBadAngel |
im not sure what causing it, but its a really weird behaviour, when you place nodes from left to right it wont happen |
02:35 |
RealBadAngel |
if in reverse order, on block edge next wont see previous node |
02:36 |
RealBadAngel |
but if you punch it, it will recheck and look ok |
02:38 |
RealBadAngel |
http://i.imgur.com/NZUNRkE.png |
02:39 |
RealBadAngel |
this is huge glass surface, right after reload game |
02:39 |
VanessaE |
weird. |
02:39 |
RealBadAngel |
see artifacts? |
02:39 |
VanessaE |
yes |
02:39 |
RealBadAngel |
after some time they all will disappear |
02:39 |
RealBadAngel |
or when you come closer and punch it to force update |
02:40 |
RealBadAngel |
this is not a bug in my code |
02:40 |
VanessaE |
as far as you know ;) |
02:40 |
RealBadAngel |
n2 = data->m_vmanip.getNodeNoEx(n2p); |
02:40 |
RealBadAngel |
if (current == n2.getContent()) |
02:40 |
RealBadAngel |
detNodeNoEx seems to fail sometimes |
02:40 |
RealBadAngel |
*get |
02:41 |
hmmmm |
by fail you mean return CONTENT_IGNORE? |
02:41 |
hmmmm |
or just return something wrong |
02:41 |
RealBadAngel |
this happens when blocks are fully loaded |
02:41 |
RealBadAngel |
i can reproduce this bug when placing nodes |
02:41 |
hmmmm |
that's a pretty huge bug if that's the case |
02:42 |
RealBadAngel |
im placing a line of nodes one by one |
02:42 |
RealBadAngel |
when im crossing block border this function doesnt see the neighbour |
02:43 |
RealBadAngel |
but in certain direction only |
02:43 |
RealBadAngel |
if i perform check from left to right it works |
02:43 |
RealBadAngel |
from right to left dont |
02:46 |
RealBadAngel |
http://i.imgur.com/KwYJEdv.png |
02:46 |
RealBadAngel |
i just placed 2 nodes inside to form connections, this one selected and one above |
02:47 |
RealBadAngel |
and they dont see neighbours to the left |
02:47 |
RealBadAngel |
however if i do punch the nodes to the left, they will see new ones |
02:47 |
RealBadAngel |
and connections will be fixed |
02:48 |
VanessaE |
well that means you could do the hacky thing and simulate a punch after each node is placed ;-) |
02:48 |
RealBadAngel |
left on the screenshot is x+, right is x- |
02:48 |
VanessaE |
but that's a horrible solution |
02:48 |
RealBadAngel |
its worse |
02:48 |
RealBadAngel |
punching the placed node wont help |
02:49 |
ShadowNinja |
RealBadAngel: normal glass has that issue too |
02:49 |
RealBadAngel |
you have to punch node next to it i mean in other block |
02:49 |
RealBadAngel |
the faulty connection is at the border of blocks |
02:50 |
RealBadAngel |
so, to the point, gedNodeNoEx is bugged imho |
02:50 |
VanessaE |
hey Mr. Literal, the ";-)" usually means "I'm not being 100% serious" :-) |
02:50 |
RealBadAngel |
this cannot be because block is not loaded or something |
02:50 |
RealBadAngel |
it surely is loaded |
02:56 |
RealBadAngel |
btw it will fix itself after some time |
02:57 |
RealBadAngel |
looks like getNodeNoEx is workin on kinda cache |
02:57 |
RealBadAngel |
and its got updated or somethin |
02:57 |
hmmmm |
by the way you do realize that a block can be blank if loaded with emergeBlock() anymore, right? |
02:57 |
hmmmm |
s/anymore// |
02:58 |
hmmmm |
that might be what's tripping you up |
02:58 |
hmmmm |
i changed it that way so nothing else besides the emergethread can generate map |
02:59 |
RealBadAngel |
it updated now after like 1 minute i placed the blocks |
02:59 |
RealBadAngel |
(nodes) |
03:00 |
RealBadAngel |
notice this wont happen if i place new nodes 1 to the left |
03:00 |
RealBadAngel |
they will always see neighbour in x- direction |
03:00 |
RealBadAngel |
and bug wont pop up |
03:01 |
RealBadAngel |
it happens only in + direction, imho on all axises |
03:03 |
RealBadAngel |
i will check it later today when i will be back from work |
03:03 |
RealBadAngel |
now have to go, cya later |
03:19 |
VanessaE |
bbl. sleep. |
03:40 |
|
Pentium44 joined #minetest-dev |
04:02 |
kaeza |
what is VoxelManipulator? some kind of "double-buffered system" for the world? |
04:02 |
kaeza |
just being curious |
04:05 |
ShadowNinja |
kaeza: It is a faster way of modifying the map |
04:06 |
kaeza |
ah I see that |
04:15 |
Pentium44 |
ohh hi ShadowNinja |
04:16 |
ShadowNinja |
Hello Pentium44. |
04:16 |
Pentium44 |
you have you been? |
04:16 |
Pentium44 |
its madchicken13 |
04:16 |
Pentium44 |
or WiredOnLinux, or M13, or UbuntuNerd too |
04:17 |
Pentium44 |
same person |
04:19 |
ShadowNinja |
Pentium44: huh, are you saying I am that person? I am not and this should be in #minetest. |
04:20 |
Pentium44 |
sorry, and no 'I' am that person |
04:20 |
Pentium44 |
that is what I meant |
04:20 |
ShadowNinja |
OK, well better stop chatting here. |
04:21 |
hmmmm |
hrm |
04:22 |
hmmmm |
how would you guys like to tell minetest to use the alpha channel of a texture? |
04:22 |
hmmmm |
would you set alpha to some value below 255? |
04:22 |
hmmmm |
or would you rather have a new boolean parameter, use_alpha (this would require a change in the ContentFeatures version) |
04:24 |
ShadowNinja |
hmmmm: Is there an advantage to the second version (if I am understanding you correctly)? |
04:24 |
hmmmm |
well it's not as hacky, and what happens is clearer. |
04:27 |
ShadowNinja |
Well I think you want Minetest to use a transparent texture if it is one, I can't think of any case where you wouldn't. |
04:27 |
hmmmm |
you think i would want that, but in fact i don't |
04:28 |
ShadowNinja |
Why not? |
04:30 |
hmmmm |
because the drawing mode used for this type of material is quite slow |
04:31 |
ShadowNinja |
Well that is what I was asking when I asked about the disadvantades ;-) |
04:32 |
ShadowNinja |
So add the uses_alpha or similar option |
04:33 |
hmmmm |
you must've understood me ... |
04:34 |
VanessaE |
hmmmm: re: alpha, it should be based on whether the node's textures have an alpha channel at all, imho |
04:34 |
VanessaE |
rather than an explicit flag |
04:34 |
hmmmm |
and i just explained why that's not happening |
04:34 |
VanessaE |
sorry, guess I missed it |
04:36 |
VanessaE |
*reads* again |
04:36 |
VanessaE |
ok, so a flag then. |
04:36 |
hmmmm |
and then i said adding a new flag would require a contentfeatures version change |
04:36 |
VanessaE |
saw that. |
04:37 |
hmmmm |
meh, i'll just add a flag in lua but it won't actually be part of contentfeatures. |
04:38 |
hmmmm |
and it'll just modify the alpha parameter on its own |
04:40 |
VanessaE |
now the real question: can this be used arbitrarily e.g. with nodeboxes? or strictly cubes? |
04:40 |
hmmmm |
can glass be used with nodeboxes? |
04:41 |
VanessaE |
well the texture certainly can ;) but I mean for example, in the "fancy" door in homedecor. The glass insert there should have been translucent, were it possible. |
04:42 |
hmmmm |
i remember seeing a glass tube nodebox for something |
04:42 |
hmmmm |
that's not glasslike? |
04:43 |
VanessaE |
that was probably pipeworks pneumatic tube. |
04:43 |
VanessaE |
and no, it ain't. |
04:45 |
VanessaE |
(that is, however, another example that would look beautiful with skilled use of alpha) |
04:53 |
hmmmm |
you might be able to use it without glasslike |
04:53 |
hmmmm |
you just need to make sure that the backface isn't culled |
04:53 |
hmmmm |
erm that's stupid |
04:53 |
hmmmm |
that comes automatically with nodebox |
04:54 |
hmmmm |
nvm, so yeah, you can use this with nodeboxes |
05:04 |
VanessaE |
seet |
05:04 |
VanessaE |
sweet, too. |
05:38 |
hmmmm |
i still have to make the shader for this |
05:39 |
VanessaE |
oh that'll be real fun |
05:40 |
VanessaE |
I don't think I'd worry about that, honestly. |
05:40 |
VanessaE |
more pressing is the need for smooth lighting across nodeboxes/2d objects |
05:40 |
VanessaE |
(frankly, the flat lighting among smooth-lighted objects makes those things look like total shit in some situations. :-/ ) |
05:42 |
VanessaE |
(issues https://github.com/minetest/minetest/issues/104 and https://github.com/minetest/minetest/issues/125 ) |
05:46 |
khonkhortisan |
Quothe the raven, 404 |
05:48 |
VanessaE |
khonkhortisan: 2d objects issue (look at the ceiling), http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/homedecor1.png |
05:52 |
VanessaE |
nothing handy that shows the nodebox issue but we've all seen that one. same effect, but in 3d. |
05:52 |
kaeza |
there's one in the slabrealm mod |
05:54 |
VanessaE |
http://i49.tinypic.com/2v8oljl.jpg |
05:55 |
kaeza |
that one |
05:55 |
VanessaE |
(the other one is misleading because of the attempted recolored slab textures) |
05:57 |
khonkhortisan |
it looks topographic |
05:57 |
VanessaE |
mmhmm |
06:17 |
|
bookwar1 joined #minetest-dev |
06:25 |
celeron55 |
i see quite little comments in here about https://github.com/minetest/minetest/pull/679 so i assume nobody opposes it |
06:25 |
* celeron55 |
merges |
06:26 |
VanessaE |
merge it. seen kaeza's joke image? :) |
06:33 |
ShadowNinja |
If you feel like merging some pull requests I have some that nobody oposes... |
06:35 |
khonkhortisan |
repost: http://imgur.com/wqJaBg7 |
06:36 |
khonkhortisan |
I have some that people oppose :) |
06:37 |
ShadowNinja |
Me too (but for bad reasons imo). |
06:38 |
khonkhortisan |
I put the cart before the horse (rail before the cart) |
06:43 |
ShadowNinja |
Well I hope they get merged, I had better go now. |
06:53 |
celeron55 |
umm well |
06:54 |
celeron55 |
i guess if i merge some small scriptapi stuff, it won't conflict too much with sapier's rework stuff |
06:54 |
celeron55 |
it might though; i already said him there won't be changes if he gets it done fast |
06:55 |
celeron55 |
well the hud improvements already conflict with such so i'll just do this |
07:47 |
|
ecube_ joined #minetest-dev |
08:23 |
|
ssieb joined #minetest-dev |
08:48 |
|
Zeg9 joined #minetest-dev |
09:15 |
|
darkrose joined #minetest-dev |
09:15 |
|
darkrose joined #minetest-dev |
09:19 |
|
proller joined #minetest-dev |
09:34 |
|
iqualfragile joined #minetest-dev |
09:46 |
|
darkrose joined #minetest-dev |
09:46 |
|
darkrose joined #minetest-dev |
09:59 |
|
PilzAdam joined #minetest-dev |
10:18 |
|
darkrose joined #minetest-dev |
10:18 |
|
darkrose joined #minetest-dev |
10:21 |
|
ImQ009 joined #minetest-dev |
10:45 |
|
Calinou joined #minetest-dev |
10:46 |
|
PilzAdam joined #minetest-dev |
10:56 |
|
darkrose joined #minetest-dev |
11:03 |
PilzAdam |
RealBadAngel, for your problem with the new glasslike: I had the same problem when fixing new_style_water |
11:04 |
PilzAdam |
the solution is to treat CONTENT_IGNORE as a node of the same kind |
11:04 |
PilzAdam |
so all glasslike nodes "connect" to CONTENT_IGNORE |
11:04 |
|
Jordach joined #minetest-dev |
11:04 |
|
Jordach joined #minetest-dev |
11:09 |
|
ImQ009 joined #minetest-dev |
11:23 |
|
kahrl joined #minetest-dev |
11:24 |
kahrl |
that may be an improvement but I wouldn't call it a solution |
11:25 |
kahrl |
a solution (although expensive) would be to regenerate the meshes of all connected mapblocks when a block is received |
11:25 |
Calinou |
kahrl is back ö_ö |
11:26 |
|
kaeza1 joined #minetest-dev |
11:26 |
kahrl |
I've been for a while :P |
11:26 |
Calinou |
+1 for regenerating mapblock mesh when there's glasslike nodes at the edge |
11:26 |
PilzAdam |
kahrl, yea, but at least for water that works quite good |
11:27 |
Calinou |
water doesn't suffer from that problem too, why? |
11:27 |
Calinou |
does it regenerate mesh like I said? |
11:28 |
kahrl |
there also used to be edges with the smooth lighting depending on the order of block loading, because of CONTENT_IGNORE. But I haven't seen those in recent versions |
11:30 |
Calinou |
while we're talking at rendering issues, there are two bugs related to nodeboxes and other "transparent" drawtypes: |
11:30 |
Calinou |
- any "transparent" drawtype is drawn 1 light level darker than it should be. as a result of this, I'm forced to use sunlight_propagates for stairs+ nodes (in moreblocks now) so that textures are not darkened |
11:30 |
Calinou |
fix: draw them 1 light level brighter, except if they're in light level 0? |
11:31 |
Calinou |
- plantlike/signlike/nodebox/glasslike/allfaces/allfaces_optional/fencelike nodes should have sunlight_propagates set to true by default |
11:31 |
Calinou |
(airlike too?) |
11:44 |
PilzAdam |
kahrl, c55 has fixed the "shadow edges" in 0.4.2 or so |
11:55 |
celeron55 |
yeah, i added the diagonal neighbors to the mesh generator voxelmanipulator as it turned out it didn't slow it down at all |
12:17 |
|
ImQ009_ joined #minetest-dev |
12:24 |
|
ImQ009 joined #minetest-dev |
13:09 |
|
PilzAdam joined #minetest-dev |
13:19 |
|
ImQ009 joined #minetest-dev |
13:29 |
|
hmmmm joined #minetest-dev |
14:04 |
bookwar1 |
celeron55: I unblocked the domain name. As I understand, now you need to ask your registrar to initiate transfer, then they will ask my registrar and then I should approve |
14:40 |
|
salamanderrake joined #minetest-dev |
14:50 |
|
Jordach joined #minetest-dev |
14:52 |
celeron55 |
bookwar1: replied by e-mail |
15:02 |
|
EduardeCalibal joined #minetest-dev |
15:07 |
|
serengeor joined #minetest-dev |
15:11 |
sfan5 |
is dtime in milliseconds? |
15:12 |
celeron55 |
in minetest almost all times are in seconds; IIRC that isn't any different |
15:12 |
sfan5 |
ok |
15:30 |
|
Calinou joined #minetest-dev |
15:35 |
|
jojoa1997|Tablet joined #minetest-dev |
15:37 |
|
Deivan joined #minetest-dev |
15:44 |
|
bookwar1 joined #minetest-dev |
15:49 |
|
rubenwardy joined #minetest-dev |
15:55 |
RealBadAngel |
hi all |
15:55 |
RealBadAngel |
PilzAdam, thx for tip, but this is rather very nasty hack |
15:56 |
PilzAdam |
yea, it seems like it works only for water |
15:56 |
RealBadAngel |
im pretty sure by now under which certain circumistances this bug occurs |
15:56 |
RealBadAngel |
so hopefully i will be able to find the reason |
16:13 |
|
rubenwardy1 joined #minetest-dev |
16:19 |
|
rubenwardy joined #minetest-dev |
16:20 |
|
dexter0 joined #minetest-dev |
16:20 |
|
rubenwardy2 joined #minetest-dev |
16:24 |
hmmmm |
ah thanks for merging that celeron |
16:28 |
hmmmm |
you also added the 'don't prepend ~!~ Server' thing... personally i wanted there to still be some way to differentiate between server and client messages, like slightly different-colored text |
16:29 |
celeron55 |
i'd think of that more like differentiating what the player writes from other text |
16:30 |
celeron55 |
(that's how irc clients do it; your nick or lines are in different color) |
16:30 |
Exio |
hmmmm: by default the messages will still have -!- server |
16:30 |
PilzAdam |
can we change "PM from player:" to ">player<"? |
16:31 |
RealBadAngel |
use bold to highlight broadcaster |
16:31 |
hmmmm |
can't without making a bold font |
16:31 |
Jordach |
cant we just colour it yellow |
16:31 |
celeron55 |
i'd say just don't touch it anymore |
16:31 |
celeron55 |
it's good enough |
16:31 |
celeron55 |
:P |
16:32 |
hmmmm |
how about this https://github.com/minetest/minetest/pull/670 |
16:32 |
RealBadAngel |
so use irc way then |
16:32 |
RealBadAngel |
server: blah blah |
16:32 |
RealBadAngel |
player: Hello |
16:32 |
celeron55 |
the mods are responsible for differentiating themselves somehow if they disable the regular server notice text |
16:33 |
celeron55 |
and i belive they will do so because otherwise anyone will see it doesn't make any sense |
16:34 |
celeron55 |
hmmmm: how is that not a problem on ARM? |
16:34 |
Jordach |
lemme just compile this on arm |
16:34 |
hmmmm |
ARM is usually run in little endian mode |
16:34 |
celeron55 |
(i think minetest has been succesfully built on android, albeit doesn't actually work) |
16:34 |
Jordach |
celeron55, correct |
16:34 |
Jordach |
Irrlicht just wont :P |
16:34 |
RealBadAngel |
again on the problem with getNodeNoEx |
16:35 |
RealBadAngel |
celeron55, have you read what i wrote today in the morning about it? |
16:36 |
PilzAdam |
hmmmm, why do we need snow and dirt_with_snow? |
16:36 |
hmmmm |
because that's what's needed for a snow biome..? |
16:36 |
hmmmm |
isn't it? |
16:36 |
PilzAdam |
i think dirt_with_snow isnt needed |
16:36 |
PilzAdam |
just add a snow layer on top of it |
16:36 |
Jordach |
yeah, we have a hot place, but no cold place |
16:37 |
RealBadAngel |
should be added with flag? |
16:37 |
hmmmm |
but how will people build on the ground with that |
16:37 |
Jordach |
PilzAdam, you do realise the grass side needs re-texturing right |
16:37 |
Jordach |
hmmmm, buildable_to |
16:37 |
hmmmm |
oh okay |
16:37 |
Jordach |
snow acts like water or a liquid |
16:37 |
hmmmm |
sounds good then |
16:37 |
RealBadAngel |
flag snow=1 then dispaly it with snow texture added |
16:37 |
PilzAdam |
Jordach, all other nodes need side retexturing too if snow is on them |
16:38 |
RealBadAngel |
same way as ores are added to stone |
16:39 |
RealBadAngel |
ofc snow will require top, and side textures, top will be replacement, side mixed with original side one |
16:40 |
celeron55 |
PilzAdam: because dirt_with_snow looks good |
16:41 |
PilzAdam |
yea, dirt_with_gras with snow over it doesnt look good |
16:41 |
Jordach |
i agree with celeron55 |
16:41 |
celeron55 |
i agree that there could be a better way, but i also think many other ways will be just hackier |
16:41 |
Jordach |
anyways, MC has dirt_with_snow |
16:41 |
Jordach |
so why are we complaining |
16:42 |
celeron55 |
Jordach: because we can sometimes do better |
16:42 |
Calinou |
MC doesn't |
16:42 |
Jordach |
celeron55, we did beat them to modding :P |
16:42 |
hmmmm |
hmmmm |
16:42 |
RealBadAngel |
celeron55, long story short: consider 2 blocks next to each other. check at pos from node placed in direction x+ to node in block in direction x-, will always see correct content |
16:42 |
Calinou |
grass blocks look like they have snow on their sides when there is a snow cover above |
16:42 |
celeron55 |
we'd need some kind of a group -> grass re-texture definition table |
16:42 |
Calinou |
and there are (stackable!) snow covers |
16:42 |
celeron55 |
and then make the client apply a different grass based on it |
16:42 |
celeron55 |
but it's kind of arbitrary |
16:42 |
hmmmm |
if we can semi-fix the transparency sorting problem and add a colored drawtype, biomes would be in good shape |
16:43 |
RealBadAngel |
when you do the very same in differen direction x- to x+, it WILL ALWAYS give you content ignore |
16:43 |
celeron55 |
RealBadAngel: just fix it, i don't want to think of that |
16:43 |
hmmmm |
we are getting snow and all these neat blocks |
16:43 |
hmmmm |
it's all coming together |
16:43 |
Jordach |
hmmmm, were looking more polished |
16:44 |
RealBadAngel |
celeron55, i will try |
16:44 |
RealBadAngel |
i really dont like solution PA suggested to treat ignore as same node we would want to have there |
16:45 |
hmmmm |
one question though |
16:45 |
hmmmm |
is there a way to pass my color-to-blend to the shaders? |
16:45 |
RealBadAngel |
propably it will work in this very case, but who knows what it could break |
16:46 |
hmmmm |
I figure since i'm mucking around with shaders anyway, it'd probably be a good time to add the color drawtype in too |
16:46 |
celeron55 |
hmmmm: that's a complicated subject |
16:47 |
hmmmm |
well as it stands, if i can't pass my color along to the shader, then this feature just won't happen |
16:47 |
celeron55 |
currently two light values (IIRC) are passed as the vertex color components R and G, to be mixed by the shaders according to a global which contains the current day cycle brightness |
16:48 |
hmmmm |
according to a global |
16:48 |
hmmmm |
hmm |
16:48 |
celeron55 |
so there is B left in that |
16:48 |
Exio |
can't you pass that as a "variable"? |
16:48 |
Exio |
(to the shader, i mean) |
16:48 |
celeron55 |
(A is obviously used for actual alpha) |
16:48 |
celeron55 |
well shaders are kind of limited in where they can get data |
16:49 |
hmmmm |
it's probably not going to work out if i make a constant called "blend color" that i change every time i'm shading a pixel from a different node |
16:49 |
Calinou |
color... drawtype? shouldn't it be a paramtype? |
16:49 |
celeron55 |
also i am quite unknowledgeable about shaders, and don't know much about actual modern graphics programming |
16:49 |
hmmmm |
paramtype, yeah, whatever |
16:49 |
hmmmm |
i don't know anything about graphics programming |
16:50 |
celeron55 |
i think there must be some way to associate more data per vertex, but that is going to get complicated in some way that i don't have any idea of |
16:50 |
hmmmm |
a game is pretty foreign to me... but that's fine because i can pick up on things quickly enough |
16:50 |
hmmmm |
people are probably going to hate me for asking this, but.... |
16:50 |
celeron55 |
i suggest just implementing the oldskool implementation first (probably with texture modifications); a shader implementation can be figured out later |
16:50 |
hmmmm |
.....how does minecraft do it? |
16:51 |
hmmmm |
lol |
16:51 |
hmmmm |
this wouldn't be a problem if we had lighting |
16:52 |
celeron55 |
(even with shaders being used, any oldskool stuff can be in use, so that's the right way to do it anyway) |
16:52 |
hmmmm |
oh my god. if we can just get lighting, all of our problems would disappear |
16:52 |
sfan5 |
celeron55: you should be able to pass any integer/floating point number to the shader |
16:52 |
hmmmm |
mauvebic's whining included |
16:52 |
celeron55 |
sfan5: yes one global, but one per vertex is a different story |
16:53 |
celeron55 |
there of course *are* ways to do it |
16:53 |
celeron55 |
because obviously the complex grass and whatever rendering systems use that much data |
16:53 |
celeron55 |
modern ones i mean |
16:53 |
* sfan5 |
guesses there complicated |
16:53 |
hmmmm |
erm |
16:53 |
celeron55 |
but i have no idea how they do it |
16:53 |
sfan5 |
*they are |
16:53 |
celeron55 |
somebody needs to read up on this |
16:53 |
hmmmm |
kahrl did the current shaders, right? |
16:53 |
sfan5 |
yes |
16:53 |
hmmmm |
i wonder if he'd be willing to help here |
16:53 |
celeron55 |
i implemented the current shaders |
16:53 |
hmmmm |
oh |
16:53 |
Calinou |
hmmmm: minecraft uses no shaders at all |
16:53 |
celeron55 |
kahrl implemented much of the framework |
16:53 |
Calinou |
minecraft do what, too? |
16:54 |
* Calinou |
knows quite a lot about MC, as a regular player and *cough |
16:54 |
Calinou |
MCP user*cough* |
16:54 |
Calinou |
(fail enter key) |
16:54 |
hmmmm |
well we're figuring out how to colorize individual nodes |
16:54 |
hmmmm |
at draw time |
16:55 |
hmmmm |
that way we can 1). reduce definitions of all the same node with the only difference being color, and 2). have grass/water/etc. colored differently in different biomes |
16:55 |
hmmmm |
and this isn't working with shaders |
16:56 |
hmmmm |
(just as a recap to anybody lost in the conversation) |
16:56 |
celeron55 |
apparently one can bind arrays of miscellaneous structures of data to opengl to be used per-vertex: http://stackoverflow.com/questions/15102593/how-to-pass-per-vertex-attributes-to-glsl-shader |
16:56 |
hmmmm |
neato |
16:56 |
celeron55 |
dunno how new shader support that requires (might be newer than we want to support) and might be confusing to implement in irrlicht |
16:57 |
celeron55 |
that's to be found out by somebody |
16:57 |
celeron55 |
(miscellaneous structures = structures containing a miscellaneous amount of named floats :P) |
16:58 |
celeron55 |
if that isn't possible, then i am guessing at least passing a second array of colors (one per vertex) will be possible with a version-to-be-supported) |
16:58 |
celeron55 |
-) |
16:59 |
PilzAdam |
I have added a function to snow that turns grass under it to dirt_with_snow when placed; now I need to change the ABM that grows grass |
17:00 |
PilzAdam |
should it just grow dirt_with_snow if snow is on top of it? |
17:00 |
hmmmm |
yeah |
17:00 |
hmmmm |
that's good |
17:01 |
RealBadAngel |
funny fact: last sunday came into my room 2 little girls, daughter of my sister, and her friend. both aged 5-6yrs |
17:01 |
hmmmm |
why is that funny |
17:01 |
RealBadAngel |
saw me workin on mt, i was just codin and testing |
17:02 |
RealBadAngel |
and those girls said: oh! youre playin minecraft |
17:02 |
RealBadAngel |
we do play too! |
17:02 |
hmmmm |
hah wow. they know what minecraft is? |
17:03 |
sfan5 |
"best comment award goes to hmmmm" |
17:03 |
RealBadAngel |
yeah, and they started to explain me what they build in there |
17:03 |
RealBadAngel |
5 yrs old kids |
17:03 |
celeron55 |
humm... this is going to get ugly |
17:05 |
celeron55 |
quickly looking, it seems irrlicht doesn't have built-in support for such modern shader stuff (as it hasn't been designed for flexible shaders in the first place) |
17:06 |
celeron55 |
but irrlicht has some more complicated vertex data formats (= contains some more data fields) that can be used |
17:07 |
PilzAdam |
should dirt_with_snow turn into something else if the snow above it is dug? |
17:07 |
celeron55 |
http://irrlicht.sourceforge.net/forum/viewtopic.php?f=4&t=27802 |
17:07 |
PilzAdam |
and I also gonna add a snowblock, crafted with 9 snow |
17:09 |
celeron55 |
(eg. this http://irrlicht.sourceforge.net/docu/structirr_1_1video_1_1_s3_d_vertex_tangents.html) |
17:09 |
hmmmm |
that's not horrible though |
17:09 |
celeron55 |
by the way, i hate that new doxygen page format of irrlicht |
17:09 |
celeron55 |
the old one was like 10x better |
17:10 |
RealBadAngel |
about lights: http://www.youtube.com/watch?v=Y7AR7oxLR_4 |
17:10 |
celeron55 |
those frames are like back to 90s |
17:10 |
hmmmm |
we'll just use a S3DVertex2TCoords |
17:11 |
celeron55 |
well, ugly is not always horrible 8) |
17:11 |
hmmmm |
it's the best we can do given the restrictions imposed upon us by irrlicht |
17:11 |
Calinou |
hmmmm: minecraft never colorizes individual nodes, wool just uses 16 textures like we do |
17:11 |
Calinou |
in 1.9pre2 part of the cauldron texture was colorized |
17:12 |
Calinou |
and potions are still colorized dynamically, but that's an item |
17:12 |
hmmmm |
well |
17:12 |
hmmmm |
this has lots of applications |
17:12 |
hmmmm |
not just potions and whatever |
17:13 |
hmmmm |
potions have to be colorized dynamically though because they're animated |
17:13 |
Calinou |
some minecraft packs animate potion textures, too |
17:14 |
Calinou |
talking about animation: it'd be nice if instead of definiting in lua code, we used text files, client-side |
17:14 |
celeron55 |
hmmmm: you do understand that there absolutely needs to be a non-shader implementation of the coloring of whatever too? |
17:14 |
Calinou |
eg. default_stone.png, default_stone.txt, it contains the total time of animation |
17:14 |
hmmmm |
obviously |
17:14 |
Calinou |
(in seconds) |
17:14 |
hmmmm |
and that's much simpler as well |
17:14 |
celeron55 |
good |
17:14 |
Calinou |
why can't we use a shader-less implementation regardless of whether shaders are enabled or not? is it faster? |
17:14 |
Calinou |
would be simpler |
17:14 |
hmmmm |
it's just that i gave to give special attention to the shader case because it's the main complicating factor |
17:14 |
celeron55 |
a shader one will be useful for those using super-high-resolution textures though, as otherwise it's going to take enormous amounts of texture space 8) |
17:15 |
hmmmm |
s/gave/have/ |
17:15 |
|
ssieb joined #minetest-dev |
17:16 |
hmmmm |
erm this is probably a stupid question |
17:16 |
hmmmm |
but how do i do translucency with shaders? |
17:17 |
hmmmm |
gl_Color.a always seems to be 1.0 |
17:19 |
hmmmm |
erm nevermind, that's just the shader failing to generate... |
17:23 |
hmmmm |
:D |
17:24 |
hmmmm |
suck it, transparency sorting problem! http://ompldr.org/vaTc3OA |
17:24 |
PilzAdam |
hmmmm, change the red texture aplha to 0 |
17:25 |
PilzAdam |
can you see to the ground of the sea then? |
17:25 |
hmmmm |
probably |
17:25 |
hmmmm |
that's hardly a problem though |
17:26 |
PilzAdam |
is the alpha set in the texture file or in the alpha field in nodedef? |
17:26 |
hmmmm |
texture file |
17:26 |
hmmmm |
well, obviously, you won't be able to replace regular glass with this |
17:31 |
hmmmm |
nor should you |
17:31 |
hmmmm |
(for obvious performance reasons) |
17:37 |
celeron55 |
there is 100% surely going to be a mod for those who wish to kill their performance with making all grass and all leaves and all everything translucent 8) |
17:37 |
celeron55 |
grass? ehm, i mean glass |
17:38 |
celeron55 |
also, actually it doesn't even affect performance |
17:39 |
hmmmm |
maybe if you're using shaders it won't |
17:39 |
hmmmm |
but EMT_TRANSPARENT_ALPHA_CHANNEL is definitely slower than EMT_TRANSPARENT_ALPHA_CHANNEL_REF |
17:45 |
celeron55 |
yes, on old hardware, definitely |
17:45 |
Calinou |
on today's hardware texture size doesn't even matter |
17:45 |
Calinou |
just use the thing that looks best |
17:46 |
celeron55 |
it matters because of memory consumption |
17:46 |
Calinou |
today's graphics cards have 1GB of VRAM in the low end range, 2GB in the mid end |
17:46 |
celeron55 |
also mesh sizes matter mostly because of memory consumption |
17:46 |
Calinou |
good luck filling that, even with 4× AA on 2560×1440 |
17:46 |
hmmmm |
we are not optimizing for high-end systems, that's against the minetest philosophy |
17:47 |
hmmmm |
frankly i don't care about "hardware these days" |
17:47 |
celeron55 |
how about one thousand pieces of VanessaE's 512x512px textures? 8) |
17:47 |
celeron55 |
that's 1GB |
17:47 |
Calinou |
512× is pointless, 256× is enough, by far :P |
17:47 |
hmmmm |
i don't really like that i have such a powerful processor on this computer for testing minetest... but compiling is great (: |
17:47 |
celeron55 |
hmmmm: in linux there is a way to select how many cores to use for a process 8) |
17:48 |
hmmmm |
everything ought to be near-instantaneous on any processor from 2005 |
17:48 |
celeron55 |
setting that to one for MT makes a good difference |
17:48 |
hmmmm |
still won't simulate an athlon 64 3500+ very well |
17:48 |
celeron55 |
not really, today's cores are a couple of times faster |
17:49 |
celeron55 |
>near-instantaneous on any processor from 2005 |
17:49 |
celeron55 |
any web application these days lags like hell eating 100% CPU on those |
17:49 |
Calinou |
architecture is very important, much more important than amount of cores :P |
17:49 |
celeron55 |
they just rely on the processing power :P |
17:49 |
Calinou |
today's quad core intels beat eg. a 990X (some 6 core from intel) |
17:50 |
celeron55 |
well, a pentium 4 is like a low-end atom these days |
17:50 |
celeron55 |
that's how it goes |
17:50 |
celeron55 |
(a nice 10x difference in power consumption) |
17:51 |
celeron55 |
(well, more like 5x) |
17:51 |
celeron55 |
actually... more like 20x |
17:53 |
hmmmm |
did anybody notice that people do stupid things like "hey imma run a minetest server on my 600mhz laptop" |
17:53 |
hmmmm |
they figure minetest shouldn't be intensive at all |
17:53 |
hmmmm |
can anybody say with honesty that minetest deserves to be as intensive as it is? |
17:53 |
hmmmm |
maybe they are justified |
18:07 |
|
sapier joined #minetest-dev |
18:08 |
celeron55 |
a minetest server will run on a 600MHz laptop |
18:08 |
celeron55 |
as long as it has RAM in the range of 100MB |
18:08 |
celeron55 |
i broke a HDD of one of mine by running an MT server on it 8) |
18:09 |
celeron55 |
poor old thing |
18:09 |
sapier |
but if you want to use mods even 1.8ghz won't be enough for server |
18:09 |
sapier |
at leastwhile magen is running |
18:10 |
celeron55 |
well yeah, all of my servers have always been quite vanilla |
18:11 |
sapier |
yes vanilla is quite fast ... swamp mod is horrific and snow mod not that much better |
18:11 |
PilzAdam |
we have snow now in vanilla :-) |
18:12 |
sapier |
snow biomes? |
18:12 |
PilzAdam |
no |
18:12 |
PilzAdam |
snow nodes |
18:12 |
sapier |
hmm maybe I had both :-) |
18:13 |
sapier |
does vanilla create sea ice? |
18:13 |
PilzAdam |
the snow and ice nodes arent generated yet |
18:14 |
sapier |
did anyone look at the scriptapi subfolder changeset yet? |
18:14 |
PilzAdam |
yes, its broken |
18:14 |
sapier |
a little bit more details plz ;-) |
18:15 |
PilzAdam |
https://travis-ci.org/minetest/minetest/jobs/6547231 |
18:17 |
sapier |
what the hell? |
18:18 |
sapier |
wonder why gcc 4.7 doesn't have any problems with this |
18:22 |
celeron55 |
the standard does say that class should always be "friend class X", functions are "friend <function declaration>" |
18:23 |
sapier |
gcc 4.7 doesn't even think this is worth a warning |
18:25 |
celeron55 |
actually no, it doesn't say so |
18:25 |
celeron55 |
but |
18:25 |
celeron55 |
ah, here's the key |
18:26 |
celeron55 |
there doesn't need to be "class" if the class is in scope |
18:26 |
celeron55 |
is this related to your case? |
18:26 |
celeron55 |
hmm, it seems you do have declarations for them |
18:27 |
sapier |
hmm class is forward declared not quite sure if this counts as "in scope" ... I've added the class already hopefully this is only 4.6 4.7 incompatibility |
18:27 |
celeron55 |
it does count |
18:28 |
celeron55 |
(as per C++98) |
18:28 |
sapier |
maybe this is a gcc 4.6 bug ... would explain why 4.7 doesn't even issue a warning |
18:28 |
celeron55 |
anyhow, we support 4.6 so just fix it 8) |
18:28 |
sapier |
already done ;-) |
18:31 |
sapier |
does travis build start automaticaly? |
18:32 |
celeron55 |
yes |
18:32 |
sapier |
btw celeron you've been right problem with entity duplication is not exactly beeing saved in different block |
18:33 |
sapier |
seems problem was a entity was not staticized while still beeing in use by a client but left active ... noone ever deactivated it |
18:36 |
celeron55 |
i'm not sure about the correctness of your patch |
18:37 |
sapier |
I've been thinking about it too but the more I think about it the more I do think it's correct |
18:38 |
celeron55 |
IIRC it's intended to continue storing the object as a counterpart of an active object (=having static id) until all clients have been informed it, and when it has happened, then it should finally store it as static-only (id=0) |
18:38 |
sapier |
problem is that there is no static data within this block once it's deactivated |
18:38 |
celeron55 |
the active part is kept in the pending state until all clients know it will be removed |
18:38 |
sapier |
while the entity still is active |
18:39 |
sapier |
but a remove message is sent to client |
18:39 |
sapier |
if this block is activated again there is not static object to be activated --> client doesn't get informed this object needs to be added |
18:39 |
celeron55 |
i would guess you have tested it enough to see that it does work though |
18:40 |
sapier |
I've only tested singleplayer |
18:40 |
sapier |
so if there are race conditions with multiple clients I wouldn't have run into it |
18:40 |
celeron55 |
well then, if somebody cares to do some testing with some mob mod in multiplayer, that would be highly valued |
18:41 |
celeron55 |
also, the dungeon game of mine always spewed some static object errors |
18:41 |
celeron55 |
that would be a good test too |
18:42 |
sapier |
testing first part of bug is really simple |
18:42 |
sapier |
add a cart somewhere run away until this cart is unloaded |
18:42 |
sapier |
then run back |
18:42 |
sapier |
in current version you'll never get the cart back on client until you log out |
18:43 |
celeron55 |
i think you actually do sometimes; i was testing that once and it behaved really oddly |
18:43 |
sapier |
I tried yesterday I didn't have a single situation where I got it back ... |
18:44 |
sapier |
of course that doesn't tell it never happens |
18:48 |
kahrl |
yeah, I remember seeing mixed results when I tried the same |
18:48 |
kahrl |
(with item objects instead of carts) |
18:49 |
sapier |
as far as I understand that shouldn't be any difference |
18:49 |
ssieb |
any idea what would cause this: 20:27:38: ERROR[ServerThread]: ServerEnv: Trying to store id=3 statically but block (-2,1,3) already contains 49 (over 49) objects. Forcing delete. |
18:49 |
ssieb |
I investigated this once and the location was in a solid area of stone... |
18:50 |
sapier |
it's exactly what is written in the message |
18:50 |
sapier |
too many objects at one place |
18:50 |
kahrl |
object duplication, probably |
18:51 |
ssieb |
but nobody had been there and there was nothing there |
18:51 |
ssieb |
I teleported into that spot and dug out the stone and there was nothing... |
18:52 |
kahrl |
did you dig out the entire 16x16x16 mapblock? |
18:52 |
ssieb |
oh! |
18:52 |
ssieb |
am I confusing the terms? |
18:52 |
kahrl |
block (-2,1,3) is at coordinates (-32,16,48) |
18:53 |
ssieb |
ok, now that's makes a lot more sense |
18:53 |
ssieb |
there's a limit per mapblock of how many loose items can be around? |
18:54 |
kahrl |
yeah, it was added in the 0.3 days when there was a rat plague on the gameboom server |
18:54 |
ssieb |
I'll tell the kids that they really need to clean up there mess then. ;-) |
18:54 |
sapier |
maybe we should disable this limit, in 0.3 ther haven't been item entities mob entities ... |
18:55 |
ssieb |
s/there/their/ :-/ |
18:55 |
sapier |
now if your inventory is full all nodes are dropped as entities so limit is reached very soon |
18:55 |
ssieb |
yes |
18:55 |
ssieb |
and TNT! |
19:11 |
|
rubenwardy joined #minetest-dev |
19:13 |
celeron55 |
kahrl: no |
19:13 |
celeron55 |
it was added when my server got riddled with dungeon master duplication |
19:14 |
celeron55 |
or misspawning |
19:14 |
celeron55 |
it's been there waiting for a time when we are confident with object handling actually doing it's job reasonably |
19:15 |
sapier |
hmm so if my patches already cought all bugs this could be disabled completely? |
19:15 |
celeron55 |
there should probably always be some limit, but maybe we can raise it a factor of some after testing sapier's fix |
19:15 |
sapier |
i don't wanna tell I already fixed everything |
19:15 |
celeron55 |
no, it should never be disabled completely |
19:15 |
sapier |
of course some limit is reasonable |
19:16 |
celeron55 |
i don't want anyone to have a broken world because of a broken mod or something |
19:16 |
celeron55 |
the limit should be in the hundreds |
19:16 |
celeron55 |
once there are no bugs |
19:16 |
sapier |
mods always can break a world |
19:16 |
celeron55 |
yes but it's too easy to break a world by flood-spawning entities |
19:17 |
sapier |
it's even more easy by using an abm to replace nodes ... but I got what you want to tell |
19:17 |
celeron55 |
it should cap at something that most computers will still handle |
19:17 |
celeron55 |
sapier: that's hard to get accidentally wrong |
19:18 |
sapier |
one typo in replacement node ;-) |
19:19 |
sapier |
but back to entity problem once those bugs are fixed player experience with mobs way better than now |
19:19 |
sapier |
I've been playing only 3 days now in order to release new mobf version and got duplicated mobs to an extent it wasn't fun anymore |
19:20 |
|
StrayBytes joined #minetest-dev |
19:20 |
|
StrayBytes joined #minetest-dev |
19:21 |
|
proller joined #minetest-dev |
19:25 |
|
iqualfragile joined #minetest-dev |
19:27 |
|
StrayBytes joined #minetest-dev |
19:31 |
|
proller joined #minetest-dev |
19:31 |
|
rubenwardy left #minetest-dev |
19:52 |
celeron55 |
okay so i play minetest a bit after like a month |
19:52 |
celeron55 |
and i think that this end-of-fall camera jiggling is ridiculous |
19:52 |
celeron55 |
this is the most ridiculous thing i have seen |
19:52 |
celeron55 |
what the fuck man |
19:53 |
celeron55 |
1) it isn't even close to being anywhere properly synced with any momentum, 2) it would be stupid anyway |
19:53 |
StrayBytes |
It does get really annoying. |
19:53 |
iqualfragile |
PilzAdam wasnt too hapy about that either |
19:53 |
celeron55 |
who even agreed in putting this in |
19:54 |
|
Randy_ joined #minetest-dev |
19:54 |
celeron55 |
i'm going to just revert this unless somebody gives any reasonable explanation for this in an hour |
19:54 |
Randy_ |
Hey PilzAdam Can you add farming as a default? and maybe some animals/mobs? in the next Dev.? |
19:55 |
PilzAdam |
ehm |
19:55 |
iqualfragile |
Randy_: animals and mobs are not yet stable/performant enought |
19:56 |
Randy_ |
For like 0.4.7 MineTest maybe then just Farming |
19:56 |
PilzAdam |
its Minetest, not MineTest |
19:57 |
Randy_ |
Same difference. tomato,tamoto |
19:57 |
Jordach |
celeron55, ask Taoki |
19:57 |
Jordach |
he put it in |
19:57 |
sapier |
I'd like to expose collision handling support to lua in order to make mobs more performant what do you think about this idea? |
19:57 |
Taoki |
celeron55: It's just an effect for realism, and it's very welcome |
19:57 |
Jordach |
bull, |
19:57 |
iqualfragile |
Randy_: in minecraft mojang makes the game, in minetest the server admin does, so just add it to your local installation |
19:57 |
celeron55 |
lol what |
19:57 |
Taoki |
Why does every good feature have to be considered wrong in this project |
19:57 |
Jordach |
i dont mind it: but it does annoy me slightly |
19:58 |
Taoki |
Seriously? A simple camera jiggling when you fall is that stupid? |
19:58 |
sapier |
e.g. once collision is detected call to lua telling which entity collided |
19:58 |
celeron55 |
it's like the player deliberately gently curtseyed after each landing |
19:58 |
Taoki |
Maybe we should indeed fork this project if that's what the current admins think... |
19:58 |
Taoki |
Who don't want any parts of it to evolve |
19:58 |
celeron55 |
it's plain stupid :D i don't even have anything else to say about it |
19:58 |
Jordach |
realistically, its correct |
19:58 |
Jordach |
but as this is not IRL, there is no need for it |
19:59 |
celeron55 |
it's utterly wrong, it should not work even close to this if it wanted to act like in real life |
19:59 |
Taoki |
celeron55: A shocking amount of games (both open and closed source) have such "plain stupid" effects. I guess Minetest needs to be kept at stupidly simplistic level however |
19:59 |
Taoki |
Really? Like, every project I saw so far has something like this |
19:59 |
Taoki |
FPS or anything else |
19:59 |
Jordach |
Taoki, red eclipse does not |
19:59 |
ShadowNinja |
Taoki: I like it but falling off even one node activates it, I think it should take a little more |
19:59 |
Taoki |
You're the first I see who finds this plain stupid |
20:00 |
celeron55 |
where's the code to make this disabled by default and enabled by a configuration setting that nobody can find |
20:00 |
Jordach |
Taoki, if the force was like falling from 8+ nodes, then yes |
20:00 |
Jordach |
it would be nice |
20:00 |
Taoki |
But I'm more and more starting to support the idea of a fork. Since the current administration doesn't seem to want anything to evolve properly |
20:00 |
iqualfragile |
Taoki: just go and help minetest black |
20:00 |
Taoki |
Everything is seen as stupid |
20:00 |
celeron55 |
>Everything is seen as stupid |
20:00 |
iqualfragile |
its basicly minecraft build via minetest |
20:00 |
celeron55 |
>everything |
20:00 |
Jordach |
because it doesnt fit currently. |
20:00 |
celeron55 |
>EVERYTHING |
20:00 |
celeron55 |
:D |
20:00 |
celeron55 |
LOOK AT THE WORD |
20:01 |
Jordach |
were going into chit chat territory |
20:01 |
Taoki |
celeron55: Also, I wanted to add a setting for it. PilzAdam didn't agree. Blame him that it's enabled only in the code and there's no setting |
20:01 |
Taoki |
If you need to blame someone |
20:01 |
Jordach |
blame yourself. |
20:01 |
Taoki |
celeron55: Unfortunately, that is the vision of the current administration. And things such as "who needs / cares about the user base" |
20:01 |
celeron55 |
Taoki: EVERYTHING is seen as stupid! |
20:01 |
iqualfragile |
Taoki: s/administration/bunch of random blockheads/g |
20:01 |
celeron55 |
i |
20:01 |
celeron55 |
lol |
20:02 |
celeron55 |
where's all sense from any of this |
20:02 |
Taoki |
iqualfragile: I simply don't understand why anyone would be so pissed about a mininal camera fall effect, which is sane in any game to keep falling when jumping from looking horrible and fake |
20:02 |
celeron55 |
everything! |
20:02 |
celeron55 |
everything is stupid! |
20:02 |
Taoki |
celeron55: Anyway, if you must remove it, please add a setting and turn it off by default. Other people like me (stupid ones) would like to be able to enable it, even if manually |
20:03 |
celeron55 |
i mean, have you ever even glanced at the commit log? |
20:03 |
celeron55 |
or pull requests |
20:03 |
iqualfragile |
Taoki: im sorry, i misstook you for Randy |
20:03 |
sapier |
:-) I think EVERYONE got the point ;-P |
20:03 |
Jordach |
celeron55, if youre going to be acting crazy, go to minetest |
20:03 |
Taoki |
Ah, ok. No I don't use that name |
20:03 |
Jordach |
we dont need your kind here! |
20:04 |
Taoki |
Jordach: He is the main developer and I appreciate what he did. But I don't agree with how he admins all the time myself... maybe its just me. Then again this isn't my project / fork and that's the most I can say / complain about. |
20:04 |
Randy_ |
Oh and i can't log on the forum it says im a bot? |
20:04 |
sapier |
currently most ppl do only add new features bugs are tracked down by very few ppl ... taoki when did you look for an anoying bug last time? |
20:04 |
|
jin_xi joined #minetest-dev |
20:04 |
Taoki |
sapier: I'm all for bug fixing, but it doesn't mean new features aren't good too |
20:04 |
PilzAdam |
Randy_, thats offtopic |
20:05 |
sapier |
no but new features do mean NEW bugs ... this fixing the old ones will get more and more complicated |
20:05 |
celeron55 |
so here's a poll: will i either disable this by default or simply revert it |
20:05 |
|
iqualfragile joined #minetest-dev |
20:05 |
Taoki |
celeron55: Can you add a setting and disable it instead of removing it, so we can still use it optionally? Maybe let it adjust the intensity as well, like view bobbing works |
20:06 |
Taoki |
I wanted to do it like that, but PilzAdam said it won't go in if I add a setting for something so baisc. Not to blame anyone, just how things happen. So you might want to ask him if it's ok to just add a setting |
20:06 |
Taoki |
**happened |
20:07 |
celeron55 |
do you understand that i am not blaming anyone, i am blaming this stupid thing |
20:07 |
PilzAdam |
if its enabled by default, then a setting is useless |
20:07 |
Taoki |
Other than that, I'm starting to wonder if my vision (of maybe a more modern and advanced Minetest) isn't really in match with the artistic style of Minetest. Would be good to know just to be sure |
20:07 |
PilzAdam |
but if its disabled by default, then go ahead and add the setting |
20:07 |
PilzAdam |
I would be fine with removing also |
20:07 |
celeron55 |
Taoki: that may be very true |
20:07 |
celeron55 |
Taoki: but that's more of you to decide, because i have never seen your full vision |
20:07 |
Taoki |
celeron55: It's a small new feature that got added. I don't see why it's so stupid and evil and horrible. It's ok if people don't like it otherwise... which is why I suggested a setting |
20:08 |
sapier |
PilzAdam I don't understand your logics if anything default doesn't need a setting why add any setting? |
20:08 |
PilzAdam |
sapier, because noone would enable it |
20:08 |
sapier |
using this logics security is to be added for everyone or noone too ... |
20:08 |
Taoki |
celeron55: Don't really have a full vision. Just that I'm hoping Minetest can get to be a very modern engine (even if using blocks for terrain, etc). Modern visual effects, camera effects, hardware lighting, etc. Much of what I'm doing is to lead to that. |
20:09 |
hmmmm |
[04:01 PM] <Taoki> celeron55: Also, I wanted to add a setting for it. PilzAdam didn't agree. Blame him that it's enabled only in the code and there's no setting |
20:09 |
hmmmm |
a setting |
20:09 |
hmmmm |
a setting isn't magically going to reverse the damage that you've done to the infrastructure to support fake colored lights |
20:09 |
celeron55 |
what |
20:10 |
|
proller joined #minetest-dev |
20:10 |
celeron55 |
now there is absolutely no sense in here |
20:10 |
Taoki |
hmmmm: Firstly, I haven't done anything... just supported the idea of the feature being done. Second, I understand your point on this... like I said I think colored lights would be worth the extra info in mapgen but that's just me |
20:10 |
PilzAdam |
why are you changing the topic? |
20:10 |
hmmmm |
oh |
20:11 |
celeron55 |
i don't understand anything anymore, i'll just make this and go to sleep i guess |
20:11 |
hmmmm |
sorry, i thought that's what he was on about |
20:11 |
hmmmm |
i didn't realize the topic was something less controversial like the fall bobbing |
20:11 |
hmmmm |
no, it's not just "extra info in the mapgen" |
20:11 |
Taoki |
celeron55: If you wish, make a setting instead of removing. It's your choice though... I'd prefer that though. |
20:11 |
hmmmm |
it's "doubling the size of everything in minetest" |
20:11 |
Taoki |
hmmmm: Ah no, it's a about a camera effect I added for falling |
20:12 |
hmmmm |
i personally don't have any problems with that. |
20:12 |
hmmmm |
a setting is always nice though |
20:13 |
hmmmm |
[03:53 PM] <celeron55> who even agreed in putting this in i agreed to putting it in because it didn't seem very harmful for one, and for two, everybody was talking about it as if they didn't have any problems either |
20:14 |
sapier |
maybe noone tested it? |
20:15 |
* Taoki |
is a bit upsed because I don't understand why a minor feature like that could be so hated for no reason. That and I'm still unclear about other things in vision of the dev team... especially after the who needs / cares about a community mentality I heard here. Or the everything is stupid line c55 mentioned |
20:15 |
Taoki |
**upset |
20:15 |
hmmmm |
there's that word "everything" again |
20:15 |
hmmmm |
i don't think you people know what it means |
20:15 |
sapier |
I haven't tested it by now so I can't really tell |
20:16 |
Taoki |
Minetest is a great project. But sadly, I no longer feel the positive direction behind it. Maybe it's just me though. |
20:18 |
hmmmm |
it really is just you |
20:18 |
Taoki |
if you say so |
20:18 |
hmmmm |
you and mauvebic in particular try to paint the portrait of the dev team being negative and unreceptive to outside ideas |
20:18 |
PilzAdam |
Taoki, c55 just quoted you with the "everything is stupid" |
20:18 |
Taoki |
PilzAdam: Ok, misunderstood then |
20:19 |
hmmmm |
because we're not allowing a feature to be implemented in the naive way |
20:19 |
Taoki |
hmmmm: Maybe it's a bit of how I feel... I don't have a purpose of painting such a thing |
20:19 |
hmmmm |
and because someone else has a personal preference to not have fall bobbing enabled |
20:19 |
hmmmm |
fucking a |
20:19 |
hmmmm |
it certainly is ant season now |
20:20 |
Taoki |
The personal preference is ok >_> Was a bit surprised the feature got so hated all of a suggen, when it was just a small part of me trying to optimize and modernize several things on my list |
20:20 |
jin_xi |
such things should be configurable. no need to speculate if users will turn it on if someone already made the feature |
20:20 |
Taoki |
I have other reasons of my own to be upset too... but those aren't relevant here |
20:20 |
hmmmm |
hold on i need to take care of this |
20:21 |
celeron55 |
done |
20:22 |
kahrl |
I don't mind the fall bobbing, but I agree with Jordach, the effect for 1-2 node falls and simple jumps is way too much |
20:24 |
Taoki |
Anyway, I don't really plan to upset part of the team as much in the future with features they consider stupid. As ffar as the engine is concerned, I'm most interested in dynamic lighting now. Then effects like reflections, gloss, bloom, parallax / bump mapping, and what else can be done and allowed. My ideas and plans will be more on the LUA side in the future |
20:24 |
Taoki |
Though if I can help with the engine too at any time, I like to |
20:24 |
hmmmm |
taoki, have you looked at what Terasology does for hardware lighting? |
20:25 |
Taoki |
But before coding new features, I'll probably ask first from now on. I spoke about this with PilzAdam, but I can't rely on every main dv telling me if a feature is right or wrong since not everyone is online all the time |
20:25 |
Taoki |
hmmmm: I'm not familiar with its code, but I'm totally impressed by its graphics |
20:25 |
PilzAdam |
celeron55, care to put a rangelime arround the setting? |
20:25 |
hmmmm |
well they seem to have the problems we've discussed figured out already |
20:26 |
celeron55 |
we have a simple rule: if two in the core team agree on something, it can be merged; but as i did now, it can of course be reverted or disabled by default later |
20:26 |
celeron55 |
PilzAdam: why? |
20:26 |
Taoki |
ok |
20:26 |
PilzAdam |
fall_bobbing_amount = 100 <- I just tried that |
20:27 |
Taoki |
PilzAdam: That will probably cause the view to go way in the ground :P |
20:27 |
celeron55 |
well that's user error (or if someone is crazy enough, that may be exactly the wanted thing) |
20:27 |
celeron55 |
my policy is to not restrict anything unless actually necessary |
20:27 |
hmmmm |
also what's up with the mese pick not being able to mine cactuses anymore |
20:27 |
PilzAdam |
its illogical to go deeper than the ground |
20:28 |
hmmmm |
that's a bit redic. |
20:28 |
kahrl |
it could be seen as a cheaty way to find caves |
20:28 |
PilzAdam |
hmmmm, you need an axe for this |
20:28 |
Taoki |
PilzAdam: Sure. Which is why one shouldn't set the setting too high... maybe beyond 2 or so |
20:28 |
iqualfragile |
great… now everybody is unhappy about it not beeing on by default |
20:29 |
celeron55 |
oh god |
20:29 |
celeron55 |
i thought making the amount configurable was a good idea |
20:29 |
celeron55 |
... |
20:29 |
Taoki |
It is a good idea. View bobbing is configurable too |
20:29 |
Taoki |
It's how I intended it initially also |
20:29 |
kahrl |
nothing is ever easy :P |
20:29 |
celeron55 |
move on, it's done and perfect now |
20:30 |
* celeron55 |
moves hands like a police guiding traffic |
20:30 |
Taoki |
:) |
20:31 |
celeron55 |
if somebody wants to limit it, the limit must be done so that it's barely limited to not go through ground |
20:31 |
celeron55 |
anything else is overly restrictive |
20:36 |
celeron55 |
i'm open to testing improvements on it, if somebody cares to attempt such |
20:36 |
celeron55 |
i'm not hopeful at all about that though |
20:48 |
celeron55 |
anyway, there are at least three problems with it: it does not properly match the fall velocity of the player, the acceleration curve of it doesn't make much sense (it uses sin(); that's not right in any way) and it shouldn't really happen at all unless the player is continuously walking |
20:49 |
celeron55 |
when testing it when walking without jumping at all, one can kind of see what it tries to do |
20:49 |
celeron55 |
but it's too wrong to be enjoyable even then |
20:54 |
|
iqualfragile joined #minetest-dev |
20:56 |
celeron55 |
so my "2) it would be stupid anyway" part might be wrong; but i am yet to see |
21:02 |
|
sapier1 joined #minetest-dev |
21:04 |
Exio |
:D perfect, now i can haz fall_bobbing_amount = 2.0 |
21:27 |
|
proller joined #minetest-dev |
21:28 |
kahrl |
ugh, not having any luck whatsoever trying to reproduce the F10 crash |
21:28 |
kahrl |
has it been fixed? I haven't seen any mention of that in chat |
21:29 |
kahrl |
though I managed to fix an unrelated bug that few people will ever notice, but anyway: https://github.com/kahrl/minetest/commit/104fe65b4155f9341e3e66bdf11b5d1385b3e61a |
21:30 |
kahrl |
hope it's okay I fixed a typo in the same commit |
21:33 |
sapier1 |
is there any scheme when a travis build is run? |
21:41 |
|
OWNSyouAll joined #minetest-dev |
21:55 |
hmmmm |
erm |
21:55 |
sapier1 |
yes? |
21:55 |
* VanessaE |
looks at hmmmm |
21:55 |
hmmmm |
kahrl, vanessa gave us a backtrace for the F10 bug and the problem seems to be in a call to isspace(), but the string it was passing the character to was wide |
21:56 |
hmmmm |
i figured that was probably the problem, but because we can't reproduce it, i didn't touch it |
22:08 |
kahrl |
right, that should maybe be iswspace |
22:08 |
kahrl |
don't see how it could crash though |
22:08 |
hmmmm |
me neither |
22:08 |
hmmmm |
but it was a segfault, and it happened in isspace |
22:09 |
kahrl |
pretty it's memory corruption that for some reason causes a crash when submitting chat |
22:09 |
kahrl |
pretty sure* |
22:10 |
hmmmm |
by submitting chat you mean opening up the console, right? that's why it's called the F10 bug, because you press F10, it instantly crashes (for certain people) |
22:10 |
hmmmm |
but i do agree that it must be memory corruption, otherwise there would be no explanation to why the majority of people don't have the problem |
22:10 |
kahrl |
oh, no I didn't mean that |
22:11 |
kahrl |
because for me when it crashed (years ago) it was always when I pressed enter in the console |
22:11 |
ShadowNinja |
There is also a chat-submit bug |
22:11 |
hmmmm |
yeah, those are two different things then |
22:11 |
kahrl |
possibly caused by the same memory corruption |
22:12 |
ShadowNinja |
Also a rare bug, and sometimes the same message won't cause the crash |
22:19 |
|
OWNSyouAll joined #minetest-dev |
22:26 |
hmmmm |
ugh |
22:26 |
hmmmm |
i need to finish up with what i'm doing |
22:31 |
hmmmm |
whatever, i'm done. |
22:32 |
hmmmm |
i'm going to stop fiddling around and just commit it. it does have its problems though, you can pick your poison though by disabling or enabling shaders (i'll solve the problems at some later point in time if it's really that bad) |
22:39 |
hmmmm |
https://github.com/kwolekr/minetest/commit/7bd10de45d9a012be53528d2b7c15544989940b2 |
22:48 |
ShadowNinja |
hmmmm: use_texture_alpha_channel is terribly long |
22:51 |
ShadowNinja |
just use_alpha or use_texture_alpha would work fine I think |
23:05 |
|
kaeza joined #minetest-dev |
23:28 |
|
OWNSyouAll joined #minetest-dev |
23:29 |
hmmmm |
yeah but this is self-descriptive |
23:33 |
|
drizz joined #minetest-dev |