| Time |
Nick |
Message |
| 00:01 |
|
Lunatrius joined #minetest-dev |
| 00:24 |
|
cib0 joined #minetest-dev |
| 00:30 |
|
asl97 joined #minetest-dev |
| 01:19 |
|
AnotherBrick joined #minetest-dev |
| 02:45 |
cg |
https://github.com/minetest/minetest_game/pull/683 |
| 03:56 |
|
Player_2 joined #minetest-dev |
| 04:36 |
hmmmm |
https://github.com/kwolekr/minetest/commit/b7d92ae861a0b15d0f40678da42b22e4d23503f6 |
| 04:36 |
hmmmm |
PTAL |
| 04:47 |
asl97 |
github diff sure isn't smart |
| 04:49 |
cg |
asl97 fixed |
| 04:50 |
asl97 |
there is still the space/tab mix |
| 04:51 |
cg |
on #683? |
| 04:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/683 -- Allow custom liquids to have drops by 0gb-us |
| 04:51 |
cg |
its all tab, god git hates me lol |
| 04:51 |
asl97 |
why change the file from space to tab? |
| 04:52 |
cg |
why use space? i never do |
| 04:54 |
cg |
actual question, is there a rule about spaces or tab for the engine/ _game code? |
| 04:54 |
asl97 |
yes there is |
| 04:54 |
VanessaE |
use tabs for primary formatting, indentation, etc, spaces to line stuff up after that |
| 04:54 |
VanessaE |
(like in a table) |
| 04:54 |
asl97 |
http://dev.minetest.net/MinetestWiki:Style_Guide |
| 04:54 |
cg |
ok so thats what i do |
| 04:57 |
asl97 |
cg: isn't it still the same? |
| 04:57 |
asl97 |
if the file doesn't exist, the input should be nil |
| 04:58 |
asl97 |
and then it throw(err) |
| 04:58 |
hmmmm |
anybody have anything about my commit? |
| 04:59 |
VanessaE |
hmmmm: only that it's another useful-looking feature. |
| 04:59 |
VanessaE |
but you already knew that :P |
| 05:00 |
asl97 |
it's the pregenerate world thing isn't it? |
| 05:00 |
hmmmm |
yeah |
| 05:00 |
hmmmm |
I'm sure modders are going to find some other fantastic use for emerge_area() though |
| 05:01 |
hmmmm |
also I think this is a decent time to finally add a callback mechanism for block emerge completion |
| 05:02 |
hmmmm |
I've been thinking a lot about things, does it actually make sense to store objects in a block? |
| 05:03 |
hmmmm |
if I were doing minetest from scratch I'd have all objects stored in a separate database or at least section |
| 05:03 |
asl97 |
getContainingChunk look nice, maybe you could prove an api for it too |
| 05:03 |
VanessaE |
I would give them their own section of the map database |
| 05:03 |
VanessaE |
however, having two separate databases is better |
| 05:03 |
hmmmm |
right, minetest can still evolve |
| 05:03 |
VanessaE |
/clearobjects --> os.delete(object_db) :) |
| 05:03 |
hmmmm |
yeah there's that advantage too |
| 05:04 |
hmmmm |
another thing I was envisioning was that mods can make queries to get "their" objects |
| 05:05 |
hmmmm |
instead of having to do that hacky workaround where they store object positions in a text file |
| 05:05 |
VanessaE |
now THAT could be useful |
| 05:05 |
hmmmm |
and then force load the blocks |
| 05:05 |
hmmmm |
I am always delighted by the creativity of modders though |
| 05:05 |
VanessaE |
don't you mean the abusiveness? ;) |
| 05:05 |
hmmmm |
yeah, abusiveness |
| 05:05 |
hmmmm |
I really wish they'd put that creativity/effort into making the engine better instead of hacking around it |
| 05:06 |
hmmmm |
minetest is NOT closed source |
| 05:06 |
cg |
but most find lua easy compared to c++ |
| 05:06 |
hmmmm |
I find the verbosity of lua to be suffocating |
| 05:07 |
VanessaE |
verbosity? |
| 05:07 |
hmmmm |
yeah.. if that's a good way to put it |
| 05:07 |
VanessaE |
aside from lack of trinary operators, what else is missing? |
| 05:07 |
VanessaE |
er, ternary |
| 05:07 |
hmmmm |
well it's a culmination of all the little things I guess |
| 05:07 |
hmmmm |
the mandatory "end" statement for example |
| 05:07 |
hmmmm |
the fact that it's a word at all |
| 05:08 |
VanessaE |
ok I'll grant you that. |
| 05:08 |
hmmmm |
it just feels like something that ought to be small turns out to be much larger and wordier |
| 05:08 |
hmmmm |
also not sure about break, but there's no continue statement in lua from what I understand |
| 05:08 |
hmmmm |
this leads to loops that are always like.. |
| 05:08 |
hmmmm |
if (blah) then if (blah2) then ( ... ) |
| 05:09 |
VanessaE |
mm, true |
| 05:09 |
cg |
there is a break, but continue idk |
| 05:09 |
hmmmm |
you have more levels of indentation than seems necessary |
| 05:09 |
VanessaE |
no case() statement either, some to think of it |
| 05:09 |
hmmmm |
yeah |
| 05:09 |
VanessaE |
come* |
| 05:09 |
hmmmm |
ewgh |
| 05:09 |
hmmmm |
well nevermind this language babble, it's not particularily constructive |
| 05:10 |
hmmmm |
I see est is making nice progress on voxel area entities, that's exciting to see |
| 05:21 |
cg |
any way of having a selection/collision mesh? |
| 05:22 |
VanessaE |
collision meshes, unlikely, but selection meshes would be useful in some situations. |
| 05:22 |
cg |
players and models for entities is my thoughts |
| 05:41 |
|
Hunterz joined #minetest-dev |
| 06:09 |
VanessaE |
hmmmm: thoughts on the "make the map larger" conversation from earlier? |
| 06:10 |
VanessaE |
(I expect "fuck no, the whole idea sucks") |
| 06:13 |
hmmmm |
sum it up for me? |
| 06:15 |
VanessaE |
the map's X/Z coords (only) should be extended to u32 or u64, damn the Lua torpedoes. imho, make new string-based hashing functions to replace the bitwise-based ones that currently return large-ish numbers (to avoid Lua's limits). Maybe add a config switch and/or auto-detect if the map is of the larger variety and disable access to the old hash functions |
| 06:16 |
VanessaE |
embedded in that discussion was the question of how VAE's ought be stored. |
| 06:16 |
VanessaE |
(no resolution was reached there) |
| 06:18 |
|
asl97 joined #minetest-dev |
| 06:18 |
|
asl97 joined #minetest-dev |
| 06:33 |
|
nrzkt joined #minetest-dev |
| 06:53 |
hmmmm |
that's a horrible idea |
| 06:54 |
hmmmm |
i see no reason why we need to extend the map coordinates, that breaks all kinds of compatibility |
| 06:55 |
VanessaE |
ok. |
| 06:59 |
|
kaeza joined #minetest-dev |
| 06:59 |
VanessaE |
it'll be needed sooner or later. |
| 06:59 |
VanessaE |
in either case, "almost infinite" and similar phrases need to be removed wherever they occur until then |
| 07:17 |
|
Darcidride joined #minetest-dev |
| 07:21 |
|
red1 joined #minetest-dev |
| 07:24 |
red1 |
is m_sectors a list of all sectors loaded? |
| 07:53 |
|
nrzkt joined #minetest-dev |
| 08:40 |
|
cib0 joined #minetest-dev |
| 08:41 |
|
asl97 joined #minetest-dev |
| 08:53 |
|
oleastre joined #minetest-dev |
| 08:59 |
|
H-H-H joined #minetest-dev |
| 09:02 |
|
Krock joined #minetest-dev |
| 09:18 |
asl97 |
cg went offline.... |
| 09:21 |
nrzkt |
cg ? |
| 09:22 |
asl97 |
[16:32:28] cg [~GP 204.111.255.5] has quit IRC: Quit: bye \o |
| 09:24 |
nrzkt |
and what is the problem with cg ? |
| 09:24 |
Krock |
oh yay, spreading IPs is always good |
| 09:24 |
asl97 |
Krock: everyone should have gotten the ip :| |
| 09:24 |
asl97 |
nrzkt: i was writing an benchmark as a respond his/her pm > https://github.com/minetest/minetest_game/pull/683#issuecomment-142540673 |
| 09:37 |
|
kilbith joined #minetest-dev |
| 09:45 |
|
rubenwardy joined #minetest-dev |
| 10:02 |
|
T4im joined #minetest-dev |
| 10:07 |
|
Krock joined #minetest-dev |
| 10:18 |
|
younishd joined #minetest-dev |
| 10:23 |
|
leat joined #minetest-dev |
| 10:26 |
|
cg joined #minetest-dev |
| 10:37 |
|
cib0 joined #minetest-dev |
| 11:00 |
rubenwardy |
the map size in MT is less than earth, it's not even a country |
| 11:01 |
rubenwardy |
It becomes limited if you want to make country maps etc |
| 11:01 |
kilbith |
there's no mountains of size of Himalaya either.. |
| 11:02 |
rubenwardy |
and for MM server |
| 11:02 |
rubenwardy |
admittedly MT doesn't have the interest for that |
| 11:03 |
rubenwardy |
but big changes cause instability and bugs |
| 11:04 |
asl97 |
does minetest or even minecraft scale well to those kind of size? in fact, does the backend even scale that large? |
| 11:04 |
rubenwardy |
They've built the UK in MC |
| 11:04 |
rubenwardy |
from OS maps |
| 11:04 |
rubenwardy |
(ordinate surveys) |
| 11:05 |
rubenwardy |
MC is purportedly 4,000,000m |
| 11:05 |
rubenwardy |
ofc there's buggy areas at the edges |
| 11:05 |
asl97 |
iirc, float point error are still a mess at those size |
| 11:05 |
asl97 |
or whatever error it is |
| 11:06 |
rubenwardy |
My view is that a larger map could be needed/wanted, however it's not essential and other stuff is more important |
| 11:06 |
kilbith |
even bigger then UK : http://www.planetminecraft.com/project/the-recreation-of-the-earth-11500-scale/ |
| 11:06 |
rubenwardy |
like fixing inventories, networks, client side mods, environmental sounds, etc |
| 11:08 |
|
Hunterz1 joined #minetest-dev |
| 11:17 |
|
proller joined #minetest-dev |
| 11:22 |
|
Krock joined #minetest-dev |
| 11:42 |
asl97 |
why does minetest.get_craft_recipe(*something invalid like air*) return {width = 0} instead of nil? |
| 11:54 |
|
proller joined #minetest-dev |
| 11:54 |
|
Krock joined #minetest-dev |
| 11:54 |
|
proller joined #minetest-dev |
| 12:10 |
|
asl joined #minetest-dev |
| 12:15 |
|
Elinvention joined #minetest-dev |
| 12:25 |
|
red1 joined #minetest-dev |
| 12:28 |
|
lisacvuk joined #minetest-dev |
| 12:35 |
|
proller joined #minetest-dev |
| 13:07 |
|
Elinvention joined #minetest-dev |
| 13:51 |
|
Krock joined #minetest-dev |
| 13:51 |
|
hmmmm joined #minetest-dev |
| 14:17 |
|
7GHAA9CLS joined #minetest-dev |
| 14:25 |
|
proller joined #minetest-dev |
| 14:26 |
|
exio4 joined #minetest-dev |
| 14:45 |
|
cheapie joined #minetest-dev |
| 15:07 |
|
cheapie joined #minetest-dev |
| 15:26 |
|
est31 joined #minetest-dev |
| 15:29 |
est31 |
hmmmm, remember to get rid of this https://github.com/kwolekr/minetest/commit/b7d92ae861a0b15d0f40678da42b22e4d23503f6#diff-93af8f0472f15bf128803754d689a4e2R775 |
| 15:31 |
est31 |
wow we really test the misc helpers at loadtime |
| 15:31 |
est31 |
this is bad |
| 15:31 |
hmmmm |
yup, I did get rid of that, I uploaded a new version of that commit |
| 15:32 |
hmmmm |
well I just figured it'd be a nice idea to follow along with the other code in that file |
| 15:32 |
hmmmm |
can't hurt too much |
| 15:32 |
est31 |
it impedes startup time |
| 15:32 |
est31 |
yea, but it should probably be generally fixed |
| 15:32 |
est31 |
e.g. put all the asserts and so on into another file |
| 15:33 |
est31 |
string_to_area isnt documented |
| 15:34 |
hmmmm |
should it be? |
| 15:34 |
est31 |
string_to_pos is |
| 15:34 |
hmmmm |
mm |
| 15:34 |
|
eugd joined #minetest-dev |
| 15:34 |
|
ElectronLibre joined #minetest-dev |
| 15:35 |
est31 |
https://github.com/kwolekr/minetest/commit/dcf1c0baa50e26ac4aaaa1774117a37e0e3e4b7e#diff-c6d551e431c1fb79f5cf714da9b6c604R67 |
| 15:35 |
est31 |
some people wont like that |
| 15:35 |
est31 |
they prefer if not p1 then |
| 15:37 |
est31 |
string_to_area is only used in parse_range_str right? |
| 15:38 |
|
proller joined #minetest-dev |
| 15:38 |
nanepiwo |
has anyone seen lightning glitches with v7 mapgens? I'm using paragenv7 and some regions away from spawn are very very dark |
| 15:39 |
nanepiwo |
might it also be a client problem? |
| 15:39 |
eugd |
does anyone know where in the code spawn coordinate is determined? |
| 15:39 |
est31 |
hmmmm, the general problem I have with the emerge_area callback is that it doesnt give any guarantees |
| 15:39 |
eugd |
especially for singleplayer, i'd assume (servers will set player initial spawn, right?) |
| 15:40 |
nanepiwo |
eugd, to change it use set_static_spawnpoint |
| 15:40 |
est31 |
you just call the area to be emerged, but it can be unloaded later |
| 15:40 |
est31 |
also no guarantee when it will be loaded |
| 15:40 |
est31 |
so people will still be forced to create voxelmanips |
| 15:41 |
hmmmm |
the purpose behind this is to pre-generate map, mostly |
| 15:41 |
|
Amaz joined #minetest-dev |
| 15:41 |
est31 |
perhaps it shouldn't be called then "emerge" |
| 15:41 |
hmmmm |
but it does exactly that |
| 15:41 |
est31 |
"generate"? |
| 15:42 |
T4im |
wouldn't voxelmaniping an area do the same? |
| 15:42 |
est31 |
hmmmm's commit would give a more lightweight alternative |
| 15:43 |
est31 |
manips copy the whole content dont they |
| 15:43 |
|
Amaz joined #minetest-dev |
| 15:44 |
est31 |
also, it gives no indication when mapgen has finished |
| 15:44 |
est31 |
e.g. if you want to emerge a certain area on your server you may want to shut it down when emerge is done so that you can restart it as a public server |
| 15:44 |
est31 |
or so |
| 15:46 |
|
Lunatrius` joined #minetest-dev |
| 15:46 |
|
eugd joined #minetest-dev |
| 15:48 |
|
eugd left #minetest-dev |
| 15:49 |
T4im |
ah, ok :) |
| 15:50 |
est31 |
(note that the "also, it gives no indication when mapgen has finished" is a comment on hmmmm's commit and not the voxelmanip method. the voxelmanip method would allow better control in this regard) |
| 15:51 |
|
eugd joined #minetest-dev |
| 15:51 |
hmmmm |
voxelmanip would not generate the map at that point, i don't think |
| 15:51 |
hmmmm |
pretty sure if the block doesn't exist on disk it would create a blank placeholder block |
| 15:52 |
T4im |
btw, want me to add test_string_to_area() to coretest? that way you have it out of the way during startup |
| 15:52 |
|
Hunterz joined #minetest-dev |
| 15:52 |
hmmmm |
sure |
| 15:52 |
hmmmm |
in the function above there are also tests |
| 15:52 |
hmmmm |
it's just that i had to make this into a separate testing function because of the scope for temp variables |
| 15:53 |
eugd |
where is singleplayer spawn location determined? it seems to be a range several hundred blocks of 0 0 0 |
| 15:53 |
eugd |
is it property of minetest_game? |
| 15:53 |
hmmmm |
it's random |
| 15:57 |
|
eugd joined #minetest-dev |
| 15:59 |
est31 |
note that I dont have any real progress on VAEs in code, I only think right now how to do it |
| 16:00 |
T4im |
developing != coding ;) |
| 16:00 |
est31 |
lol |
| 16:00 |
est31 |
but you are right |
| 16:01 |
est31 |
coders are the "fachinformatiker", developers are those who have studied it |
| 16:01 |
eugd |
re: VAEs, imo should not just slice up map |
| 16:01 |
T4im |
you could develop something on paper and send it to a bunch of programmers to code it down |
| 16:02 |
eugd |
should start by making map variable size and maybe shape (still rectangular but non-cube) |
| 16:02 |
eugd |
and then having multiple maps in environment |
| 16:03 |
est31 |
the only real problem I face with VAEs is lighting |
| 16:04 |
est31 |
our current lighting system is designed for a non-VAE world |
| 16:04 |
eugd |
imo lighting also should be removed from map |
| 16:04 |
eugd |
put in environment |
| 16:04 |
est31 |
its stored and sent over the network inside the mapblocks, |
| 16:05 |
eugd |
having block 'light level' is one of the uglier parts of mc inheritance |
| 16:05 |
est31 |
eugd, do you have a better idea for lighting? |
| 16:05 |
eugd |
not really |
| 16:05 |
eugd |
just to do it like any other graphics engine |
| 16:05 |
eugd |
divorce it from gameplay at base |
| 16:06 |
hmmmm |
I have a really simple way to do the sunlight |
| 16:06 |
est31 |
? |
| 16:06 |
hmmmm |
it could be a single dynamic light |
| 16:06 |
eugd |
and then if needed have blocks/nodes/entities query environment |
| 16:06 |
hmmmm |
that would improve the look of minetest x500 but it wouldn't offer a solution for light sources (huge problem) |
| 16:07 |
est31 |
traditional engines load the whole map, not just parts of it |
| 16:08 |
hmmmm |
traditional games load up a single mesh for the entire world (or a significant portion of it) along with a static lightmap |
| 16:09 |
hmmmm |
we are essentially re-generating the lightmap each time a mesh is regenerated |
| 16:09 |
hmmmm |
except cheaply, because our lights are distributed along a regular grid of distances |
| 16:09 |
hmmmm |
so vertex lighting |
| 16:10 |
hmmmm |
another complicated idea I had was very carefully managing dynamic lights |
| 16:10 |
hmmmm |
if several light sources are in proximity, they could be combined |
| 16:10 |
hmmmm |
less significant lights could be culled out from the scene |
| 16:10 |
hmmmm |
etc. |
| 16:11 |
VanessaE |
isn't this the sort of thing shaders were designed for? |
| 16:11 |
hmmmm |
no |
| 16:12 |
|
lisacvuk joined #minetest-dev |
| 16:13 |
VanessaE |
well pixel shaders are, for sure. |
| 16:13 |
VanessaE |
either way, seems to me the best idea is to have statically-stored/generated data in the map like we have now, and use shaders to actually render the lighting. |
| 16:13 |
VanessaE |
the GPU will always be faster than the CPU at this task. |
| 16:14 |
|
nerzhul_ joined #minetest-dev |
| 16:15 |
VanessaE |
i.e. ditch the CPU-managed "smooth" lighting we have now, that barely works as it is, and let the GPU handle it like it's designed to. |
| 16:15 |
est31 |
VanessaE, sounds like you want to implement that :) ? |
| 16:15 |
VanessaE |
nope :) |
| 16:15 |
hmmmm |
lol |
| 16:15 |
VanessaE |
that's RBA's territory actually. |
| 16:16 |
hmmmm |
VanessaE, it's our job to store the lighting information |
| 16:16 |
hmmmm |
like I said, in normal games, this is stored as another texture |
| 16:16 |
VanessaE |
hmmmm: of course. but not to *render* it (i.e. modifying vertex lighting values or whatever it is we do now) |
| 16:16 |
hmmmm |
there are dynamic lights but gpus only have a small number, like 4 or 8 of them, available on the screen at the same time |
| 16:16 |
est31 |
we could in fact only store the lighting info at the edges of a mapblock |
| 16:16 |
est31 |
then calculate the rest |
| 16:17 |
hmmmm |
est31, yea that was my idea at one point |
| 16:17 |
hmmmm |
it works |
| 16:17 |
hmmmm |
you only need to save 96 light values vs. 4096 |
| 16:17 |
eugd |
i'd like to suggest again a fundamental change to engine in direction of facilitating VAEs |
| 16:18 |
hmmmm |
and the only time lighting is actually used is during mesh making (and checking light values at a point, for some mods) |
| 16:18 |
eugd |
that it becomes environment- rather than map- focused |
| 16:18 |
est31 |
hmmmm, dont forget entities |
| 16:18 |
hmmmm |
? |
| 16:19 |
hmmmm |
eugd: I thought that was the plan all along, no? |
| 16:19 |
est31 |
if you have an entity, it has the same light value as the block its "root" position is inside |
| 16:19 |
eugd |
i don't really know, probably not up to date |
| 16:19 |
hmmmm |
the map db would just be a convenient place to store it |
| 16:19 |
hmmmm |
est31: oh yeah |
| 16:19 |
eugd |
entities should have their own maps |
| 16:19 |
est31 |
made so that if you are in a dark cave, you don't shine like a torch :) |
| 16:19 |
hmmmm |
est31: any suggestions for that? :p |
| 16:19 |
eugd |
right? as VAES |
| 16:20 |
|
nerzhul_ joined #minetest-dev |
| 16:20 |
hmmmm |
eugd, I think so yeah |
| 16:20 |
eugd |
i don't know efficiency issues with overhead for database stuff, if they'd actually have their own DBs |
| 16:21 |
hmmmm |
probably not too much tbh |
| 16:21 |
est31 |
giving every VAE its own database? no, thats too laggy |
| 16:21 |
est31 |
better store them in one big database |
| 16:22 |
eugd |
i thought would be very cool to give players own VAE space |
| 16:22 |
|
nerzhul_ joined #minetest-dev |
| 16:22 |
eugd |
for unique player avatars |
| 16:23 |
eugd |
what would cause lag in many database? |
| 16:23 |
eugd |
locking? |
| 16:23 |
eugd |
i see in code much concern about that |
| 16:24 |
eugd |
or is it just innate overhead stuff? |
| 16:28 |
eugd |
did i lose connection? |
| 16:28 |
|
eugd left #minetest-dev |
| 16:28 |
|
eugd joined #minetest-dev |
| 16:29 |
|
DFeniks joined #minetest-dev |
| 16:29 |
hmmmm |
one feature at a time |
| 16:29 |
eugd |
do we have a current focus? |
| 16:36 |
hmmmm |
my focus is supposed to be client side modding |
| 16:36 |
hmmmm |
but i take a break in between to work on some smaller things that pop up |
| 16:40 |
T4im |
compiler complains about count being potentially uninit in l243/l276 btw |
| 16:41 |
est31 |
T4im, about #2235 usually issues are only closed if the pr is merged |
| 16:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/2235 -- Clarify radii and distance types in documentation |
| 16:43 |
T4im |
its superseded by that other issue :P https://github.com/minetest/minetest/issues/3192 |
| 16:44 |
|
Robert_Zenz joined #minetest-dev |
| 16:44 |
hmmmm |
okay how about now https://github.com/kwolekr/minetest/commit/68eef323d3bbcdf9c190df086a2ee5843d6d8083 |
| 16:46 |
est31 |
the queue had a maximum size? |
| 16:46 |
est31 |
damn of course it was totally broken for the purposes I used it |
| 16:47 |
eugd |
what is core dev teams position on having variable map sizes and shapes? there is hearsay on forums that it is firmly rejected. |
| 16:49 |
est31 |
eugd, you can limit the map size if you want |
| 16:49 |
est31 |
rubenwardy has added such functionality to the engine |
| 16:49 |
est31 |
and about shapes... well.. we are a voxel game, dont know whats so appealing about circles |
| 16:50 |
est31 |
either way, we do allow for slopes etc, so you can have "smooth" landscapes if you want |
| 16:50 |
T4im |
well technically they are circles :> |
| 16:50 |
est31 |
erm spheres ofc |
| 16:50 |
T4im |
or that, yes |
| 16:51 |
T4im |
didn't someone even already mapgen those slopes into the landscape? |
| 16:51 |
est31 |
yea |
| 16:51 |
est31 |
thats where that idea is from :) |
| 16:52 |
T4im |
I wonder how that performed rendering wise |
| 16:52 |
eugd |
i was thinking more like |
| 16:53 |
eugd |
MAX_MAP_GENERATION_LIMIT |
| 16:53 |
eugd |
and associated |
| 16:53 |
eugd |
adding two more |
| 16:53 |
est31 |
eugd, that functionality exists |
| 16:53 |
T4im |
if the new emerge function allows to ignore that generation limit, couldn't you even "create" shapes? |
| 16:53 |
eugd |
to have limited x/y/z |
| 16:53 |
T4im |
by actively emerging shapes outside the generation limit? |
| 16:53 |
eugd |
from engine rather than lua |
| 16:53 |
est31 |
no it doesnt allow the generation limit |
| 16:54 |
est31 |
eugd, the xyz are automatially limited by mapgen |
| 16:54 |
eugd |
i was just saying |
| 16:54 |
est31 |
you cant enter areas that arent generated |
| 16:54 |
eugd |
the way it's set up now |
| 16:54 |
eugd |
you are stuck to cubic worlds |
| 16:54 |
eugd |
regular rectangles |
| 16:54 |
eugd |
because we only have one value that it checks for all three axis |
| 16:59 |
eugd |
est31 'automatically limited by mapgen' you mean lua mapgens can set limits? i figured that |
| 17:00 |
|
MinetestForFun joined #minetest-dev |
| 17:00 |
eugd |
but would be nice as a core engine feature too (?) |
| 17:00 |
T4im |
it is limited by the engine mapgen |
| 17:00 |
T4im |
not by lua |
| 17:00 |
eugd |
you just mean the 64k cube limit? |
| 17:00 |
T4im |
you can decrease that limit |
| 17:00 |
eugd |
yeah |
| 17:00 |
eugd |
i was suggesting |
| 17:01 |
eugd |
just adding variables for limits per-axis |
| 17:01 |
|
Calinou joined #minetest-dev |
| 17:01 |
eugd |
not sure if understood |
| 17:05 |
|
troller joined #minetest-dev |
| 17:05 |
eugd |
and i'm asking if the core dev team would be opposed to that addition |
| 17:06 |
eugd |
splitting map_generation_limit into three variables one for each axis |
| 17:06 |
sfan5 |
sounds like an useful addition |
| 17:07 |
eugd |
that's actually something i'm not even sure of |
| 17:07 |
est31 |
I'm not strictly against that, but wondering about use cases |
| 17:07 |
eugd |
i *think* lua could do the same thing? right? so would it actually be useful |
| 17:07 |
Calinou |
at least make Y axis configurable separately |
| 17:07 |
eugd |
calinou exactly |
| 17:07 |
eugd |
that's the real problem |
| 17:07 |
Calinou |
yes, you can do it in Lua more or less well |
| 17:07 |
Calinou |
but it'll be slower than a C++ solution |
| 17:08 |
eugd |
ok, cool |
| 17:08 |
est31 |
Calinou, do you want it to be minecraft limited |
| 17:08 |
Calinou |
maybe some people like it so |
| 17:08 |
eugd |
est31 exactly :) |
| 17:08 |
T4im |
you can't make lua stop generating something, you can just attempt to catch the players before they trigger it, afaik :P |
| 17:08 |
eugd |
minecraft backwards compatibility |
| 17:08 |
est31 |
we are no minecraft clone |
| 17:08 |
Calinou |
I still want a full-world Minecraft converter :( |
| 17:09 |
eugd |
minecraft 2 |
| 17:09 |
est31 |
Calinou, doesnt the one hmmmm has created work? |
| 17:09 |
Calinou |
Minceraft 2, you mean :-) |
| 17:09 |
T4im |
no, that's probably the only way you can cobble off microsoft... messing with their trademark |
| 17:09 |
hmmmm |
that's for minecraft classic |
| 17:09 |
Calinou |
est31, haven't tried it... does it work on "real" worlds and handle Minecraft-specific worlds nicely? |
| 17:09 |
T4im |
:P |
| 17:09 |
est31 |
T4im's idea is good e.g. you can just hurt players if they are outside "legal" bounds |
| 17:09 |
Calinou |
yeah, I want something for the full game |
| 17:09 |
est31 |
like in lava |
| 17:10 |
T4im |
est31: the issue with lua trying to do these things, is that its unreliable |
| 17:10 |
T4im |
a malicious player can just teleport into a corner and trigger mapgen, no matter what lua tries to do |
| 17:10 |
est31 |
but they can't "play" there |
| 17:11 |
T4im |
and even a common player might go a little out of bounds with sufficient lag |
| 17:11 |
est31 |
because they get killed |
| 17:11 |
Calinou |
client-side damage can be undone on client |
| 17:11 |
Calinou |
it's quite easy to have a god mode IIRC |
| 17:11 |
Calinou |
(except from actual player punches or server-side settings) |
| 17:11 |
T4im |
wasn't there still that bug, that if your health is negative/zero, that you won't take more damage? :P |
| 17:12 |
T4im |
and won't die either |
| 17:12 |
est31 |
well, after some distance, it can just teleport you |
| 17:13 |
eugd |
i have another question |
| 17:13 |
T4im |
but it won't prevent mapgen running.. and with that won't prevent disk space waste (which vps run servers might have problems with) or mapgen lag |
| 17:13 |
eugd |
would there be a likely problem from having two 'instances' of the same block? |
| 17:14 |
eugd |
for example in the extreme case of a 1x1 block world |
| 17:14 |
eugd |
i am wanting to do looping worlds |
| 17:14 |
eugd |
and thinking best way is just to do a direct and actual instance |
| 17:14 |
eugd |
but would it likely just crash from memory access clusterfuck? |
| 17:15 |
eugd |
or not really? |
| 17:27 |
|
kilbith joined #minetest-dev |
| 17:30 |
eugd |
is there a technically ideal MAP_BLOCKSIZE? i've asked this before on the forums a year ago |
| 17:31 |
est31 |
#3197 looks fine for me |
| 17:31 |
ShadowBot |
https://github.com/minetest/minetest/issues/3197 -- Save and remove player by pointer by nerzhul |
| 17:31 |
est31 |
will merge it |
| 17:31 |
est31 |
or nerzhul_ do you want to push it? |
| 17:32 |
est31 |
and remove the playersave_perfix branch :) |
| 17:32 |
nerzhul_ |
i let you push it :) |
| 17:32 |
nerzhul_ |
i'm working on another thing :p |
| 17:33 |
|
proller joined #minetest-dev |
| 17:33 |
|
H-H-H joined #minetest-dev |
| 17:34 |
|
zupoman joined #minetest-dev |
| 17:36 |
nrzkt |
thanks est31 |
| 17:36 |
|
paramat joined #minetest-dev |
| 17:37 |
|
twoelk joined #minetest-dev |
| 17:37 |
|
cib0 joined #minetest-dev |
| 17:38 |
hmmmm |
est31: any word about dcf1c0b? |
| 17:40 |
est31 |
perhaps the chat command description should reflect the fact that its async as well? |
| 17:40 |
paramat |
nanepiwo there are some minor lighting bugs in mgv7, please post a screenshot if you can. also, are you using moretrees mod or l-system trees? those cause dark patches |
| 17:40 |
est31 |
otherwise, ok from what I see |
| 17:40 |
est31 |
but im not very familiar with chunks etc |
| 17:41 |
hmmmm |
well okay |
| 17:41 |
nrzkt |
thanks est31 |
| 17:43 |
est31 |
hmmmm, problem |
| 17:43 |
est31 |
why do you set allow_generate to false? |
| 17:43 |
hmmmm |
ah |
| 17:43 |
hmmmm |
because it doesn't matter |
| 17:43 |
est31 |
it doesnt seem to matter right now because its only used in dead code |
| 17:44 |
est31 |
but perhaps in future people might change the impl |
| 17:44 |
hmmmm |
force_queue_block overrides what allow_generate would do |
| 17:44 |
est31 |
and then bug reports pop up |
| 17:44 |
hmmmm |
yeah to be honest emergequeue needs a lot of work |
| 17:44 |
est31 |
^ |
| 17:44 |
est31 |
THIS. |
| 17:44 |
est31 |
we'd need a non locking queue impl |
| 17:45 |
hmmmm |
what do you personally think needs the most fixing with it |
| 17:45 |
est31 |
its mostly features |
| 17:45 |
hmmmm |
oh |
| 17:45 |
est31 |
e.g. I want to be abled to force loading an area |
| 17:46 |
est31 |
without voxelmanips etc |
| 17:46 |
hmmmm |
that has more to do with the environment than it does with the emerge queue though, does it not? |
| 17:46 |
est31 |
just for getting and parsing a mapblock |
| 17:46 |
est31 |
my usecase is benchmarking mapblock compression |
| 17:46 |
est31 |
and for that you need mapblock data |
| 17:47 |
hmmmm |
isn't there a forceload block feature? |
| 17:47 |
est31 |
I could perhaps indeed use that, as it seems |
| 17:48 |
hmmmm |
hrmm |
| 17:48 |
hmmmm |
is the way emerge_area and delete_area are implemented kind of dumb |
| 17:48 |
hmmmm |
shouldn't it be emerge_block and delete_block, and then have the part where it iterates over the area as part of a lua wrapper function |
| 17:48 |
hmmmm |
what do you think? |
| 17:49 |
est31 |
no it seems fine |
| 17:49 |
hmmmm |
really the way force loading should be implemented is that it should be an option to emerge_block() |
| 17:50 |
est31 |
the biggest problem remaining with your patch for me is that the user has no way to know when mapgen finished |
| 17:50 |
hmmmm |
small steps |
| 17:50 |
hmmmm |
you need to fight the temptation to shove all of the functionality into a single commit |
| 17:50 |
est31 |
meh no |
| 17:50 |
hmmmm |
each commit needs to have a very focused goal |
| 17:50 |
est31 |
well yeah, no problem |
| 17:50 |
est31 |
if you promise to do it, then its ok |
| 17:51 |
est31 |
because you keep your promises :) |
| 17:51 |
hmmmm |
yeah I see what you mean |
| 17:51 |
hmmmm |
I guess this would be something to be wary of with an occasional contributer |
| 17:52 |
hmmmm |
rather than a devoted developer who's sticking around |
| 17:52 |
T4im |
and the uninit variable is not a problem? |
| 17:52 |
hmmmm |
what uninitialized variable |
| 17:53 |
T4im |
(06:40:35 PM) T4im: compiler complains about count being potentially uninit in l243/l276 btw |
| 17:53 |
hmmmm |
1243?? |
| 17:53 |
hmmmm |
what is that |
| 17:53 |
T4im |
line* |
| 17:53 |
hmmmm |
which file |
| 17:53 |
T4im |
emerge.cpp |
| 17:53 |
hmmmm |
1243 hasn't been modified |
| 17:53 |
est31 |
lol thats outside of hmmmm 's changes |
| 17:54 |
est31 |
I just guess that applying the patch has triggered recompiling |
| 17:54 |
est31 |
which means that you get the warning again |
| 17:54 |
est31 |
but if you do a clean build on a normal copy you should get the warning as well |
| 17:54 |
est31 |
(if my theory is right xD) |
| 17:55 |
hmmmm |
emerge.cpp only has 573 lines |
| 17:55 |
T4im |
the "1" is a "l" |
| 17:55 |
T4im |
L243/L276 |
| 17:55 |
T4im |
bad font :P |
| 17:56 |
hmmmm |
ahhh |
| 17:56 |
hmmmm |
nice catch |
| 17:56 |
est31 |
yup seeing it as well |
| 17:56 |
est31 |
count = blocks_enqueued.size(); |
| 17:56 |
hmmmm |
that actually might have caused a problem |
| 17:56 |
hmmmm |
or would it... |
| 17:57 |
est31 |
it would |
| 17:59 |
hmmmm |
hmm |
| 17:59 |
hmmmm |
the queue limit is kind of broken anyway |
| 17:59 |
est31 |
where |
| 17:59 |
hmmmm |
when I said that I think the emerge queue needs work, in particular what it needs is an actual way to discriminate against blocks that exist on disk vs. blocks that need to be generated |
| 18:00 |
paramat |
oh nanepiwo also note the y co-ord of the lighting bug |
| 18:00 |
hmmmm |
you can't tell unless you do a slow, blocking call to Map::emergeBlock(), or until the emerge queue already processed it |
| 18:00 |
hmmmm |
so the disk queue limit vs. generate limit are broken |
| 18:00 |
hmmmm |
s/are/is |
| 18:01 |
hmmmm |
i had an idea of how to fix, but it requires preloading a sparse table of all the blocks existing on the map |
| 18:01 |
hmmmm |
since this set is huge, i need to come up with an uber efficient data structure |
| 18:01 |
hmmmm |
I think possibly the Z addressing scheme would help here |
| 18:02 |
T4im |
bloom filter? |
| 18:02 |
est31 |
why do we need such a queue anyway |
| 18:03 |
hmmmm |
T4im, yeah, I think I was looking at that too |
| 18:03 |
hmmmm |
there was a problem with it iirc |
| 18:03 |
est31 |
preloading blocks on the map is very slow for leveldb databases |
| 18:03 |
hmmmm |
not preloading |
| 18:03 |
hmmmm |
just reading which ones exist in the DB |
| 18:04 |
est31 |
yes precisely that |
| 18:04 |
hmmmm |
this is obviously going to be slow |
| 18:04 |
est31 |
sqlite is faster |
| 18:04 |
est31 |
just leveldb has problems out of which reason |
| 18:04 |
hmmmm |
so another thought was that I should cache this existence table in the db |
| 18:06 |
est31 |
just try this commit https://github.com/est31/minetest/commit/cb85dbd03ecec23d5d92994498f4e3e2aaf09c31 |
| 18:06 |
est31 |
it will hang forever for leveldb |
| 18:07 |
est31 |
caching might be needed |
| 18:07 |
est31 |
but again, why do we need that queue limiting? |
| 18:07 |
est31 |
and why does it have to be separate between map and mapgen |
| 18:07 |
hmmmm |
the queue limiting was there before I started coding minetest |
| 18:07 |
hmmmm |
so |
| 18:08 |
hmmmm |
ask celeron :p |
| 18:08 |
est31 |
I can partially understand that its needed so that the server doesnt lag totally |
| 18:08 |
est31 |
or that you cant DOS a server by having 20 clients fly around |
| 18:09 |
est31 |
but it seems to have problems |
| 18:09 |
celeron55 |
i don't think i have much more insight to it than you do |
| 18:09 |
est31 |
e.g. it might be that that limiting is the reason why sometimes you have to wait so long for mapgen |
| 18:09 |
celeron55 |
but having a queue that some issue or someone can make infinitely grow will generally make all kinds of hangs and DoSes completely distrastrous |
| 18:09 |
est31 |
while in fact you dont wait for mapgen, its just the queue thats full |
| 18:10 |
hmmmm |
hmm |
| 18:10 |
hmmmm |
a lot of us just keep the same overall design from celeron |
| 18:11 |
hmmmm |
it's a tough habit to break; you come to work on minetest but you don't want to ruin something that already works, or you don't question why something is that way, so you leave it go |
| 18:11 |
|
twoelk|2 joined #minetest-dev |
| 18:11 |
celeron55 |
i can believe it if you're saying its design has some kind of a problem if it's something that's there just because i added it at some early point |
| 18:11 |
hmmmm |
thinking critically about the emerge queue limit, I don't see why it needs to be done in that manner, but then again, I don't see why the emerge queue needs to be done in this manner at all.. |
| 18:12 |
eugd |
anyone got a moment to look at map.cpp for me? |
| 18:12 |
eugd |
search for "map_generation_limit" |
| 18:12 |
hmmmm |
still to this day I have this fear that if I change something in minetest that was there already, it's going to explode in unpredictable ways |
| 18:12 |
hmmmm |
eugd: ?? what about it |
| 18:12 |
paramat |
eugd initial player spawn is a random search starting at 0,0 and working outwards with increasing radius, it calls the mapgen's 'ground level at point' to search for dry land at low altitude |
| 18:13 |
eugd |
wow thanks paramat |
| 18:13 |
eugd |
it doesn't look for trees? |
| 18:13 |
eugd |
can you point me to the code for it? |
| 18:13 |
kilbith |
eugd: your answer is likely here : ec796b8e |
| 18:13 |
eugd |
kilbith i don't know what that means :( |
| 18:14 |
est31 |
its a commit hash |
| 18:14 |
eugd |
ha showing my inexperience |
| 18:14 |
paramat |
no check for trees, so sometimes you are inside one |
| 18:14 |
eugd |
and also can be far, far away from any, right? |
| 18:14 |
paramat |
i don't remember where the code is |
| 18:14 |
paramat |
yeah |
| 18:15 |
eugd |
anyway my real concern was to limit its reach from 0,0 |
| 18:15 |
eugd |
or make that an option |
| 18:15 |
eugd |
um back to map.cpp |
| 18:16 |
paramat |
spawn will always be as close to 0,0 as possible |
| 18:16 |
eugd |
starting line 2579 |
| 18:16 |
eugd |
is there a reason this little segment is the way it is, rather than just calling back to one of the functions from mapblock.h? |
| 18:23 |
nanepiwo |
paramat, about my lightning bugs: I'm using your paragenv7 mod, not sure of kinds of trees. it happens only in regions far enough out of spawn, which I think were generated after I updated my minetest server version |
| 18:24 |
kahrl |
weren't fireflies removed a long time ago |
| 18:24 |
eugd |
no one wants to help or no one knows re map.cpp 2581-2588? |
| 18:24 |
eugd |
kahri not sure if joking |
| 18:24 |
eugd |
he means lighting errors |
| 18:24 |
kahrl |
oh, ok |
| 18:25 |
paramat |
lol |
| 18:26 |
paramat |
yes more recent MT has different lighting bugs due to changes in mgv7 lighting calculations |
| 18:26 |
paramat |
worst shadows are at y = 63 |
| 18:27 |
nanepiwo |
I'm away from my machine right now, but they basically look like the endless shadows similar to those caused by worldedit |
| 18:27 |
nanepiwo |
I've tested between y = 0 and y = 100is, still dark |
| 18:27 |
nanepiwo |
and rapidly becomes so |
| 18:28 |
paramat |
#2759 is one current bug |
| 18:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/2759 -- Lighting bug at y = 63 in mgv7 and core mapgens in development |
| 18:28 |
MinetestForFun |
this lightning problem is boring, in mapgenv6 with watershed i can see this shadows, and with a mapgenv7 not tweaked, i can see more and more shadows issues :/ |
| 18:28 |
Soni |
so let's say I can add full Lua 5.2 compat to LuaJIT |
| 18:28 |
Soni |
(and even Lua 5.3) |
| 18:29 |
Soni |
(yes, it's a bit overengineered, but w/e) |
| 18:29 |
hmmmm |
I've heard some stuff about lua 5.3 being faster than luajit |
| 18:29 |
paramat |
watershed should be used in singlenode |
| 18:29 |
Soni |
if I do it, can we switch to Lua 5.2+? |
| 18:29 |
MinetestForFun |
oh yes sorry, watershed + singlenode = shadows |
| 18:29 |
|
lisacvuk joined #minetest-dev |
| 18:29 |
paramat |
ok |
| 18:29 |
nanepiwo |
its the whole entire region for me |
| 18:29 |
MinetestForFun |
my mistake :p |
| 18:29 |
Soni |
(not that we'd have to - LuaJIT would already support it) |
| 18:29 |
|
twoelk|2 joined #minetest-dev |
| 18:29 |
Soni |
(so we'd just have to update LuaJIT) |
| 18:29 |
hmmmm |
Soni: the lua language itself is reverse-compatible, correct? |
| 18:29 |
Soni |
not really |
| 18:29 |
hmmmm |
ahh |
| 18:30 |
Soni |
Lua 5.2 brings _ENV |
| 18:30 |
hmmmm |
see that's the problem |
| 18:30 |
T4im |
well you can compensate for that |
| 18:30 |
hmmmm |
is there a utility similar to Python's 2to3? |
| 18:30 |
Soni |
anyway, overengineering |
| 18:30 |
Soni |
ew 2to3 |
| 18:30 |
Soni |
no |
| 18:30 |
hmmmm |
okay nevermind |
| 18:30 |
T4im |
there's drop-in replacements for setfenv for example written in lua |
| 18:30 |
Soni |
I wanna make an universal Lua VM |
| 18:30 |
hmmmm |
we definitely need reverse compatibility |
| 18:30 |
paramat |
well, best to post a screenshot of the lighting bug sometime later |
| 18:30 |
hmmmm |
the thing that makes minetest great are the mods |
| 18:31 |
Soni |
it'll be built-in |
| 18:31 |
Soni |
you'll just need to add a mod manifest file |
| 18:31 |
hmmmm |
sounds fine then |
| 18:31 |
Soni |
that controls the Lua version to use |
| 18:31 |
T4im |
ah, nice.. |
| 18:31 |
hmmmm |
just as long as we don't end up with a python 3 situation |
| 18:31 |
hmmmm |
where nobody uses it because it's simply not compatible |
| 18:31 |
hmmmm |
if lua were updated and not reverse compatible, everybody would say "ugh I am using minetest 0.4.13" |
| 18:32 |
hmmmm |
"the new minetests are broken and none of the mods work with it" |
| 18:32 |
Soni |
I just posted on the LuaJIT mailing list about my overengineered idea |
| 18:32 |
T4im |
most don't make use of those things that changed, hmmmm |
| 18:32 |
Soni |
(altho it'll probably only do 32-bit integers in Lua 5.3) |
| 18:32 |
T4im |
there's rarely a setfenv or debug library use anywhere |
| 18:33 |
Soni |
you see, LuaJIT is already Lua 5.3-compatible |
| 18:33 |
Soni |
you just need to put a Lua 5.3 parser on top of it |
| 18:33 |
T4im |
ah |
| 18:33 |
Soni |
(and add a few missing Lua 5.3 libs, which's trivial) |
| 18:34 |
Soni |
(adding the missing C API stuff isn't trivial tho) |
| 18:36 |
eugd |
eh wow sorry for this terrible question, but where do i put the config file? i'm trying to test the x/y/z split thing |
| 18:36 |
eugd |
like minetest.conf.example, where do i put the actual minetest.conf? in the world folder? |
| 18:36 |
eugd |
and do i rename it [worldname].conf? |
| 18:37 |
T4im |
besides it, when run in place |
| 18:37 |
T4im |
or in the folder above it (which allows multiple versions to use the same one) |
| 18:37 |
eugd |
so configuration files are not world-specific? |
| 18:37 |
T4im |
there is a game specific one |
| 18:38 |
eugd |
? |
| 18:38 |
T4im |
worlds do have for example map_meta.txt though |
| 18:39 |
T4im |
but it won't be read the same way |
| 18:40 |
T4im |
game specific ones are for example minetest_game/minetest.conf |
| 18:40 |
T4im |
installation minetest.conf overrules their settings though iirc |
| 19:09 |
eugd |
so, i think i've got x/y/z split working fine |
| 19:10 |
eugd |
except for my question about map.cpp 2581-2588, which i've left alone for the time being |
| 19:11 |
eugd |
would it be acceptable (desirable?) to change it to work as a count of blocks/sectors, rather than nodes? |
| 19:11 |
eugd |
right now it's actually a strange thing where you put in some number and the actual map size ends up significantly less |
| 19:12 |
eugd |
because of sector-wise generation |
| 19:17 |
eugd |
also why does mapgen only work sector-wise? why no ability to generate partly-empty sectors? having this kind of world size limitation work mapblock-wise would be best, i think?? |
| 19:36 |
Soni |
http://www.freelists.org/post/luajit/Make-the-VM-Luaversionagnostic-and-modularize |
| 19:36 |
Soni |
just in case someone's curious |
| 19:45 |
|
MinetestForFun joined #minetest-dev |
| 19:49 |
|
FR^2 joined #minetest-dev |
| 19:55 |
Soni |
oh btw can we get a minetest batching API? |
| 20:04 |
|
paramat left #minetest-dev |
| 20:04 |
|
red1 joined #minetest-dev |
| 20:06 |
|
Ardonel joined #minetest-dev |
| 20:10 |
eugd |
map.cpp 2581-2588 |
| 20:10 |
eugd |
or ServerMapSector * ServerMap::createSector(v2s16 p2d) |
| 20:11 |
eugd |
line 2545 |
| 20:11 |
eugd |
this whole declaration uses x/y |
| 20:11 |
eugd |
to refer to x/z? |
| 20:11 |
eugd |
or am i missing something? |
| 20:11 |
eugd |
is this a case where notation changes? |
| 20:11 |
eugd |
or just an oversight? |
| 20:11 |
kahrl |
eugd: yeah, v2s16 has only x and y components |
| 20:12 |
eugd |
oh so it is for a reason |
| 20:12 |
kahrl |
so y is used to refer to what appears as z in game |
| 20:12 |
eugd |
ok |
| 20:12 |
eugd |
thanks |
| 20:16 |
eugd |
so how to do i make push? i think i have it pretty well sorted |
| 20:16 |
eugd |
simple thing really |
| 20:17 |
eugd |
changes in four files, map.cpp, mapblock.h, defaultsettings.cpp, minetest.conf.example |
| 20:17 |
eugd |
not sure if the way it's done is the most efficient |
| 20:17 |
kahrl |
do you have a github account already? |
| 20:17 |
eugd |
but i'm following the format that existed |
| 20:18 |
eugd |
nope |
| 20:18 |
kahrl |
well, make one |
| 20:18 |
kahrl |
then go to github.com/minetest/minetest and click on the fork button |
| 20:18 |
eugd |
oh yes i do |
| 20:18 |
eugd |
ok |
| 20:18 |
Soni |
how does this look? https://github.com/minetest/minetest/issues/3198 |
| 20:19 |
kahrl |
git clone from your github repository (or add your github repo as a remote if you already cloned minetest) |
| 20:19 |
kahrl |
git checkout -b <name_of_your_new_branch> |
| 20:20 |
Soni |
(it's supposed to be faster when doing procedurally generated stuff) |
| 20:20 |
kahrl |
make the changes, git add <list of files>, git commit |
| 20:20 |
kahrl |
then push to your repo |
| 20:21 |
kahrl |
if you then go to github.com/minetest/minetest again, it should give you the option to compare & create a pull request |
| 20:22 |
kahrl |
that was a bit terse so feel free to ask if any step is unclear |
| 20:23 |
red1 |
Is m_sectors a list of all loaded sectors or is it a list of all sectors that are generated? |
| 20:26 |
nanepiwo |
paramat: i made some screenshots of my lighting problems here: https://imgur.com/a/YxIQ4 |
| 20:28 |
red1 |
Is that the bug were part of the map has light set to zero after placing a using voxel manipulator? |
| 20:29 |
nanepiwo |
i dunno, but sounds about right |
| 20:29 |
nanepiwo |
whole regions of my map are completely darkened |
| 20:52 |
T4im |
you can set light and calculate it with voxelmanip though |
| 20:53 |
T4im |
vm:set_lighting({day=15, night=15}) and vm:calc_lighting() |
| 20:53 |
T4im |
though I did have that for some blocks with simple schematic placement as well |
| 20:53 |
red1 |
could a dev take a look at game#602 |
| 20:53 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/602 -- Allowed players with server priv to access any locked chest and open any steel door. by red-001 |
| 20:54 |
red1 |
thanks |
| 20:57 |
T4im |
they are both right, that that would work btw :P in both if-clauses |
| 20:58 |
T4im |
"if statement then return true else return false end" can always be written as "return statement" |
| 20:59 |
red1 |
should I add a new priv for opening doors and chests? |
| 21:04 |
|
ElectronLibre left #minetest-dev |
| 21:06 |
|
proller joined #minetest-dev |
| 21:07 |
|
est31 joined #minetest-dev |
| 21:10 |
eugd |
ok, i think i got my request in properly |
| 21:10 |
eugd |
i had to just use the website gui |
| 21:24 |
|
Siva_Machina joined #minetest-dev |
| 21:46 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-09-23_17-46-01.png |
| 21:47 |
VanessaE |
causes |
| 21:47 |
VanessaE |
2015-09-23 12:01:48: ERROR[Emerge-0]: Ignoring block load error. Duck and cover! (ignore_world_load_errors) |
| 21:47 |
VanessaE |
2015-09-23 12:01:48: ERROR[Emerge-0]: Invalid block data in database (123,-88,-1933) (SerializationError): unsupported Nam |
| 21:47 |
VanessaE |
eIdMapping version |
| 21:47 |
est31 |
congrats to a corrupted map! |
| 21:47 |
VanessaE |
so, someone gonna fix this or what? |
| 21:48 |
VanessaE |
better screenshot: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot_2015-09-23_17-48-23.png |
| 21:49 |
VanessaE |
that's maybe a quarter of what I was able to see initially, but they're falling too fast to capture better./ |
| 21:49 |
VanessaE |
and it's flooding my log with a shitton of those "invalid block" messages |
| 21:49 |
est31 |
what exactly is the problem |
| 21:49 |
VanessaE |
est31: those entities are outside the world bounds. |
| 21:50 |
VanessaE |
why isn't the engine deleting them instead of just corrupting mapblocks? |
| 21:50 |
T4im |
again? |
| 21:50 |
VanessaE |
T4im: yep. |
| 21:50 |
est31 |
!c -1933*16 |
| 21:50 |
ShadowBot |
est31: math calc <math expression> |
| 21:50 |
est31 |
!c -1933 * 16 |
| 21:50 |
ShadowBot |
est31: math calc <math expression> |
| 21:50 |
VanessaE |
-30928 |
| 21:50 |
T4im |
well luckily you have /deleteblocks now at least :D |
| 21:51 |
T4im |
yea, some player again digging to the bottom, placing elevator? |
| 21:51 |
VanessaE |
yeah, I nuked the region in which they were stored |
| 21:51 |
T4im |
or doing other nasty stuff |
| 21:52 |
VanessaE |
well nto the bottom - this is only about X=-1900 Y=-2400 |
| 21:52 |
VanessaE |
not* |
| 21:52 |
T4im |
oh.. seeing it now.. mobs |
| 21:52 |
* VanessaE |
runs /clearobjects on the server |
| 21:52 |
VanessaE |
and now, it's gonna be down for like 3 hours. |
| 21:53 |
VanessaE |
hell, one of those entities even managed to punch me while I was also floating out-of-bounds. |
| 21:53 |
T4im |
wouldn't it be faster than a clearobjects to just patch that mod to delete the entities if they find themselves under a certain thrshold? |
| 21:53 |
T4im |
:o |
| 21:55 |
VanessaE |
so.. |
| 21:56 |
VanessaE |
can we PLEASE stick to the original plan where the 0.4.13 -> 0.4.14 period was supposed to be all about bugfixes????? |
| 21:56 |
est31 |
original? |
| 21:56 |
VanessaE |
yeah. |
| 21:57 |
|
paramat joined #minetest-dev |
| 21:57 |
VanessaE |
0.4.13 was supposed to be a stability/feature release of a sort, and the time leading up to 0.4.14 was supposed to be primarily bugfixing because there wasn't enough time to go on such a spree for 0.4.13 |
| 21:57 |
est31 |
well we did it for 0.4.13 either way |
| 21:57 |
T4im |
hmm primary bugfixing? |
| 21:58 |
T4im |
_game badly needs a bugfixing-spree too :D |
| 22:00 |
paramat |
nanepiwo thanks, the problem is paragenv7 itself, will fix. for now if you're using paragenv7 v0.5.0 or later delete lines 85 to 87 |
| 22:01 |
paramat |
i set 'nolight' so on-generated needs to run for every mapchunk |
| 22:02 |
VanessaE |
I'm sorry to be so bitchy about this, but damn it, how can I run production servers with features people want (MOBs) if the engine is gonna trash my maps? |
| 22:02 |
T4im |
I think that's a reasonable thing to ask |
| 22:02 |
T4im |
:) |
| 22:02 |
VanessaE |
how much longer it this shit gonna go on before someone says "enough is enough"?! |
| 22:03 |
|
Lunatrius` joined #minetest-dev |
| 22:04 |
eugd |
can we add this one first https://github.com/minetest/minetest/pull/3199 ? |
| 22:07 |
est31 |
I don't think this is the way we should do it |
| 22:08 |
est31 |
the code itself looks good but is there any real use case for having different x and z sizes |
| 22:08 |
eugd |
well |
| 22:08 |
eugd |
minecraft 2 |
| 22:08 |
eugd |
and future stuff along those lines really |
| 22:09 |
eugd |
i am looking to add looping |
| 22:09 |
eugd |
on engine-level, because i've seen LUA implementations and they suck |
| 22:09 |
est31 |
if its optional and doesnt break anything, im ok with it |
| 22:10 |
eugd |
i don't really know if it doesn't break anything |
| 22:10 |
eugd |
i don't *think* it should? |
| 22:10 |
est31 |
depends on how you implement it |
| 22:10 |
eugd |
is that what the checks it took forever doing automatically check? |
| 22:11 |
celeron55 |
well one thing it breaks is that if somebody was using that setting already (and we should assume yes) |
| 22:11 |
est31 |
agreed |
| 22:11 |
celeron55 |
the original one should probably be left as the "master limit" or something |
| 22:11 |
est31 |
we released a stable version with that setting |
| 22:13 |
eugd |
so basically equivalent but supersceded by MAX_MAP_GENERATION_LIMIT of constants.h |
| 22:13 |
celeron55 |
this still seems kind of arbitrary though; why not have separate positive and negative edge limits? |
| 22:13 |
paramat |
i'm not too keen on different limits though, for artistic/design reasons, the cubic cosmology is a good MT characteristic |
| 22:13 |
eugd |
yeah it kind of is |
| 22:13 |
eugd |
also the entire way generation is currently done |
| 22:13 |
eugd |
is kind of weird |
| 22:14 |
eugd |
80x80x80 chunks but it doesn't sit evenly over 0 0 0 |
| 22:14 |
celeron55 |
also this limit sometimes has to be chosen by the game too and this setting isn't helping in that |
| 22:14 |
celeron55 |
and this setting isn't per-world either |
| 22:14 |
eugd |
agreed per-world would be better but how to do that? |
| 22:14 |
celeron55 |
the usefulness of this as it is or how you propose to change it is very limited |
| 22:14 |
eugd |
i tried to change the least from what existed |
| 22:15 |
eugd |
i intend to use it as part of next step looping worlds |
| 22:15 |
est31 |
celeron55, lots of settings should be per world |
| 22:15 |
VanessaE |
I must also point out: |
| 22:15 |
VanessaE |
19328 minetest 20 0 10.176g 8.714g 1.823g S 99.5 27.7 62:59.95 /usr/bin/minetestserver --worldname FreeForAll_World+ |
| 22:15 |
est31 |
many server owners just have different .conf files |
| 22:15 |
celeron55 |
est31: that is very true |
| 22:15 |
VanessaE |
(yes, 8.7 GB of RAM used for a server. the 99.5 is the CPU usage, as it's running /clearobjects right now) |
| 22:16 |
eugd |
i was honestly surprised to learn this .conf wasn't a world-based thing |
| 22:16 |
est31 |
if we do something like that, we should have e.g. a worldsettings.conf file or so |
| 22:16 |
est31 |
and then make it generic for all settings |
| 22:16 |
celeron55 |
eugd: it's global because it holds the client's graphics settings and key bindings and whatever |
| 22:17 |
eugd |
i think what est31 suggests would be best |
| 22:17 |
celeron55 |
probably they would need to be split or layered somehow |
| 22:17 |
eugd |
mapsettings |
| 22:17 |
eugd |
playersettings |
| 22:17 |
eugd |
environmentsettings |
| 22:18 |
celeron55 |
est31: that's the best solution assuming it doesn't create too many new problems |
| 22:18 |
celeron55 |
it might |
| 22:19 |
celeron55 |
the configuration UI is going to be interesting, given our bad UI capabilities |
| 22:19 |
eugd |
that, too. there's no UI at all for most of these |
| 22:20 |
eugd |
even just a simple text editor in-window would maybe help people? or one which locks the setting names and only lets you change variable |
| 22:21 |
celeron55 |
i have a feeling that it is going to be a ridiculous uncontrollable mess; but if someone manages to do it without ending up so, that would be good 8-) |
| 22:22 |
celeron55 |
in any case if the settings are layered to global and world settings, that can't be hidden from the user |
| 22:22 |
celeron55 |
otherwise the user will change a global setting and wonder why it doesn't work when a world setting the user doesn't know about overrides it, or something stupid like that |
| 22:23 |
eugd |
why layered and not split? what cause for overlap would there be? |
| 22:23 |
eugd |
sincere question |
| 22:24 |
celeron55 |
i think it should probably be split, but maybe the initial world-specific settings would be copied from global settings at world creation if needed... maybe |
| 22:24 |
eugd |
yeah set to default from .cpp just like current |
| 22:24 |
eugd |
oh you mean allow players to have their own custom-made 'default' |
| 22:25 |
eugd |
which all future worlds will look to |
| 22:25 |
eugd |
? |
| 22:25 |
celeron55 |
that's what i just described, yes |
| 22:25 |
celeron55 |
not sure how that should actually work; somebody has to design it and take care of the details |
| 22:26 |
eugd |
how do people running servers manage it now? |
| 22:26 |
celeron55 |
it would be kind of nice to get rid of the global creative mode and damage settings after half a decade 8D |
| 22:27 |
eugd |
creative mode and damage, almost an entirely different can of worms. game-based things if ever there were. |
| 22:27 |
VanessaE |
celeron55: well unified inventory takes care of the former. |
| 22:27 |
celeron55 |
well many games use them in a way or another, so they are relevant |
| 22:28 |
celeron55 |
...and i think there still is some hardcoded behavior in the engine for those |
| 22:28 |
eugd |
there is |
| 22:29 |
eugd |
it was discussed just today |
| 22:29 |
celeron55 |
i'm all in for making game specific main menus and whatnot, but i'm not optimistic about anyone deciding to pull that off |
| 22:29 |
eugd |
-1 health invulnerability |
| 22:32 |
|
asl97 joined #minetest-dev |
| 22:32 |
est31 |
a forum admin is needed at #minetest |
| 22:33 |
eugd |
? |
| 22:35 |
celeron55 |
hmm |
| 22:40 |
est31 |
also we have to find a solution for the secure.trusted_mods setting, if its settable from a file in the world folder, security is gone |
| 22:40 |
est31 |
(world folder can be edited by untrusted mods) |
| 22:41 |
eugd |
what is significance of being 'trusted' mod? |
| 22:41 |
est31 |
a trused mod has the privileges of the user who executes minetest |
| 22:41 |
|
red1 joined #minetest-dev |
| 22:41 |
est31 |
(if security is turned on) |
| 22:42 |
est31 |
an untrusted mod has only limited privileges, limited to the current minetest world |
| 22:42 |
est31 |
basically a sandbox |
| 22:43 |
est31 |
we need trusted mods because some functionality requires user level access |
| 22:43 |
est31 |
e.g. the irc mod |
| 22:44 |
eugd |
then yeah that should be a global setting? |
| 22:44 |
eugd |
why would you need that set world-wise anyway? |
| 22:44 |
est31 |
it should not be settable by untrusted mods |
| 22:45 |
eugd |
test |
| 22:54 |
|
red1 joined #minetest-dev |
| 23:03 |
|
paramat left #minetest-dev |
| 23:08 |
|
OldCoder joined #minetest-dev |
