| Time |
Nick |
Message |
| 00:13 |
|
crazyR joined #minetest-dev |
| 00:13 |
|
sapier left #minetest-dev |
| 00:43 |
Megaf |
hm, I think minetest in full screen when 1920x1080 its just actually 1080i, and not 1080p |
| 00:43 |
Megaf |
yep |
| 00:44 |
Megaf |
its 1080i |
| 00:44 |
Megaf |
why? |
| 00:44 |
Megaf |
^ PilzAdam ShadowNinja |
| 00:44 |
Megaf |
minetest 1920x1080 fullscreen is actually 1080i |
| 00:45 |
PilzAdam |
what is 1080i ? |
| 00:46 |
Megaf |
minetest in fullscreen |
| 00:46 |
PilzAdam |
"1080i and 1080p are both High Definition display formats for HDTVs. 1080i and 1080p signals actually contain the same information. Both 1080i and 1080p represent a 1920x1080 pixel resolution (1,920 pixels across the screen by 1,080 pixels down the screen). The difference between 1080i and 1080p is in the way the signal is sent from a source component or displayed on an HDTV screen." |
| 00:48 |
proller__ |
i = interlaced = 30fps |
| 00:48 |
proller__ |
p = progressive = 60fps |
| 00:48 |
Megaf |
1080i is not actually 1080 lines, is half |
| 00:49 |
Megaf |
720p > 1080i |
| 00:49 |
PilzAdam |
maybe its your video driver? |
| 00:50 |
Megaf |
http://i1.ytimg.com/vi/boF_Zl-nK-A/maxresdefault.jpg |
| 00:50 |
Megaf |
http://aparanjape.files.wordpress.com/2010/03/hd_vs_sd_resolutions.png |
| 00:51 |
Megaf |
here is a good example http://www.brorsoft.com/images/how-to/video-converter/1080i-vs-1080p.gif |
| 01:04 |
|
Taoki joined #minetest-dev |
| 01:05 |
|
deltib joined #minetest-dev |
| 01:56 |
|
aboutGod joined #minetest-dev |
| 02:01 |
|
aboutGod left #minetest-dev |
| 02:02 |
|
jin_xi joined #minetest-dev |
| 02:07 |
|
BrandonReese joined #minetest-dev |
| 05:23 |
|
CraigyDavi_ joined #minetest-dev |
| 05:38 |
|
nore joined #minetest-dev |
| 06:32 |
|
Bhima___ joined #minetest-dev |
| 06:42 |
|
Bhima joined #minetest-dev |
| 06:43 |
|
werwerwer joined #minetest-dev |
| 07:08 |
|
darkrose joined #minetest-dev |
| 07:13 |
|
RealBadAngel joined #minetest-dev |
| 07:33 |
|
deltib joined #minetest-dev |
| 07:49 |
|
Hunterz joined #minetest-dev |
| 08:11 |
|
PenguinDad joined #minetest-dev |
| 08:13 |
|
OldCoder joined #minetest-dev |
| 08:17 |
|
Calinou joined #minetest-dev |
| 08:20 |
|
Bhima joined #minetest-dev |
| 08:46 |
|
deltib joined #minetest-dev |
| 08:53 |
|
Hunterz joined #minetest-dev |
| 08:58 |
|
kaeza joined #minetest-dev |
| 08:59 |
|
SmugLeaf joined #minetest-dev |
| 08:59 |
|
SmugLeaf joined #minetest-dev |
| 09:10 |
|
jin_xi joined #minetest-dev |
| 09:13 |
|
vifino joined #minetest-dev |
| 09:15 |
|
tomreyn joined #minetest-dev |
| 09:20 |
|
rsiska joined #minetest-dev |
| 09:21 |
|
Anchakor_ joined #minetest-dev |
| 09:32 |
|
ImQ009 joined #minetest-dev |
| 09:50 |
CraigyDavi |
Managed to capture a bug caused by 3rd person view, it happens occasionally when just walking around. Did not happen before 3rd person view was introduced. |
| 09:50 |
CraigyDavi |
https://mediacru.sh/cOA83eNE36FV |
| 09:50 |
CraigyDavi |
The player you see near the end is me. |
| 09:51 |
CraigyDavi |
I should not be able to see myself when not using the 3rd person view mode, right? |
| 09:56 |
PenguinDad |
CraigyDavi: are you using the latest build? |
| 09:56 |
CraigyDavi |
Not the latest but a fairly recent one |
| 09:57 |
|
sapier joined #minetest-dev |
| 09:57 |
PenguinDad |
CraigyDavi: which commit id? |
| 10:00 |
CraigyDavi |
https://github.com/minetest/minetest/commit/5b1bd2fb4760e7d6f4a47e59839aa1b52c6c0f7a |
| 10:01 |
CraigyDavi |
Probably should get a more recent one. That is over a month old |
| 10:01 |
sapier |
if I rember correct blockmen said a bug like that was fixed as sideeffect of 3d mode addition |
| 10:02 |
sapier |
so there's reason to believe this is an old bug |
| 10:02 |
CraigyDavi |
it was probably fixed by "Bugfix: make waypoints respect camera offset" or "Fix player:set_animation() in third person view" |
| 10:03 |
sapier |
possible, there have been various changes since your version |
| 10:03 |
|
crazyR joined #minetest-dev |
| 10:03 |
|
deltib joined #minetest-dev |
| 10:04 |
RealBadAngel |
sapier, could you check why sometimes player:hud_add can return the very same id for different elements? |
| 10:05 |
sapier |
yes I can but I don't see a way how I might have caused that ;-) |
| 10:05 |
|
smoke_fumus joined #minetest-dev |
| 10:05 |
RealBadAngel |
it is happening |
| 10:05 |
RealBadAngel |
i do have two mods (UI's waypoints) and 4itemnames mod, both are using hud elements |
| 10:06 |
|
BlockMen joined #minetest-dev |
| 10:06 |
RealBadAngel |
and both call hud_add and getting same id for own elements |
| 10:06 |
sapier |
if (id == (u32)-1) { ?? ... not the bug anyway |
| 10:07 |
RealBadAngel |
also, i found out that putting hud_add calls in minetest_after function, solves the problem |
| 10:09 |
sapier |
sounds like a race condition |
| 10:09 |
RealBadAngel |
yup, statbars were also affected by this |
| 10:10 |
RealBadAngel |
if mods elements were added straightforward, without minetest_after, it caused bars to be overwritten |
| 10:10 |
sapier |
do those mods use different ways to add hud? |
| 10:11 |
RealBadAngel |
no, simple text (or waypoint) |
| 10:11 |
sapier |
no I mean server step, entitiy step something else |
| 10:11 |
RealBadAngel |
one (4itemnames) changes hud at server step |
| 10:12 |
RealBadAngel |
UI changes that on user action (push a button) and loads data on startup (if waypoints were active, restores them) |
| 10:12 |
RealBadAngel |
in UI case restoring had to placed in minetest_after |
| 10:13 |
sapier |
hmm I'll have to check that but seems to be same thread |
| 10:13 |
|
Bhima_ joined #minetest-dev |
| 10:13 |
RealBadAngel |
basically, if not used in minetest after, it is given wrong id |
| 10:13 |
RealBadAngel |
which gets overriden later or something |
| 10:14 |
BlockMen |
or isnt applied at all (without after) |
| 10:14 |
RealBadAngel |
it is applied |
| 10:14 |
RealBadAngel |
i keep getting id=1 for example |
| 10:15 |
RealBadAngel |
and then another mod is getting the very same id |
| 10:15 |
RealBadAngel |
so the first mod assumes 1 is his own and modifies another's mod hud element |
| 10:15 |
|
deltib joined #minetest-dev |
| 10:16 |
sapier |
that code is strange ... it's spread throughout different classes |
| 10:16 |
RealBadAngel |
so, it looks like whatever is done before minetest_after(0.0) gets lost |
| 10:17 |
BlockMen |
sapier, i doubt that the issue CraigyDavi showed here is the same that got fixed now |
| 10:17 |
BlockMen |
because you see the player from front |
| 10:17 |
BlockMen |
with the issue you would see him from back |
| 10:17 |
BlockMen |
it might be something else |
| 10:17 |
CraigyDavi |
It happens from all angles, not just the front |
| 10:17 |
sapier |
maybe a combination of lag and your bug? |
| 10:18 |
BlockMen |
hmm...might explain it then |
| 10:18 |
CraigyDavi |
Sometimes you see the inside of the player, sometimes you see the back, sometimes the front |
| 10:18 |
BlockMen |
CraigyDavi, have you tried with a current git version yet? |
| 10:19 |
CraigyDavi |
I'm using it now, I'll see if the problem is still there |
| 10:19 |
BlockMen |
k |
| 10:21 |
sapier |
RealBadAngel: I'm looking for that bug but I don't understand yet how it's happening, without beeing called from different threads |
| 10:26 |
RealBadAngel |
can minetest_after calls being made from many threads? |
| 10:27 |
RealBadAngel |
or theyre made one by one from just one thread? |
| 10:27 |
sapier |
for what I know everything is done from same thread |
| 10:29 |
RealBadAngel |
hmm, i think i know the reason |
| 10:29 |
sapier |
if that code is supposed to be used from different threads we've got a major issue anyway |
| 10:29 |
RealBadAngel |
builtin statbar.lua clears the hud |
| 10:30 |
sapier |
clears? |
| 10:30 |
RealBadAngel |
line #39 |
| 10:30 |
sapier |
no that's just the statbar local variable |
| 10:31 |
sapier |
not related to the player hud vector |
| 10:32 |
sapier |
change_hud receivces a pointer to a hud element, if that element is removed while still beeing processed ... |
| 10:51 |
|
Jordach joined #minetest-dev |
| 10:51 |
sapier |
oh shit |
| 10:51 |
RealBadAngel |
what? |
| 10:52 |
sapier |
hmmm no wrong idea ... even if add remove packets are lost they arrive in order |
| 10:53 |
sapier |
as long as we send them in order ... |
| 10:53 |
sapier |
which isn't guaranteed if we use it from multiple threads |
| 10:56 |
sapier |
assuming we really use different threads the id mechanism is completely useless |
| 10:56 |
BlockMen |
but it works fine in general |
| 10:56 |
BlockMen |
just at "start" not |
| 10:57 |
sapier |
as hud's ar initialized at "start" chances to mess up are way better there |
| 10:57 |
sapier |
think about following constellation |
| 10:57 |
sapier |
thread A removes hud 1, but is scheduled prior sending that packet |
| 10:58 |
sapier |
thread B adds a new one and is assigned id 1 because that one is now free |
| 10:58 |
RealBadAngel |
issues is not with removing and adding at the same time |
| 10:58 |
RealBadAngel |
we are talkin now adding returns same id |
| 10:58 |
RealBadAngel |
one call is not delayed, second is delayed with minetest.after |
| 10:59 |
sapier |
which codewise means threads manage to get scheduled prior really adding their hud |
| 10:59 |
RealBadAngel |
so definitely nothing to do with threads |
| 10:59 |
|
Bhima___ joined #minetest-dev |
| 10:59 |
RealBadAngel |
something that happens before minetest.after calls resests the id's counter or something like that |
| 10:59 |
sapier |
as of code there's no way to add huds with same id |
| 10:59 |
sapier |
as long as it's run singlethread |
| 11:00 |
BlockMen |
wait, when it does return same id when adding hud element without after, why does it work for buitin then? |
| 11:00 |
BlockMen |
there is no after |
| 11:01 |
RealBadAngel |
propably point is to let builtin do its job, then go with mods hud elements |
| 11:01 |
sapier |
mods are initialized by same thread so there is no concurrency |
| 11:01 |
RealBadAngel |
going to disable now builtin and see if problem is still here |
| 11:02 |
BlockMen |
RealBadAngel, its nothing new, so i guess it will |
| 11:03 |
sapier |
whole hud code isn't thread safe but I don't understand why it'd be necessary for that code |
| 11:05 |
RealBadAngel |
and we have the winner |
| 11:06 |
RealBadAngel |
statbar.lua definitely messes up things |
| 11:06 |
RealBadAngel |
idk how, but it deletes everything |
| 11:07 |
RealBadAngel |
disabling it lets hud_add work properly, no matter delayed or not |
| 11:07 |
sapier |
it's just another way of using it |
| 11:08 |
RealBadAngel |
if it clears everything, no wonder mods can get same id |
| 11:08 |
sapier |
but there's no way to clear everything |
| 11:09 |
RealBadAngel |
mod a is executed first, without delays gets id |
| 11:09 |
RealBadAngel |
then comes statbar, clears it |
| 11:10 |
RealBadAngel |
then another mod delayed |
| 11:10 |
sapier |
what does your mod do? |
| 11:10 |
RealBadAngel |
both mods will get same id on first try to call hud_add |
| 11:10 |
RealBadAngel |
add's hud elements |
| 11:10 |
RealBadAngel |
same as the other one |
| 11:11 |
RealBadAngel |
you can reproduce it easily |
| 11:11 |
sapier |
statbars should already have it's ids and not do any add or remove operation |
| 11:11 |
sapier |
ok give me those mods ;-) |
| 11:11 |
RealBadAngel |
https://github.com/minetest-technic/unified_inventory |
| 11:11 |
RealBadAngel |
https://github.com/4aiman/4itemnames |
| 11:11 |
RealBadAngel |
enable both mods |
| 11:12 |
RealBadAngel |
within UI, click on waypoints icon and turn some waypoints on |
| 11:13 |
RealBadAngel |
if you enable both mods, UI's waypoints wont work |
| 11:13 |
RealBadAngel |
now clear statbar.lua |
| 11:13 |
RealBadAngel |
and both mods will work as a charm |
| 11:14 |
RealBadAngel |
btw, 4aiman had problems with hud_change not workin properly |
| 11:15 |
RealBadAngel |
no wonder if statbar messed up ids |
| 11:15 |
sapier |
lets see what's really happening first ;-) |
| 11:15 |
sapier |
how do I enable the waypoints? |
| 11:16 |
RealBadAngel |
see buttons on bottom |
| 11:16 |
RealBadAngel |
last one (map) turns on Waypoints tab |
| 11:16 |
sapier |
they miss a tooltip ;-) |
| 11:16 |
sapier |
ok I'm already there |
| 11:16 |
RealBadAngel |
green flag sets the waypoint's pos |
| 11:16 |
sapier |
I added waypoints too how to enable them? |
| 11:16 |
RealBadAngel |
switch next to it, turns it on/off |
| 11:17 |
RealBadAngel |
when switch is green, you should see waypoint in game |
| 11:17 |
sapier |
no ... is this the bug? |
| 11:17 |
RealBadAngel |
yes |
| 11:17 |
RealBadAngel |
now, disable 4aiman's mod |
| 11:18 |
RealBadAngel |
and reload game |
| 11:19 |
sapier |
ok I see one now |
| 11:20 |
RealBadAngel |
now enable 4itemsname again, but clear content of statbar.lua |
| 11:20 |
sapier |
aren't I supposed to see ALL waypoints? |
| 11:21 |
RealBadAngel |
if you turn all on |
| 11:21 |
sapier |
I did |
| 11:21 |
RealBadAngel |
have you set different positions for each one? |
| 11:21 |
sapier |
yes |
| 11:21 |
RealBadAngel |
so you should see them all |
| 11:22 |
sapier |
wait two of them are quite close |
| 11:22 |
sapier |
ok user error |
| 11:26 |
RealBadAngel |
btw, 4itemnames show item name over inventory bar, when you change wielded item |
| 11:26 |
BlockMen |
but if builtin would "clean up" the ids whole time then better hud wouldnt work either |
| 11:26 |
BlockMen |
but it works fine |
| 11:27 |
RealBadAngel |
does better hud use minetest after? |
| 11:27 |
sapier |
I don't think so |
| 11:28 |
BlockMen |
yes |
| 11:28 |
BlockMen |
oh, right |
| 11:28 |
BlockMen |
ups^^ |
| 11:31 |
RealBadAngel |
btw, why when i erase whole statbar.lua code, all the hud elements are still here? |
| 11:31 |
RealBadAngel |
i mean health bar, inv |
| 11:31 |
sapier |
inventory isn't related |
| 11:31 |
RealBadAngel |
what does this code really do? |
| 11:32 |
sapier |
you run into fallback code |
| 11:32 |
sapier |
the one required for old servers |
| 11:33 |
RealBadAngel |
ok |
| 11:33 |
RealBadAngel |
so the old one is ok, new one is used to break mods, cool :) |
| 11:33 |
sapier |
the old one doesn't use luahud |
| 11:33 |
BlockMen |
^ better |
| 11:33 |
sapier |
wrong ... ugly hack |
| 11:33 |
RealBadAngel |
gtg, bbl |
| 11:34 |
sapier |
but that's a different discussion |
| 11:38 |
sapier |
no hud removed RBA? wwaypoints aren't changed but always removed and readded |
| 11:41 |
BlockMen |
^ same for the itemnames mod |
| 11:41 |
sapier |
if huds[pll] then player:hud_remove(huds[pll]) end do you see any code invalidating the hud? |
| 11:42 |
sapier |
this most likely will always clear same hud element, no matter if it was added by it or not |
| 11:43 |
sapier |
I don't find a bug in statbar once fixing 4aimans mod |
| 11:45 |
sapier |
for what I see statbar is only involved as it's another source for huds |
| 11:45 |
sapier |
which could be any other mod too |
| 12:11 |
|
PilzAdam joined #minetest-dev |
| 12:23 |
|
lanxu joined #minetest-dev |
| 12:38 |
sapier |
#1332 ... comments? sorry for the added lines but I had to follow our coding style ;-) |
| 12:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/1332 -- Small cleanup of hud add/remove code by sapier |
| 13:07 |
|
Zeitgeist_ joined #minetest-dev |
| 13:07 |
|
Zeitgeist_ joined #minetest-dev |
| 13:18 |
|
vifino joined #minetest-dev |
| 13:35 |
|
Bhima_ joined #minetest-dev |
| 13:49 |
BlockMen |
sapier, #1333 |
| 13:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/1333 -- Remove useless statbar protection by BlockMen |
| 13:50 |
|
PenguinDad joined #minetest-dev |
| 13:53 |
sapier |
you know my opinion about this, i wrote it down as comment |
| 13:53 |
BlockMen |
ok |
| 14:13 |
|
hmmmm joined #minetest-dev |
| 14:16 |
|
rubenwardy joined #minetest-dev |
| 14:17 |
|
ImQ009 joined #minetest-dev |
| 15:02 |
|
Bhima_ joined #minetest-dev |
| 15:03 |
SoniEx2 |
I think Minetest's Lua 5.1 should be compiled without 5.0 compatibility |
| 15:08 |
|
Bhima__ joined #minetest-dev |
| 15:23 |
|
grrk-bzzt joined #minetest-dev |
| 15:31 |
|
kahrl joined #minetest-dev |
| 15:42 |
|
Megaf joined #minetest-dev |
| 15:45 |
|
Calinou joined #minetest-dev |
| 16:24 |
|
Bhima joined #minetest-dev |
| 16:34 |
|
crazyR_ joined #minetest-dev |
| 16:37 |
|
catninja_ joined #minetest-dev |
| 16:39 |
|
GhostDoge joined #minetest-dev |
| 16:48 |
|
jin_xi joined #minetest-dev |
| 17:10 |
|
arjuna joined #minetest-dev |
| 17:32 |
|
rubenwardy joined #minetest-dev |
| 17:32 |
|
arjuna joined #minetest-dev |
| 17:41 |
ShadowNinja |
sapier: I commented on it. There are also some {s on seperate lines than their statements, but that's less important. |
| 17:42 |
sapier |
I'm writing a suggestion how this should really be done ... yet that variant would break compatibility and therefore is 0.5 ... of course we could add compatibility code to it but doing so would just result in same chaos we already have |
| 17:43 |
|
vifino joined #minetest-dev |
| 17:43 |
|
kaeza joined #minetest-dev |
| 17:43 |
sapier |
basic idea is adding generic stats to any object |
| 17:44 |
sapier |
removing (most of) health as well as breath special handling |
| 17:44 |
sapier |
maybe everything but I'm not that far right now |
| 17:49 |
BlockMen |
ShadowNinja: https://github.com/minetest/minetest/pull/1333#issuecomment-44140918 |
| 17:56 |
sapier |
ShadowNinja you could write a lua coding style specification if you already refer to it ;-) |
| 17:59 |
Exio4 |
what about making a branch and start "don't caring" about about 0.4 compat? |
| 18:00 |
sapier |
not without releasing a "final" 0.4 version |
| 18:00 |
sapier |
at least that's my opinion |
| 18:01 |
sapier |
And to be honest what I'm doing now is a proof of concept to illustrate how a good solution is supposed to be (at least in my oppinion) |
| 18:02 |
sapier |
breaking compat for a improvement that small would be quite crazy |
| 18:02 |
Exio4 |
what i saw in the last weeks (or months) is "nah, don't do that, that would break compat" repeated at least once a day :P |
| 18:02 |
sapier |
the only difference would be "if lag is as big as you can't play any longer at least your statbar will be up to date" |
| 18:03 |
sapier |
everything else is just a nice base for mods to start from |
| 18:04 |
Exio4 |
all the devs should agree to make a last "feature" 0.4 version |
| 18:05 |
sapier |
"all devs should agree" is same as "neverever do this" ;-) |
| 18:05 |
Exio4 |
eh |
| 18:05 |
Exio4 |
i mean, agree about the process |
| 18:06 |
Exio4 |
you alone do it => "sapier thinks minetest is his own project" |
| 18:06 |
BlockMen |
^ proller! |
| 18:06 |
BlockMen |
:D |
| 18:06 |
sapier |
did I ever say it has to be done that way? |
| 18:07 |
Exio4 |
but you, hmmmm, RBA and c55, SN, BM :P |
| 18:07 |
Exio4 |
everything you said that could be done is your fault sapier! |
| 18:07 |
Exio4 |
you're why minetest doesn't have X feature! or why minetest has Y bug! :P |
| 18:08 |
sapier |
I know :-) I'm glad to be the one responsible if that keeps the peace for others ;-) |
| 18:09 |
sapier |
if those requesting features did write half the code they suggest mt would improve almost at speed of light ;-) |
| 18:10 |
SoniEx2 |
remove table.getn |
| 18:11 |
|
PenguinDad joined #minetest-dev |
| 18:11 |
SoniEx2 |
either by removing it from table.* at runtime or by compiling Lua without it |
| 18:22 |
|
Zeitgeist_ joined #minetest-dev |
| 18:22 |
|
Zeitgeist_ joined #minetest-dev |
| 18:44 |
ShadowNinja |
Comments on #1149? |
| 18:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/1149 -- Add AppData file by davidgumberg |
| 18:48 |
ShadowNinja |
If we break compat I'd like to add some big feature, like reloadable <del>mods</del><ins>plugins</ins>. |
| 18:50 |
sapier |
If you have those 3-6 months to implement it shadow? |
| 18:50 |
ShadowNinja |
Modules would be (re)loadable C++ shared libraries, and mods would just be modufications to the engine. |
| 18:50 |
ShadowNinja |
sapier: Well, the main thing to do is to make register_* unregisterable. |
| 18:50 |
sapier |
btw you're talking about breaking compat to any mod out there not about some small client compat glitches |
| 18:50 |
ShadowNinja |
sapier: Yes. |
| 18:50 |
sapier |
basically forcing any single mod to be rewritten |
| 18:51 |
ShadowNinja |
sapier: I think that reloadable plugins could be done without breaking compat, but it would be uglier. |
| 18:51 |
sapier |
I'm listening |
| 18:51 |
sapier |
how do you think it could be done? |
| 18:51 |
ShadowNinja |
sapier: The hardest part would probably be deregistering items on the clients. |
| 18:52 |
sapier |
that's just a lot of work |
| 18:52 |
sapier |
really hard is how to separate the mods from each other |
| 18:52 |
sapier |
you'd have to detect and deregister dependent mods automaticaly |
| 18:53 |
ShadowNinja |
You would have register_* add a ["plugin"]=minetest.get_current_modname() field to everything registered, and then go through all registration tables looking for the appropriate items on unloading. |
| 18:54 |
ShadowNinja |
I like the way that I implemented reloadable plugins in LuaBot, but something like that would be a major compatability break. |
| 18:54 |
sapier |
ok sounds like a way to go for hard dependencys ... what about soft deps? |
| 18:55 |
sapier |
are you really willing to spend those 3 months of work or are we talking about a hypothetical scenario right now? |
| 18:55 |
ShadowNinja |
sapier: We should probably add a way to check if a plugin is loaded, rather than just minetest.get_modpath. |
| 18:56 |
sapier |
yes but first we need to fix the broken async |
| 18:56 |
ShadowNinja |
sapier: Hypothetical currently. It should be fairly easy to do though. With the exception of updating client's itemdefs, because I don't know much about that part of Minetest. |
| 18:57 |
sapier |
I didn't say it's complicated but it's a lot of work |
| 18:57 |
ShadowNinja |
sapier: Yes. I haven't gotten any further on that. |
| 18:57 |
sapier |
time conduming work |
| 18:57 |
sapier |
-d+s |
| 18:57 |
sapier |
even if you know it getting it right takes time |
| 18:58 |
ShadowNinja |
sapier: Well, since we use make_registration only a few places will have to be changed to add it. |
| 18:58 |
ShadowNinja |
+ a function to go through and remove entries, and a command. |
| 18:58 |
sapier |
and and and ;-) |
| 18:58 |
Megaf |
What does this means? "fdir=2" |
| 18:59 |
ShadowNinja |
Megaf: fdir = FaceDirection. |
| 18:59 |
Megaf |
I got like 7 lines of this |
| 18:59 |
sapier |
even without knowing the details I assume loadable mod support isn't something to be done in parallel and will require a lot of core changes |
| 18:59 |
sapier |
even more then android support |
| 18:59 |
Megaf |
http://paste.debian.net/101733/ |
| 18:59 |
|
zat joined #minetest-dev |
| 19:02 |
ShadowNinja |
sapier: The clean way to do it would be like this: http://pastebin.ubuntu.com/7516674/ |
| 19:03 |
sapier |
to do what? |
| 19:03 |
ShadowNinja |
sapier: We could also namespace textures. Eg, default/dirt.png |
| 19:03 |
ShadowNinja |
sapier: Reloadable plugins. |
| 19:03 |
ShadowNinja |
(mods/modules) |
| 19:03 |
sapier |
wait please write some concept prior starting to implement it |
| 19:03 |
sapier |
this is a task as big as chances your/my/anyone elses first ideas are correct are next to zero |
| 19:04 |
ShadowNinja |
sapier: I haven't started writing it, that's a concept. |
| 19:04 |
sapier |
well if that's supposed to be a concept you've got a long way to go ;-) |
| 19:04 |
ShadowNinja |
sapier: LuaBot ( https://github.com/ShadowNinja/LuaBot ) uses a method like this for it's reloadable plugins. |
| 19:05 |
sapier |
plugin concepts aren't that complicated but still we should try to find a way to implement it to not force moders to rewrite their mods in total but just modify them |
| 19:05 |
sapier |
that's the problem |
| 19:06 |
ShadowNinja |
There should also be a unload function that is called if available. It can return true to signify that the plugin isn't unloadable. |
| 19:06 |
Megaf |
what could cause player timing out? |
| 19:06 |
sapier |
mods taking to much time |
| 19:06 |
sapier |
if a server step increases above client timeout all clients are dropped |
| 19:07 |
ShadowNinja |
sapier: Annother option is a combilition of both, with the old API depreciated and removed after a few releases. |
| 19:07 |
Megaf |
Im not timing out, only players with not fast internet are timing out |
| 19:07 |
sapier |
classical timeout about all packets beeing lost? |
| 19:08 |
Megaf |
16:06:31: ERROR[ConnectionSend]: con(5/1)RunTimeouts(): Peer 580 has timed out. (source=peer->timeout_counter) |
| 19:08 |
Megaf |
16:06:31: ACTION[ServerThread]: kaue123 times out. List of players: Megaf Ricardo |
| 19:08 |
Megaf |
16:08:33: ERROR[ConnectionSend]: con(5/1)RunTimeouts(): Peer 581 has timed out. (source=peer->timeout_counter) |
| 19:08 |
Megaf |
16:08:33: ACTION[ServerThread]: Lander times out. List of players: Megaf Ricardo kaue123 |
| 19:08 |
Megaf |
actually everyone but me are timing out |
| 19:09 |
Megaf |
And i get these messages alone too, without a player actually timing out |
| 19:09 |
Megaf |
16:08:54: ERROR[ConnectionSend]: con(5/1)RunTimeouts(): Peer 583 has timed out. (source=peer->timeout_counter) |
| 19:09 |
ShadowNinja |
Megaf: pastebin please. |
| 19:09 |
Megaf |
http://paste.debian.net/101739/ |
| 19:14 |
|
nyuszika7h left #minetest-dev |
| 19:17 |
|
Zeitgeist_ joined #minetest-dev |
| 19:17 |
Megaf |
It's also really hard to teleport those players |
| 19:17 |
Megaf |
and when they die, they spawn where they died |
| 19:27 |
Megaf |
ok, not everyone timing out |
| 19:30 |
sapier |
well spawn location issue is something completely different |
| 19:30 |
Megaf |
You are wrong |
| 19:30 |
sapier |
that happens for me too |
| 19:30 |
sapier |
not always but sometimes |
| 19:31 |
Megaf |
wrong spawn location + problems teleporting + timeout = all network issues |
| 19:31 |
Megaf |
client and server having trouble speaking to each other |
| 19:32 |
sapier |
just because I'm the only one fixing bugs claiming everything to be a network issue wont help |
| 19:32 |
sapier |
;-) |
| 19:32 |
Megaf |
i don't know whos fixing it |
| 19:33 |
sapier |
btw peer timeout after 2 minutest of not receiving anything from that client is perfectly ok |
| 19:33 |
sapier |
are those clients current ones or some old buggy ones? |
| 19:33 |
Megaf |
I believe those clients have poor internet connections or may be using outdated clients |
| 19:34 |
sapier |
then make them use recent clients in first step and see if this helps, we can't fix client side bugs causing client not to send any data on server |
| 19:34 |
Megaf |
so, I think there's nothing we can do about |
| 19:35 |
sapier |
the only difference to before is those clients have been dropped silently in old code |
| 19:39 |
sapier |
the spawn location thingy is a bug ... but it's not server/client communication as the position is done server side only |
| 19:40 |
sapier |
teleporting ... no idea, but if a client isn't initialized properly due to already timing out that might be the result |
| 19:40 |
sapier |
and timeout ... if there's really a slow connection and old clients that might be the reason for this one |
| 19:40 |
sapier |
later two issues are hard to impossible to fix on server side |
| 19:45 |
Megaf |
sapier, I can see no way of improving that without creating overhead |
| 19:45 |
sapier |
improve what? |
| 19:45 |
Megaf |
timeouts] |
| 19:46 |
Megaf |
that could be prevented |
| 19:46 |
sapier |
how is it supposed to be prevented? we already send pins |
| 19:46 |
sapier |
pings |
| 19:46 |
Megaf |
being passive, not sending pings |
| 19:46 |
Megaf |
but not a good idea |
| 19:46 |
sapier |
that's not an option as you'd not have a way to remove clients |
| 19:47 |
sapier |
dead clients |
| 19:49 |
sapier |
in case those clients state machine is messed up they most likely wont answer no matter if we wait 60 600 or 6000 seconds |
| 19:56 |
|
arjuna joined #minetest-dev |
| 19:58 |
|
ImQ009 joined #minetest-dev |
| 20:11 |
* VanessaE |
peeks in |
| 20:22 |
Megaf |
sapier; Just confirmed, there was 3 players having issues |
| 20:22 |
Megaf |
other players are fine |
| 20:22 |
Megaf |
no timeouts at all |
| 20:23 |
sapier |
ok now we'd have to find out what clients those 3 players have been using |
| 20:25 |
|
deltib joined #minetest-dev |
| 20:25 |
|
BlockMen left #minetest-dev |
| 20:55 |
|
Taoki joined #minetest-dev |
| 21:41 |
|
deltib joined #minetest-dev |
| 22:24 |
sapier |
#1335 comments on this? worth continuing and adding stats for lua entities too or drop it? |
| 22:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/1335 -- WIP replace hp/breath by generic stat mechanism by sapier |
| 22:25 |
sapier |
proller you don't even have to answer the last question I already know your answer |
| 22:33 |
VanessaE |
how does this affect old clients if they connect to a server so-patched? |
| 22:33 |
sapier |
they won't have any statbar |
| 22:33 |
VanessaE |
ok, that's a big no, then. |
| 22:34 |
sapier |
that's why I suggest not to add it as is |
| 22:34 |
sapier |
it's an improvement for a 0.5 release |
| 22:34 |
VanessaE |
you should mention that in the "compatibility" line |
| 22:34 |
sapier |
basicaly a showcase how I believe stats should be implemented in a clean way |
| 22:34 |
VanessaE |
fair enough |
| 22:35 |
sapier |
open for suggestions and improvement till it's added or not added by 0.5 |
| 22:36 |
sapier |
maybe it's possible to add compatibility code, but I'm not sure if it'd result in crazy code |
| 22:37 |
VanessaE |
well of course I suppose I should clarify, by "old" client, I mean one that has C++ statbars and doesn't support HUD |
| 22:37 |
sapier |
and to be honest this thing wont give a lot of benefit as long as we don't have client side lua |
| 22:37 |
VanessaE |
anything that supports HUD surely would work fine with an appropriately-coded game on the server. |
| 22:38 |
sapier |
partial |
| 22:39 |
sapier |
starting from lua hud support a game could at least add some sort of statbar |
| 22:39 |
sapier |
16x16 px |
| 22:39 |
sapier |
scaling with texture pack ... so not a really good way |
| 22:40 |
sapier |
I'll check if it's possible to make it compatible but if it's more then 500 lines of code I don't really think it's worth it |
| 22:42 |
|
sapier left #minetest-dev |
| 22:49 |
ShadowNinja |
Commented. |
| 23:22 |
RealBadAngel |
sapier, imho definitely worth continuing. especially for lua entities |
| 23:38 |
VanessaE |
RealBadAngel: you have messages waiting. |
