| Time |
Nick |
Message |
| 00:00 |
RealBadAngel |
i need to test the change first, i may have an idea how to do that |
| 00:00 |
RealBadAngel |
i will play with it on weekend |
| 00:01 |
|
VanessaE joined #minetest-dev |
| 00:01 |
Taoki |
ok |
| 00:01 |
RealBadAngel |
hi VanessaE |
| 00:01 |
hmmmm |
yeah, it looks good |
| 00:02 |
PilzAdam |
https://github.com/PilzAdam/minetest/commit/c5a8448c41e4ea9d33a43cebef61425d4568a46d |
| 00:03 |
PilzAdam |
this works with nil -> not override current setting |
| 00:03 |
Taoki |
Awesome. Looks good |
| 00:03 |
hmmmm |
so you're handling that? |
| 00:03 |
hmmmm |
thank you |
| 00:05 |
hmmmm |
by the way pilzadam, when you commit something that has a pull request, be sure to paste the link to the commit and say something like "done" in a comment then close it |
| 00:05 |
PilzAdam |
random idea: Lua side sprinting :-) |
| 00:05 |
hmmmm |
uh no. |
| 00:05 |
hmmmm |
horrible idea |
| 00:05 |
PilzAdam |
:D |
| 00:05 |
RealBadAngel |
PilzAdam, have you read what i wrote bout creative tools? |
| 00:05 |
VanessaE |
hey RB. |
| 00:05 |
VanessaE |
A. |
| 00:05 |
PilzAdam |
RealBadAngel, what exactly do you want? |
| 00:05 |
hmmmm |
as for the "add support to latest C++ standard" pull request, i dunno, there are lots of compilers that don't support this |
| 00:06 |
RealBadAngel |
imho you shall leave tools intact regardless the game mode |
| 00:06 |
hmmmm |
i don't forsee us using any of those funky language features he was giving examples of |
| 00:06 |
hmmmm |
it's a general rule (in minetest anyway) to make your code really stupid and simple |
| 00:06 |
PilzAdam |
RealBadAngel, what you suggest is that the hand digging time shouldnt be used if the tool doesnt define it |
| 00:06 |
Taoki |
PilzAdam: My change would allow that too :) |
| 00:06 |
hmmmm |
and don't use any super-duper high level C++ constructs |
| 00:06 |
Taoki |
The sprinting I mean |
| 00:07 |
Taoki |
Anyway, need to go to bed since it's late. Waiting for the code to be ready and merged to be sure it's all ok |
| 00:07 |
PilzAdam |
Ill add that to MiniTest :-) |
| 00:07 |
Exio |
hmmmm: please, i need my object-matching-pattern-wtfisthatshit super-OOP things for live!!!!!!!111! |
| 00:07 |
Exio |
hi btw :P |
| 00:07 |
hmmmm |
and jesus christ.. C++11 allows you to overload quotation marks? |
| 00:07 |
RealBadAngel |
PilzAdam, havent checked the code, just noticed fact that diamond swords digs concrete blocks faster than pickaxe |
| 00:07 |
hmmmm |
okay it's beyond saving |
| 00:08 |
PilzAdam |
RealBadAngel, the hand digs stone faster than a pickaxe, so does any tool that doesnt define the cracky group |
| 00:08 |
hmmmm |
thanks to this guy's pull request, i know to specifically disallow C++11 |
| 00:08 |
Taoki |
MiniTest? |
| 00:08 |
PilzAdam |
Ill push that now |
| 00:08 |
Taoki |
ok |
| 00:09 |
PilzAdam |
Taoki, yes, a game by me that copys MC |
| 00:09 |
Exio |
hmmmm: lol |
| 00:09 |
Taoki |
Fun fun |
| 00:09 |
RealBadAngel |
PilzAdam, that should be somehow fixed then |
| 00:09 |
PilzAdam |
the creative mode isnt meant to use tools |
| 00:10 |
Exio |
what about the cosmetic fix for infinite tools? |
| 00:10 |
Exio |
the stacks are already infinite, i don't see the "why not" of that |
| 00:10 |
PilzAdam |
anything else that requires a protocol version bump? |
| 00:10 |
Exio |
as it is just cosmetic |
| 00:10 |
RealBadAngel |
folks sometimes want to play legacy on creative servers |
| 00:10 |
RealBadAngel |
go on VanessaE server and see |
| 00:11 |
Taoki |
PilzAdam: Thanks PilzAdam. Tomorrow I'll fix the ladder speed too since that's something else a lot of people complained about |
| 00:11 |
Taoki |
Night |
| 00:12 |
RealBadAngel |
night Taoki |
| 00:12 |
PilzAdam |
hmmmm, I have this MC like sand falling (with a little delay when updating) and VanessaE said it is awesome |
| 00:13 |
PilzAdam |
it doesnt add thousands of entities at once when digging a huge amount of flying sand |
| 00:13 |
PilzAdam |
and it looks pretty nice |
| 00:13 |
PilzAdam |
https://github.com/PilzAdam/minetest/commit/ea9fd59f2bce8d8a31f7bd4a952564faa0629441 |
| 00:13 |
VanessaE |
works on gravel too |
| 00:13 |
VanessaE |
other falling nodes also, I'm sure. |
| 00:14 |
hmmmm |
PilzAdam, sure, doesn't really matter to me though |
| 00:14 |
hmmmm |
if you (actual minetest players) like it, then I guess add it |
| 00:15 |
hmmmm |
just make sure others agree with it |
| 00:15 |
hmmmm |
those are gameplay tweaks I can't really comment at all on |
| 00:15 |
Exio |
https://github.com/sfan5/minetest/commit/30d029814ef5f0680510146d0e4b72bccd1bae50 |
| 00:15 |
Exio |
i would like to see this |
| 00:16 |
PilzAdam |
hmmmm, it acutally isnt a gameplay tweak |
| 00:16 |
PilzAdam |
Exio, it turned out that you cant apply more than one shader to a material IIRC |
| 00:16 |
Exio |
ehm |
| 00:17 |
PilzAdam |
http://irc.minetest.ru/minetest-dev/2013-04-04#i_2984467 |
| 00:19 |
Exio |
oh |
| 00:20 |
Exio |
as doing the stuff, what do you think about https://github.com/minetest/minetest/pull/578 ? (it will make the "look" of the IRC-mod and others similar mods "better" |
| 00:21 |
PilzAdam |
seems ok to me |
| 00:22 |
hmmmm |
https://github.com/minetest/minetest/pull/596#issuecomment-15932423 |
| 00:23 |
Exio |
upgrade your compiler hmmmm |
| 00:24 |
Exio |
the last gcc is super cooler(tm) |
| 00:24 |
hmmmm |
in order for me to allow merging something, it'd have to *work* for me in the first place |
| 00:24 |
hmmmm |
and I know it'd cause problems for other freebsd users |
| 00:25 |
hmmmm |
freebsd is a tier-1 supported platform for minetest |
| 00:25 |
PilzAdam |
pushed the mc like sand falling |
| 00:25 |
hmmmm |
meaning it _has_ to work on there, or else there's a problem |
| 00:26 |
PilzAdam |
hmmmm, I fixed the nick completion fix to not copy the list all the time: https://github.com/PilzAdam/minetest/commit/f245c6dc18e2b84d480209b64fec1fdfa8262a92 |
| 00:26 |
hmmmm |
i saw that |
| 00:26 |
jordan4ibanez |
delay in node_update, won't that cause a lot of problems? |
| 00:26 |
PilzAdam |
(yes, I fix fixes :-)) |
| 00:26 |
hmmmm |
why not push it? |
| 00:26 |
jordan4ibanez |
why not a slow_node_update instead?? |
| 00:27 |
VanessaE |
PilzAdam: how short of a delay can you use and still have it work? |
| 00:27 |
PilzAdam |
hmmmm, If you are ok with it now Ill push it |
| 00:27 |
VanessaE |
(for the falling code) |
| 00:27 |
hmmmm |
hmm |
| 00:27 |
PilzAdam |
well, It had a delay of 0 and it worked, so this question isnt very good |
| 00:28 |
VanessaE |
I ask because I'm concerned about those 0.1s delays adding up and causing lag is all. |
| 00:28 |
PilzAdam |
I wouldnt call it "lag" |
| 00:28 |
hmmmm |
it creates a nodetimer for each falling node, doesn't it |
| 00:28 |
hmmmm |
that has potential to be bad if there's a large amount of nodes that start falling at once |
| 00:28 |
PilzAdam |
hmmmm, no, it just queues them in globalstep |
| 00:28 |
hmmmm |
ah |
| 00:29 |
jordan4ibanez |
That's cool! |
| 00:29 |
PilzAdam |
Ill push the nick completion now |
| 00:29 |
|
jordan4ibanez left #minetest-dev |
| 00:29 |
hmmmm |
oh shoot |
| 00:29 |
VanessaE |
PilzAdam: re: nick completion, does that work in the 't' command line yet? |
| 00:29 |
hmmmm |
there was something about that i wanted to make sure of before you push it |
| 00:29 |
PilzAdam |
VanessaE, nope |
| 00:29 |
VanessaE |
damn. |
| 00:29 |
hmmmm |
you changed something from a wstring to a string |
| 00:29 |
VanessaE |
that would be incredibly handy to have. |
| 00:29 |
hmmmm |
are you sure that's correct? |
| 00:30 |
PilzAdam |
player names are send to the client as std::string |
| 00:31 |
PilzAdam |
so I keep it in the env as a string and change it to wsring when passing it to Irrlicht |
| 00:31 |
hmmmm |
ah, it's irrlicht that expects the wstring |
| 00:32 |
PilzAdam |
also, hmmmm, what do you think about the "Server -!-" prefix for chat_send_player()? |
| 00:33 |
hmmmm |
i don't know |
| 00:33 |
hmmmm |
that prefix was put there for a reason |
| 00:33 |
Exio |
or at least making it less annoying for short messages or relays |
| 00:33 |
hmmmm |
it's good to know what messages are coming from the server though |
| 00:34 |
hmmmm |
maybe server messages could be drawn with a slightly different colored font |
| 00:34 |
Exio |
-S- from the server? or something what is shorter than the word + signs |
| 00:34 |
PilzAdam |
as a modder, I think its very annoying |
| 00:34 |
PilzAdam |
Exio, nobody would understand that :-= |
| 00:34 |
PilzAdam |
*:-) |
| 00:34 |
hmmmm |
is that possible, though, the way the font works with irrlicht? |
| 00:34 |
hmmmm |
if it is, i'd remove the prefix and change the coloring |
| 00:34 |
PilzAdam |
wtf |
| 00:35 |
PilzAdam |
github has a new GUI for pull requests |
| 00:35 |
hmmmm |
yeah i saw |
| 00:35 |
hmmmm |
it's what websites do |
| 00:35 |
hmmmm |
they change things for the sake of changing things, not like it's being made better at all |
| 00:35 |
VanessaE |
font? push my bigger, sharper one ;) |
| 00:35 |
hmmmm |
vanessae, not until the culling issues are fixed |
| 00:35 |
PilzAdam |
VanessaE, we have TTF now |
| 00:35 |
hmmmm |
also that |
| 00:35 |
PilzAdam |
just install your own if you like to |
| 00:36 |
VanessaE |
ttf sucks |
| 00:36 |
VanessaE |
no shadowing. |
| 00:36 |
VanessaE |
hmmmm: culling issues? you mean kerning right? |
| 00:36 |
PilzAdam |
you even have a font_size setting for ttf fonts ((c) PilzAdam) |
| 00:36 |
hmmmm |
kerning yeah |
| 00:36 |
VanessaE |
hmmmm: right. I agree on that point. Forgot about that issue actually. |
| 00:36 |
hmmmm |
but i agree, the main purpose of the font change is to add that border for readaibility |
| 00:37 |
hmmmm |
so increasing the font size of what's already there won't really help |
| 00:37 |
hmmmm |
can we have a shadow? |
| 00:37 |
hmmmm |
what if we write the same string twice, one in black, offset by 1+1 pixel? |
| 00:37 |
hmmmm |
i'd actually rather not do that, i'm just throwing stupid ideas out there |
| 00:38 |
VanessaE |
hmmmm: you'd need to actually outline the whole font |
| 00:38 |
VanessaE |
a 1x1 offset only shadows part of it, wouldn't work in practive |
| 00:38 |
VanessaE |
practice* . I tried already. |
| 00:39 |
PilzAdam |
oh fuck, its too late again :-( |
| 00:42 |
VanessaE |
? |
| 00:42 |
VanessaE |
oh |
| 00:42 |
VanessaE |
<PilzAdam> bye |
| 00:42 |
PilzAdam |
how about that one? https://github.com/PilzAdam/minetest/commit/2126bf06d20f6cb5bb6a0dbe728923b228d5c5cb |
| 00:42 |
VanessaE |
(kidding) |
| 00:42 |
VanessaE |
mm |
| 00:42 |
VanessaE |
you need to widen the list box for that |
| 00:43 |
VanessaE |
well, maybe not actually. |
| 00:44 |
VanessaE |
in my particular use case, doing that would cause about half the entries in my worlds list to run out past the right margin |
| 00:44 |
PilzAdam |
even minimal with the long name fits into it |
| 00:44 |
PilzAdam |
and it is hardly at the half |
| 00:44 |
VanessaE |
probably not a real concern then |
| 00:44 |
PilzAdam |
(with the worldname being "minimal") |
| 00:46 |
PilzAdam |
well, its a bit more critical in the advanced tab |
| 00:47 |
PilzAdam |
but using the foldername instead of the actual gamename is stupid IMO |
| 00:47 |
|
dexter0 joined #minetest-dev |
| 00:48 |
PilzAdam |
hmmmm, what do you think? |
| 00:59 |
hmmmm |
i think we shouldn't take up unnecessary space |
| 01:00 |
hmmmm |
i just hope it isn't too wide |
| 01:02 |
|
salamanderrake joined #minetest-dev |
| 01:11 |
|
mrtux_ joined #minetest-dev |
| 01:28 |
|
mrtux joined #minetest-dev |
| 01:28 |
|
mrtux joined #minetest-dev |
| 01:33 |
hmmmm |
hah wow |
| 01:33 |
hmmmm |
https://github.com/Bukkit/mc-dev/blob/master/net/minecraft/server/BiomeBase.java |
| 01:33 |
hmmmm |
coincidentially, i limited the number of biomes to 256 too |
| 01:33 |
Exio |
i will not open *that* file |
| 01:34 |
hmmmm |
except the first one is occupied by a "default" biome that exists no matter what |
| 01:34 |
VanessaE |
I can't see us needing more than a dozen biomes anyway |
| 01:34 |
hmmmm |
and it seems that they have something that's similar to DecorationDef, and they call it BiomeDecorator |
| 01:34 |
hmmmm |
i want to check that out, i want to know if it really is what i think it is, and if they do the placement like i do too |
| 01:35 |
hmmmm |
nevertheless, i'm going to try to rip their biome temperature/humidity settings so we have something that doesn't need balancing |
| 01:36 |
hmmmm |
it might be tougher than that, because i don't do the max/min like they do |
| 01:38 |
hmmmm |
also i think the mushroom island idea is stupid and i'll omit that biome altogether |
| 01:38 |
hmmmm |
https://github.com/Bukkit/mc-dev/blob/master/net/minecraft/server/BiomeHell.java gotta really love Java with their one-class-per-file restriction |
| 01:39 |
Exio |
oh god, stop posting links what finish with .java |
| 01:39 |
hmmmm |
you'll live |
| 01:39 |
Exio |
if i open those links i'm sure i'll start bleeding |
| 01:48 |
hmmmm |
sand, gravel, ore, flowers, mushrooms, huge mushrooms, reed, cactus, waterlilly |
| 01:49 |
hmmmm |
they handle trees separately for some reason, it seems |
| 01:50 |
VanessaE |
oh G*d no, not those huge mushrooms |
| 01:50 |
VanessaE |
what idiot thought those made even a lick of sense? |
| 01:51 |
VanessaE |
oh wait, Notch did. ;) |
| 01:51 |
Exio |
the only thing what i miss of MT actually is the nether (as the only think i do in MC actually, is playing in the nether) |
| 01:51 |
hmmmm |
or probably one of the designers he employed |
| 01:52 |
Exio |
i don't like them for the mushrooms, but mobs can't spawn in those biomes |
| 01:52 |
ShadowNinja |
I like how descriptive calling a() is |
| 01:52 |
Exio |
(on those?) |
| 01:52 |
hmmmm |
it's not hard to do that |
| 01:52 |
Exio |
hmmmm: yep, just saying "what i see is good for those biomes" :P |
| 01:53 |
ShadowNinja |
you can use multiple characters for variables! |
| 01:53 |
hmmmm |
when it comes time for mobs, we'll just leave some biomes without them |
| 01:53 |
hmmmm |
shadowninja, that's not really the source, that's just decompiled |
| 01:53 |
Exio |
the code of bukkit is "de-ofuscated" code |
| 01:53 |
Exio |
er, that |
| 01:54 |
Exio |
the *real* code is not available for public |
| 01:54 |
ShadowNinja |
hmm, ok fine |
| 01:56 |
hmmmm |
the way they do beaches is kind of smart |
| 01:56 |
hmmmm |
https://github.com/Bukkit/mc-dev/blob/master/net/minecraft/server/WorldGenSand.java |
| 01:57 |
hmmmm |
pick a random radius, at least 2, replace all the blocks around that are water to be sand |
| 01:57 |
hmmmm |
doesn't require any perlin noise that way |
| 01:59 |
hmmmm |
and the way they do nether is different from what i expected, and i'd have to say more difficult.. i'm pretty sure negative 3d perlin noise space would've worked just as well |
| 02:03 |
hmmmm |
oh, ahh, those pieces are for the nether fortress, not the nether itself |
| 02:03 |
hmmmm |
that's an interesting approach to procedurally generating large structures, but i'd have to say ultimately boring. L-systems beat this |
| 03:20 |
|
kaeza1 joined #minetest-dev |
| 04:12 |
VanessaE |
hrm. the "build" and "survival" games are not included in the 'make install' step? |
| 04:37 |
kaeza |
aren't they installed separately just as minetest_game? |
| 04:38 |
VanessaE |
well they can be, but minetest_game is covered when you `make install` |
| 04:41 |
VanessaE |
I kinda figured the other two would be also. |
| 04:49 |
kaeza |
then that is inconsistent at least |
| 04:49 |
VanessaE |
yes. |
| 04:50 |
VanessaE |
I'd like my builds to include those two games, but it's not possible without help from one of the upstream devs. I don't understand shit when it comes to makefiles :) |
| 04:53 |
|
kaeza1 joined #minetest-dev |
| 04:57 |
kaeza1 |
https://github.com/minetest/minetest/pull/600 |
| 04:58 |
VanessaE |
\o/ |
| 04:58 |
kaeza |
hope that helps |
| 04:59 |
kaeza |
;) |
| 04:59 |
VanessaE |
cherry-picked. |
| 04:59 |
kaeza |
fux |
| 04:59 |
kaeza |
forget about that |
| 04:59 |
VanessaE |
let's see what THIS breaks |
| 04:59 |
VanessaE |
shit. |
| 04:59 |
VanessaE |
ok |
| 04:59 |
kaeza |
I meant to edit my repo, and edited minetest master instead |
| 05:00 |
kaeza |
sorry about that |
| 05:00 |
VanessaE |
reverted. |
| 05:00 |
VanessaE |
eh? it looks to me like it's on your repo? |
| 05:03 |
kaeza |
ah sorry lol I meant the pull request |
| 05:03 |
kaeza |
https://github.com/kaeza/minetest/commit/2de3956cb0787231d87e79cff0178d60af8ac764 |
| 05:04 |
kaeza |
can you test that? |
| 05:04 |
VanessaE |
sure, sec |
| 05:05 |
kaeza |
I forgot to change line 153 to .../survival in the previous one |
| 05:05 |
VanessaE |
ah |
| 05:05 |
VanessaE |
running it through my regular build script, let's see what this breaks ;) |
| 05:05 |
* kaeza |
crosses fingers |
| 05:07 |
VanessaE |
hrm, something didn't work. |
| 05:07 |
VanessaE |
lemme check my script. |
| 05:09 |
kaeza |
what's the error? |
| 05:09 |
VanessaE |
my script didn't install minetest_game et.al before cmake was executed. |
| 05:09 |
kaeza |
ah |
| 05:09 |
VanessaE |
re-running it now with that change. |
| 05:10 |
kaeza |
I'll need to rework that change to use a foreach loop |
| 05:10 |
kaeza |
may be useful in case someone decides to add new "standard" games in the future |
| 05:10 |
VanessaE |
eh, leave it unrolled |
| 05:11 |
VanessaE |
make install coming up in seconds... *crosses fingers* |
| 05:11 |
VanessaE |
\o/ |
| 05:11 |
kaeza |
success? |
| 05:11 |
VanessaE |
I see all four components in the make install spew |
| 05:11 |
kaeza |
\o/ |
| 05:11 |
kaeza |
make pull request? |
| 05:11 |
VanessaE |
hold, let me verify it |
| 05:14 |
VanessaE |
I think it's good |
| 05:14 |
VanessaE |
uploading the build to my web space now. |
| 05:14 |
kaeza |
ok |
| 05:14 |
VanessaE |
http://forum.minetest.net/viewtopic.php?pid=81578#p81578 |
| 05:15 |
VanessaE |
can you double-check the output? |
| 05:15 |
kaeza |
sure |
| 05:22 |
VanessaE |
*waits* |
| 05:23 |
kaeza |
still building... |
| 05:23 |
kaeza |
I usually compile with RUN_IN_PLACE |
| 05:23 |
VanessaE |
ok |
| 05:28 |
kaeza |
success! |
| 05:29 |
VanessaE |
\o/ |
| 05:29 |
VanessaE |
pull-request that sucker. :) |
| 05:35 |
|
ecube joined #minetest-dev |
| 05:40 |
kaeza |
I need some help with this |
| 05:41 |
VanessaE |
I always do that from the website |
| 05:41 |
kaeza |
I accidentally pushed to my master branch, but I already have a pull rq for it |
| 05:41 |
VanessaE |
that's ok, it'll get refreshed to the new code. |
| 05:41 |
kaeza |
no I mean, the pull is for another unrelated thing |
| 05:41 |
VanessaE |
oh |
| 05:42 |
VanessaE |
then you'll have to push the change to a different branch and pull-request that against upstream master |
| 05:42 |
VanessaE |
https://github.com/minetest/minetest/pull/593 |
| 05:42 |
kaeza |
I did that, but now all the changes (including the commit in the open pull) are in it |
| 05:42 |
VanessaE |
there it is. |
| 05:43 |
VanessaE |
in that case you have to revert your commit and push -f |
| 05:43 |
kaeza |
you know what? I'll nuke and reclone |
| 05:43 |
VanessaE |
or just clo....... |
| 05:43 |
VanessaE |
or do that. |
| 05:43 |
VanessaE |
:D |
| 05:43 |
kaeza |
:P |
| 05:54 |
kaeza |
https://github.com/minetest/minetest/pull/601 |
| 05:54 |
kaeza |
:D |
| 05:54 |
* kaeza |
is starting to love rm -fr |
| 05:54 |
VanessaE |
heh |
| 05:57 |
celeron55 |
Taoki|away: why did you add the implementation and declaration of gob_cmd_update_physics_override to that position in the file while all the others were in the same order as in the enum? https://github.com/minetest/minetest/commit/c5a8448c41e4ea9d33a43cebef61425d4568a46d |
| 05:58 |
celeron55 |
(actually not enum but bunch of #defines but anyway) |
| 06:02 |
|
nyuszika7h_ joined #minetest-dev |
| 06:03 |
VanessaE |
kaeza: better. :) |
| 06:04 |
kaeza |
hah. that's the powa of git push -f! |
| 06:04 |
VanessaE |
hehe |
| 06:05 |
kaeza |
and now back to my side-project of bringing Puppy builds up to date |
| 06:06 |
VanessaE |
cool |
| 06:06 |
kaeza |
latest in the repos is 0.4.3 :/ |
| 06:07 |
VanessaE |
better than the ubuntu repos, which still hold 0.3.x |
| 06:52 |
|
ImQ009 joined #minetest-dev |
| 06:54 |
|
BackupCoder joined #minetest-dev |
| 08:53 |
|
Calinou joined #minetest-dev |
| 08:57 |
|
Calinou joined #minetest-dev |
| 09:05 |
|
serengeor joined #minetest-dev |
| 09:27 |
|
ImQ009 joined #minetest-dev |
| 09:38 |
|
Calinou joined #minetest-dev |
| 09:40 |
|
Calinou_ joined #minetest-dev |
| 09:52 |
|
troller joined #minetest-dev |
| 10:16 |
|
Taoki joined #minetest-dev |
| 10:34 |
Taoki |
celeron55: Thought I added the new function exactly like all others. At least that was my intention |
| 10:37 |
Taoki |
Aaah... the #define stuff. Yeah... I added that one at the bottom cuz you said not to invert and modify numbers any more. Else I could have centered it as well |
| 10:38 |
Taoki |
I tend to prefer adding things in the order that makes sense, not necessarily "newest at the bottom". I'm too perfectionist when coding xD |
| 10:39 |
Taoki |
You can re-arrange it in the enum too if it's safe, but I think that's where you said never to modify old numbers cuz it breaks previous clients. Yeah... I should have just added everything new to the bottom really |
| 10:43 |
|
PilzAdam joined #minetest-dev |
| 10:54 |
|
proller joined #minetest-dev |
| 10:57 |
|
kaeza joined #minetest-dev |
| 11:09 |
|
jojoa1997|Tablet joined #minetest-dev |
| 11:20 |
|
jojoa1997_Tablet joined #minetest-dev |
| 11:22 |
|
jojoa1997|Tablet joined #minetest-dev |
| 11:29 |
|
jojoa1997_Tablet joined #minetest-dev |
| 11:29 |
|
ImQ009 joined #minetest-dev |
| 11:43 |
|
jojoa1997_Tablet left #minetest-dev |
| 11:46 |
|
Calinou joined #minetest-dev |
| 11:47 |
|
Jordach joined #minetest-dev |
| 11:47 |
|
Jordach joined #minetest-dev |
| 12:40 |
|
rarkenin_ joined #minetest-dev |
| 12:48 |
Taoki |
celeron55, PilzAdam: I fixed the aux1_descends problem that everyone was complaining about. https://github.com/minetest/minetest/pull/603 |
| 12:48 |
Taoki |
The fast movement on ladders problem |
| 12:49 |
Taoki |
VanessaE: ^ |
| 12:49 |
PilzAdam |
localplayer.cpp:192 this line is way too long |
| 12:50 |
Taoki |
Never heard about lines which are too long before :P Relocate the comment at the end in that case |
| 12:50 |
PilzAdam |
lines shouldnt contain more than 80 chars and ~100 is the maximum |
| 12:51 |
Taoki |
That comment is important so people always know exactly why it's done that way. But move it if needed |
| 12:53 |
Taoki |
Anyway I tested locally both with and without aux1_descends and it works as intended |
| 12:57 |
PilzAdam |
yes, it works |
| 12:59 |
PilzAdam |
also this commit message is too long |
| 13:00 |
Taoki |
Aaaargh :P |
| 13:00 |
Taoki |
Even that is harmful |
| 13:00 |
PilzAdam |
pushed |
| 13:01 |
Taoki |
thanks. For the future I'll try to keep stuff shorter if it's important |
| 13:21 |
|
hmmmm joined #minetest-dev |
| 13:24 |
|
iqualfragile joined #minetest-dev |
| 13:38 |
|
serengeor joined #minetest-dev |
| 13:39 |
Taoki |
I wonder if anyone else things we should have mapgen floating islands by default in minetest_game... |
| 13:39 |
Taoki |
**thinks |
| 13:39 |
Taoki |
Tried out the floatlands mod and it's beautiful. Really wouldn't harm to have it default. |
| 13:39 |
Taoki |
Once it's no longer so layyg and slow to generate that is |
| 13:40 |
PilzAdam |
use mg_name = indev |
| 13:40 |
PilzAdam |
it has floating islands |
| 13:46 |
PilzAdam |
anything against this? https://github.com/minetest/minetest/pull/553 |
| 13:48 |
RealBadAngel |
nothing |
| 13:49 |
Jordach |
no problems in my eyes |
| 13:50 |
Taoki |
nope, looks good |
| 13:51 |
Taoki |
And what's mg_name - indev? Where and what is that? |
| 13:51 |
PilzAdam |
its a setting in minetest.conf |
| 13:51 |
RealBadAngel |
Taoki it shall be "nAsWs/c&aux1_d is on" |
| 13:52 |
RealBadAngel |
and everybody will know from start what you meant ;) |
| 13:52 |
Taoki |
oh, ok. What does it do exactly? |
| 13:54 |
Taoki |
What is mg_name = indev exactly though? It enables experimental features in the code? |
| 13:55 |
PilzAdam |
we have support for mutlitple map generators in the engine |
| 13:55 |
PilzAdam |
the default is mg_v6 |
| 13:55 |
PilzAdam |
indev is the playground of proller |
| 13:56 |
Taoki |
oh nice |
| 13:57 |
Taoki |
Still unclear what the statuus is on defining biomes in LUA btw. And getting rid of things like alias_dirt / alias_sand / etc. Of course while the mapgen stays in C++ |
| 13:58 |
PilzAdam |
hmmmm is working on magpen v7 |
| 13:58 |
PilzAdam |
it will have all this register_biome() stuff |
| 13:58 |
Taoki |
Awesome! |
| 14:00 |
Taoki |
Hoping it would be something like "define areas where these types of nodes are used, and have this amount of caves, tunnels, rivers, etc" |
| 14:01 |
Taoki |
Also, I find the indev mapgen a lot prettier :) |
| 14:02 |
Taoki |
It generates some amazing places. Default mapgen does too but this one even better |
| 14:02 |
Taoki |
However, before I see floating islands I see a few floating trees. And no, not in the good sense :P |
| 14:02 |
Taoki |
(very rarely still) |
| 14:03 |
PilzAdam |
the only difference is that it has larger mountains at the edge and floating islands |
| 14:04 |
proller |
and CAVES |
| 14:05 |
proller |
and biomes larger |
| 14:06 |
Taoki |
I'm quite above cloud height and see no islands though |
| 14:06 |
PilzAdam |
you have to go to 500+ |
| 14:06 |
proller |
500+ - very rare |
| 14:06 |
proller |
30000 - more islands |
| 14:07 |
proller |
go to "sky hardcore" server - |
| 14:07 |
Taoki |
Wow, that's way high >.< |
| 14:07 |
proller |
spawn at 30000 |
| 14:07 |
Taoki |
How do you do that? |
| 14:07 |
proller |
what ? |
| 14:08 |
proller |
static_spawnpoint = 15,29539,-8 |
| 14:08 |
proller |
mg_name = indev |
| 14:08 |
|
rarkenin joined #minetest-dev |
| 14:08 |
PilzAdam |
what mods do you have there? |
| 14:08 |
Taoki |
Also, MineTest seems to be bacly lagging the system when in view. Can barely even alt-tab switch although it's windowed |
| 14:08 |
proller |
bones elevator minetest-teleporters moretrees nuke plants_lib sponge tnt |
| 14:09 |
Taoki |
proller: I meant how to teleport at that height |
| 14:09 |
proller |
/teleport 0,30000,0 |
| 14:10 |
Taoki |
thanks, worked |
| 14:10 |
Taoki |
Hmm. Could mods make floating islands be made out of other materials than classic dirt and stone? Also, can you change the spawn height of islands? |
| 14:12 |
|
Jordach joined #minetest-dev |
| 14:12 |
|
Jordach joined #minetest-dev |
| 14:12 |
proller |
# Float islands starts from height, 0 to disable |
| 14:12 |
proller |
#mgindev_float_islands = 500 |
| 14:13 |
proller |
about adding new materials - ask PilzAdam |
| 14:14 |
Taoki |
ok |
| 14:15 |
proller |
i think about some kinds of float lands, maybe something like walkable clouds |
| 14:15 |
proller |
and like asteroids from stone or metal |
| 14:38 |
Taoki |
Trees with black leafs are a nice species of tree that got implemented in MineTest ;) |
| 14:38 |
|
Guest27058 joined #minetest-dev |
| 14:39 |
|
kaeza joined #minetest-dev |
| 14:40 |
kaeza |
I see you are not able to build the executables into a directory different than the source dir; minetest and minetestserver are always output to minetest/bin |
| 14:40 |
kaeza |
is there any particular reason for this? |
| 14:41 |
kaeza |
I see you are not able to build the executables into a directory different than the source dir; minetest and minetestserver are always output to minetest/bin |
| 14:41 |
kaeza |
derp |
| 14:41 |
kaeza |
I see you are not able to build the executables into a directory different than the source dir; minetest and minetestserver are always output to minetest/bin |
| 14:41 |
kaeza |
I'm editing the CMakeLists.txt file to be able to do it, but asking just in case |
| 14:50 |
|
Calinou joined #minetest-dev |
| 14:50 |
Jordach |
afternoon Calinou |
| 14:53 |
|
Zeg9 joined #minetest-dev |
| 15:00 |
|
rubenwardy joined #minetest-dev |
| 15:06 |
proller |
about floatlands - now we cant build stairs down |
| 15:06 |
|
rubenwardy left #minetest-dev |
| 15:08 |
proller |
you cant buld anything below lower block of float land |
| 15:11 |
kaeza |
can someone test this: https://github.com/kaeza/minetest/commit/70a23c2a7898df310b651cc4cf1a50bddb7ba2d6 |
| 15:11 |
proller |
http://paste.org.ru/?9sk33e |
| 15:11 |
kaeza |
I tested and works as expected |
| 15:15 |
PilzAdam |
proller, you can, with water and lava |
| 15:15 |
proller |
where get water or lava in sky? |
| 15:16 |
PilzAdam |
doesnt it spawn there? |
| 15:17 |
proller |
i tested some water springs at sky, but now waiting hmmmm while he fix ore gen with param1 param2 |
| 15:18 |
proller |
and springs make now very good lakes in air above unloaded blocks |
| 15:18 |
proller |
not good |
| 15:20 |
proller |
possible fix - delete liquid when it falls on unloaded node |
| 15:20 |
proller |
above sea level only |
| 15:20 |
PilzAdam |
there was a fix for it IIRC |
| 15:25 |
Calinou |
proller: suggestion: add nodes that do 20 damage per second below floating island |
| 15:25 |
Calinou |
16 layers of them or so :P |
| 15:27 |
celeron55 |
Taoki: you didn't understand at all; it's not about what the code does; it's a bout how it's organized |
| 15:27 |
celeron55 |
-" " |
| 15:27 |
Jordach |
about* |
| 15:30 |
proller |
Calinou, for what? you die if fall anyway, but now is bug - you can stop while falling, and land on next island with low speed |
| 15:32 |
Calinou |
stop thinking like a debian user; it takes way too long to die |
| 15:32 |
Calinou |
or bundle a /kill command with your mod :P |
| 15:36 |
celeron55 |
the the fuck kind of new spam is this http://paste.dy.fi/9zr |
| 15:36 |
Calinou |
lol :D |
| 15:43 |
Jordach |
celeron55, huh, changing from viagra (with virus) to now mobile phone games which read your address book and spam the fuck out of you and your friends |
| 15:56 |
celeron55 |
i consider anyone who install such a game very stupid |
| 15:57 |
celeron55 |
also, i've always wondered how the viagra crap can possibly spread any computer viruses |
| 15:57 |
celeron55 |
like... do people, like, think at all? |
| 15:58 |
Jordach |
celeron55, not anymore, this is the age of instant gratificartion |
| 15:58 |
Jordach |
-r |
| 15:58 |
Jordach |
where people are essentially sheep |
| 16:02 |
celeron55 |
i've always wondered if i should make a re-branded "minetest for sheep" |
| 16:02 |
celeron55 |
it could be a hit |
| 16:02 |
celeron55 |
:D |
| 16:04 |
Jordach |
celeron55, go ahead |
| 16:05 |
|
dexter0 joined #minetest-dev |
| 16:09 |
celeron55 |
it'd need to be a very stripped down and polished version with some very simple focus and a installer that is closer a virus than an actual legit installer |
| 16:11 |
celeron55 |
i'm supportive of this as an experiment; but not really ideologically |
| 16:11 |
Jordach |
see how dumb people are by giving a zipfile which just contains a link to a survey download |
| 16:12 |
Jordach |
(some download sites have the downloader to answern surveys which never answer) |
| 16:13 |
kaeza |
point them to this: http://nooooooooooooooo.com/ |
| 16:13 |
* Jordach |
claps |
| 16:53 |
|
rubenwardy joined #minetest-dev |
| 17:10 |
Taoki |
celeron55: Yeah. I meant I like to keep it clean and organize everything in order, but I should have added this at the bottom instead |
| 17:17 |
celeron55 |
yes, that is what i mean; while the code does what it should, it's not in perfect order while it could as well be |
| 17:18 |
PilzAdam |
why isnt launchpad updated to 0.4.6 yet? |
| 17:18 |
celeron55 |
because i haven't remembered |
| 17:19 |
celeron55 |
probably somebody other should register there and let me teach how to use it |
| 17:20 |
celeron55 |
also, launchpad isn't updated to have tracking bazaar repos for the other games |
| 17:20 |
celeron55 |
it needs to be done via support tickets |
| 17:20 |
|
rubenwardy1 joined #minetest-dev |
| 17:21 |
celeron55 |
launchpad is a fucking pain overally, i don't really understand why i try to tolerate it |
| 17:21 |
celeron55 |
anyway, i'll make it make a 0.4.6 with minetest_game |
| 17:22 |
Taoki |
celeron55: Anyway, I fxied the annoying ladder speed problem today. Sorry it took so long, but now everything's fine at last for aux1_descends users :) |
| 17:24 |
celeron55 |
Taoki: i saw that |
| 17:24 |
celeron55 |
haven't tried yet though |
| 17:25 |
Taoki |
Thinking of other things for the engine and which of them I can help with doing |
| 17:26 |
celeron55 |
actually... now that i think of it, i think you *can* make tracking repos in bazaar via an online form; it's the changing of them that needs support tickets |
| 17:26 |
Taoki |
BTW, tried the floating islands for the first time (the C++ ones in the dev mapgen). Really lovely stuff, can't wait for them to be defaulted on :) |
| 17:26 |
celeron55 |
but eh, no, i'm not going to do that |
| 17:27 |
celeron55 |
why can't launchpad support plain git repos and get stuff based on tags in them; it would be like million times easier |
| 17:30 |
Taoki |
Who handles the mapgen floatislands BTW? I have a suggestion if they're around |
| 17:30 |
Taoki |
(haven't seen a forum topic for these, just for the LUA floatlands mod) |
| 17:32 |
celeron55 |
i think proller is the one messing around with the "indev" mapgen |
| 17:32 |
|
rubenwardy joined #minetest-dev |
| 17:33 |
celeron55 |
yeah, the forum isn't really used for core stuff development, except by some people |
| 17:33 |
proller |
its port of floatlands mod with minor changes |
| 17:33 |
celeron55 |
this channel and github are better for tracking such |
| 17:34 |
proller |
but dislike this algorithm, it uses 3 differend perlins, but islandg looks good |
| 17:35 |
proller |
ups, misses.. |
| 17:36 |
Taoki |
oh, ok :) |
| 17:36 |
PilzAdam |
celeron55, I have set up an launchpad account |
| 17:37 |
Taoki |
proller: My question was if you could add water to float islands too. In some cases near the edge, so that waterfalls will go down and even reach the ground eventually (might not happen due to the huge distance but still) |
| 17:38 |
proller |
^^^ <proller> and springs make not very good lakes in air above unloaded blocks |
| 17:38 |
proller |
^^^ <proller> i tested some water springs at sky, but now waiting hmmmm while he fix ore gen with param1 param2 |
| 17:39 |
proller |
springs was broken in new oregen |
| 17:39 |
proller |
but possible add with old lua function |
| 17:39 |
|
rubenwardy1 joined #minetest-dev |
| 17:39 |
|
rubenwardy1 left #minetest-dev |
| 17:41 |
Taoki |
proller: Another suggestion; The version paramat made uses special nodes for floating islands (float-stone and float-dirt which is dirt of a more cyan color). Do you think the mapgen version should do the same? Would be nicer than using the same type of stone and dirt as the normal ground |
| 17:42 |
proller |
and i think visual of flowed water must be remaked, its too buggy now |
| 17:42 |
|
rubenwardy joined #minetest-dev |
| 17:43 |
proller |
i think i must go home right now, will answer later |
| 17:43 |
celeron55 |
PilzAdam: if you have any questions, i recommend asking before doing |
| 17:43 |
Taoki |
ok |
| 17:44 |
celeron55 |
PilzAdam: also, ask too if you don't have anything to ask, because then i am guessing you just don't know what to ask (because nobody can know how to use launchpad before having done or heard all the mistakes once) |
| 17:44 |
Taoki |
BTW. Was there some debug key to enable wireframe mode? I forgot, and wanted to check something |
| 17:51 |
celeron55 |
Taoki: no |
| 17:51 |
celeron55 |
(afaik) |
| 17:51 |
Taoki |
ok |
| 17:52 |
Taoki |
celeron55: I wanted to check if block and nodebox surfaces are drawn as triangles or quads, for performance. Not sure if Irrlicht allows this itself, but IIRC if the surface doesn't generate any spikes, it can be drawn out of quads instead of triangles which might be faster. |
| 17:52 |
Taoki |
Since the surfaces of blxes / voxels are flat this would work |
| 17:53 |
Taoki |
IIRC pure OpenGL allows it. You can define a quad surface |
| 17:53 |
PilzAdam |
celeron55, the code gets imported automatically into the bazaar repo? |
| 18:11 |
celeron55 |
PilzAdam: yes |
| 18:12 |
celeron55 |
then dailies automatically built from it; the stable packages are built according to the recipe (which you can probably find), that needs to be updated for each version and then the new build must be requested |
| 18:12 |
celeron55 |
to make a new stable build, three things must be changed: the package version, the minetest bzr revision and the minetest_game bzr revision |
| 18:13 |
celeron55 |
the ppaX at the end of the package version is for new launchpad builds of the same minetest version (because you screw them up half of the time) |
| 18:14 |
celeron55 |
all builds use the minetest_packaging or something like that repo that contains all the debian packaging things, including the command line for building and the package description |
| 18:15 |
celeron55 |
generally the daily builds don't need to be tuned at all; i guess that needs to be done only when the packaging repo is updated, or if more games or something would be added |
| 18:18 |
celeron55 |
complicated enough? 8) |
| 18:19 |
PilzAdam |
updating the recipe for stable just means setting the revno to the commit? |
| 18:21 |
PilzAdam |
and how would one set up the bazaar branches for common, survival and build? |
| 18:22 |
celeron55 |
somewhere there is some "import external repository" thing |
| 18:22 |
PilzAdam |
hmm... the stable build you made shouldnt work because you are missing common |
| 18:22 |
celeron55 |
that's very true... didn't even remember 8D |
| 18:22 |
celeron55 |
as you can see, that was ppa0 |
| 18:22 |
PilzAdam |
same for unstable |
| 18:23 |
PilzAdam |
*daily |
| 18:23 |
celeron55 |
beware that if you screw up the external import, you need to contact launchpad support to modify it |
| 18:24 |
celeron55 |
i feel bad for anyone trying to package minetest 0.4 |
| 18:25 |
celeron55 |
0.3 is like the easiest possible, 0.4 is like the hardest possible |
| 18:25 |
* PilzAdam |
cant find the import button |
| 18:25 |
PilzAdam |
this interface sucks |
| 18:26 |
celeron55 |
hmm |
| 18:27 |
celeron55 |
i'm sure i found it once |
| 18:27 |
|
proller joined #minetest-dev |
| 18:28 |
celeron55 |
apparently it isn't automated: https://help.launchpad.net/Code/Imports |
| 18:29 |
celeron55 |
this is the request form https://code.launchpad.net/+code-imports/+new |
| 18:29 |
celeron55 |
i think we may need to implement gamepacks 8) |
| 18:29 |
celeron55 |
it's too complicated to manage multiple game repos in some situations |
| 18:29 |
celeron55 |
like this |
| 18:30 |
PilzAdam |
should I fill these forms for common, build and survival? |
| 18:30 |
celeron55 |
i guess so |
| 18:31 |
PilzAdam |
what is a "branch" in bazaar? |
| 18:31 |
PilzAdam |
is it master or common? |
| 18:32 |
|
rarkenin joined #minetest-dev |
| 18:32 |
celeron55 |
umm |
| 18:32 |
celeron55 |
you mean the "Branch Name:" thing in that form? |
| 18:32 |
PilzAdam |
I would guess its "common" |
| 18:32 |
PilzAdam |
yes |
| 18:32 |
celeron55 |
leave it as is |
| 18:33 |
celeron55 |
that is "trunk" |
| 18:33 |
celeron55 |
i don't understand what that does but at least "common" or "master" makes zero sense |
| 18:33 |
PilzAdam |
well, here is the list of branches: https://code.launchpad.net/~minetestdevs |
| 18:34 |
PilzAdam |
and they are named "minetest-c55" etc. |
| 18:34 |
celeron55 |
ah |
| 18:34 |
celeron55 |
wtf |
| 18:34 |
PilzAdam |
and it says that it will be used in the URL to identify the branch |
| 18:35 |
celeron55 |
name them after the github repos then |
| 18:35 |
celeron55 |
and set the project to "minetest-c55" |
| 18:36 |
celeron55 |
and set the owner to minetestdevs |
| 18:37 |
PilzAdam |
https://code.launchpad.net/~minetestdevs/minetest-c55/common |
| 18:39 |
PilzAdam |
ummm |
| 18:39 |
PilzAdam |
the whole layout has changed: https://launchpad.net/minetest-c55 |
| 18:39 |
celeron55 |
i have a feeling this is going to explode somehow |
| 18:43 |
PilzAdam |
oh, seems that was the site for the 0.3.1 packages that are in the official ubuntu repos |
| 18:45 |
PilzAdam |
the minetestdevs site still looks the same and has the common branch in it (unimported yet) |
| 18:45 |
PilzAdam |
I make the forms for the other games now |
| 18:49 |
VanessaE |
PilzAdam: where was it that you added that little delay that made falling sand/gravel work? |
| 18:49 |
PilzAdam |
in builtin/falling.lua in the nodeupdate() function |
| 18:50 |
VanessaE |
thought so. |
| 18:50 |
VanessaE |
regression warning: this causes a massive lag when using worldedit //fixlight |
| 18:51 |
VanessaE |
I suggest not adding it there, but rather to the part of the code that causes each sand/gravel block to start falling, if that's possible. |
| 18:52 |
VanessaE |
(e.g. to some place where it won't be executed by mods that force nodeupdates for other reasons) |
| 18:52 |
PilzAdam |
why? |
| 18:53 |
VanessaE |
because the point of adding that delay was so that gravel/sand falls properly, but it horribly kills performance for things that need nodeupdate but don't care about the falling code. |
| 18:54 |
PilzAdam |
umm... what? |
| 18:54 |
PilzAdam |
nodeupate() only handles falling nodes |
| 18:54 |
VanessaE |
81000 nodes updated with my last //fixlight command, which uses dig_node() on air, which forces a nodeupdate. |
| 18:54 |
VanessaE |
which means 8100 seconds for the "rest" of minetest to pick up after worldedit finishes. |
| 18:55 |
VanessaE |
this used to only take 10 seconds or less |
| 18:55 |
|
Jordach joined #minetest-dev |
| 18:56 |
VanessaE |
I'll revert that commit from my local copy and rebuild to be sure. |
| 18:57 |
PilzAdam |
well, nodeupate_single() is called for the same amount of nodes as before |
| 18:58 |
PilzAdam |
the only difference is that only 1 of the 9 nodeupdate_single() calls is done instantly |
| 18:58 |
PilzAdam |
the other 8 are queued to on_globalstep() |
| 18:59 |
VanessaE |
same amount of nodes, but now more time per node |
| 18:59 |
VanessaE |
with a few it's fine, with large amounts the time stacks up exponentially |
| 18:59 |
PilzAdam |
so the first 8100 nodeupdate_single() calls are done instantly, and the other 64800 are done 0.1 seconds after that |
| 19:00 |
VanessaE |
yeah |
| 19:00 |
VanessaE |
that's 6480 seconds. |
| 19:00 |
PilzAdam |
before that all 72900 calls were done instantly |
| 19:00 |
VanessaE |
that's a bit less than two hours |
| 19:00 |
PilzAdam |
<VanessaE> that's 6480 seconds. <- wrong |
| 19:00 |
VanessaE |
before, all 81000 calls were done in maybe 10 seconds or less. |
| 19:00 |
PilzAdam |
they are all done in the same environment step |
| 19:01 |
VanessaE |
um |
| 19:01 |
VanessaE |
no |
| 19:01 |
PilzAdam |
the delay isnt added for every single node |
| 19:01 |
VanessaE |
ok, I just rebuilt without your commit |
| 19:01 |
VanessaE |
let's see how it handles now. |
| 19:01 |
PilzAdam |
you dont have to rebuild |
| 19:02 |
PilzAdam |
builtin can be modified without rebuilding |
| 19:03 |
|
rarkenin joined #minetest-dev |
| 19:03 |
VanessaE |
ok I just proved it |
| 19:03 |
VanessaE |
without your patch, it takes 6 seconds to update 85000 nodes. |
| 19:03 |
VanessaE |
with your patch, it goes on endlessly. |
| 19:03 |
PilzAdam |
it is simply no difference in do the whole work in at once, or doing 1/9 and the other 8/9 after 0.1 seconds |
| 19:03 |
VanessaE |
I just tested it. |
| 19:03 |
VanessaE |
your code causes a massive regression. |
| 19:04 |
PilzAdam |
this cant be |
| 19:04 |
VanessaE |
I just timed it. |
| 19:05 |
VanessaE |
I reverted your patch, recompiled (yeah I forgot I didn't need to), restarted, and executed a //fixlight on a slightly larger volume (closest I could get). |
| 19:05 |
VanessaE |
it completed in 6 seconds. |
| 19:05 |
PilzAdam |
are you sure that it doesnt stop with the commit? |
| 19:05 |
VanessaE |
100% positive. |
| 19:05 |
PilzAdam |
that doesnt make sense at all |
| 19:06 |
VanessaE |
maybe not, but that's where it stands |
| 19:06 |
PilzAdam |
do you have LuaJIT running? |
| 19:06 |
VanessaE |
maybe you're just not understanding when/how that function is being called or something |
| 19:06 |
VanessaE |
yes I do, of course. |
| 19:06 |
|
proller joined #minetest-dev |
| 19:08 |
PilzAdam |
can you try it with a delay of 0 in minetest.after()? |
| 19:09 |
VanessaE |
sure |
| 19:10 |
VanessaE |
wait, where is that at? |
| 19:10 |
PilzAdam |
falling.lua:179 |
| 19:11 |
VanessaE |
oh, that's with your patch in place heh. |
| 19:11 |
VanessaE |
I already reverted it. |
| 19:11 |
VanessaE |
just try it yourself, it's really easy to spot. |
| 19:11 |
VanessaE |
take out your patch. Run worldedit, select at least a 50,000 node region, //fixlight |
| 19:12 |
VanessaE |
then put your patch in and do exactly the same thing. |
| 19:12 |
PilzAdam |
celeron55, anything else todo than adding "nest common lp:~minetestdevs/minetest-c55/common games/common" to the recipes? |
| 19:12 |
PilzAdam |
(same for the other games) |
| 19:12 |
PilzAdam |
VanessaE, I dont have worldedit |
| 19:12 |
VanessaE |
PilzAdam: so install it? |
| 19:12 |
PilzAdam |
Im fighting with launchpad currently |
| 19:13 |
VanessaE |
ok |
| 19:13 |
VanessaE |
I recommend you revert that commit from upstream. |
| 19:21 |
celeron55 |
PilzAdam: dunno, try 8) |
| 19:23 |
PilzAdam |
should I also request a daily build? |
| 19:24 |
VanessaE |
PilzAdam: in addition to default fire and leafdecay, a lot of external mods directly call nodeupdate also...though I don't see that being done in worldedit. |
| 19:24 |
VanessaE |
somehow the dig_node() command must be calling it. |
| 19:24 |
PilzAdam |
yes, its called in minetest.register_on_dignode() |
| 19:24 |
VanessaE |
that's why. |
| 19:24 |
|
Calinou joined #minetest-dev |
| 19:25 |
VanessaE |
each call of minetest.after() causes a delay of x seconds |
| 19:25 |
PilzAdam |
nope |
| 19:25 |
VanessaE |
and if you //fixlight, you're executing dig_node() for every air node therein. |
| 19:25 |
PilzAdam |
that is wrong |
| 19:25 |
celeron55 |
PilzAdam: you can request a daily build anytime; they're quite disposable |
| 19:26 |
celeron55 |
they aren't archived anywhere or anything |
| 19:26 |
VanessaE |
wrong or not, directly or indirectly invoking nodeupdate() is the only possible way to force a lighting update. |
| 19:26 |
VanessaE |
you need to add that delay to the part of the falling code that calls nodeupdate() in the first place. |
| 19:27 |
VanessaE |
not to nodeupdate() itself |
| 19:27 |
celeron55 |
nodeupdate() is not really in the API anyway |
| 19:27 |
PilzAdam |
celeron55, it is |
| 19:27 |
PilzAdam |
since its moved to builtin |
| 19:28 |
celeron55 |
ehm... well i guess so then |
| 19:30 |
VanessaE |
well, whether it's in the API or not, you busted it. ;) |
| 19:30 |
celeron55 |
but the fact that worldedit even calls it is very wrong |
| 19:30 |
celeron55 |
it doesn't need to be supported |
| 19:32 |
VanessaE |
worldedit uses dig_node. |
| 19:32 |
celeron55 |
dig_node isn't meant to work for such bulk operations |
| 19:32 |
VanessaE |
anything that calls dig_node() is affected. |
| 19:33 |
VanessaE |
well how else do you expect a mod to be able to force a lighting update to fix bad shadows? |
| 19:33 |
celeron55 |
set_node is the only one supported when you have to do >5 node changes in one go |
| 19:34 |
VanessaE |
there is no method I know of in the API (or not) that can cause a node's lighting to be updated except for dig_node() and the equivalent placement functions. |
| 19:34 |
celeron55 |
VanessaE: fix lighting bugs in the first place, or add an api function for recalculating lighting in some place |
| 19:34 |
celeron55 |
it isn't rocket science and both of these are obvious |
| 19:34 |
VanessaE |
but that's not an option here. |
| 19:35 |
celeron55 |
digging nodes when you want to recalculate lighting is nonsense |
| 19:35 |
VanessaE |
this already worked great before pilzadam's patch |
| 19:35 |
VanessaE |
his patch broke it, and that's the end of it. |
| 19:35 |
celeron55 |
your way of always preserving compatibility over making things right is nonsense, ridiculous and will lead this project doom |
| 19:35 |
celeron55 |
i recommend stopping it, or at least understanding that nobody should listen it |
| 19:35 |
celeron55 |
+to |
| 19:36 |
|
proller joined #minetest-dev |
| 19:36 |
VanessaE |
no, what will lead to the death of this project is constant breaking of things that worked perfectly before. |
| 19:36 |
celeron55 |
no it won't |
| 19:36 |
celeron55 |
not in the scale we're doing it |
| 19:37 |
celeron55 |
modders should more often implement useful features to the engine instead of working around them with hacks |
| 19:37 |
VanessaE |
jesus H. I'm talking about a, what was it, 4 line change to nodeupdate() that breaks a dozen mods for no benefit at all. |
| 19:37 |
celeron55 |
that way these can be avoided altogether |
| 19:38 |
celeron55 |
i'm pretty sure there is some reason for such a change |
| 19:38 |
VanessaE |
which makes more sense? rewrite a dozen mods, or move a couple of lines in nodeupdate() ? |
| 19:38 |
celeron55 |
depends on reasons |
| 19:39 |
VanessaE |
celeron55: I'm talking about a several minutes' delay in executing a function that used to take a few seconds. |
| 19:39 |
VanessaE |
THAT is reason enough not to allow that change. |
| 19:39 |
VanessaE |
the delay was added to fix a bug in falling code. Put the change where it will only affect the falling code, not where it'll affect a bunch of other shit |
| 19:40 |
proller |
Taoki, i think its bad to add random new blocks, we need something like Story with relations between blocks |
| 19:40 |
VanessaE |
then if there's some one random mod that needs that delay, that one person can add it him/herself. |
| 19:40 |
Taoki |
proller: Not random new blocks. Just a special type of smooth stone and dirt to use for floating islands |
| 19:40 |
Taoki |
I like the cyan sand the LUA version uses |
| 19:41 |
VanessaE |
(which, at present, is only the falling code, to my knowledge, though mesecons has minor timing glitches also) |
| 19:41 |
Taoki |
Called float-sand and float-stone |
| 19:41 |
celeron55 |
VanessaE: i guess you need to find a proper solution with PilzAdam then |
| 19:41 |
VanessaE |
I just found one. |
| 19:41 |
proller |
Taoki, for example like avatar idea about float lands, simple stone with rare ore with special properties (flying) |
| 19:42 |
VanessaE |
dig_node() worked perfectly fine before the way it is being used |
| 19:42 |
VanessaE |
there was no reason to bust it like that |
| 19:42 |
Taoki |
proller: Nah, simple stone is kinda dead. It's nice to have smooth stone and dirt. But a slightly different type |
| 19:42 |
celeron55 |
updating lighting with dig_node() makes me puke |
| 19:43 |
VanessaE |
celeron55: well, it works. |
| 19:43 |
PilzAdam |
VanessaE, I tested it now |
| 19:43 |
VanessaE |
and it works perfectly fine. |
| 19:43 |
celeron55 |
why won't remove_node work? |
| 19:43 |
celeron55 |
or whatever it is |
| 19:43 |
VanessaE |
celeron55: because fixlight needs to operate on AIR. |
| 19:43 |
PilzAdam |
//fixlight takes exactly the same time as before |
| 19:43 |
proller |
Taoki, float-sand and float-stone must have relations via crafting with rest of the world |
| 19:43 |
celeron55 |
VanessaE: and? |
| 19:43 |
Taoki |
Heh. Cuz Minetest needs hardware lighting like christians need Jesus :) |
| 19:43 |
VanessaE |
PilzAdam: how much of a region did you test? |
| 19:43 |
PilzAdam |
the problem is the environment step after 0.1 seconds |
| 19:43 |
Taoki |
Updating the lightmap like that is hacky IMO |
| 19:44 |
VanessaE |
PilzAdam: exactly |
| 19:44 |
Taoki |
Just one thing that's hacky about the current lighting |
| 19:44 |
VanessaE |
the actual command executes just fine, but the server hangs like hell when it's done. |
| 19:44 |
Taoki |
proller: Well normal dirt or stone can't be crafted, they're only natural |
| 19:44 |
PilzAdam |
VanessaE, easy to fix: set minetest.timer_to_add = {} after looping through the dignodes in worldedit |
| 19:44 |
celeron55 |
Taoki: i think all hardware lighting except raytracing is just full of hacks, this voxel lighting is good |
| 19:44 |
VanessaE |
PilzAdam: no, WE DON'T BREAK USERSPACE. |
| 19:44 |
proller |
Taoki, player must be need in float-* materials in some purposes |
| 19:45 |
PilzAdam |
this doesnt break anything |
| 19:45 |
VanessaE |
fix the problem in the engine code or in falling.lua |
| 19:45 |
celeron55 |
Taoki: your intention seems mostly to be removing voxel lighting from minetest and replacing it with something that can only run on modern hardware, which i frown upon |
| 19:45 |
VanessaE |
I ripped your change out and it fixed the problem. Which means you need to only be adding those timers to FALLING nodes. |
| 19:45 |
VanessaE |
not to ALL nodes that are dug |
| 19:45 |
Taoki |
proller: Well we have sand and desert-sand currently, which are the exact same thing only different color |
| 19:45 |
celeron55 |
or alternatively making it look like shit on older hardware |
| 19:45 |
PilzAdam |
it needs to be done if a mod calls dig_node() excessively |
| 19:45 |
Taoki |
celeron55: Not removing entirely as long as older hardware -needs- it |
| 19:46 |
VanessaE |
PilzAdam: and what about all the mods out there that have to call nodeupdate()? |
| 19:46 |
celeron55 |
Taoki: if it's not removed, then issues with it aren't removed either; thus, it is not a solution to anything |
| 19:46 |
PilzAdam |
how much do they call it? |
| 19:46 |
proller |
Taoki, better for some thing player must get some rare material from sky and from hell, it must encourage trade and world explore |
| 19:46 |
Taoki |
celeron55: If everything we wanted was possible, I do wish it could be removed entirely. But that depends if HW lights would work with older hardware too. If not then it should stay optional |
| 19:46 |
celeron55 |
Taoki: so don't propose it as any kind of solution |
| 19:46 |
PilzAdam |
I dont think they call it for 10000+ nodes |
| 19:46 |
VanessaE |
PilzAdam: 83 separate calls in my entire mods tree |
| 19:46 |
Taoki |
Yeah I guess |
| 19:47 |
VanessaE |
(and none of them are my mods) |
| 19:47 |
PilzAdam |
VanessaE, for how many nodes per environment step= |
| 19:47 |
PilzAdam |
*? |
| 19:47 |
Taoki |
But I'll correct; Only removed as long as older hardware can't handle normal lighting. As in light entities from Irrlicht. Normally, those can be handled even without shaders... but like we discussed shades are needed to mask it in caves |
| 19:47 |
Taoki |
So if the problem is still there then yeah |
| 19:47 |
VanessaE |
PilzAdam: beats me, I have no way to count that up |
| 19:47 |
RealBadAngel |
PilzAdam, introducing delay to stuff not connected in anyway to falling nodes is a bad idea |
| 19:48 |
VanessaE |
I know technic makes significant use of it in constructors, deployers, node breakers |
| 19:48 |
VanessaE |
I see lots of calls in mesecons |
| 19:49 |
celeron55 |
Taoki: once the hardware we consider "old" runs such shaders reasonably, we'll probably throw the voxel lighting completely away; until then, it will stay |
| 19:49 |
VanessaE |
hm, homedecor does make one call to it in the 3dforniture import (blame tonyka) |
| 19:49 |
Taoki |
celeron55: Makes sense, that's correct. But if better lighting can be added, it should then stay optionally |
| 19:49 |
PilzAdam |
RealBadAngel, why? |
| 19:49 |
celeron55 |
Taoki: also, for that to happen at that time, there needs to be someone around who has or will implement the shadered shadows and stuff |
| 19:50 |
celeron55 |
Taoki: currently, we have nobody who can do that |
| 19:50 |
Taoki |
I know. I really wish I could, but I have virtually no diea about those things :( |
| 19:50 |
Taoki |
Yeah, really sucks |
| 19:50 |
PilzAdam |
VanessaE, every mod only calls it for single nodes |
| 19:50 |
PilzAdam |
except worldedit |
| 19:50 |
celeron55 |
also, those who can do that don't want to touch minetest; minetest is like total crap from their viewpoint |
| 19:50 |
celeron55 |
they want stuff that is designed from the ground up for modern graphcis |
| 19:50 |
Taoki |
They're fools :P |
| 19:50 |
Taoki |
Oh, MineTest can have very modern graphics once this is done |
| 19:51 |
VanessaE |
PilzAdam: still, you should put the delay in the FALLING code, not in nodeupdate. |
| 19:51 |
PilzAdam |
nodeupated is the falling code |
| 19:51 |
VanessaE |
I'm not saying to get rid of the idea, I'm saying to localize and limit its effects to that which you originally intended to fix anyway |
| 19:51 |
VanessaE |
yeah and DIG NODE uses it! |
| 19:51 |
celeron55 |
i could consider throwing some coffee money out of donation budget to someone who'd do that, if nobody does it for free |
| 19:51 |
VanessaE |
you literally affect EVERY mod that uses dig_node() for any reason at all |
| 19:51 |
Taoki |
celeron55: If shaders are used for light shadows, are the lights done there too? I keep hoping we can use the light entities in Irrlicht and speficy them in C++. ButI assume it would be a combination between that and shaders |
| 19:51 |
RealBadAngel |
mesecons are falling stuff? |
| 19:51 |
PilzAdam |
there is no way to have the delay when a player digs the node, and not have it when a mod calls it |
| 19:52 |
VanessaE |
I'm just saying to move it up one level, out of nodeupdate() and into the code that calls nodeupdate. |
| 19:52 |
VanessaE |
RealBadAngel: probably for a piston pushing objects around, or the movestone |
| 19:52 |
Taoki |
celeron55: I'd donate to someone to do that too. Though we're sort of in a money crisis so even 10$ would have me killed :P But I'd certainly try it |
| 19:52 |
VanessaE |
PilzAdam: then. put. it. in. the. falling. code. itself. |
| 19:52 |
PilzAdam |
VanessaE, not possible, since the player call dig_node() to dig nodes |
| 19:52 |
PilzAdam |
what do you mean by falling code? |
| 19:52 |
VanessaE |
where you convert each node into an entity |
| 19:52 |
celeron55 |
Taoki: if you find some people with some odd fetishes to retro opengl wrapped in a clumsy cross-platform library (irrlicht), tell them minetest could use some work 8D |
| 19:52 |
VanessaE |
that's the proper place to put it |
| 19:53 |
Taoki |
celeron55: But 10$ for something like this could upset you if it's too little ;) |
| 19:53 |
Taoki |
(cuz I don't see who else can at all) |
| 19:53 |
VanessaE |
gotta run, back later. |
| 19:53 |
Taoki |
later |
| 19:53 |
PilzAdam |
<VanessaE> where you convert each node into an entity <- why havent you said this before? |
| 19:54 |
VanessaE |
because I thought you would understand what I meant? |
| 19:54 |
VanessaE |
I didn't think it needed to be stated that explicitly. |
| 19:54 |
VanessaE |
anyway, out -> |
| 19:55 |
PilzAdam |
this would cause a delay for the node at the postion of nodeupdate too |
| 19:55 |
celeron55 |
PilzAdam: that is the original problem here? |
| 19:55 |
celeron55 |
what* |
| 19:56 |
PilzAdam |
a large table being generate/copied in the env step after calling nodeupate() for thousands of nodes at the same time |
| 19:56 |
celeron55 |
that is the resulting problem of the current fix to the problem that i am asking about |
| 19:57 |
PilzAdam |
the table has #(nodes)*8 elements |
| 19:57 |
PilzAdam |
the original intention of me for adding the dealy was 1) entities arent spawned all at the same time and 2) it looks good |
| 19:58 |
PilzAdam |
*delay |
| 19:58 |
Taoki |
Anyway, something just as important: http://forum.minetest.net/viewtopic.php?pid=81733 I'm curious what people think about this especially the main devs |
| 19:58 |
celeron55 |
why don't you just limit the size of the table |
| 19:58 |
celeron55 |
if it grows higher than like 10, start just updating immediately |
| 19:59 |
PilzAdam |
it could be fixed by moving the delay to the place were the entity is actually genereated |
| 19:59 |
PilzAdam |
because the delay causes the table to grow |
| 20:01 |
celeron55 |
i don't know... but if the performance is decreased 100x like VanessaE says, it isn't good |
| 20:02 |
celeron55 |
there needs to be a way to make it efficient, even while cases that actually make it take seconds are silly |
| 20:02 |
PilzAdam |
yep, fixed it |
| 20:05 |
Taoki |
celeron55: BTW, regarding the voxel lighting. My own idea would actually still require it. Which is to use the current "lightmaps" as a way to limit hardware lights outdoor, at least for sun |
| 20:05 |
Taoki |
So basically: When HW lighting is off, voxel light areas are used like they are currently; bright spots |
| 20:05 |
Taoki |
When HW lighting is on however, they're used to indicate where the infinite light can shine |
| 20:06 |
Taoki |
It would also remain needed so the light value at each node can be detected, which is needed by mods. For example to know when it's dark so you can spawn a mob |
| 20:07 |
Taoki |
The only real issue is how to use this as a mask for lights. That I can't tell |
| 20:08 |
celeron55 |
i can imagine tricks that don't even need shaders, but they're hard and might need bare opengl (but i've said this before) |
| 20:08 |
Taoki |
We have the current voxel light system which knows what light value each node should have from the sun / moon, and we can add an Irrlicht light with just one line of code. But how to combine them is the thing :P |
| 20:08 |
Taoki |
yeah, those tricks would be awesome |
| 20:10 |
Taoki |
There actually is a trick that can be used currently as well; Add a black texture over nodes to cancel lighting or dim it. Using the existing light calculations of the voxel system |
| 20:11 |
Taoki |
Or fill color that covers the texture. I assume multi-texturing likely works under Irrlicht |
| 20:11 |
Taoki |
Pretty sure you can set surfaces to not be affected by lights, or limit some surfaces to some lights only. |
| 20:12 |
Taoki |
Problem is how to do it smoothly AND not break lights coming from torches placed indoor |
| 20:14 |
celeron55 |
well, you can always do multiple render passes without clearing the frame or z buffers (and you should be able to swap lights between them) |
| 20:14 |
celeron55 |
that'll more or less eat framerate though |
| 20:14 |
Taoki |
Yeah. That might be doable without shaders too |
| 20:14 |
Taoki |
hmm |
| 20:15 |
celeron55 |
and isn't trivial anyway |
| 20:18 |
celeron55 |
one could render all kinds of special masks based on what receives voxel sunlight or light at all or something, and then AND or OR that to something else and whatever |
| 20:18 |
celeron55 |
but it's again very nontrivial |
| 20:18 |
celeron55 |
especially getting something useful out of it |
| 20:18 |
Taoki |
Having real light is an important thing I believe. I think it's the most major feature that would be needed |
| 20:19 |
Taoki |
There are others too but especially this |
| 20:19 |
Taoki |
I think special masks are sort of the best or only way to go though |
| 20:19 |
hmmmm |
[01:38 PM] <proller> ^^^ <proller> and springs make not very good lakes in air above unloaded blocks |
| 20:20 |
celeron55 |
i think it would be reasonable to only implement it with shaders |
| 20:20 |
hmmmm |
yeah, that's something i couldn't really figure out when i first saw the problem |
| 20:20 |
celeron55 |
or maybe not |
| 20:20 |
celeron55 |
it's hard to decide where to draw the line |
| 20:20 |
hmmmm |
i don't know, i need to look at it more, but either way, the insane SEnv lag when water flows into an unloaded chunk == unacceptable |
| 20:20 |
Taoki |
Shaders are usually for improved effects anbd the like. Lighting would be... sorta too important to be shader-only |
| 20:21 |
hmmmm |
need to add some sort of check in updateLighting() so it doesn't bother to keep trying to update that |
| 20:21 |
celeron55 |
in modern 3d graphics, you don't have fixed pipeline at all and use shaders for everything, including lights |
| 20:21 |
hmmmm |
[02:25 PM] <celeron55> 0.3 is like the easiest possible, 0.4 is like the hardest possible |
| 20:22 |
hmmmm |
all 0.3 versions have problems with missing libintl for me |
| 20:22 |
hmmmm |
i need to remove -lintl from a certain cmake file to get anything older than 0.4.1 to build |
| 20:22 |
Taoki |
heh. Way too modern :P |
| 20:22 |
hmmmm |
0.4 is hard because of the JThread mess and the json crap |
| 20:22 |
proller |
hmmmm, very simple to fix water in transform_liquids - drop if bottom unloaded |
| 20:22 |
celeron55 |
Taoki: that's how you'd do any new project if you started it today |
| 20:22 |
hmmmm |
proller, need to make it more general |
| 20:23 |
hmmmm |
i'll look at it more later on |
| 20:23 |
hmmmm |
first i need to go pass out |
| 20:23 |
Taoki |
celeron55: Thing is that Irrlicht light entities should also work for that old hardware which can't handle shaders. And barely reduce performance if at all |
| 20:23 |
celeron55 |
Taoki: true |
| 20:24 |
hmmmm |
i couldn't play eduke32 with dynamic lighting even |
| 20:24 |
hmmmm |
and i don't think an 8400gs is too old |
| 20:24 |
Taoki |
And there are some mask hacks I can think of to hide sunlight in caves. At worst we use a black color on the texture, opposite of the current voxel lights. Where the suinlight doesn't shine at all, the surface would be fully black. Black can't be lit |
| 20:25 |
celeron55 |
but really, this problem needs to be thought from the standpoint of using hardware lighting, and then asking the question: how can voxel lighting be used to make caves dark, *without* making torches in them dark |
| 20:25 |
Taoki |
And to make sure that unlit caves aren't 100% darkl unless a torch is placed, bumped up manually by some ambient lighting |
| 20:25 |
proller |
hmmmm, other variants will be much more difficult, or impossible if you make infinity spring at 30000 |
| 20:25 |
Taoki |
celeron55: Yes. Thgat's how I'm thinking of it |
| 20:26 |
Taoki |
The closest hack in mind though is using black color to kill sunlight. But that would also kill torch lights |
| 20:26 |
proller |
hmmmm, best way is load block under, but you cant load all blocks to -31000 |
| 20:27 |
Taoki |
I feel we're pretty close with a solution though... somehow. Still far but close :P |
| 20:27 |
celeron55 |
it's just that you haven't yet thought about the thing that will make the solution not work at all |
| 20:28 |
Taoki |
yeah. Torches would now be the problem |
| 20:28 |
celeron55 |
but really, one would first need to know all the things that can be done with irrlicht with old hardware |
| 20:28 |
celeron55 |
it's probably more than one would think, and probably different things than one would think |
| 20:31 |
celeron55 |
hmm, assuming it is possible to render a "mask" that can be used to dim everything not touched by sunlight, it would be possible to just let it dim torches when you're in sunlight, and when you go to a cave and don't look outside, the dimming would be turned off and ambient light would be turned off |
| 20:31 |
hmmmm |
proller, can the springs spawn above water_level? |
| 20:31 |
celeron55 |
-> torches are bright |
| 20:31 |
Taoki |
Ahhh, I think I remembered something actually. If I'm correct there is a diffuse parameter for faces in Irrlicht. It allows changing how much light a surface takes, without changing its color. I hope I'm right about that |
| 20:32 |
Taoki |
You can adjust diffuse and specular separately yeah... I think |
| 20:32 |
celeron55 |
that would be a reasonable solution and would need only single extra pass to make the mask |
| 20:32 |
Taoki |
Yes. Can someone else check just to be 100% sure? |
| 20:32 |
celeron55 |
(what i said, i mean) |
| 20:32 |
Taoki |
Ah, ok |
| 20:32 |
Taoki |
I think I saw the diffuse option when I implemented my models |
| 20:33 |
Taoki |
Oh, I remember better. It's called "diffuse color". I already added it to colorize entities. But if all 3 values are adjusted together than it just decreases how much lighting the surface takes |
| 20:33 |
Taoki |
diffuse_color, specular_color... I think there was a third one but mattered less |
| 20:34 |
celeron55 |
minetest basically currently uses diffuse color to set the lighting of *everything* |
| 20:34 |
celeron55 |
afaik |
| 20:34 |
celeron55 |
you can't really use diffuse color to set lighting if hardware lighting is enabled |
| 20:34 |
celeron55 |
it's very nonlinear and unpredictable then |
| 20:34 |
Taoki |
Found my lines: m_animated_meshnode->getMaterial(i).AmbientColor = m_prop.colors[i]; m_animated_meshnode->getMaterial(i).DiffuseColor = m_prop.colors[i]; m_animated_meshnode->getMaterial(i).SpecularColor = m_prop.colors[i]; |
| 20:35 |
Taoki |
So there's AmbientColor, DiffuseColor, and SpecularColor |
| 20:35 |
Taoki |
I wonder what the difference is between AmbientColor and DiffuseColor |
| 20:35 |
celeron55 |
http://blog.lexique-du-net.com/index.php?post/2009/07/24/AmbientDiffuseEmissive-and-specular-colorSome-examples |
| 20:36 |
PilzAdam |
celeron55, VanessaE, here is a working fix: https://github.com/PilzAdam/minetest/commit/97f0bb03423b6d2e22058166b677e568c53d7567 |
| 20:36 |
Taoki |
Oh... I see |
| 20:36 |
celeron55 |
that is, diffuse color will show up when you point it with non-ambient light and ambient color when it isn't pointed with such.... ehm... well, i can't say i would understand how that would actually work |
| 20:37 |
proller |
hmmmm, if you write it to register_ore with height >0 and param128, i tried it on my server, its ok. and its only way to run down witout death |
| 20:37 |
Taoki |
Me neither. Sounds more like bounce lighting |
| 20:38 |
Taoki |
Still, this parameter does bring us closer to a solution hopefully. Only issue would be how to separate sunlight from torches and torches from each other as well |
| 20:39 |
Taoki |
Hopefully all with Irrlicht functions |
| 20:40 |
celeron55 |
i don't think that is close to a solution |
| 20:49 |
Taoki |
celeron55: Someone in #icclicht mentioned a light manager, which could solve our problem. Supposedly it can separate nodes from certain lights |
| 20:50 |
Taoki |
Found a video which uses it, the description is interesting: http://www.youtube.com/watch?v=RO3pRcymG-w |
| 20:50 |
Taoki |
He also linked this: http://irrlicht.sourceforge.net/docu/example020.html |
| 20:51 |
Taoki |
"Normally, you are limited to 8 dynamic lights per scene: this is a hardware limit. If you want to use more dynamic lights in your scene, then you can register an optional light manager that allows you to to turn lights on and off at specific point during rendering. You are still limited to 8 lights, but the limit is per scene node." |
| 20:52 |
celeron55 |
that doesn't help at all in our problem |
| 20:53 |
Taoki |
Ahh. Got the impression it's exactly it. Since it allows separating lights per nodes |
| 20:53 |
celeron55 |
the only thing it does is multiplexes light sources to allow having more than 8 |
| 20:54 |
Taoki |
ah |
| 20:54 |
Taoki |
He still said the light manager could be used to achieve this. Maybe not in that example |
| 20:54 |
celeron55 |
i am wondering that you might have even asked |
| 20:55 |
Taoki |
[23:42:31] <Taoki> Separate question, not sure if I asked some months ago already: Is there really no way to make some surfaces be affected by some lights only? Some function, or hack... |
| 20:55 |
Taoki |
[23:46:01] <Taoki> Can be multiple nodes too at worst. But for example if I place two surfaces one next to the other and two lights one next to the other. I mean some way to make one surface affected by one light and the other by the other light |
| 20:55 |
Taoki |
Hold on actually, |
| 20:56 |
Taoki |
http://pastebin.com/cmVBWtX3 |
| 20:56 |
celeron55 |
that is simply achieved by swapping lights on and off between rendering different stuff; there's no magic there |
| 20:56 |
Taoki |
No magic, but would it work? |
| 20:57 |
celeron55 |
are you aware that node means something completely different in irrlicht than in minetest? |
| 20:57 |
Taoki |
I think. A node in MT is usually a block. Nodes in Irrlicht are like holders for meshes IIRC |
| 20:58 |
celeron55 |
something like that |
| 20:58 |
Taoki |
Still, I think each surface of a block in MT is an Irrlicht node. Or at least each whole block |
| 20:58 |
Taoki |
From what I quickly seen in the code once |
| 20:59 |
celeron55 |
actually the whole minetest voxel world is a single irrlicht node |
| 20:59 |
celeron55 |
but it's irrelevant here (except that it makes the direct use of the light manager not possible) |
| 20:59 |
Taoki |
Right. In that case there is a problem |
| 20:59 |
Taoki |
ok then. Was going to ask if separating caves into other nodes could allow them to be lit separately |
| 21:00 |
celeron55 |
we can switch lights on and off in the map rendering code anyway |
| 21:00 |
celeron55 |
or, well, world |
| 21:00 |
celeron55 |
Taoki: i believe so |
| 21:00 |
Taoki |
True. But once could be seeing multiple lights at once |
| 21:00 |
Taoki |
Both sunlight and a torch in a cave |
| 21:00 |
Taoki |
**one |
| 21:01 |
celeron55 |
basically, stuff designated as being caves or insides of things would be rendered without the sunlight light |
| 21:01 |
Taoki |
Yeah. Caves could be separated into a second Irrlicht node with its own lighting effects |
| 21:01 |
celeron55 |
no |
| 21:02 |
celeron55 |
don't mix up any irrlicht nodes in here |
| 21:02 |
Taoki |
ok |
| 21:02 |
celeron55 |
it's irrelevant here and only makes things hard |
| 21:02 |
Taoki |
Hmm... and there's another problem in the mix; Torches themselves would need their lighting cut. Since you wouldn't want to place a torch on one side of the wall and have its light on the other... even in a deep cave with no sun light |
| 21:02 |
RealBadAngel |
http://irrlicht.sourceforge.net/docu/example003.html |
| 21:03 |
celeron55 |
Taoki: for that and for any shadows outside you need shadows; there are someting like two ways to make them traditionally using irrlicht |
| 21:04 |
celeron55 |
they require two render passes and whatever |
| 21:04 |
Taoki |
Yeah, I think the same |
| 21:04 |
RealBadAngel |
the sample code of scene node looks suspiciously similar to mt node ;) |
| 21:04 |
Taoki |
Well, we can go with that if it's really really needed. How much can two passes decrease performance |
| 21:05 |
celeron55 |
RealBadAngel: IIRC minetest started as that example |
| 21:05 |
celeron55 |
altough all custom scene nodes always are implemented like how minetest implements the world |
| 21:06 |
Taoki |
There is another way too. But eeven more FPS costly |
| 21:06 |
RealBadAngel |
so, we *can* treat mt node as irrlicht scene node object |
| 21:06 |
Taoki |
That would be to use dynamic shadows / light cutting. So every surface casts a direct sharp shadow. But that's usually meant to be an option itself cuz it's pretty consuming to do for each block |
| 21:06 |
celeron55 |
Taoki: well, 2x |
| 21:07 |
Taoki |
Only issue with light cutting would be if the ceiling of a cave hasn't loaded (eg: is beyond your draw distance). No blocks are detected and the system could think you're outside. But I guess that's less important for starters |
| 21:07 |
Taoki |
Do Irrlicht lights support cutting natively? |
| 21:08 |
celeron55 |
it would be quite deceptive to try to think that two passes would take less than twice the time 8) |
| 21:08 |
Taoki |
heh |
| 21:08 |
celeron55 |
but if you take into account more things, then it will become (much) less |
| 21:08 |
|
sapier1 joined #minetest-dev |
| 21:08 |
celeron55 |
but that depends on what you do with two passes |
| 21:09 |
celeron55 |
if you're drawing shadows, then you could probably render a much smaller distance for the shadow pass |
| 21:09 |
Taoki |
yeah. And exclude other defails perhaps |
| 21:10 |
celeron55 |
there's not really any such details in minetest |
| 21:11 |
celeron55 |
anyway... somebody'd just need to start experimenting |
| 21:12 |
Taoki |
celeron55: How much worse would dynamic shadows be? |
| 21:12 |
celeron55 |
dunno |
| 21:13 |
celeron55 |
3d shadows are standard stuff, just google |
| 21:13 |
Taoki |
That sounds like it could be quite the solution |
| 21:13 |
Taoki |
FPS costly, but better than nothing. Especially if HW lighting can be optional |
| 21:14 |
Taoki |
Haha. The person who I spoke to about this is actually on this channel too. Hi serengeor :) |
| 21:15 |
Taoki |
celeron55: But yeah. From what I can think, this would be the best if not only solution. And really worth trying out :) Dynamic shadows would instantly do the trick. But I wonder how reliable they are for that... |
| 21:16 |
Taoki |
Irrlicht should support it natively and without shaders |
| 21:16 |
celeron55 |
ehm, how do you think "dynamic shadows" differ from "shadows"? |
| 21:16 |
Taoki |
I mean the same thing sorry |
| 21:17 |
celeron55 |
irrlicht can do it, but it's not automatic by any means; it's basically the same as doing it with bare opengl/d3d |
| 21:17 |
Taoki |
Hopefully that's ok then |
| 21:19 |
Jordach |
can i have a main page suggestion? |
| 21:19 |
Taoki |
As in, still doable with Irrlicht |
| 21:19 |
Jordach |
as in: http://minetest.net |
| 21:21 |
Taoki |
sure |
| 21:21 |
Jordach |
celeron55, instead of linking directly to the engine github repo, instead, is it possible to link it to https://github.com/minetest ? |
| 21:21 |
Taoki |
Sounds better indeed |
| 21:36 |
serengeor |
Taoki, what kind of lighting exists currently in minetest? |
| 21:36 |
Taoki |
serengeor: A fake voxel lighting system. Basically, light value is calculated at various points, and the surface's color is changed to reflect it |
| 21:37 |
Taoki |
Long story short, light is done by fakely coloring each surface or vertice. But there's many reasons to switch to hardware lights |
| 21:38 |
Taoki |
However, if that's done we need a way to keep sunlight from shining in caves. The only info the current light system offers IRC is "the light value at each block". Probably a number between 1 and 10 or something like that. |
| 21:38 |
Taoki |
So that info needs to be worked with to mask different lights for different areas |
| 21:41 |
serengeor |
I see |
| 21:42 |
Taoki |
serengeor: But the situation is complicated. Since for example you can place a lot of torches at once in a cave, and their lights need to show correctly. You might also be seeing the sunlight outside at the same time |
| 21:42 |
Taoki |
What would make everything right was if Irrlicht had a way to influnce the effect a specific light has on a specific surface |
| 21:42 |
Taoki |
And tell each face or vertice how much light to take from any individual light entity |
| 21:43 |
serengeor |
you can use vertex colors to do that |
| 21:44 |
serengeor |
and use shader to mix light with vertex color |
| 21:45 |
serengeor |
but that just sounds the same as it is now :? |
| 21:45 |
Taoki |
serengeor: Problem is that MineTest is meant to run on machines that don't support shaders too. So it would have been awesome to have a shader-less way to do this as well |
| 21:45 |
Taoki |
Kind of. It's better to mask a real hardware light than manually change the color of surfaces |
| 21:45 |
dexter0 |
3d textures, oh wait. |
| 21:46 |
Taoki |
serengeor: Can you think of a shader-less way to do this in Irrlicht though? |
| 21:47 |
serengeor |
raytrace the fuck out of it |
| 21:47 |
Taoki |
Even if it requires a hack to hide lights in some places... like for instance colorizing that face in black somehow |
| 21:47 |
serengeor |
:D |
| 21:47 |
Taoki |
heh, yeah that would be one idea :P |
| 21:48 |
Taoki |
I suggested dynamic shadows, I think they might be the best option |
| 21:49 |
dexter0 |
Unless you use stencil shadows, you'd need to build a shadow map for each light. |
| 21:49 |
dexter0 |
err shadow volumes |
| 21:51 |
Taoki |
Yep. Stencil shadows would be the way |
| 21:52 |
Taoki |
But how do you place a light with stencil shadowing? |
| 22:17 |
|
proller joined #minetest-dev |
| 22:19 |
|
iqualfragile joined #minetest-dev |
| 22:20 |
Taoki |
Ah-hah! This shows how to add shadows to lights... hopefully this is what we need: http://irrlicht.sourceforge.net/docu/example008.html |
| 22:33 |
VanessaE |
PilzAdam: that seems to work exactly as desired. |
| 22:33 |
VanessaE |
worldedit is fast again, and a large region of e.g. falling sand falls in a nice, even wave (until the client starts to lose fps ;) ) |
| 22:46 |
|
Deivan joined #minetest-dev |
| 23:05 |
hmmmm |
i don't mean to be insulting, but gosh, the forum is filled with what seems like 12 year olds |
| 23:05 |
hmmmm |
just read the Moontest thread, pretty lol |
| 23:06 |
PilzAdam |
maybe because only 12 year old people play Minetest? |
| 23:06 |
hmmmm |
:( |
| 23:06 |
Taoki |
Far from it |
| 23:07 |
* Taoki |
is a 12 * 2 year old :P |
| 23:17 |
Taoki |
BTW. I found out a new method of trolling in MineTest which just happened to me on a server. Trolls can dig holes in stone. If a new player falls in them without either a pickaxe or nodes to put under themselves, and there's no command to teleport to spawn or otherwise, you're stuck there |
| 23:19 |
Taoki |
The server's fault for having neither /spawn, /die, or default privileges for either free_move or /teleport |
| 23:31 |
ShadowNinja |
I think lua should be able to get a spawn point for servers that don't have static_spawnpoint set |
