| Time |
Nick |
Message |
| 00:38 |
sofar |
well dammit, I fixed culling for older version, but now it's broken for latest :( |
| 00:41 |
sofar |
ohhh man, ContentFeatures has it's own version number :((( |
| 00:43 |
Fixer |
lol |
| 00:45 |
sofar |
this is anything but hilareous at this point |
| 00:46 |
sofar |
third revision of a fix :( |
| 00:56 |
kaadmy |
hilarious* |
| 01:00 |
sofar |
it isn't. nor will I ever spell that right ... I'm not a native english speaker. |
| 01:04 |
sofar |
now I need to dig the servers' protocol version out in the client... somehow |
| 01:04 |
sofar |
I don't even know if it sends it |
| 01:10 |
|
red-001 joined #minetest-dev |
| 01:12 |
* red-001 |
is making beds meshes |
| 01:44 |
sofar |
ok, I can see the server sending the server protocol version to the client |
| 01:44 |
sofar |
now where the heck is it stored? |
| 02:00 |
frustrat1d |
is there a proper way to cause the digging cracking animation to happen on a node via the lua api? |
| 02:00 |
frustrat1d |
for example, if a mob is digging a node |
| 02:09 |
kaadmy |
not really afaik |
| 02:09 |
kaadmy |
the crack is drawn client-side |
| 02:13 |
ShadowNinja |
Merging #3433. |
| 02:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/3433 -- Fix world config menu ignoring `name` in `mod.conf`. by kaeza |
| 02:21 |
sofar |
ShadowNinja: do you know if the client holds the server version somewhere? |
| 02:22 |
ShadowNinja |
sofar: It uses the protocol version, but not the "human friendly" version. |
| 02:23 |
sofar |
I can't find anywhere during deserialization of nodedef data what the heck it is |
| 02:24 |
sofar |
what do you mean by "not human friendly version"? |
| 02:25 |
frustrat1d |
thanks kaadmy. does anyone know of a mod off hand where they are simulating it with an entity? |
| 02:54 |
sofar |
hmmmm: do you know how to get a handle on Client::m_server_ser_ver or Client::m_proto_ver in nodedef.cpp? |
| 02:55 |
sofar |
I'm scratching my head over this... honestly I thought the client side deserialization would be using it already somewhere |
| 02:55 |
hmmmm |
they're passed as parameters to ContentFeatures::deSerialize() |
| 02:55 |
sofar |
void ContentFeatures::deSerialize(std::istream &is)� |
| 02:56 |
sofar |
I don't see that |
| 02:57 |
hmmmm |
CNodeDefManager::deSerialize rather |
| 02:57 |
sofar |
same, only has the input stream as well |
| 02:57 |
sofar |
void CNodeDefManager::deSerialize(std::istream &is) |
| 02:58 |
hmmmm |
hm you're right, it's deSerializeOld that that has the parameter |
| 02:58 |
sofar |
wrong, that's not the server protocol version |
| 02:58 |
sofar |
that's the nodedef version |
| 02:58 |
hmmmm |
what are you trying to do exactly? force a ContentFeatures to get deserialized with a version different than what you need? |
| 02:58 |
hmmmm |
err than what it is |
| 02:58 |
hmmmm |
I don't get it |
| 02:59 |
sofar |
the problem is that some data has been serialized since version 20 or so |
| 02:59 |
sofar |
and a recent patch by me changes it to actually use that information |
| 02:59 |
sofar |
but if a new client connects to an old server, the client needs to disregard that data |
| 02:59 |
hmmmm |
so you want to use the /protocol/ version to determine how to parse a ContentFeatures? |
| 02:59 |
hmmmm |
this is incorrectly designed |
| 03:00 |
sofar |
I have no choice |
| 03:00 |
hmmmm |
then make a new ContentFeatures version. |
| 03:00 |
sofar |
that would make the server incompatible with all old clients |
| 03:00 |
hmmmm |
what you're trying to do stinks, badly |
| 03:01 |
hmmmm |
there is a major design flaw in all of this and i don't know how to fix it without knowing all the context of your problem |
| 03:01 |
hmmmm |
sorry I can't be of more help |
| 03:01 |
sofar |
easy enough, the code is in these 2 PRs: |
| 03:01 |
sofar |
https://github.com/minetest/minetest/commit/882a89d65aa78b89cfaf2af054d15cc4c94ad022 |
| 03:01 |
sofar |
https://github.com/minetest/minetest/commit/735e3b70596e16d04de1edcd878deec3c539c6ed |
| 03:02 |
sofar |
I made the mistake in the second commit (735e3b7) to assume that the version number there was the server version |
| 03:02 |
sofar |
but it's the nodedef version |
| 03:03 |
hmmmm |
i don't quite understand why you're making backface culling a node-level option |
| 03:03 |
hmmmm |
this has to do with the drawtype |
| 03:03 |
sofar |
simple reason: I found that people wanted it enabled for mesh nodes |
| 03:03 |
sofar |
and it's already being serialized/deserialized since v20 or so |
| 03:04 |
sofar |
we have the right data, it just wasn't being used |
| 03:04 |
sofar |
then the problem becomes: new client connects to old server, and sees values that are wrong (old servers just put "true" irregardless) |
| 03:05 |
hmmmm |
so you want there to be an option to enable backface culling for mesh nodes in the case where the mod author knows better that it would be acceptable in this case |
| 03:05 |
sofar |
so for mesh, firelike, liquid and one more we need to ignore it when connecting to an old server |
| 03:05 |
hmmmm |
the drawtype determines the backface culling |
| 03:05 |
sofar |
yes, backface culling defaults do not change |
| 03:05 |
sofar |
it's enabled for all except the 4 special ones |
| 03:06 |
sofar |
for those remaining 4 nodes, clients v27 will honor the tiledef setting if on the server mods enable it for nodes |
| 03:06 |
hmmmm |
backface culling has been an independent field in a serialized ContentFeatures for a long time, correct? |
| 03:06 |
sofar |
exceept it only had meaning in SpecialTiles |
| 03:06 |
hmmmm |
oh |
| 03:07 |
hmmmm |
so backface culling is an option in a serialized TileDef |
| 03:07 |
sofar |
but it was serialized in tiles as well |
| 03:07 |
hmmmm |
s/option/field/ |
| 03:07 |
sofar |
yes, tileDef |
| 03:07 |
hmmmm |
and now you want the older clients to not ignore backface culling for regular tiles |
| 03:07 |
sofar |
inverse |
| 03:07 |
sofar |
new clients to old servers |
| 03:07 |
sofar |
and new clients to new servers |
| 03:08 |
hmmmm |
so for a new client to old servers you want the new client to do what now |
| 03:08 |
sofar |
older clients already ignore it, and they work fine |
| 03:08 |
sofar |
so right now, due to the bug in 735.. |
| 03:09 |
sofar |
if a new client connect to an old server, culling is disabled for mesh nodes |
| 03:09 |
sofar |
but |
| 03:09 |
sofar |
if a new client connect to an new server, culling is disabled for mesh nodes |
| 03:09 |
sofar |
even if the server tells the client that it should cull the nodedef |
| 03:09 |
hmmmm |
why is that exactly? |
| 03:09 |
hmmmm |
new client to a new server should not ignore any of the fields |
| 03:10 |
hmmmm |
you just change the logic in the client to not ignore them |
| 03:10 |
sofar |
well it's because deSerialize() doesn't know it's a new server |
| 03:10 |
hmmmm |
or is it that you want the new clients to keep ignoring the fields for old servers? |
| 03:10 |
sofar |
the code is there to ignore it for old servers |
| 03:10 |
hmmmm |
so the desired behavior is: ignore for old servers, don't ignore for new servers |
| 03:10 |
hmmmm |
right? |
| 03:10 |
sofar |
with the one bit missing... the server version |
| 03:10 |
sofar |
yes |
| 03:10 |
* hmmmm |
processing |
| 03:11 |
sofar |
https://github.com/minetest/minetest/commit/735e3b70596e16d04de1edcd878deec3c539c6ed#diff-70868aa6d6b96c0c1623c761500d23c4R348 |
| 03:11 |
sofar |
that line right there (348) |
| 03:11 |
sofar |
in that line I need "m_server_ser_ver" instead of "version" |
| 03:11 |
sofar |
and same on line 1287 |
| 03:12 |
hmmmm |
in this situation, what I would do is add a new field |
| 03:12 |
hmmmm |
and bump the contentfeatures version |
| 03:12 |
hmmmm |
there really is no way to access m_srever_ser_ver there |
| 03:13 |
hmmmm |
and add a nice big comment explaining why you added a new field instead of using the old one that was ignored by clients |
| 03:13 |
hmmmm |
it sucks, sure, but this is the cleanest way to do it imho |
| 03:14 |
sofar |
ok, so then |
| 03:14 |
sofar |
say I add a "use_tiledef_culling" bool |
| 03:14 |
sofar |
the new server can send it, sure |
| 03:14 |
sofar |
but the old version never does? |
| 03:15 |
hmmmm |
right |
| 03:15 |
sofar |
I can't just read a value that's never sent |
| 03:15 |
hmmmm |
so from the new client's perspective, if the field doesn't exist, that means it's false |
| 03:16 |
hmmmm |
sure you can |
| 03:16 |
hmmmm |
see that try { } catch (SerializationError ... block? |
| 03:19 |
sofar |
hmmm |
| 03:28 |
|
kaeza joined #minetest-dev |
| 03:57 |
sofar |
hmmmm: ok, yes, that works out. |
| 04:04 |
sofar |
hmmmm: #3608 |
| 04:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/3608 -- Backface culling once more: We don't know the server vers. by sofar |
| 04:51 |
|
est31 joined #minetest-dev |
| 04:53 |
est31 |
<hmmmm>in this situation, what I would do is add a new field |
| 04:53 |
est31 |
and bump the contentfeatures version |
| 04:54 |
est31 |
I dont think that bumping the contentfeatures version is neccessary or useful here |
| 04:54 |
est31 |
after all you want to spare a bump of the network protocol version, right? |
| 04:55 |
est31 |
but bumping contentfeatures version requires a bump of the network protocol as well |
| 04:55 |
est31 |
bc the contentfeatures version isn't negotiated at the connection |
| 04:56 |
est31 |
but instead the server has to know it for sure |
| 04:57 |
est31 |
#3608 is a bit different, it looks like some kind of a hack so that one doesn't have to pass through the used network protocol version internally in the client |
| 04:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/3608 -- Backface culling once more: We don't know the server vers. by sofar |
| 04:57 |
est31 |
bc idk |
| 04:58 |
est31 |
so probably its a great thing to do if you want to avoid having to bump the network protocol version |
| 04:59 |
est31 |
but 1. the PR still keeps the protocol version bumped and 2. I dont think that not bumping protocol version is worth the extra byte sent |
| 05:00 |
est31 |
its not a great thing to do, except you want to avoid bumping the protocol version at all cost |
| 05:03 |
est31 |
A better hack in my opinion would be to send the boolean value + 1 over the network |
| 05:04 |
est31 |
Then if its 0 at the reciever side you know server doesn't support it, if its 1 its false, if its 2 its true. |
| 05:09 |
est31 |
but I do admit that I dont really see the beauty in having separate contentfeatures version, at least not this way, where it bases on network protocol version anyway. |
| 05:16 |
est31 |
but yeah this code stinks bad https://github.com/minetest/minetest/pull/3608/files#diff-70868aa6d6b96c0c1623c761500d23c4L348 |
| 05:17 |
est31 |
version is not network proto version |
| 05:17 |
est31 |
but contentfeatures one |
| 05:18 |
est31 |
and this code stinks too https://github.com/minetest/minetest/pull/3608/files#diff-70868aa6d6b96c0c1623c761500d23c4L358 |
| 05:18 |
est31 |
This should have been caught by review |
| 05:19 |
est31 |
so my fault. |
| 05:21 |
sofar |
est31: no worries, I never properly tested that version value either |
| 05:21 |
sofar |
est31: now that I started doing that when I caught the new error, it all fell through |
| 05:22 |
sofar |
est31: this is why I don't mind not being a core dev for a looong time - I'm coding too fast for my own good still, at this point ;) |
| 05:24 |
est31 |
okay... probably raising the contentfeatures version is most reasonable indeed |
| 05:25 |
est31 |
@ least its most consistent with the past practice |
| 05:25 |
est31 |
but idk, parts of the approach is still flawed |
| 05:26 |
est31 |
e.g. this comment https://github.com/minetest/minetest/pull/3608/files#diff-70868aa6d6b96c0c1623c761500d23c4R392 |
| 05:26 |
est31 |
why should that happen? |
| 05:26 |
est31 |
you have to support three versions now? |
| 05:26 |
est31 |
one where it doesn't get sent, one where it gets sent using the outdated version, and one where it gets sent via the new version? |
| 05:26 |
|
rubenwardy joined #minetest-dev |
| 05:27 |
sofar |
the outdated version never sends it |
| 05:27 |
est31 |
additional copypasta in order to have a "correct place" for stuff? |
| 05:27 |
sofar |
the problem is that the bool doesn't get read until after all tiledefs are read |
| 05:29 |
sofar |
I also made a huge error in passing drawtype to deSerialize() in deSerializeOld that got unnoticed |
| 05:30 |
sofar |
I'm not anywhere proud of this patch either |
| 05:30 |
sofar |
but, this gets it correct for now |
| 05:30 |
sofar |
maybe we can make it prettier |
| 05:30 |
est31 |
good idea |
| 05:30 |
sofar |
but the whole damn problem has been that there's been data sent and received for many versions that's been wrong |
| 05:31 |
sofar |
this would have never happened if tiledef.backface_culling was properly set to false in older versions |
| 05:31 |
sofar |
that's the root of the problem |
| 05:31 |
sofar |
TL:DR if you serialize unused data, better serialize it right |
| 05:32 |
sofar |
I hope there's not more damage like this lurking :) |
| 05:44 |
ShadowNinja |
Does #3347 look good to y'all? |
| 05:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/3347 -- Fix jumping at node edge by ShadowNinja |
| 05:49 |
est31 |
wrote a comment on your pr sofar |
| 05:50 |
est31 |
sorry SN dont really know much about collision handling code |
| 05:55 |
ShadowNinja |
est31: Neither do I, but it seems to work somehow :-P |
| 05:56 |
sofar |
code looks a lot cleaner, if you ask me. other than that, I have NFC |
| 05:56 |
sofar |
:) |
| 06:08 |
sofar |
oh |
| 06:09 |
sofar |
I've discovered a bug in porting.h |
| 06:11 |
sofar |
and I know what the right fix is as well |
| 06:11 |
est31 |
? |
| 06:11 |
sofar |
we're not using a monotonic clock for POSIX |
| 06:12 |
sofar |
IOW ntpd skew could cause time to go backwards |
| 06:12 |
sofar |
causing all sorts of lag on the server |
| 06:16 |
est31 |
okay... |
| 06:16 |
est31 |
what is the proposed fix? |
| 06:17 |
sofar |
so to keep it fully compiling on systems that do not have clock_gettime()... |
| 06:17 |
sofar |
I'll have to see if I can detect runtime which clocksource is available I think |
| 06:17 |
sofar |
in any case, we'll want to use CLOCK_MONOTONIC_RAW |
| 06:18 |
est31 |
(I don't know what you talk about but I guess its something like making it compatible to leap seconds or y2k or sth) |
| 06:18 |
sofar |
do you know what NTP is? |
| 06:18 |
est31 |
yes |
| 06:18 |
est31 |
time synchronisation over network |
| 06:18 |
sofar |
ok, so on a normal server ntp adjusts your time very often, but little amounts |
| 06:18 |
sofar |
if you have a bad clock, then it adjusts it more often |
| 06:19 |
sofar |
if those adjustments adjust the clock forward (clock is slow) then probably nothing happens |
| 06:19 |
sofar |
if your clock is fast, then the time gets set backwards |
| 06:19 |
sofar |
in that case, you'd see the server sleep too long between steps, possibly timer calculations roll over backwards, etc. |
| 06:20 |
sofar |
with CLOCK_MONOTONIC_RAW, that problem disappears |
| 06:20 |
sofar |
because the clock will (for the process) always appear to go forward no matter the ntp adjustments |
| 06:21 |
est31 |
so it stops until the time got right again when the clock gets reset? |
| 06:21 |
est31 |
or does it only slow down or sth |
| 06:21 |
sofar |
it never slows down |
| 06:22 |
sofar |
the process continues to see it's own version of time |
| 06:22 |
sofar |
note that the monotonic clock doesn't start at 1970-1-1 |
| 06:22 |
sofar |
it starts at the process start |
| 06:22 |
sofar |
it's like a private clock that is not affected by NTP |
| 06:23 |
|
OldCoder joined #minetest-dev |
| 06:23 |
est31 |
okay |
| 06:27 |
sofar |
too bad OSX is such a disaster |
| 06:43 |
|
blaze joined #minetest-dev |
| 07:12 |
|
Hunterz joined #minetest-dev |
| 07:35 |
|
nrzkt joined #minetest-dev |
| 07:46 |
|
Dragonop joined #minetest-dev |
| 07:58 |
hmmmm |
[11:54 PM] <est31> I dont think that bumping the contentfeatures version is neccessary or useful here |
| 07:58 |
hmmmm |
right, i made a mistake saying that but i guessed that sofar would probably see the comment right above the try catch block saying that you don't need to bump the CF version by adding things here |
| 07:59 |
hmmmm |
so I didn't bother mentioning it |
| 07:59 |
|
Dragonop joined #minetest-dev |
| 08:01 |
|
Dragonop joined #minetest-dev |
| 08:04 |
|
Dragonop_ joined #minetest-dev |
| 08:11 |
|
Dragonop joined #minetest-dev |
| 08:20 |
|
nrzkt2 joined #minetest-dev |
| 08:23 |
|
Calinou joined #minetest-dev |
| 09:03 |
everamzah |
https://forum.minetest.net/viewtopic.php?f=10&t=10539&p=205530#p205441 |
| 09:07 |
nrzkt2 |
everamzah, not related with this IRC channel |
| 09:07 |
everamzah |
ok sry |
| 09:07 |
everamzah |
my mistake, then |
| 09:51 |
|
Krock joined #minetest-dev |
| 10:09 |
|
jin_xi joined #minetest-dev |
| 10:17 |
|
Darcidride joined #minetest-dev |
| 10:43 |
|
red-001 joined #minetest-dev |
| 10:55 |
|
red-001 joined #minetest-dev |
| 10:56 |
|
nrzkt joined #minetest-dev |
| 11:17 |
|
Obani joined #minetest-dev |
| 11:36 |
|
CraigyDavi joined #minetest-dev |
| 12:55 |
|
CraigyDavi joined #minetest-dev |
| 13:29 |
|
RealBadAngel joined #minetest-dev |
| 13:30 |
RealBadAngel |
hi |
| 13:30 |
RealBadAngel |
https://github.com/minetest/minetest/pull/3610 |
| 13:30 |
RealBadAngel |
should be pretty complete, ive added the missing timers and cleaned the code |
| 13:36 |
sfan5 |
https://github.com/minetest/minetest/pull/3610/files#diff-65f34680878a6bd86f3a59ebc0c06c6dL2278 |
| 13:36 |
sfan5 |
you added some whitespace |
| 13:36 |
VanessaE |
RealBadAngel: items now rotate nicely in the inventory, but it still flickers while changing pages in UI etc. |
| 13:36 |
VanessaE |
(there's still a measurable delay in flipping pages, that is) |
| 13:37 |
VanessaE |
(though it does seem to be faster) |
| 13:37 |
RealBadAngel |
meshes have to be created |
| 13:38 |
RealBadAngel |
the process is faster than getting inv textures but still takes some time |
| 13:38 |
RealBadAngel |
in UI its more visible because theres shitload of items on a single page |
| 13:39 |
VanessaE |
RealBadAngel: you need to reset the rotation counter when you stop the mouseover rotation as well |
| 13:39 |
VanessaE |
the yaw counter I mean |
| 13:39 |
VanessaE |
mouseover an item, it rotates. mouse away, it returns to its default state. mouseover it again, it begins rotating from the yaw it was at when you moved the mouse away. |
| 13:40 |
RealBadAngel |
sfan5, fixed |
| 13:40 |
RealBadAngel |
VanessaE, cant do much about it, timers do reset when mesh changes |
| 13:41 |
RealBadAngel |
the function to draw them is neither part of the hud or formspec, its used by both |
| 13:41 |
VanessaE |
not a timer, I mean there's a counter that reports the current (actual) yaw, that should be reset on mouseout. |
| 13:41 |
RealBadAngel |
yaw changes with time |
| 13:42 |
RealBadAngel |
timers are reset when you hover/select/drag another mesh than before |
| 13:43 |
RealBadAngel |
if you hover the same as before, timers wont reset, so yaw too |
| 13:45 |
RealBadAngel |
i cant do anything with that because of both hud and formspec menu design |
| 13:45 |
VanessaE |
ok. |
| 13:45 |
RealBadAngel |
formspec doesnt even have global timers for hovered things |
| 13:46 |
RealBadAngel |
thats why tooltips for items are not delayed |
| 13:47 |
VanessaE |
suggestion: if it's a mesh node, don't angle it like you do with a block. |
| 13:47 |
RealBadAngel |
no can do |
| 13:47 |
VanessaE |
no? |
| 13:47 |
RealBadAngel |
stairs... for example |
| 13:48 |
VanessaE |
hm |
| 13:48 |
VanessaE |
well, see what it does to e.g. an ilights light. |
| 13:48 |
RealBadAngel |
to what? |
| 13:50 |
VanessaE |
it angles the light and rotates around that new center, rather than rotating around the center of the object itself. maybe a node def field should be added to fine-tune the camera location, roll, etc. for some nodes. |
| 13:50 |
RealBadAngel |
that could be a solution |
| 13:50 |
VanessaE |
it's not a major issue, just a detail I noticed is all |
| 13:52 |
VanessaE |
(seems to me that just specifying the X/Z location for the rotation axis, and its X/Z pitch, would be more than enough. distance/rotation/etc of the camera would be overkill) |
| 13:52 |
RealBadAngel |
something like default_inventory_rotation = (x, y,z) |
| 13:52 |
VanessaE |
something like that yeah |
| 13:52 |
RealBadAngel |
atm default is as we had for cubes |
| 13:53 |
VanessaE |
so that there's just enough to make some model rotate about its own center |
| 13:53 |
RealBadAngel |
center doesnt change |
| 13:56 |
VanessaE |
anyway this looks good so far |
| 13:58 |
RealBadAngel |
shall i add that def field now or maybe later on? |
| 13:58 |
RealBadAngel |
btw, inventory cubes are also obsolete with it |
| 13:59 |
VanessaE |
default glass ^^^^ |
| 13:59 |
RealBadAngel |
removing them from water, glass etc will be necesary |
| 13:59 |
VanessaE |
why DOES glass still use the inventorycube thing anyway? |
| 13:59 |
RealBadAngel |
idk |
| 14:00 |
VanessaE |
(moreblocks' glasses don't use it) |
| 14:00 |
VanessaE |
hm, point of note: transparent objects probably should not use backface culling in the inventory model |
| 14:00 |
VanessaE |
look at moreblocks glass (which is a real cube, not an inventorycube), compare to framed glass |
| 14:01 |
RealBadAngel |
ive set culling to on, but can disable it at all |
| 14:01 |
RealBadAngel |
that doesnt really matter here |
| 14:02 |
VanessaE |
well I'm just saying that a transparent block like glow glass probably ought to show all 6 sides :) |
| 14:02 |
RealBadAngel |
you can test it, its at the end of wieldmesh.cpp |
| 14:02 |
RealBadAngel |
line 540 |
| 14:02 |
* VanessaE |
tries... |
| 14:03 |
RealBadAngel |
in game you cant see all glass faces anyway |
| 14:04 |
VanessaE |
right, but in the inventory it seems like it would make sense to see them |
| 14:04 |
RealBadAngel |
but you can if using connected glass |
| 14:04 |
VanessaE |
particularly because of the new rotation |
| 14:04 |
VanessaE |
in-game you can't see all the glass faces because the streaks would make everything obscure, as I understand it |
| 14:05 |
VanessaE |
interesting. |
| 14:05 |
VanessaE |
that flag had no effect. |
| 14:07 |
VanessaE |
(neither on the wielded item, nor in-game, nor in the inventory) |
| 14:09 |
* VanessaE |
shrugs. what you've made here is a damn sight better than what we had. |
| 14:10 |
VanessaE |
I wonder if the inventorycube thing can be made into a simple no-op (just passing the referenced textures straight through)? |
| 14:13 |
|
Dragonop joined #minetest-dev |
| 14:15 |
|
Dragonop joined #minetest-dev |
| 14:18 |
|
ElectronLibre joined #minetest-dev |
| 14:22 |
RealBadAngel |
ah |
| 14:22 |
RealBadAngel |
i know why, its for extruded only here |
| 14:23 |
VanessaE |
ah, yeah we don't need that for an extruded item |
| 14:26 |
RealBadAngel |
also, killbith noticed that already, items do look way better now |
| 14:26 |
VanessaE |
yes, they do |
| 14:26 |
RealBadAngel |
theyre displayed in actual screen resolution |
| 14:26 |
VanessaE |
guess all that upscaling-for-inventory code can be dispensed with also |
| 14:27 |
RealBadAngel |
idc about it, i just take window defined and use it as a viewport |
| 14:27 |
VanessaE |
look fore references to "gui_scaling_filter" |
| 14:27 |
VanessaE |
-e |
| 14:27 |
RealBadAngel |
that will scale all other elements propapbly |
| 14:27 |
VanessaE |
we don't need this now, with your mesh-based inventory |
| 14:28 |
VanessaE |
that ^^^ scales all inventory images/cubes/etc during (or after?) render-to-texture |
| 14:28 |
RealBadAngel |
need to take a look |
| 14:28 |
RealBadAngel |
this code makes many things obsolete indeed |
| 14:29 |
RealBadAngel |
btw i think i have figured how to reset rotations for hovered/grabbed ones |
| 14:30 |
VanessaE |
oh good |
| 14:30 |
RealBadAngel |
will try if its gonna work, i hope it will |
| 14:30 |
RealBadAngel |
some good ideas come with time |
| 14:31 |
RealBadAngel |
i had problems with makin timers reset at all, so ive put this code on hold for a week or so |
| 14:31 |
RealBadAngel |
today idea just blinked and solution was here ;) |
| 14:40 |
|
Fixer joined #minetest-dev |
| 14:49 |
|
luizrpgluiz joined #minetest-dev |
| 14:55 |
luizrpgluiz |
what is the probability of version 0.4.14 out this year? |
| 14:55 |
|
turtleman joined #minetest-dev |
| 15:03 |
|
Amoebaa joined #minetest-dev |
| 15:04 |
Amoebaa |
hi, I'm guessing this is a better place to ask this question: is anybody specifically working on changes to the minimap? |
| 15:04 |
Fixer |
luizrpgluiz, just download new builds from sfan or krock or whatever |
| 15:04 |
Amoebaa |
I had a pretty simple change in mind, and am wondering how it would be recieved |
| 15:07 |
Amoebaa |
basically, adding a simple depth indication to the radar mode by showing the aircount for the above mapblock in blue, the current mapblock in the current green, and the aircount for the mapblock below in red |
| 15:08 |
Amoebaa |
I love the minimap, but am irritated that radar mode doesn't give any idea whether a shallow opening is above or below |
| 15:10 |
Amoebaa |
I should be able to code this myself, but would like to check that there aren't plans for major changes in the minimap that would make this moot |
| 15:11 |
red-001 |
RealBadAngel made the minmap iirc |
| 15:11 |
red-001 |
you should ask him |
| 15:13 |
RealBadAngel |
Amoebaa, how would you like to indicate that? |
| 15:16 |
Amoebaa |
as I noted above, using the red and blue colors |
| 15:17 |
Amoebaa |
by the command on line 357 in minimap.cpp ( c.setGreen ), I'm guessing doing the same for red and blue should work |
| 15:19 |
|
Ardonel joined #minetest-dev |
| 15:19 |
Amoebaa |
so, if there's empty space in both the current and above mapblock, it would show cyan, the current and below would be yellow, and if there's space in the above and below mapblock but not in the current one, it would show purple |
| 15:23 |
Amoebaa |
it looks like the program logic needs to be slightly changed to pass around the three values instead of just one, but I think it's doable |
| 15:29 |
Amoebaa |
it would probably require a bit of testing to see how glaring the white is in large open areas, but I think it'd be mostly an improvement |
| 15:29 |
RealBadAngel |
you will loose "radar" feeling |
| 15:29 |
RealBadAngel |
maybe a third mode then? |
| 15:29 |
everamzah |
when i need to know whether to mine upwards or downwards using radar mode, i just head in either direction and watch how the minimap changes |
| 15:30 |
Amoebaa |
yeah, I've gotten to used to going to the edge of multiples of 16 and jumping up and down |
| 15:30 |
RealBadAngel |
VanessaE, ive updated the PR, timers do properly reset in all cases |
| 15:31 |
Amoebaa |
it just seems a bit dumb, or at least funny... |
| 15:31 |
VanessaE |
RealBadAngel: ok |
| 15:31 |
Amoebaa |
and yeah, I agree it would lose some of that "radar" feeling |
| 15:31 |
|
luizrpgluiz joined #minetest-dev |
| 15:32 |
Amoebaa |
but my basic question still is: there aren't any major changes currently planned to the minimap? |
| 15:32 |
everamzah |
"frustrating" is the word i might use |
| 15:32 |
Amoebaa |
if not, I'll putter around with this and see how it looks, maybe submit something in a few days... |
| 15:32 |
red-001 |
sofar add an on_place callback to doors:hidden to check is there a door under it |
| 15:33 |
red-001 |
mesecons can still break doors |
| 15:33 |
RealBadAngel |
rather no plans atm |
| 15:33 |
VanessaE |
RealBadAngel: looks better now but I wonder if the timer should reset when you grab an item? (left click that is) |
| 15:34 |
VanessaE |
(but still reset it when dropping the item) |
| 15:35 |
VanessaE |
s/should reset when/shouldn't reset when/ |
| 15:47 |
|
kaadmy joined #minetest-dev |
| 15:49 |
|
ElectronLibre joined #minetest-dev |
| 15:59 |
|
Player_2 joined #minetest-dev |
| 16:23 |
|
hmmmm joined #minetest-dev |
| 17:04 |
|
blaze joined #minetest-dev |
| 17:10 |
|
Obani joined #minetest-dev |
| 17:17 |
RealBadAngel |
VanessaE, ouch THAT is im afraid i cant do |
| 17:17 |
RealBadAngel |
those are two different timers |
| 17:17 |
VanessaE |
ok |
| 17:17 |
VanessaE |
(20 minutes later: VanessaE, I figured out that timer issue do try it now) |
| 17:17 |
VanessaE |
;) |
| 17:17 |
RealBadAngel |
:P |
| 17:18 |
RealBadAngel |
dont count on it this time ;) |
| 17:18 |
VanessaE |
hehe |
| 17:23 |
VanessaE |
btw, it works VERY well with HDX. |
| 17:23 |
VanessaE |
page flipping is only slightly slower than default textures now (used to be hugely slower) |
| 17:29 |
VanessaE |
well mostly. hard to describe - put a yellow signs_lib sign on the inventory and watch it rotate. you can see bright, vertical lines flicker across the face of it, and it changes "resolution" as the rotation approaches 90 degrees to the camera. |
| 17:30 |
VanessaE |
seems to happen with any extruded item regardless of its resolution |
| 17:31 |
VanessaE |
(look at carbone mobs' rat for example - it's not yet supported by HDX, so it's the regular low-rez rat image that originated in 0.3.x) |
| 17:32 |
RealBadAngel |
its fault of wielded (extruded) meshes |
| 17:32 |
RealBadAngel |
im reusing them |
| 17:32 |
RealBadAngel |
but i will see if i can do anything with it |
| 17:32 |
VanessaE |
ok |
| 17:32 |
VanessaE |
so it's not unique to my box then |
| 17:32 |
RealBadAngel |
no, its general flaw of extruded meshes |
| 17:33 |
VanessaE |
ok |
| 17:33 |
RealBadAngel |
way too many invisible planes |
| 17:33 |
VanessaE |
ahh |
| 17:33 |
VanessaE |
didn't someone say you needed to use irrlicht's mesh weld call for that? |
| 17:33 |
|
Gael-de-Sailly joined #minetest-dev |
| 17:33 |
RealBadAngel |
hmm |
| 17:34 |
RealBadAngel |
i remember that there something like createMeshCopyWelded or similar |
| 17:34 |
RealBadAngel |
i didnt knew whats that for |
| 17:34 |
VanessaE |
might be useful here |
| 17:34 |
RealBadAngel |
will try it |
| 17:35 |
RealBadAngel |
brb |
| 17:36 |
VanessaE |
this code basically makes the old render-to-texture code obsolete now, doesn't it? |
| 17:38 |
|
ElectronLibre joined #minetest-dev |
| 17:40 |
RealBadAngel |
ofc it does |
| 17:41 |
VanessaE |
ok, so what makes the inventory flicker when changing pages? |
| 17:41 |
VanessaE |
I was told before that this was due to render-to-texture |
| 17:41 |
RealBadAngel |
yes |
| 17:41 |
RealBadAngel |
now theres also a small delay because of meshes |
| 17:42 |
RealBadAngel |
they have to be created and stored |
| 17:42 |
RealBadAngel |
making a copy of mesh is way faster |
| 17:42 |
VanessaE |
ok |
| 17:42 |
VanessaE |
it might be prudent to work on that |
| 17:42 |
RealBadAngel |
but still, each page of UI means 80 meshes |
| 17:42 |
VanessaE |
flicker between pages doesn't look very good :) |
| 17:43 |
RealBadAngel |
aw cmon, its almost instant by now |
| 17:43 |
VanessaE |
not in HDX ;) |
| 17:43 |
RealBadAngel |
comparing to total blackouts? |
| 17:43 |
RealBadAngel |
well, HDX shouldnt make ANY difference |
| 17:43 |
RealBadAngel |
it doesnt care bout textures used |
| 17:43 |
VanessaE |
it makes a difference, but it's not much now. besides, it's only for the first few pages, after which I guess most of the meshes have been generated. |
| 17:44 |
RealBadAngel |
it should take the very same time as for 16px |
| 17:44 |
RealBadAngel |
hmmm |
| 17:44 |
RealBadAngel |
maybe not |
| 17:44 |
RealBadAngel |
we do copy then more extruded 512x meshes |
| 17:44 |
VanessaE |
yes. but like I said, the difference is small |
| 17:44 |
VanessaE |
it's far better now with your PR than without. |
| 17:45 |
RealBadAngel |
that was the point from start |
| 17:45 |
VanessaE |
I'm just trying to address the flickery, choppy way that new meshes are fed to the formspec |
| 17:45 |
RealBadAngel |
i wonder how much it would take to actually "preload" all the meshes |
| 17:45 |
RealBadAngel |
same way we did that before with textures |
| 17:46 |
VanessaE |
I would avoid that. |
| 17:46 |
VanessaE |
it would take a drastically long time I think |
| 17:46 |
RealBadAngel |
its way faster process than with textures |
| 17:46 |
RealBadAngel |
maybe it would be acceptable after all |
| 17:47 |
VanessaE |
RAM usage was respectable, btw - Dreambuilder + HDX256 = about 5 GB after 10 minutes of farting around in-game. |
| 17:47 |
RealBadAngel |
wanna try? |
| 17:47 |
RealBadAngel |
ah that |
| 17:47 |
VanessaE |
that's with mesh cache disabled. 5GB is around what I'd expect from that combination. less is better, of course. |
| 17:48 |
VanessaE |
sure I'll give pre-loading a tryu |
| 17:48 |
VanessaE |
-u |
| 17:49 |
|
Obani joined #minetest-dev |
| 17:50 |
RealBadAngel |
talking bout ram usage |
| 17:50 |
RealBadAngel |
can you compare it? |
| 17:50 |
RealBadAngel |
when using hdx it should spare you some ram |
| 17:50 |
RealBadAngel |
throw 512 at it |
| 17:51 |
VanessaE |
I can't run 512. that takes too much RAM, but 256 takes around 5GB now. before, 6-8 GB (variable) |
| 17:52 |
RealBadAngel |
so this earned you 1-3gb or mem? |
| 17:52 |
VanessaE |
anyway I just did a quick unscientific test: using your PR as it stands now, loading DB takes 21 seconds without HDX, and 42 sec with (a few seconds of that is server set-up time). That's rather faster than upstream, but I don't recall by how much. |
| 17:53 |
VanessaE |
let me try it without your PR |
| 17:55 |
RealBadAngel |
ok |
| 17:57 |
VanessaE |
ok, I'm wrong about both. |
| 17:57 |
VanessaE |
DB + HDX startup time and RAM usage are comparable between upstream and your PR |
| 17:58 |
VanessaE |
maybe I'm thinking of celeron55's farmap PR. that DOES increase RAM usage. |
| 17:58 |
VanessaE |
anyway, the benefit here is clear: your PR makes things definitely faster in-game, and looks nicer |
| 17:59 |
RealBadAngel |
ram usage, tell me about it... :) |
| 17:59 |
RealBadAngel |
ah |
| 17:59 |
RealBadAngel |
you did ;) |
| 17:59 |
VanessaE |
yep. |
| 18:00 |
RealBadAngel |
i was hoping for some gain |
| 18:00 |
VanessaE |
sorry to say, no gains in that department :) |
| 18:00 |
VanessaE |
or I should say, thankfully no gains (as in increases ;) ) |
| 18:00 |
VanessaE |
it's all good. |
| 18:02 |
RealBadAngel |
hmm i do have an idea |
| 18:02 |
RealBadAngel |
lemme try something |
| 18:02 |
VanessaE |
uh oh... |
| 18:03 |
RealBadAngel |
nah, wont work ;) |
| 18:03 |
VanessaE |
heh |
| 18:03 |
VanessaE |
ok |
| 18:03 |
RealBadAngel |
forget it ;) |
| 18:04 |
RealBadAngel |
i was thinkin about not cloning the meshes but reuse them |
| 18:04 |
RealBadAngel |
but i do need to set textures in their materials |
| 18:05 |
RealBadAngel |
or can i? |
| 18:05 |
RealBadAngel |
hrmmm |
| 18:05 |
VanessaE |
one thing at a time :) |
| 18:05 |
RealBadAngel |
thats a good question, why not to set the texture when displaying a mesh? |
| 18:05 |
VanessaE |
you still have to code the jump-zoom and glow effects we discussed :D |
| 18:06 |
RealBadAngel |
those i will leave for the already merged code |
| 18:06 |
VanessaE |
ok :) |
| 18:06 |
RealBadAngel |
i bet that spirit will block 'em ;) |
| 18:06 |
VanessaE |
I can't for the life of me think of the name of the zoom effect :-/ |
| 18:07 |
RealBadAngel |
but definitely those can go into the forks |
| 18:07 |
RealBadAngel |
tiny things that make things look lovely |
| 18:10 |
RealBadAngel |
with working timers adding such things is just a matter of design |
| 18:27 |
|
est31 joined #minetest-dev |
| 18:27 |
RealBadAngel |
i can see that even spinning is way too much for the spirit |
| 18:27 |
RealBadAngel |
i dont even wanna try what will happen to real lighting |
| 18:28 |
RealBadAngel |
forking now |
| 18:28 |
VanessaE |
oh come on :PO |
| 18:28 |
VanessaE |
:P |
| 18:29 |
RealBadAngel |
theres nothing to talk about, see comments |
| 18:29 |
RealBadAngel |
do you actually realize how much im gonna change with lighting and the stuff? |
| 18:30 |
RealBadAngel |
if spinning is way too much i just dont wanna waste my time |
| 18:30 |
VanessaE |
I do. |
| 18:30 |
est31 |
go on, seeing you do a fork isnt sth bad IMO |
| 18:30 |
VanessaE |
but as long as it remains within the "soul" of minetest it's fine |
| 18:31 |
RealBadAngel |
i dont wanna go that far as other forks did, i just wanna minetest be a modern game |
| 18:31 |
VanessaE |
est31: but in this case hje |
| 18:31 |
VanessaE |
he's talking about his meshes-in-inventory PR |
| 18:31 |
VanessaE |
which works and looks pretty nice |
| 18:32 |
RealBadAngel |
word "nice" is not welcome here anymore |
| 18:32 |
VanessaE |
RealBadAngel: nah, "nice" is welcome. "overengineered" isn't :D |
| 18:33 |
|
dfelinto joined #minetest-dev |
| 18:33 |
RealBadAngel |
are spinning cubes overengineered? stop items on the ground too then |
| 18:34 |
VanessaE |
I was trying to say that your code doesn't fall under the "overengineered" clause :) |
| 18:34 |
VanessaE |
it's nice. fix that issue with the vertical stripes I mentioned and merge it. done. :) |
| 18:35 |
RealBadAngel |
i highly doubt if i can do anythin with it, its how the meshes are done. maybe if i write another extrusion code |
| 18:36 |
RealBadAngel |
well, frankly i do have already one, but its working only for 16px, and cant be any fast with 512px for example |
| 18:38 |
VanessaE |
just relax and take a break, you'll figure it out |
| 18:40 |
RealBadAngel |
whatever, im merging it, let it be the start |
| 18:54 |
|
hmmmm joined #minetest-dev |
| 19:02 |
|
H-H-H joined #minetest-dev |
| 19:09 |
est31 |
sofar, seen my comment in #3608? |
| 19:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/3608 -- Backface culling once more: We don't know the server vers. by sofar |
| 19:10 |
|
red-001 joined #minetest-dev |
| 19:11 |
sofar |
yes, I'm fighting 3 kids here atm, will need some time to get to all the comments I got overnight |
| 19:11 |
est31 |
oh ok |
| 19:11 |
est31 |
take your time |
| 19:13 |
* VanessaE |
hands sofar a lion-tamer's whip and chair to defend against the aforementioned kids :) |
| 19:17 |
sofar |
well two are now watching Sesame Street and one is playing with command blocks in Minecraft |
| 19:17 |
red-001 |
victory? |
| 19:20 |
red-001 |
game#602 is quiet trivial could someone review it? |
| 19:20 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/602 -- Add access privilege that allows players to bypass protection. by red-001 |
| 19:21 |
|
kaeza joined #minetest-dev |
| 19:29 |
everamzah |
with the recent discussion about players overriding priv checks, i can't help but worry that player's will lose things out of their locked chests. or am i being paranoid? |
| 19:30 |
sofar |
you are being paranoid |
| 19:32 |
kaeza |
could somebody point me in the right direction as to where to look at? https://forum.minetest.net/viewtopic.php?f=11&t=3905&p=205588#p205539 |
| 19:33 |
kaeza |
in particular, look at fireglow's response a few posts down |
| 19:37 |
est31 |
ask fireglow to include server log at infostream level |
| 19:38 |
est31 |
it will contain messages like "Couldn't convert wstring 0x" |
| 19:38 |
|
Gael-de-Sailly joined #minetest-dev |
| 19:38 |
est31 |
"into UTF-8 string" |
| 19:39 |
est31 |
but most likely its because the server and client think differently of what wstring means |
| 19:40 |
|
fireglow joined #minetest-dev |
| 19:45 |
kaeza |
est31, setting LANG env var (which was unset) seems to have fixed the problem |
| 19:46 |
kaeza |
but I'm not sure if this would be a bug in the engine or not |
| 19:50 |
everamzah |
i get that error by using the shout mod |
| 19:53 |
|
proller joined #minetest-dev |
| 19:56 |
fireglow |
:) |
| 20:12 |
|
H-H-H joined #minetest-dev |
| 20:14 |
est31 |
<kaeza> but I'm not sure if this would be a bug in the engine or not |
| 20:15 |
est31 |
I'm pretty sure it is |
| 20:15 |
sofar |
monotonicity |
| 20:15 |
sofar |
is that a word? |
| 20:15 |
kaadmy |
unlikely ;) |
| 20:15 |
est31 |
idk, I'm no native speaker |
| 20:15 |
sofar |
http://www.thefreedictionary.com/monotonicity |
| 20:15 |
sofar |
seems it is :) |
| 20:16 |
kaadmy |
heh |
| 20:16 |
|
`PenguinDad` joined #minetest-dev |
| 20:17 |
kaeza |
monotoniburg for the german speakers (?)</badpun> |
| 20:18 |
Fixer |
hauptvermessunsabteilung! |
| 20:19 |
kaadmy |
^i'm hoping that's a joke ;) |
| 20:23 |
fireglow |
it's not =) |
| 22:36 |
est31 |
wft |
| 22:37 |
est31 |
wtf* |
| 22:37 |
est31 |
collisionMoveSimple has non const references |
| 22:37 |
est31 |
I'll modify it so that it doesnt have them |
| 23:04 |
kaadmy |
wtf you made a typo! |
| 23:07 |
est31 |
here https://github.com/est31/minetest/commit/59893823ca3e6f65dd7c4ad6c931012556208576 |
| 23:07 |
est31 |
When I hear nothing for two hours, I'll merge it. |
| 23:09 |
est31 |
what the hell |
| 23:09 |
est31 |
man |
| 23:09 |
est31 |
thats bad |
| 23:09 |
est31 |
I think I'll fix that as well. |
| 23:12 |
est31 |
ah okay seems to be problem of my pr |
| 23:12 |
est31 |
ermm commit |
| 23:12 |
est31 |
@ least I hope... :/ |
| 23:15 |
est31 |
https://github.com/est31/minetest/commit/61f84da1b56505601a4df69125c2020d57b1842c |
| 23:15 |
est31 |
okay updated |
| 23:15 |
RealBadAngel |
est31, screenshots of that crafting being broken? |
| 23:16 |
RealBadAngel |
preferably before and after |
| 23:17 |
RealBadAngel |
btw, ive updated PR a few minutes ago |
| 23:20 |
|
Megaf joined #minetest-dev |
| 23:22 |
|
rubenwardy joined #minetest-dev |
| 23:22 |
|
Lunatrius joined #minetest-dev |
| 23:28 |
est31 |
RealBadAngel, uploaded screenshots |
| 23:33 |
est31 |
even newer version of my commit https://github.com/est31/minetest/commit/60e5c48ddea3393c59b02b41dc9ec2160d0f9055 |
| 23:33 |
est31 |
just a bit of style fixeas |
| 23:33 |
est31 |
fixes* |
| 23:40 |
|
Megaf_ joined #minetest-dev |
| 23:40 |
Fixer |
RealBadAngel, found funny report, acacia leaves are not waving -> https://github.com/minetest/minetest_game/issues/802 is this interesting for you? |
| 23:42 |
RealBadAngel |
propably waving flag is not set in node def |
| 23:42 |
RealBadAngel |
est31, fixed, pushing it shortly |
| 23:44 |
Fixer |
looks like slabs and panels has different lightning |
| 23:45 |
|
Icedream joined #minetest-dev |
| 23:45 |
kaadmy |
Fixer: yup |
| 23:45 |
Fixer |
vs normal blocks |
| 23:45 |
kaadmy |
they don't have the smooth lighting |
| 23:45 |
Fixer |
yes |
| 23:45 |
Fixer |
you could be right |
| 23:45 |
Fixer |
maybe* |
| 23:45 |
kaadmy |
^ SSAO would fix most of that problem |
| 23:49 |
RealBadAngel |
fixer, ive solved that issue in the PR already |
| 23:49 |
Fixer |
damn you are good |
| 23:49 |
RealBadAngel |
loading mesh doesnt set mesh color |
| 23:50 |
RealBadAngel |
in code we do set it to (255,255,255,255) |
| 23:50 |
RealBadAngel |
loader sets some other values propably |
| 23:50 |
Fixer |
does it fix ingame lightning difference, or only in inventory? |
| 23:51 |
RealBadAngel |
in game we do set mesh vertices colors no matter what |
| 23:51 |
RealBadAngel |
so it cant be related |
| 23:51 |
RealBadAngel |
difference in game comes from the fact mesh is not a cube (which have different light on each face) |
| 23:52 |
RealBadAngel |
nodeboxes on the other hand have one lighting, for the inner of the node |
| 23:52 |
RealBadAngel |
same as meshes |
| 23:53 |
RealBadAngel |
thats fault of our lighting system, not the meshes |
| 23:53 |
RealBadAngel |
real lighting (at least on the surface) will fix it |
| 23:53 |
Fixer |
hope so |
| 23:57 |
sofar |
was anyone else asking about the new mesh doors breaking mesecons_doors? |
| 23:57 |
sofar |
in case they were: I have a PR pending to mesecons to integrate the new API and fix it... |
