| Time |
Nick |
Message |
| 00:04 |
|
Miner_48er joined #minetest-dev |
| 00:16 |
|
Lunatrius joined #minetest-dev |
| 00:16 |
|
DI3HARD139 joined #minetest-dev |
| 00:43 |
|
bigfoot547 joined #minetest-dev |
| 01:11 |
|
twoelk left #minetest-dev |
| 01:15 |
paramat |
#6168 |
| 01:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/6168 -- Network protocol: Document settable player collisionbox by paramat |
| 02:08 |
|
CalebDavis joined #minetest-dev |
| 02:39 |
|
bigfoot547 joined #minetest-dev |
| 02:41 |
|
CalebDavis joined #minetest-dev |
| 03:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/6165 -- Advanced lighting by kaadmy |
| 03:43 |
|
ssieb joined #minetest-dev |
| 05:12 |
|
Hunterz joined #minetest-dev |
| 05:26 |
|
nerzhul_ joined #minetest-dev |
| 05:32 |
nerzhul_ |
merged #6168 |
| 05:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/6168 -- Network protocol: Document settable player collisionbox by paramat |
| 05:37 |
|
Raven262 joined #minetest-dev |
| 06:07 |
|
YuGiOhJCJ joined #minetest-dev |
| 06:39 |
nerzhul_ |
pushing a trivial code move (move MapEditEventAreaIgnorer for server.h to emerge.cpp |
| 06:42 |
nerzhul_ |
strange i can push but not pull, not very easy to rebase :p |
| 06:43 |
nerzhul_ |
seems github bugs... |
| 06:43 |
nerzhul_ |
https://status.github.com/ has problems too |
| 08:22 |
|
DS-minetest joined #minetest-dev |
| 08:28 |
|
DI3HARD139 joined #minetest-dev |
| 08:41 |
|
Vadtec joined #minetest-dev |
| 08:42 |
|
exio4 joined #minetest-dev |
| 08:44 |
|
nerzhul joined #minetest-dev |
| 08:50 |
|
octacian_ joined #minetest-dev |
| 08:55 |
|
nerzhul joined #minetest-dev |
| 09:07 |
|
Darcidride joined #minetest-dev |
| 09:39 |
|
proller__ joined #minetest-dev |
| 09:46 |
|
DI3HARD139 joined #minetest-dev |
| 10:27 |
|
octacian__ joined #minetest-dev |
| 10:32 |
|
nerzhul joined #minetest-dev |
| 10:51 |
|
jin_xi joined #minetest-dev |
| 11:02 |
|
lisac joined #minetest-dev |
| 11:22 |
|
proller__ joined #minetest-dev |
| 11:39 |
|
ThomasMonroe joined #minetest-dev |
| 11:39 |
|
CalebDavis joined #minetest-dev |
| 11:51 |
|
shalmezad joined #minetest-dev |
| 11:53 |
|
Fixer joined #minetest-dev |
| 12:17 |
|
est31 joined #minetest-dev |
| 12:22 |
rubenwardy |
game#1849 |
| 12:22 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1849 -- Separate player code into new mod by rubenwardy |
| 12:22 |
rubenwardy |
needs more testing |
| 12:23 |
|
cx384 joined #minetest-dev |
| 12:24 |
|
proller__ joined #minetest-dev |
| 12:55 |
|
DS-minetest joined #minetest-dev |
| 13:21 |
|
twoelk joined #minetest-dev |
| 13:28 |
|
antims joined #minetest-dev |
| 13:48 |
|
thePalindrome joined #minetest-dev |
| 14:06 |
|
octacian joined #minetest-dev |
| 14:14 |
|
CalebDavis joined #minetest-dev |
| 14:17 |
|
est31 left #minetest-dev |
| 14:55 |
|
CalebDavis joined #minetest-dev |
| 15:21 |
|
proller__ joined #minetest-dev |
| 15:22 |
|
RobbieF joined #minetest-dev |
| 15:23 |
|
est31_ joined #minetest-dev |
| 15:48 |
|
Krock joined #minetest-dev |
| 15:51 |
|
proller__ joined #minetest-dev |
| 15:59 |
|
est31_ left #minetest-dev |
| 16:04 |
|
proller__ joined #minetest-dev |
| 16:34 |
|
soupfly joined #minetest-dev |
| 16:40 |
* KaadmY |
waits for more devs to come online |
| 16:42 |
|
nerzhul joined #minetest-dev |
| 16:44 |
nerzhul |
Krock, for casts, in guideliens we define a space after cast if i remember ? |
| 16:44 |
KaadmY |
nerzhul: is there a problem using NULL instead of nullptr for style consistenct? |
| 16:44 |
KaadmY |
nerzhul: the guidelines don't say |
| 16:44 |
nerzhul |
NULL vs nullptr should be used carefuly in code |
| 16:44 |
Krock |
there's neither a rule for casts nor nullptr |
| 16:45 |
KaadmY |
That entire file (game.cpp) uses NULL only, there's only one instance of nullptr |
| 16:45 |
KaadmY |
Krock: the guidelines say use nullptr |
| 16:45 |
nerzhul |
the main problem is if you init with nullptr and somewhere you have if (a != NULL) instead of i (!a) you will do a null crash |
| 16:45 |
Krock |
new code should be written with nullptr whenever possible |
| 16:45 |
nerzhul |
nullptr should be used everywhere yes, it's C++11 guidelines |
| 16:45 |
KaadmY |
Should I use nullptr and hope someone else replaces all the NULLs with nullptrs? |
| 16:45 |
nerzhul |
the only case where you should be careful in a C++11 program is C interfaces which compare to NULL |
| 16:46 |
nerzhul |
no never |
| 16:46 |
Krock |
change all affected pointers |
| 16:46 |
nerzhul |
yes |
| 16:46 |
nerzhul |
maybe add a point on next meeting and vote for a cast style |
| 16:47 |
nerzhul |
strange my mail didn't work |
| 16:47 |
nerzhul |
v3s16 && = moved variable |
| 16:47 |
nerzhul |
it permits to no create any reference and move the memory area passed to the function |
| 16:47 |
nerzhul |
it should be used very carefully as it removed variable from caller |
| 16:48 |
nerzhul |
in updateFastFaceRow case there is no problem as we pass hardcoded values |
| 16:49 |
nerzhul |
(it('s not a remove, it's a memory move) |
| 16:49 |
KaadmY |
^ are you talking to me or just in general? |
| 16:49 |
nerzhul |
for the move i answer Krock on #6169 |
| 16:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/6169 -- VoxelManip cleanups (const ref, const move) + function removal by nerzhul |
| 16:51 |
Krock |
nerzhul, how high is the benefit of using these expressions for 48 bits? |
| 16:51 |
Krock |
v3s16 isn't much of data copy, so optimizing within the functions might be better (?) |
| 16:52 |
nerzhul |
Krock, sorry but copy is the main problem in updateFastFaceRow :p |
| 16:52 |
nerzhul |
in a single call no problem |
| 16:53 |
nerzhul |
when it's 4 millions calls, callgrind shows we have ~5% time to copy this |
| 16:53 |
nerzhul |
updateFastFaceRow take ~40% of the client CPU usage |
| 16:54 |
Krock |
:< |
| 16:54 |
nerzhul |
i have a biggest optimization to do on it, i think i will work on it this evening, we have ~12% CPU used to do TileSpec copy |
| 16:55 |
Krock |
get your assembler skills ready :P |
| 16:55 |
nerzhul |
i should reduce memory copy massively on this function |
| 17:01 |
nerzhul |
i will do the other optimizations in a future PR as it needs a specific diff |
| 17:02 |
Hijiri |
#5612 |
| 17:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/5612 -- Allow overriding tool capabilities through itemstack metadata by raymoo |
| 17:03 |
|
iZacZip joined #minetest-dev |
| 17:04 |
nerzhul |
in 6169 the main optimization is the getExtent caching it has a nice impact on index function we called many times, and getVolume. Both are massively called in MapGen and updateFastFaceRow :) |
| 17:05 |
KaadmY |
Does anybody know where the mapblock mesh vertex alpha is set? |
| 17:05 |
KaadmY |
It's supposed to be the day/night ratio which doesn't make much sense |
| 17:05 |
KaadmY |
Since it's the same data per-vertex |
| 17:05 |
KaadmY |
I want to put that into a uniform and make the per-vertex data store how much artificial light there is |
| 17:08 |
nerzhul |
Krock, my dream is to load map as fast in debug mode as in release mode now :p |
| 17:09 |
nerzhul |
i don't think if it's possible, but i saw some map generation & loading improvements in release mode after this PR, mapgen valleys was generating a little bit faster than before |
| 17:09 |
Krock |
maybe the map will be faster but everything else is heck slow without many optimizations from the compiler |
| 17:09 |
nerzhul |
yes server side emerging is not the high bottleneck except on new maps |
| 17:09 |
nerzhul |
it's a side effect of my getExtend change :p |
| 17:10 |
nerzhul |
the optimization was for updateFastFaceRow, i want to reduce its client usage, 40% is crazy |
| 17:10 |
|
cx384 joined #minetest-dev |
| 17:11 |
nerzhul |
on client, in regular mode, running 5 mins (with 1 or 0 fps under valgrind/callgrind) 40% usage is updateFastFaceRow and 15% generation of the mapblockmesh |
| 17:12 |
nerzhul |
Krock, => https://lut.im/5x30Fsws1b/6juQxoXeH8GJ5Nik.png |
| 17:12 |
nerzhul |
it's the client |
| 17:12 |
nerzhul |
i used remote server in release mode to drop the CPU usage of the server from graphs |
| 17:13 |
Krock |
heh, 200k calls on updateFastFaceRow. I see |
| 17:14 |
|
shalmezad joined #minetest-dev |
| 17:14 |
nerzhul |
with callgrind yes |
| 17:15 |
nerzhul |
part i want to optimize after this merge |
| 17:15 |
nerzhul |
https://lut.im/RGkiJqQb8T/LeQIEXpAuRzfl7gd.png |
| 17:15 |
nerzhul |
it's copy :) |
| 17:15 |
|
soupfly joined #minetest-dev |
| 17:17 |
nerzhul |
Krock, i fixed 6169 it's ready for a merge |
| 17:19 |
Krock |
LGTM |
| 17:24 |
Krock |
nerzhul, spotted a function you restyled a bit: https://github.com/minetest/minetest/pull/6169/files#diff-c2f90db5de8c33a259c27113939c63c5R1529 |
| 17:24 |
Krock |
nothing special about this part but there's an "else" case |
| 17:25 |
Krock |
same functionality, but using "verticies" instead of "tangent_vertices" |
| 17:26 |
|
lisac joined #minetest-dev |
| 17:26 |
|
Raven262 joined #minetest-dev |
| 17:27 |
Krock |
sounds a bit wrong to only re-style one part of it |
| 17:31 |
nerzhul |
yeah it's more complicated the second part |
| 17:31 |
nerzhul |
it's not only 1 loop |
| 17:31 |
nerzhul |
go clion, do it instead of myself |
| 17:32 |
nerzhul |
you are exact it's same loop |
| 17:33 |
Krock |
:P |
| 17:33 |
nerzhul |
done |
| 17:33 |
Krock |
s/exact/right/ |
| 17:34 |
nerzhul |
:p |
| 17:37 |
nerzhul |
Krock, is this okay for you now ? |
| 17:38 |
Krock |
already approved but the other devs should have the possibility to look at it |
| 17:38 |
nerzhul |
yeah i'm waiting tomorrow morning |
| 17:40 |
Krock |
good, thanks :) |
| 17:40 |
|
ssieb joined #minetest-dev |
| 17:49 |
|
behalebabo joined #minetest-dev |
| 18:06 |
KaadmY |
Why is sun and night light (?) stored in each node? |
| 18:06 |
KaadmY |
Instead of being a global value for the entire world? |
| 18:07 |
sofar |
nerzhul: since we're going incompat to 0.5, why not see if we can make the worlds larger in XZ coordinates? |
| 18:07 |
KaadmY |
sofar: why though? |
| 18:07 |
nerzhul |
sofar, do it yourself haha, i will not doing that |
| 18:07 |
sofar |
KaadmY: the game uses that to calculate dawn/dusk values which are in between |
| 18:07 |
KaadmY |
It'd require a pretty large rework of the map format as well as the entire mapgen |
| 18:07 |
nerzhul |
it's the biggest change |
| 18:07 |
KaadmY |
sofar: it's global though |
| 18:07 |
KaadmY |
Not per-node |
| 18:08 |
KaadmY |
Lemme check more |
| 18:08 |
Krock |
we're breaking the proto compat - yet. not sure if changing the map format is a good idea |
| 18:08 |
sofar |
not every node gets direct sunlight |
| 18:08 |
sofar |
surface is just much more valuable than depth imho |
| 18:08 |
nerzhul |
mapblock serialization is not compatible with new corridnates as it uses s16 :) |
| 18:09 |
KaadmY |
Also seriously, why increase X/Z? |
| 18:09 |
KaadmY |
It's already massive |
| 18:09 |
sofar |
surface is just much more valuable than depth imho |
| 18:09 |
sofar |
any player will confirm |
| 18:10 |
sofar |
you could decrease the depth and not many players would complain |
| 18:10 |
sofar |
not until you get to about 1024 or so |
| 18:10 |
Krock |
I agree with KaadmY. I barely play outside of 2000m X/Z as the coordinates get hard to handle |
| 18:10 |
sofar |
you barely play outside 100Y |
| 18:10 |
sofar |
so surface is 20x more valuable |
| 18:10 |
Krock |
for realms |
| 18:11 |
sofar |
for reals |
| 18:11 |
sofar |
if a protocol break is on the table, I would think this would be open for discussion |
| 18:11 |
nerzhul |
protocol break != mapblock break |
| 18:11 |
nerzhul |
but i really want to see comprssion algorithm change |
| 18:12 |
nerzhul |
using zstd or lz45 |
| 18:12 |
sofar |
potato, potato |
| 18:12 |
nerzhul |
lz4 |
| 18:12 |
nerzhul |
i use lz4 on my server since 2 years it's smooth and CPU thanks me :p |
| 18:12 |
Krock |
potato compression algorithm? |
| 18:13 |
nerzhul |
i prefetch ketchup hamburger :p |
| 18:14 |
Krock |
SELECT taste FROM ketchup WHERE usecase LIKE `%hamburger%` |
| 18:14 |
sofar |
derailing the discussion will only make it come back |
| 18:15 |
Krock |
if we break the compatibility, then we should do it for real - which requires some pulls that improve the game largely |
| 18:15 |
sofar |
that's not how reality works |
| 18:16 |
sofar |
we don't magically have a bunch of hail mary patches lying around |
| 18:16 |
Krock |
I know, that's why I'm not sure if we should consider map break already now |
| 18:16 |
sofar |
celeron55 maybe :) |
| 18:16 |
Krock |
s/maybe/definitely/ |
| 18:17 |
nerzhul |
sofar, i don't have time for a such change i prefer to solve the performance bottleneck client side & add server side features like mobs |
| 18:18 |
nerzhul |
i don't know if you look at the whole code but using v3f instead of v3s16 is not a simple change :p |
| 18:18 |
* KaadmY |
would prefer real CSM |
| 18:18 |
sofar |
optimize ABMs -> #1 performance issue |
| 18:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/1 -- GlowStone code by anonymousAwesome |
| 18:18 |
nerzhul |
sofar, i don't think we can fix ABM more, the current ABM implementation is fast, the Lua modding usage is wrong, that's all |
| 18:18 |
KaadmY |
LOL that issue has like 100 references |
| 18:19 |
sofar |
a single ABM is causing my server over 95% of it's CPU usage |
| 18:19 |
nerzhul |
i have some ideas of Lua calls which can permit to solve some lua bottlenecks, for example TNT explosion should be in core to manage node explosion spreading over loop time easily |
| 18:19 |
nerzhul |
it's easy if it's just a bad ABM |
| 18:19 |
nerzhul |
which ABM is this ? |
| 18:19 |
sofar |
lava cooling |
| 18:19 |
Krock |
well, it would be nice to speed up the ABMs but the way it works, there have to be this many loops and node lookups |
| 18:19 |
nerzhul |
the dirt/grass ABM is consuming too |
| 18:19 |
sofar |
the only abm on my server actually |
| 18:19 |
nerzhul |
you don't have dirt/grass ABM ? |
| 18:19 |
sofar |
nope |
| 18:19 |
nerzhul |
lava cooling is too heave |
| 18:20 |
sofar |
needed for gameplay |
| 18:20 |
nerzhul |
find the generic algorithms make them core side lua calls |
| 18:20 |
sofar |
no other way of doing it still |
| 18:20 |
nerzhul |
i hope you can provide some nice PR i don't see PR from you in core since a long time and it seems you have some needs, then code ! |
| 18:20 |
Krock |
caching of the affected nodes would be an option |
| 18:20 |
sofar |
building up some energy atm |
| 18:20 |
sofar |
house build is starting tomorrow |
| 18:21 |
nerzhul |
Krock, it's not as simple as that |
| 18:21 |
sofar |
still spending a lot of time on building stuff atm |
| 18:21 |
nerzhul |
caching can be performance painful is caching map increase |
| 18:21 |
nerzhul |
i think we should have specific unittests to permit performance analysis |
| 18:22 |
nerzhul |
i don't know how but when i will need it i will add some unittests to call code parts isolated to run valgrind/callgrind on them |
| 18:24 |
|
behalebabo joined #minetest-dev |
| 18:24 |
sofar |
I'm thinking ABM's can be optimized one step further |
| 18:24 |
nerzhul |
how ? |
| 18:24 |
nerzhul |
the ABM processing is not the biggest usage in core it's the Lua part on ABM run |
| 18:24 |
sofar |
if the nodes for the ABM are not present in a mapblock, and the mapblock hasn't changed since last run, there is no need to check again |
| 18:25 |
|
proller__ joined #minetest-dev |
| 18:25 |
sofar |
it's not the lua that is the problem |
| 18:25 |
sofar |
the ABM core loop is what is consuming 95% of my server's CPU |
| 18:25 |
sofar |
even though there is NO lava anywhere |
| 18:25 |
sofar |
it's just the abm loop going over all the mapblocks trying to find lava nodes |
| 18:25 |
nerzhul |
maybe we should index which nodes content_t are present in the mapblock |
| 18:26 |
nerzhul |
if node is not present it can prevent looping over it |
| 18:26 |
KaadmY |
There should be "related" ABMs or something |
| 18:26 |
sofar |
afk |
| 18:26 |
KaadmY |
That are called when nodes are placed |
| 18:26 |
KaadmY |
Or dug, like leaves |
| 18:31 |
|
CalebDavis joined #minetest-dev |
| 18:36 |
|
paramat joined #minetest-dev |
| 18:38 |
paramat |
increase XZ dimensions .. absolutely not, not yet anyway with our severe dev shortage, we're not going to break map format |
| 18:39 |
paramat |
players love the depth of MT and the height that allows stacked realms, it's just as valuable as width and actually makes more interesting things possible, width is usually just more of the same |
| 18:42 |
paramat |
oh, freeminer has an ABM optimisation that may be worth looking at (if it's any good) |
| 18:45 |
paramat |
the lavacooling ABM runs very frequently, maybe we can reduce the interval more |
| 18:45 |
paramat |
eek it's still at interval 1s, i'll change that to 2 |
| 18:45 |
octacian |
paramat: You know, here's another reason why "real" realms could be better. The game could be configured so that clients would only have to load mods and other data for the particular realm. Otherwise, it could get really heavy if there's a large amount of differences between realms. |
| 18:47 |
paramat |
sounds like sending a player to a different server, it's been discussed a lot and there seems to be issues. stacked levels are not meant to be a replacement for 'dimensions' and are just as 'real' |
| 18:48 |
paramat |
i'm saying have both if possible, it isn't a choice |
| 18:51 |
octacian |
paramat: That clears things up a bit. I'd love the possibility of having both stacked realms and "real" dimensions then |
| 18:54 |
sofar |
stacked realms are proof that more surface is needed |
| 18:54 |
rubenwardy |
^ |
| 18:54 |
rubenwardy |
stack realms seem to be a work around |
| 18:55 |
rubenwardy |
that cause lighting issues |
| 18:55 |
rubenwardy |
skylands? Far enough |
| 18:55 |
rubenwardy |
nether/hell? Fair enough |
| 18:55 |
sofar |
I'm not discounting the complexity of the change, I'm saying that it's *needed* and it will always remain a heated debate problem |
| 18:55 |
rubenwardy |
because it's okay for the player to come accross those |
| 18:56 |
sofar |
nether is essentially a biome imho |
| 18:56 |
rubenwardy |
agreed |
| 18:56 |
rubenwardy |
but it's not that important to me |
| 18:56 |
rubenwardy |
so I'll butt out now :P |
| 18:59 |
nerzhul |
we have ABM optimization like freeminer since 0.4.16 if i remember |
| 18:59 |
nerzhul |
multiple maps in a single server can be nice |
| 19:00 |
nerzhul |
oh nice |
| 19:01 |
nerzhul |
i reduced TileSpec operator load 4 times by using a shared_ptr, nice |
| 19:02 |
nerzhul |
the lifetime of the object is correctly controlled |
| 19:02 |
nerzhul |
Krock, https://lut.im/bcqmwee1xu/cTwtptY5tRuS9lp0.png becomes https://lut.im/bcqmwee1xu/cTwtptY5tRuS9lp0.png |
| 19:02 |
nerzhul |
10 times, not 4 times |
| 19:03 |
Krock |
nerzhul, 2nd unique link please |
| 19:03 |
nerzhul |
Krock, i don't understand |
| 19:03 |
Krock |
you proved that 14881832 == 14881832. it's the same image URL |
| 19:03 |
nerzhul |
oops |
| 19:04 |
nerzhul |
before: https://lut.im/RGkiJqQb8T/LeQIEXpAuRzfl7gd.png |
| 19:04 |
nerzhul |
the Ir is the relevant metric here |
| 19:04 |
nerzhul |
it's the consumed time |
| 19:04 |
Krock |
wow amazing. |
| 19:05 |
nerzhul |
the change is simple |
| 19:05 |
Krock |
and I thought the compiler would know the important tricks |
| 19:05 |
nerzhul |
std::vector<FrameSpec> frames; => std::shared_ptr<std::vector<FrameSpec>> frames = nullptr; |
| 19:05 |
nerzhul |
compiler does memcpy the non trivial object in all cases in release mode too |
| 19:05 |
nerzhul |
here compiler copy the shared_ptr |
| 19:05 |
nerzhul |
int + sizeof(ptr) copy |
| 19:06 |
Krock |
lovely |
| 19:06 |
nerzhul |
instead of 4 to 16 * sizeof(FrameSpec) copy (Framespec = 3 * sizeof(ptr) + int) |
| 19:06 |
nerzhul |
i publish the patch in a secodn pr later (depending on previous pr) |
| 19:09 |
paramat |
stacked realms are a more interesting way to get more surface, and it can be different types of surface: netherworlds, floatlands, alien planets, moons, dimensions, none of those make sense displaced horizontally |
| 19:09 |
Krock |
would like to see that :) gtg now |
| 19:09 |
paramat |
larger world is not really needed, just a few have a non-essential desire mostly due to being used to MC |
| 19:11 |
paramat |
no-one has run out of surface area or even got close to that, even with one level |
| 19:19 |
|
shalmezad_ joined #minetest-dev |
| 19:19 |
VanessaE |
paramat: the problem with your idea is light propagation, and keeping users from being able to move from one realm to another without e.g. a teleporter or something |
| 19:20 |
VanessaE |
(except maybe from base terrain to floatlands or something) |
| 19:28 |
paramat |
those can be solved |
| 19:28 |
VanessaE |
I'm sure. |
| 19:28 |
paramat |
i have ideas for vertical travel |
| 19:28 |
VanessaE |
there's a better idea though, |
| 19:28 |
VanessaE |
multiple worlds, multiple instances |
| 19:29 |
VanessaE |
with a teleporter or other maguffin to move between them while in-game |
| 19:29 |
paramat |
in which the vertical travel itself is an adventure and a challenge, much more interesting than teleporting |
| 19:30 |
VanessaE |
well that's fair, if you're moving between say base terrain and float lands. |
| 19:30 |
VanessaE |
but for example nether, you're not supposed to be able to get there without a teleporter portal |
| 19:31 |
paramat |
well for a MC nehter, but if MC had the vertical height, nether would have been a hell realm physically below |
| 19:31 |
paramat |
*nether |
| 19:31 |
VanessaE |
but what I meant by multiple-worlds-multiple-instances is, think of the 5 servers I run right now. Suppose there were a mod I could install in all of them that would let a player "teleport" to another world, without them having to exit to the menu, select the other world, and manually connect with username/pw |
| 19:31 |
paramat |
travelling to it would be more interesting too |
| 19:32 |
paramat |
yeah, it's being discussed |
| 19:32 |
VanessaE |
I think in MC you'd use a linking book for that, but in MT I think something more akin to Sokomine's travelnets are more appropriate. |
| 19:34 |
VanessaE |
I think this is a much better idea than multiple stacked "realms" because not only does it avoid the problem of losing vertical space, but also it allows you to spread the CPU load without clustering or anything special. |
| 19:36 |
paramat |
we don't have to choose between the 2, and the dimensions idea has been discussed a lot and has issues (and importantly, doesn't exist yet) |
| 19:38 |
VanessaE |
dimensions? |
| 19:39 |
VanessaE |
you mean as in map size? |
| 19:39 |
VanessaE |
screw that. leave the map the way it is now. |
| 19:39 |
VanessaE |
there's no reason to increase the map size if you do multiple-worlds-multiple-instances. for that, all you'd need is a way to send a player to another server without an exit to the menu. |
| 19:40 |
rubenwardy |
dimensions -> multiple maps on a server |
| 19:40 |
VanessaE |
rubenwardy: no |
| 19:40 |
VanessaE |
not on A server |
| 19:40 |
VanessaE |
on MANY servers. |
| 19:40 |
rubenwardy |
errr no |
| 19:40 |
VanessaE |
one minetest instance, one realm/world/dimension/whatever |
| 19:40 |
VanessaE |
that's what i'm proposing |
| 19:40 |
rubenwardy |
dimensions is another co-ordinate for the map |
| 19:40 |
VanessaE |
I'm* |
| 19:40 |
rubenwardy |
it's been discussed at length |
| 19:40 |
VanessaE |
yeah I know, and honestly it's a stupid idea |
| 19:40 |
VanessaE |
I'm sorry, it is. |
| 19:41 |
rubenwardy |
not a feature I care about, tbh |
| 19:41 |
VanessaE |
by doing it that way you make it impossible to adapt an existing map to be able to have other "realms" |
| 19:41 |
VanessaE |
a "realm" should just be another random minetest server instance with a suitable world, but of course not announcing to the master server list |
| 19:42 |
VanessaE |
the client just needs something user-readable that makes it evident where they'll be connecting to if they sign off one day, and come back in some other time. |
| 19:42 |
|
Fixer_ joined #minetest-dev |
| 19:43 |
sofar |
server redirection |
| 19:43 |
sofar |
MC does this and it works really well |
| 19:43 |
VanessaE |
sofar: in essence, yeah, but done in such a way that it looks to the user like they're being transported magically :) |
| 19:44 |
sofar |
you'd still have a loading screen |
| 19:44 |
sofar |
which is fine, I guess |
| 19:44 |
VanessaE |
yeah but don't make it look like a server sign-on screen |
| 19:44 |
sofar |
the functionality is the thing that's needed |
| 19:44 |
VanessaE |
make it look more... I dunno...less clinical |
| 19:48 |
|
octacian_ joined #minetest-dev |
| 19:49 |
|
Qbiq joined #minetest-dev |
| 19:58 |
Hijiri |
having the maps on separate servers will make sharing mod data between them much more of a pain though |
| 19:59 |
Hijiri |
at least, if it's meant to fulfill the "dimensions" feature |
| 19:59 |
Hijiri |
each map would also cost a lot more than if they were on the same server |
| 20:00 |
Hijiri |
so it would be harder to have a mod that adds new dimensions or whatever you want to call them during gameplay |
| 20:00 |
VanessaE |
http access? |
| 20:00 |
Hijiri |
what about http access? |
| 20:00 |
VanessaE |
use curl/http to share said data? |
| 20:01 |
Hijiri |
I mean when the servers need to share data that they can also all modify |
| 20:01 |
Hijiri |
a simple example would be player achievements, they could get an achievement on any world |
| 20:01 |
Hijiri |
or a more problematic example could be a faction system |
| 20:01 |
VanessaE |
that plus player inventories is a question, yeah |
| 20:02 |
Hijiri |
a team leader could kick a player on one server while the player is doing stuff using the faction on another |
| 20:02 |
VanessaE |
but if you can send a player to another server, surely there should be a way to send this "shared" data along with the new connection |
| 20:03 |
Hijiri |
there will be cases where all servers need to be able to modify a player's data, not just the one with the player online right now |
| 20:03 |
Hijiri |
and there might be data not associated to a specific player at all |
| 20:03 |
VanessaE |
but all of that is somewhat less relevant at the moment |
| 20:03 |
Hijiri |
I thought this was all hypothetical |
| 20:03 |
VanessaE |
the first goal should be getting the player transported to the other server. |
| 20:04 |
VanessaE |
worry about their inventory or achievements or whatever later. |
| 20:04 |
Hijiri |
assuming we take this approach for dimensions |
| 20:04 |
Hijiri |
they could even be separate features, one for multiple maps per server and one for linking servers |
| 20:04 |
VanessaE |
well if "dimensions" were implemented the way rubenwardy suggests, then it would be a fourth dimension to the map. |
| 20:04 |
Hijiri |
where mods that want to use the worlds more tightly coupled could operate on the former thing |
| 20:05 |
VanessaE |
i.e. multiple worlds on a single server instance |
| 20:05 |
Hijiri |
VanessaE: that's what I mean by multiple maps per server |
| 20:05 |
VanessaE |
meaning such things wouldn't be an issue at all. |
| 20:05 |
VanessaE |
but doing that doesn't allow you to spread the load |
| 20:06 |
Hijiri |
well, one server per map also adds a lot of overhead if you want a mod to be able to add new worlds |
| 20:07 |
Hijiri |
I guess you could shut down a server with no players and only restart it when a player tries to go to it |
| 20:07 |
|
paramat joined #minetest-dev |
| 20:07 |
Hijiri |
then the worst case would be one server thread or process per online player |
| 20:07 |
VanessaE |
can't do that. |
| 20:08 |
VanessaE |
then the server won't be able to do things like keep technic machines running, or furnaces cooking, or other active things |
| 20:08 |
VanessaE |
(think world anchors) |
| 20:08 |
Hijiri |
right |
| 20:08 |
Hijiri |
but maybe that would be an acceptable compromise to not need to have 1000 server processes running? |
| 20:08 |
Hijiri |
(if 1000 worlds are made) |
| 20:09 |
VanessaE |
why would it matter how many server instances are running? |
| 20:09 |
Hijiri |
Or you could mark worlds as not being always online |
| 20:09 |
Hijiri |
I guess it doesn't matter that much |
| 20:10 |
Hijiri |
I don't know what the memory overhead of a server instance with no players on it is so I can't say anything specific about memory use or anything |
| 20:11 |
paramat |
VanessaE by 'dimensions' i don't mean a 4th co-ordinate (which is silly), just either moving players between servers or having multiple 'worlds' in one world database, these seem to be the 2 ideas currently discussed |
| 20:11 |
VanessaE |
it's pretyt low on light-weight servers. |
| 20:11 |
VanessaE |
paramat: ok so basically more or less what I said. |
| 20:11 |
VanessaE |
one world/dimension per server instance is the best. :) |
| 20:12 |
Hijiri |
I don't like that modders will have to deal with concurrency problems |
| 20:12 |
paramat |
yeah what you suggest :] |
| 20:12 |
Hijiri |
if Minetest exposes a good transactional memory API then that might be enough |
| 20:13 |
Hijiri |
but otherwise it won't really be a substitute for multiple maps on the same server |
| 20:14 |
Hijiri |
And I have a feeling that such an API is something that will take either a long time or forever to get implemented |
| 20:14 |
Hijiri |
I guess it could just be a thin wrapper over sql |
| 20:15 |
Hijiri |
and redis supports transactions too |
| 20:16 |
Hijiri |
you would also need a messaging API between servers |
| 20:16 |
Hijiri |
but if you're sending players across then maybe that is something that would come naturally? |
| 20:19 |
|
YuGiOhJCJ joined #minetest-dev |
| 20:22 |
sofar |
keeping players in different dimensions on the same server seems like a bad idea for performance |
| 20:23 |
sofar |
I think you'd want to make them connect to a different IP address even based on GEO |
| 20:23 |
Hijiri |
what if the players want to meet each other |
| 20:23 |
sofar |
just an option, of course |
| 20:23 |
|
thePalindrome joined #minetest-dev |
| 20:24 |
paramat |
can anyone consider #6167 ? quite simple mapgen stuff |
| 20:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/6167 -- Mgv7: Add 'mount_zero_level' parameter by paramat |
| 20:24 |
sofar |
but spreading the load to different physical servers makes sense |
| 20:24 |
Hijiri |
I don't think players in different dimensions on the same server is significantly worse than if they are 500 nodes away from each other on one dimension, but I guess it's worse than if you had the dimensinos on separate servers |
| 20:24 |
Hijiri |
but implementing multiple dimensions within a server I don't think on its own will make a server support less players than before |
| 20:25 |
Hijiri |
I mean, on average |
| 20:26 |
Hijiri |
it's possible that dimensions would encourage players to all be in their own dimension, which would increase active block count |
| 20:26 |
Hijiri |
it's possible now for players to go far away from each other, but you have to go through the pain of walking |
| 20:26 |
Hijiri |
players to each be in their own dimension* |
| 20:32 |
|
sebastian321 joined #minetest-dev |
| 20:52 |
paramat |
ok #6167 is fairly trivial and internal to mgv7 so i'll merge later on my own approval, let me know if any objections :] |
| 20:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/6167 -- Mgv7: Add 'mount_zero_level' parameter by paramat |
| 21:03 |
|
Qbiq joined #minetest-dev |
| 21:08 |
|
RobbieF left #minetest-dev |
| 21:10 |
|
twoelk left #minetest-dev |
| 21:25 |
|
proller joined #minetest-dev |
| 21:35 |
|
octacian__ joined #minetest-dev |
| 21:37 |
nerzhul |
wow #6171 has a nice side performance side effect. I passed from 1 FPS to 4 FPS when calgrind run |
| 21:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/6171 -- TileLayer: use shared_ptr for FrameSpec vector by nerzhul |
| 21:41 |
paramat |
nice |
| 21:43 |
nerzhul |
it's not playable but seeing it under callgrind shows an interesting benefit |
| 22:03 |
|
Corvus_ joined #minetest-dev |
| 22:16 |
|
bigfoot547 joined #minetest-dev |
| 22:34 |
|
jin_xi joined #minetest-dev |
| 22:41 |
KaadmY |
Is video::SColor (irr::video::SColor) clamped from 0 to 1 anywhere? |
| 22:41 |
KaadmY |
Or can I safely overflow it |
| 22:41 |
KaadmY |
(0 to 255 technically) |
| 22:41 |
KaadmY |
Nope |
| 22:41 |
KaadmY |
It's one byte each |
| 22:45 |
paramat |
not sure |
| 22:46 |
KaadmY |
I wonder how much performance loss I'll get if I use SColorf for passing around vertex colors in the final light/sunlight pass |
| 22:46 |
KaadmY |
Instead of SColor |
| 22:47 |
KaadmY |
paramat: is having a mapgen max height plateau possible right now without a custom Lua mapgen? |
| 22:50 |
KaadmY |
Huh seems like all of the Irrlicht color types clamp from 0 to 1 range :( |
| 22:53 |
sfan5 |
pretty sure SColor just stores those as u8 which makes any kind of invalid values impossible |
| 22:54 |
KaadmY |
Yeah |
| 22:54 |
KaadmY |
There's also video::SColorf, which according to Irrlicht, still only allows values from 0.0 to 1.0 |
| 22:55 |
KaadmY |
All I need is the ability to bleed alpha to an arbitrary value :( |
| 22:55 |
KaadmY |
Hm |
| 23:00 |
KaadmY |
Egh getting waaaaaaaay too much inaccuracy from mapping 1k+ to 0.0-1.0 |
| 23:00 |
sfan5 |
wat |
| 23:01 |
sfan5 |
if you have value range around 1k why not just use u16? |
| 23:01 |
KaadmY |
sfan5: can't |
| 23:01 |
KaadmY |
SColor |
| 23:01 |
KaadmY |
Which clamps 0-1 |
| 23:01 |
KaadmY |
I'm assuming anything along the line might also clamp 0-1 |
| 23:01 |
sfan5 |
in any case float should have enough bits for your usage |
| 23:01 |
KaadmY |
Since OpenGL might also do it IIRC |
| 23:02 |
sfan5 |
how are you mapping values? |
| 23:02 |
KaadmY |
sfan5: I need to fit two floats in a 0.0 to 1.0 range |
| 23:03 |
KaadmY |
Both floats are 0.0 to 1.0 though |
| 23:03 |
KaadmY |
And I can't do binary stuff |
| 23:03 |
sfan5 |
and how are you doing that |
| 23:04 |
KaadmY |
https://gist.github.com/kaadmy/0ed16c4f12de1f3c19e811580ac60ac5 |
| 23:04 |
KaadmY |
Shitty method since accuracy is horrible |
| 23:04 |
KaadmY |
But unless someone can think if a cleaner way I'm using it |
| 23:08 |
KaadmY |
If both values have 2 digits of accuracy and the first is 0.0-0.5 it'll work |
| 23:09 |
KaadmY |
Accuracy is really bad, wonder if it'll work |
| 23:09 |
KaadmY |
Yeah a lot of accuracy is lost casting to a byte :| |
| 23:09 |
KaadmY |
(Not surprising) |
| 23:13 |
KaadmY |
LOL |
| 23:13 |
KaadmY |
Apparently one of Irrlicht's features is that is has 5 video drivers to chose from |
| 23:13 |
KaadmY |
D3D, OpenGL, Irrlicht's SW render, Burningsvideo SW render, and a null render |
| 23:13 |
KaadmY |
So now if nothing is rendered, that's a "renderer" |
| 23:17 |
KaadmY |
Are the actual color channels for vertices used for tinting nodes? |
| 23:17 |
KaadmY |
Or is that texture-side |
| 23:17 |
KaadmY |
I can reuse a color channel for artificial brightness |
| 23:20 |
paramat |
a plateau hmm .. |
| 23:21 |
KaadmY |
Yay node colors don't change the vertex color |
| 23:21 |
KaadmY |
Hm no |
| 23:21 |
KaadmY |
Yeah they do :( |
| 23:22 |
paramat |
"Are the actual color channels for vertices used for tinting nodes?" the person to ask is 'juhdanad' who did a lot of work on colouring when he coded hardware colouring |
| 23:22 |
KaadmY |
Yeah |
| 23:22 |
KaadmY |
So I have RGBA, RGB is used |
| 23:22 |
KaadmY |
So it's down to the alpha channel to store two numbers :| |
| 23:22 |
KaadmY |
Can't use binary encoding |
| 23:23 |
KaadmY |
Since it's cast when passing through Irrlicht, so I don't have a binary representation between the CPU side code and the shader |
| 23:23 |
paramat |
see #4986 it might have some answers |
| 23:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/4986 -- Hardware node coloring by juhdanad |
| 23:24 |
|
proller__ joined #minetest-dev |
| 23:26 |
paramat |
mggv7 can be tuned with noise params to have completely flat plateaus at any height but there would be occasional mountains sticking up from it, but you can disable mountains |
| 23:27 |
paramat |
that PR is where there were some changes to shader colour stuff (i don't understand it) |
| 23:29 |
KaadmY |
Yeah |
| 23:29 |
KaadmY |
Not related though |
| 23:48 |
|
deep-book-gk_ joined #minetest-dev |
| 23:49 |
|
deep-book-gk_ left #minetest-dev |
| 23:50 |
paramat |
https://github.com/minetest/minetest_game/issues/1852 oops |
| 23:52 |
KaadmY |
> But I will probably change this to another function which can approximate the current lighting better. |
| 23:52 |
KaadmY |
The problem, as you can see, is that the shader does not know the day and night light intensity, but their ratio (q). |
| 23:52 |
KaadmY |
From #4986 |
| 23:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/4986 -- Hardware node coloring by juhdanad |
| 23:54 |
|
Warr1024 joined #minetest-dev |
