Time Nick Message 00:00 paramat so now get_mapgen_params and biome api changes are in i can try getting some biomes into MTgame, however since tree schems will take time to create (and schems unstable) how about i add beaches and plains biomes with grasses and flowers for now? then at least v5/v7 will look good 00:22 paramat then i'll aim to get a complete set of biomes finished, with trees, for next stable. i plan to use lua tables for tree schems, it's actually the easiest way currently 01:58 hmmmm lots of work on biomes coming up soon 02:00 hmmmm there's so much work to do on EVERYTHING 02:01 hmmmm i blew my entire christmas vacation on trying to get minetest to a happy place but it still needs work to get there 02:25 hmmmm https://github.com/minetest/minetest/commit/ca89e63b27a2548a7615fcf4943c22f88818f6eb 02:39 hmmmm hahahahaha 02:39 hmmmm on_generated has been being called with the incorrect blockpos for a very long time 02:40 hmmmm s/being// 02:40 hmmmm actually since 0.4-dev 03:20 paramat i'm using recent git 5e2 and can't get decorations to appear, i'm suspecting the addition of height min/max (which is very useful) 03:20 hmmmm does reverting that one make them work?? 03:20 hmmmm personally they work for me... 03:22 paramat i see, i haven't bisected yet, hope this is my mistake 03:23 paramat discovered while testing my biomes branch is MTgame https://github.com/paramat/minetest_game/commit/9cafad476a036bd1cbd7401acb1f164e4abe2b23 03:23 paramat *in 03:35 paramat guess it's bisect time.. BTW people seem a little confused about your v7 vote, they don't know how extreme your proposed 'modification' will be, and some are voting yes because they would like to see v7 improved (as i would, i almost voted yes at first) 03:42 paramat personally the only reason i can see to trash v7 is if it was embarrassingly bad, which of course it isn't (indev was much much worse). seems obvious to me to have more choice and variety 03:43 paramat good thing we're not a democracy heh 03:43 hmmmm it's not going to look much the same 03:43 hmmmm let's put it that way 03:44 hmmmm the fundamental approach i took to terrain is flawed.. i used 2d noise composed with 3d noise to get nice properties of both and i ended up with the worst instead 03:45 hmmmm v5 using 3d as the base and 2d as a height factor is much better 03:46 paramat well, if it's kept i'm offering to maintain it, make improvements, and come up with alternative noiseparams for use in .conf 03:47 hmmmm offer accepted 03:47 paramat i've been playing with using the 3D noise to create floatlands throughout the atmosphere, this being the advantage of the separate 2D and 3D noises 03:47 paramat cool man 03:48 hmmmm you know the thing about mapgens is that what we consider crappy algorithms can turn out to be really awesome with the right noise parameters 03:48 hmmmm eh 03:48 hmmmm floatlands is supposed to be a realm thing 03:48 hmmmm which ties in with the biome thing 03:48 hmmmm you probably saw BIOME_TYPE_AETHER 03:48 paramat yes i keep seeing that 03:49 paramat there have been requests recently for extra 'levels' above/below 03:49 hmmmm it's probably a good idea to bump the priority of working on the biome system 03:50 paramat so of course i've been wondering if v7 aether/nether is coming 03:50 paramat ..in v7 03:50 hmmmm i haven't determined how this is going to work yet 03:51 paramat apart from the requests, i feel any new mapgen should make full use of the vertical space 03:51 hmmmm my original idea was to have aether/nether independent of the mapgen but i'm not sure that's a great idea 03:51 hmmmm so each mapgen should define a generateTerrain() for each biome type 03:52 paramat agreed they shouldn't be independant of mapgen 03:52 hmmmm the actual terrain is easy for those 03:53 paramat in my lua mapgen i keep seeing ways of just tweaking the normal realm to create stuff above and below 03:53 hmmmm it can't be too much more difficult than 2d noise * 3d noise > threshhold for aether and carve out negative space with 3d noise for nether 03:53 hmmmm finer details aside 03:54 hmmmm perhaps there should be a "default" generateTerrain() for aether/nether defined in mapgen.cpp and then each mapgen can leave it unimplemented if they don't want to do anything special 03:54 paramat yep, for a 3D noise mapgen just changing how 'noise gradient' behaves can generate all 3 types of reallm 03:55 hmmmm with all this stuff, how am I supposed to find time to work on OGL lightmaps and the emergethread disk queueing 03:55 hmmmm :/ 03:55 hmmmm or what about the lua ABM context switching cleanup 03:57 paramat i don't expect you to do all these things as well, i can do the simpler / time consuming work on mapgen 03:58 hmmmm and then any of the things on the dev wiki TODO list... hah 03:58 hmmmm minetest is a full time job 03:58 paramat you know i'm the 'mapgen tea boy' 03:58 hmmmm lol 03:58 hmmmm care for a cuppa? 03:58 paramat funny i don't drink caffeine 03:59 paramat anyway here's my mapgen that does all 3 realms just by altering 'noise gradient' https://forum.minetest.net/viewtopic.php?f=9&t=10481 04:00 hmmmm tea doesn't necessarily contain caffeine, does it? 04:00 hmmmm I'm looking for a minecraft-like nether 04:00 paramat yeah more underworldy 04:01 hmmmm in any case this requires modifying light levels 04:01 hmmmm client side biome effects 04:01 hmmmm they're going to be necessary if this is to be successful 04:01 paramat i also realised adjusting how noise gradient behaves can create planets/dyson spheres/dyson cubes/tube worlds 04:01 paramat yeah lighting =P 04:02 hmmmm i'm going to add something very dangerous to the modding api that only very responsible people can use 04:03 paramat too bad i miss out 04:03 hmmmm nah, it's intended for you 04:03 hmmmm i am trying to come up with signing mechanisms 04:03 hmmmm if I don't, it WILL be abused and cause tons of crashes and people whining and moaning 04:04 hmmmm you probably realize what it is I'm talking about, right? 04:06 paramat signing ... mirror-image mapgens? 04:07 paramat symmetry through signing of co-ords erm.. 04:07 hmmmm huh? 04:08 paramat guess not =) 04:08 hmmmm control over envlock from on_generated :p 04:08 hmmmm crazy, huh 04:08 paramat multi-threaded lua mapgen? 04:09 hmmmm that not so much, because there's still scriptlock 04:09 hmmmm just so that ServerThread doesn't hang while map is generating 04:09 hmmmm that's the #1 problem with lua mapgens 04:09 paramat yes 04:09 hmmmm here's a really easy solution. but the dumb people 04:11 paramat this would be a more powerful form of threaded lua mapgen i guess, control over when to thread? 04:12 hmmmm the problem is that i can't think of a good way to stop other people from impersonating you 04:12 hmmmm because open source 04:13 paramat lol. well anyway that is indeed dangerous 04:13 hmmmm we can't communicate with a 3rd party server 04:13 paramat i would be happy enough with multi-threaded lua mapgen for the masses 04:14 hmmmm it's either restricted to certain people or nothing at all 04:14 hmmmm there's simply too much potential for abuse 04:14 paramat crumbs 04:15 paramat i thought it would be for everyone, c55 was considering it a priority 04:15 paramat just for LVM seemed doable 04:16 paramat anyway, if that can be done yes please 04:16 paramat if not ill do it in core 04:16 hmmmm the only safe way is to add checks !EVERYWHERE! to every single api 04:16 hmmmm ugh 04:17 hmmmm i have a solution for this actually 04:17 hmmmm alright, i can do it the safe way 04:19 paramat to be clear i have no resistence to coding core mapgen now, just haven't got around to it 04:20 paramat 'riverdev' mod is a monster and needs to be done in core 04:20 hmmmm lua mapgens are nicer because you don't need to generalize as much 04:20 paramat they are more relaxing too 04:21 paramat 'leisure coding' core is a bit stressful 04:22 paramat i like to hide away and work independantly with lua stuff, i miss it actually 04:26 hmmmm http://fpaste.org/164229/14199135/ 04:26 hmmmm :p 04:26 hmmmm i'm busy for a while 04:26 paramat me too 04:58 VanessaE all right, this shit has to stop 04:58 VanessaE Minetest for windows needs a proper installer 04:58 VanessaE not this zip file shit 04:59 VanessaE I'm trying to help someone through just unzipping the file and they can't even figure out what a zip is. 05:02 hmmmm minetest might not be for them :p 05:04 VanessaE eh.. 05:04 Zeno` 7z self-extracting archives are probably the easiest solutions for Windows 05:04 VanessaE Zeno`: +1 05:12 VanessaE so, what about it? 05:12 VanessaE is there some reason not to switch to that like, right now? 05:47 paramat i assume if height_min and height_max are left out of a decoration definition it will still work? now bisected and commit 863379a breaks decos 05:48 paramat the biomes work okay though 05:50 hmmmm hahaha 05:51 hmmmm do you see why? :) 05:51 hmmmm i bet it works if you specified a height_min/height_max 05:51 paramat i'll try adding that in ... 05:57 paramat erm it still doesn't work with those params in 05:59 paramat anyway that bool that triggers continue may be the error? 05:59 hmmmm how is that logically possible 06:00 hmmmm did you see this? this is what i figured the problem is: https://github.com/minetest/minetest/commit/b589353d89a5a5cd2dd999a13ca039079bee0ece 06:00 paramat well i can't see the error 06:00 paramat swapped 06:01 paramat oh yeah see it now 06:02 hmmmm it works for me after my fix... so 06:02 paramat will compile and test! 06:03 hmmmm oh uh oh 06:03 hmmmm i see a larger problem 06:03 hmmmm with decosimple anyway 06:08 hmmmm really need to start being more careful with naming things 06:11 paramat still doesnt work 06:17 paramat are -32000 and 32000 safe to use as height limits? i always see 31000 instead 06:18 paramat wow v7 with super-amplified 3D noise is stunning 06:18 paramat mgv7_np_mountain = 0, 16, (250, 350, 250), 5333, 5, 0.68, 2.0 06:25 paramat yes it's simple decos which don't appear for me 06:31 paramat oh there's 2 height_max parameters! 06:31 hmmmm yea 06:31 paramat good grief 06:31 hmmmm the height_min/height_max is wrong terminology 06:31 hmmmm it should be y_min/y_max 06:31 hmmmm if i do that, i'll break compatibility though! 06:32 paramat http://i.stack.imgur.com/9y9uk.gif 06:32 hmmmm i set height_max to 20 for grass and i got 06:32 hmmmm an interesting result 06:33 hmmmm also i discovered that if you cut the bottom node of one of these... grass trees... all the nodes on top will fall down 06:34 hmmmm and what's more is that the dropped items like seeds gather together if they fall on top of one another 06:34 hmmmm very convenient feature 06:35 hmmmm so I was wasting time making this http://i.imgur.com/QHkKgYT.jpg 06:48 hmmmm okay, NOW try it https://github.com/minetest/minetest/commit/9b0d77a549e4c29c9c189ff2a454568fa9746c1e 07:09 paramat okay 07:12 paramat ah because grass is 'attached node', nice 07:27 paramat now works, thanks, big relief 07:39 paramat enough stress and excitement for one day, time to watch sci-fi anime 07:39 hmmmm you and your anime... 07:39 hmmmm is it a new show or what? 07:47 paramat i'm currently watching 3 series from last year. i get withdrawl symptoms with anime. the average anime is more imaginative and has better design and story than any hollywood live-action film 07:48 hmmmm i've gotta catch up on the past 3 seasons 12:49 Zeno` kahrl, #2017... any reason why your gist isn't merged? 12:49 ShadowBot https://github.com/minetest/minetest/issues/2017 -- facedir > 23 causes segfault in client 12:51 Zeno` I will merge #1851 soon. Bug fix 12:51 ShadowBot https://github.com/minetest/minetest/issues/1851 -- Cleanup updateCameraDirection and fix random input not working by Zeno- 12:54 Zeno` Also #2026 12:54 ShadowBot https://github.com/minetest/minetest/issues/2026 -- Fix endian.h include for FreeBSD by AMDmi3 13:12 Zeno` comments on #1967, please 13:12 ShadowBot https://github.com/minetest/minetest/issues/1967 -- Add display_gamma option for client by Zeno- 13:16 Krock Zeno`, I'm not sure if that feature is used by regular players. Also, this could be confusing when the server uses an other light tabe and (as example) the plants won't grow 13:20 Zeno` Doesn't affect the server 13:20 Zeno` Gamma correction (and brightness and contrast, but I'm not going to do that at this point) are common game options 13:21 Zeno` the light table is a *display* value, not something used for ABMs etc 13:21 Krock Can't te screens do that? 13:21 Krock *the 13:22 Krock whatever. I'm not sure if that should be merged 13:24 Zeno` screens? 13:24 Zeno` You want me to adjust my monitor for one game? :) 13:26 Zeno` My monitor is calibrated and I (for one) am not going to change anything on the monitor just for minetest. Many people have complained about this simple feature being missing for a long time. All monitors are different and this fixes that problem by letting the user set a "correction" 13:27 Zeno` It will also stop 500 #if 0 #endif variants of light_table heh 13:30 Zeno` I'm not sure why it's not easy to understand that people's monitors (and eyesight) are different :/ 13:30 Zeno` and there is no one size fits all solution 13:50 Megaf Hi Zeno` 13:50 Megaf Zeno`: memory leak on server side is fixed indeed 13:50 Megaf Zeno`: but client leak is not 13:51 pitriss Zeno`: I support your set gamma patch 13:52 pitriss Zeno`: my monitor is also set up properly but I know many ppl who will find this useful 14:05 Zeno` I'm just making some changes so it's even more obvious that this (light_table) is a client thing only 14:05 Zeno` pushed 14:07 Zeno` I'll merge before I go to sleep I guess... otherwise it'll never happen 14:13 Zeno` waiting for Travis 14:14 Krock did someone agree the merge? 14:14 Zeno` yes, pitriss 14:14 Zeno` and MegaF 14:15 Krock I thought devs must agree or am I wrong? 14:17 Zeno` Well, if that were the case nothing would ever get merged unfortunately :( 14:18 Zeno` and shadowninja kind of agreed (apart from his comment that it may affect servers, which I've now addressed... the code isn't even there for servers now) 14:18 Zeno` I'm still not sure why you're so opposed to it 14:19 Krock Okay, the range is limited and the defaults equal the current light table 14:19 Krock nothing speaks against it 14:24 Zeno` This will all become obsolete when (if?) GPU lighting is implemented anyway. When that's done there's probably no way to get the actual light value 14:25 Zeno` displayed light value* 15:43 Ritchie hello 15:44 Ritchie Zeno`: i support your gamma patch too 15:45 Ritchie Zeno`: can i ask what monitor do you have that you said you have it calibrated? 15:46 Zeno` It's not an expensive monitor. I have 3x SyncMasterS22B300 monitors that I've calibrated with Spyder2 15:48 Ritchie i have a cheap LCD screen "ProView" but i have now a chance to buy used EIZO FlexScan F67 with low price 15:48 Zeno` But I'm not changing brightness/contrast/gamma on the monitor for the only game in existence without the ability to change those values (at least gamma) when it's an easy fix :) 15:48 Ritchie yes i agree with you 15:49 Zeno` The EIZO is much better than a ProView 15:49 Zeno` about 1000x better probably 15:51 Ritchie http://www.prad.de/en/guide/screen3350.html 15:52 Ritchie i bought it in university accomodation for 0.5l slivovitze:D 15:53 Ritchie -e 15:58 cib0 "We want to document most or all of Minetest core with Doxygen-style code comments. The system for extracting information from those comments is not yet ready, but once we have comments in that format, it should be relatively simple to implement. " what 15:58 cib0 "is not yet ready"? 15:59 Zeno` Tesseract, I've updated #1967 to make it completely obvious that it does not affect server stuff. Merge? 15:59 ShadowBot https://github.com/minetest/minetest/issues/1967 -- Add display_gamma option for client by Zeno- 16:00 Zeno` cib0, where did you get that quote from? 16:00 cib0 http://dev.minetest.net/Engine_documentation 16:00 Zeno` I think it's ready 16:00 Zeno` That page is probably outdated 16:00 cib0 If it is that page should probably contain a link to an online version of the docs, too. :) 16:01 cib0 "Last modified January 2013" yup 16:01 Zeno` Well, there are no online docs yet (AFAIK) but the " system for extracting information from those comments" is in place 16:02 Zeno` i.e. https://github.com/minetest/minetest/blob/master/doc/Doxyfile.in 16:04 Zeno` Could probably do with some improvement, but at least it's in place :) 16:17 Zeno` Ok, since there are no problems I'll merge in 30 minutes 16:26 celeron55 what the hell 16:27 celeron55 yes, that page is very outdated and it gives a wrong idea about what we can accept as contributions in that area 16:28 celeron55 i added a notice to it 16:33 kaeza #minetest-doc is also dead. would it be OK to redirect here instead? 16:44 hmmmm argh 16:45 hmmmm if minetest didn't have lua modding capabilities i bet it would be half the size 16:46 VanessaE (Score:-1, Troll) 16:46 VanessaE :P 16:47 hmmmm no sarcasm here 16:47 hmmmm consider something trivial like adjustable light 16:47 hmmmm normal games just... adjust the light 16:47 VanessaE well half the size it might be, but it would also have like 1 percent of the userland activity also 16:48 hmmmm instead if minetest wants to adjust the light there needs to be: 16:48 hmmmm - a lua api to do so 16:48 hmmmm - documentation on it 16:48 hmmmm - server -> client transfer 16:48 hmmmm - actually adjusting the light 16:49 hmmmm - also a protocol version bump 16:49 VanessaE well 16:50 VanessaE consider the flipside to that code-size coin: does the total amount of code lead to a reduction on performance, maintainability, etc.? 16:50 hmmmm then some time later modders want to do x y and z with the api so you have to maintain it 16:50 hmmmm well, it certainly decreases developer happiness 16:50 VanessaE (on performance, I mean assume a game with no mods installed) 16:51 VanessaE well, I'll grant you that :P 16:51 Brains Of course, you didn't have to implement all those things that the modders did with your api... So, write good and popular APIs. (If you manage to figure out how to do that repeatably, retire to a moderately sized island and invite your peers.) 16:53 hmmmm it's difficult to think of minetest as a game because of these reasons 16:53 hmmmm there's so much more overhead and it does so much more than simply 'be entertaining' 16:53 hmmmm very little focus these days on audiovisuals and graphics 16:54 hmmmm although there's lots of work that could be done there 16:54 Brains It is getting hard for even big games to be successful without modding capabilities. *shrug* 16:54 VanessaE hmmmm: haven't I been complaining about the lack of focus on A/V for a while now? (with exceptions to what RBA has done recently) 16:54 Zeno` ahem 16:54 VanessaE and zeno :) 16:54 Zeno` :P 16:55 VanessaE (though I lumped your stuff under performance, not AV) 16:55 Zeno` fair enough I guess ;) 16:56 VanessaE hmmmm: there's two problems though - not enough coders who can do it, and not enough skills among those we have who already can. 16:56 hmmmm there's simply too much shit todo 16:56 hmmmm how long have i been wanting to add the nether 16:56 VanessaE I mean, I've seen screenshots of some seriously "next level shit" to quote Will Smith, and those things are just way WAY beyond what Minetest can do given the current skill level we have at our disposal 16:57 hmmmm 250+ commits later and i still didn't get to that 16:57 hmmmm what do you mean? 16:57 VanessaE I mean nice AV effects, shadows, bloom, etc 16:57 hmmmm oh, AV effects 16:57 VanessaE things that irrlicht itself probably can't even do 16:57 cib0 There's always a balance to be found between simplicity, flexibility and features.. 16:57 hmmmm of course irrlicht can't do that 16:58 VanessaE but which, if used to proper degree would look really good in minetest 16:58 hmmmm in any case, we're right up against a wall because of irrlicht 16:58 hmmmm it's probably a smart idea to fork it and include the source 16:58 hmmmm modify that 16:58 VanessaE hmmmm: I dunno about that..... 16:58 hmmmm really. 16:59 hmmmm it's either that or start using raw opengl 16:59 VanessaE honestly? that's a better idea imho 16:59 hmmmm you don't work with any of this though 16:59 VanessaE yeah I know 16:59 hmmmm how could you believe your opinion holds a lot of weight 16:59 VanessaE but my point is, what happens if by some miracle irrlicht actually develops along similar lines as you're proposing maintaining in your own fork? 17:00 hmmmm awesome stuff, but that won't happen 17:00 VanessaE do you switch back to mainline? 17:00 hmmmm irrlicht is optimized for typical "game" games 17:00 hmmmm and there's nothing preventing us from contributing back 17:00 hmmmm if they don't accept our contributions, no sweat. 17:00 Zeno` there's an easier way 17:01 VanessaE well since my opinions seem to hold little weight, I'll just shut up. 17:01 Zeno` "abstracting" the rendering engine 17:01 cib0 Go away. :| 17:01 cib0 :P 17:01 Zeno` this could probably be done in a few weeks 17:01 exio4 as long as you don't use objects for that, we'll hug you Zeno` 17:02 cib0 Looks like I'm the only one who believes the audio-visuals are just fine? 17:02 hmmmm and you'll be fighting with the irrlicht interface then 17:02 hmmmm who said you'll be able to get your paws on irrlicht private resouces 17:02 hmmmm resources 17:03 Zeno` Why would I have to? 17:03 hmmmm because you might need to 17:04 hmmmm i'm not sure what's involved to do all the things we want to do yet 17:04 Zeno` Not really... irrlicht versions/build will just not be able to do some things other backends can do (maybe) 17:05 Zeno` The main problem is the server and other parts of shared/common code use irrlicht types; but that's not *too* hard to change 17:06 kilbith hmmmm, it seems have a bug with the mapgen: https://lut.im/w1GAF3IJ/FwXbqJNt (latest git, that happen here and there) 17:07 hmmmm nothing changed the output 17:07 kilbith large rectangular pieces of hundreds nodes 17:08 Krock kilbith, use 0.4.10 and 0.4.11 and compeare those 17:08 hmmmm there was a period in 0.4.10-dev where output got messed up a little 17:08 Krock *compare 17:08 hmmmm it could be that the map seed got messed up, make sure that's set correctly in both versions where it works properly and doesn't work properly 17:08 VanessaE hmmmm: can we PLEASE get a "delete this block from the database" command? 17:09 hmmmm thought there already was one 17:09 VanessaE to fix that ^^ after the fact? 17:09 VanessaE there isn't, afaik 17:09 VanessaE there was supposed to be, SN propose such 17:09 hmmmm you can do //regen, no? 17:09 hmmmm for some mods 17:09 VanessaE that doesn't delete blocks from the mapgen database. 17:10 VanessaE s/mapgen/map/ 17:16 VanessaE (fwiw, //regen I think is a command in the 'mg' mod but it just triggers lua mapgen code to overwrite what's there. that doesn't do any good for forcing the base mapgen, e.g. mgv6 to regenerate an area that was botched) 17:18 kilbith hmmm, i may know why that happens now, the seed changes whenever you enter in the *same* world 17:18 kilbith hmmmm ^ 17:19 hmmmm you have a random seed set? 17:19 kilbith yes 17:20 hmmmm yes, i see the problem 17:20 hmmmm this could be related to the map_meta.txt error 17:20 hmmmm you say this started happening recently? 17:21 kilbith yes, since today 17:21 kilbith i wander on the map whenever you push new commits 17:23 hmmmm do things work fine before 5e2753c7? 17:23 kilbith haven't tested 17:24 kilbith built after 9b0d77a 17:28 hmmmm whoopsies 17:28 * Krock makes a troutslap ready 17:31 hmmmm kilbith, try this https://github.com/kwolekr/minetest/commit/a3d7203be5777010f13bf5465667028b920f4a29 17:40 neoascetic https://github.com/minetest/minetest/blob/master/src/CMakeLists.txt#L110 17:41 neoascetic why we need this statement? why not always simply process cmake_config.h.in? 17:47 celeron55 it allows easier building for platforms that don't really have cmake easily available 17:48 celeron55 i actually used that to my benefit this year so there's that 17:49 celeron55 mostly it's a historical thing from the time when minetest natively supported a visual studio project 17:50 celeron55 it could be removed i guess 17:51 hmmmm hey celeron, what approach are you taking for improving vertex buffering in buildat? 17:58 rubenwardy #buildat 17:58 celeron55 umm... regarding to what exactly? 17:59 hmmmm well i was under the impression that buildat had the same fundamental problem as minetest does with mesh rendering due to the vertex buffering 18:00 celeron55 well it's a bit similar but it uses so much larger buffers and it has functioning texture atlasing 18:00 celeron55 so it really doesn't have an issue 18:00 rubenwardy Two core developers agree! https://github.com/minetest/minetest/pull/1977#issuecomment-68335991 18:01 celeron55 or, well 18:01 rubenwardy #1977 18:01 celeron55 i mean, that part of it is very unfinished 18:01 celeron55 and it has compromises that maybe shouldn't be there 18:01 hmmmm rubenwardy, was it rebased to the current revision of the API? 18:01 celeron55 so whether it's aacceptable completely depends on where you set the bar 18:01 rubenwardy See shadowninja's commt 18:02 hmmmm hmm 18:02 rubenwardy (s)he'll do it soon, probably 18:02 celeron55 buildat's goal is more about flexibility than performance so it does not concern me a lot 18:02 hmmmm ahh, taking the technically easy way out 18:02 hmmmm is urho3d any better than irrlicht in that regard? 18:02 Zeno` it should be merged now 18:02 hmmmm irrlicht seems to be optimized for generic game-games 18:03 celeron55 there's not that much you can do with performance in the end if you don't get the thing done in the first place - and you probably won't if you try something too fancy 18:03 Zeno` I suspect it needs rebasing again though :( 18:03 hmmmm it doesn't use any fancy buffering modes 18:03 celeron55 frankly buildat is probably already too intricate to take off 18:05 celeron55 hmmmm: urho3d is optimized zero amount for open world games like irrlicht (and all others); it's just more modern (basically it uses an opengl 2 style with some requirements from ogl3 while irrlicht is from the opengl1 era) 18:05 celeron55 i don't know if an open source engine exists that is designed for this kind of stuff 18:05 celeron55 i'm not surprised if it does not 18:06 hmmmm i'm no stranger to minecraft-like games 18:06 hmmmm before i discovered minetest, i was going to write one from scratch along with the graphics engine 18:07 hmmmm sorta wondering if I should continue on that mess 18:07 rubenwardy It is up to you. We can't stop you. Diversity is good. 18:08 rubenwardy Of course we like you contributing. 18:08 hmmmm no, i mean the dynamic-world graphics engine 18:08 Zeno` where is the main bottleneck? 18:09 celeron55 well, you could try, but make damn sure you find an easy way to include the boatload of model and animation support that is needed for a real game 18:09 rubenwardy CPU to GPU 18:09 celeron55 urho3d handles that absolutely effortlessly for buildat 18:09 celeron55 and irrlicht adequately for minetest 18:10 rubenwardy buildat is very slow for me - I guess I need a gaming PC. 18:10 hmmmm originally it was going to be sparse voxel octree-based 18:10 Zeno` irrlicht is the bottleneck? 18:10 hmmmm no, irrlicht is just old 18:10 kilbith hmmm: i confirm that your patch works, thanks 18:11 celeron55 rubenwardy: try lowering the rendering distance that is hardcoded in... umm... let me find it 18:11 celeron55 rubenwardy: assuming you are trying to run games/digger, see games/digger/main/client_lua/init.lua 18:11 Zeno` hmmmm, if irrlicht is not the bottleneck then how can switching to something more modern help? 18:12 hmmmm ?? it can't, it could make things a little better 18:12 hmmmm this was discussed before 18:14 Calinou we have a CPU bottleneck somewhere 18:14 kilbith hmmmm, the versionning is wrong on your fork: https://lut.im/1JeIGBa7/SihLfMQ1 18:14 Calinou probably by scene node abuse or such 18:15 kilbith (i use linux) 18:15 hmmmm whaa? 18:15 rubenwardy Much better, celeron55, it's now about 30 FPS rather than 1 FPS. 18:16 rubenwardy @160 18:16 Zeno` hmmmm, perhaps I directed the question at the wrong person 18:17 hmmmm the bottleneck is uploading meshes to the gpu 18:17 Zeno` celeron55... hmmmm: urho3d is optimized zero amount for open world games like irrlicht (and all others); it's just more modern (basically it uses an opengl 2 style with some requirements from ogl3 while irrlicht is from the opengl1 era) 18:17 Zeno` how is that an issue? 18:17 hmmmm again.. read up 18:18 Zeno` I have read up and I can assure you that it's not the issue 18:18 hmmmm it definitely is. what brand of gpu do you have? 18:18 Zeno` nvidia 18:18 hmmmm then check your profiler in the debug menu, look at num_meshes_processed 18:19 celeron55 hmmmm: are you not interested in just implementing texture atlases and mapblock mesh combining? 18:19 celeron55 it would get the mesh upload performance to a totally acceptable level 18:20 Calinou is the old texture atlas code of any use now? 18:20 hmmmm sure, but I can't help but wonder if I'd be able to eke out some more performance by changing some buffering modes 18:20 hmmmm i've been reading that chapter in that OpenGL Insights book 18:20 celeron55 well the thing that is achievable if these pre-made engines are not used is that meshes could be uploaded from other threads 18:20 celeron55 it's the main difference 18:21 Calinou also, what about VBOs, that are currently used in Freeminer? 18:21 Calinou helped greatly in jungles 18:22 celeron55 well the situation with them of course is specific to irrlicht 18:22 hmmmm could've sworn we had vbo support for a while now, which can be enabled via the config 18:22 hmmmm unsynchronized buffers with multiple worker threads 18:23 Zeno` ok I just looked. GPU is not struggling at all 18:23 celeron55 they don't help much without big meshes though, and big meshes rarely happen without texture atlasing and mapblock mesh combining! 18:23 hmmmm i wanted to run multiple MeshMakeThreads 18:23 hmmmm gah 18:23 celeron55 (that's why you see a difference in jungles; they are the only place with big meshes) 18:23 hmmmm could just make mapblocks larger 8) 18:23 hmmmm 16x16x16 is pretty arbitrary 18:24 celeron55 then you leave out support for old intel laptops 18:24 celeron55 maybe it's acceptable 18:24 Calinou wouldn't that break all maps? and what about map size? 18:25 celeron55 but you can't make them too large, it starts causing other issues due to data size 18:25 celeron55 yes it will break everything 18:25 celeron55 that's why i talk about combining them at runtime 18:25 hmmmm i'll add that and see where it gets me 18:26 celeron55 oh also, in addititon to "old intel laptops", mobile devices need the small meshes too 18:26 celeron55 they neither can render a huge amount of vertices 18:26 celeron55 i mean, android 18:27 celeron55 buildat apparently happens to use 32x32x32 chunks (=MT mapblocks) 18:28 celeron55 there's no map saving at all so it's easily changeable :P 19:05 VanessaE hmmmm: you asked earlier about VBO support. no, we don't have it in minetest but there is a now-outdated pull for it. I've used it in the past, and it worked well. Whether it's still as performant, I don't know. It never made it in because it causes memory leaks (outdated/obsolete meshes aren't deleted) 19:11 hmmmm perhaps it should be rebased. i'd merge it in a second. 19:12 VanessaE well until the leak/obsolete meshes issue is solved, I think it'll be vetoed even faster 19:13 rubenwardy * if it works correctly 19:13 VanessaE ah, here it is: https://github.com/ShadowNinja/minetest/tree/vbo 19:14 VanessaE I guess it never got a proper pull request, but anyway there's the code. 19:35 hmmmm there is no leak 19:36 hmmmm it's just vastly increased memory usage 19:39 VanessaE ask Pilzadam. 19:39 hmmmm that's what i understood 19:39 VanessaE according to him I think it was, memory will just keep increasing as new meshes are generated and fed to the GPU 19:39 VanessaE the old ones are never thrown out 19:39 hmmmm hhrmm 19:40 hmmmm but freeminer added this? 19:40 VanessaE yep, apparently 19:40 VanessaE whether/how they fixed that issue, idk 19:40 hmmmm they probably didn't fix the issue 19:40 hmmmm by freeminer we mean proller 19:40 VanessaE heh 19:41 VanessaE inb4 some snide remark from him ;) 19:42 rubenwardy How dare Freeminer take our code, make a better game and don't allow us to take it back. 19:42 rubenwardy The GPL -> LGPL move failed 19:42 Calinou yes we know :/ 19:42 rubenwardy If we moved back, we could nick their code 19:42 VanessaE "better" is quite subjective here. 19:42 Calinou if Minetest was GPL they could switch to AGPL :p 19:43 hmmmm freeminer is waaaay inferior to minetest 19:43 rubenwardy better -> some optimisations 19:43 hmmmm those optimizations aren't actual optimizations and they're buggy as shit 19:43 Calinou Freeminer feels broken when you play it 19:43 rubenwardy They optimised things and added things that we don't have 19:43 rubenwardy Oh, okay 19:43 Calinou stuff like coloured text is very useful, and we can merge it 19:43 hmmmm proller told you he optimized things but they simply omit essential steps 19:43 Calinou but the PR has been abandoned and no dev approved it 19:43 hmmmm leading to bugs in edge cases 19:43 rubenwardy Just look how he did these things, and subtly copy them 19:44 hmmmm I did look at them and I'm not copying any of it 19:44 hmmmm it sucks ass 19:44 rubenwardy Well, look at it in despair and do it your own way. 19:44 hmmmm despair? 19:44 rubenwardy Loss of all hope 19:44 hmmmm I'm not exactly weeping over freeminer 19:45 hmmmm if you think it's better than minetest, that's fine. you go play freeminer 19:45 rubenwardy (loss of all hope because it is a bad way of doing it, to clarify) 19:45 rubenwardy I prefer Minetest 19:50 hmmmm here's a typical Freeminer "fix" or "optimization": https://github.com/freeminer/freeminer/commit/877ef2f5dcaa341c76a9abe073cbea5bba63ddae#diff-34f48ad91ac6c202ac60b0348ae90e30R160 19:51 hmmmm like... are you shitting me 19:52 rubenwardy Wow 19:52 hmmmm and here's another "fix" for his "optimization": https://github.com/freeminer/freeminer/commit/bef8bdb61b9fb8addcb1389c44efaf14cee155a7 19:53 hmmmm which basically invalidates 99% of the advantage gained from the optimization 19:53 hmmmm but the optimization wasn't really necessary to begin with 19:53 hmmmm freeminer is soo awesome 19:53 rubenwardy Lol 19:54 hmmmm I want you to seriously go through the commit logs, subtract Merge commit messages, and count the number of them that begin with the word "fix" 19:54 hmmmm perhaps also subtract the trivial ones like "remove comment" 19:54 rubenwardy Discard any that were ported from MT 19:55 rubenwardy https://github.com/freeminer/freeminer/commit/88bde8e8e9d8a75ae3fa05444993f4815d1334f1 19:55 rubenwardy "Fix merge" 19:55 hmmmm this is why he's not a minetest core dev 19:56 rubenwardy This is why I'm not a Minetest core dev: https://github.com/rubenwardy/NodeBoxEditor/blob/master/src/FileDialog.cpp#L85 19:56 hmmmm that's in bad taste but it's not invalid 19:57 Brains Heh, I had a dickens of a time convincing people that delete this was valid if not exactly the best taste... 19:58 rubenwardy "bad taste"? Like bad code style/structure? 19:58 hmmmm yes 19:58 rubenwardy Okay 19:58 hmmmm the "C++ way" is to perform deinitialization in the destructor 19:58 hmmmm so "delete fileobject" should actually be the thing to close the file handle 19:59 rubenwardy ah, that makes sense 19:59 hmmmm RAII and all that great stuff 19:59 hmmmm RAII is retarded and doesn't need to exist if it weren't for exceptions 19:59 hmmmm C++ is a shit language 20:00 rubenwardy Why does Irrlicht use drop rather than delete? 20:00 rubenwardy ie node->drop(); delete node; 20:03 rubenwardy Ah, grab() 20:03 Kray do you even know the point of RAII 20:03 Kray it is not that you manually do it 20:03 Kray but you use proper memory management 20:03 Kray as in unique_ptr or shared_ptr 20:03 exio4 it is poor man's garbage collection 20:04 Kray if it wasn't for the fact C++ doesn't have special syntax to make it less verbose, this is superior way to do memory management 20:04 hmmmm and if you used unique_ptr/shared_ptr, you wouldn't need a destructor 20:04 Kray garbage collection doesn't guarantee object lifetime and features possible performance issues 20:04 Kray u wot 20:04 Kray it is the destructor doing all the work 20:04 Kray which is being invoked by the memory container 20:05 hmmmm maybe if there was a special piece of syntax that told the compiler to automatically manage this thing 20:05 hmmmm like I said... destructors are unnecessary 20:05 Kray do you even know what you are talking about 20:06 Kray if you have some kind of a file handle, you obviously need to close it 20:06 Kray which is done in the destructor 20:06 hmmmm what's the difference between file->close(); 20:06 hmmmm and delete file; 20:06 hmmmm you're assuming that RAII simply needs to exist 20:06 Kray delete file; is unnecessary when you manage your memory properly 20:07 Kray you don't need to do anything to clean up after you 20:07 Kray the file gets closed when you can no longer access the thing using the file automatically 20:07 Kray as in, when the unique_ptr or last shared_ptr gets deinitialized from heap 20:08 Kray if you write modern c++ you write 0 new or delete statements 20:08 hmmmm you use files how often? 20:08 Kray this is not just about files 20:08 hmmmm like 1% of the time? 20:08 Kray this is everything memory 20:08 rubenwardy Why use new when you can use malloc? 20:08 hmmmm 99% of destructor usage is memory management 20:10 hmmmm this all simply confirms my point that the concept of constructors/destructors is necessary only because of exceptions 20:11 hmmmm just because other languages jumped on the RAII train doesn't mean you have to. it simply requires you to write more code to do the same task 20:11 kahrl I've read new/delete based code and smart pointer based code, I've always found the latter much harder to follow 20:11 kahrl anyway shared_ptr is boost or C++11 so this kind of moot for minetest 20:11 kahrl this is* 20:12 Kray hmmmm: it requires you to write more code and remember to do all deinitializations and stuff yourself 20:12 Kray more code to do same thing AND more ways to introduce bugs 20:12 hmmmm again, not if your language had some kind of "auto-deallocate" 20:12 rubenwardy destructors are overrated. Just do pvariable = NULL; 20:13 hmmmm you're stuck in the C++ mode of thinking 20:13 rubenwardy Easy 20:13 hmmmm if C++ does it, it must be the correct way to do it, I guess 20:13 Kray C++ does shitload of stuff so wrong it's not even funny 20:14 Kray but RAII is simply superior 20:14 hmmmm I don't know about you, but I can't see it 20:14 rubenwardy What have I started? 20:14 Kray i write C# for living and otherwise it is genuinely a good language, but i miss so much C++ style guaranteed object lifetime 20:15 rubenwardy c# is good, except it is pretty much Windows only. 20:15 hmmmm RAII has nothing to do with object lifetime. 20:15 Kray RAII has everything to do with object lifetime 20:16 rubenwardy C# is a powerful laser rifle strapped to a donkey, when taken off the donkey the laser doesn't seem to work as well. http://img.svbtle.com/ddmvewfmbobm0g.png 20:16 hmmmm are you sure you know what you're talking about? 20:16 hmmmm :) 20:16 Kray >In RAII, holding a resource is tied to object lifetime 20:16 Kray t: wikipedia 20:16 hmmmm holding a resource 20:17 hmmmm holding. a. resource. 20:17 hmmmm that doesn't affect the object lifetime at all 20:17 Kray RAII is the concept of object lifetime 20:17 hmmmm no it's not 20:17 hmmmm object lifetime is something separate 20:17 Kray when the object begins to exist, i.e. you allocate it dynamically or from the heap, it is initialized 20:17 hmmmm there is no such thing as the 'heap' 20:17 hmmmm that's an implementation specific detail and it doesn't belong in this discussion 20:18 Kray you know full well what i mean 20:18 hmmmm stop saying that 20:18 rubenwardy Go to PM? 20:18 Kray when the object is no longer accessible, it is denitialized and its lifetime ends 20:18 kahrl btw, here's a more recently rebased version of the vbo patch: https://github.com/kahrl/minetest/tree/vbo 20:18 VanessaE kahrl: ah, that's a bit better :) 20:19 hmmmm but how does initialization and deinitialization have anything to do with the object's lifetime 20:19 hmmmm I can initialize an object 5 lines later in C 20:19 Kray are you serious 20:19 rubenwardy Well, they generally mark the start and the end 20:19 hmmmm yes, I am serious 20:19 Kray the object is initialized when it begins to exist 20:19 hmmmm with RAII 20:19 Kray it is denitialized when it ceases it 20:19 hmmmm yes 20:19 Kray yes, with RAII 20:19 hmmmm so are you saying that everything in the world uses RAII because it's so awesome? 20:20 hmmmm my point is that RAII does not dictate anything about object lifetime 20:20 Kray wat 20:20 hmmmm an object's lifetime is a separate concept from initialization and deinitialization. RAII combines the two. 20:20 Kray it is even in the initialism itself 20:20 Kray Resource Acquisition Is an Initialization 20:21 hmmmm RAII is the concept that they should be one in the same 20:21 hmmmm but they don't need to be 20:21 hmmmm RAII mechanisms combine the two to happen concurrently 20:22 hmmmm so like I said, RAII has nothing to do with object lifetime. 20:22 hmmmm in the sense that it does not affect object lifetime 20:22 hmmmm RAII makes events dependent upon an object's lifetime however 20:22 hmmmm are you seriously arguing with this? 20:23 Kray by now you are just generating nonsense to make it seem like you have an argument 20:23 hmmmm you're a C++ fanboy with his RAII head stuck so far up his ass he can't see anything different 20:24 hmmmm you can set some default values by adding a piece of syntax to do that in the class declaration. you can manage memory by adding a piece of syntax to tell the compiler to clear it at the end of the object's lifetime. there is no need for constructors or destructors. 20:25 hmmmm it leads to nothing more than adding more tasks to a programmer's todo list that makes coding less enjoyable 20:25 celeron55 i actually agree with hmmmm in "RAII is retarded and doesn't need to exist if it weren't for exceptions", but some of the things you're saying is not right 20:25 hmmmm "oh gotta define a constructor for this" 20:26 celeron55 or, well, not that it's completely retarded, but it's not a necessary thing in a language 20:26 hmmmm it's retarded because it poisoned the well 20:26 celeron55 hmmmm: did you watch some of the videos i linked to you previously? 20:26 hmmmm case in point: kray thinks it's the only way existing 20:26 hmmmm no 20:26 celeron55 because what you're now saying is like taken almost directly from them 20:26 celeron55 ...and the guy proceeds to start designing his own language after the ranting videos 20:26 Kray 222010 +hmmmm my point is that RAII does not dictate anything about object lifetime 20:27 hmmmm haha :( I found myself 20:27 Kray this is so incredibly wrong statement 20:27 hmmmm I was designing a "new-C" a year ago 20:27 hmmmm this is one of the major things 20:27 hmmmm Kray, tell me 20:28 Kray RAII is a model of object lifetime 20:28 Kray no one who has any kind of understanding of what it is can state that RAII doesn't dictate anything about object lifetime 20:28 hmmmm it's a model of initializing and deinitializing on object lifetime events 20:28 hmmmm RAII told me that the object dies when it falls out of scope - right? 20:28 Kray on object lifetime events that it dictates 20:28 hmmmm but wait that happens with C too 20:28 hmmmm C doesn't have RAII 20:29 hmmmm what is going on here 20:29 Kray on lifetime events that are necessary for it to work 20:29 celeron55 hmmmm: watch all of this stuff later once you have time, starting from "Ideas about a new programming language for games.": https://www.youtube.com/user/jblow888/videos 20:29 Kray on lifetime events that don't exist in garbage collected languages 20:29 hmmmm haha 20:29 hmmmm celeron55: is it more like C than it is a better C++? 20:29 celeron55 it's also in my blog http://c55.me/blog/?p=1723 20:29 celeron55 hmmmm: yes, the guy hates C++ in the same way as I and you 20:29 hmmmm alright 20:30 hmmmm so I'm nowhere near being alone in that I want a better C and C++ is the wrong way to go 20:30 celeron55 he is going to publish it free and open source later, but he's keeping it to himself until it's proper 20:30 hmmmm I started writing down some design concepts for my language but I never did anything about it because i have no time and better things to do 20:30 hmmmm I bet you did the same thing, right? 20:30 celeron55 no i haven't done such 20:30 celeron55 i'm too much of a practical person 20:30 celeron55 8) 20:31 hmmmm does his new-C language have optional garbage collection? 20:31 celeron55 no 20:31 hmmmm there's one difference 20:32 celeron55 watch the videos for your entertainment at some point, let's discuss them then 8) 20:32 celeron55 i recommend them to Kray too 20:34 hmmmm i'l check it out 20:34 hmmmm i'd much rather get some of the biome crap done though 20:40 hmmmm wish the videos were in text format.. I read a lot faster than I do listen to some guy in front of a webcam 20:43 celeron55 yeah; you really have to watch them at some time when you're not in the mood of doing anything 20:43 celeron55 or do some cooking or stuff while listening 20:43 hmmmm i can't multitask 20:44 celeron55 or, just sit back and throw efficency in the thrash, it's a hobby anyway 20:44 celeron55 trash* 20:44 celeron55 +i 20:45 celeron55 i'm *watching* a 3-hour live streamed podcast at the moment, about videogames 8D 20:45 hmmmm i suppose i could eat while watching videos, because eating is more automatic than other things 20:45 celeron55 because... well, i got enough done today already 20:47 celeron55 i enjoy listening to that guy, he's not bad or uninteresting at speaking at all 20:47 hmmmm i like this guy so far 20:52 kahrl I tend to watch videos (well, some) at increased speed 20:52 kahrl you can listen faster than talk 20:55 celeron55 i find myself burning out easily if i'm "efficient" so i find long videos to be quite convenient 20:55 celeron55 put a few in a day and it's much harder to overwork yourself 8) 20:58 kahrl yeah, I watch the "serious" videos at increased speed so I have more time to watch non-serious stuff at normal speed to relax :P 20:59 kahrl "serious" = mostly lectures from my uni or some MOOC 21:13 Guest32871 Hey guys I just was noticing this glitchy behavior, think it's worth filing an issue? Video of the problem https://www.dropbox.com/s/i7zfklip3g85gwq/out.ogv?dl=0 21:13 Guest32871 (Namely, the seeing through walls) 21:15 hmmmm yeah i noticed that too 21:15 hmmmm file an issue about it... it started recently 21:15 kahrl this is with the default FOV, right? 21:16 Guest32871 Yes 21:17 kahrl any idea when it started happening? 21:17 Guest32871 kahrl: No idea, I just downloaded the game today :) 21:18 kahrl ah okay 21:18 kahrl there was a similar bug a long time ago (#718) but only with increased FOV, so yours is not a duplicate 21:18 kahrl definitely file an issue 21:19 celeron55 it seems like you have to be exactly at that position relative to mapblocks for it to happen 21:23 VanessaE I've noticed it too, and have for a long while. 21:23 VanessaE didn't think to mention it. 21:24 Guest32871 celeron55, kahrl: It would be helpful to include my game save or something to reproduce the issue I'm thinking. Where could I find some such save file? 21:24 VanessaE it's really noticable if you have a lot of map loaded up, and you fly high in order to take a wide-angle screenshot (e.g. a world preview image for a server topic) 21:24 VanessaE (default FoV) 21:26 celeron55 it's probably not the same issue 21:27 celeron55 it's in the same system but a different issue 21:27 celeron55 those close mapblocks aren't supposed to be handled by the same calculation as the very far ones 21:31 kahrl Guest32871: I assume a game save won't be necessary, just include the coordinates and which direction you're facing 21:31 kahrl just make a screenshot with the F5 debug info enabled 21:39 Guest32871 kahrl, celeron55, VanessaE, hmmmm : https://github.com/minetest/minetest/issues/2032 21:49 kahrl Guest32871: yeah, I can reproduce that when I load your world 21:52 kahrl also when I build a similar staircase in another world at the same coordinates 21:54 Guest32871 Interesting 21:56 kahrl easiest way to reproduce this is to stand at x=z=0 and dig down until the F5 info shows y = -2.5 21:56 kahrl then jump 22:35 kahrl https://gist.github.com/kahrl/4c0dbb62b3bd67666c03 22:35 kahrl not sure if that is the best way to fix it but it works 22:36 kahrl the issue is that the camera is just outside the radius given by block_max_radius but still close enough that the FOV check below fails 22:38 kahrl perhaps the FOV check can be fixed but I don't have any idea how 22:51 Guest32871 Wow that was fast! 23:30 RealBadAngel hi 23:32 celeron55 kahrl: yeah, and it occurs because of that due to block visibility not being updated every frame 23:32 celeron55 or... umm... maybe 23:33 celeron55 at least it might be part of what is going on but whatever, if that works in practice, it's fine 23:37 RealBadAngel the issue looks like wrong positioned camera or somethin like that 23:38 RealBadAngel block visibility cannot be updated every frame 23:39 RealBadAngel it is done in mapblock mesh updates only 23:41 RealBadAngel only way to make those faces invisible is imho the position of the camera 23:49 celeron55 lol don't start 23:50 celeron55 you're going to the wrong direction and already just embarras everybody 23:50 celeron55 +s 23:51 RealBadAngel just a thought, im not sure 23:55 RealBadAngel on the other hand mesh updates doesnt care about face visibility, only irrlicht can eliminate visible faces 23:55 RealBadAngel i mean depending on camera position 23:56 RealBadAngel notice that happens on jumps, changing camera position