| Time |
Nick |
Message |
| 00:01 |
|
shadowzone joined #minetest-dev |
| 00:31 |
|
Megaf joined #minetest-dev |
| 00:36 |
|
shadowzone joined #minetest-dev |
| 00:36 |
|
Megaf joined #minetest-dev |
| 00:44 |
|
Megaf joined #minetest-dev |
| 00:48 |
|
ShadowLadyXD joined #minetest-dev |
| 01:11 |
|
Megaf joined #minetest-dev |
| 01:25 |
|
shadowzone joined #minetest-dev |
| 01:38 |
|
chchjesus joined #minetest-dev |
| 01:40 |
|
Megaf joined #minetest-dev |
| 01:44 |
|
sapier1 joined #minetest-dev |
| 01:46 |
|
sapier1 left #minetest-dev |
| 01:46 |
|
Megaf joined #minetest-dev |
| 01:57 |
|
Taoki joined #minetest-dev |
| 02:13 |
|
Megaf joined #minetest-dev |
| 02:21 |
|
Megaf joined #minetest-dev |
| 02:22 |
|
shadowzone joined #minetest-dev |
| 02:27 |
|
Megaf joined #minetest-dev |
| 03:01 |
|
NakedFury joined #minetest-dev |
| 03:12 |
|
cg72 joined #minetest-dev |
| 03:53 |
Fritigern |
RealBadAngel: A little earlier, i experienced a server crash, and waypoints was blamed: ERROR: An unhandled exception occurred: ...lds/Pacata/worldmods/unified_inventory/waypoints.lua:42: attempt to index field '?' (a nil value) |
| 04:26 |
|
chchjesus joined #minetest-dev |
| 04:30 |
|
Megaf joined #minetest-dev |
| 05:04 |
|
Megaf joined #minetest-dev |
| 05:04 |
|
Megaf joined #minetest-dev |
| 05:21 |
|
selat joined #minetest-dev |
| 05:25 |
|
Megaf joined #minetest-dev |
| 05:31 |
|
sol_invictus joined #minetest-dev |
| 06:04 |
|
Megaf joined #minetest-dev |
| 06:07 |
|
Megaf joined #minetest-dev |
| 06:15 |
|
andre_pl joined #minetest-dev |
| 06:39 |
|
werwerwer joined #minetest-dev |
| 06:49 |
|
darkrose joined #minetest-dev |
| 07:23 |
|
Megaf_ joined #minetest-dev |
| 07:28 |
|
nore joined #minetest-dev |
| 07:45 |
|
gravgun joined #minetest-dev |
| 07:47 |
|
andre_pl joined #minetest-dev |
| 08:10 |
|
Calinou joined #minetest-dev |
| 08:17 |
Calinou |
what about making a news on forum about meshnodes? |
| 08:18 |
Calinou |
and other recent developments for 0.4.11 |
| 08:19 |
|
khonkhortisan joined #minetest-dev |
| 08:24 |
VanessaE |
good idea |
| 08:26 |
* VanessaE |
wanders off to bed |
| 08:26 |
Calinou |
I can do it, but I would rather get approval of developers first |
| 08:40 |
|
kilbith joined #minetest-dev |
| 08:40 |
|
Hunterz joined #minetest-dev |
| 08:45 |
|
shmanceloticus joined #minetest-dev |
| 08:52 |
|
Amaz joined #minetest-dev |
| 08:58 |
|
AnotherBrick joined #minetest-dev |
| 09:08 |
|
casimir joined #minetest-dev |
| 09:42 |
Calinou |
nore, <Calinou> what about making a news on forum about meshnodes? / <Calinou> and other recent developments for 0.4.11 |
| 09:42 |
nore |
well, good idea |
| 09:43 |
nore |
you should ask RBA if he wants to make one (since he coded them), and if not, make the announcement yourself |
| 09:44 |
Calinou |
RealBadAngel is away |
| 09:45 |
Calinou |
(visibly) |
| 09:57 |
RealBadAngel |
good idea |
| 09:57 |
* RealBadAngel |
just woke up |
| 10:04 |
Calinou |
I started writing one, RealBadAngel |
| 10:04 |
Calinou |
hi :) |
| 10:08 |
RealBadAngel |
hi |
| 10:09 |
RealBadAngel |
you could point to VE's mesh primitives |
| 10:09 |
Calinou |
also More Blocks slope branch |
| 10:10 |
Calinou |
I made a screenshot of slopes |
| 10:11 |
|
ImQ009 joined #minetest-dev |
| 10:14 |
Calinou |
https://forum.minetest.net/viewtopic.php?f=18&t=10621 |
| 10:14 |
Calinou |
here it is, RealBadAngel |
| 10:15 |
Calinou |
will add screenshot of key change menu… |
| 10:16 |
RealBadAngel |
seems ok. you can mention also node highlighting |
| 10:18 |
kilbith |
Calinou: optimize your screenies a bit by cutting the interesting part |
| 10:18 |
Calinou |
RealBadAngel, already done in another older post… |
| 10:19 |
gravgun |
RealBadAngel, still working on VGA signs? |
| 10:19 |
Calinou |
https://cdn.mediacru.sh/1Ez_uPVzHVt8.png |
| 10:19 |
Calinou |
cropped screenshot |
| 10:19 |
kilbith |
better |
| 10:20 |
gravgun |
Calinou: progressive PNG please? |
| 10:20 |
kilbith |
also, sphere and rounded-corners things |
| 10:20 |
Calinou |
I don't bother with that, didn't bother using OptiPNG either |
| 10:20 |
RealBadAngel |
gravgun, atm im polishing extruded plantlike drawtype |
| 10:20 |
RealBadAngel |
signs and displays gonna be next |
| 10:20 |
gravgun |
Uses same extrusion as weild item? |
| 10:22 |
Calinou |
made some more screenshots |
| 10:23 |
kilbith |
show in evidence that they're 6d facedir |
| 10:23 |
Calinou |
also adding new chest/furnace textures |
| 10:24 |
kilbith |
don't need to show the game's stuff |
| 10:26 |
kilbith |
ah, and do not forget mgv5 |
| 10:27 |
Calinou |
game stuff is also useful |
| 10:28 |
Calinou |
will add mgv5 |
| 10:32 |
RealBadAngel |
gravgun, http://i.imgur.com/SqAVIcb.png |
| 10:33 |
gravgun |
yep i saw that yesterday ( http://i.imgur.com/GYVEWmK.png ) |
| 10:33 |
|
jin_xi joined #minetest-dev |
| 10:38 |
|
zat joined #minetest-dev |
| 10:38 |
Calinou |
RealBadAngel, do you have a screenshot of wielditem using shaders? |
| 10:38 |
Calinou |
heh, nice 3D plantlike |
| 10:38 |
Calinou |
would be a good addition |
| 10:38 |
RealBadAngel |
i think i will be rdy with it today |
| 10:39 |
RealBadAngel |
Calinou, http://i.imgur.com/TPuGWyJ.png |
| 10:39 |
Calinou |
thanks |
| 10:43 |
nore |
VanessaE, Sokomine, ShadowNinja: about the "don't place node where you are" thing: the current version is bugged with full nodes too: if you are close enough to the border of the node, you can place one, but then you will be able to move inside it because you will be partially in it |
| 10:54 |
Calinou |
https://github.com/minetest/minetest/commit/b994a7af130cb8219fc0c546454317cb105c7322 |
| 10:54 |
Calinou |
is this usable in mods? |
| 11:00 |
nore |
Calinou, IIRC yappy uses it |
| 11:00 |
Calinou |
OK |
| 11:04 |
nore |
just checked, it can: https://github.com/minetest/minetest/blob/874109c5201c3deed49bc9eb98352e816c271d50/doc/lua_api.txt#L2809 |
| 11:05 |
Calinou |
thanks |
| 11:05 |
Calinou |
will point to it in newspost |
| 11:07 |
nore |
you should perhaps split the topic in three topic: user engine changes, user game changes, and dev/modder changes |
| 11:07 |
nore |
perhaps you could merge the node highlighting topic too |
| 11:12 |
|
werwerwer joined #minetest-dev |
| 11:34 |
|
rubenwardy joined #minetest-dev |
| 11:37 |
|
CraigyDavi joined #minetest-dev |
| 12:04 |
|
sapier joined #minetest-dev |
| 12:05 |
sapier |
hello, when did we start to mixup declaration and implementation AGAIN ... ? |
| 12:06 |
sapier |
I'm talking about class game ... |
| 12:07 |
|
PenguinDad joined #minetest-dev |
| 12:09 |
sapier |
I guess someone did ignore that issue in favour of merging that doubtless good improvement. Yet there's a bad taste merging incomplete work. Especially if that incompleteness is exactly in the area what the patch improoves. |
| 12:48 |
|
MinetestForFun joined #minetest-dev |
| 12:57 |
|
ImQ009 joined #minetest-dev |
| 12:59 |
|
Amaz joined #minetest-dev |
| 13:27 |
|
kaeza joined #minetest-dev |
| 13:52 |
|
RealBadAngel joined #minetest-dev |
| 13:55 |
RealBadAngel |
https://www.youtube.com/watch?v=hGv6k3-2D3s&feature=youtu.be |
| 13:56 |
|
nore joined #minetest-dev |
| 13:56 |
RealBadAngel |
how do you like that? |
| 13:58 |
|
Megaf joined #minetest-dev |
| 13:59 |
kilbith |
RealBadAngel: awesome; i'd like to see the torch on a wall |
| 13:59 |
RealBadAngel |
not yet done ;) |
| 14:00 |
|
hmmmm joined #minetest-dev |
| 14:00 |
sapier |
hmmm ... shouldn't this be done with particles? |
| 14:01 |
|
shadowzone joined #minetest-dev |
| 14:01 |
PenguinDad |
sapier: what does this have to do with particles? |
| 14:02 |
RealBadAngel |
sapier it works with default textures |
| 14:02 |
sapier |
torches? |
| 14:02 |
RealBadAngel |
yes |
| 14:02 |
sapier |
torches <-> particles ... thought the relation is obvious ;-) |
| 14:02 |
RealBadAngel |
it works with any animated textures in fact |
| 14:03 |
RealBadAngel |
theres no problem to code torch with particles on the other hand |
| 14:03 |
kilbith |
#1700 |
| 14:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/1700 -- wip irrlicht particles by obneq |
| 14:04 |
sapier |
ohhh ... I see it's about animated textures in general and not about torches |
| 14:05 |
RealBadAngel |
well, its about extruded meshes |
| 14:06 |
RealBadAngel |
thx to them you can have 3d torches without breakin compability with old solutions |
| 14:07 |
sapier |
looks like something quite cpu intensive? |
| 14:08 |
RealBadAngel |
GPU rather |
| 14:08 |
sapier |
hmm well guess we have a lot of unused gpu power within minetest. I'm sure you did implement a fallback for slow devices? |
| 14:08 |
RealBadAngel |
there are just more polygons, animation is made as before |
| 14:09 |
RealBadAngel |
sapier, i will make those an option, like we did with fancy leaves |
| 14:10 |
sapier |
that's what I meant ;-) |
| 14:10 |
sapier |
thinking about the number of torches usually used that could result in a quite noticable slowdown on old/slow machines |
| 14:11 |
RealBadAngel |
https://www.youtube.com/watch?v=F7LcggphDeA&feature=youtu.be |
| 14:11 |
sapier |
falling.lua is broken |
| 14:12 |
PenguinDad |
sapier: falling nodes seem to work for me |
| 14:12 |
RealBadAngel |
on the 2nd vid you can see that it works with any textures, so doesnt break texture packs |
| 14:13 |
sapier |
there's a warning in it, built in lua code has to be free of warnings |
| 14:14 |
PenguinDad |
minetest_game has less warnings than builtin :D |
| 14:14 |
sapier |
wtf ... shadowninja I'm quite sure you did forbid me to add warnings spaming the console with same message over and over again. Am I right you did add the global variable access spaming warining? |
| 14:15 |
sapier |
especially as that warning is stupid, checking for a global variable to exist is not supposed to be an error! |
| 14:22 |
sapier |
btw did anyone benchmark that lua wrappers shadowninja added? checking each variable access with a lot of additional code looks like huge performance killer to me |
| 14:30 |
sapier |
ShadowNinja IMHO your strict module should only be used in debug builds. Unless you can explain to me how this is not supposed to cause performance issues for mods accessing global namespace |
| 14:31 |
sapier |
e.g. mods consisting of libraries used by other mods like mobf. |
| 14:32 |
PenguinDad |
sapier: imho this shouldn't depend on the build type but should rather be a setting in minetest.conf |
| 14:33 |
sapier |
well I'd be fine with this too as long as it's disabled in release builds |
| 14:34 |
sapier |
it's silly to cause speed penalty for legitimate mods just because they don't fit ShadowNinja's personal crusade for redefining mods to be plugins |
| 14:36 |
kaeza |
sapier, what happens if I access a global `foo` in `a.lua`, and the same-named `foo` in `b.lua` ? |
| 14:37 |
sapier |
then you still have a warning and if you really care about it you will fix it |
| 14:37 |
kaeza |
as I see, one or the other access is just ignored |
| 14:37 |
kaeza |
wouldn't it be better to warn once per line? |
| 14:37 |
sapier |
the current way of doing it writes 100mb of logs withing minutes just because a mod does if variable then |
| 14:38 |
sapier |
well kaeza you're free to implement it in a better way ;-) my only requirement is it won't write gigabytes of log files for existing mods without any sane reason |
| 14:39 |
sapier |
As I've seen ShadowNinja did suggest a solution which still breaks existing mods so it's useless |
| 14:40 |
kaeza |
yes, this is a bit better, but hides extra accesses, making the feature worse as much |
| 14:41 |
sapier |
It doesn't hide anything compared to last stable version but fixes a huge bug for existing mods. |
| 14:43 |
sapier |
that feature is already doubtfull as I don't believe that getting debuginfo checking names and and and is done in no time so each variable access is way more slow then before |
| 14:43 |
sapier |
any mod adding functions to global namespace is quite heavyly affected by a stupid thing like that |
| 14:44 |
sapier |
imho that's a debug feature not something to be active in production |
| 14:45 |
sapier |
https://github.com/minetest/minetest/pull/1561 fixed review comments as well as added zeframs font fixes. |
| 14:46 |
sapier |
That pull has two main benefits, on android devices we can handle different dpi and screensizes way better then now, and of course upcoming 4k displays are supported too. |
| 14:47 |
sapier |
In case there aren't any reasonable objections I'm gonna merge 1561 in about a week |
| 14:50 |
sapier |
kaeza, you're free to change the alreadywarned to check the triple name, function line. It's most likely already to slow for production so making it even slower wont cause additional problems |
| 15:01 |
kaeza |
sapier, https://github.com/kaeza/minetest/commit/a139924fd9645f1fd5079dda170b28c91c0e49a0 |
| 15:01 |
kaeza |
it won't be slow if mods declare variables properly |
| 15:02 |
sapier |
it will be slow |
| 15:02 |
sapier |
following legit scenario |
| 15:02 |
sapier |
two mods |
| 15:02 |
sapier |
one defining a global variable |
| 15:02 |
sapier |
another one having that mod as optional dependency |
| 15:03 |
sapier |
obviously second mod has to check that variable prior using it, but if the optinal mod isn't present .... |
| 15:03 |
kaeza |
>it won't be slow if mods declare variables properly |
| 15:03 |
sapier |
and no matter if mods declare variables or not the code checking them to be declared will be run anyway |
| 15:03 |
kaeza |
Lua does not call __[new]index at all if the value of the global is not nil |
| 15:04 |
sapier |
unction meta:__index(name) is called on any access |
| 15:06 |
sapier |
as I said no matter what code you add the original one is already way to slow for production. Your changes seem to be reasonable |
| 15:06 |
sapier |
let me check if they work in practice |
| 15:08 |
sapier |
seems to be fine, merge it |
| 15:08 |
kaeza |
>unction meta:__index(name) is called on any access |
| 15:09 |
kaeza |
http://codepad.org/UEiUDer8 disagrees |
| 15:09 |
sapier |
sorry but I've seen hundreds of megabytes of warnings if that one ain't called on any access that'd make no sense |
| 15:10 |
|
PenguinDad joined #minetest-dev |
| 15:10 |
|
rubenwardy joined #minetest-dev |
| 15:11 |
sapier |
unless it's only called on accessing nil set parameters ... which still might be a legitimate usecase |
| 15:11 |
sapier |
try a=nil |
| 15:12 |
kaeza |
<kaeza> Lua does not call __[new]index at all if the value of the global is not nil |
| 15:12 |
kaeza |
nil may be a valid value, but most of the time it isn't (at least for globals) |
| 15:12 |
sapier |
ok so declaring that variable doesn't help anything to remove the speed penalty ;-) |
| 15:13 |
sapier |
as I said kaeza as long as you have a single mod only your assumptions are correct. once you have multiple mods with optional dependencys they get wrong |
| 15:14 |
kaeza |
in fact, __newindex specifically isn't called once a variable is assigned (even nil) |
| 15:14 |
sapier |
setmetatable(_G, {__index = function(t,k) |
| 15:14 |
sapier |
print(k) |
| 15:14 |
sapier |
end}) |
| 15:14 |
sapier |
a=nil |
| 15:14 |
sapier |
print(a) |
| 15:14 |
sapier |
print(b) |
| 15:14 |
sapier |
it is called |
| 15:15 |
sapier |
at least on lua 5.1.5 |
| 15:17 |
sapier |
still there ain't any benefit of that code for production. The only reason for it is bugging modders to follow some more or leas reasonable mod writing style. Which neither ain't defined anywhere nor does it handle all possible usecases a mod may have |
| 15:17 |
kaeza |
hmm, this is weird... I recall reading that __newindex is called only for new keys... |
| 15:18 |
kaeza |
but in any case, this would probably be made a config option (mod_debugmode or something) |
| 15:18 |
sapier |
well maybe an error in doc, still your simple example shows that only setting it to some value stops the code from beeing executed |
| 15:19 |
sapier |
for what I remember we already have some debug options which are only enabled in debug mode. Why add another way of enabling debug features? |
| 15:19 |
kaeza |
we do? |
| 15:19 |
sapier |
to be more precise we have settings set to different values in debug mode then in production |
| 15:20 |
sapier |
deprecated_lua_api_handling show_debug |
| 15:20 |
sapier |
IMHO strict should be handled same way |
| 15:21 |
sapier |
it's a helpfull feature without doubt, but there are limitations where it's causing false positives |
| 15:21 |
kaeza |
I see, that is probably best; the end user does not give a crap about these kinds of stuff (even though they may lead to obscure bugs) |
| 15:22 |
sapier |
true, but mod authors already have a lot of debugging support that isn't available by default in release build. Most time because it's causing performance penalty even without error beeing there. |
| 15:23 |
sapier |
e.g. the mod profiling code |
| 15:31 |
kaeza |
ah! indeed __newindex is only called for new keys: http://codepad.org/FW6v0FSa |
| 15:32 |
sapier |
what's the news on that code? |
| 15:33 |
sapier |
ahh newindex instead of index |
| 15:34 |
sapier |
still if you set a to nil after declaring it it's called again |
| 15:35 |
kaeza |
I can't think of a use case where a `nil` global would make sense |
| 15:36 |
kaeza |
all globals should probably be set to proper default values on init |
| 15:36 |
kaeza |
I will add an option to disable `strict.lua` anyway, is that OK? |
| 15:37 |
kaeza |
err, not add, but use one of those you mentioned |
| 15:38 |
sapier |
nil is a proper value for something not beeing present ;-) |
| 15:39 |
sapier |
if you expect some other value you have to add load dependencys for mods which don't really have a load dependency |
| 15:40 |
kaeza |
in that case, the "slow" logic is only run once at init, at which point the "slowness" of this particular feature doesn't matter at all |
| 15:40 |
sapier |
no it isn't |
| 15:41 |
sapier |
in worst case it's run hundreds of times per second |
| 15:41 |
kaeza |
eh? |
| 15:41 |
kaeza |
are you checking if a mod is loaded every single step? |
| 15:41 |
sapier |
think about two mods |
| 15:41 |
sapier |
one providing nice to have information to be handled by another mode |
| 15:41 |
sapier |
-e |
| 15:41 |
kaeza |
that is broken code IMHO |
| 15:41 |
sapier |
no it aint |
| 15:41 |
sapier |
the other mod can do it's work without that information too |
| 15:42 |
sapier |
but if that information is present it's taken into account |
| 15:42 |
sapier |
of course the second mod has to check if that information is nil prior doing calculations to it |
| 15:42 |
kaeza |
and why is that information global and not namespaced (at which point the code isn't touched at all)? |
| 15:43 |
sapier |
that information will always be global no matter what you do |
| 15:43 |
kaeza |
again, broken code |
| 15:43 |
sapier |
differen't mods don't have a common namespace |
| 15:43 |
sapier |
not broken code |
| 15:43 |
kaeza |
mod_namespace = { } |
| 15:43 |
kaeza |
mod_namespace.some_info = "asdf" |
| 15:43 |
sapier |
different mods shouldn't mess up a common namespace |
| 15:44 |
sapier |
and again, you add a load order dependency by doing that |
| 15:44 |
PenguinDad |
sapier: with #1561 the font in the inventory is much bigger than it used to be https://cdn.mediacru.sh/JpWmcREuvlor.png |
| 15:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/1561 -- Implement proper font handling by sapier |
| 15:45 |
|
Jeija joined #minetest-dev |
| 15:45 |
sapier |
Not sure if it's an issue PenguinDad it's not a 100% identical fix, that's impossible for that issue |
| 15:46 |
kaeza |
sapier, I still think you and me are talking about completely different things, or you are blowing this so-called "slowness" out of proportion |
| 15:47 |
sapier |
no I'm not kaeza, mobf does a lot of things multiple times per server step and there are situations where optional mods are handled |
| 15:48 |
kaeza |
sapier, in that case, fix mobf, and store the "the optional mod was found" either in a local, or into the `mobf` namespace |
| 15:48 |
sapier |
goddamn checking a variable for existance is a legit usecase no matter if this dosn't fit in your mind |
| 15:50 |
kaeza |
alright, this discussion is going nowhere, and I'm not going to repeat things again, so ignore I said anything |
| 15:52 |
sapier |
True if you insist in forcing everyone to write mods the way you feel they should be written without accepting legitimate usecases we won't get anywhere |
| 15:56 |
VanessaE |
kaeza: the issue in this particular case is that the possibly-undefined variable (as supplied by the hypothetical optional dependency) will, on globalstep, change its value frequently, so it's impossible to local-cache it in the mod that's using it. |
| 15:56 |
VanessaE |
each time the mod using it reads it, it'll get either nil or a random, changing value, so caching it at init time won't give the changing result that's needed. |
| 15:57 |
VanessaE |
so in this use case, there's no choice at all but to be able to disable the strict module entirely. |
| 15:57 |
sapier |
PenguinDad what screensize do you have? |
| 15:58 |
sapier |
it's supposed to scale with formspec itself so in case you have a huge screen it's gonna be way bigger |
| 15:58 |
VanessaE |
(having a bloated log and the CPU usage that goes with it is unacceptable for a warning of this nature that is impossible to resolve) |
| 15:59 |
sapier |
VanessaE impossible for existing mods. For new ones you can write workarounds. Still updating minetest will cause perfectly fine mods to fail. |
| 16:00 |
VanessaE |
sapier: exactly. |
| 16:00 |
VanessaE |
where "existing mods" == mods that are no longer maintained but which still otherwise work |
| 16:01 |
PenguinDad |
sapier: my screen is 1920x1080 and minetest uses 1920x1041 |
| 16:01 |
sapier |
As I said I like that feature but I don't like it to be enabled by default as it doesn't provide any benefit for regular user |
| 16:01 |
sapier |
PenguinDad: ok that's exactly where you have most impact |
| 16:01 |
sapier |
ok despite of 4k screens |
| 16:02 |
sapier |
the interesting thing is your hud doesn't seem to scale too ... that's more of a concern to me |
| 16:03 |
VanessaE |
now, I can see a simple way to reduce the log bloat for the hundreds-of-warnings case, if not minetest.get_modpath("optional mod") then foo = 0 end at the start (or some other value to foo that's guaranteed to be interpreted as "do nothing" by the calling mod) but that's a hack |
| 16:03 |
VanessaE |
and it still causes at least one warning to be issued |
| 16:04 |
sapier |
ShadowNinja already wrote a pull to workaround this issue he added, so we would have a solution for new mods. But that's not what I'm talking about |
| 16:04 |
VanessaE |
I know. |
| 16:04 |
VanessaE |
just thinking of ways to patch around it as simply as possible to shut the warnings up and cut the log bloat |
| 16:05 |
sapier |
You guys always think about simple mods. But there are way more complex mod(s) having a lot of connections to other mods too. |
| 16:05 |
VanessaE |
oh I know that. |
| 16:06 |
sapier |
And telling authors of complex mods "you just have to write it that and that way" ... with "that and that" changing for each version is causing a lot of hate ;-P |
| 16:06 |
VanessaE |
I agree |
| 16:07 |
kaeza |
no, you are complaining about performance issues. if you need to access globals in performance critical code, you are doing it wrong, and should fix your code |
| 16:07 |
|
Calinou joined #minetest-dev |
| 16:07 |
VanessaE |
kaeza: you can't local-ize a variable that's being read in realtime from another mod, where it's changing periodically. |
| 16:08 |
VanessaE |
especially if "periodically" is on globalstep |
| 16:08 |
kaeza |
globals involve a hashtable lookup, compared to locals which are just a pointer dereference |
| 16:08 |
kaeza |
VanessaE, example? |
| 16:08 |
sapier |
kaeza yes making it even worse to add additional penalty to it |
| 16:09 |
VanessaE |
kaeza: imagine you've got a mod that's scanning the area for number of some special object. it makes its info available in a global variable. |
| 16:10 |
VanessaE |
you depend on that mod to return such results, and you HAVE to have those results in realtime, on globalstep |
| 16:10 |
VanessaE |
you can't call a function |
| 16:10 |
VanessaE |
and you can't import one mod's code into the other |
| 16:10 |
kaeza |
okay |
| 16:10 |
VanessaE |
what's left? |
| 16:11 |
y |
global state is really amazing, it is a hidden effect that is painful to debug, insanely hard to mantain, and is abused |
| 16:11 |
VanessaE |
a global variable to pass the results from the depended-on mod to the other. |
| 16:11 |
sapier |
y true but abuse is how things are regularly done in minetest |
| 16:14 |
VanessaE |
frankly, I don't think there's any way around it that makes everyone happy. strict module has to be disabled by default. modders can always enable it if they want the spam. :) |
| 16:15 |
y |
maybe if modders wanted code that is easy to understand it could make everyone happy |
| 16:15 |
sapier |
we can enable it by default once some time has passed e.g. in 2 or three versions |
| 16:15 |
sapier |
but if we do that now we cause mods to fail that wouldn't fail otherwise |
| 16:19 |
sapier |
and I explicitly include mods where the warning is legitimate but where the bug doesn't cause any harm |
| 16:20 |
sapier |
btw things like that give false positives too: |
| 16:20 |
sapier |
assert(mobf_settings == nil) |
| 16:20 |
sapier |
mobf_settings = {} |
| 16:21 |
sapier |
checking no other mod did abuse your namespace |
| 16:27 |
|
exio4 joined #minetest-dev |
| 16:30 |
|
AnotherBrick joined #minetest-dev |
| 16:35 |
|
nore joined #minetest-dev |
| 16:47 |
Sokomine |
nore: i thought that was due to lag (server needing time to notice the placement of the node and tell the client that the player can't be there). that ought to be no hinderance for #1867 |
| 16:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/1867 -- added enable_build_where_you_stand option by Sokomine |
| 17:10 |
Sokomine |
regarding global namespaces: those debug messages are very helpful for debugging mods and removing errors. but sapier's right as well: only the mod developers can benefit from it. for normal players, it just spams the hard disk with an ever-growing log |
| 17:14 |
|
khonkhortisan joined #minetest-dev |
| 17:54 |
|
GhostDoge joined #minetest-dev |
| 17:56 |
|
Krock joined #minetest-dev |
| 18:09 |
ShadowNinja |
Don't argue a performance difference, the difference will be almost non-existant is you're doing anything remotely sane. Ideally mods namespaces should be in minetest.mods or something and should be created by returning the table. That could be done without breaking anything too, although you'd need hacks or you'd have fragmentation between the global namespaces and the returned ones. |
| 18:10 |
ShadowNinja |
Sokomine: Isn't that setting name a bit long? ;-) |
| 18:10 |
Calinou |
build_on_standing |
| 18:10 |
Calinou |
shorter name |
| 18:10 |
Calinou |
ShadowNinja, while we are talking about namespaces: https://github.com/minetest/minetest/issues/1865 |
| 18:15 |
sapier |
ShadowNinja once you consider mods actually doing things there are sane issues where performance will be harmed by that fix |
| 18:16 |
sapier |
e.g. the dontknowhowoftenmentioned if variable == nil then check |
| 18:21 |
|
rubenwardy joined #minetest-dev |
| 18:30 |
|
shadowzone joined #minetest-dev |
| 18:56 |
Calinou |
https://chocolatey.org/packages/minetest |
| 18:56 |
Calinou |
add on Windows downloads? |
| 18:56 |
Calinou |
looks safe, looked at the .ps1 files |
| 18:56 |
Calinou |
Chocolatey is a Windows package manager that lets you install packages à la “apt†|
| 18:56 |
|
ImQ009 joined #minetest-dev |
| 18:56 |
Calinou |
this could be added on web site |
| 19:01 |
Sokomine |
ShadowNinja: admittedly it's a bit long. we might as well take calinous suggestion. the idea was that the config variable ought to be a "speaking" name. weather that works is hard to predict |
| 19:02 |
Sokomine |
but the important point is that it gets approved of by core devs and merged. it will make a lot of players very happy |
| 19:03 |
PenguinDad |
Sokomine: as soon as that pull gets merged I'll add that option to my minetest.conf ;) |
| 19:04 |
Sokomine |
:-) guess most builders will do that |
| 19:05 |
Krock |
And this prevent for building 'on' the player was just added to make it noob-friendly? |
| 19:05 |
|
kaeza joined #minetest-dev |
| 19:07 |
kaeza |
Krock, right, but you know, something about using spacebar as control |
| 19:07 |
Sokomine |
Krock: as far as i understand it, it was added to prevent another problem. when you did place a node at the position of your head prior to that old pull request, you where able to see through nodes as if you had the nocliip privilege. it was changed so that you can't place nodes at your head (and foot) position anymore; plus the screen gets black if you do and don't have noclip |
| 19:07 |
|
shadowzone joined #minetest-dev |
| 19:08 |
Krock |
Sokomine, ah okay. Thanks for the explanation |
| 19:09 |
|
Jeija joined #minetest-dev |
| 19:10 |
Sokomine |
the "screen now gets black when you put a node at your head position and don't have noclip" is not affected. only the ability to place nodes there. which is important for placing signs and facedir nodes in small corridors or when pillaring up |
| 19:11 |
Krock |
I agree. |
| 19:11 |
* Krock |
just learned, mapblocks are laggier than player animations /offtopic |
| 19:19 |
|
Wayward_One joined #minetest-dev |
| 19:23 |
|
shadowzone joined #minetest-dev |
| 19:46 |
|
Megaf joined #minetest-dev |
| 20:02 |
|
Megaf joined #minetest-dev |
| 20:04 |
ShadowNinja |
Re: megabytes of warnings: You shouldn't have many warnings at all after startup as long as you're not doing something like setting and un-setting globals every step. |
| 20:05 |
ShadowNinja |
At startup there might be 64 or so on heavily modded worlds though. |
| 20:07 |
|
ImQ009 joined #minetest-dev |
| 20:08 |
ShadowNinja |
My most heavily moded world has 20 warnings right now. |
| 20:08 |
sapier |
ShadowNinja I'm just doing a if variable == nil then ... that's causing megabytes of warnings |
| 20:08 |
sapier |
because that check is in a critical path done by any entity in each step at least once |
| 20:08 |
ShadowNinja |
Make that 17, missed some mod startup messages. |
| 20:08 |
ShadowNinja |
sapier: Then fix that code. |
| 20:09 |
ShadowNinja |
Do one check at startup. |
| 20:09 |
sapier |
ShadowNinja thats a useless discussion I can't check a changing variable on startup |
| 20:09 |
ShadowNinja |
If you want cross-mod interaction use callbacks, not globals. |
| 20:10 |
sapier |
And changing the whole architecture wont enable me travelling back in time fixing the last version |
| 20:10 |
kaeza |
eh? |
| 20:10 |
ShadowNinja |
Mods really shouldn't create any globals at all, but I left the strict checks out because it's too floody. |
| 20:10 |
sapier |
thus this change breaks a mod without any benefit for user |
| 20:11 |
Calinou |
mods have legit reasons to create globals |
| 20:11 |
sapier |
ShadowNinja could you ONE TIME read what I am saying |
| 20:11 |
Calinou |
variables being accessed by several mods… constants… |
| 20:11 |
kaeza |
Calinou, wrong; those should be namespaced |
| 20:12 |
sapier |
no they aren't constants calinou |
| 20:12 |
sapier |
And even if all your arguments where valid that doesn't justify breaking exisiting mods |
| 20:13 |
sapier |
what is users benefit of having that warning in production version, tell me ONE SINGLE benefit |
| 20:13 |
sapier |
USER of course! |
| 20:13 |
Calinou |
there is none |
| 20:13 |
Calinou |
so, don't change what is currently done about variables |
| 20:14 |
Calinou |
but you can add a debug option to warn about all globals if you want |
| 20:14 |
Calinou |
off by default |
| 20:14 |
sapier |
Calinou I can't change code which is already published |
| 20:14 |
kaeza |
I already added that to my code locally |
| 20:14 |
sapier |
I can fix it in future versions but this still breaks a lot of servers without any reason to do that |
| 20:15 |
sapier |
I'm pefectly fine with making this an option which is disabled by default or even disabled on release build only and enabled on debug build |
| 20:17 |
ShadowNinja |
sapier: The problem is that the degub build is what developers use, but most modders use release builds. |
| 20:17 |
ShadowNinja |
debug* |
| 20:17 |
Calinou |
make a minetest.conf setting for that then |
| 20:17 |
Calinou |
“There's a minetest.conf setting for that.†—Steve Jobs (2008) |
| 20:18 |
ShadowNinja |
Calinou: constants should be literals or locals. |
| 20:18 |
ShadowNinja |
Calinou: The problem with that is that nobody will enable it. |
| 20:18 |
sapier |
Oh I see when I wanted to add a deprecation warning you did argument you can't flood log for deprecation warnings but once it's you to add deprecation warnings everything is different |
| 20:19 |
Calinou |
I believe serious modders will be aware of it |
| 20:19 |
ShadowNinja |
sapier: I said you can't flood with minetest.env warnings because that's used dozens of times per step. |
| 20:19 |
sapier |
problem ain't that feature isn't helpfull problem is that feature breaks mods that wouln't have any major issues without it |
| 20:19 |
Calinou |
we could maintain a wiki page about deprecations/incompatible changes |
| 20:19 |
Calinou |
make it a sticky in mod releases/wip mods topic |
| 20:20 |
ShadowNinja |
There should be a mod_debug setting that automatically enables things like deprecation warnings. |
| 20:20 |
Calinou |
minetest.env: is the biggest offender |
| 20:20 |
Calinou |
and that |
| 20:20 |
sapier |
and your message is shown <number of mobs>*steps per second too for mobf where's the difference? |
| 20:20 |
ShadowNinja |
Modders have to be aware of it though. |
| 20:20 |
sapier |
at least |
| 20:20 |
Calinou |
if an offense appears once, then warn in console? but only once |
| 20:21 |
Calinou |
eg. on first minetest.env: use, you see “The mod may be deprecated, use mod_debug = true to debug. Ignore this message if you are not a mod developer.†|
| 20:21 |
sapier |
I already fixed most crucial issues for next version but that's not gonna fix last version of mobf |
| 20:21 |
kaeza |
ShadowNinja, sapier, https://github.com/kaeza/minetest/commit/07a4caee4cc03eeab47b220e81b9303e91f51d62 |
| 20:21 |
ShadowNinja |
Calinou: That's doable -- but a issue in one mod would hide issues in other mods, we can't get the modname after init. |
| 20:21 |
kaeza |
(not sure about setting name) |
| 20:21 |
sapier |
And despite of most other modders I support old versions for some time |
| 20:22 |
ShadowNinja |
I might be able to use the debug library to get the source file and only warn once per source file... |
| 20:22 |
sapier |
and of course that "WARNING" is a false positive if a mod checks for namespace collisions too |
| 20:22 |
ShadowNinja |
I can limit by line too. |
| 20:22 |
ShadowNinja |
That would fix the floods. |
| 20:22 |
* ShadowNinja |
inplements. |
| 20:22 |
kaeza |
seriously... |
| 20:22 |
sapier |
ShadowNinja: stop we already did this |
| 20:23 |
sapier |
there's still another issue, calling debug lib that often can't be without performance impact |
| 20:24 |
sapier |
so even if we fixed the logging which causes immediate death with the feature enabled you still cause performance regressions |
| 20:24 |
ShadowNinja |
kaeza: It should be per-file, per-line, and per-name. Simplify it by just joining them with NUL characters. |
| 20:25 |
ShadowNinja |
kaeza: That's pretty much just what I wanted to do though. |
| 20:25 |
kaeza |
do it |
| 20:25 |
kaeza |
I'm not thouching shit anymore |
| 20:25 |
ShadowNinja |
:-( |
| 20:25 |
|
Megaf joined #minetest-dev |
| 20:26 |
RealBadAngel |
http://i.imgur.com/s9c9zLT.png |
| 20:26 |
sapier |
and it should be disabled in release, at least for next minetest version. make a release note that accessing global variables will cause performance issues in future versions so we can enable it in following minetest version |
| 20:27 |
ShadowNinja |
sapier: alreadywarned isn't a word, use underscores. |
| 20:27 |
kilbith |
RealBadAngel: smaller in lenght |
| 20:27 |
kaeza |
fixed in free^W my patch |
| 20:27 |
sapier |
I'm german we have words like donaudampfschiffahrtsgesellschaftskapitänswittwenrente |
| 20:27 |
sapier |
;-P |
| 20:28 |
exio4 |
does that mean "hi how are you?" |
| 20:28 |
sapier |
not exactly it's a noun |
| 20:30 |
sapier |
btw game refactoring was good work :-) |
| 20:30 |
sapier |
we only have to move the class declaration to game.h where it belongs |
| 20:30 |
kaeza |
noooo |
| 20:31 |
sapier |
of course class declarations don't have any reason to be mixed up to code |
| 20:31 |
kaeza |
if you move it there, anything that uses `game.h` gets recompiled whenever it changes |
| 20:31 |
kaeza |
and right now it seems nothing uses class Game anyway |
| 20:31 |
sapier |
I see you always add and remove spaces to game class? ;_P |
| 20:32 |
sapier |
game is a basic class it's not used because noone did cleanup the interfaces by now |
| 20:33 |
kaeza |
still, no point in moving it to .h and extending compilation time more than it is |
| 20:33 |
sapier |
still thats another discussion and I don't intend to do anything there so lets discuss it once it's really relevant |
| 20:34 |
sapier |
https://github.com/minetest/minetest/pull/1561 better check this one |
| 20:35 |
|
Megaf joined #minetest-dev |
| 20:36 |
sapier |
it's not supposed to change a lot of things but should fix some long open font/formspec scaling issues |
| 20:42 |
|
Megaf joined #minetest-dev |
| 20:44 |
|
ImQ009_ joined #minetest-dev |
| 20:46 |
Sokomine |
ShadowNinja: adding/using an option in minetest.conf really seems best for these new warnings. they're very helpful for modders, but useless for normal users who don't have a clue as to why their debug file takes up more and more space |
| 20:46 |
|
ImQ009 joined #minetest-dev |
| 20:47 |
Sokomine |
ShadowNinja: it would be great to have these debug options beeing documented somewhere more prominent. even mod developers may read the example config file once - and occasionally scroll through the changelog - but very few people will be sufficiently up to date |
| 21:00 |
|
Megaf joined #minetest-dev |
| 21:08 |
|
FR^2 joined #minetest-dev |
| 21:17 |
|
NakedFury joined #minetest-dev |
| 21:25 |
|
proller joined #minetest-dev |
| 21:38 |
RealBadAngel |
ok, looks like i finished changing torchlike: https://www.youtube.com/watch?v=SH_mr82khjk |
| 21:43 |
|
proller joined #minetest-dev |
| 21:45 |
RealBadAngel |
how do you like extruded torches? |
| 21:46 |
|
Garmine joined #minetest-dev |
| 21:50 |
|
khonkhortisan joined #minetest-dev |
| 21:54 |
kilbith |
looks good, RBA |
| 21:55 |
|
SmugLeaf joined #minetest-dev |
| 21:57 |
RealBadAngel |
sapier, such torchlike doesnt seem to be much of a problem for fps, http://i.imgur.com/6kkxmnQ.png |
| 22:07 |
|
Garmine42 joined #minetest-dev |
| 22:27 |
ShadowNinja |
proposal: Add mod_debug setting that enables strict.lua and a few other moding-related things like deprecation logging. |
| 22:28 |
ShadowNinja |
Then create a news topic and stress that all moders should have it on. |
| 22:29 |
|
Megaf joined #minetest-dev |
| 22:29 |
|
Megaf joined #minetest-dev |
| 22:31 |
|
werwerwer joined #minetest-dev |
| 22:39 |
|
zat joined #minetest-dev |
| 22:40 |
sapier |
RealBadAngel well if you fill 10l to a olympic swimming pool and then fill another 10l to it there wont be a significant difference too, if you do this to a bucket there will be ;-) |
| 22:40 |
sapier |
you should try this on a slow device already at etch, e.g. a android phone already beeing fps limited |
| 22:42 |
|
Megaf joined #minetest-dev |
| 23:25 |
|
sapier left #minetest-dev |
| 23:27 |
Megaf |
Hi all, do you believe that it is safe to use the dev version of Irrlicht? |
| 23:34 |
|
Megaf joined #minetest-dev |
| 23:39 |
RealBadAngel |
Megaf, no idea |
| 23:51 |
Megaf |
Ok, I will keep using the 1.8.1 then |
| 23:52 |
Megaf |
that moment when you type ls on the address bar of your browser expenting to get a list of the sites you can open |
| 23:55 |
|
chchjesus joined #minetest-dev |
