| Time |
Nick |
Message |
| 05:04 |
|
Bad_Command joined #minetest-dev |
| 05:04 |
|
Bad_Command joined #minetest-dev |
| 05:05 |
|
Bad_Command left #minetest-dev |
| 05:19 |
|
hmmmm joined #minetest-dev |
| 06:30 |
|
celeron55_ joined #minetest-dev |
| 08:15 |
|
jin_xi joined #minetest-dev |
| 10:45 |
|
Calinou joined #minetest-dev |
| 14:28 |
|
PilzAdam joined #minetest-dev |
| 15:10 |
|
hmmmm joined #minetest-dev |
| 15:20 |
RealBadAngel |
Hi, a quick question: when changing protocol version, protocol ID shall be changed too? |
| 15:21 |
celeron55_ |
never |
| 15:21 |
RealBadAngel |
thx |
| 15:22 |
celeron55_ |
the protocol id is there only to distinguish minetest packets from random data or some other protocol |
| 15:23 |
RealBadAngel |
k |
| 15:23 |
celeron55_ |
also i don't think you'll need to increase the protocol version for the addition of the flags to the end of the single packet; it'll be increased once something actually incompatible is added upstream (like taoki's stuff) |
| 15:24 |
PilzAdam |
RealBadAngel, if you change the protocol version you can move this back to correct place: https://github.com/celeron55/minetest/commit/0709918bd82ab942445e12aca5bceb85c6ce05e0 |
| 15:24 |
RealBadAngel |
hmmm, increasing size of the packet wont cause problems? |
| 15:24 |
celeron55_ |
PilzAdam: it will not be changed now |
| 15:24 |
RealBadAngel |
if the client will send more data? |
| 15:25 |
celeron55_ |
hmm... actually, you'd need to add a check for whether the packet is long enough in case an old client connects to a new server |
| 15:25 |
celeron55_ |
the other way there is zero problems |
| 15:27 |
RealBadAngel |
without new version checks should be on both sides, imho this would lead to just makin extra code |
| 15:28 |
RealBadAngel |
and after other update like Taoki's one the checks will become obsolete |
| 15:32 |
PilzAdam |
it would be nice if this would be developed further: http://c55.me/blog/?p=275 |
| 15:33 |
|
Taoki joined #minetest-dev |
| 15:37 |
RealBadAngel |
celeron55_, checks for the server alone could be done, but if the server will run the mods that will use the new feature that can lead to crashes or to incorrect behaviour at least |
| 15:38 |
RealBadAngel |
PilzAdam, ive seen some1 made mod called "betterchest" out of your carts box |
| 15:38 |
RealBadAngel |
wont it dissapear when used clearobjects? |
| 15:39 |
PilzAdam |
yep |
| 15:39 |
RealBadAngel |
servers alone can force clearing objects so such mod is unusable then, right? |
| 15:40 |
PilzAdam |
i guess so |
| 15:40 |
PilzAdam |
btw: https://github.com/Uberi/minetest/commit/0f3bd365e1d7e7c6dfe99d862923e78acd5aa70e <- Ive tested it and it works |
| 15:41 |
RealBadAngel |
so imho shall be added asap |
| 15:42 |
RealBadAngel |
using that greifers can crash servers |
| 15:42 |
Taoki |
Just a note: My models branch already upates protocol version to 14. If that will come soon after RBA's patch, there might be no need to increment it twice |
| 15:42 |
RealBadAngel |
how soon is soon? :) |
| 15:42 |
RealBadAngel |
may happen some folks will download it just meanwhile and start to scream somethin is wrong |
| 15:43 |
RealBadAngel |
numbers are infinite anyways |
| 15:43 |
Taoki |
RealBadAngel: After your key reading code is in, all that's needed is the script to handle animations and it will work for the most part |
| 15:43 |
Taoki |
The player script will need to be improved but that's the last remaining concern |
| 15:44 |
RealBadAngel |
celeron55_ ? |
| 15:44 |
RealBadAngel |
up to you |
| 15:44 |
Taoki |
All else works fine. Apart from an Irrlicht bug that causes bone positioning to break animations and the mesh so far... but Irrlicht will fix that in the future |
| 15:44 |
celeron55_ |
i already mentioned taoki's stuff up thre |
| 15:44 |
celeron55_ |
+e |
| 15:44 |
Taoki |
Also: The CODE part of my branch should be ok to merge as well. Not the script and player yet, but the code yes |
| 15:45 |
RealBadAngel |
Taoki, i think some1 posted here yesterday somethin bout this particular bug |
| 15:45 |
Taoki |
oh? |
| 15:45 |
Taoki |
Would be nice if someone could fix it, though it is not urgent. Just doesn't allow animation blending to work yet, and stuff like the head looking up / down |
| 15:45 |
RealBadAngel |
Taoki i pasted you start of todays talk |
| 15:45 |
Taoki |
yeah |
| 15:45 |
Taoki |
will read again maybe i missed it |
| 15:46 |
Taoki |
Yeah, that's about the protocol version. Read it |
| 15:47 |
Taoki |
In my opinion you can leave protocol version as is, since after that my code should be ok to merge soon. Models code can probably go in today also |
| 15:47 |
Taoki |
There might still be small bugs, but normally minor things. |
| 15:48 |
celeron55_ |
it is, of course, possible also to support multiple protocol versions in a single server version, but it generally is not worth the trouble |
| 15:51 |
Taoki |
Anyway: Once RBA's changes are in master, I'll update latest master, merge it in my branch, fix git conflicts if needed... and if no one knows any major bugs with the current models code, I can pull request it. Maybe it can even get in tonight... if small bugs exist they can be fixed on the way (surely no one will do major tests on the code until it's in, so it goes to large servers) |
| 15:51 |
Taoki |
Then I'll likely be finishing the scripts (will probably need help past some point) so the 3D player can be ready too |
| 15:51 |
RealBadAngel |
i need half an hour or so to make last changes to the patch and test it |
| 15:51 |
Taoki |
sure |
| 15:52 |
celeron55_ |
PilzAdam: re. http://c55.me/blog/?p=275: i might, but currently there is just too many things to worry about (and my other projects) in order to sink the required time to it |
| 15:53 |
RealBadAngel |
but the fix that PilzAdam mentioned is rather urgent |
| 15:53 |
PilzAdam |
already merged |
| 15:53 |
RealBadAngel |
afaik Landmine is using this to crash the servers |
| 15:55 |
celeron55_ |
landmine is quite useful; he's harmless and finds out problems before any actual bad guys 8) |
| 15:58 |
PilzAdam |
https://github.com/celeron55/minetest_game/pull/40 <- this is a matter of taste so i suggest we vote or something like this |
| 16:00 |
celeron55_ |
care to make screenshots of with and without? |
| 16:01 |
Taoki |
lol landmine. I seen him around here a few times. Some projects have "common trolls" which manage to stick around, and not do quite enough to get permanently bad |
| 16:01 |
Taoki |
Xonotic has one too, but he's way worse :P |
| 16:05 |
PilzAdam |
celeron55_, old: http://www.zimg.eu/i/1124599787 new: http://www.zimg.eu/i/2296078330 |
| 16:05 |
PilzAdam |
its after ~1/2 of the animation |
| 16:06 |
Taoki |
BTW. There's something else I wanted to ask about. Not sure if I can do it, but IMO that would be really nice and needed |
| 16:06 |
Taoki |
With the current lighting system, would it be posisble to allow for colored lighting? Lighting can't be given a color currently... that would be a relally nice feature |
| 16:07 |
celeron55_ |
not as-is, but somebody did once insist on implementing it, and did so |
| 16:07 |
celeron55_ |
it requires three times the computing power |
| 16:07 |
celeron55_ |
and roughly twice the space |
| 16:07 |
Taoki |
Nice. Is his code still around? |
| 16:07 |
Taoki |
Hmmm |
| 16:08 |
Taoki |
If it can be a client choice that should be fine |
| 16:08 |
celeron55_ |
the server has to do it too |
| 16:08 |
Taoki |
So if it's disabled the player sees all lights white |
| 16:08 |
Taoki |
ok. That could have it as a feature too, and only enable it if the server has enough power |
| 16:08 |
celeron55_ |
sounds complicated-ish, but anyway, umm... i wonder who did it |
| 16:09 |
celeron55_ |
(oh and also, it looks kind of dull with the vertex color based lighting) |
| 16:09 |
Taoki |
My aim is still to get real irrlicht lighting working, but it's hard to imagine a way around sun shining in caves. So this one I likely won't be able to do alone |
| 16:09 |
Taoki |
What I will once the models is over, is to try add support for some nice parallax mapping :) |
| 16:10 |
celeron55_ |
it was here, as a branch, but the guy has removed it https://github.com/Queatz/minetest/ |
| 16:10 |
Taoki |
ahhh, ok |
| 16:11 |
celeron55_ |
and i don't seem to have it pulled to my local repo |
| 16:12 |
celeron55_ |
this video exists http://www.youtube.com/watch?v=1MWZxyCsbv4 |
| 16:12 |
celeron55_ |
somebody probably has it if you ask around |
| 16:12 |
Taoki |
Damn, that looks so beautiful :( |
| 16:12 |
Taoki |
Yeah, totally should |
| 16:14 |
celeron55_ |
it's fairly trivial to implement though |
| 16:14 |
Taoki |
true... not the most important feature. But it will contribute to making the world even more beautiful and extended |
| 16:14 |
celeron55_ |
you basically just triple the light bytes in nodes and make the lighting code loop through all three channels |
| 16:16 |
Taoki |
Right. Does it noticeably decrease performance on older machines however? Can anyone confirm they sense a performance decrease? |
| 16:16 |
Taoki |
Since that doesn't sound like a lot more harder task |
| 16:20 |
celeron55_ |
i am not aware of how much of cpu time the lighting currently takes |
| 16:20 |
celeron55_ |
at map generation time it is already a real PITA |
| 16:20 |
celeron55_ |
but i don't know of the updates at other times |
| 16:21 |
Taoki |
Probably very little... calculating 1-3 integer values per node should be easy (I assume each lighting point is a value between 0 and 255) |
| 16:21 |
celeron55_ |
i wouldn't make any assumptions like that |
| 16:22 |
celeron55_ |
it's a recursive algorithm that generally has a range of 15 nodes to each direction |
| 16:23 |
celeron55_ |
in 3d space that isn't exactly lightweight |
| 16:23 |
Taoki |
I see |
| 16:26 |
celeron55_ |
also, there are already two values per node (day and light) |
| 16:26 |
celeron55_ |
night* |
| 16:26 |
celeron55_ |
or, actually not day and night, but rather "with sunlight" and "without sunlight" |
| 16:29 |
RealBadAngel |
im actually going to upgrade my box by the end of the yr |
| 16:29 |
RealBadAngel |
3 yrs old hardware is a bit too old |
| 16:30 |
RealBadAngel |
btw testing now the patch with changes |
| 16:32 |
RealBadAngel |
already wrote a letter to santa ;) |
| 16:32 |
RealBadAngel |
need SDD, some more RAM, better GFX and new MOBO |
| 16:33 |
RealBadAngel |
and quad core instead of dual |
| 16:35 |
RealBadAngel |
if santa will be kind enough maybe bigger lcd, and old one will go as secondary |
| 16:38 |
Taoki |
bbl, later |
| 16:39 |
PilzAdam |
is it ok to fix this two things in one commit? https://github.com/celeron55/minetest_game/pull/41 |
| 16:40 |
celeron55_ |
they're much related and small -> yes |
| 16:41 |
RealBadAngel |
what about torches being able to place underwater? |
| 16:41 |
PilzAdam |
anything against the commit? |
| 16:42 |
RealBadAngel |
its ok with me, shrubs on my cacti farm was makin me nervous ;) |
| 16:42 |
PilzAdam |
RealBadAngel, this is part of this problem: Water should flush walkable/buildable nodes away |
| 16:45 |
PilzAdam |
i had several attempts to do this in Lua, but it is all too slow |
| 16:46 |
RealBadAngel |
water spread code should be the place |
| 16:48 |
celeron55_ |
i guess liquids flushing buildable_to nodes could be added |
| 16:49 |
celeron55_ |
it's not even a group so making a fast check in C++ is like doing nothing |
| 16:49 |
PilzAdam |
this wouldnt effect torches; i would prefer walkable |
| 16:49 |
celeron55_ |
you mean non-walkable? |
| 16:49 |
PilzAdam |
this walkable thing confuses me all the time ;-) |
| 16:49 |
celeron55_ |
walkable is more like "collidable" or "solid" but whatever |
| 16:49 |
celeron55_ |
there is a problem with that |
| 16:49 |
PilzAdam |
i always think walkable=you can walk into the node |
| 16:50 |
celeron55_ |
for example snow |
| 16:50 |
celeron55_ |
and other very small nodeboxes |
| 16:50 |
|
rubenwardy joined #minetest-dev |
| 16:50 |
PilzAdam |
add a field water_resistent? |
| 16:50 |
PilzAdam |
*flushable; default = true |
| 16:51 |
celeron55_ |
i guess making the check to be (buildable_to == true || walkable == false) could work |
| 16:51 |
celeron55_ |
i don't think a new field is a good way at all |
| 16:52 |
celeron55_ |
it should just work |
| 16:53 |
PilzAdam |
<celeron55_> and other very small nodeboxes <- what do you mean exactly? |
| 16:53 |
celeron55_ |
snow mod. |
| 16:53 |
celeron55_ |
put water on snow |
| 16:54 |
PilzAdam |
ah, okay |
| 16:54 |
celeron55_ |
and now i'm off to something else, i'll seriously burn out if i try to answer even half of your stuff |
| 16:54 |
celeron55_ |
-> |
| 16:55 |
PilzAdam |
heh |
| 16:55 |
|
SpeedProg joined #minetest-dev |
| 16:59 |
|
sstrandberg joined #minetest-dev |
| 17:01 |
RealBadAngel |
celeron55_, im ready with testing the patch. now the question remains bout protocol change. |
| 17:11 |
|
Calinou joined #minetest-dev |
| 17:23 |
|
rubenwardy1 joined #minetest-dev |
| 17:42 |
|
sstrandberg joined #minetest-dev |
| 18:06 |
RealBadAngel |
celeron55_, are you there? what shall i do with protocol version? |
| 18:08 |
PilzAdam |
<celeron55_> and now i'm off to something else [...] |
| 18:09 |
|
jin_xi joined #minetest-dev |
| 18:10 |
RealBadAngel |
and im here with finished patch, and Taoki expecting to get it today |
| 18:10 |
RealBadAngel |
to merge 3D players |
| 18:11 |
RealBadAngel |
i think adding extra checks, when next update make them obsolete is pointless |
| 18:11 |
RealBadAngel |
so im adding protocol version change and posting the final patch |
| 18:19 |
|
Taoki joined #minetest-dev |
| 18:53 |
|
rubenwardy joined #minetest-dev |
| 19:03 |
|
Taoki joined #minetest-dev |
| 19:49 |
|
Taoki joined #minetest-dev |
| 20:12 |
|
rubenwardy left #minetest-dev |
| 20:40 |
|
doserj joined #minetest-dev |
| 21:00 |
|
doserj joined #minetest-dev |
| 21:57 |
|
doserj joined #minetest-dev |
| 22:14 |
|
darkrose joined #minetest-dev |
| 22:14 |
|
darkrose joined #minetest-dev |
| 22:36 |
|
ssstrandberg joined #minetest-dev |
| 22:40 |
|
sstrandberg joined #minetest-dev |
