Time Nick Message 06:04 nerzhul too many labels make labels usage too complicated 07:53 oiaohm I have been looking a bit the source code of both minetest and minetest_game. Has the project ever looked at using like .ini file for storage craft-able and so on in the mods to avoid as much Lua code and to improve start-up speed. So like a init.ini next to the init.lua with the ini containing all the stuff that can be just straight up declared. 07:53 sfan5 that's much additional complexity for little gain 07:55 oiaohm sfan5: reading the lua code to work what a mod create is what you call exactly non complex either. 07:55 sfan5 for external programs, maybe 07:56 sfan5 but Minetest needs to run Lua anyway, so why add some custom data format to "bypass" the lua vm? 08:00 oiaohm Lua not always what you can speed or memory friendly. You have to remember LuaJit does does cache stuff in memory. So a lot of init stuff is consuming memory that could freed very quickly. Read file process file close file in C++ can be very memory tidy Not as memory tidy when you go Lua or LuaJit. 08:02 oiaohm Also it could remove a lot of conversions and Lua state handling that do also effect start up time. 08:02 sfan5 >So a lot of init stuff is consuming memory that could freed very quickly. 08:02 sfan5 isn't that the GC's job? 08:03 sfan5 of course, reading a file from C++ is faster than letting Lua do some stuff 08:03 sfan5 but I doubt that would make a significant difference in startup time 08:12 oiaohm GC job is made lot more complex when you have jit in the mix caches. Because it can only be cleaned up with the JIT lets go. Just because you need VM/JIT todo something does not mean you should use it for everything. 08:14 oiaohm From what you are saying sfan5 no one as really looked at if a ini or like file should be there. In past I worked on custom mud servers. yes we did just a different jit for bot automation. But the static items we took from ini files. It do improve server restart times a lot. 09:16 nerzhul oiaohm if you mean the node def i have a working branch with nodedefs in database, but it's not easy to distribute 09:17 nerzhul also starting a server with many mods is due to the code size added in the init.lua, changing format will not help. Also it's fast to load generally 09:29 oiaohm nerzhul: I was looking ini part for simple to distribute and being a one time read on load what does. The code size for processing what could be static data in some mods is quite high as well. So what I am talking about is part about reducing over all code size as well. 09:29 oiaohm ok it will make core engine size larger but will allow the mods code to be smaller. 16:09 rubenwardy was it ever decided whether assignments in if-statements should be allowed? 16:09 rubenwardy ala: https://github.com/minetest/minetest/pull/6786/files#diff-722710b5ecd9db42e7dd785dd517e186R1409 16:31 sfan5 pretty sure nrz suggested using those 16:32 rubenwardy tbh, it's not that bad there 16:43 Krock we've used it in some places and IMO that's fine. while writing this message: "oh, that's actually my code" 16:43 rubenwardy ok, it's fine there 16:57 rubenwardy Krock: please may you use the review feature properly? 16:58 rubenwardy ie: start a review 16:58 rubenwardy then submit when you're happy you've made all the comments you need to 16:58 rubenwardy otherwise I get spammed with notifications 16:59 Krock either that or check less frequently. Will however make use of the review-comment feature in the future 17:00 Krock however, I can't reduce the notification flood when commenting on comments. I hope that's acceptable 20:44 Krock will merge #7126 in 10 minutes 20:44 ShadowBot https://github.com/minetest/minetest/issues/7126 -- Android: Replace movement buttons with joystick by srifqi 20:45 nerzhul Krock, very nice 20:46 nerzhul sfan5: right, sometimes i suggest that :) i like to use it when it's readable :p 20:54 Krock merging.. 21:45 paramat rubenwardy and all, after how many years shall we close a feature request that has no core dev interest? how about 2? 22:16 nerzhul don't forget sometimes we just loose them due to some visiblity problems :) 22:27 Fixer feature requests can't be closed unless they are invalid 22:27 rubenwardy I think they should only be closed if there's low interest (no more than say 2 reactions) and no dev interest too 22:28 rubenwardy or obviously if they're outright rejected as per usual 22:34 paramat hmm any idea gets non-core-dev support, this would mean an ever-growing number of feature requests with no core dev interest :] 22:34 paramat i feel that if there is no core-dev interest for 2-3 years it can be closed, after a bump for reconsideration 22:35 rubenwardy just because none comment doesn't mean they're not interested 22:35 paramat true 22:35 rubenwardy for example, it could just be straight forward in design or they could have larger priorities 22:37 paramat that's why it should be bumped for consideration, in case core devs missed it 22:37 Fixer btw, we don't have cart collisions, do you think it is legitimate goal to have? 22:38 Fixer not just carts, but boats 22:38 Fixer entities 22:38 paramat i think a feature request needs a core dev to say (within 2-3 years): it's worth keeping this open 22:38 rubenwardy sure 22:39 rubenwardy maybe have concept approval then 22:39 rubenwardy idk 22:39 rubenwardy not the same 22:40 paramat otherwse we have feature requests that no core dev supports hanging around forever, the current problem 22:40 rubenwardy yeah, there's some obviously meh stuff 22:41 paramat i think entity collisions are an option actually 22:41 paramat but reduce performance