| Time |
Nick |
Message |
| 00:00 |
hmmmm |
then now when i went to go git diff, it showed that all the files were completely different |
| 00:00 |
hmmmm |
and they were, because every line had a CR added to the ending |
| 00:00 |
SpeedProg |
you can set git to convert line endings |
| 00:00 |
hmmmm |
so when i went to commit and push it, it'd commit absolutely everything as new and show no changes |
| 00:00 |
SpeedProg |
through I don't actually know the name of the setting |
| 00:00 |
hmmmm |
autocrlf |
| 00:01 |
hmmmm |
already read about it and all |
| 00:01 |
Taoki |
ouch... I see |
| 00:01 |
SpeedProg |
it isn't hard to undo a commit :D |
| 00:01 |
hmmmm |
i did undo it |
| 00:02 |
hmmmm |
for damage control, i'm converting everything back to LF manually |
| 00:02 |
SpeedProg |
lol |
| 00:02 |
SpeedProg |
good luck and have fun :D |
| 00:02 |
hmmmm |
thanks |
| 00:02 |
Taoki |
That has to suck :/ Good luck with that |
| 00:02 |
Taoki |
Sad some IDE's do that |
| 00:03 |
SpeedProg |
can't you text editor search for crlf and replace it with lf? |
| 00:03 |
hmmmm |
i'd have to have every single file in the source tree opened |
| 00:03 |
Taoki |
hmmmm: You could try that out. There is a high amount of files, but something like notepad++ should be able to handle it |
| 00:04 |
Taoki |
Never tried that many files... I assume it could be past 100 |
| 00:04 |
Taoki |
Yeah, 281 files in source. Dunno if that could crash it or fill up the RAM |
| 00:04 |
SpeedProg |
it shouldn't make a difference even if they are a few thousend |
| 00:04 |
Taoki |
hmm |
| 00:04 |
SpeedProg |
because it does not keep them open |
| 00:11 |
hmmmm |
haha, more like 439 according to find . | egrep '.h$|.cpp$' | wc |
| 00:15 |
Taoki |
brb |
| 00:35 |
hmmmm |
i deserve a raise http://pastebin.com/a2rDu3Xv |
| 00:35 |
hmmmm |
on that note, i hate shell scripting with a burning passion |
| 00:40 |
|
Taoki joined #minetest-dev |
| 00:41 |
Taoki |
Back for a few minutes till heading off to bed |
| 00:41 |
Taoki |
hmmmm: Any news? |
| 00:42 |
hmmmm |
nah |
| 00:42 |
hmmmm |
oh, [19:34] <hmmmm> i deserve a raise http://pastebin.com/a2rDu3Xv |
| 00:57 |
Taoki |
Late, need to go now. Night everyone |
| 00:58 |
Taoki |
Hope you can put the code in Github today or tomorrow, can't wait to see it on some server :) |
| 02:20 |
hmmmm |
*phew* |
| 02:20 |
hmmmm |
https://github.com/kwolekr/minetest/commit/bd674eea80d89f8cdb25479cb9414d9c4c9fc81e |
| 02:20 |
hmmmm |
22 modified files |
| 02:20 |
hmmmm |
1300 LoC changed |
| 02:20 |
hmmmm |
and it doesn't even work yet |
| 02:24 |
hmmmm |
actually it's 21 changed files, 1600 additions, 751 deletions |
| 02:38 |
|
doserj left #minetest-dev |
| 02:49 |
|
SpeedProg joined #minetest-dev |
| 02:53 |
|
SpeedProg joined #minetest-dev |
| 04:43 |
|
hmmmm joined #minetest-dev |
| 06:07 |
hmmmm |
yeah... sorry, i haven't been keeping up with what was said in the channel lately |
| 06:08 |
VanessaE |
shit happens. |
| 09:06 |
|
rsiska joined #minetest-dev |
| 09:20 |
|
rob_ joined #minetest-dev |
| 09:48 |
|
kotolegokot joined #minetest-dev |
| 09:53 |
|
Calinou joined #minetest-dev |
| 10:00 |
|
rob_ joined #minetest-dev |
| 10:06 |
|
rsiska joined #minetest-dev |
| 10:26 |
thexyz |
wtf? https://gist.github.com/4147549 |
| 11:03 |
|
rsiska joined #minetest-dev |
| 13:32 |
|
rsiska joined #minetest-dev |
| 13:34 |
celeron55 |
thexyz: guess: truncated player file |
| 13:36 |
celeron55 |
umm... no |
| 13:36 |
celeron55 |
it |
| 13:36 |
celeron55 |
it must be a very old version at least |
| 13:36 |
celeron55 |
at least since 0.4.3 that error hasn't even existed in the source code |
| 13:38 |
celeron55 |
here is some interesting stuff: https://github.com/celeron55/minetest/commits/exp |
| 13:39 |
celeron55 |
making things use that for serialization should allow easier compatibility between versions |
| 13:40 |
celeron55 |
and way less horrible problems in case somebody messes things up |
| 13:54 |
celeron55 |
it does have some storage overhead (when storing many individual bytes), but it can be minimized to be reasonable |
| 13:59 |
Taoki |
celeron55: Seen the link hmmmm posted? He managed to get the mapgen stuff on a branch. |
| 13:59 |
Taoki |
Now I wonder when and if it will be ready for upstream too |
| 14:01 |
celeron55 |
simple answer: not soon |
| 14:01 |
Taoki |
ok |
| 14:01 |
Taoki |
Was it tested and something known to be wrong? |
| 14:04 |
celeron55 |
... |
| 14:04 |
celeron55 |
04:21:54 < hmmmm> and it doesn't even work yet |
| 14:04 |
celeron55 |
i suggest reading |
| 14:04 |
celeron55 |
it isn't even *supposed* to work yet |
| 14:05 |
celeron55 |
22:36:32 < hmmmm> it's in my experience that if something isn't 100% when it's released to the public, people will try to use it and people will complain that it doesn't work |
| 14:05 |
celeron55 |
22:36:44 < hmmmm> and i'd get 1000 messages "hey your thing crashed when i did blah blah blah" |
| 14:05 |
celeron55 |
8) |
| 14:05 |
Taoki |
Sorry, missed some of his lines |
| 14:06 |
Taoki |
If it's not intended to work yet then sure, no one can expect it to work. Wasn't sure if it was only... no rush in finishing it then |
| 14:10 |
Taoki |
In other news: I'm close to implementing parallax mapping for tiles. Normal maps will be specified as a property of the tile, just like textures and material options are (from mua). Trying to debug why setting the material to EMT_PARALLAX_MAP_SOLID causes eveything to go black, whereas EMT_SOLID works |
| 14:10 |
Taoki |
It's not lighting either, I tried enabling ambient light and same story |
| 14:11 |
Taoki |
**from lua |
| 14:13 |
celeron55 |
probably because here is no lighting |
| 14:14 |
|
hmmmm joined #minetest-dev |
| 14:14 |
Taoki |
Don't see why that should require lighting in a different way. I tried setting ambient lighting to it and same |
| 14:14 |
Taoki |
WB hmmmm :) |
| 14:14 |
hmmmm |
hi |
| 14:14 |
Taoki |
Nice work on that code. Haven't tried it yet but I'm glad it's on GIT, and I see a lot of changes |
| 14:14 |
hmmmm |
are you guys talking about shaders |
| 14:14 |
hmmmm |
dude |
| 14:14 |
hmmmm |
don't try it |
| 14:15 |
hmmmm |
it doesn't work |
| 14:15 |
hmmmm |
at all |
| 14:15 |
Taoki |
hmmmm: ok. And we're talking about me implementing parallax mapping. But for some reason it causes surfaces to go black |
| 14:15 |
hmmmm |
is that already a feature in irrlicht? |
| 14:17 |
Taoki |
Sure. Found two examples of how to use it and for everyone else it works |
| 14:17 |
Taoki |
Here's one: http://irrlicht.sourceforge.net/forum/viewtopic.php?t=42716 See the code sectin at the bottom of the first post |
| 14:17 |
Taoki |
I'm adding the same lines where material texture is set |
| 14:18 |
Taoki |
And I tried ambient light and diffuse on the material, same story |
| 14:18 |
Taoki |
So I don't think it's the lighting either |
| 14:18 |
hmmmm |
could it have something to do with the alpha channel? |
| 14:18 |
hmmmm |
most likely it's a bug with irrlicht itself |
| 14:19 |
hmmmm |
just make sure makeNormalMapTexture isn't being called twice (as the problem is stated in that forum you linked) |
| 14:19 |
Taoki |
I'm trying a temporary test that applies it to all textures. Most have no alpha channel |
| 14:20 |
Taoki |
hmmmm: Currently I'm trying even without the normal texture. Simply setting the material type to EMT_PARALLAX_MAP_SOLID breaks it |
| 14:22 |
* Taoki |
will also want to implement envmap or cubemap reflections... hopefully these go well |
| 14:26 |
Taoki |
celeron55: Where exactly is that one line of code that applies the lighting system in MineTest to the material of nodes? Might help to take a look at it |
| 14:29 |
Taoki |
http://pastebin.com/raw.php?i=y9UKjFbb And to make sure it's not the lighting, I also smashed in the lines http://pastebin.com/raw.php?i=JpKrJw31 |
| 14:30 |
Taoki |
(and yes unknown_block.png is used in a temporary test circumstance, it's in the bin folder next to the minetest binary till I get the atlas working with it) |
| 15:12 |
celeron55 |
most things that seem like bugs in irrlicht actually aren't so 8) |
| 15:12 |
celeron55 |
irrlicht is such a thin wrapper for most parts that many bugs don't fit there |
| 15:15 |
Taoki |
Clearly what's happening isn't right. Since like I said I set some Irrlicht lighting too to test and same problem |
| 15:17 |
celeron55 |
maybe you have to explicitly enable lighting |
| 15:17 |
Taoki |
I set the lighting flag to 1 as well, same thing |
| 15:17 |
Taoki |
erm, to true |
| 15:17 |
Taoki |
like material.setFlag(video::EMF_LIGHTING, true); |
| 15:18 |
Taoki |
But parallax shouldn't use lighting different than existing materials, so it should work with the current light system |
| 15:18 |
celeron55 |
maybe mapblock_mesh.cpp:1069 |
| 15:23 |
|
PilzAdam joined #minetest-dev |
| 15:24 |
Taoki |
doesn't change anything either |
| 15:46 |
|
jin_xi joined #minetest-dev |
| 15:57 |
Taoki |
damn. It seems I have to add an irrlicht light entity before parallax mapping works. It needs new lighting... no idea why |
| 15:58 |
Taoki |
Problem is however, that during my test I'm among the first to see a MineTest scene with dynamic lighting :) I got that working without even intending to, and it looks pretty fine |
| 15:58 |
Taoki |
Maiybe I can post a screenshot. I'm so tempted to work on implementing this now, but I don't know how sunlight can be kept from shining in caves :( |
| 15:59 |
Taoki |
I'm also getting an envmap reflection for an unknown reason |
| 16:02 |
Taoki |
I'll try to see if I can somehow get textures to make a screenshot, just so everyone can see the MT world with dynamic Irrlicht lighting |
| 16:06 |
Taoki |
Damn this looks good :) |
| 16:07 |
Taoki |
OMG, I got it working with good textures! Not parallax (that's still buggy) but dynamic lighting |
| 16:08 |
Taoki |
Guess what: It doesn't reduce any performance either |
| 16:09 |
Taoki |
http://i46.tinypic.com/j5fd35.png That's with one static light entity added to the world |
| 16:12 |
celeron55 |
it looks like generic basic 3d stuff, not interesting at all |
| 16:15 |
Taoki |
celeron55: It looks a lot like the current lighting, but it's directional. So eg: surfaces facing the sun will be lit, and everything else only affected by ambiental lighting. |
| 16:15 |
celeron55 |
yeah; go in a cave |
| 16:15 |
celeron55 |
or under a tree |
| 16:15 |
Taoki |
Thing is, the Irrlicht lighting system is needed for many other features to work (in terms of visual improvements). I have toa bandon parallax mapping till then for instance |
| 16:15 |
Taoki |
I know, I know |
| 16:16 |
Taoki |
That's why I'm pissed this is so hard to implement :P |
| 16:16 |
Taoki |
Also note: If this could be used instead, there would no longer be a need to generate lighting with the mapgen. Will be MUCH faster |
| 16:17 |
celeron55 |
that is never going to be plausible on old hardware |
| 16:17 |
Taoki |
Thing is that in the test I jsut did, tynamic light didn't decrease performance the slightest little bit. |
| 16:17 |
Taoki |
**dynamic |
| 16:17 |
celeron55 |
i've tested that multiple times myself already |
| 16:18 |
Taoki |
So that's another interesting point. Obviously I've no idea how it will be with a lot of torches |
| 16:18 |
Taoki |
hmm... ok |
| 16:18 |
celeron55 |
the thing is, hardware lighting is horrible without shaders |
| 16:18 |
Taoki |
Obviously both the old and new systems will be in place at best. And the client will be able to decide which to use |
| 16:19 |
Taoki |
I think I'll make a branch to play with this a little. Just see what I get for now... won't pretend I can suddenly get any of it working properly |
| 16:19 |
celeron55 |
yeah, it needs some experimentation |
| 16:19 |
Taoki |
Idea: We could use the current lighting system in MineTest, but instead of brightening the area "lit" by this system, use that as a mask for other lights |
| 16:20 |
Taoki |
But again, might need a shader |
| 16:20 |
Taoki |
I'll see what I can get, at least to get a taste of what it might be like |
| 16:20 |
Taoki |
For now I need to go, so BRB |
| 16:20 |
celeron55 |
the most interesting outcome would be to feed the voxel lighting data into a shader and use it there |
| 16:20 |
celeron55 |
(in addition to other stuff) |
| 17:02 |
|
Calinou joined #minetest-dev |
| 18:44 |
Taoki |
Back. Going to look into those lights some more |
| 18:56 |
Calinou |
Taoki: https://github.com/celeron55/minetest/pull/304 opinions? |
| 18:57 |
Taoki |
Calinou: Yes. Make that a server setting in minetest.conf instead if possible. And default it to that then I guess. Might be better to have a way to set it I think |
| 18:57 |
celeron55 |
Calinou: have you really tested it to look better or do you just imagine it to do that? |
| 18:58 |
Calinou |
yes, i tested it locally |
| 18:58 |
celeron55 |
because i don't know |
| 18:58 |
Calinou |
it does look better. by far |
| 18:58 |
Calinou |
celeron55: maybe host a server with that patch :) and se |
| 18:58 |
Calinou |
see* |
| 18:58 |
Taoki |
I say default it to that, but please make it a minetest.conf setting. Might be best if it can be tweaked... if other devs agree too |
| 18:58 |
Calinou |
serverside minetest.conf setting would be ok too |
| 18:59 |
celeron55 |
it shouldn't make much difference unless there is some other problem somewhere |
| 18:59 |
Calinou |
people see other people turning more fluidly |
| 18:59 |
Calinou |
also, jumping |
| 19:01 |
Taoki |
It surely will be a lot better. But again, please do make it a minetest.conf setting |
| 19:01 |
Calinou |
Taoki: /msg Taoki 80.118.209.33 port 30000 |
| 19:01 |
Calinou |
fail |
| 19:01 |
Calinou |
I tried to pm... lol |
| 19:01 |
Taoki |
hehe, it's ok |
| 19:01 |
Calinou |
well then, feel free to connect |
| 19:01 |
Taoki |
I'll join |
| 19:01 |
Calinou |
(use my patch!!) |
| 19:01 |
Calinou |
you have to use my patch and recompile of course |
| 19:01 |
Taoki |
Do I need to? I thought the server sends it |
| 19:01 |
Calinou |
since the timer is client side |
| 19:01 |
Calinou |
nope |
| 19:01 |
Taoki |
ahhh, weird. Ok then |
| 19:02 |
Calinou |
(also, this is a nice security bug... set it to 100, overflow ;)) |
| 19:02 |
Taoki |
It's one line of code so I'll do it manually |
| 19:02 |
Calinou |
works too |
| 19:02 |
Taoki |
I'm trying toa dd dynamic lighting some, damn hard tho |
| 19:02 |
darkrose |
it can have a min/max in client side config |
| 19:03 |
Taoki |
Yeah. So trolls won't use it to lag a server |
| 19:03 |
Calinou |
making the setting clientside is another option, maybe, force minimum to 5, maximum to 20 |
| 19:03 |
Calinou |
and default 10 |
| 19:03 |
Calinou |
(20 would be useful for specific cases, eg. videos) |
| 19:03 |
Calinou |
where you need high accuracy :) |
| 19:03 |
celeron55 |
Calinou: i ask you to try what changing the value in environment.h:209 to 0.2 does, when the client sends 5 times a second |
| 19:04 |
Taoki |
Calinou: Is your server up? Won't connect here |
| 19:04 |
celeron55 |
because it could be just a problem of the sends being not in sync, rather than not being frequent enough |
| 19:04 |
Calinou |
nope, not frequent enough, definitely. the difference is big between 5 and 10, 10 feels much more smooth |
| 19:05 |
Calinou |
i tried changing the amount of smoothing, but it didn't really look good (forgot where) |
| 19:05 |
celeron55 |
you didn't try what i asked |
| 19:05 |
Taoki |
Server's down, let me know when it will be up |
| 19:05 |
Calinou |
celeron55: do i do that while keeping player position frequency to 0.2? or set it to 0.1 like in my patch? |
| 19:06 |
Calinou |
Taoki: weird, it is up here.. |
| 19:06 |
celeron55 |
Calinou: the smoothing code probably gets screwed up as the server sends two same positions and then two same positions and so; there are two ways to fix that: either raise the client send frequency to 10, or lower the server send frequency to 5 |
| 19:06 |
celeron55 |
Calinou: both to 0.2 |
| 19:06 |
Taoki |
You probably mentioned a bad ip or port then\ |
| 19:07 |
Calinou |
done, recompiling |
| 19:07 |
Calinou |
ERM |
| 19:07 |
Taoki |
Calinou: Do I keep the change client-side? |
| 19:07 |
Calinou |
the internal IP I forwarded is my printer's O_o |
| 19:07 |
Taoki |
lol |
| 19:07 |
Calinou |
:p |
| 19:07 |
Calinou |
fixing it |
| 19:08 |
Taoki |
The first user to run minetest on their printer :3 |
| 19:08 |
Calinou |
try again Taoki |
| 19:08 |
Taoki |
works now |
| 19:08 |
Calinou |
celeron55: i bet this won't fully fix the issue (this doesn't fix turning not being smooth enough) |
| 19:08 |
Taoki |
someone else join so we can compare |
| 19:08 |
Calinou |
if someone spins rapidly in one direction then another, other players might see nothing |
| 19:09 |
celeron55 |
if it fixes moving, then the right fix to turning is to smooth turning |
| 19:09 |
celeron55 |
it's not like 10 sends per second would fix turning, it just improves it a bit |
| 19:09 |
celeron55 |
for smooth turning, smooth turning must be implemented rather than flooding packets |
| 19:10 |
Calinou |
it's not really flooding, some games send position 20-30 times a second ;) (like sauerbraten) |
| 19:10 |
Calinou |
sends 30fps in best conditions |
| 19:10 |
Calinou |
iirc |
| 19:10 |
Calinou |
but the more you lag the less you send, of course |
| 19:11 |
celeron55 |
well, 10 isn't too much, but i don't want to raise it unnecessarily |
| 19:11 |
Taoki |
BTW, a way to reduce bandwidth usage: When a player is staying still and hasn't moved, is its position still being sent? Both by server and clients |
| 19:11 |
Calinou |
it is iirc |
| 19:11 |
Taoki |
It should't IMO since there's no reason to |
| 19:11 |
Calinou |
methinks "turning" and "moving" should be separate packets |
| 19:11 |
Calinou |
like in minecraft |
| 19:11 |
celeron55 |
it's beneficial to have small bandwidth consumption, because it makes huge servers and crappy connections more viable |
| 19:12 |
celeron55 |
Calinou: minecraft does not have packets; it uses tcp which is a stream protocol |
| 19:12 |
celeron55 |
Calinou: you can't compare it |
| 19:12 |
Calinou |
I spawned a random input player, it doesn't look any better than if I didn't use your change.. |
| 19:13 |
Calinou |
it did look better when I used 10fps |
| 19:13 |
Taoki |
lol, didn't know about thsse :P Is it a mod |
| 19:13 |
celeron55 |
in minetest, sending a packet actually sends a single packet; in minecraft using TCP, sending a virtual packet either sends it or waits for a bit for more data to put into the packet, and then sends it |
| 19:13 |
celeron55 |
so it makes sense to put many things in a packet |
| 19:13 |
Calinou |
Taoki: random_input = true in minetest.conf |
| 19:14 |
Taoki |
fun fun |
| 19:14 |
Calinou |
celeron55: well I think it should be set to 10fps, and disable sending positions when you don't move :) would compensate somewhat |
| 19:14 |
celeron55 |
that makes sense |
| 19:15 |
Calinou |
i suggested this yesterday, since pitch is sent, why not make the player model pitch when looking up/down? not very realistic (since the whole model will pitch) but better than nothing |
| 19:15 |
Taoki |
turning should also be transitioned client-side, like movement is |
| 19:15 |
Calinou |
probably easy to do |
| 19:16 |
Taoki |
So it doesn't snap but turn smoothly |
| 19:16 |
Calinou |
yeah |
| 19:16 |
Calinou |
i suck at c++ so i didn't tyr |
| 19:16 |
Calinou |
try* |
| 19:16 |
celeron55 |
i don't want player model pitching, it's not better, just odd |
| 19:16 |
Taoki |
it's ok, I do too and not sure how, but someone who knows should be able to do it easily |
| 19:17 |
Calinou |
celeron55: when you're looking up/down, mining stuff but looking "normal" to other players, it does feel odd |
| 19:17 |
Taoki |
Calinou: Anyway, I don't see a big improvement on your server really. Player seems to be pretty much as smooth |
| 19:17 |
hmmmm |
what |
| 19:17 |
Calinou |
Taoki: i send 5fps + celeron55's improvement |
| 19:17 |
Calinou |
let me come back with 10fps |
| 19:17 |
Taoki |
sure, lets try that |
| 19:17 |
celeron55 |
by the way, "some players will set it very high (eg. 50 per second), using lots of bandwidth for the server and other clients..." is completely wrong |
| 19:17 |
Taoki |
send 10fps from the server so we can see if that makes a difference |
| 19:17 |
hmmmm |
even if we used shaders, it turns out to be ~3x slower |
| 19:18 |
celeron55 |
the server sends the positions at a static interval, when it sends |
| 19:18 |
hmmmm |
which is the reason why it was abandonded in the first place |
| 19:18 |
Taoki |
hmmmm: Shaders? Where where where :D |
| 19:18 |
hmmmm |
Kahrl's repository |
| 19:18 |
celeron55 |
did you try it |
| 19:18 |
hmmmm |
i don't have a link handy though |
| 19:18 |
Calinou |
Taoki: come back and see |
| 19:18 |
Taoki |
Do those still work with latest master? Would be nice if they do |
| 19:18 |
Taoki |
Ok, logging back in |
| 19:19 |
Taoki |
Ahh yes, now I can feel a difference. It's smoother a bit |
| 19:20 |
Taoki |
the 10 fps instead of 5fps on ths server helps. The client update interval, not sure if that too |
| 19:20 |
Taoki |
Maybe only when both are done |
| 19:21 |
Taoki |
My suggestion is pussing it for both the server and client in minetest.conf |
| 19:21 |
Taoki |
*putting |
| 19:21 |
celeron55 |
the server already sends 10 |
| 19:21 |
Calinou |
but it looks like 5 since clients send 5 |
| 19:21 |
celeron55 |
it sends object messages (position and whatever) in the same packet |
| 19:21 |
celeron55 |
(it doesn't send anything if nothing moves) |
| 19:22 |
celeron55 |
so... actually it probably sends 5 per second if clients send 5 per second, if there are no other moving entities |
| 19:22 |
Taoki |
BTW. At the current moment (with and without the change) how much bandwidth does MineTest use? Both server and client. I'm curious |
| 19:22 |
Taoki |
In kbps |
| 19:23 |
celeron55 |
in what situation |
| 19:23 |
Taoki |
Well, idly for instance. When there are an average number of players on a server, some moving, some standing |
| 19:23 |
Calinou |
one player on my server, 1-3kbyte/sec outgoing |
| 19:23 |
Calinou |
better than MC which uses 20-40kbyte/sec outgoing |
| 19:23 |
Calinou |
-for one player- |
| 19:24 |
hmmmm |
oh, on that note, what does everybody say about increasing the server tick default to .25? |
| 19:24 |
Calinou |
(with the 10fps patch) |
| 19:24 |
Calinou |
default tick is 0.05, no? |
| 19:24 |
hmmmm |
it is, but that's really low |
| 19:24 |
Calinou |
"0.10 ought to be enough for everybody" --RMS |
| 19:24 |
Calinou |
fits 99% of uses |
| 19:24 |
celeron55 |
0.10 would be a good default |
| 19:24 |
Taoki |
yeah |
| 19:24 |
celeron55 |
0.25 is very slow, it already kills gameplay much |
| 19:24 |
Calinou |
(like player pos FPS ;)) |
| 19:25 |
hmmmm |
I had it up to as high as .35 and it seems fine (for me) |
| 19:25 |
Taoki |
Anyway, a more important change about player position sending, if you can add it: Don't send either from client to server or server to clients if the position and rotation of an object haven't changed. There's no need to waste bandwidth for players who are standing and doing nothing |
| 19:25 |
Taoki |
And it's easy to check. Just store an old_position and old_rotation vector, and check them if updated |
| 19:26 |
celeron55 |
hmmmm: it doesn't matter as long as you don't have moving animals or anything like that, and also it will limit the send interval that we were talking about |
| 19:26 |
Taoki |
On both client and server |
| 19:26 |
Taoki |
Same for lua entities, not just players. This will be important when mods will add a lot |
| 19:26 |
celeron55 |
if clients send position every 0.1s by default, then the server should tick at at least 0.1s as default |
| 19:27 |
Taoki |
Agreed |
| 19:27 |
Taoki |
Server tick is another thing I'd recomment making a setting in minetest.conf |
| 19:27 |
celeron55 |
0.05 is excessive though, this is not an FPS or something... |
| 19:27 |
celeron55 |
Taoki: it is |
| 19:28 |
Taoki |
ah good |
| 19:28 |
celeron55 |
i recommend reading through the example config |
| 19:28 |
Taoki |
Ies 0.05 sounds like more than needed to me too |
| 19:28 |
celeron55 |
the things aren't there for no reason |
| 19:28 |
Taoki |
0.1 shouldn't make any visible difference compared to that |
| 19:29 |
hmmmm |
on my old machine, Minetest took up a consistent 30-50% cpu in system time |
| 19:29 |
hmmmm |
which was ridiculous imo |
| 19:29 |
celeron55 |
the server? |
| 19:29 |
hmmmm |
well, singleplayer |
| 19:29 |
hmmmm |
so yes |
| 19:29 |
celeron55 |
the client uses practically all of available CPU for rendering |
| 19:29 |
celeron55 |
don't blame the server |
| 19:30 |
hmmmm |
no, no, i had fps_max set. |
| 19:30 |
hmmmm |
to 30 |
| 19:30 |
Taoki |
Isn't GPU used for rendering, and CPU for calculating other things? |
| 19:30 |
hmmmm |
the cpu will spin around and keep rendering |
| 19:30 |
celeron55 |
the way minetest draws things makes a lot of CPU usage |
| 19:31 |
celeron55 |
(that is, in small pieces) |
| 19:31 |
Calinou |
setting FPS to 10 also allows seeing players punching, when they hold mouse for less than 0.2 sec :( |
| 19:31 |
Taoki |
ok. That's ok, good CPU here so I don't mind |
| 19:31 |
Calinou |
:)* |
| 19:31 |
Taoki |
Just wish FPS was higher when "full view range" is enabled |
| 19:31 |
Taoki |
BRB |
| 19:31 |
celeron55 |
not like "world mesh + players" but like "mapblock + mapblock + mapblock + mapblock + mapblock + mapblock + mapblock with another rendering material + ..." |
| 19:31 |
Calinou |
it's impossible unless you have a NASA mainframe, full view range draws a lot of triangles... |
| 19:31 |
Calinou |
1 million+ easily |
| 19:32 |
hmmmm |
yeah, but the problem with saying that is you're giving it the "Works on my machine" seal of approval |
| 19:32 |
celeron55 |
minetest really struggles on my machine |
| 19:32 |
celeron55 |
this is an intel GMA950 with a 1600x1200 display |
| 19:32 |
hmmmm |
but you have a stronger cpu, no? |
| 19:32 |
Calinou |
my shit connection manages to host 6-8 players with no lag, even with the patch |
| 19:32 |
celeron55 |
centrino duo @ 1.6GHz |
| 19:32 |
celeron55 |
throttles down due to heat though |
| 19:33 |
hmmmm |
ouch |
| 19:33 |
Calinou |
how many RAM? |
| 19:33 |
hmmmm |
i wonder how it'd stack up against an athlon 64 3500+ |
| 19:33 |
celeron55 |
Calinou: 2 |
| 19:33 |
celeron55 |
hmmmm: that sounds similar to my server, a 3GHz P4 |
| 19:33 |
hmmmm |
and 1gb ram |
| 19:33 |
celeron55 |
it's quite similar |
| 19:33 |
Calinou |
a raspi is still slower, wait a few years and they'll be better :P |
| 19:33 |
celeron55 |
in performance |
| 19:34 |
celeron55 |
well, mobile phones are still a tiny bit slower than this laptop 8) |
| 19:34 |
hmmmm |
you see, even though now i have a cpu equivalent to an ivy bridgde i7, i still am going to test my stuff on the athlon 64 |
| 19:34 |
celeron55 |
except that they have more GPU power |
| 19:34 |
celeron55 |
maybe |
| 19:34 |
celeron55 |
at least shader power |
| 19:34 |
hmmmm |
right |
| 19:35 |
hmmmm |
so back on topic, change the default server step to .1 |
| 19:35 |
celeron55 |
i have a 3.4 or so GHz i3 with 4GB of RAM, but it's boring; i don't generally use it, and also the sandy bridge GPU sucks balls with minecraft and minetest because it is so slow at taking new vertex data into use |
| 19:36 |
celeron55 |
works fine for normal games that just load everything and then play, but for these... no way |
| 19:36 |
hmmmm |
and i wasn't aware that the position packet send was a separate setting from the server step |
| 19:36 |
celeron55 |
that makes the choppy FPS that is known within MC players 8) |
| 19:36 |
hmmmm |
what if they were always the same, the clients can negotiate with the server for the interval |
| 19:37 |
hmmmm |
and instead of it being the "server step" and the "client step" it can be just the "step" |
| 19:37 |
celeron55 |
ehm |
| 19:37 |
celeron55 |
are you seriously suggesting running the client at a lower rate than the FPS is? |
| 19:37 |
celeron55 |
that'll make some really choppy stuff |
| 19:37 |
hmmmm |
no, just the send interval |
| 19:38 |
hmmmm |
you don't need to seriously send a packet *every* single frame, do you? |
| 19:38 |
celeron55 |
i didn't say that |
| 19:39 |
celeron55 |
anyway... |
| 19:39 |
celeron55 |
it might be a good idea to make client use the same interval as the server does |
| 19:39 |
celeron55 |
based on server configuration |
| 19:39 |
celeron55 |
same send interval, that is |
| 19:39 |
celeron55 |
...and that would be the same as the server step interval |
| 19:40 |
celeron55 |
hmm, i'll do those now |
| 19:41 |
Calinou |
letting clients choose their own rates is bad for fairness (especially for pvp) |
| 19:41 |
hmmmm |
yeah, the client will set the interval in TOCLIENT_INIT |
| 19:42 |
hmmmm |
when parsing* |
| 19:42 |
Calinou |
will the server step/player position rates be changed? |
| 19:43 |
celeron55 |
i'll make it stick to the server step interval |
| 19:44 |
Calinou |
ah, ok, good then :) |
| 19:44 |
Calinou |
gtg |
| 20:10 |
|
doserj joined #minetest-dev |
| 20:46 |
|
rsiska joined #minetest-dev |
| 20:55 |
celeron55 |
by the way, was this approved by, like, anyone? https://github.com/celeron55/minetest/commit/ffad18e42442fed10c312adc989fc62b74e05896 |
| 20:56 |
celeron55 |
it has the known issue of being heavy to render for HD texture packs due to the huge per-pixel generated meshes |
| 20:56 |
celeron55 |
it's not an issue for me, but surely for HD texture users |
| 20:58 |
celeron55 |
oh umm... |
| 20:58 |
celeron55 |
what does that even do |
| 20:59 |
VanessaE |
celeron55: one thing I've noticed, at least with HD textures, if the image has lots of holes (say, a checkerboard of white-hole/hole-white) it slows the extrude-for-wield down horribly |
| 20:59 |
celeron55 |
wtf does that do |
| 20:59 |
VanessaE |
like one 512px image takes *minutes* on a fast box. |
| 21:00 |
celeron55 |
it forces node items to look like nodes even if they have an inventory image |
| 21:00 |
celeron55 |
why was that put in |
| 21:00 |
VanessaE |
dunno, I didn't even get a chance to ask pilz about it |
| 21:00 |
VanessaE |
maybe related to RBA's new unified inventory mod. |
| 21:01 |
VanessaE |
he said he needs a hook to get the wielded appearance of every node/item registered by the game/engine. |
| 21:01 |
celeron55 |
i do not approve this |
| 21:02 |
VanessaE |
well, the build I have in place now has that commit. |
| 21:02 |
VanessaE |
is there something I can look for to say "it's broken"? |
| 21:02 |
celeron55 |
it's a change for no reason |
| 21:02 |
celeron55 |
that is the problem |
| 21:03 |
celeron55 |
the only thing it can do is break things |
| 21:03 |
celeron55 |
PilzAdam shall explain it tomorrow |
| 21:03 |
celeron55 |
(he should have explained it in the commit message) |
| 21:04 |
VanessaE |
RBA says it is *not* related to the inventory mod. |
| 21:22 |
Taoki |
back |
| 21:24 |
VanessaE |
wb |
| 21:29 |
Taoki |
Thanks. Thinking of the next changes to try working on now :) |
| 21:29 |
Taoki |
Pretty determined to get a WIP of dynamic lighting working to some extent. Undoubtfully a dead end till someone digufes out good shaders, but I so wanna see that a bit :) |
| 22:16 |
Taoki |
WTF? |
| 22:16 |
Taoki |
mesh.cpp line 465: smgr->addLightSceneNode(0, light_position, light_color, light_radius); There already is Irrlicht lighting in MineTest? |
| 22:17 |
Taoki |
An addLightSceneNode is the correct way to setup Irrlicht lighting, and what I tested with today. But in its case it's not directional. I wonder what use that line has... it exists in upstream, together with an ambient light |
| 22:20 |
Taoki |
Well it's part of GenerateTextureFromMesh lol... probably unused in any actual circumstance :P |
| 22:22 |
celeron55 |
ehm |
| 22:22 |
celeron55 |
it is used for making images from nodes to inventory and so |
| 22:23 |
Taoki |
oh, right then :P |
| 22:49 |
|
SpeedProg joined #minetest-dev |
| 23:40 |
Taoki |
VanessaE: I got the changes you wanted on a GIT branch. Hats work now. However, I forgot to set some material flags... a code change must also be merged |
| 23:41 |
VanessaE |
wonderful! |
| 23:41 |
Taoki |
celeron55, thexyz, darkrose: Can any of you please merge those two branches upstream? https://github.com/MirceaKitsune/minetest/tree/models_flags ---- and ---- https://github.com/MirceaKitsune/minetest_game/tree/player_extras |
| 23:41 |
Taoki |
The first one is of highest importance since I forgot some material flags for meshes, and they didn't allow transparency and weren't affected by fog |
| 23:42 |
Taoki |
The second adds hat support to fix some skins, and also a sit animation to be used by mods (like the carts or chairs) |
| 23:44 |
Taoki |
VanessaE: http://i50.tinypic.com/2ynroxs.png With hats working |
| 23:45 |
VanessaE |
perfect |
| 23:45 |
VanessaE |
you are a goddess, Taoki :-) |
| 23:45 |
Taoki |
awww |
| 23:45 |
Taoki |
Still around for 15 or so minutes, if anyone with upstream access can check this |
| 23:46 |
Taoki |
VanessaE: Don't use the new player update yet however. The code is needed to fix alpha channel, otherwise the head / hat will apperar black |
| 23:46 |
Taoki |
Clients need the code patch |
| 23:47 |
VanessaE |
I will wait until you and c55 are happy with it and merge it to git master. |
| 23:47 |
VanessaE |
make sure it is backwards compatible with the pre-hats code ;-) |
| 23:48 |
Taoki |
yes, it will be |
| 23:53 |
Taoki |
Just added a fix for the sit animation positioning, please use latest rev |
| 23:57 |
Taoki |
Also, to be clear: You can't animate the player sitting and mining at the same time. Please don't ask me to add that, it would be a waste of animation space. I already do a combined walk + mine animation since there's no other choice |
| 23:58 |
VanessaE |
oh that's more than fair - who sits and mines at the same time? :-) |
| 23:58 |
Taoki |
exactly :) |
| 23:59 |
Taoki |
BTW: I made the sit animation so that the player sits on the bottom of his origin / bounding box. This can already be used to sit on the ground even, and it looks great for that |
| 23:59 |
Taoki |
Will post a shottie |
