| Time |
Nick |
Message |
| 00:10 |
|
OWNSyouAll joined #minetest-dev |
| 00:32 |
|
kaeza joined #minetest-dev |
| 00:37 |
RealBadAngel |
im debbuging now what getNodeNoEx returns and i keep getting strange things |
| 00:40 |
RealBadAngel |
what is content = 29 ? |
| 00:45 |
|
dexter0 joined #minetest-dev |
| 00:47 |
RealBadAngel |
nvm, found out |
| 00:57 |
hmmmm |
the 30th node that you registered 8) |
| 01:02 |
RealBadAngel |
i was dumpin the content on direction i had problems |
| 01:02 |
hmmmm |
sooo |
| 01:03 |
RealBadAngel |
in fact at the very beginin (just loaded the world) it shows there 127 - content ignore |
| 01:03 |
hmmmm |
any objections to the use texture alpha channel? |
| 01:03 |
RealBadAngel |
its ok with me |
| 01:03 |
hmmmm |
there are two problems with it though, and i'd really like to document them beforehand, where would i do that? |
| 01:04 |
RealBadAngel |
on dev wiki? |
| 01:04 |
hmmmm |
i guess, but i was thinking more like on github |
| 01:04 |
hmmmm |
do i just create two bug reports? |
| 01:05 |
hmmmm |
and refer people to those if they complain? |
| 01:05 |
hmmmm |
do i put the known problems in the lua_api.txt? |
| 01:06 |
RealBadAngel |
maybe put link to wiki in doc and then later on when problems are solved remove it? |
| 01:06 |
hmmmm |
i guess |
| 01:08 |
RealBadAngel |
about my problem, content ignore is just one thing, second is when i put node at the border of the block, only nodes in this block are updated |
| 01:08 |
RealBadAngel |
neighbourin block is not updated |
| 01:09 |
RealBadAngel |
so effect in both cases is the same, but reasons are different |
| 01:10 |
hmmmm |
why not just connect with content ignore too? |
| 01:11 |
RealBadAngel |
that fixes first reason |
| 01:11 |
RealBadAngel |
but not the second |
| 01:11 |
RealBadAngel |
when im placing the node |
| 01:11 |
hmmmm |
yeah, you'll have one less problem though |
| 01:12 |
RealBadAngel |
i guess autoconnecting nodes shall force update the neighbour if it is in another block |
| 01:13 |
RealBadAngel |
but this should be done on_place, not in render code imho |
| 01:14 |
hmmmm |
then why not do it there? |
| 01:15 |
RealBadAngel |
if i put such trigger in mesh update thread i could cause chains of forced updates |
| 01:16 |
RealBadAngel |
in fact i need to do that only once |
| 01:17 |
RealBadAngel |
simple punch on ANY node in non updated block fixes the connections |
| 01:17 |
kahrl |
what if you change addUpdateMeshTaskWithEdge to update all 6 adjacent meshes instead of only 3 of them? |
| 01:19 |
RealBadAngel |
but then updating the neighbours will trigger the update for their neighbours and so on |
| 01:20 |
kahrl |
no |
| 01:20 |
kahrl |
it calls addUpdateMeshTask |
| 01:20 |
kahrl |
it's not recursive |
| 01:20 |
|
IceCraft joined #minetest-dev |
| 01:21 |
RealBadAngel |
if not then i will try to do so |
| 01:22 |
RealBadAngel |
ah |
| 01:22 |
RealBadAngel |
that will really help imho |
| 01:23 |
RealBadAngel |
it add check only to - direction |
| 01:23 |
RealBadAngel |
and problem i noticed on ALL + directions |
| 01:25 |
RealBadAngel |
yikes! it works :) thx kahrl :) |
| 01:26 |
RealBadAngel |
shall i post client.cpp change to addUpdateMeshTaskWithEdge as separate patch? |
| 01:27 |
hmmmm |
yes |
| 01:27 |
RealBadAngel |
ok, i will do so in a few minutes |
| 01:27 |
hmmmm |
kinda wonder what the rationale behind making it only update 3 directions is now |
| 01:27 |
RealBadAngel |
will make this with loop and table |
| 01:27 |
RealBadAngel |
6 same pieces of code in a row looks stupid |
| 01:28 |
hmmmm |
i made it look nice in calcLighting() |
| 01:28 |
kahrl |
yeah, use g_6dirs |
| 01:29 |
kahrl |
hmmmm: I think this piece of code is really old... 3 directions used to be enough |
| 01:30 |
hmmmm |
hrm |
| 01:30 |
hmmmm |
RBA, do you want to commit your thing first, or shall I? |
| 01:30 |
hmmmm |
it's going to cause a conflict either way i bet |
| 01:32 |
RealBadAngel |
i can see same code down below in addUpdateMeshTaskForNode |
| 01:33 |
RealBadAngel |
also only 3 directions |
| 01:33 |
hmmmm |
i wouldn't change it if i were you |
| 01:33 |
RealBadAngel |
why? |
| 01:34 |
hmmmm |
the 3 directions is sufficient for that, evidently |
| 01:34 |
hmmmm |
doing more work than is necessary is bad |
| 01:34 |
hmmmm |
if your thing works with the one modification, i'd leave the other thing be |
| 01:34 |
RealBadAngel |
ok, at least if it pops up i will know where to look ;) |
| 01:34 |
hmmmm |
yeah |
| 01:34 |
hmmmm |
hope it doesn't though |
| 01:35 |
hmmmm |
i mean doesn't that put twice as much work on the mesh update thread? |
| 01:36 |
RealBadAngel |
if it does i guess we have to live with it, because it is ablosutely necesary imho |
| 01:37 |
kahrl |
the difference is 3 more mesh updates when the client sets or removes a crack |
| 01:38 |
RealBadAngel |
so no big deal |
| 01:38 |
hmmmm |
er |
| 01:38 |
kahrl |
maybe |
| 01:38 |
hmmmm |
okay :) |
| 01:39 |
kahrl |
I remember that I coded the crack stuff into the animation system so that cracks didn't eat all performance on celeron's hardware |
| 01:40 |
kahrl |
before then, every time the crack texture changed, there were 4 mesh updates |
| 01:41 |
kahrl |
now it is only when the crack is added or removed |
| 01:42 |
hmmmm |
now hold on a minute, when you say update, does it mean the entire mesh for that mapblock is regenerated, or is the existing mesh modified? |
| 01:43 |
kahrl |
yeah regenerated |
| 01:44 |
kahrl |
nowadays changing the crack texture only modifies the existing mesh |
| 01:44 |
hmmmm |
sounded painful before |
| 01:44 |
kahrl |
it was =) |
| 01:49 |
kahrl |
I keep stumbling upon mapblock_mesh.cpp:1365 |
| 01:50 |
kahrl |
should I try to implement the suggestion there? people seem to run into that limit somewhat often |
| 01:50 |
kahrl |
(for irc log SEO: FIXME: Meshbuffer ran out of indices) |
| 01:53 |
RealBadAngel |
go on, its really needed |
| 01:54 |
RealBadAngel |
i started with it but im still learnin stuff related to meshes |
| 01:56 |
RealBadAngel |
moretrees makes you hit that limit in no time ;) |
| 01:59 |
kahrl |
I thought moretrees was mostly L-system stuff? not complex nodeboxes? |
| 01:59 |
kahrl |
or how does it hit the limit? |
| 01:59 |
RealBadAngel |
huge amount of leaves |
| 02:00 |
kahrl |
ok true, that's a lot of allfaces nodes |
| 02:06 |
|
kaeza1 joined #minetest-dev |
| 02:14 |
|
ssieb joined #minetest-dev |
| 02:14 |
RealBadAngel |
https://github.com/minetest/minetest/pull/680 |
| 02:14 |
RealBadAngel |
i need a coffee |
| 02:15 |
RealBadAngel |
thx to it i will be able to pull NDT_GLASSLIKE_FRAMED tommorow, need just to clean it and write some docs |
| 02:16 |
RealBadAngel |
not the coffee ofc, but the fix above ;) |
| 02:17 |
hmmmm |
why not commit it? |
| 02:18 |
RealBadAngel |
you know why ;) |
| 02:18 |
RealBadAngel |
you do it |
| 02:18 |
hmmmm |
no, why? |
| 02:18 |
hmmmm |
oh |
| 02:18 |
hmmmm |
oh come on man, learn how2use git |
| 02:18 |
hmmmm |
i'll guide you through it if you'd like |
| 02:18 |
RealBadAngel |
i playin with branches on technic body |
| 02:19 |
RealBadAngel |
*im |
| 02:19 |
RealBadAngel |
had lately to remove whole tree and build it from scratch ;) |
| 02:19 |
hmmmm |
alright |
| 02:20 |
RealBadAngel |
when i will be sure i wont screw something i will let you know :) |
| 02:21 |
hmmmm |
even if you do screw it up somehow, any of us can fix it by simply force-pushing our current tree |
| 02:21 |
RealBadAngel |
we can try tommorow with glasslike_framed |
| 02:23 |
RealBadAngel |
btw, http://pastebin.com/vthR9T7B |
| 02:23 |
RealBadAngel |
this is the code |
| 02:24 |
hmmmm |
now that is scary looking |
| 02:24 |
RealBadAngel |
hehe why? |
| 02:24 |
hmmmm |
just look at it |
| 02:25 |
hmmmm |
oh |
| 02:26 |
hmmmm |
by the way, we put the opening and closing braces on the same level of indentation |
| 02:26 |
RealBadAngel |
i havent cleaned it yet |
| 02:26 |
hmmmm |
so like, how do you figure out all those constants? do you just sit there and figure them out one by one? |
| 02:26 |
hmmmm |
it's nuts |
| 02:27 |
RealBadAngel |
you mean triplets? |
| 02:27 |
hmmmm |
that and the aabb3fs |
| 02:27 |
RealBadAngel |
not really, nodeboxes are defined with a program |
| 02:28 |
RealBadAngel |
i just replaced values with variable (i used this model many times already) |
| 02:28 |
hmmmm |
ah |
| 02:28 |
RealBadAngel |
to make it scalable |
| 02:28 |
RealBadAngel |
and triplets are selfexplainin |
| 02:29 |
RealBadAngel |
you look at the g26dirs, look at the direction |
| 02:29 |
RealBadAngel |
and put there rule nr |
| 02:30 |
RealBadAngel |
so its really easy to define which nodes you want to check |
| 02:32 |
RealBadAngel |
thx to im not checkin unwanted nodes in 3x3x3 box |
| 02:32 |
RealBadAngel |
so just 18 instead of all 26 |
| 02:36 |
hmmmm |
oh shoot |
| 02:36 |
hmmmm |
i hate it when you're right |
| 02:37 |
hmmmm |
you were right about the on-draw tile colorizing being tough to do |
| 02:37 |
hmmmm |
i just realized that finalColorBlend works on verticies, not on the actual tile |
| 02:38 |
RealBadAngel |
node stored in the world shall carry just two more tables to do all the fancy stuff |
| 02:38 |
RealBadAngel |
nodeboxes and tiles |
| 02:38 |
RealBadAngel |
ofc only if modified |
| 02:39 |
RealBadAngel |
and then nodeboxes animation, texture changin, whatever will be child's play |
| 02:39 |
hmmmm |
....:( |
| 02:40 |
hmmmm |
okay, forget about all the shader crap, i don't need it anymore |
| 02:40 |
hmmmm |
the only solution here is to really just generate all those different textures |
| 02:40 |
hmmmm |
so this would reduce the number of nodes needing to be defined, but won't help the number of textures at all |
| 02:40 |
RealBadAngel |
ALSO important side effect we cut nodes count by hundreds |
| 02:41 |
RealBadAngel |
if not thousands like on VanessaE's server |
| 02:41 |
hmmmm |
the biggest benefit here would've been cutting the number of textures |
| 02:41 |
hmmmm |
it's still very attractive though |
| 02:41 |
RealBadAngel |
wires - 1 node instead of 64 |
| 02:42 |
RealBadAngel |
same apply to mesecons |
| 02:42 |
hmmmm |
huh |
| 02:42 |
hmmmm |
hold on a minute |
| 02:42 |
RealBadAngel |
pipes, frames |
| 02:42 |
hmmmm |
if you combine some other param2 with this, you'll have less than 64 colors |
| 02:42 |
RealBadAngel |
all stairsplus nodes |
| 02:42 |
hmmmm |
facedir takes up 5 bits |
| 02:42 |
hmmmm |
which leaves only 3 for color |
| 02:43 |
hmmmm |
so how many different colors of stairsplus are there? |
| 02:43 |
RealBadAngel |
colors? |
| 02:43 |
hmmmm |
yeah |
| 02:43 |
RealBadAngel |
stairsplus is about nodeboxes, not different colors |
| 02:44 |
hmmmm |
then how would this help stairsplus nodes |
| 02:44 |
RealBadAngel |
simply. if you can define on the fly a nodebox |
| 02:44 |
RealBadAngel |
and insert it into world |
| 02:45 |
hmmmm |
well that's not what i was planning at all |
| 02:45 |
RealBadAngel |
then why predefine dozens of them for each wanted material? |
| 02:45 |
RealBadAngel |
but this is connected |
| 02:45 |
hmmmm |
right |
| 02:45 |
hmmmm |
the same concept can be applied |
| 02:45 |
RealBadAngel |
because same applies to textures |
| 02:45 |
RealBadAngel |
so no more 2 furnaces |
| 02:45 |
RealBadAngel |
just one and change the texture just |
| 02:46 |
hmmmm |
but let's see |
| 02:46 |
hmmmm |
erm |
| 02:46 |
hmmmm |
so you need 8 or less types of stairs for each material? |
| 02:47 |
hmmmm |
corner in, corner out, regular stair, half slab, that's 4 different shapes of stairs |
| 02:49 |
RealBadAngel |
there are more pieces |
| 02:49 |
RealBadAngel |
microblocks, panels, etc |
| 02:49 |
hmmmm |
oh yeah but a microblock is different and it's used in recipes iirc |
| 02:50 |
hmmmm |
for obvious reasons, you won't be able to specify a certain param2 for craft recipes, that's getting ridiculous |
| 02:50 |
RealBadAngel |
no need to |
| 02:51 |
RealBadAngel |
all modders need is an ability to modify nodeboxes and tiles on the fly |
| 02:51 |
hmmmm |
mm |
| 02:51 |
RealBadAngel |
give that to them and you will see miracles in a few weeks |
| 02:52 |
hmmmm |
would you like to do this? |
| 02:52 |
hmmmm |
or should i |
| 02:52 |
RealBadAngel |
by now i dont know where to start |
| 02:53 |
RealBadAngel |
im not familiar with how the nodes are stored |
| 02:53 |
hmmmm |
well gosh, i know where, scriptapi_content.cpp |
| 02:53 |
hmmmm |
8) |
| 02:53 |
RealBadAngel |
hehehe |
| 02:53 |
RealBadAngel |
lemme finish mesh drawtype and you go for it |
| 02:53 |
hmmmm |
alright |
| 02:54 |
hmmmm |
let's see what we're going to have to do |
| 02:54 |
RealBadAngel |
imho node shall have kinda flag "modified" and then read tables not from definition but from stored node |
| 02:55 |
hmmmm |
first we'd have to wrap all facedir operations in (x & 0x1F) |
| 02:55 |
hmmmm |
or is that already done |
| 02:55 |
RealBadAngel |
ive put such and somwhere |
| 02:56 |
hmmmm |
a lot of caution would need to be put into making sure that facedir only modifies the bits that it's allowed |
| 02:57 |
RealBadAngel |
i will check it when i got back from work today |
| 02:57 |
hmmmm |
k |
| 02:57 |
RealBadAngel |
now im leaving to work, just 5 minutes left |
| 02:57 |
hmmmm |
later |
| 02:57 |
RealBadAngel |
next week i will have 5 days in a row free for coding |
| 03:02 |
kaeza |
hmmmm, can you merge this one? https://github.com/kaeza/minetest/commit/ff0578d35992f4b3b28533fdf8c9c60a7acf423d |
| 03:02 |
kaeza |
and sorry about that |
| 03:04 |
|
kaeza joined #minetest-dev |
| 03:16 |
hmmmm |
ehehe |
| 03:16 |
hmmmm |
that's a pretty huge bug |
| 03:18 |
kaeza |
well... no one is using the HUD thingy yet |
| 03:18 |
kaeza |
(besides me) |
| 03:19 |
hmmmm |
did you have a pull request for that? |
| 03:19 |
kaeza |
nope |
| 03:20 |
hmmmm |
it's great that others are further developing the HUD |
| 03:20 |
kaeza |
I pushed it to the same branch, but the pull rq was already closed, so I thought it would be a waste to open another for a smallish change |
| 03:20 |
kaeza |
ah thanks |
| 03:20 |
hmmmm |
i felt that i would probably be the only one to add/modify it |
| 03:21 |
hmmmm |
but i guess that's not so |
| 03:21 |
kaeza |
I'd like to see more feedback from modders to see what more is needed |
| 03:21 |
hmmmm |
that's what the forum is for.. they just need to start using it more |
| 03:21 |
kaeza |
but nobody wants to play with HUDs :( |
| 03:22 |
hmmmm |
i thought people would go crazy over huds |
| 03:22 |
kaeza |
me too, that feature has been requested time and time again |
| 03:24 |
kaeza |
I see it is now possible to use texture alpha. This will be great for some stuff |
| 03:25 |
hmmmm |
it's not perfect. |
| 03:25 |
hmmmm |
see the wiki topic on minetest.register_item |
| 03:25 |
kahrl |
I have played a bit with huds and have one lua_api.txt suggestion |
| 03:25 |
kahrl |
make it clearer that 'text' is where you put the texture name for image hud elements |
| 03:27 |
kaeza |
it is |
| 03:28 |
kahrl |
oh, I somehow missed that |
| 03:28 |
kaeza |
https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L433 |
| 03:28 |
kahrl |
I only looked at the section at the end |
| 03:28 |
kaeza |
err...wrong link |
| 03:29 |
kaeza |
well, it's kinda like reusing parameters |
| 03:29 |
kaeza |
for example, 'number' is used as statbar value, but as text color |
| 03:30 |
hmmmm |
just being efficient |
| 03:30 |
hmmmm |
it's better than having 1000 different parameter names |
| 03:30 |
kahrl |
yeah it's fine. I'm just being derpy |
| 03:33 |
kahrl |
I guess that happened because I typed /hud in less and that is case sensitive |
| 03:34 |
hmmmm |
someone should write a manpage for minetest |
| 03:36 |
kahrl |
"BUGS For this feature, you need to install the insects(6) mod which depends on mobf(6)." |
| 03:37 |
kaeza |
hmmmm, isn't there one already? |
| 03:37 |
kaeza |
doc/minetest.6 |
| 03:38 |
hmmmm |
hrm? dunno |
| 03:38 |
hmmmm |
it's not installed for me |
| 03:39 |
kaeza |
it only contains command line usage though |
| 03:41 |
kaeza |
and, erhm... I don't think it's very up to date... perhaps from the 0.3.x days |
| 03:43 |
kahrl |
there's some 0.4 stuff like gameid in there |
| 03:46 |
hmmmm |
has anyone played terasology or blockscape? |
| 03:47 |
hmmmm |
if so, can you tell me if there is a height limit? |
| 04:02 |
|
mitori joined #minetest-dev |
| 04:06 |
hmmmm |
a |
| 04:07 |
hmmmm |
this thread is very insightful http://forum.movingblocks.net/threads/height-limit.576/page-2 |
| 04:07 |
hmmmm |
indeed they use shadow masks |
| 04:15 |
hmmmm |
erm no what am i saying |
| 04:15 |
hmmmm |
_because_ terasology has a height limit of 256, they can use hardware lighting |
| 04:20 |
ShadowNinja |
hmm, not sure how this works but can't you just assume that non-loaded blocks are transparent? |
| 04:22 |
hmmmm |
of course not, we'd have light shining through caves |
| 04:22 |
hmmmm |
all this was discussed |
| 04:22 |
|
darkrose joined #minetest-dev |
| 04:22 |
|
darkrose joined #minetest-dev |
| 04:23 |
ShadowNinja |
If you were in a cave then the ceiling would most likely be loaded |
| 04:25 |
hmmmm |
hrm. |
| 04:26 |
hmmmm |
alright, from what i've observed, terasology has a small height limit and all of the vertical space is loaded at the same time, allowing for the use of accurate hardware lighting; but they don't use hardware lighting, they store light values for some reason even though they don't need to. it seems they are trying to move to our kind of format |
| 04:27 |
hmmmm |
blockscape on the other hand, has no height limit at all and stores no light value |
| 04:27 |
ShadowNinja |
Wait, it is infinite? or just crazy high? |
| 04:28 |
hmmmm |
well, very high |
| 04:28 |
hmmmm |
i wouldn't say it's very relevant because if it's "high enough" then they can't have the entire thing loaded at once which means they can't do the obvious thing for lighting |
| 04:30 |
ShadowNinja |
Yes, I was just curious |
| 04:36 |
kahrl |
how does blockscape do indirect light without storing light values? |
| 04:39 |
kahrl |
hm, looking at some videos it seems like they don't |
| 04:40 |
kahrl |
so shadowed areas get pitch black (+ ambient light) pretty quickly |
| 04:40 |
hmmmm |
aaa http://forum.blockscape.com/viewtopic.php?f=10&t=3216&start=20#p13233 |
| 04:40 |
hmmmm |
what's this |
| 04:40 |
hmmmm |
chunk type 10 "is world rotation (for the day/night cycle)" |
| 04:41 |
hmmmm |
oh |
| 04:41 |
hmmmm |
file chunk |
| 04:42 |
hmmmm |
he uses the terminology "chunk" to mean chunk in the file, and "world chunk" to mean a variable-height collection of 32x32 nodes |
| 04:42 |
hmmmm |
er |
| 04:43 |
hmmmm |
a "world chunk" is made up of a variable number of "block layers", a "block layer" is a 32x32 collection of nodes |
| 04:45 |
hmmmm |
so like what, do the people making these blockscape editors just not do lighting at all? |
| 04:45 |
hmmmm |
>Heist, well, while you work on graphical stuff, I will tinker with decoding some more, cuz C# 3D stuff is too over complicated. And I wasn't able to find byte buffer in .net framework |
| 04:46 |
hmmmm |
C# is hard for them, so I guess I shouldn't expect very good solutions from the forum |
| 04:56 |
hmmmm |
it seems to me like they just rely on the world around them loading quick enough that nobody would notice light shining through before the shadow gets loaded |
| 04:57 |
|
darkrose joined #minetest-dev |
| 04:59 |
hmmmm |
indeed.. http://blockscape.wikia.com/wiki/Bug_List - see the second to last point |
| 05:11 |
kaeza |
I don't understand it... blockscape has apparently awesome graphics, but does not have the basic things (which MT had from the beginning)? |
| 07:43 |
|
celeron55 joined #minetest-dev |
| 07:46 |
|
darkrose joined #minetest-dev |
| 07:50 |
celeron55 |
<+hmmmm> kinda wonder what the rationale behind making it only update 3 directions is now |
| 07:50 |
celeron55 |
it's because mesh updates are painfully slow |
| 07:50 |
celeron55 |
it's commonly the limiting factor when transferring blocks from the server |
| 07:51 |
celeron55 |
that'll effectively halve the transfer rate in many cases now 8) |
| 07:52 |
|
emptty joined #minetest-dev |
| 08:00 |
celeron55 |
(actually, commonly = probably only single player) |
| 08:13 |
|
darkrose joined #minetest-dev |
| 08:13 |
|
darkrose joined #minetest-dev |
| 08:17 |
|
chaiman joined #minetest-dev |
| 08:17 |
chaiman |
Hello |
| 08:18 |
chaiman |
I want to ask about this: http://forum.minetest.net/viewtopic.php?id=5459 |
| 08:18 |
chaiman |
The idea is to move death screen to lua |
| 08:19 |
chaiman |
So some kind of afterlife would be possible |
| 08:22 |
chaiman |
Also, dead and alive should see world differently - same blocks should be rendered differently for those who are dead. |
| 08:23 |
chaiman |
Both of this require changes to the engine to be made |
| 08:23 |
|
darkrose joined #minetest-dev |
| 08:23 |
chaiman |
So, basically, will this be added, if implemented? |
| 08:24 |
kaeza |
hmm |
| 08:25 |
kaeza |
I'm not very sure about the different rendering |
| 08:26 |
chaiman |
By "different rendering" I mean rather "different texture" |
| 08:26 |
chaiman |
the problem that can't be set in the realtime |
| 08:27 |
chaiman |
But if it would be possible to define 2 sets of textures |
| 08:28 |
chaiman |
then engine will check fo is_alive flag (or smth like that) and apply a different texture, which is allready in node definition |
| 08:28 |
chaiman |
*for |
| 08:28 |
kaeza |
well... that would require some big changes |
| 08:29 |
kaeza |
and I doubtif it would be useful for anything else |
| 08:29 |
chaiman |
It probably wont |
| 08:29 |
kaeza |
but meh, I'm not the one to give the ok or no about that |
| 08:29 |
chaiman |
Idea was to bring a new level of exploration |
| 08:31 |
chaiman |
In MC you can build, fight, go to nether for resources aand explore there, then there are END and even after the end you may discover potions stuff etc |
| 08:31 |
celeron55 |
that sounds quite arbitrary, you probably need to think of it in some more general way if you want to propose something to be put in the engine |
| 08:32 |
chaiman |
@celeron55, I don't quite got your message |
| 08:32 |
celeron55 |
put in other words, we aren't eager to put things in the engine that are not widely useful |
| 08:33 |
chaiman |
That's why I finally came here - to convince that ghosts thing will bring joy and amusement ;) |
| 08:33 |
chaiman |
Anyway |
| 08:33 |
chaiman |
Suppose all above is done and the code is good |
| 08:34 |
kaeza |
indeed they will, but not as an engine feature |
| 08:34 |
celeron55 |
moving the death screen to lua sounds like something to consider if there is a way to implement it cleanly and robustly |
| 08:35 |
celeron55 |
i can't say much more than that nothing will be added that is not useful for anything else than your ghost thing |
| 08:36 |
chaiman |
It's not mine |
| 08:36 |
celeron55 |
you need to propose general things that many will find use for that also work well for it too |
| 08:36 |
chaiman |
So, even if it wiil be ready to merge you won't add this? |
| 08:36 |
chaiman |
*will |
| 08:37 |
celeron55 |
as you described it, probably not, unless it's very simple and affects basically nothing |
| 08:38 |
chaiman |
I got your point. Thanks for your time. Bye. |
| 08:38 |
kaeza |
being able to disable the death screen would be useful perhaps, but the different rendering not so much |
| 08:38 |
celeron55 |
i know that making games with personality is easier if you can freely mess around with the engine, but it won't work for us in the long run |
| 08:38 |
kaeza |
erhm |
| 08:39 |
kaeza |
whatever |
| 08:39 |
celeron55 |
it works for a do-once release |
| 08:39 |
kahrl |
moving the death screen to lua seems easy enough |
| 08:39 |
kaeza |
perhaps implemented as a formspec? |
| 08:39 |
kahrl |
remove the SendDeathscreen calls from Server; add a scriptapi function that calls SendDeathscreen; implement the proper lua callbacks |
| 08:40 |
kahrl |
or remove the deathscreen entirely and find some way to do it with formspec, yes |
| 08:40 |
celeron55 |
...plus backwards compatibility |
| 08:40 |
celeron55 |
(if possible) |
| 08:40 |
kahrl |
it'll be a protocol change, I suppose |
| 08:41 |
celeron55 |
at least a new client has to support an old server; maybe not for a new server - old client combination |
| 08:41 |
kaeza |
which reminds me, would it be useful to add methods to the hud to be able to relocate the healthbar and/or hotbar? |
| 08:41 |
celeron55 |
(because of easiness of implementation) |
| 08:41 |
kahrl |
new server - old client would work if implemented via formspec |
| 08:42 |
kahrl |
unless the client is really old |
| 08:43 |
celeron55 |
kaeza: no; maybe a simple call to hide them |
| 08:43 |
kahrl |
and if lua just calls SendDeathscreen there aren't any server<->client compatibility problems |
| 08:44 |
kaeza |
celeron55, we discussed this ("discussed") and adding health/hot bar completely in Lua would have problems under heavy lag |
| 08:45 |
kaeza |
+with hmmmm |
| 08:45 |
celeron55 |
kaeza: we really care only about compatibility between git head and the existing stable release, but if necessary new server/old client compatibility can be dropped |
| 08:45 |
celeron55 |
... |
| 08:45 |
celeron55 |
kahrl* |
| 08:46 |
celeron55 |
kaeza: well, in that case you'd have the screen full of other lag-affected bars anyway so it wouldn't really matter |
| 08:46 |
kaeza |
okay... |
| 08:47 |
kaeza |
good point |
| 08:47 |
|
darkrose joined #minetest-dev |
| 08:49 |
kaeza |
so I guess I need to add a new command to the protocol? |
| 08:50 |
kaeza |
actually, this could be done with a special parameter to hud_remove() |
| 08:50 |
kahrl |
why a special parameter if you want to move the default hud to lua? |
| 08:51 |
kaeza |
because there won't be any move to Lua |
| 08:51 |
celeron55 |
something like hud_remove_builtin() would probably be cleanest |
| 08:51 |
kaeza |
I'll just disable the default HUD, and let a mod in default handle it |
| 08:51 |
celeron55 |
some magic ids or something is kind of hacky |
| 08:52 |
kaeza |
I mean about the protocol... I don't want to mess with that stuff if at all possible |
| 08:52 |
celeron55 |
or actually... hud_enable_builtin(true/false) |
| 08:52 |
celeron55 |
you can add a new message for that |
| 08:53 |
kaeza |
okay |
| 08:53 |
celeron55 |
you'd kind of have to modify the protocol anyway |
| 08:54 |
celeron55 |
hell, someon has messed up the command ids once again |
| 08:54 |
celeron55 |
so let's count in hex |
| 08:54 |
celeron55 |
0x48, 0x49, 0x50? |
| 08:54 |
celeron55 |
NO! this is shit |
| 08:55 |
kaeza |
heh |
| 08:56 |
celeron55 |
just move all of them to correct place and don't modify any protocol versions |
| 08:57 |
celeron55 |
building on broken stuff has to stop |
| 08:59 |
kaeza |
won't this break compat? |
| 08:59 |
kaeza |
err... nvm |
| 08:59 |
celeron55 |
yes it will |
| 09:00 |
celeron55 |
but the hud implementation is still clearly only taking it's initial shape so it's prefectly fine |
| 09:00 |
|
jin_xi joined #minetest-dev |
| 09:00 |
kaeza |
ok, so renumbering messages then |
| 09:00 |
celeron55 |
so the existing ones should be 0x49, 0x4a and 0x4b, and yours will be 0x4c |
| 09:02 |
kaeza |
should I make it so a single call enables/disables everything? |
| 09:02 |
celeron55 |
hmm... what are the things subject to this |
| 09:02 |
celeron55 |
the hotbar and the health bar? |
| 09:03 |
kaeza |
yes |
| 09:03 |
celeron55 |
i wonder if somebody would want to mess around with wielded item rendering |
| 09:03 |
kaeza |
hmm |
| 09:04 |
kahrl |
maybe someone wants to move it to the center for doomlike rendering |
| 09:04 |
celeron55 |
this is trickier than it seemed |
| 09:04 |
kaeza |
maybe being able to disable individual components would be better |
| 09:04 |
celeron55 |
kaeza: i |
| 09:04 |
celeron55 |
... |
| 09:04 |
celeron55 |
kahrl: well, i'm thinking mostly if it should be disableable, on it's own |
| 09:04 |
kaeza |
... |
| 09:05 |
celeron55 |
so maybe we need some kind of a thing to disable and enable some named hud parts |
| 09:06 |
kaeza |
right |
| 09:06 |
kaeza |
maybe player:hud_builtin_enable("hotbar", true) |
| 09:06 |
kaeza |
(or some variation) |
| 09:08 |
celeron55 |
as for the api, i think that's fine |
| 09:08 |
celeron55 |
the protocol needs a small bit of thought |
| 09:08 |
kaeza |
that's what I meant actually |
| 09:08 |
kaeza |
maybe this can be done in a single messane |
| 09:09 |
kaeza |
passing first the named item, and then the flag |
| 09:09 |
kaeza |
message* |
| 09:09 |
celeron55 |
well i guess it'll just convert the "hotbar" and "healthbar" and "wielditem" or something like that to some predefined ids |
| 09:09 |
celeron55 |
and put the id and a boolean in a message |
| 09:09 |
kaeza |
there are util functions in scriptapi to convert strings to enums |
| 09:10 |
kaeza |
this is what hud_change() uses |
| 09:10 |
kaeza |
it converts "number" to HUD_STAT_NUMBER, and sends this to the client |
| 09:11 |
kaeza |
I can do the same |
| 09:11 |
celeron55 |
yeah, it's fine |
| 09:11 |
kaeza |
one little question... what's the preferred method to send a boolean? a single char or an u32? |
| 09:11 |
celeron55 |
u8 |
| 09:12 |
kaeza |
ah |
| 09:12 |
celeron55 |
(=unsigned char) |
| 09:12 |
kaeza |
yep, that's what I meant :P |
| 09:13 |
celeron55 |
one thing i'm a bit worried about here is that there isn't really anything to facilitate any kind of mod interoperability here, but i guess someone will invent something in lua for that (just like inventory plus or so) |
| 09:14 |
kaeza |
I've been tinkering with that actually |
| 09:14 |
kaeza |
(Lua of course) |
| 09:14 |
|
darkrose joined #minetest-dev |
| 09:14 |
|
darkrose joined #minetest-dev |
| 09:16 |
kaeza |
so, the message would be: u16 command, u8 what, u8 flag |
| 09:31 |
|
darkrose joined #minetest-dev |
| 09:31 |
|
darkrose joined #minetest-dev |
| 09:39 |
|
darkrose joined #minetest-dev |
| 09:39 |
|
darkrose joined #minetest-dev |
| 09:53 |
|
proller joined #minetest-dev |
| 10:07 |
kaeza |
can I add an option to disable default crosshair while I'm at it? |
| 10:07 |
kaeza |
(I mean, as argumnt to hud_builtin_enable() ) |
| 10:21 |
celeron55 |
guess so |
| 10:28 |
kaeza |
ditto for the wield item |
| 10:28 |
kaeza |
(in case someone wishes to implement wielditems as overlay images or whatnot) |
| 10:31 |
celeron55 |
also, don't expect it to get wide usage very fast |
| 10:31 |
|
PilzAdam joined #minetest-dev |
| 10:31 |
celeron55 |
many features i've been implementing or overlooked the implementation of have gained use quite slowly |
| 10:31 |
kaeza |
I know... RBA's background just got started to be used |
| 10:32 |
celeron55 |
(overlook is a stupid word though, that sentence could mean two almost opposite things...) |
| 10:32 |
kaeza |
but at least the stuff is there for the daring modder that wants to try something new |
| 10:32 |
celeron55 |
yes; somebody always needs to set up the framework |
| 10:33 |
celeron55 |
there's always a delay in the momentum that comes from adding some base feature |
| 10:33 |
celeron55 |
people slowly realize what new things they can do |
| 10:44 |
Exio |
kaeza: uhm, what? |
| 10:44 |
Exio |
when you are poiting at something? |
| 10:45 |
kaeza |
Exio, read scrollback |
| 10:46 |
Exio |
kaeza: i don't get it - that is why i ask :P |
| 10:46 |
|
Calinou joined #minetest-dev |
| 10:46 |
Exio |
you mean a function for disabling it from lua, like you can remove and add other hud items? |
| 10:47 |
kaeza |
that |
| 10:47 |
kaeza |
err...no |
| 10:47 |
PilzAdam |
this new "use_texture_alpha" is unusable; with shaders enabled it doesnt work at all and without shaders its extremly glitchy above water |
| 10:47 |
kaeza |
Exio, you'll see soon |
| 10:48 |
Calinou |
no transparency sorting (yet), PilzAdam, that's why it's glitchy, probably |
| 10:48 |
VanessaE |
Calinou: I almost have an update for you for stairsplus, but I need your input on it |
| 10:48 |
Calinou |
while we're talking about rendering stuff, it'd be nice if we have a paramtype "facedir_fixed_texture", like facedir but the texture never rotates |
| 10:49 |
VanessaE |
->#minetest |
| 10:49 |
Calinou |
ah |
| 10:49 |
VanessaE |
and I was *JUST* about to suggest that |
| 10:49 |
Calinou |
ninja'd :P |
| 11:00 |
kaeza |
celeron55, I will need to #include "hud.h" from player.cpp; any objections? |
| 11:05 |
kaeza |
I can move stuff directly to player.h, but would seem out of place there |
| 11:05 |
PilzAdam |
what stuff? |
| 11:05 |
kaeza |
the new defines I added |
| 11:06 |
PilzAdam |
just dont include headers just for class definitions, use "class foo;" instead |
| 11:06 |
PilzAdam |
(in headers, that is) |
| 11:06 |
kaeza |
nope, a bunch of #defines |
| 11:06 |
celeron55 |
why do you need defines there |
| 11:07 |
kaeza |
I don't want to add tons of hud_hotbar_enabled members to Player |
| 11:07 |
celeron55 |
so what do you add? |
| 11:07 |
kaeza |
a simple bitfield |
| 11:08 |
celeron55 |
so you need the #defines for initializing the bitfield by default with the right bits on? |
| 11:08 |
kaeza |
yep |
| 11:08 |
celeron55 |
i guess just put the defines there then; not a big deal as it's the actual storage place of the bits anyway |
| 11:08 |
kaeza |
ok |
| 11:09 |
celeron55 |
or umm... |
| 11:09 |
celeron55 |
do you then need to include player.h in hud.h? |
| 11:09 |
kaeza |
I can just stick a 0xFF in there 8) |
| 11:09 |
celeron55 |
if that is the case, then put them rather in hud.h and include it in player.cpp |
| 11:10 |
kaeza |
ehm... I'll commit and show you |
| 11:12 |
celeron55 |
but the thing here is that hud.h is a huge header because of the headers that are included in there; that means you will never want to include hud.h in any other header |
| 11:13 |
kaeza |
https://github.com/kaeza/minetest/commit/ebdf0f5e67cfc97824b0237113513fd0fdc2eb03 |
| 11:14 |
kaeza |
wrong link |
| 11:14 |
kaeza |
https://github.com/kaeza/minetest/commit/ebdf0f5e67cfc97824b0237113513fd0fdc2eb03#L5R34 |
| 11:15 |
celeron55 |
well that's what you already described |
| 11:15 |
kaeza |
let's see... they are used in player.cpp and hud.cpp |
| 11:17 |
celeron55 |
just let it be like that |
| 11:17 |
celeron55 |
it's not the worst way to do it |
| 11:17 |
celeron55 |
and there's no obvious better way |
| 11:18 |
celeron55 |
(well, adding a small hudtypes.h header would be the trivial lightweight solution) |
| 11:18 |
celeron55 |
(but that's kind of file count bloat then) |
| 11:19 |
kaeza |
would be the a good option |
| 11:20 |
kaeza |
for now lemme test if this actually works, and I'll cocentrate on the details later |
| 11:20 |
celeron55 |
if it works, make a pull request and concentrate on using the end result :P |
| 11:21 |
celeron55 |
(after adding reference to doc/lua_api.txt) |
| 11:23 |
PilzAdam |
celeron55, file bloat? this is file bloat: https://github.com/minetest/minetest/blob/master/src/content_cao.h |
| 11:23 |
celeron55 |
PilzAdam: lol 8) |
| 12:04 |
|
kaeza joined #minetest-dev |
| 12:07 |
|
VanessaE joined #minetest-dev |
| 12:09 |
kaeza |
f*ck yea |
| 12:10 |
Calinou |
lol yea |
| 12:10 |
Calinou |
should be merged in another file, because there is almost nothing in that file :P |
| 12:11 |
kaeza |
err... almost anyway |
| 12:11 |
kaeza |
I cannot disable the crosshair :P |
| 12:11 |
VanessaE |
re: file bloat, heh |
| 12:11 |
kaeza |
lol this looks like minetest-delta without wielditem |
| 12:12 |
|
iqualfragile joined #minetest-dev |
| 12:17 |
Calinou |
why? |
| 12:17 |
Calinou |
minetest-delta's hud was the same as it is currently, pretty much |
| 12:20 |
kaeza |
erhm... I meant 0.2.x |
| 12:20 |
kaeza |
anyway |
| 12:20 |
kaeza |
https://dl.dropboxusercontent.com/u/100008207/screenshot_1006336820.jpg :D |
| 12:21 |
kaeza |
Calinou, https://dl.dropboxusercontent.com/u/100008207/screenshot_1006463337.jpg |
| 12:22 |
kaeza |
I need to write docs and this thing is done |
| 12:24 |
Calinou |
haha, timestamp |
| 12:25 |
Calinou |
you can color text now? |
| 12:25 |
Calinou |
or is this lua-hud only? |
| 12:25 |
Calinou |
(/me would like to see color codes, like ^f0f8 for semi-transparent pink) |
| 12:26 |
kaeza |
Calinou, yep |
| 12:26 |
kaeza |
part of my misc stuff |
| 12:26 |
kaeza |
Calinou, https://github.com/kaeza/minetest-kaeza_misc |
| 12:26 |
kaeza |
see mods/testclock |
| 12:27 |
kaeza |
err... testclock/ |
| 12:35 |
kaeza |
aaaaaand pull requested: https://github.com/minetest/minetest/pull/681 |
| 12:35 |
kaeza |
celeron55, ^ |
| 12:45 |
Calinou |
+1 |
| 12:45 |
Calinou |
useful: disable health bar when in god mode |
| 12:45 |
Calinou |
:P |
| 12:46 |
kaeza |
It's possible now ;) |
| 12:47 |
kaeza |
also, who inv in top-left corner |
| 12:47 |
kaeza |
(somehow) |
| 12:49 |
kaeza |
s/who/draw/ |
| 12:50 |
kaeza |
my hands are derping lately |
| 13:13 |
|
hmmmm joined #minetest-dev |
| 13:17 |
|
ImQ009 joined #minetest-dev |
| 13:58 |
RealBadAngel |
more useful: make HUD minimap |
| 13:59 |
RealBadAngel |
hi all |
| 14:08 |
kaeza |
hey RBA |
| 14:08 |
kaeza |
how's it goin'? |
| 14:14 |
Tracerneo |
RealBadAngel: yeah, it would be cool. How about map item, that will add map in HUD (and other items, like compass, changing HUD)? |
| 14:14 |
|
kaeza1 joined #minetest-dev |
| 14:28 |
celeron55 |
kaeza: it's in now (edited lua_api.txt a bit) |
| 14:30 |
kaeza |
celeron55, ok, thanks ^_^ |
| 14:35 |
PilzAdam |
any objections to change wool crafting from color + white wool to colort + group:wool? |
| 14:36 |
PilzAdam |
-t |
| 14:37 |
|
ecube joined #minetest-dev |
| 14:37 |
PilzAdam |
and it should also be not possible for every player to destroy other player's locked chests if they are emtpy |
| 14:42 |
PilzAdam |
the output should be changed to one colored wool then, instead of 16 |
| 14:57 |
|
Calinou joined #minetest-dev |
| 14:58 |
|
Jordach joined #minetest-dev |
| 15:00 |
|
OWNSyouAll joined #minetest-dev |
| 15:18 |
RealBadAngel |
16 ->1 i agree, but dont touch players properties |
| 15:19 |
RealBadAngel |
this way one will be able to destroy empty chest, machines etc |
| 15:19 |
RealBadAngel |
and some chest are EXPENSIVE |
| 15:19 |
PilzAdam |
currently everyone can dig empty locked chests |
| 15:20 |
PilzAdam |
I want to change it so that only the owner can |
| 15:20 |
RealBadAngel |
maybe wooden |
| 15:20 |
RealBadAngel |
ah so i got you opposite. sure do that |
| 15:21 |
RealBadAngel |
owned and end of story |
| 15:21 |
Jordach |
perhaps steel chests can only be dug by the owner |
| 15:21 |
Jordach |
even when empty |
| 15:22 |
PilzAdam |
Jordach, we dont have steel chests |
| 15:22 |
RealBadAngel |
maybe you :P ;) |
| 15:22 |
PilzAdam |
done |
| 15:26 |
RealBadAngel |
PilzAdam, for glasslike_framed i got all the code almost ready, bugs are dead |
| 15:26 |
RealBadAngel |
i would like to discuss with you (not now, maybe later today) crafting recipes for framed glass |
| 15:28 |
RealBadAngel |
please think about for example wooden and iron framed glass |
| 15:28 |
RealBadAngel |
or maybe you will pop up with another ideas |
| 15:29 |
RealBadAngel |
fyi: frame can have different textures, faces (glass) others |
| 15:30 |
RealBadAngel |
i will be back in 4-5hrs from now on |
| 15:30 |
PilzAdam |
*start timer* |
| 15:30 |
RealBadAngel |
and you start thinkin ;) |
| 15:31 |
RealBadAngel |
cya later aligator :) |
| 15:40 |
|
jojoa1997|Tablet joined #minetest-dev |
| 15:43 |
|
dexter0 joined #minetest-dev |
| 15:45 |
|
jojoa1997|Tablet joined #minetest-dev |
| 15:46 |
|
jojoa1997|Tablet left #minetest-dev |
| 16:00 |
|
rubenwardy joined #minetest-dev |
| 16:01 |
|
kaeza joined #minetest-dev |
| 16:01 |
|
Calinou joined #minetest-dev |
| 16:10 |
|
dexter0 joined #minetest-dev |
| 16:21 |
|
dzho joined #minetest-dev |
| 16:23 |
|
kaeza1 joined #minetest-dev |
| 16:44 |
|
VanessaE joined #minetest-dev |
| 16:49 |
|
ssieb joined #minetest-dev |
| 17:07 |
|
rubenwardy1 joined #minetest-dev |
| 17:22 |
|
troller joined #minetest-dev |
| 17:46 |
|
proller__ joined #minetest-dev |
| 18:03 |
sfan5 |
is there and easy way to clear somebody' inventory in lua? |
| 18:05 |
VanessaE |
sfan5: http://pastebin.com/cYzT0xmm |
| 18:05 |
VanessaE |
(traxie21 wrote that) |
| 18:05 |
sfan5 |
I was just going to ask if :set_list("main", {}) was going to work |
| 18:42 |
|
OWNSyouAll joined #minetest-dev |
| 18:43 |
|
Jordach joined #minetest-dev |
| 18:50 |
|
rubenwardy left #minetest-dev |
| 18:57 |
|
khonkhortisan joined #minetest-dev |
| 19:07 |
|
Jordach1 joined #minetest-dev |
| 19:11 |
|
StrayBytes joined #minetest-dev |
| 19:11 |
|
StrayBytes joined #minetest-dev |
| 19:20 |
|
Jordach2 joined #minetest-dev |
| 19:24 |
|
sapier1 joined #minetest-dev |
| 19:24 |
sapier1 |
did anyone try if my fixes for gxx 4.6 build do work? travis build doesn't seam to start again for additional commits? |
| 19:25 |
|
proller joined #minetest-dev |
| 20:24 |
|
emptty joined #minetest-dev |
| 21:18 |
|
StrayBytes joined #minetest-dev |
| 21:37 |
hmmmm |
eh |
| 21:38 |
hmmmm |
grr |
| 21:40 |
hmmmm |
now i have to make another commit to fix those commits |
| 21:54 |
|
Pentium44 joined #minetest-dev |
| 22:00 |
jin_xi |
what is DecorationDef going to do? |
| 22:06 |
RealBadAngel |
define plants, trees, ores that are biome specific |
| 22:10 |
jin_xi |
oh ok, so not new stuff but a new way to define biomes |
| 22:17 |
RealBadAngel |
exactly |
| 22:24 |
|
mrtux joined #minetest-dev |
| 22:32 |
|
jin_xi joined #minetest-dev |
| 22:58 |
|
Pentium44 joined #minetest-dev |
| 22:58 |
|
Pentium44 joined #minetest-dev |
| 23:28 |
Exio |
would decorationdef work for spawning things inside dungeons? |
| 23:31 |
RealBadAngel |
Exio you should ask hmmmm about it, but propably yeah |
| 23:33 |
Exio |
I didn't want to highlight him :P |
| 23:34 |
ShadowNinja |
Exio: I think I saw that on the TODO list |
| 23:40 |
Exio |
Add Lua callbacks for DungeonGen room placement - this comes with DecorationDef, I reckon |
| 23:40 |
Exio |
k, thanks |
