Minetest logo

IRC log for #minetest-dev, 2016-01-24

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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&amp;t=10539&amp;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&amp;t=3905&amp;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...

| Channels | #minetest-dev index | Today | | Google Search | Plaintext