| Time |
Nick |
Message |
| 01:21 |
|
sgtbigman joined #minetest-dev |
| 03:36 |
|
Hunterz joined #minetest-dev |
| 04:48 |
Sketch2 |
https://www.grc.com |
| 04:55 |
hmmmm |
uhm... yes? |
| 05:26 |
hmmmm |
https://github.com/kwolekr/minetest/commit/c2d23ff9ccf04dd0e4c2ba8a8026857c034bc947 will push in 30 minutes |
| 05:26 |
hmmmm |
ptal if you'd like |
| 05:46 |
|
Hunterz joined #minetest-dev |
| 06:22 |
|
nrzkt joined #minetest-dev |
| 06:39 |
|
nore joined #minetest-dev |
| 06:44 |
OldCoder |
I have been debugging for hours. Is anybody able to explain why mts files placed even in an empty world with just minetest_game might not appear? |
| 06:46 |
hmmmm |
if the schematic file path is absolute, it will use that path. otherwise, the schematic file path is assumed to be relative to the current mod path. |
| 06:47 |
OldCoder |
There are no error messages. The mtschemplace command says placed the mts. However, it does not appear. |
| 06:48 |
OldCoder |
Worked for a 1GB mts file the other day |
| 06:48 |
OldCoder |
However, multiple slightly smaller mts files behave as indicated above |
| 06:49 |
OldCoder |
Issue has actually occurred for a year, with different git-current sources along the way |
| 06:49 |
OldCoder |
Current minetest_game, no other mods but worldedit, and empty world |
| 06:50 |
hmmmm |
dunno, it seems to work for everyone else, maybe they can help debug your problem |
| 06:50 |
OldCoder |
I suspect it does not work for everyone else; i.e., not that many people load large mts files. However, thank you. |
| 06:51 |
OldCoder |
I will confirm this suspicion by seeing if anybody else will try to load specific mts files from the forums. My guess is that nobody has tried to do so for a year but me. |
| 06:51 |
hmmmm |
well, file a bug report and upload the failing schematic somewhere |
| 06:51 |
OldCoder |
Yes; once I have confirmed that the problem occurs for others. |
| 06:55 |
nrzkt |
hmmm: why https://github.com/minetest/minetest/commit/c2d23ff9ccf04dd0e4c2ba8a8026857c034bc947 ? |
| 06:56 |
hmmmm |
because it hasn't been used by anybody for years and it's silently sucking about 2.5 microseconds of execution time |
| 06:56 |
hmmmm |
probably more on other peoples' slower processors |
| 06:57 |
nrzkt |
good :) |
| 06:57 |
hmmmm |
it's not a lot but it adds up when people have these calls inside of loops |
| 06:58 |
nrzkt |
it's right, profiler make game a little bit slow sometimers and should be enabled on debug builds, not release i think |
| 07:00 |
|
leat joined #minetest-dev |
| 07:00 |
|
leat joined #minetest-dev |
| 07:11 |
|
leat joined #minetest-dev |
| 07:21 |
|
nanepiwo joined #minetest-dev |
| 07:28 |
|
nanepiwo joined #minetest-dev |
| 07:35 |
|
nrzkt joined #minetest-dev |
| 07:54 |
|
tuy joined #minetest-dev |
| 08:05 |
|
Yepoleb joined #minetest-dev |
| 08:14 |
|
johnwayne1986 joined #minetest-dev |
| 08:35 |
|
deltib joined #minetest-dev |
| 08:36 |
|
Calinou joined #minetest-dev |
| 08:37 |
|
Ardonel joined #minetest-dev |
| 09:01 |
|
Gael-de-Sailly joined #minetest-dev |
| 09:12 |
|
leat joined #minetest-dev |
| 09:14 |
|
johnwayne1986 joined #minetest-dev |
| 09:27 |
johnwayne1986 |
Hi all! |
| 09:30 |
johnwayne1986 |
When I try the unit tests with the latest commit, the test readF1000(is) == 53.534f at test_serialization.cpp:299 fails. Can somebody confirm this? Is this meaningful? (Just wanted to tell you that I noticed that.) |
| 09:41 |
|
err404 joined #minetest-dev |
| 09:58 |
|
johnwayne1986_ joined #minetest-dev |
| 10:01 |
|
johnwayne1986 joined #minetest-dev |
| 10:04 |
kahrl |
johnwayne1986: the tests pass on my machine |
| 10:04 |
kahrl |
it might depend on the FPU rounding mode or whatever though |
| 10:04 |
johnwayne1986 |
interesting... |
| 10:05 |
kahrl |
the original version of that test was UASSERT(fabs(readF1000(is) - 53.534f) < 0.005); |
| 10:06 |
kahrl |
I wonder why it was changed |
| 10:08 |
kahrl |
the commit message of 42cf5e972d says it should be safe to do an exact comparison, but I don't understand exactly why |
| 10:08 |
kahrl |
hmmmm: ^ |
| 10:15 |
|
Darcidride joined #minetest-dev |
| 10:16 |
johnwayne1986 |
so, I get: f: 53.534, diff: 3.8147e-06 |
| 10:29 |
nanepiwo |
could someone pls reopen #2985 ? |
| 10:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/2985 -- Player's direction of view pitches up slightly when clicking |
| 10:32 |
|
wischi joined #minetest-dev |
| 10:40 |
nore |
nanepiwo: see my comment on #2985 |
| 10:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/2985 -- Player's direction of view pitches up slightly when clicking |
| 10:45 |
|
ElectronLibre joined #minetest-dev |
| 10:48 |
|
Zeitgeist_ joined #minetest-dev |
| 10:49 |
|
err404 joined #minetest-dev |
| 10:50 |
|
AnotherBrick joined #minetest-dev |
| 10:51 |
kahrl |
johnwayne1986: sorry for the delay, had to shower & eat and have to leave now, but just so hmmmm has the info when he comes back: what is your OS/compiler? |
| 11:01 |
johnwayne1986 |
I have to leave as well in a few minutes or so... |
| 11:03 |
johnwayne1986 |
I use LMDE 1, which is outdated and supported with security fixes only. Compiler is g++ 4.8.2. |
| 11:06 |
johnwayne1986 |
If I run 'file minetest' it tells me: minetest: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.32 |
| 11:07 |
johnwayne1986 |
I am running 3.11-2-amd64 though. Is the output 2.6.32 normal? |
| 11:29 |
|
Fritigern joined #minetest-dev |
| 11:44 |
|
sgtbigman joined #minetest-dev |
| 11:50 |
kahrl |
johnwayne1986: the "for GNU/Linux 2.6.32" is from the PT_NOTE section of the executable and the value depends on what --enable-kernel option was given when glibc was built |
| 11:51 |
|
err404 left #minetest-dev |
| 11:54 |
|
TenPlus1 joined #minetest-dev |
| 11:54 |
TenPlus1 |
Hi folks |
| 11:56 |
TenPlus1 |
Question. is gui_scaling in minetest.conf meant to be server specific ?? |
| 11:57 |
|
Gael-de-Sailly joined #minetest-dev |
| 12:00 |
kahrl |
TenPlus1: it's a client setting |
| 12:00 |
nanepiwo |
@tenplus GUI_scaling is client side, for any formspecs (like main menu and in multiplayer servers) |
| 12:01 |
TenPlus1 |
I read the gui_scaling setting and it always reads the server's setting, never the client |
| 12:01 |
TenPlus1 |
so personal scaling for hud always appears at 1.0 |
| 12:03 |
|
proller joined #minetest-dev |
| 12:03 |
TenPlus1 |
am using: local gui_scale = tonumber(minetest.setting_get("gui_scaling")) .. am I doing something wrong ? |
| 12:05 |
|
proller joined #minetest-dev |
| 12:05 |
kahrl |
minetest.setting_get reads serverside settings, yes |
| 12:05 |
kahrl |
client settings are generally not sent to the server |
| 12:05 |
|
Fritigern joined #minetest-dev |
| 12:05 |
TenPlus1 |
so the gui scaling is useless unless you are playing singleplayer |
| 12:06 |
kahrl |
why useless? it's applied to all formspecs automatically |
| 12:06 |
TenPlus1 |
formspec yes, hud display no... |
| 12:07 |
TenPlus1 |
there is no way for a mob to read player gui_scaling to assist in hud output... |
| 12:07 |
TenPlus1 |
*mod |
| 12:07 |
kahrl |
it's not applied to hud? that might be a bug |
| 12:07 |
TenPlus1 |
that's the point though, I want to be able to scale up HUD graphics for HD and 4k screens but cannot access player scaling setting... |
| 12:09 |
kahrl |
well the proper solution would be to apply it to hud in the client, not to do it serverside |
| 12:10 |
TenPlus1 |
not possible if conencting to server... |
| 12:10 |
|
H-H-H joined #minetest-dev |
| 12:10 |
kahrl |
I mean in the C++ code |
| 12:11 |
TenPlus1 |
oh, gotcha... |
| 12:12 |
TenPlus1 |
maybe I could put in a github issue to read it always from client |
| 12:13 |
TenPlus1 |
or have a personal minetest variable for the machine it's run on with scaling number itself |
| 12:14 |
|
proller joined #minetest-dev |
| 12:17 |
RealBadAngel |
agree, only way is to do that client side |
| 12:17 |
RealBadAngel |
server dont need to know actual clients resolution at all |
| 12:17 |
TenPlus1 |
agreed... will post github issue for that one |
| 12:17 |
TenPlus1 |
thanks |
| 12:36 |
|
Calinou joined #minetest-dev |
| 12:37 |
|
SopaXorzTaker joined #minetest-dev |
| 13:06 |
|
srifqi joined #minetest-dev |
| 13:12 |
|
johnwayne1986 joined #minetest-dev |
| 13:22 |
|
Niebieski joined #minetest-dev |
| 13:37 |
|
zupoman joined #minetest-dev |
| 13:37 |
|
zupoman joined #minetest-dev |
| 14:15 |
|
H-H-H joined #minetest-dev |
| 14:35 |
|
Sketch2 joined #minetest-dev |
| 14:37 |
|
VanessaE joined #minetest-dev |
| 14:50 |
|
hmmmm joined #minetest-dev |
| 14:53 |
|
Sketch2 joined #minetest-dev |
| 14:59 |
|
Yepoleb_ joined #minetest-dev |
| 15:06 |
|
Fritigern joined #minetest-dev |
| 15:07 |
|
SopaXorzTaker joined #minetest-dev |
| 15:08 |
|
nrzkt joined #minetest-dev |
| 15:12 |
|
thatgraemeguy joined #minetest-dev |
| 15:30 |
|
damiel joined #minetest-dev |
| 15:37 |
|
paramat joined #minetest-dev |
| 15:41 |
paramat |
RealBadAngel #3073 |
| 15:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/3073 -- tileable_{horizontal,vertical} flags cause fps decrease |
| 15:43 |
paramat |
nore sfan5 game#640 |
| 15:43 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/640 -- Fire: Slow down spread and reduce lua load by paramat |
| 15:45 |
paramat |
perhaps i'll merge game#639 later unless anyone knows a better implementation |
| 15:45 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/639 -- Boats: Fix sinking through boat when detaching, by CProgrammerRU by paramat |
| 15:51 |
kahrl |
why is there special code in the shader to handle tileable_* flags at all? |
| 15:51 |
kahrl |
wouldn't it be enough to set TextureWrapU/TextureWrapV in the material settings? |
| 15:51 |
paramat |
to fix a visual glitch i think? |
| 15:51 |
kahrl |
most likely with no fps drop |
| 15:52 |
kahrl |
the glitch is the same glitch that happened with wield meshes |
| 15:52 |
kahrl |
I think |
| 15:52 |
kahrl |
I fixed that glitch by setting TextureWrapU/TextureWrapV |
| 15:52 |
kahrl |
to video::ETC_CLAMP_TO_EDGE |
| 15:57 |
RealBadAngel |
paramat, i do have fixes for that rdy |
| 15:58 |
paramat |
ok |
| 15:58 |
RealBadAngel |
when we made fsaa fixes it looks like setting uv wrapping was also enough to fix tiling issues |
| 15:59 |
RealBadAngel |
i have already removed that code from shaders |
| 15:59 |
|
Hunterz joined #minetest-dev |
| 15:59 |
RealBadAngel |
sidenote, its weird he noticed slowdown with it |
| 15:59 |
RealBadAngel |
the mechanism is here all the time |
| 16:00 |
RealBadAngel |
anyway, the code in question will be just gone |
| 16:01 |
RealBadAngel |
i will help my wife with the dinner and then prepare PRs with latest stuff |
| 16:01 |
RealBadAngel |
paramat: https://imgrush.com/vxfrNtQojkvy.png |
| 16:02 |
RealBadAngel |
now, tell me what do you think about it when its complete :) |
| 16:03 |
|
Zeitgeist_ joined #minetest-dev |
| 16:03 |
paramat |
crystals look ok themselves but it's certainly for an eye-candy fork |
| 16:09 |
RealBadAngel |
partially youre right, but those are named crystals already |
| 16:10 |
RealBadAngel |
and other hand having quite big number of ores that do actually look the same its not a candy, its eye boring ;) |
| 16:12 |
RealBadAngel |
anyway im lookin on ideas (and conditions to fullfill) to make crystals grow |
| 16:12 |
RealBadAngel |
if any of you have some please let me know |
| 16:24 |
paramat |
in minetest the crystals are (i think) fragments of mese blocks, so crystals growing in these natural-forming shapes is something very different |
| 16:28 |
|
nrzkt joined #minetest-dev |
| 16:30 |
|
Robert_Zenz joined #minetest-dev |
| 16:34 |
|
Krock joined #minetest-dev |
| 16:36 |
hmmmm |
hmm whatever happened to est? |
| 16:36 |
hmmmm |
he dropped off the earth with perfect timing |
| 16:36 |
hmmmm |
the release is basically waiting on him alone :p |
| 16:42 |
paramat |
i have 2 more PRs for game, need perhaps 1 more day |
| 16:46 |
paramat |
also there's the tiling bug mentioned above, RBA possibly has a PR for engine. |
| 16:47 |
hmmmm |
great |
| 16:48 |
hmmmm |
hmm est is active on github but not.. here |
| 16:48 |
hmmmm |
wonder how the inventory replace bug is coming along |
| 16:49 |
RealBadAngel |
im preparing my fixes atm, gimme an hour or two |
| 16:55 |
Krock |
\o/ MSVCRT linking errors |
| 16:56 |
|
MinetestForFun joined #minetest-dev |
| 17:12 |
|
paramat left #minetest-dev |
| 17:22 |
RealBadAngel |
hmmmm, some1 said that est31 will be off for a few days, reason unknown |
| 17:22 |
|
crazyR joined #minetest-dev |
| 17:23 |
|
FR^2 joined #minetest-dev |
| 18:00 |
|
est31 joined #minetest-dev |
| 18:01 |
est31 |
hmmmm, I have said I'll be away for some days |
| 18:02 |
est31 |
but now im back! |
| 18:02 |
est31 |
I'll fix that inventory bug, then we wait for paramat to do the release, |
| 18:02 |
est31 |
then lets hope blockmen does a build |
| 18:04 |
* Krock |
tries to compile |
| 18:09 |
* nrzkt |
thinks est31 should go in holidays another time :D |
| 18:09 |
Krock |
a library uses the /MD comiler flag instad of /MT .. I think a clean build is neccessary :( |
| 18:10 |
est31 |
nrzkt, if we went after original schedule, there would have been no problem |
| 18:10 |
est31 |
now there is neither |
| 18:11 |
* nrzkt |
thinks germans works too much and should work like mexicans |
| 18:18 |
hmmmm |
lol |
| 18:18 |
hmmmm |
isn't there a labor shortage in germany |
| 18:19 |
est31 |
depends on the job I guess |
| 18:20 |
nrzkt |
if you work with a contract without a minimum salary like germans like to decrease their unemployment, you could earn 100$ per month for 40 hours a weak :D |
| 18:20 |
est31 |
also part of it is self caused |
| 18:20 |
nrzkt |
week* |
| 18:20 |
est31 |
we do have minimum wage nrzkt |
| 18:21 |
est31 |
since this year |
| 18:21 |
est31 |
or the year before |
| 18:21 |
est31 |
but the great coalition that took over gvt in 2014 promised minimum salaries |
| 18:21 |
est31 |
was demand of the SPD |
| 18:22 |
est31 |
germandy does have doctor shortage on the countryside |
| 18:23 |
est31 |
many german doctors go to norway or switzerland where they are better paid |
| 18:23 |
est31 |
or just stay inside the cities |
| 18:23 |
* Krock |
misses the swiss german in hospitals... |
| 18:24 |
est31 |
lol |
| 18:26 |
Krock |
est31, win32 build is coming in ~1 min, if interested |
| 18:27 |
* Krock |
slaps himself after noticing the actual release was meant |
| 18:31 |
|
Hunterz joined #minetest-dev |
| 18:48 |
|
Calinou joined #minetest-dev |
| 19:18 |
|
tuy joined #minetest-dev |
| 19:26 |
|
tuy joined #minetest-dev |
| 19:27 |
|
proller joined #minetest-dev |
| 19:49 |
|
rubenwardy joined #minetest-dev |
| 20:03 |
|
Player_2 joined #minetest-dev |
| 20:05 |
|
Gael-de-Sailly joined #minetest-dev |
| 20:09 |
|
Icedream joined #minetest-dev |
| 20:09 |
|
Icedream joined #minetest-dev |
| 20:37 |
|
paramat joined #minetest-dev |
| 20:38 |
|
nrzkt joined #minetest-dev |
| 20:40 |
paramat |
nore sfan5 i'd like to merge game#639 very soon, any objections? also any comments on game#640 ? |
| 20:40 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/639 -- Boats: Fix sinking through boat when detaching, by CProgrammerRU by paramat |
| 20:40 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/640 -- Fire: Slow down spread and reduce lua load by paramat |
| 20:40 |
sfan5 |
639 is fine |
| 20:43 |
paramat |
apart from those there are also 2 PRs coming from RBA then that's everything |
| 20:57 |
|
tuy joined #minetest-dev |
| 21:00 |
|
est31 joined #minetest-dev |
| 21:05 |
|
tuy joined #minetest-dev |
| 21:06 |
|
tuy joined #minetest-dev |
| 21:06 |
|
proller joined #minetest-dev |
| 21:32 |
paramat |
now merging game 639 |
| 21:37 |
paramat |
merge complete |
| 21:38 |
nrzkt |
paramat: you add many empty lines.... |
| 21:40 |
paramat |
yes separating functions with 2 newlines for clarity |
| 22:00 |
rom1504 |
why not 5 newlines |
| 22:01 |
RealBadAngel |
paramat, #3079 |
| 22:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/3079 -- Remove use of engine sent texture tiling flags - theyre no longer needed by RealBadAngel |
| 22:01 |
RealBadAngel |
thats for the engine |
| 22:01 |
est31 |
RealBadAngel, why are they no longer needed now? |
| 22:01 |
est31 |
also is the bug from cheapie still fixed? |
| 22:01 |
est31 |
s/from/reported by/ |
| 22:02 |
RealBadAngel |
theyre no longer needed becaue setting UV clamping in the material is enough |
| 22:03 |
est31 |
is that done by the pr? |
| 22:03 |
RealBadAngel |
kahrl solution for fsaa bug solved also problems with tiling |
| 22:03 |
est31 |
ok |
| 22:03 |
RealBadAngel |
in this pr i removed code that did the same in shaders |
| 22:03 |
est31 |
so are the tiling flags totally unneccessary? |
| 22:04 |
est31 |
or do they serve some purpose? |
| 22:04 |
RealBadAngel |
absolutely no |
| 22:04 |
RealBadAngel |
theyre needed |
| 22:04 |
RealBadAngel |
based on them material is configured |
| 22:05 |
RealBadAngel |
what was not needed is shaders doing it again |
| 22:05 |
est31 |
ok |
| 22:06 |
RealBadAngel |
theres also the code that generates the textures flag - it should also be changed |
| 22:06 |
est31 |
how |
| 22:06 |
est31 |
ah |
| 22:06 |
est31 |
you mean the code that sends the #defines? |
| 22:06 |
est31 |
err |
| 22:06 |
est31 |
the code that generates the texture flags texture?* |
| 22:06 |
RealBadAngel |
no, i mean the code that generates the texture for shaders with flags |
| 22:07 |
RealBadAngel |
yes, but i do believe its harmless now and i would like to use it for another purposes |
| 22:07 |
est31 |
ok |
| 22:08 |
RealBadAngel |
thats why i left it unchanged |
| 22:08 |
RealBadAngel |
i wil make now two PRs for the game |
| 22:09 |
paramat |
ok |
| 22:27 |
RealBadAngel |
paramat, https://github.com/minetest/minetest_game/pull/641 |
| 22:27 |
RealBadAngel |
first one |
| 22:31 |
RealBadAngel |
https://github.com/minetest/minetest_game/pull/642 |
| 22:31 |
RealBadAngel |
and the second |
| 22:33 |
|
wilkgr joined #minetest-dev |
| 22:47 |
RealBadAngel |
ouch, minetest doesnt have marble and granite, fixing 642 now |
| 22:49 |
VanessaE |
so I don't recall seeing where you said what happens if a user switches to some other texture pack which doesn't supply all the normalmaps. do these get used then? or only the ones their texture pack supplies? |
| 22:51 |
RealBadAngel |
if some1 wants to use displacement mapping he needs to get tp pack that supports it |
| 22:52 |
VanessaE |
let me rephrase that |
| 22:52 |
RealBadAngel |
i know what you mean |
| 22:52 |
VanessaE |
if some texture pack has NO normals at all, what gets used for normals? nothing? these defaults? something pulled from the aether? |
| 22:52 |
RealBadAngel |
normal maps are default textures |
| 22:52 |
RealBadAngel |
tp that does not support them is not complete |
| 22:53 |
VanessaE |
FAIL |
| 22:53 |
RealBadAngel |
displacement mapping is core feature |
| 22:53 |
VanessaE |
in effect you break every texture pack in existence except for Haven |
| 22:53 |
RealBadAngel |
this is not texture pack |
| 22:53 |
est31 |
grrr, there seem to be other bugs with inventory replacements too |
| 22:54 |
est31 |
e.g. if the destination inventory is full |
| 22:54 |
est31 |
and you take from a creative inventory |
| 22:54 |
VanessaE |
special handling of normals is needed - only pull normalmaps from the user's texture pack if there is a texture pack in use. |
| 22:54 |
est31 |
it deletes one element from the destination inventory |
| 22:54 |
est31 |
without asking |
| 22:54 |
hmmmm |
can players crouch in minetest? |
| 22:54 |
VanessaE |
hmmmm: no |
| 22:54 |
hmmmm |
ahh okay |
| 22:54 |
est31 |
why |
| 22:54 |
hmmmm |
is that wanted |
| 22:54 |
VanessaE |
possibly. |
| 22:55 |
RealBadAngel |
could be useful |
| 22:55 |
VanessaE |
there is "sneak" but that really means "walk slowly and more carefully". |
| 22:55 |
est31 |
you can sit on chairs |
| 22:55 |
est31 |
but not very reliably |
| 22:56 |
VanessaE |
RealBadAngel: my point being, just about every actual texture pack in existence is going to be devoid of normalmaps. They were never "incomplete" before, you can't go retroactively making them incomplete now. |
| 22:57 |
VanessaE |
not when there are 345 textures in minetest_game alone. |
| 22:57 |
VanessaE |
that's too much breakage. |
| 22:57 |
paramat |
ok |
| 22:57 |
RealBadAngel |
enabling displacement mapping doesnt mean selecting new texture pack at all |
| 22:58 |
VanessaE |
I'm not talking about that, RealBadAngel |
| 22:58 |
RealBadAngel |
yes you want that |
| 22:58 |
RealBadAngel |
for normal maps that are for core feature |
| 22:58 |
VanessaE |
I'm talking about if it's *already* enabled for say, several days/weeks, and the user *then* selects a texture pack that has partial support for normalmaps |
| 22:59 |
hmmmm |
what events are missing here that you would think is useful for a client mod? http://fpaste.org/256506/39938718/ |
| 22:59 |
VanessaE |
are you saying that normalmaps included with minetest_game will get used when a texture pack does not supply them? |
| 22:59 |
RealBadAngel |
yes, hightlight the word "partial" - it means its incomplete |
| 22:59 |
VanessaE |
then it's a fail |
| 22:59 |
VanessaE |
you can't do that,. |
| 22:59 |
VanessaE |
you HAVE to make sure normalmaps are always pulled from the same dir as their corresponding color texture |
| 23:00 |
VanessaE |
(regardless whether it's a texture pack or a mod or a game) |
| 23:00 |
RealBadAngel |
cant do that im afraid |
| 23:00 |
VanessaE |
why not? |
| 23:00 |
RealBadAngel |
that would break even more things |
| 23:00 |
RealBadAngel |
and even the features |
| 23:01 |
VanessaE |
for normalmaps? |
| 23:01 |
RealBadAngel |
ability to override normals for example |
| 23:01 |
VanessaE |
it would break less than what you're proposing to do now. |
| 23:01 |
VanessaE |
wat |
| 23:01 |
VanessaE |
foo/bar/blahblah.png --> foo/bar/blahblah_normal.png |
| 23:01 |
VanessaE |
that's all. |
| 23:01 |
RealBadAngel |
override_normal.png |
| 23:01 |
VanessaE |
anything more complicated than that breaks shit that should not break. |
| 23:02 |
est31 |
or alternative solution, just rename all textures |
| 23:02 |
VanessaE |
hmmmm: what about if the player is merely punched (perhaps by a MOB) with no HP change? |
| 23:02 |
est31 |
then there wont be breakage |
| 23:03 |
hmmmm |
yep got it |
| 23:03 |
est31 |
you'll just see that texture packs wont work |
| 23:03 |
VanessaE |
... |
| 23:04 |
est31 |
but VanessaE's point is valid |
| 23:04 |
RealBadAngel |
lemme show you another situation |
| 23:04 |
est31 |
until we get to the point where texture packs authors only want to change the normals, but not the original texture |
| 23:04 |
est31 |
or only the original texture, but not the normals |
| 23:04 |
RealBadAngel |
you decide to use texture pack, that has partial support for textures |
| 23:05 |
paramat |
fallback to auto-generated normalmaps? |
| 23:05 |
RealBadAngel |
if you enable it, you will loose all the normal maps |
| 23:05 |
VanessaE |
paramat: doesn't work out so well for some textures. |
| 23:05 |
est31 |
hmmmm, what should CSEVT_NETWORK do |
| 23:05 |
paramat |
yeah |
| 23:05 |
est31 |
also, we shouldnt have keyboard and mouse input |
| 23:05 |
est31 |
imagine android users |
| 23:05 |
hmmmm |
that event is triggered with the message payload any time a TOCLIENT_SCRIPT_MESSAGE is received |
| 23:06 |
hmmmm |
yes about that |
| 23:06 |
est31 |
should perhaps be renamed |
| 23:06 |
VanessaE |
est31: call it generic HID input then? |
| 23:06 |
RealBadAngel |
texturing nodes in minetest engine does require 2 files, diffuse map and a normal map |
| 23:06 |
hmmmm |
if a mod doesn't want any inputs it's ignored |
| 23:06 |
VanessaE |
RealBadAngel: in other words, "so, the proposal is to make twice as much work for texture authors". |
| 23:06 |
est31 |
we shouldnt offer apis this low level |
| 23:06 |
RealBadAngel |
any texture pack that wants to alter existing textures and be full, have to provide both files |
| 23:06 |
hmmmm |
mods have to "subscribe" to events first or else they're not even queued, saving CPU from doing useless allocations/semaphore signals |
| 23:06 |
hmmmm |
why not? |
| 23:07 |
est31 |
otherwise we get to the use key not availiable on android situation |
| 23:07 |
est31 |
just even worse |
| 23:07 |
RealBadAngel |
its not a proposal, its requirement |
| 23:07 |
VanessaE |
RealBadAngel: then the requirement needs to be re-evaluated |
| 23:07 |
hmmmm |
well then |
| 23:07 |
VanessaE |
this is NOT 0.4.13 material. |
| 23:07 |
hmmmm |
mod writers will need to adapt |
| 23:07 |
est31 |
hmmmm, its not about adapting |
| 23:07 |
RealBadAngel |
this is core feature for the very long time |
| 23:07 |
est31 |
its about giving mod writers a safe sandbox |
| 23:08 |
est31 |
and not letting mod writers getting into our way |
| 23:08 |
VanessaE |
the vast majority of texture authors just want to change the textures, not any normalmaps, and you're requiring a skill few graphics artists possess. |
| 23:09 |
VanessaE |
you need to pull normals from the same dir as the texture came from or generate a "zero" image for those textures. |
| 23:09 |
RealBadAngel |
if texture pack creator havent made maps he should clearly state and warn user that tp DOESNT SUPPORT bumpmapping and displacement mapping |
| 23:09 |
est31 |
hmmmm, you dont design good apis by adding such specific features |
| 23:09 |
VanessaE |
but what if they've created SOME but not ALL? |
| 23:09 |
est31 |
right now formspec is very semantic |
| 23:09 |
VanessaE |
like they don't think e.g. gravel needs a normalmap? |
| 23:09 |
est31 |
and thats good |
| 23:10 |
|
wilkgr left #minetest-dev |
| 23:10 |
hmmmm |
nobody said we were going to expect mod writers to handle keys themselves |
| 23:10 |
est31 |
e.g. you can set up an interface where you say the name of the button |
| 23:10 |
hmmmm |
and mouse moves |
| 23:10 |
VanessaE |
think cartoonish textures. usually those won't want normalmaps at all, but the user wants normalmaps enabled for all those other mods that have them |
| 23:10 |
est31 |
hmmmm, so why offer it to them |
| 23:10 |
hmmmm |
in case they need it |
| 23:10 |
est31 |
they should give us their usecase |
| 23:11 |
est31 |
and we build them then a custom plugin for that usecase |
| 23:11 |
est31 |
that also works on touch |
| 23:11 |
est31 |
otherwise we can forget porting minetest to game consoles |
| 23:11 |
hmmmm |
this can all be abstracted |
| 23:11 |
VanessaE |
est31: what about just registering *actions* rather than keys, sorta like what hmmmm already specified |
| 23:11 |
est31 |
sooner or later every mod will require the custom input events |
| 23:11 |
RealBadAngel |
http://i.imgur.com/RX2BUjh.png |
| 23:12 |
est31 |
because to work around engine bugs |
| 23:12 |
est31 |
or whatever |
| 23:12 |
RealBadAngel |
are you sure that cartoonish tps doesnt need normal maps? |
| 23:12 |
est31 |
even more people will cry out "lets do this in lua" |
| 23:12 |
VanessaE |
RealBadAngel: I wasn't talking about sphax.. |
| 23:12 |
est31 |
we'll get to a point where there wont be difference between hud or formspecs |
| 23:12 |
est31 |
where its all just a big cesspit |
| 23:13 |
hmmmm |
there is a difference between hud and formspecs |
| 23:13 |
est31 |
of mod incompatibilities |
| 23:13 |
hmmmm |
a formspec is a hud element that displays the mouse when open and accepts input |
| 23:13 |
hmmmm |
also formspecs are heirarchical |
| 23:13 |
hmmmm |
well |
| 23:14 |
est31 |
no mouse |
| 23:14 |
hmmmm |
in the future that's the way it'll be |
| 23:14 |
RealBadAngel |
VanessaE, but anywyay even if i will agree with you, theres no way to make it working the way youre describing now |
| 23:14 |
est31 |
thats not part of the definition |
| 23:14 |
est31 |
mouse isnt available on touch devices |
| 23:14 |
hmmmm |
god dammit est |
| 23:14 |
VanessaE |
RealBadAngel: then the normals can't be included with minetest_game. |
| 23:14 |
est31 |
<hmmmm> in the future that's the way it'll be |
| 23:14 |
hmmmm |
i understand this |
| 23:14 |
est31 |
thats very arrogant to sa |
| 23:14 |
est31 |
y |
| 23:14 |
hmmmm |
when I say "shows the mouse cursor" obviously it's going to do the correct thing on android |
| 23:15 |
est31 |
its like if RBA said "in the future we will have that tune by the legend" |
| 23:15 |
hmmmm |
on android that means that touching the screen will behave like a mouse click on a gui element instead of punching a node |
| 23:15 |
hmmmm |
well I have a vision |
| 23:15 |
RealBadAngel |
VanessaE, then remove displacement mapping from the core |
| 23:15 |
hmmmm |
I want Hud and Formspecs to be abstracted to the point where there isn't much of a difference between them |
| 23:15 |
VanessaE |
... |
| 23:15 |
RealBadAngel |
without those files its not needed |
| 23:16 |
VanessaE |
RealBadAngel: this is the realm of texture packs, not default game. |
| 23:16 |
est31 |
hmmmm, what you propose isnt abstraction |
| 23:16 |
RealBadAngel |
displacement mapping is not texture pack feature |
| 23:16 |
VanessaE |
if you want to propose your normals as an alternate texture pack that the user can turn on, that is itself included with...something... I'm fine with thaty. |
| 23:16 |
VanessaE |
-y |
| 23:16 |
hmmmm |
from what I understand, you're afraid that if we give modders the power to detect raw clicks or whatever, they'll misuse it by hacking together their own GUI system? |
| 23:16 |
est31 |
you propose to require mod makers to work for support specific devices |
| 23:16 |
est31 |
supporting* |
| 23:16 |
RealBadAngel |
users are selecting it and reporting - that doesnt work! |
| 23:16 |
est31 |
hmmmm, yes |
| 23:16 |
hmmmm |
I am saying that if they want to use low-level events, they need to be aware of the risks involved |
| 23:17 |
hmmmm |
if they want to be safe, they should just stick to the high-level events |
| 23:17 |
RealBadAngel |
because the game without those files is incomplete |
| 23:17 |
RealBadAngel |
not the texture pack |
| 23:17 |
est31 |
hmmmm, current attitude has been to offer a safe sandbox for modders |
| 23:17 |
hmmmm |
in every GUI toolkit, the user has the ability to trigger events on mouse movement |
| 23:17 |
VanessaE |
the game will *always* be "incomplete", and lack of normalmaps does not make it any worse. |
| 23:17 |
est31 |
its also the reason why we dont have version string displays |
| 23:17 |
hmmmm |
do you ever see people reimplementing their own gui? |
| 23:18 |
est31 |
we are so extreme, we dont even say mods which version we run |
| 23:18 |
est31 |
because of fear they could use it for feature detection |
| 23:18 |
est31 |
and not detecting the features themselves |
| 23:18 |
est31 |
what you propose is much more intrusive |
| 23:19 |
hmmmm |
erm, 'intrusive'? |
| 23:20 |
hmmmm |
I'm just making sure the power is there in case modders need it |
| 23:20 |
hmmmm |
I am not going to arrogantly pretend that we know better than they do |
| 23:20 |
est31 |
client scripting is for allowing to control the camera or so, not to make minetest an interface between lua and irrlicht |
| 23:20 |
RealBadAngel |
also VanessaE if texture pack maker would want to change only normal map for the texture |
| 23:20 |
RealBadAngel |
your proposal would make it impossible |
| 23:21 |
VanessaE |
better to require a texture to go with a normalmap than to require a normalmap to go with a texture. |
| 23:21 |
est31 |
hmmmm, we dont know better than they do, but thats what why the c++ level isn't final |
| 23:21 |
VanessaE |
if they want to only change the normals, they can copy the default textures that go with them and leave them unchanged,. |
| 23:21 |
VanessaE |
come on, really, that's about as far into the corner as a corner case gets. |
| 23:22 |
est31 |
hmmmm, minetest is good because modding is easy, making it more extendible doesn't help |
| 23:22 |
hmmmm |
alright, I'll leave those out for now |
| 23:22 |
est31 |
there are tons of super extendible engines with super easy languages out there |
| 23:22 |
est31 |
take unity |
| 23:22 |
paramat |
RealBadAngel, is 641 tested? you know what to look for so it's best tested by you |
| 23:23 |
est31 |
note, I'm not against an actually customizeable "gui canvas" where you can e.g. make client side terminals |
| 23:23 |
est31 |
there you can process mouse output etc |
| 23:23 |
est31 |
just it should be clearly separated |
| 23:23 |
RealBadAngel |
paramat, just enable displacement mapping with this commit and without. and look at grass |
| 23:23 |
est31 |
as its own formspec element |
| 23:24 |
est31 |
or "new" generic gui |
| 23:24 |
RealBadAngel |
without 641 grass will be messed up |
| 23:25 |
hmmmm |
btw we're calling the new gui "formspec" but it's definitely not going to share any resemblence to formspec |
| 23:25 |
hmmmm |
formspec is bad and it needs to go |
| 23:25 |
est31 |
dunno share the opinion with you that its especially bad |
| 23:25 |
est31 |
but shrug, if you want to replace it, go on |
| 23:25 |
paramat |
sure but please test it yourself as i'm unfamiliar with the glitch |
| 23:26 |
est31 |
as long as we will have ways to maintain compatibility with old mods |
| 23:26 |
est31 |
and the new api will be as easy to use as formspecs |
| 23:26 |
hmmmm |
three times, I've went to add a feature using formspec and I've been unsatisfied to the point where it made me want to scrap what it was i was working on |
| 23:26 |
paramat |
we'll add 642 but then please can we remove the 'tree top' normalmaps because these are cut logs and need a flat surface? |
| 23:27 |
hmmmm |
formspec is junk that was created to fill a very niche type of GUI form and then people expanded upon it until it became what it is present day |
| 23:27 |
RealBadAngel |
removing the normal map wont make it flat at all |
| 23:27 |
RealBadAngel |
autogen will make it bumped too |
| 23:27 |
hmmmm |
also formspec is not easy |
| 23:27 |
hmmmm |
it's confusing as all hell |
| 23:27 |
paramat |
ah |
| 23:28 |
RealBadAngel |
hmmmm, but each and every mod out there is using it |
| 23:28 |
hmmmm |
if we want a text-based GUI description language, let's use XML instead |
| 23:28 |
hmmmm |
this is one of the things i wanted to do |
| 23:28 |
est31 |
XML is super ugly |
| 23:28 |
hmmmm |
there should be several frontends |
| 23:28 |
est31 |
you need end tags |
| 23:28 |
hmmmm |
formspec front end, xml front end, etc. |
| 23:28 |
est31 |
end tags bear no information |
| 23:28 |
est31 |
ok they do |
| 23:28 |
RealBadAngel |
removing formspec will efectively make all mods not working |
| 23:29 |
est31 |
but still, formspecs are straightforward |
| 23:29 |
est31 |
why xml is shiny dynamic |
| 23:29 |
paramat |
well we'll sort tree tops out later, 642 can go in for relesae |
| 23:29 |
est31 |
formspecs are the lua way |
| 23:29 |
paramat |
(release) |
| 23:29 |
RealBadAngel |
paramat, i can make that one more flat on request |
| 23:30 |
hmmmm |
XML was made for this exact type of bullshit |
| 23:30 |
paramat |
yes please if you have time, completely flat |
| 23:30 |
RealBadAngel |
have you actually checked how tree tops look like with it? |
| 23:30 |
hmmmm |
it might not be the most efficient design but there is loads of support for it |
| 23:30 |
est31 |
hmmmm, as things to add to your list, I'd propose CSEVT_PLAYER_MOVE, CSEVT_NODE_PUNCH, CSEVT_NODE_DIG, CSEVT_NODE_PLACE |
| 23:30 |
paramat |
well i know they need to be flat |
| 23:31 |
hmmmm |
est, I have added more |
| 23:31 |
RealBadAngel |
paramat, https://imgrush.com/mXL-Y3TCcykB.png |
| 23:31 |
est31 |
hmmmm, whats your new list |
| 23:31 |
hmmmm |
http://fpaste.org/256522/40683143/ |
| 23:31 |
hmmmm |
so |
| 23:31 |
hmmmm |
just to be clear: |
| 23:31 |
paramat |
i'll merge 641 once you've tested it |
| 23:31 |
hmmmm |
client side scripting runs in a separate thread |
| 23:31 |
est31 |
yes |
| 23:31 |
hmmmm |
events are posted to it |
| 23:31 |
est31 |
yes |
| 23:31 |
hmmmm |
everything is asynchronous here |
| 23:31 |
est31 |
yes |
| 23:31 |
hmmmm |
no laggy bullshit |
| 23:32 |
hmmmm |
we learned our lesson from the server modding |
| 23:32 |
est31 |
well yeah |
| 23:32 |
est31 |
separate thread is a good idea |
| 23:32 |
RealBadAngel |
paramat, 641 is made weeks ago |
| 23:32 |
hmmmm |
every time one of these events happen an event gets posed to the client m_script |
| 23:32 |
hmmmm |
the script thread executes the lua handler for this event |
| 23:33 |
hmmmm |
s/posed/posted/ |
| 23:33 |
RealBadAngel |
so i believe its tested enough ;) |
| 23:33 |
est31 |
I'd rename CSEVT_PLAYER_CHATMESSAGE ---> CSEVT_CHATMESSAGE |
| 23:33 |
hmmmm |
then I have some ideas for what the lua api will look like |
| 23:33 |
hmmmm |
by the way, do clients get individual player join/leave events? |
| 23:33 |
hmmmm |
probably not, right? |
| 23:34 |
est31 |
they get it |
| 23:34 |
est31 |
as chat messages |
| 23:34 |
hmmmm |
they do get it |
| 23:34 |
hmmmm |
yeah exactly |
| 23:34 |
est31 |
also I think it might be possible they even get it more low level too |
| 23:34 |
est31 |
for the f10 console completion |
| 23:34 |
est31 |
s |
| 23:34 |
hmmmm |
that's what I was asking mostly |
| 23:34 |
hmmmm |
hmm let's see |
| 23:34 |
RealBadAngel |
VanessaE, atm only solution to your request would be moving all the normal maps to another folder and forcing it to be texture pack |
| 23:34 |
est31 |
but it might be horribly hacked |
| 23:34 |
est31 |
by the client parsing server sent messages |
| 23:35 |
RealBadAngel |
theres no other solution |
| 23:35 |
VanessaE |
RealBadAngel: then do that. |
| 23:35 |
est31 |
hmmmm, we should add some API for completion too |
| 23:35 |
hmmmm |
nick completion? |
| 23:35 |
est31 |
or command completion |
| 23:35 |
hmmmm |
ehh |
| 23:35 |
est31 |
in f10 console |
| 23:36 |
est31 |
or in the t console |
| 23:36 |
RealBadAngel |
VanessaE, but then core feature will become broken. i would like to hear other voices on that |
| 23:36 |
hmmmm |
we'll see what we can do later |
| 23:36 |
est31 |
ok |
| 23:36 |
hmmmm |
hrm |
| 23:36 |
hmmmm |
i'm not seeing a player join/leave notify packet |
| 23:37 |
est31 |
the f10 console does maintain such a list |
| 23:37 |
est31 |
so it seems it parses it... |
| 23:37 |
hmmmm |
are you sure?? |
| 23:37 |
est31 |
no |
| 23:37 |
hmmmm |
I am not seeing it |
| 23:37 |
hmmmm |
well nevermind that |
| 23:38 |
paramat |
okay will merge 641 |
| 23:39 |
hmmmm |
let's not discuss anything more until i get this portion done |
| 23:39 |
est31 |
what portion |
| 23:39 |
hmmmm |
the amount of discussion about a feature is inversely proportional to how fast it actually gets done |
| 23:39 |
hmmmm |
just the basic |
| 23:40 |
est31 |
we should discuss before there is an implementation |
| 23:40 |
hmmmm |
my first goalpost is to have the server send client scripts as media, client loads them, and posts scripting events to them |
| 23:40 |
est31 |
otherwise the implementation might be wasted |
| 23:40 |
hmmmm |
we already agree on what i'm doing so far |
| 23:40 |
est31 |
yes |
| 23:41 |
hmmmm |
so right now I just need to add in the event hooks |
| 23:41 |
hmmmm |
and then I'm pretty much done |
| 23:41 |
est31 |
ok |
| 23:41 |
hmmmm |
but I'd rather focus on getting 0.4.13 out |
| 23:41 |
est31 |
agreed |
| 23:42 |
hmmmm |
less talking more doing |
| 23:43 |
est31 |
well, I do have PRs around that can be merged sooner or later |
| 23:43 |
est31 |
e.g. my utf chat pr |
| 23:43 |
hmmmm |
how about 3058 |
| 23:44 |
est31 |
#3058 |
| 23:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/3058 -- Modstore: show an ui error if retrieving failed by est31 |
| 23:44 |
est31 |
I don't think we should add http_response_code to the exception object |
| 23:45 |
hmmmm |
why |
| 23:45 |
est31 |
a JsonFetchException is just noting that something went wrong during fetching json information |
| 23:45 |
est31 |
it might be a wrong http code |
| 23:45 |
est31 |
it might be dns failure |
| 23:45 |
hmmmm |
so if it's 0 then that means it wasn't a failure at the http level |
| 23:46 |
est31 |
or just the returned thing isnt json |
| 23:46 |
est31 |
also what would it use us |
| 23:46 |
hmmmm |
i just want there to be a friendlier message |
| 23:46 |
hmmmm |
can't you make it say |
| 23:46 |
est31 |
I'd go with what VanessaE proposed |
| 23:46 |
hmmmm |
"Oops! Sorry about that, mmdb seems to be having problems right now." |
| 23:47 |
est31 |
"Sorry but there was a problem with loading the modstore. Its technical message, which you should include in error reports, is:" |
| 23:47 |
hmmmm |
no don't do that |
| 23:47 |
hmmmm |
you're going to encourage useless bug reports for a website 404 error |
| 23:48 |
hmmmm |
this is why I want to know if it's an HTTP error vs. some other kind of error I guess |
| 23:48 |
est31 |
perhaps we should point out then that the modstore might be offline because of choice? |
| 23:48 |
hmmmm |
is it some operational problem or is it an engine problem |
| 23:48 |
est31 |
then a bool vale suffices |
| 23:48 |
est31 |
is_http_404 |
| 23:48 |
hmmmm |
i do NOT want our github to get spammed with operational problems |
| 23:49 |
hmmmm |
no, is_http_error probably |
| 23:49 |
est31 |
no |
| 23:49 |
hmmmm |
what if the webserver gets misconfigured and it posts 503 or something |
| 23:49 |
est31 |
is_http_error might be a problem of the wrong request too |
| 23:50 |
est31 |
hmmmm, what if the webserver is just simply gone, because the domain isnt hosted anymore? |
| 23:50 |
est31 |
then its no 404 |
| 23:50 |
hmmmm |
right |
| 23:50 |
est31 |
it might be a dns problem |
| 23:50 |
est31 |
or timeout |
| 23:50 |
hmmmm |
do we want users to file /bug/ reports over that? |
| 23:50 |
est31 |
or tcp error |
| 23:50 |
hmmmm |
I want to be able to differentiate between actual bugs and imaginary bugs |
| 23:50 |
est31 |
hmmmm, agreed |
| 23:50 |
hmmmm |
so |
| 23:50 |
hmmmm |
however that's best accomplished |
| 23:50 |
est31 |
but we dont solve it by adding http codes to the exception |
| 23:50 |
hmmmm |
but right now i need to go take a shit |
| 23:51 |
hmmmm |
bbl |
| 23:56 |
|
wischi2 joined #minetest-dev |
| 23:57 |
paramat |
now merging game 641 |
