| Time |
Nick |
Message |
| 00:19 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 00:21 |
hmmmm |
farmesh was removed?! |
| 00:22 |
PilzAdam |
yes |
| 00:22 |
hmmmm |
woah when did that happen |
| 00:22 |
hmmmm |
omnicleanup? |
| 00:22 |
PilzAdam |
https://github.com/minetest/minetest/commit/c8930850e37dab9820049152a3e668a315a97560 |
| 00:24 |
|
Miner_48er joined #minetest-dev |
| 00:26 |
PilzAdam |
that was 1 day before omnicleanup |
| 00:30 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 00:34 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 00:54 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 00:58 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 01:32 |
ShadowNinja |
We need a naming convention for functions, specificaly usage of underscores. Example: minetest.setting_getbool/minetest.setting_get_pos. |
| 01:33 |
ShadowNinja |
Should underscores be used between all words? Or can words be combined as in get_timeofday? |
| 01:58 |
|
Miner_48er joined #minetest-dev |
| 02:07 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 02:12 |
|
smoke_fumus joined #minetest-dev |
| 02:16 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 02:17 |
|
book` joined #minetest-dev |
| 02:32 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 02:50 |
ShadowNinja |
https://github.com/minetest/minetest/pull/923 |
| 03:00 |
hmmmm |
https://github.com/kwolekr/minetest/commit/d308352dbd4121d12d4f44d591463468c09d37f9 |
| 03:02 |
ShadowNinja |
^ looks good. |
| 03:29 |
hmmmm |
so uh |
| 03:29 |
hmmmm |
all this hubbub about LevelDB, and nobody pointed out that there are far superior alternatives |
| 03:29 |
hmmmm |
like sophia for example: http://sphia.org/benchmarks.html |
| 03:34 |
Sokomine |
hmmm: if a map chunk would be copied directly (on database level) from one world to another - then would the nodes stay the same or change? |
| 03:34 |
hmmmm |
stay the same obviously, but you mean a mapblock |
| 03:35 |
hmmmm |
a map chunk is merely an abstraction at the voxelmanip level to mean some box of mapblocks |
| 03:37 |
Sokomine |
ok. so a mapblock then. id conversion will not be necessary? |
| 03:38 |
hmmmm |
"id"? you mean the key used to map the position to the mapblock data? |
| 03:38 |
Sokomine |
would be intresting to combine 2-3 worlds in one world |
| 03:39 |
Sokomine |
in this case i meant the number/id an individual node (gravel, dirt, ...) has in the data field of the mapblock |
| 03:39 |
hmmmm |
you should probably read up on mapblock serialization |
| 03:40 |
hmmmm |
each mapblock on disk stores its own table of IDs to node names so they are completely disparate. |
| 03:41 |
hmmmm |
that is, for mapblock A you have a gravel node with id 0, a dirt node with id 1, and an air node with id 2. so whenever a "0" occurs within that mapblock, you know it's a gravel node... but at the same time, in mapblock B you have a completely different mapping where gravel may be, 54 |
| 03:43 |
hmmmm |
each disk-serialized mapblock is its own separate unit and all of the information it stores can be understood on its own without any reliance on anything else |
| 03:45 |
Sokomine |
thanks! so i understood it correctly |
| 03:49 |
|
andersje joined #minetest-dev |
| 03:54 |
|
andersje_ joined #minetest-dev |
| 04:19 |
ShadowNinja |
hmmmm: Regarding vector checks: Yes, but I think the backtrace is worth it. IMO we should also remove metatable setting, not only will it be faster, but it will be more consistent with what other functions return. |
| 04:20 |
ShadowNinja |
(Better do it before a stable release) |
| 04:22 |
VanessaE |
hmmmm: nice benchmarks on that sophia db. any chance of that becoming a MT backend? |
| 04:22 |
VanessaE |
(options are usually good) |
| 04:23 |
ShadowNinja |
If you need it to be as fast as posible you should use a local function or inline it. The vector helpers are really for readability and simplicity, not super-speed. |
| 04:24 |
ShadowNinja |
VanessaE: It looks pretty simple from the docs, maybe I could even implement it. :-) |
| 04:37 |
ShadowNinja |
The Minetest GitHub organiztion should have a image, the Minetest logo. |
| 04:43 |
|
Miner_48er joined #minetest-dev |
| 04:56 |
|
neko259 joined #minetest-dev |
| 05:30 |
|
smoke_fumus joined #minetest-dev |
| 05:38 |
|
darkrose joined #minetest-dev |
| 05:38 |
|
darkrose joined #minetest-dev |
| 05:41 |
|
smoke_fumus|2 joined #minetest-dev |
| 06:25 |
|
werwerwer joined #minetest-dev |
| 07:13 |
|
Anchakor_ joined #minetest-dev |
| 07:43 |
|
proller joined #minetest-dev |
| 08:52 |
|
Calinou joined #minetest-dev |
| 09:00 |
|
darkrose joined #minetest-dev |
| 09:00 |
|
darkrose joined #minetest-dev |
| 09:21 |
|
Ritchie joined #minetest-dev |
| 09:28 |
|
john_minetest joined #minetest-dev |
| 09:29 |
|
proller joined #minetest-dev |
| 09:29 |
|
john_minetest joined #minetest-dev |
| 09:30 |
|
john_minetest left #minetest-dev |
| 10:13 |
|
Zeitgeist_ joined #minetest-dev |
| 10:35 |
Exio4 |
random thing, just looking at the manpage, https://github.com/minetest/minetest/blob/master/doc/minetest.6#L84 |
| 10:35 |
Exio4 |
shouldn't it have a link to github too? |
| 10:36 |
|
troller joined #minetest-dev |
| 11:58 |
|
EdB joined #minetest-dev |
| 12:09 |
|
PilzAdam joined #minetest-dev |
| 13:17 |
|
ImQ009 joined #minetest-dev |
| 13:21 |
|
EdB_ joined #minetest-dev |
| 13:26 |
|
iqualfragile joined #minetest-dev |
| 13:44 |
|
Anchakor_ joined #minetest-dev |
| 14:58 |
|
Calinou joined #minetest-dev |
| 15:28 |
|
Jordach joined #minetest-dev |
| 15:39 |
|
Zeg9 joined #minetest-dev |
| 15:46 |
IceCraft |
hi |
| 16:10 |
|
hmmmm joined #minetest-dev |
| 16:19 |
|
proller joined #minetest-dev |
| 16:32 |
|
rubenwardy joined #minetest-dev |
| 16:51 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 16:55 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 17:00 |
|
smoke_fumus joined #minetest-dev |
| 17:05 |
|
neko259 joined #minetest-dev |
| 17:27 |
|
tango_ joined #minetest-dev |
| 17:42 |
|
rubenwardy_ joined #minetest-dev |
| 17:53 |
|
tango_ joined #minetest-dev |
| 18:07 |
celeron55 |
hmmmm: one crucial thing to consider with these is how well they work on windows and how well they are available to external map-editing utilities |
| 18:07 |
celeron55 |
leveldb doesn't fare too well in that aspect |
| 18:08 |
celeron55 |
as a starting point, sqlite is quite ubiqutous |
| 18:08 |
celeron55 |
it's just everywhere |
| 18:08 |
celeron55 |
(and available as a single C file) |
| 18:08 |
hmmmm |
btw, I don't see what's wrong with dumping the python minetestmapper completely |
| 18:08 |
hmmmm |
it's really too slow to be useful |
| 18:08 |
celeron55 |
i'm not referring to it (only) |
| 18:08 |
hmmmm |
not aware of any other 3rd party utilities |
| 18:09 |
hmmmm |
aside from my mcconvert |
| 18:09 |
celeron55 |
there surely are utilities based on the python code in minetestmapper |
| 18:09 |
hmmmm |
erm |
| 18:09 |
celeron55 |
i once saw one that allowed managing worlds on a mapblock level (copying/moving/deleting) |
| 18:09 |
hmmmm |
we already have sector-directory, sqlite3, and leveldb storage methods |
| 18:10 |
hmmmm |
don't you think it'd be a bit more prudent to separate all of this crap into its own library |
| 18:10 |
celeron55 |
what is your point? |
| 18:10 |
hmmmm |
well look |
| 18:10 |
hmmmm |
we're talking about adding in even more databases |
| 18:10 |
hmmmm |
that means these utilities are going to need to support those as well |
| 18:11 |
celeron55 |
we are talking about using something else than sqlite; not about supporting 5 of them |
| 18:11 |
hmmmm |
the db backend is very flexible and it'd be almost an insult to only stick with 2, especially when there's an alternative that may be even better than leveldb and as simple to use |
| 18:12 |
hmmmm |
even if it's "not-sqlite", you need to support the specific dbs |
| 18:12 |
celeron55 |
now you're going to so many directions simultaneously that i don't understand what your stance on this issue even is at all |
| 18:12 |
celeron55 |
-even |
| 18:13 |
hmmmm |
my stance is that we need a way to abstract away what a minetest map is stored in |
| 18:14 |
hmmmm |
so we can do all the hard stuff (like reading/writing to a leveldb database among others without bindings) and 3rd party utilities won't need to constantly add new ones |
| 18:19 |
celeron55 |
so you propose that we make a library for that and 3rd party utilities are written using that library? |
| 18:19 |
hmmmm |
yes |
| 18:20 |
hmmmm |
I'm saying we take database_dummy.cpp, database_sqlite3.cpp, database_leveldb.cpp and turn that into... libmtmap, create python bindings for it, and have everything use that |
| 18:20 |
hmmmm |
and make minetest use that as well |
| 18:20 |
celeron55 |
sounds fine to me |
| 18:20 |
sfan5 |
do you think I like it if I have to update my build script again? |
| 18:20 |
hmmmm |
of course you do |
| 18:21 |
celeron55 |
shouldn't matter for such a once-in-a-year thing |
| 18:22 |
sfan5 |
what if the same happens to libmtmap what happend to the common modpack split? |
| 18:22 |
sfan5 |
anyway, what other database backend is worth supporting? |
| 18:23 |
hmmmm |
that other one i pasted yesterday |
| 18:24 |
celeron55 |
of course making such a library requires more code and work which somebody has to do |
| 18:24 |
celeron55 |
also it's important to have one primary format that isn't switched all the time so that eg. windows builders can leave others out |
| 18:24 |
sfan5 |
... |
| 18:25 |
celeron55 |
it would be completely insane to require 5 backend libraries in order to have a usable version minetest |
| 18:25 |
celeron55 |
+of |
| 18:25 |
hmmmm |
sqlite3 could be the primary one i suppose |
| 18:25 |
celeron55 |
and i think we should change only once; from sqlite3 to something else, and then never again |
| 18:25 |
celeron55 |
or maybe not even that |
| 18:25 |
hmmmm |
really? i don't.. |
| 18:25 |
hmmmm |
come on |
| 18:26 |
celeron55 |
what? you don't make any sense in the things you seem to disagree on |
| 18:26 |
sfan5 |
link to "the on i pasted yesterday" please |
| 18:26 |
sfan5 |
one* |
| 18:26 |
hmmmm |
i don't understand why you'd like to lock yourself into one db that might not even be that great |
| 18:27 |
hmmmm |
compared to something that could pop up later |
| 18:27 |
celeron55 |
well that the fuck |
| 18:27 |
hmmmm |
sfan5, http://sphia.org/benchmarks.html |
| 18:27 |
celeron55 |
i didn't say anything about a special case where something magically good pops up |
| 18:27 |
celeron55 |
special cases always exist |
| 18:28 |
hmmmm |
alright, i just didn't see that as a "special" case |
| 18:28 |
hmmmm |
i mean i know what you're saying |
| 18:28 |
hmmmm |
you don't want us to switch around map formats for no good reason |
| 18:28 |
celeron55 |
i guess that's so obvious i shouldn't say it |
| 18:28 |
celeron55 |
but there are others here than you who might need it |
| 18:29 |
hmmmm |
I thought progress toward something better was common and not special |
| 18:30 |
lanxu |
I don't see any problem with having a common api for world data backends. |
| 18:31 |
|
IceCraft joined #minetest-dev |
| 18:33 |
celeron55 |
we could consider changing the format at the same time to something saner |
| 18:33 |
celeron55 |
the mapblock format itself is kind of completely random |
| 18:34 |
celeron55 |
and the sqlite indexing scheme... |
| 18:34 |
kahrl |
bkvl? |
| 18:34 |
celeron55 |
altough, anything we change out must be still supported anyway 8) |
| 18:35 |
celeron55 |
at least in some way; but directly supporting something is often easier than managing some kind of migration tools and steps |
| 18:35 |
hmmmm |
what's wrong with the mapblock format exactly? |
| 18:35 |
lanxu |
as long as there is some sort of version information :) |
| 18:36 |
hmmmm |
lanxu, if you read the documentation you'll see that there is an 8 bit version identifier for all serialized structures. |
| 18:37 |
celeron55 |
hmm, oh well; now that i looked at the doc, it's not really that bad as-is |
| 18:38 |
celeron55 |
especially if things would be supposed to support it via a library and not directly |
| 18:38 |
celeron55 |
i guess we don't want to move to a single-file format either |
| 18:39 |
celeron55 |
such could be much more useful for sharing maps on the internet (no need to zip/unzip), but much worse for server maintainers and tinkerers |
| 18:40 |
|
AnAfkIceNotHere joined #minetest-dev |
| 18:40 |
celeron55 |
dunno really, it's hard to guess here what different kinds of users would like |
| 18:40 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 18:41 |
kahrl |
if the library is good there should be no need to directly mess with invidual files |
| 18:41 |
sfan5 |
what about "dd if=/dev/zero bs=1M count=50 of=map.img; mkfs.ext2 map.img; mount map.img mapdir -t ext2 -o loop" ? |
| 18:41 |
kahrl |
+di |
| 18:42 |
rubenwardy |
The single file can be a zip, so the maintain can still fiddle |
| 18:42 |
hmmmm |
yeah about that |
| 18:42 |
hmmmm |
it always bugged me that a map was actually a directory with this myriad of text files and whatever |
| 18:42 |
hmmmm |
but i mean that's no problem if people just zip it |
| 18:43 |
hmmmm |
people can still do that anyway |
| 18:43 |
Jordach |
as a user, multiple files would confuse a noob |
| 18:43 |
hmmmm |
what database format is being used is just some detail that ought to be irrelevant to people wishing to manipulate it |
| 18:44 |
Jordach |
singlefiles are more likely to break, (some form of non /minetest/worlds folder which are cloned at world start) could alleviate this |
| 18:44 |
hmmmm |
I think the "standard" format should be leveldb, or rather whatever's the "best" choice at that time |
| 18:45 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 18:45 |
kahrl |
oh you are talking about the auxiliary files (players...) as well |
| 18:45 |
kahrl |
I think it's a bad idea to hide those in a binary format |
| 18:45 |
hmmmm |
if we distribute the library, though, I don't see why windows people would have a problem with compiling all the other databases in |
| 18:45 |
kahrl |
says a server owner wants to copy the auth information from an old world to a new one |
| 18:46 |
kahrl |
say* |
| 18:46 |
hmmmm |
kahrl, i would've disagreed with you if we had only sqlite (you'd be able to manipulate things with the sqlite3 command line utility) |
| 18:46 |
hmmmm |
the situation is obviously different now |
| 18:46 |
hmmmm |
I don't think having multiple files is that big of a downside though |
| 18:47 |
kahrl |
it might actually make sense to separate the auth files from the world |
| 18:47 |
kahrl |
as is, it's easy to accidentally to make passwords public by uploading a map |
| 18:48 |
hmmmm |
I agree with that |
| 18:49 |
hmmmm |
okay, so just to recap: |
| 18:49 |
hmmmm |
1). make authentication on a per-server basis, not a per-world |
| 18:49 |
VanessaE |
plaintext for those sorts of files also makes it trivial to manipulate locally. I just merged my two servers' auth.txt together (the "right" way; to sync them) |
| 18:50 |
hmmmm |
2). the world consists of the entire directly holding the map + other data, which can be zipped by the end user if a "single file" is so desired |
| 18:50 |
hmmmm |
3). we ought to create and maintain a library for accessing different databases |
| 18:50 |
lanxu |
any of you notice any major memory leaks with minetest? |
| 18:54 |
lanxu |
oh well, I guess my libraries are just somehow borked. valgrind reports major leakage for /usr/lib/libsqlite3.so.0.8.6 :) |
| 18:55 |
VanessaE |
plus there's the issue of things like corrupt player files. Much easier to deal with by editing/deleting such a file than to try to do so through some kind of database. |
| 18:56 |
hmmmm |
valgrind reports a lot of problems that either we can't fix, or aren't actually problems |
| 18:56 |
lanxu |
true |
| 18:57 |
hmmmm |
we fixed lots of memory leaks a couple months ago |
| 18:58 |
kahrl |
there's the issue that shader materials can't be reclaimed in irrlicht, but that's unrelated to sqlite |
| 18:58 |
PilzAdam |
valgrind always reported memory leaks in sqlite, I need to check that with leveldb |
| 18:59 |
VanessaE |
kahrl: realbadangel is also having the major problem of being able to pass per-material variables or something like that, to shaders. |
| 18:59 |
kahrl |
yeah |
| 19:00 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 19:02 |
pitriss |
hi guys: why that db backend library shouldn't support also storing players records etc also in db? It can be fine if someone will have big dedicated sql server.. it can be performance advantage to store all those data in DB, or not? |
| 19:02 |
VanessaE |
didn't I just say why it shouldn't do that? |
| 19:02 |
hmmmm |
of course not |
| 19:03 |
pitriss |
VanessaE: yeah, yo do.. but, still it can be optional, not default.. |
| 19:03 |
hmmmm |
why would there be a performance advantage for something that's read/written to like once on login and once on logout |
| 19:03 |
hmmmm |
or however often the player save interval is |
| 19:03 |
PilzAdam |
player files are written once a second, but only if modified |
| 19:03 |
hmmmm |
should be more than a second by default :x |
| 19:04 |
kahrl |
a small interval is good in case the server crashes |
| 19:04 |
kahrl |
you lose less progress |
| 19:05 |
kahrl |
perhaps leave it at 1 second in singleplayer and longer otherwise |
| 19:06 |
PilzAdam |
oh, its actually saved in server_map_save_interval |
| 19:10 |
|
OWNSyouAll_DESK1 joined #minetest-dev |
| 19:22 |
|
proller joined #minetest-dev |
| 19:25 |
proller |
btw liquid_finite can cause lot of map changes and cause write to disk at 100% busy |
| 19:25 |
proller |
i use 60 seconds interval on server |
| 19:28 |
proller |
and i still want to merge lot of pulls |
| 19:42 |
|
zancdar joined #minetest-dev |
| 19:45 |
kahrl |
#897 I don't like how this nerfs fast_move |
| 19:45 |
|
jojoa1997 joined #minetest-dev |
| 19:48 |
proller |
how better? |
| 19:48 |
proller |
you have no horizontal damage with fastmove |
| 19:48 |
kahrl |
I don't mean damage |
| 19:49 |
kahrl |
I mean that it's significantly slower than it used to be |
| 19:49 |
kahrl |
and that you can't change direction while jumping |
| 19:51 |
proller |
now you can at high speed |
| 19:52 |
proller |
inspired by something like this |
| 19:52 |
proller |
http://www.youtube.com/watch?v=WRqnTODwvEA |
| 19:53 |
kahrl |
I thought Superman 64 :P |
| 19:53 |
PilzAdam |
so Minetest becomes a RL simulation? |
| 19:54 |
proller |
but angles less than wingsuit use. but fun for game |
| 19:54 |
proller |
its not true simulation, its add more fun on jumping |
| 19:56 |
kahrl |
the prediction of blocks to load is good |
| 19:56 |
proller |
flying near mountains in Sky server very fun |
| 19:56 |
kahrl |
still get stuck sometimes but much less than usual |
| 19:57 |
proller |
yes, impossible to predict your keypress |
| 19:57 |
celeron55 |
i continue to think that not being able to change direction mid-air is as fun as sticking nails into one's eyes |
| 19:57 |
proller |
but after 2-4 jumps path already loaded and you can flyy |
| 19:58 |
proller |
celeron55, its only on high speed |
| 19:59 |
PilzAdam |
I wonder if jumping is really such an important part of the gameplay that we should change it like this |
| 19:59 |
PilzAdam |
for me its just a tool to move, the actualy core gameplay is something else |
| 20:00 |
Jordach |
the only time i jump is when i'm swimming in lava |
| 20:01 |
proller |
its not change standard jumping, but it make sense in floatlands |
| 20:01 |
proller |
or maybe on deeeeep holes |
| 20:02 |
proller |
and with it possible to make new type of maps and gameplay |
| 20:02 |
proller |
fly-oriented with death at end 8) |
| 20:07 |
proller |
good to test it on math - mengersponge |
| 20:17 |
proller |
aaand? |
| 20:19 |
ShadowNinja |
https://github.com/minetest/minetest/pull/925 |
| 20:20 |
|
werwerwer_ joined #minetest-dev |
| 20:35 |
|
xrogaan joined #minetest-dev |
| 21:03 |
hmmmm |
..... wtf |
| 21:03 |
hmmmm |
whose idea was Environment::m_time_of_day_f |
| 21:03 |
hmmmm |
keeping track of another variable to syncronize, and literally the only difference between that and m_time_of_day is that it's divided by 24000 |
| 21:05 |
PilzAdam |
https://github.com/minetest/minetest/commit/2e90ed07acd295387c0da6c0689d14665b6c125d |
| 21:06 |
hmmmm |
absolutely briliant |
| 21:06 |
hmmmm |
well, whatever, i just hope people don't do something like that in the future |
| 21:07 |
PilzAdam |
ShadowNinja, the whole purpose of the vector helpers is to use + - * / in Lua |
| 21:11 |
celeron55 |
why does it create a new table every time for the metatable? |
| 21:11 |
celeron55 |
it could use the same table for all created vectors |
| 21:12 |
ShadowNinja |
celeron55: I also noticed that before. PilzAdam: Yes, but other functions don't set those metatables so it is inconsistent. |
| 21:12 |
ShadowNinja |
https://github.com/minetest/minetest/pull/926 |
| 21:12 |
ShadowNinja |
^ Pretty simple. |
| 21:17 |
ShadowNinja |
Oh, and that makes 73 pull requests... |
| 21:17 |
ShadowNinja |
That is almost half of the issues. |
| 21:31 |
hmmmm |
alright, I think I came up with a better way around the whole heat/humidity thing.. i put it in ServerEnvironment::activateBlock. this is where I do the check to see if the weather data had previously been written to, and if not, have the Map update it, and if it's not cached (which it's not, obviously) then the Map calls upon the BiomeDefManager to calculate new values for it, using the time information passed along by t |
| 21:31 |
hmmmm |
he ServerEnvironment |
| 21:31 |
hmmmm |
does that seem like a rational setup for this |
| 21:32 |
hmmmm |
the weather conditions going on in the world are part of the environment, not so much the map |
| 21:32 |
hmmmm |
but the map is the one that deals with the storage and caching of those values |
| 21:33 |
VanessaE |
seems fair - I'm more concerned with how that code translates into in-world values, and how those values change over time and geographically. |
| 21:33 |
hmmmm |
that's not *my* concern |
| 21:33 |
VanessaE |
wait, storage and caching? I thought the weather stuff was calculated in realtime? |
| 21:33 |
hmmmm |
i'm just trying to figure out a good way of how to fit this all into the model we currently have |
| 21:34 |
VanessaE |
your idea seems fair. |
| 21:34 |
hmmmm |
the last time I tried to clean things up I got stuck on this part and frusturated, so I put it off and then i got busy and forgot about it completely |
| 21:46 |
proller |
hmmmm, heat/humidity still changed over time? |
| 21:47 |
hmmmm |
I'm not changing the functionality of anything |
| 21:48 |
proller |
activate block run only once after block loading/generating? |
| 21:48 |
hmmmm |
that's where it would initially be written, instead of directly in the emergethread |
| 21:48 |
proller |
ok |
| 21:52 |
proller |
.. still want to merge something.. |
| 21:56 |
hmmmm |
your most recent commit seems good, i said yesterday |
| 21:58 |
proller |
miss it |
| 21:58 |
proller |
https://github.com/minetest/minetest/pull/921 this ? |
| 21:59 |
hmmmm |
yes |
| 21:59 |
hmmmm |
also squash those commits |
| 22:01 |
proller |
i'm always squash |
| 22:01 |
proller |
and have git alias for it 8) |
| 22:02 |
proller |
upb = "!f() { echo squashing [$1] && git ups && git upsm && git branch -D $1 && git co master && git co -b $1 && git merge --squash origin/$1 && echo 'git commit && git push -f'; }; f" |
| 22:02 |
proller |
;) |
| 22:03 |
hmmmm |
that could come in handy |
| 22:07 |
proller |
my full set- https://github.com/proller/home/blob/master/.gitconfig |
| 22:12 |
proller |
commited, |
| 22:13 |
proller |
hmmmm, how to load mapblocks around generating huge cave to prevent flat edges? it possible? |
| 22:21 |
hmmmm |
if it were possible, it would've been done already |
| 22:25 |
|
jin_xi joined #minetest-dev |
| 22:26 |
jin_xi |
fwiw id like to keep the vector helpers |
| 22:26 |
|
kaeza joined #minetest-dev |
| 22:31 |
ShadowNinja |
https://github.com/minetest/minetest/pull/409 <-- This can be closed as #760 replaces it. |
| 22:32 |
ShadowNinja |
jin_xi: I don't want to remove them, just their metatables. You can still use vector.multiply(a, b) etc, just not v3 = v1 * v2 |
| 22:37 |
kahrl |
#926 looks good |
| 22:39 |
proller |
microsmall: https://github.com/minetest/minetest/pull/899 |
| 22:39 |
hmmmm |
no ;) |
| 22:41 |
proller |
why? |
| 22:41 |
VanessaE |
409/760 is absolutely a 'no'. |
| 22:41 |
VanessaE |
do not "fix" that. |
| 22:41 |
hmmmm |
because I see you're trying to sneak in weather and finite liquid by default |
| 22:41 |
PilzAdam |
there needs to be a way to disable the sneak glitches; I do not want them in Pilztest |
| 22:41 |
ShadowNinja |
kahrl: Then merge it. :-) |
| 22:41 |
proller |
hmmmm, if without defaulting? |
| 22:42 |
kahrl |
ShadowNinja: did someone else agree on it yet? |
| 22:42 |
hmmmm |
then, sure. |
| 22:42 |
proller |
ok |
| 22:42 |
ShadowNinja |
kahrl: No, but others don't have to for such simple changes. |
| 22:43 |
hmmmm |
I would set a boolean variable, call it 'use_weather', outside of the main game loop |
| 22:43 |
kahrl |
ShadowNinja: fair enough |
| 22:44 |
hmmmm |
things such as acquiring a lock, then doing a lookup, then parsing text, those are all unnecessarily time consuming things |
| 22:44 |
kahrl |
I'll merge it if no one is against in in a few minutes |
| 22:44 |
hmmmm |
people seem to use g_settings->get* like they're free but they aren't |
| 22:44 |
proller |
ups |
| 22:44 |
proller |
ok |
| 22:45 |
kahrl |
we should have a struct MinetestSettings that stores all core settings pre-parsed |
| 22:48 |
proller |
and transfer some settings to client |
| 23:02 |
proller |
more complex try: https://github.com/minetest/minetest/pull/892 |
| 23:03 |
proller |
it have default weather too, i will skip it |
| 23:04 |
proller |
and saving liquid_finite to map meta - by celeron55 request, it can be skipped too |
| 23:08 |
proller |
and hell in map.cpp 8) |
| 23:13 |
proller |
and MEGA this https://github.com/minetest/minetest/pull/882 |
| 23:20 |
hmmmm |
kahrl, we could do a lot of things. someday i'd like to profile how slow Settings is and see the impact it has on the overall performance, like how much time it eats of a Server step |
| 23:21 |
hmmmm |
the MinetestSettings struct could possibly be a bad idea, because any time some shmuck adds a setting, everybody else has to recompile from scratch |
| 23:22 |
hmmmm |
perhaps it could be a void * array, and you reference an ID constant instead of the actual member |
| 23:23 |
hmmmm |
actually nevermind, there's no way you can avoid that now that i think about it |
| 23:30 |
VanessaE |
oh G*d, whose idea was it to highlight "enabled" modpacks in really DARK green? |
| 23:33 |
kahrl |
VanessaE, I'm going to remove all the colors from that mod list when rewriting it using table[] |
| 23:33 |
kahrl |
enabled/disabled will be shown using checkboxes that can be clicked |
| 23:34 |
kahrl |
modpacks will be shown using a + or - that opens the modpack |
| 23:35 |
kahrl |
same with game mods and world mods |
| 23:36 |
VanessaE |
kahrl: the colors are fine, just use a brighter shade of green |
| 23:36 |
VanessaE |
but okay if you wanna use checkboxes |
| 23:38 |
kahrl |
I guess I'll leave the color indicating enabled mods there to see them more easily |
| 23:38 |
kahrl |
nothing else though |
| 23:43 |
|
djdduty joined #minetest-dev |
| 23:44 |
ShadowNinja |
Who will write libmtmap? |
| 23:45 |
ShadowNinja |
Add to dev wiki TODO? Under "Soon"? |
| 23:54 |
hmmmm |
meh |
| 23:54 |
hmmmm |
any one of us could really |
| 23:54 |
hmmmm |
i'd say it's a 2 day max job |
