| Time |
Nick |
Message |
| 01:49 |
|
psedlak_ joined #minetest-dev |
| 04:14 |
|
smoke_fumus joined #minetest-dev |
| 04:24 |
|
psedlak joined #minetest-dev |
| 04:58 |
|
nore joined #minetest-dev |
| 05:04 |
|
neko259 joined #minetest-dev |
| 05:20 |
|
kaeza joined #minetest-dev |
| 06:03 |
|
darkrose joined #minetest-dev |
| 06:03 |
|
darkrose joined #minetest-dev |
| 06:05 |
|
Ritchie joined #minetest-dev |
| 07:37 |
|
Akien joined #minetest-dev |
| 08:02 |
|
emptty joined #minetest-dev |
| 08:11 |
|
Jordach joined #minetest-dev |
| 08:40 |
|
psedlak joined #minetest-dev |
| 08:43 |
|
psedlak joined #minetest-dev |
| 08:51 |
|
Calinou joined #minetest-dev |
| 09:18 |
|
proller joined #minetest-dev |
| 10:31 |
kahrl |
Woo, GUITable works well enough already to replace IGUIListBox for implementing textlists, no black magic needed anymore: https://github.com/kahrl/minetest/commit/f6e9ad671dc746ada5fe267cf35e8d5e01568afb |
| 10:31 |
kahrl |
(the only thing missing is parsing the #RRGGBB syntax) |
| 10:33 |
kahrl |
oh, and searching for items by typing their first characters, but that's mostly a matter of removing some #if 0 and making a function to get a Row's text |
| 10:56 |
|
proller joined #minetest-dev |
| 11:00 |
|
Calinou joined #minetest-dev |
| 11:11 |
|
Zeitgeist_ joined #minetest-dev |
| 11:13 |
|
PilzAdam joined #minetest-dev |
| 12:08 |
|
proller joined #minetest-dev |
| 12:53 |
|
hmmmm joined #minetest-dev |
| 13:41 |
|
Taoki[laptop] joined #minetest-dev |
| 14:26 |
|
tango_ joined #minetest-dev |
| 15:00 |
|
kaeza joined #minetest-dev |
| 15:02 |
|
rubenwardy joined #minetest-dev |
| 15:09 |
|
kaeza joined #minetest-dev |
| 15:24 |
|
Calinou joined #minetest-dev |
| 15:32 |
|
sapier joined #minetest-dev |
| 15:56 |
hmmmm |
hey guys |
| 15:56 |
* hmmmm |
reads some logs |
| 15:57 |
sapier |
you can skip the late night discussion there was not a single result |
| 15:58 |
proller |
https://github.com/proller/minetest/compare/heat https://github.com/proller/minetest/compare/liquid63 8) |
| 15:59 |
sapier |
proller you obviously still believ in wonders to happen ;-) |
| 16:00 |
proller |
its semi-automatic 8) |
| 16:01 |
sapier |
hmm that's a good idea it should be possible to make pidgin autowrite some text on join :-) I guess if I do that I'll be banned very soon |
| 16:02 |
hmmmm |
well |
| 16:02 |
hmmmm |
about my own weather code refactoring, i never fully completed it and i'd need to do it over again anyway after the omnicleanup and other things |
| 16:03 |
hmmmm |
so, it would be great to have those weather additions/fixes/whatever added in before i re-do what i had planned |
| 16:04 |
proller |
heat is small and simple |
| 16:04 |
hmmmm |
about the liquid63, i need to look deeper at that |
| 16:05 |
sapier |
hmmmm does this count as approval for heat? |
| 16:05 |
hmmmm |
of course |
| 16:05 |
hmmmm |
it's a strict improvement, and it's only modifying what proller already has there |
| 16:05 |
sapier |
good :-) I just wanted to clarify ;-) |
| 16:06 |
hmmmm |
yeah.... wow...... |
| 16:06 |
hmmmm |
liquid63, I guess it's not as simple as the branch name makes it sound |
| 16:06 |
hmmmm |
there's a lot more going on |
| 16:06 |
proller |
liquid63 fixes most of liquid but removes PilzAdam 2 buggy strings for "range" |
| 16:07 |
proller |
most of issues |
| 16:07 |
hmmmm |
from the name, i thought it expanded the liquid level to 63 possible values |
| 16:07 |
proller |
and add awesome features 8) |
| 16:07 |
proller |
yes, max 63, but it can beconfigurable for each liquid |
| 16:08 |
proller |
like 4 for lava, 20 for water, etc.. |
| 16:08 |
sapier |
I'm repeating ... but ... bugfixing prior features ;-) |
| 16:08 |
proller |
sapier, i cant stop doing it 8- |
| 16:08 |
proller |
_ |
| 16:08 |
proller |
8) |
| 16:09 |
proller |
and i need to go now, will read log.. |
| 16:12 |
sapier |
does anyone know who made the anaglyph support? |
| 16:12 |
Calinou |
Taoki |
| 16:13 |
|
ch98 joined #minetest-dev |
| 16:13 |
sfan5 |
$ git log | grep Anaglyph |
| 16:13 |
sfan5 |
Anaglyph stereo support, created by xyz |
| 16:13 |
Calinou |
mhm |
| 16:14 |
sapier |
taoki or thexyz was not doing selection box anaglyph to on purpose or is it a bug? |
| 16:14 |
Calinou |
bug |
| 16:15 |
sapier |
I'm not exactly sure other ui isn't anaglyph too ... but I guess it's not usefull to skip the selection box too |
| 16:15 |
sfan5 |
IIRC we have a bugreport for that on github |
| 16:15 |
sapier |
Yea but I was hoping to find the one to ask some additional questions too ;-) |
| 16:33 |
kaeza |
sapier, I have a question relating find_path(), may I PM? |
| 16:36 |
sapier |
of course |
| 16:37 |
sapier |
to everyone you don't need to ask for pm just do it ;-) |
| 17:03 |
|
sapier1 joined #minetest-dev |
| 17:17 |
|
Miner_48er joined #minetest-dev |
| 17:57 |
|
proller joined #minetest-dev |
| 18:10 |
|
proller joined #minetest-dev |
| 18:12 |
sapier1 |
whoever did the scrollbar black magic .. great work! |
| 18:15 |
|
Ritchie joined #minetest-dev |
| 18:34 |
|
neko259 joined #minetest-dev |
| 18:38 |
sapier1 |
http://www.picpaste.de/improoved_modmgr_7-nl3y1QU6.png updated suggestion for modmgr fixing the suboptimal "depends" textlist |
| 18:39 |
proller |
hmmmm, commit heat? no one want to accept it |
| 18:46 |
|
Akien joined #minetest-dev |
| 18:47 |
sapier1 |
kahrl what's up with your http fetching changes? I already posted a suggestion that'd be able to fix the delays in modmgr but that'd be major conflict to your work ... I have no interest in doing work for trash |
| 18:55 |
kahrl |
sapier1, I haven't been working on it |
| 18:55 |
sapier1 |
so how to continue? |
| 18:56 |
kahrl |
what would you need from it? maybe I can develop it far enough to have those parts |
| 18:56 |
kahrl |
it doesn't conflict with the table stuff so I can work on either |
| 18:56 |
sapier1 |
basicaly the problem within modmgr is you can't fetch the data asynchronously but have to stall the menu until you got all data |
| 18:57 |
sapier1 |
only real solution is to request the data and get informed once it's ready |
| 18:57 |
sapier1 |
thus the menu could be redrawn containing the new data |
| 18:58 |
sapier1 |
e.g. first show only empty spacers then add the description then the screenshots |
| 18:58 |
kahrl |
there was the problem that we didn't decide on a design for how it would work |
| 18:59 |
kahrl |
my suggestion was engine.httpfetch(url, callback) and additional methods to parse the serverlist/modlist/whatever from json data |
| 18:59 |
sapier1 |
exactly but obviously your work and my suggestion collide cause they're in large parts similar |
| 18:59 |
kahrl |
yours was having engine.async_get_serverlist, engine.async_get_modlist etc. calls that do the work in C++ |
| 19:00 |
sapier1 |
yes but I thought about that and think it's better to do even more |
| 19:00 |
sapier1 |
my improved suggestion is doing engine.async_call(some function to call, some data) returning a userdataelement |
| 19:01 |
sapier1 |
this isn't usefull of course so we need to add some "engine.toLua(userdata)" function too |
| 19:01 |
sapier1 |
later one is done to receive the result |
| 19:01 |
sapier1 |
of course this is just theory by now |
| 19:03 |
sapier1 |
that way you could call arbitrary lua functions and receive their result asynchronously |
| 19:03 |
kahrl |
that would of course be the most generic option |
| 19:03 |
sapier1 |
and needs some additional work |
| 19:04 |
kahrl |
I don't know enough about lua multithreading (i.e. the lack of it) to do that, I think |
| 19:04 |
sapier1 |
e.g. the functions need to support both userdata return as well as direct lua return |
| 19:04 |
kahrl |
and how would doing it conflict with httpfetch? |
| 19:05 |
sapier1 |
it basically addresses same problems threading would be done by async callbacks while yours would do their own threads |
| 19:06 |
sapier1 |
and of course my solution wouldn't be complete at first step, I'd start to add support for those functions needed atm returning "false" to a lua call not supported by that time |
| 19:06 |
sapier1 |
e.g. specifying a lua implemented function would have to be done in a later step |
| 19:07 |
kahrl |
oh so every function needs to have custom handling? |
| 19:07 |
sapier1 |
no just different types of functions |
| 19:07 |
kahrl |
types = ? |
| 19:07 |
sapier1 |
e.g. minetest.find_path is a direct call to a c function |
| 19:08 |
sapier1 |
if you do a function myname() and try to call this with async it needs to be handled different |
| 19:08 |
kahrl |
oh... I thought you were only talking about the mainmenu API |
| 19:08 |
sapier1 |
no I don't intend to do the async handling twice ... at least concept has to fit both |
| 19:09 |
sapier1 |
but it isn't settled rigth now |
| 19:09 |
kahrl |
it is useful for game mods as well of course, but I don't trust most mod authors to understand locking issues well enough |
| 19:09 |
kahrl |
no offense |
| 19:09 |
sapier1 |
me too that's why async calls will have some limits |
| 19:10 |
sapier1 |
as said no lua functions in first step ... so it'll be quite limited |
| 19:11 |
sapier1 |
and of cours the big issue is that any single c function needs to be checked and modified |
| 19:12 |
kahrl |
anyway I don't think this would affect httpfetch much, other than probably the lua API |
| 19:12 |
kahrl |
httpfetch_async is needed on the C++ side anyway for media fetching |
| 19:12 |
kahrl |
and if the lua async thing works we could even just expose httpfetch_sync to lua |
| 19:13 |
sapier1 |
I'd add a generic async job handling thread/threadpool this you could use that one for prefetch jobs too |
| 19:14 |
sapier1 |
but your solution would be way more simple and less error prone (at least for that special case we really need right now) |
| 19:15 |
sapier1 |
and to be serious ... I'd be glad not to have to add another thing beeing that controversial right now ;-) |
| 19:18 |
kahrl |
other devs: do you have opinions on this issue? because having async lua calls affects a lot of things |
| 19:19 |
kahrl |
my opinion is that it would be very nice to have, though a lot of work to get it right |
| 19:19 |
celeron55 |
i think doing any kind of generic multithreading in lua is not worth comparing with asynchronous http fetching; it's way more error prone and maybe even involves designing stuff nobody else has ever done |
| 19:19 |
sapier1 |
yes and for sure first shot won't be final solution |
| 19:19 |
celeron55 |
when on the other hand asynchronous i/o from scripting languages is a thing that happens all the time |
| 19:20 |
celeron55 |
so if you want to get stuff done, make the asynchronous http fetch call |
| 19:20 |
sapier1 |
yes but http prefetch ain't full work that data needs to be parsed too ... atm fetching and parsing is mixed up so those things need to be split either |
| 19:20 |
celeron55 |
if you want to achieve some kind of lua magician fame, then do the other thng |
| 19:22 |
sapier1 |
that split needs to be done for any async lua thing too so at least no wasted work |
| 19:22 |
|
psedlak joined #minetest-dev |
| 19:37 |
|
ch98 joined #minetest-dev |
| 19:49 |
kahrl |
sapier1: http://paste.dy.fi/OrQ <-- not the prettiest API but it should work |
| 19:52 |
sapier1 |
should do the work yes |
| 19:54 |
sapier1 |
how do you do the http header thing required for mmdb? |
| 19:54 |
sapier1 |
or do you just add those headers everywhere? |
| 19:54 |
kahrl |
httpfetch takes either a string (URL) or a table as the first argument |
| 19:54 |
kahrl |
the table contains additional request options |
| 19:54 |
kahrl |
e.g. timeout, extra headers |
| 19:54 |
sapier1 |
I see |
| 19:55 |
sapier1 |
get_serverlist_details() is missing ;-) |
| 19:55 |
sapier1 |
oh ids hidden ther in 16 :-) |
| 19:56 |
sapier1 |
I'd drop the get_modstore_list functions completely |
| 19:56 |
kahrl |
how to parse the modstore list then? |
| 19:57 |
sapier1 |
no I menat drop the function add the parsers instead ... hmm I gues you meant to do that? |
| 19:57 |
kahrl |
oh, of course |
| 19:58 |
sapier1 |
the get_favorites text is a little bit irritating but I think I understood what you wanna do ... yes it's fine |
| 19:58 |
kahrl |
yeah I know, it has syntax errors and is missing error handling ;) |
| 19:58 |
kahrl |
but that can be fixed |
| 19:59 |
sapier1 |
missing error handling combined with "that can be fixed (later)" is often reason for big big problems ;-) |
| 20:00 |
kahrl |
should the online serverlist be downloaded in the background even if public_serverlist is false? |
| 20:00 |
kahrl |
so that is can be shown immediately when the user clicks the checkbox |
| 20:00 |
kahrl |
it* |
| 20:00 |
sapier1 |
no of course not |
| 20:01 |
sapier1 |
I disable the public server list for privacy reasons for example if you download it in background the only way to do so is disable curl completely |
| 20:02 |
sapier1 |
btw that list doesn't need that much time I gues 1 or 2 seconds are acceptable ;-) |
| 20:04 |
kahrl |
ok now for the planning |
| 20:05 |
kahrl |
what do you need and when? |
| 20:07 |
sapier1 |
I need what you just suggested I'm gonna add this to menu as soon as it's available |
| 20:07 |
kahrl |
ok |
| 20:08 |
sapier1 |
as there doesn seem to be a minetest release till christmas I assume it isn't that pressing |
| 21:01 |
|
iqualfragile joined #minetest-dev |
| 21:07 |
|
jin_xi joined #minetest-dev |
| 21:41 |
|
ch98 joined #minetest-dev |
| 22:26 |
|
jin_xi joined #minetest-dev |
