| Time |
Nick |
Message |
| 00:27 |
|
chchjesus joined #minetest-dev |
| 00:29 |
|
shadowzone joined #minetest-dev |
| 00:30 |
|
Babizera joined #minetest-dev |
| 00:35 |
|
Zera joined #minetest-dev |
| 00:44 |
|
chchjesus joined #minetest-dev |
| 01:04 |
|
ZeraRoox joined #minetest-dev |
| 01:05 |
|
Fritigern joined #minetest-dev |
| 01:39 |
|
est31 joined #minetest-dev |
| 02:06 |
|
rickmcfarley joined #minetest-dev |
| 02:36 |
|
deltib joined #minetest-dev |
| 02:53 |
|
ZeraRoox joined #minetest-dev |
| 02:56 |
|
Player_2 joined #minetest-dev |
| 03:06 |
|
chchjesus joined #minetest-dev |
| 04:05 |
|
Tablet_One joined #minetest-dev |
| 05:08 |
|
Miner_48er joined #minetest-dev |
| 06:20 |
|
Megaf joined #minetest-dev |
| 06:22 |
|
jin_xi joined #minetest-dev |
| 06:30 |
|
Hunterz joined #minetest-dev |
| 06:36 |
hmmmm |
today was not a very minetesty day |
| 06:37 |
VanessaE |
that could change :P |
| 06:37 |
VanessaE |
unfortunately it's late :-/ |
| 06:39 |
hmmmm |
:/ |
| 06:39 |
hmmmm |
so busy lately |
| 06:39 |
hmmmm |
hopefully that'll change |
| 06:41 |
est31 |
what do you ppl think, which hash alg for speed improvements? |
| 06:41 |
VanessaE |
what's the target for the hash? |
| 06:41 |
est31 |
I want to make a std::unordered_map |
| 06:41 |
VanessaE |
recipes? |
| 06:41 |
est31 |
yes |
| 06:41 |
VanessaE |
oh |
| 06:42 |
hmmmm |
eh |
| 06:42 |
VanessaE |
idk, md5? :) |
| 06:42 |
hmmmm |
est31, about that... I would hold off if I were you |
| 06:42 |
est31 |
my idea would be xxhash |
| 06:42 |
est31 |
why hmmmm? |
| 06:42 |
hmmmm |
I make everything that should be a hashtable into a std::map, and then when the time comes to switch to C++11, we go through all instances of std::map and see if it's able to get changed to std::unordered_map |
| 06:42 |
hmmmm |
and same with std::set |
| 06:43 |
VanessaE |
*looks up xxhash* wow, that IS fast |
| 06:43 |
hmmmm |
C++11 should be coming soon(tm) (we're waiting on debian, i think...) |
| 06:43 |
est31 |
yea this month |
| 06:43 |
hmmmm |
you serious? |
| 06:43 |
est31 |
unordered_map is specified < c++11 |
| 06:43 |
VanessaE |
you sure deb stable will gain this? |
| 06:44 |
VanessaE |
I mean without big reinstalls etc |
| 06:45 |
hmmmm |
VanessaE: I don't really know... but once gcc 4.6 or newer is on all supported distros/platforms, there's no really good excuse for holding back as long as mingw works |
| 06:45 |
hmmmm |
switch to C++11 if only for the speed gains |
| 06:45 |
est31 |
or no, you are right, its c++1 only |
| 06:45 |
VanessaE |
hmmmm: that's fair, it's just you know how long some hosts can take to update their stuff |
| 06:45 |
est31 |
c++11* |
| 06:45 |
hmmmm |
yeah... not 100% sure what the plan is |
| 06:46 |
VanessaE |
when I was shopping around recently, I swear I was seeing places where Debian 6 was still being offered |
| 06:46 |
est31 |
weird doc ----> http://en.cppreference.com/w/cpp/container/unordered_map |
| 06:46 |
VanessaE |
(in addition to 7 of course) |
| 06:46 |
est31 |
other doc, sais its > c++11 -------> http://www.cplusplus.com/reference/unordered_map/unordered_map/ |
| 06:46 |
hmmmm |
huh? |
| 06:47 |
hmmmm |
est31: the cppreference.com link has "(since C++11)" there |
| 06:47 |
hmmmm |
in green, off to the right of the declaration |
| 06:48 |
est31 |
yes, I thought it was only about the hash part |
| 06:49 |
est31 |
would have been a very breaking way to introduce new params |
| 06:49 |
jin_xi |
hm working on particles i noticed something |
| 06:49 |
hmmmm |
agreed |
| 06:49 |
jin_xi |
it seems like for every particle spawner that is expiring by itself we leak an id |
| 06:49 |
est31 |
so then it will be a map |
| 06:49 |
hmmmm |
figures as much |
| 06:49 |
jin_xi |
so i wonder where to keep track of those on server side |
| 06:49 |
est31 |
with a comment // change this to unordered_map when c++11 can be used |
| 06:50 |
hmmmm |
in fact i'm pretty sure all of the current particle code had memory leaks |
| 06:50 |
hmmmm |
merging that has to be my biggest regret so far |
| 06:50 |
jin_xi |
here: https://github.com/minetest/minetest/blob/master/src/server.cpp#L2956 |
| 06:51 |
hmmmm |
that is so cringeworthy |
| 06:51 |
jin_xi |
m_particlespawner_ids is only handled with explicit add and delete of spawners, as expiration happens only on clients |
| 06:51 |
hmmmm |
i'm wondering if it's worth fixing particlespawners |
| 06:52 |
hmmmm |
jin_xi, i think you should scrap the entire current implementation minus the network packet format |
| 06:52 |
jin_xi |
thats what im doing |
| 06:52 |
hmmmm |
thank you. |
| 06:52 |
jin_xi |
still server needs to know spawners, mostly to give them unique ids |
| 06:53 |
hmmmm |
hehehe |
| 06:53 |
hmmmm |
:) |
| 06:54 |
hmmmm |
I didn't get around to writing up the proposed design, but basically hud, particle spawners, formspecs, and sounds are four easy targets for client side modding |
| 06:55 |
hmmmm |
the plan is to remove them from server-side completely, reimplement the current apis in lua, and use the ObjDefManager setup to manage them |
| 06:56 |
jin_xi |
so i ignore this problem just as its being done now and work on other details |
| 06:56 |
hmmmm |
well, no |
| 06:56 |
hmmmm |
there's really no telling when client side modding will happen |
| 06:57 |
jin_xi |
then i need help to come up with a solution |
| 06:57 |
est31 |
vessels should be client side too. |
| 06:57 |
jin_xi |
i would just increment a number and wrap on overflow... |
| 06:57 |
hmmmm |
that's doable |
| 06:57 |
hmmmm |
how big is the ID field? |
| 06:58 |
hmmmm |
32 bit in the Server:: methods, it seems, but I think it's incredibly inconsistent |
| 06:58 |
hmmmm |
if I recall it's 16 bit inside the packets |
| 07:01 |
jin_xi |
another highly annoying thing is that effin camera_offset |
| 07:02 |
jin_xi |
i wonder what glitches thats fixing |
| 07:03 |
VanessaE |
you mean the every-200-nodes thing? |
| 07:04 |
|
nrzkt joined #minetest-dev |
| 07:04 |
VanessaE |
that was added to counter irrlicht rende rounding errors or some such, that used to happen once you get out more than about 2km from the map center. |
| 07:04 |
VanessaE |
render* |
| 07:06 |
nrzkt |
hmmmm: experienced the replacement of our JMutexAutoLock with std::lock_guard on a separate branch, that's okay. Replacing also JMutex with a JMutex: std::mutex works great too :) |
| 07:06 |
hmmmm |
what? |
| 07:07 |
jin_xi |
yes i know, but i wonder what kind of errors it caused. because the offset thing is not without its problems. |
| 07:07 |
hmmmm |
I don't quite get what you mean by that, but std::mutex is C++11. |
| 07:07 |
nrzkt |
yes, you talked about C++11 i see in the logs :p |
| 07:07 |
jin_xi |
for one it breaks helicopter mod, attachments get torn and players teleported |
| 07:07 |
nrzkt |
then i tell you i tested it with minetest core (and also i use it on my own server) |
| 07:07 |
hmmmm |
nrzkt, I am glad it works great for you but I would much prefer that we don't make such a drastic change |
| 07:08 |
hmmmm |
there are subtle differences we may not know about... not so with std::unordered_map |
| 07:08 |
nrzkt |
the change is simple in fact |
| 07:08 |
hmmmm |
one has much higher potential for disaster because its errors are subtle by nature |
| 07:08 |
nrzkt |
i don't experienced std::unordered_map, only test std::mutex and std::lock_guard |
| 07:08 |
hmmmm |
you thought changing std::list to std::vector was easy |
| 07:08 |
hmmmm |
and look at how many bugs that caused |
| 07:09 |
nrzkt |
because only the usage was wrong because i haven't read carefully one function, right |
| 07:09 |
hmmmm |
it's not that simple. it's NEVER that simple! and we can't go around breaking things willy nilly because our upstream version must have some semblance of stability |
| 07:09 |
hmmmm |
I am not going to rush things any more |
| 07:10 |
nrzkt |
but i can tell you the std::mutex and std::lock_guard change can be done safely, i'm using in since ... 2 weeks on my server without any problem. I don't tell we must switch it |
| 07:10 |
hmmmm |
if a huge change like that is going to rot away too quickly due to merge conflicts, well then, break it up into small pieces |
| 07:10 |
nrzkt |
i tell this is possible, that's a little bit different :p |
| 07:10 |
hmmmm |
I don't care how long you tested it on your own server |
| 07:10 |
nrzkt |
and i don't care that you tell me te be slow, because i don't tell i will merge it into master. |
| 07:10 |
hmmmm |
the network changes were tested for a MONTH on multiple peoples' servers and problems were still found |
| 07:11 |
hmmmm |
nrzkt: I didn't quite understand your last sentence. are you saying that you're going to commit it without approval? |
| 07:12 |
nrzkt |
hmmmm: wake up. You tell exactly the opposite |
| 07:13 |
hmmmm |
erm... whatever. |
| 07:13 |
nrzkt |
please reread what i said slowly |
| 07:13 |
hmmmm |
I tried to and I didn't understand |
| 07:13 |
VanessaE |
hmmmm: I think he means, "because i don't tell [you] i will merge it into master" |
| 07:13 |
nrzkt |
i said: the switch is possible, i tested it. I don't say, i will merge it (soon or not). |
| 07:14 |
hmmmm |
oh |
| 07:14 |
hmmmm |
"I didn't ever say that I was going to merge it to upstream" |
| 07:15 |
nrzkt |
my english isn't perfect, i know :p but i try to be understandable :p |
| 07:15 |
hmmmm |
that particular sentence had subtle meanings. |
| 07:15 |
nrzkt |
i'm not subtile |
| 07:15 |
nrzkt |
simpler, faster, efficient :p |
| 07:15 |
hmmmm |
yea... being subtle is necessary when we're trying to not break things |
| 07:16 |
jin_xi |
so, some more questions, anyone knows what could cause textures to be upside down and black instead of transparent? |
| 07:16 |
hmmmm |
jin_xi, try enable_clean_transparent = false |
| 07:16 |
nrzkt |
in fact, when we are talking together, be subtle is not very efficient :p clear sentences are a good communication process |
| 07:17 |
hmmmm |
well subtility is not good for purposes of communication |
| 07:18 |
hmmmm |
being subtle when making code changes is |
| 07:18 |
nrzkt |
only for politicians |
| 07:18 |
hmmmm |
that's not subtility, that's doublespeak |
| 07:18 |
hmmmm |
:/ |
| 07:19 |
hmmmm |
so back to the original topic: I'm all for changing JMutexAutoLock, but don't do it all at once |
| 07:19 |
hmmmm |
change one class at a time, gradually |
| 07:19 |
nrzkt |
i will push a modified version of #2526, which only init the nodepos with static_spawnpoint value if set |
| 07:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/2526 -- findSpawnPos should use the static_spawnpoint to set the player position by nerzhul |
| 07:20 |
hmmmm |
we already went through this when we switched from irrlicht containers to stl containers |
| 07:20 |
nrzkt |
in fact hmmmm: we must change JMutex.Lock and JMutex.Unlock and add JMutex.lock and JMutex.unlock |
| 07:20 |
hmmmm |
there was a lot of disasterous breakage and bugs galore because everything was done all at once and it was hard to track |
| 07:20 |
nrzkt |
lock_guard is simple, it only call lock/unlock it's a stupid class |
| 07:20 |
VanessaE |
nrzkt: er... why the upper/lowercase change? |
| 07:21 |
nrzkt |
because of std::lock_guard |
| 07:21 |
nrzkt |
if we have std::lock_guard<JMutex> |
| 07:21 |
hmmmm |
btw |
| 07:21 |
nrzkt |
the lock_guard will call JMutex.lock at creation and JMutex.unlock at destruction |
| 07:21 |
hmmmm |
why make findSpawnPos a member of Server |
| 07:22 |
nrzkt |
because only server call it |
| 07:22 |
hmmmm |
if you're doing that, why not remove the map parameter |
| 07:22 |
hmmmm |
and use m_map |
| 07:22 |
nrzkt |
good idea :) |
| 07:22 |
nrzkt |
m_map = m_env->getServerMap() , right ? |
| 07:22 |
hmmmm |
yea |
| 07:24 |
nrzkt |
we don't have ServerMap member in Server call |
| 07:24 |
nrzkt |
but i will call the pointer into the function |
| 07:26 |
nrzkt |
okay for https://github.com/nerzhul/minetest/commit/dbc739b6a584856155575dc4580709fc332da72b ? |
| 07:26 |
hmmmm |
by the way, are you certain that static_spawnpoint doesn't have a default setting anywhere? |
| 07:27 |
nrzkt |
➜ minetest git:(master) ✗ grep -R "static_spawnpoint" src |
| 07:27 |
nrzkt |
src/server.cpp:g_settings->getV3FNoEx("static_spawnpoint", nodeposf); |
| 07:27 |
nrzkt |
src/server.cpp:// Default position is static_spawnpoint |
| 07:27 |
hmmmm |
maybe it is being set in Lua, i don't know |
| 07:27 |
hmmmm |
just checking |
| 07:28 |
nrzkt |
http://pastie.org/10071244 |
| 07:29 |
hmmmm |
wwow good one |
| 07:29 |
hmmmm |
this is why we review commits before we commit them |
| 07:29 |
hmmmm |
you're copying the entire ServerMap |
| 07:30 |
nrzkt |
that's right |
| 07:30 |
hmmmm |
i think you forgot a & |
| 07:30 |
nrzkt |
yeah, i'm adding it |
| 07:31 |
hmmmm |
what is the desired behavior of static_spawnpoint exactly? |
| 07:32 |
hmmmm |
isn't it supposed to override the random search for a spawnpoint? |
| 07:32 |
nrzkt |
here this permit to fix in some rare cases player beeing teleported to 0,0,0 because of this function call |
| 07:32 |
VanessaE |
always teleport the user there after death or on a new user sign-on |
| 07:32 |
VanessaE |
simple. |
| 07:32 |
nrzkt |
after death and new user, right |
| 07:32 |
VanessaE |
it has no other purpose than that, in a vanilla setup. |
| 07:32 |
hmmmm |
why don't you return immediately if getV3FNoEx("static_spawnpoint") returns true, then? |
| 07:33 |
nrzkt |
it was the original PR |
| 07:33 |
hmmmm |
i thought that's what we wanted |
| 07:33 |
nrzkt |
but i don't know if we should do this or find a good place |
| 07:33 |
nrzkt |
if you think we want this, okay for a return, like the original PR |
| 07:33 |
hmmmm |
i don't know what we want |
| 07:33 |
hmmmm |
i just want it to work |
| 07:34 |
hmmmm |
it's up to you i guess |
| 07:34 |
nrzkt |
here we doesn't have a player teleported to 0,0,0 if static_spawnpoint is set |
| 07:34 |
nrzkt |
but we can have a random position after a respawn |
| 07:35 |
nrzkt |
or, default, the static_spawnpoint. If the goal of static_spawnpoint is to spawn every time at spawn, then we return immediately. |
| 07:35 |
nrzkt |
it's how i understand it |
| 07:36 |
hmmmm |
that's how i understood it too |
| 07:36 |
nrzkt |
then we will return directly |
| 07:36 |
hmmmm |
but, unless i'm completely mistaken, that code in the PR doesn't do anything with static_spawnpoint since it gets overwritten by the random search loop |
| 07:37 |
nrzkt |
but in some case the random search loop doesn't match |
| 07:37 |
hmmmm |
oh yeah, I see those |
| 07:37 |
hmmmm |
the two continue statements |
| 07:37 |
nrzkt |
and we return a basic v3s16, with 0,0,0 |
| 07:38 |
hmmmm |
maybe this can be two separate settings |
| 07:38 |
hmmmm |
fallback_spawnpoint and static_spawnpoint |
| 07:38 |
hmmmm |
static_spawnpoint, if set, returns immediately with that static spawnpoint |
| 07:38 |
hmmmm |
fallback_spawnpoint, on the other hand, is the default spawnpoint used if no suitable random spawnpoint can be found |
| 07:38 |
hmmmm |
sound good or not? |
| 07:39 |
nrzkt |
it could be good to add it in a separate commit, why not :) |
| 07:39 |
hmmmm |
ok then |
| 07:39 |
VanessaE |
hmmmm: well, if you could set one, why not just set the other?> |
| 07:39 |
VanessaE |
I mean you as the user editing your config |
| 07:40 |
nrzkt |
https://github.com/nerzhul/minetest/commit/3f8024330ae9d5f92418fa4b3025638d5a7e0b37 for the static_spawnpoint |
| 07:40 |
VanessaE |
really, it just seems like overkill for a singleplayer instance - in a multiplayer server, you'll almost always have a static_spawnpoint set |
| 07:41 |
jin_xi |
so regarding expiring spawners on server: where does such stuff go? regardless of how ids are done, server needs to keep track to free expired ones |
| 07:43 |
jin_xi |
im thinking of a list of id and expiration time and a check, only wondering where this kind of housekeeping is done in server step |
| 07:43 |
hmmmm |
well, I guess it could just scan for the lowest available ID |
| 07:43 |
nrzkt |
a last review before a push hmmmm ? ^ |
| 07:43 |
hmmmm |
nothing really does need to be fancy |
| 07:43 |
hmmmm |
VanessaE: dunno, you as a server owner should make the decision on how you want the behavior to be |
| 07:43 |
hmmmm |
nrzkt, looks good |
| 07:44 |
VanessaE |
hmmmm: agreed - I'm just saying I don't think you'll see too many people actually using the feature. but ok |
| 07:44 |
jin_xi |
hmmmm: exactly. i wonder where the right place to check time in server is as im not familiar |
| 07:45 |
hmmmm |
wait, why do they need to expire after a certain time? |
| 07:46 |
hmmmm |
isn't that the mod's decision to make it expire? forgive my ignorance i don't quite know how they work |
| 07:46 |
ZeraRoox |
hmmmm Please check your private msg |
| 07:46 |
hmmmm |
ZeraRoox: why are you private messaging me |
| 07:46 |
hmmmm |
I don't check private messages btw |
| 07:47 |
hmmmm |
just tell me here what it is |
| 07:47 |
jin_xi |
yes, mods can have them expire with fixed time set. server makes spawner with id, passes to client, client handles expiration. -> id leaked and never reused |
| 07:47 |
jin_xi |
thats current situation |
| 07:47 |
hmmmm |
jin_xi, what kind of resolution does it need? |
| 07:47 |
ZeraRoox |
When you have time check your email |
| 07:48 |
hmmmm |
uh, okay |
| 07:48 |
ZeraRoox |
is about a project |
| 07:48 |
jin_xi |
hmmmm: not very precise, time is in seconds on lua side |
| 07:49 |
hmmmm |
there's nothing fundamentally wrong with time(NULL) |
| 07:49 |
hmmmm |
you could use that... |
| 07:49 |
|
err404 joined #minetest-dev |
| 07:50 |
hmmmm |
you can't use irrlicht's timer because that's client-side |
| 07:50 |
jin_xi |
ok and forgive my ignorance, but where is server step housekeeping done? |
| 07:51 |
hmmmm |
lol |
| 07:51 |
hmmmm |
in Server::step |
| 07:51 |
hmmmm |
but I think what you're actually interested in is the environment's step |
| 07:52 |
nrzkt |
Server::AsyncRunStep |
| 07:52 |
nrzkt |
which calls Environment::step |
| 07:52 |
hmmmm |
Particle spawners should be part of the Environment |
| 07:52 |
jin_xi |
thanks. i thought putting particle spawners in 25 line server::step looked off |
| 07:52 |
hmmmm |
at least in theory |
| 07:53 |
hmmmm |
jin_xi, you should use dtime instead by the way |
| 07:53 |
hmmmm |
instead of using other timers |
| 07:54 |
jin_xi |
yes thats what i want to do. |
| 07:54 |
VanessaE |
jin_xi: a note: there's a glitch with the expiration time, |
| 07:54 |
VanessaE |
if set to zero, particles don't move. |
| 07:55 |
jin_xi |
so my plan is to replace list of ids on serverside with list of struct with id and expiration time |
| 07:55 |
jin_xi |
then properly expire expired ids |
| 07:56 |
jin_xi |
VanessaE: is that on my PR or current glitch? |
| 07:56 |
VanessaE |
it's a current thing |
| 07:56 |
VanessaE |
not in your PR |
| 07:56 |
VanessaE |
just mentioning it since you're fiddling around with the code. |
| 07:56 |
jin_xi |
ok because all current rendering and stepping will be gone. im deleting this code |
| 07:57 |
VanessaE |
thought you might want to take a look at it |
| 07:57 |
VanessaE |
oh? |
| 07:58 |
jin_xi |
anyways, this server id thing needs to be fixed regardless of particle rendering situation |
| 07:59 |
VanessaE |
this is 2587? |
| 07:59 |
jin_xi |
idk what bugs it may cause, but it accumulates some memory for every spawner deleted by expiration |
| 08:00 |
jin_xi |
yes |
| 08:00 |
VanessaE |
ok |
| 08:00 |
VanessaE |
I'll leave you to it then |
| 08:00 |
VanessaE |
sorry to interrupt |
| 08:06 |
* VanessaE |
wanders off to bed, clearly too tired for rational thought :P |
| 08:06 |
VanessaE |
night. |
| 08:12 |
|
blaze joined #minetest-dev |
| 08:12 |
hmmmm |
it's past 4am, but i'm perfectly up and feeling at my best right about now |
| 08:12 |
hmmmm |
there's something seriously wrong with me |
| 08:15 |
|
Calinou joined #minetest-dev |
| 08:24 |
|
leat joined #minetest-dev |
| 08:24 |
|
blaze` joined #minetest-dev |
| 08:27 |
Megaf |
Hi everyone |
| 08:40 |
|
kilbith joined #minetest-dev |
| 08:55 |
|
eeew joined #minetest-dev |
| 09:16 |
|
err404 joined #minetest-dev |
| 09:48 |
|
OldCoder joined #minetest-dev |
| 09:59 |
Megaf |
devs are never online when we need them |
| 10:04 |
Megaf |
/home/minetest/minetest/src/irrlichttypes.h:34:22: fatal error: irrTypes.h: No such file or directory |
| 10:05 |
Megaf |
cmake . -DRUN_IN_PLACE=1 -DBUILD_CLIENT=0 -DBUILD_SERVER=1 -DIRRLICHT_INCLUDE_DIR=/home/minetest/Deps/Irrlicht/ |
| 10:05 |
Megaf |
minetest mt:~/minetest$ find /home/minetest/Deps/Irrlicht/ | grep irrTypes.h |
| 10:05 |
Megaf |
/home/minetest/Deps/Irrlicht/include/irrTypes.h |
| 10:06 |
Megaf |
The file is there |
| 10:06 |
|
leat joined #minetest-dev |
| 10:06 |
Megaf |
help? |
| 10:06 |
Megaf |
^ Calinou VanessaE |
| 10:06 |
Megaf |
fresh git clone from master |
| 10:07 |
Megaf |
-- Could NOT find Irrlicht (missing: IRRLICHT_LIBRARY) |
| 10:08 |
Megaf |
hm |
| 10:14 |
sfan5 |
Megaf: by your logic -DIRRLICHT_INCLUDE_DIR=/ should also work |
| 10:15 |
sfan5 |
Megaf: hint: you obviously need to point IRRLICHT_INCLUDE_DIR directly at the directory with irrTypes.h |
| 10:15 |
Calinou |
yes, you forgot include/ |
| 10:15 |
Megaf |
sfan5: I've been doing the very same way for three years... |
| 10:15 |
sfan5 |
no |
| 10:15 |
sfan5 |
this doesn't work and has never worked |
| 10:16 |
sfan5 |
Megaf: -DIRRLICHT_SOURCE_DIR=<irrlicht dir (without include/)> could have worked though |
| 10:16 |
sfan5 |
(IRRLICHT_INCLUDE_DIR vs IRRLICHT_SOURCE_DIR) |
| 10:17 |
Megaf |
Ok, I have changed my cmake script in fact, let me see the old script that is know to work |
| 10:17 |
Megaf |
known* |
| 10:18 |
Megaf |
sfan5: anyway, it doesnt work when I point the include to /home/minetest/Deps/Irrlicht/include and source to /home/minetest/Deps/Irrlicht/ either |
| 10:18 |
sfan5 |
what does it say when you point the include to /home/minetest/Deps/Irrlicht/include |
| 10:21 |
Megaf |
This is in fact the line that I have been using for 3 years -DIRRLICHT_SOURCE_DIR=/home/minetest/Deps/Irrlicht/ |
| 10:22 |
Megaf |
It worked till yesterday |
| 10:22 |
Megaf |
now cmake says -- Could NOT find Irrlicht (missing: IRRLICHT_LIBRARY) |
| 10:22 |
Megaf |
anyway, it's working again now |
| 10:23 |
Megaf |
go figure |
| 10:23 |
sfan5 |
it should work like that |
| 10:23 |
sfan5 |
you don't need the library for server builds |
| 10:23 |
Megaf |
I know, I attempted to include that because source wasnt working |
| 10:25 |
|
leat joined #minetest-dev |
| 10:25 |
Megaf |
sfan5: I think it was working yesterday because I had actually compile Irrlicht once, and today I removed the compiled version by a fresh source snapshot |
| 10:26 |
sfan5 |
iirc irrlicht_source_dir only finds the library on windows |
| 10:40 |
Megaf |
kilbith: my server is back online, thanks to sfan5. Join now and see if the bug is fixed, please. |
| 10:44 |
kilbith |
Megaf, the public one ? |
| 10:44 |
Megaf |
yep, the main on |
| 10:44 |
Megaf |
one |
| 10:44 |
Megaf |
mt.megaf.info 30003 or 8080 |
| 10:47 |
kilbith |
Megaf, this seems fixed now |
| 10:47 |
Megaf |
cool |
| 10:54 |
|
leat joined #minetest-dev |
| 10:58 |
Megaf |
is there a way to make cmake/gcc optimze the binary as much as possible? For speed, not for size, runtime speed |
| 10:58 |
Megaf |
or is that the same as optimizing for size/speed? |
| 10:58 |
Megaf |
Compile time is not an issue |
| 11:01 |
|
Lunatrius joined #minetest-dev |
| 11:14 |
sfan5 |
Megaf: -DCMAKE_C_FLAGS="-O3 -march=native -mtune=native" -DCMAKE_CXX_FLAGS="-O3 -march=native -mtune=native" not that the resulting binary might not run on other processors |
| 11:15 |
Megaf |
sfan5: I'd like to optimize my server, I do not intend to run it on other places |
| 11:15 |
Megaf |
Thanks |
| 11:27 |
Megaf |
sfan5: is not even compatible with its own CPU |
| 11:27 |
Megaf |
$ bin/minetestserver |
| 11:27 |
Megaf |
Illegal instruction |
| 11:29 |
|
est31 joined #minetest-dev |
| 11:30 |
|
Zeno` joined #minetest-dev |
| 11:47 |
est31 |
Zeno`, what do you think? http://pastie.org/10071522 |
| 11:48 |
Zeno` |
I think it looks like a diff |
| 11:49 |
Zeno` |
and that PAssword has a typo |
| 11:50 |
Zeno` |
PASSWORD_SIZE * 2 ??? |
| 11:51 |
est31 |
no idea why or how |
| 11:52 |
est31 |
ah |
| 11:53 |
est31 |
yes |
| 11:53 |
est31 |
ofc |
| 11:53 |
est31 |
first old password, then the new one |
| 11:53 |
est31 |
and the first byte is already strippped |
| 11:55 |
est31 |
I'll merge if you dont mind |
| 11:55 |
est31 |
or push |
| 11:57 |
Megaf |
!server Megaf |
| 11:57 |
ShadowBot |
Megaf: server [--{name,address,ip,players,ping,port} <value>] |
| 11:57 |
Megaf |
wrong channel, sorry |
| 11:58 |
est31 |
do you agree? |
| 11:59 |
Zeno` |
err you're removing just the errorstream thing? |
| 11:59 |
est31 |
yes |
| 12:00 |
Zeno` |
well it's not an error |
| 12:00 |
Zeno` |
so yeah |
| 12:00 |
est31 |
I can't find that "if nobody objects, then you can push minor stuff rule", so I dont know whether it only affects subsystem maintainers |
| 12:01 |
Zeno` |
if it's a trivial fix just mention here that's you're going to do it, wait a bit, and push/merge |
| 12:01 |
Zeno` |
that* |
| 12:01 |
Zeno` |
I have nfi why that line is even there so, yeah, that would be a trivial change |
| 12:03 |
est31 |
my theory is that its debug stuff which was forgotten to be removed |
| 12:03 |
Zeno` |
even so it should have been verbosestream |
| 12:03 |
Zeno` |
it's obviously wrong |
| 12:04 |
|
SopaXorzTaker joined #minetest-dev |
| 12:07 |
est31 |
sfan5, can you give me (freshly promoted core-dev) a blue dot? |
| 12:09 |
|
nrzkt joined #minetest-dev |
| 12:09 |
nrzkt |
est31: approved. |
| 12:10 |
Zeno` |
lol I've already approved |
| 12:10 |
Zeno` |
what is a blue dot? |
| 12:10 |
nrzkt |
yes, i also approve it because it's on my network handlers :p |
| 12:10 |
Zeno` |
oh |
| 12:10 |
Zeno` |
+v |
| 12:10 |
nrzkt |
but it's not necessary, it's very trivial :p |
| 12:10 |
est31 |
yes |
| 12:11 |
Zeno` |
no blue dot for you1 |
| 12:11 |
Zeno` |
hehe |
| 12:11 |
est31 |
its bad because every time a user changes their password, the error is transmitted in public server chat |
| 12:12 |
est31 |
"error" |
| 12:12 |
Zeno` |
yes very bad |
| 12:13 |
Zeno` |
hey, your first merge and you didn't stuff it up |
| 12:13 |
Zeno` |
nice :P |
| 12:13 |
est31 |
lol |
| 12:13 |
Zeno` |
I am supposed to be in bed :( |
| 12:14 |
Zeno` |
Doctor says I have influenza |
| 12:14 |
Megaf |
That means, a simple flue |
| 12:14 |
Megaf |
just dont move too much and drink plenty of water Zeno` |
| 12:14 |
Zeno` |
you can die from the flu |
| 12:14 |
Megaf |
flu* |
| 12:15 |
Zeno` |
so I dunno if it's "simple" :P |
| 12:15 |
Zeno` |
can I drink beer instead? |
| 12:15 |
Megaf |
I'm afraid you can't |
| 12:15 |
Megaf |
you can drink natural juices |
| 12:16 |
Zeno` |
good, because I don't feel like moving or drinking beer anyway heh |
| 12:16 |
Zeno` |
I' |
| 12:16 |
Zeno` |
I'm outa here.. I can hardly think |
| 12:16 |
Zeno` |
O/ |
| 12:19 |
Megaf |
!up stuff |
| 12:19 |
ShadowBot |
Megaf: Resolving stuff failed: [Errno -2] Name or service not known |
| 12:30 |
|
rubenwardy joined #minetest-dev |
| 12:33 |
|
srifqi joined #minetest-dev |
| 12:38 |
sfan5 |
est31: there's your blue dot |
| 12:53 |
est31 |
thanks |
| 13:08 |
|
selat joined #minetest-dev |
| 13:56 |
|
SopaXorzTaker joined #minetest-dev |
| 14:03 |
|
luizrpgluiz joined #minetest-dev |
| 14:11 |
|
luizrpgluiz left #minetest-dev |
| 14:11 |
|
MinetestForFun joined #minetest-dev |
| 14:17 |
|
est joined #minetest-dev |
| 14:24 |
|
leat joined #minetest-dev |
| 14:33 |
|
MinetestForFun joined #minetest-dev |
| 14:42 |
rubenwardy |
What technical things limit us to +/- 31,000? |
| 14:43 |
rubenwardy |
Is it the size in bytes of position serials? |
| 14:43 |
rubenwardy |
like, you'd have to break the blobs to increase the size. |
| 14:46 |
est |
yea seems so |
| 14:46 |
rubenwardy |
I guess it's a case of bigger serials means bigger maps but bigger file sizes. |
| 14:47 |
est |
not neccessarily |
| 14:47 |
est |
bigger maps I mean |
| 14:47 |
est |
network will be a bit more verbose yes |
| 14:47 |
rubenwardy |
So you have to compromise between bigger maps and bigger files |
| 14:47 |
rubenwardy |
Really? |
| 14:47 |
rubenwardy |
Yeah, networking would be a problem too. |
| 14:48 |
rubenwardy |
It seems they currently use 2 bytes for each coordinate, so 6 bytes for the position serial. |
| 14:48 |
est |
sorry got it wrong, maps will be bigger of course, but file sizes wont be |
| 14:48 |
est |
I'm not sure though |
| 14:48 |
est |
perhaps they will |
| 14:49 |
rubenwardy |
Blobs don't store position serials, of course? It's just the fields for x/y/z in the MapBlock table |
| 14:49 |
est |
yes |
| 14:49 |
est |
usually, the mapblock table is referenced by serials |
| 14:49 |
est |
inside the db |
| 14:49 |
est |
and on the network I think too |
| 14:50 |
rubenwardy |
#1845 hasn't been merged, so it's just one field for position, as a serial. Instead of three. |
| 14:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/1845 -- Split block position into separate fields in SQLite3 database by ShadowNinja |
| 14:53 |
rubenwardy |
The current map size is fun for the majority of players, but not for making countries etc in game. |
| 14:53 |
rubenwardy |
*fine |
| 14:53 |
rubenwardy |
It's mostly just a willy waving competitions |
| 14:55 |
|
SopaXorzTaker joined #minetest-dev |
| 15:26 |
|
hmmmm joined #minetest-dev |
| 15:29 |
Megaf |
rubenwardy: est: What is the technical problem/issue with infinite maps? Can't we just make it grow on demand? |
| 15:31 |
est |
the problem is that node positions are stored in a value that has certain limits, and network protocol and other places need it to not exceed the limits |
| 15:32 |
Megaf |
est: I understand that, but isnt Minecraft map infinite? |
| 15:32 |
est |
it is definitely possible for players or mobs to walk around areas past the 30k, just no voxel world |
| 15:35 |
Megaf |
hm, it is not |
| 15:35 |
Megaf |
http://gaming.stackexchange.com/questions/19179/what-happens-when-you-reach-the-edge-of-the-world |
| 15:35 |
Megaf |
first answer |
| 15:37 |
rubenwardy |
In Minecraft, we should disregard range where is starts to get floating point errors |
| 15:37 |
est |
how important is the feature that you can use aliases in craft recipes? |
| 15:37 |
est |
should I try to retain it? |
| 15:40 |
rubenwardy |
An older version of the food mod used it to add support, but no longer. It's probably best to - will it cause problems? Can you convert from alias to real when registering a recipe, and then there is no need to look it up in get craft recipes? |
| 15:41 |
rubenwardy |
ie: no alias support in get_crafts(), but doesn't matter because aliases are removed in register_craft |
| 15:42 |
|
err404 joined #minetest-dev |
| 15:42 |
est |
I'll try to retain it |
| 15:46 |
rubenwardy |
So in Minecraft you can walk in one direction from spawn 1000x longer. |
| 15:47 |
rubenwardy |
* shrugs * |
| 15:48 |
Megaf |
rubenwardy: yep, but you can't go very deep |
| 15:48 |
Megaf |
nor very high |
| 15:48 |
|
err404 joined #minetest-dev |
| 15:49 |
Megaf |
anyway, I would really like to have a world 100000x100000x100000 instead of 32000x32000x32000 |
| 15:50 |
Megaf |
Is that (10^5)*3? |
| 15:51 |
rubenwardy |
(10^5)^3 for the area |
| 15:51 |
rubenwardy |
Horizontal distance is more useful than vertical, but having a limit of 255 is just taking the p. |
| 15:52 |
rubenwardy |
It should be at least 5,000 to allow for nice layers |
| 15:53 |
Megaf |
what if the max size of the world of limited by the CPU instruction? |
| 15:53 |
rubenwardy |
huh |
| 15:53 |
rubenwardy |
? |
| 15:53 |
* Megaf |
feels liek he doesnt know what he is talking about |
| 15:53 |
kilbith |
do we *really* need more than 32K³ nodes ? biggest servers does not even have 10% of the map explored... |
| 15:53 |
Megaf |
s/liek/like |
| 15:53 |
kilbith |
better to focus on interconnected multi-worlds instead |
| 15:53 |
Megaf |
kilbith: well, you'd be surprized the distance players walk on my server |
| 15:54 |
kilbith |
and how is that useful ? |
| 15:54 |
Megaf |
how useful is it to limit peoples urge to explore? |
| 15:54 |
Megaf |
let them explore |
| 15:55 |
Megaf |
and I do agree on interconnected worlds by the way |
| 15:55 |
Megaf |
and I even have some idea on how would that be possible |
| 15:55 |
sfan5 |
Megaf: how useful is it to break everyones existing maps |
| 15:55 |
Megaf |
sfan5: no need to break... Just expand |
| 15:55 |
Megaf |
keep the existing coord and add more |
| 15:56 |
sfan5 |
the map format is not designed for that |
| 15:56 |
sfan5 |
it would need conversion |
| 15:57 |
rubenwardy |
The map size is sufficient for most uses, but not for big projects like real world maps. 32 KM isn't that much in real life. |
| 15:57 |
est |
btw what do you imagine with the "interconnected worlds" thing? |
| 15:57 |
Megaf |
rubenwardy: I was thinking about that actually |
| 15:58 |
kilbith |
est, ask to RBA when he will be there |
| 15:58 |
kilbith |
was in his plan |
| 15:58 |
Megaf |
est: one very hacky way of doing it, and "very not good" is using a shared database by n servers |
| 15:59 |
Megaf |
each server could have its own limits of map |
| 15:59 |
Megaf |
within the global map |
| 16:05 |
Megaf |
or they could just have their own database and send stuff to each other |
| 16:06 |
Megaf |
each one could have its own 32K*3 map, the coord could be relative, |
| 16:09 |
|
err404 joined #minetest-dev |
| 16:10 |
|
selat joined #minetest-dev |
| 16:10 |
|
roniz joined #minetest-dev |
| 16:16 |
|
SopaXorzTaker joined #minetest-dev |
| 16:17 |
|
selat joined #minetest-dev |
| 16:17 |
|
Jordach joined #minetest-dev |
| 16:22 |
|
Tablet_One joined #minetest-dev |
| 16:45 |
|
Zuruck joined #minetest-dev |
| 16:46 |
|
Zuruck left #minetest-dev |
| 16:51 |
|
proller joined #minetest-dev |
| 16:52 |
|
proller joined #minetest-dev |
| 17:01 |
|
Wayward_One joined #minetest-dev |
| 17:09 |
|
proller joined #minetest-dev |
| 17:20 |
est |
why again are we serializing craft definitions? |
| 17:20 |
est |
and whole managers |
| 17:20 |
sfan5 |
how would we get them over the wire otherwise? |
| 17:21 |
est |
and why do we do that? |
| 17:21 |
|
SopaXorzTaker joined #minetest-dev |
| 17:21 |
est |
why do we do them at the other side? |
| 17:21 |
est |
need* |
| 17:22 |
sfan5 |
actually |
| 17:22 |
sfan5 |
hm |
| 17:23 |
sfan5 |
why does the client need craftdefs? |
| 17:24 |
|
err404 joined #minetest-dev |
| 17:27 |
est |
https://github.com/minetest/minetest/blob/master/src/network/networkprotocol.h#L44 |
| 17:27 |
est |
my guess is it isn't used anymore |
| 17:29 |
|
ElectronLibre joined #minetest-dev |
| 17:50 |
|
MinetestForFun joined #minetest-dev |
| 18:06 |
|
ElectronLibre joined #minetest-dev |
| 18:30 |
|
rubenwardy joined #minetest-dev |
| 18:36 |
|
MinetestForFun_ joined #minetest-dev |
| 18:47 |
|
proller joined #minetest-dev |
| 19:02 |
|
MattJ joined #minetest-dev |
| 19:08 |
|
clu_program joined #minetest-dev |
| 19:15 |
|
chchjesus joined #minetest-dev |
| 20:04 |
|
AnotherBrick joined #minetest-dev |
| 20:05 |
hmmmm |
fuwah! |
| 20:05 |
hmmmm |
the weekend is here |
| 20:05 |
hmmmm |
ha ha! time to minetest! |
| 20:06 |
hmmmm |
I know how to solve the infinite map problem |
| 20:06 |
Calinou |
then do it :P |
| 20:06 |
hmmmm |
let's claim that our maps can from FLT_MIN to FLT_MAX |
| 20:07 |
hmmmm |
and then the client will exponentially decay in performance the further it goes out from the origin, discouraging people from exploring |
| 20:07 |
hmmmm |
s/exploring/teleporting to the borders/ |
| 20:08 |
hmmmm |
that's basically what minecraft does anyway |
| 20:08 |
Calinou |
but Minecraft behaves well until at least 100,000 |
| 20:14 |
hmmmm |
people don't typically build past 8000 |
| 20:15 |
hmmmm |
the more i think about it, the more i convince myself that making the limits higher is a gigantic waste of time and effort |
| 20:15 |
hmmmm |
that number is for marketing |
| 20:16 |
hmmmm |
it's like horsepower vs. torque. it's like the genesis being '64 bit' with 'blast processing' |
| 20:16 |
kilbith |
agreed |
| 20:36 |
est |
^ |
| 20:38 |
est |
even if, I would think that 2^32 is more than enough |
| 20:38 |
est |
floats lose precision |
| 20:39 |
est |
better a hard limit than "it begins to fail when the FPU starts to do weird things" |
| 20:39 |
|
err404 joined #minetest-dev |
| 21:35 |
|
jin_xi joined #minetest-dev |
| 21:43 |
|
ElectronLibre left #minetest-dev |
| 21:55 |
sofar |
well, you could pack 2^21 three times in 64 bit |
| 21:55 |
sofar |
giving you a 4mln sized cube |
| 22:01 |
ZeraRoox |
+hmmmm u there? |
| 22:05 |
|
Wayward_One joined #minetest-dev |
| 22:34 |
|
est31 joined #minetest-dev |
| 22:39 |
|
Tablet_One joined #minetest-dev |
| 23:05 |
|
paramat joined #minetest-dev |
| 23:07 |
paramat |
> making the limits higher is a gigantic waste of time and effort < this |
| 23:42 |
|
paramat left #minetest-dev |
| 23:47 |
|
Wayward_One joined #minetest-dev |
| 23:50 |
VanessaE |
marketing. |
| 23:50 |
VanessaE |
map size is a function of marketing, not necessarily whether it's practical to actually *explore and build* that far away |
| 23:51 |
VanessaE |
er not a function of, wrong word. meh, you know what I meant to say |
| 23:53 |
VanessaE |
every checkmark you can put in your column that says your product is better than your competitor is a point you can bring up when trying to "sell" your product (regardless of whether money has to change hands). |
