| Time |
Nick |
Message |
| 01:55 |
kahrl |
http://paste.dy.fi/LYD second column is # of outgoing depends, third column # of incoming depends, fourth column the product of those |
| 01:56 |
kahrl |
the ones at the end should bring the most benefit when optimized |
| 01:56 |
Tesseract |
kahrl: Did you see my reply? |
| 01:57 |
|
Weedy joined #minetest-dev |
| 01:57 |
kahrl |
Tesseract: no |
| 01:57 |
Tesseract |
<Tesseract> kahrl: There wasn't anything wrong with it, you just mentioned that you would like to have bind_address = 0.0.0.0, :: ... and not have ipv6_server. But that would take a lot mort time to implement. |
| 01:57 |
kahrl |
oh about #762 |
| 01:57 |
Tesseract |
#862 |
| 01:58 |
kahrl |
yeah, sorry :P |
| 01:59 |
Tesseract |
Also #856... |
| 01:59 |
kahrl |
Tesseract: you don't need to implement that |
| 01:59 |
Tesseract |
Hmmm? |
| 01:59 |
kahrl |
the multiple bind_address thing |
| 01:59 |
Tesseract |
Oh, yes. |
| 01:59 |
Tesseract |
So, is it good to merge? |
| 01:59 |
kahrl |
does #862 always work in singleplayer now? |
| 01:59 |
Tesseract |
Yes, it should. Although I can't test it. |
| 02:01 |
kahrl |
isn't this a memory leak? bind_addr.setAddress(new IPv6AddressBytes()); |
| 02:03 |
Tesseract |
Hmmm, maybe. |
| 02:04 |
kahrl |
aren't there people who start a server through the menu who might want to set bind_address? |
| 02:06 |
Tesseract |
Without a lot more complexity only 0.0.0.0/:: and 127.0.0.1/::1 would work... |
| 02:08 |
kahrl |
I should really try to find the pipe-socket code I wrote once |
| 02:09 |
kahrl |
(it made it so that instead of using OS sockets to communicate in singleplayer / client+server mode, messages are passed through mutex-locked in process memory) |
| 02:09 |
kahrl |
that would eliminate all those problems |
| 02:10 |
kahrl |
if anyone wants to write it, feel free :P it's unlikely I'll find it again |
| 02:11 |
Tesseract |
Hmmm, where should I free/delete it? |
| 02:12 |
kahrl |
just make the if into a block and use a local IPv6AddressBytes |
| 02:12 |
Tesseract |
Ah, I think I see... |
| 02:34 |
Tesseract |
Gah, found a bug, but I have to wade through main.cpp to find out what is causing it... |
| 03:20 |
|
ssieb joined #minetest-dev |
| 03:26 |
Tesseract |
\o/ singleplayer with IPv6 works finally. |
| 03:28 |
Tesseract |
kahrl: It should be all fixed now. |
| 03:49 |
* VanessaE |
peeks in |
| 04:38 |
|
Akien joined #minetest-dev |
| 04:52 |
|
neko259 joined #minetest-dev |
| 05:09 |
|
jin_xi joined #minetest-dev |
| 05:52 |
kahrl |
is there any point in keeping farmesh? |
| 06:06 |
celeron55 |
no |
| 06:06 |
celeron55 |
it's been scheduled for deletion a long time ago |
| 06:09 |
celeron55 |
>it's just not correct for a member of Map to deal with the environment, it's supposed to be separate from that |
| 06:09 |
celeron55 |
yes, the whole thing should be in Server/ClientEnvironment |
| 06:09 |
celeron55 |
the Map is just for the voxelly stuff |
| 06:12 |
|
darkrose joined #minetest-dev |
| 06:12 |
|
darkrose joined #minetest-dev |
| 06:15 |
VanessaE |
the point of farmesh was to give the impression of really-far-away stuff without necessarily having to render said stuff, right? |
| 06:16 |
kahrl |
VanessaE: kind of |
| 06:16 |
kahrl |
(it still rendered polygons, of course, and it was horribly inefficient at that) |
| 06:17 |
VanessaE |
right |
| 06:17 |
kahrl |
and architecturally it doesn't work in 0.4 |
| 06:17 |
VanessaE |
actually, tried it once recently... |
| 06:17 |
kahrl |
because the client doesn't know what the mapgen on the server does |
| 06:17 |
VanessaE |
it sorta still worked |
| 06:17 |
VanessaE |
but it was utterly useless :) |
| 06:22 |
celeron55 |
it should be removed even if someone redoes it sometime |
| 06:22 |
celeron55 |
because it can't work using any of the principles it currently uses |
| 06:23 |
celeron55 |
(search the logs for some more plans about it) |
| 06:29 |
* kahrl |
committed... something. https://github.com/kahrl/minetest/compare/omnicleanup |
| 06:31 |
kahrl |
seems to reduce the initial compile time on singlecores by roughly 5%: http://paste.dy.fi/LJ2 |
| 06:32 |
kahrl |
it's hard to quantify but the savings later on should be bigger (not as many header dependencies, so fewer source files to recompile) |
| 06:34 |
celeron55 |
oh by the way, wtf was this yesterday's #minetest license war |
| 06:35 |
VanessaE |
celeron55: no, I agree with you - remove it (farmesh) since it's guaranteed not to work properly anyway |
| 06:35 |
celeron55 |
"< Peacock> no matter what license mt uses, im pretty sure celeron is the copyright holder?" |
| 06:35 |
celeron55 |
this is just plain retarded |
| 06:35 |
celeron55 |
"and can relicense what he wrote at will" |
| 06:35 |
VanessaE |
oh G*d, don't start that in here :( |
| 06:36 |
celeron55 |
oh i'll kick anyone who continues 8) |
| 06:36 |
VanessaE |
:) |
| 06:43 |
celeron55 |
(to forum moderators: if somebody insist on releasing non-free mods, "Minetest-related projects" is the license-agnostic forum section) |
| 08:09 |
|
smoke_fumus joined #minetest-dev |
| 08:20 |
|
iqualfragile joined #minetest-dev |
| 08:56 |
|
darkrose joined #minetest-dev |
| 08:56 |
|
darkrose joined #minetest-dev |
| 08:58 |
|
Calinou joined #minetest-dev |
| 08:58 |
|
Calinou joined #minetest-dev |
| 09:26 |
troller |
https://github.com/proller/minetest/commit/d378deefddd5fb27e85025b932f014cda91d4dbd |
| 09:28 |
thexyz |
why? |
| 09:36 |
kahrl |
for some reason the sqlite documentation about PRAGMA synchronous = FULL gets this wrong (at least fails to mention it) |
| 09:36 |
kahrl |
it's mentioned in http://www.sqlite.org/howtocorrupt.html |
| 09:37 |
kahrl |
even in FULL mode, a power outage can still break your database with most kinds of disks you're likely to encounter |
| 09:37 |
kahrl |
because most disks lie about fsync |
| 09:41 |
celeron55 |
someone should benchmark how much faster OFF is |
| 09:42 |
celeron55 |
in one project of mine i have to use OFF to get any kind of reasonable performance even while it uses transactions properly |
| 09:43 |
celeron55 |
(haven't actually tried "normal" though) |
| 09:45 |
celeron55 |
(also i don't think we want to enable SQL injections via minetest.conf) |
| 09:45 |
Calinou |
relevant: https://xkcd.com/1172/ |
| 09:53 |
thexyz |
lol, who cares |
| 09:56 |
|
psedlak joined #minetest-dev |
| 09:57 |
|
PilzAdam joined #minetest-dev |
| 10:03 |
|
whirm joined #minetest-dev |
| 10:36 |
|
nore_ joined #minetest-dev |
| 10:36 |
nore_ |
I have an idea about a "shapechanging" nodebox type |
| 10:37 |
nore_ |
the 8 first boxes of the nodebox could be toggled visible or not by the 8 bits in param2 |
| 10:38 |
PilzAdam |
RBA had that idea a while ago |
| 10:38 |
PilzAdam |
but its not very effective |
| 10:38 |
nore_ |
I could do it, but is it a good idea and would it be merged? |
| 10:38 |
nore_ |
why? |
| 10:38 |
nore_ |
stairplus could use only 1 node, as pipeworks, etc |
| 10:39 |
nore_ |
technic cables too |
| 10:39 |
PilzAdam |
e.g. mesecons would need a node with about 20 nodeboxes to get all the wires in one node |
| 10:39 |
nore_ |
no, mesecons need 9 boxes |
| 10:39 |
nore_ |
so 2nodes |
| 10:40 |
PilzAdam |
AFAIK currently one pipeworks node has 20 nodeboxes |
| 10:40 |
nore_ |
instead of 64 curently |
| 10:40 |
PilzAdam |
so it wouldnt be useable in this mod at all |
| 10:41 |
nore_ |
pipeworks has only 6 boxes for tubes, I dont know for pipes |
| 10:41 |
PilzAdam |
8 boxes is just too restrictive, IMO |
| 10:42 |
nore_ |
it is much better than nothing |
| 10:42 |
nore_ |
but else it could be done in meta |
| 10:42 |
nore_ |
and you can get 32 boxes |
| 10:43 |
nore_ |
but I dont know if node meta is accessible to the client |
| 10:43 |
PilzAdam |
of course it is |
| 10:44 |
nore_ |
then it can probably be done |
| 10:44 |
PilzAdam |
there was a branch about setting nodedef in meta somewhere |
| 10:44 |
nore_ |
where is it? it is exactly what we need |
| 10:45 |
nore_ |
it is even better |
| 10:47 |
PilzAdam |
https://github.com/celeron55/minetest/commits/meta_set_nodedef_2 |
| 10:47 |
PilzAdam |
there are some problems with it, though |
| 10:48 |
PilzAdam |
and that BKVL stuff has to wait until 0.5.0 since it breaks compatibility |
| 10:49 |
nore_ |
what are those problems? |
| 10:57 |
nore_ |
but doing a shapechanging nodebo |
| 10:58 |
nore_ |
x could be useful, or not? would it be merged? |
| 11:08 |
celeron55 |
well, i can think of a way to make the original suggestion of nore_ work |
| 11:08 |
|
Calinou joined #minetest-dev |
| 11:08 |
PilzAdam |
64 bit param2? ;-) |
| 11:09 |
celeron55 |
it could be done so that in the node definition, there would be a list of lists of nodebox indices, and the used list would be selected directly via param2 value |
| 11:09 |
celeron55 |
altough |
| 11:09 |
celeron55 |
that doesn't give more than 8 bits of freedom |
| 11:10 |
celeron55 |
it assumes that some of the 8 bit configurations would be useless |
| 11:11 |
celeron55 |
(it allows more boxes though) |
| 11:12 |
celeron55 |
i don't know if this is wanted though |
| 11:12 |
celeron55 |
or more like accepted |
| 11:13 |
celeron55 |
i mean, what about textures, for example? |
| 11:14 |
celeron55 |
it would end up quite restrictive |
| 11:42 |
nore_ |
perhaps some other param2 that would allow to choose textures in a list too? |
| 12:08 |
PilzAdam |
and what about <insert random field of nodedef>? |
| 12:11 |
nore_ |
what field? |
| 12:12 |
nore_ |
i dont think other fields could be needed |
| 12:13 |
celeron55 |
you're very wrong |
| 12:13 |
nore_ |
and about meta_set_nodedef, why does bkvl break compatibility? |
| 12:13 |
nore_ |
celeron55, what field? |
| 12:16 |
celeron55 |
even if they were nothing currently, we're highly likely to have something in the future |
| 12:16 |
celeron55 |
or someone will want to have something either way |
| 12:16 |
celeron55 |
there* |
| 12:17 |
nore_ |
but in what way does bkvl break compatibility? |
| 12:17 |
celeron55 |
what kind of a question is that |
| 12:17 |
celeron55 |
it's a completely different serialization format |
| 12:18 |
celeron55 |
more specifically it breaks backwards compatibility; but that's not an issue |
| 12:18 |
celeron55 |
the issue is developing it to be mature enough for actual usage, which it is far from |
| 12:19 |
nore_ |
but there could be no way to connect an old client to a new server if the server knows the version of the client? |
| 12:19 |
celeron55 |
no |
| 12:19 |
celeron55 |
there is no system and will never be any system to translate node metadata that way |
| 12:19 |
celeron55 |
or, well, any kind of translation wouldn't be enough either |
| 12:20 |
nore_ |
so metadata replaces nodedef completely? |
| 12:20 |
celeron55 |
i mean |
| 12:20 |
nore_ |
nodedef of normal nodes is not sent to clients? |
| 12:20 |
celeron55 |
you can connect, but nodes that would use that thing will only be seen in their default look and behavior on old clients |
| 12:21 |
celeron55 |
and at the same time the protocol compatibility might be reset so that it doesn't work anyway to get rid of convoluted compatibility code (there's plenty of that currently) |
| 12:21 |
nore_ |
is that really a problem? because it is the same with leveled nodeboxes |
| 12:22 |
celeron55 |
yes it is and i won't explain it any further; you can expect such clean-ups once in a while |
| 12:22 |
celeron55 |
however i have no idea when it might happen; not in near future |
| 12:23 |
celeron55 |
also there are some devs that do argue against the meta_set_nodedef style thing |
| 12:23 |
nore_ |
it was said it will be with the release of 0.5.0, but that will be in a long time |
| 12:23 |
nore_ |
who is against it? |
| 12:24 |
celeron55 |
what do you do with that information |
| 12:25 |
nore_ |
nothing, it is just being curious... ;) |
| 12:25 |
celeron55 |
well, not telling it now anyway; it's pretty much offtopic currently |
| 12:28 |
celeron55 |
(i try to spare people from useless feature wars so that they can get something done instead in their little time) |
| 12:47 |
|
Taoki joined #minetest-dev |
| 12:56 |
|
proller joined #minetest-dev |
| 13:30 |
|
serengeor joined #minetest-dev |
| 13:36 |
|
Neological joined #minetest-dev |
| 14:00 |
|
jin_xi joined #minetest-dev |
| 14:11 |
|
EdB joined #minetest-dev |
| 14:21 |
|
darkrose joined #minetest-dev |
| 14:21 |
|
darkrose joined #minetest-dev |
| 14:49 |
|
Jordach joined #minetest-dev |
| 15:03 |
|
Calinou joined #minetest-dev |
| 15:14 |
|
nore joined #minetest-dev |
| 15:19 |
|
hmmmm joined #minetest-dev |
| 15:31 |
|
sapier joined #minetest-dev |
| 15:32 |
sapier |
https://github.com/minetest/minetest/commit/0d60bc55e4373167141f0f08a10a2174cc7e029a sometimes ppl should fix issues instead of adding hacks |
| 15:56 |
|
rubenwardy joined #minetest-dev |
| 16:02 |
|
PilzAdam joined #minetest-dev |
| 16:08 |
Exio4 |
PA was waiting for you sapier, but you didn't appear :P |
| 16:10 |
PilzAdam |
sapier, feel free to fix it in a proper way |
| 16:10 |
PilzAdam |
I am not familiar with the main menu code |
| 16:11 |
PilzAdam |
it was just too annyoing that Minetest takes over 10 seconds to start when you download something else |
| 16:12 |
sapier |
I'm wayting for vanessa to give feedback about my asyncronous server list prototype ... maybe she already gave it but I've been a little bit busy |
| 16:12 |
sapier |
-y+i |
| 16:12 |
Exio4 |
lazy curl? ;P |
| 16:12 |
PilzAdam |
kahrl is working on a more generic implementation of that |
| 16:13 |
sapier |
exactly similar too the async lua system I once suggested |
| 16:13 |
sapier |
more generic? |
| 16:13 |
PilzAdam |
I think its this branch: https://github.com/kahrl/minetest/commits/httpfetch |
| 16:14 |
sapier |
and what is more generic about this? |
| 16:14 |
PilzAdam |
I was told it is |
| 16:14 |
sapier |
it's just another special case that is needed too |
| 16:14 |
sapier |
async file download |
| 16:15 |
sapier |
doesn't help for json files |
| 16:15 |
sapier |
unless you add a full json to luatable parser ;-) |
| 16:16 |
sapier |
but combining with this https://github.com/sapier/minetest/tree/asynchronous_events |
| 16:16 |
sapier |
will fix the issue |
| 16:16 |
sapier |
s |
| 16:17 |
|
Calinou joined #minetest-dev |
| 16:19 |
sapier |
does anyone understand why this is so much code? |
| 16:19 |
sapier |
ahh ok he wants to replace the normal download too |
| 16:20 |
PilzAdam |
the internal API for that does not depend on cURL |
| 16:20 |
sapier |
if this is added it will |
| 16:21 |
Exio4 |
he wants to abstract the whole "http" code ;P |
| 16:21 |
sapier |
unless he's removing the dependency until he finished it |
| 16:21 |
PilzAdam |
that is what I meant with "more generic" |
| 16:21 |
sapier |
imho it's not generic enough the async calls I tried to add aren't as specific as "download something" |
| 16:21 |
PilzAdam |
sapier, I mean outside of the httpfetch.* files |
| 16:22 |
sapier |
and the lua version I proposed some months ago would even have been usable directly from mods |
| 16:22 |
sapier |
does he know about the async events? |
| 16:22 |
sapier |
I posted this some days ago but not very loud |
| 16:22 |
PilzAdam |
he is aware of your code |
| 16:23 |
PilzAdam |
he said that his code would be a more generic solution |
| 16:23 |
PilzAdam |
IIRV |
| 16:23 |
PilzAdam |
*C |
| 16:23 |
sapier |
ok what is more generic that two unspecified callbacks? |
| 16:23 |
sapier |
:-) |
| 16:23 |
PilzAdam |
it adds the httpfetch interface for the whole core, not only for the main menu |
| 16:24 |
sapier |
yes but it's limited to http ;-) |
| 16:25 |
sapier |
ok I guess I need to talk with himself maybe some information is lost by retelling what he wants to do |
| 16:28 |
PilzAdam |
<sapier> imho it's not generic enough the async calls I tried to add aren't as specific as "download something" <- can you explain that further? |
| 16:28 |
sapier |
https://github.com/sapier/minetest/commit/c900051f68fa01cc8e58034f934eb009abbe2885 guiEngine.h |
| 16:28 |
sapier |
line 60 |
| 16:29 |
celeron55 |
sapier: kahrl has a huge branch where he has reworked much of the lua and main menu code |
| 16:29 |
sapier |
do you have a link celeron? |
| 16:29 |
celeron55 |
for combining the APIs and for header optimizations |
| 16:29 |
celeron55 |
and stuff |
| 16:29 |
PilzAdam |
the omnicleanup branch in his repo |
| 16:29 |
sapier |
great ... that's ironic |
| 16:29 |
celeron55 |
you pretty much need to work with kahrl for whatever you do now to it |
| 16:29 |
celeron55 |
(until it's merged in some form) |
| 16:30 |
sapier |
the apis have ben separated on purpose |
| 16:31 |
sapier |
ok I'll have a look at it firs |
| 16:31 |
celeron55 |
(i don't actually know what the branch exactly does; kahrl hasn't yet written a summary about it (that he intends to)) |
| 16:32 |
celeron55 |
also, it's so huge you'll have tough time looking at it :P |
| 16:35 |
PilzAdam |
sapier, the httpfetch branch does a pretty similiar thing |
| 16:38 |
VanessaE |
sapier: I'm waiting for the httpfetch branch to go through, rather than test your patch |
| 16:41 |
sapier |
I wonder why ppl always think they don't need return values |
| 16:43 |
VanessaE |
bbl |
| 16:50 |
sapier |
I guess making main engine independet from componets was to ambitions to be preserverd for more than a month ... back to old style c programming |
| 16:51 |
sapier |
vanessae the http engine wont fix modstore nor big serverlists unless completely redone I don't see any of the similaritys pa is talking about |
| 16:51 |
sapier |
both use threads yes ... but that's not a similiarity |
| 16:52 |
sapier |
but I guess I should wait for more comments until tomorrow after seeing that after 2 weeks not beeing active everything I did was reclaimed |
| 16:53 |
sapier |
btw I'm still waiting for 774 640 and 418 |
| 16:54 |
sapier |
and yes not adding them will push pa's simplemods |
| 16:54 |
sapier |
so if you want to make mobf die it's best to not add those |
| 17:02 |
|
sapier1 joined #minetest-dev |
| 17:17 |
sapier1 |
not a single comment to 774 640 and 418? Guys I want a decision either add it or drop it I want to continue mobf development |
| 17:18 |
PilzAdam |
640 and 418 are good, I guess |
| 17:19 |
sapier1 |
ok and what's the issue with 774? maybe it can be fixed? |
| 17:19 |
PilzAdam |
wasnt there a compatibility problem? |
| 17:20 |
sapier1 |
not really |
| 17:20 |
sapier1 |
it seemed to be but it isn't |
| 17:22 |
PilzAdam |
then its good |
| 17:23 |
sapier1 |
ok if it's good plz add .. if you don't feel fine about the last one add the two others first |
| 17:23 |
PilzAdam |
the lua-api.txt part is messed up, though |
| 17:24 |
sapier1 |
no it isn't I just can't document things I don't know what they're doing |
| 17:24 |
sapier1 |
at least not exactly |
| 17:24 |
PilzAdam |
then why do you add lines with them? |
| 17:25 |
sapier1 |
because someone (I don't know who was sleeping when adding it) has to fix this |
| 17:25 |
PilzAdam |
also you should explain that frame_speed is adjusted according to base_velocity and the objects velocity |
| 17:26 |
sapier1 |
what about this sentence "if this is set animation framerate is adjusted dependent on frame speed and this velocity" |
| 17:27 |
sapier1 |
better "if this is set animation framerate is adjusted dependent on frame speed, this velocity and objects xz velocity" |
| 17:28 |
PilzAdam |
hm, why only xz? |
| 17:29 |
sapier1 |
because z velocity is rarely usefull for horizontal movement |
| 17:29 |
sapier1 |
y of course |
| 17:29 |
PilzAdam |
think about e.g. birds |
| 17:29 |
sapier1 |
if you really want to add this you need a completely different system |
| 17:30 |
|
ssieb joined #minetest-dev |
| 17:30 |
sapier1 |
e.g. not use a single velocity but multiple and to be more exact you need models supporting differend overlayd animations |
| 17:32 |
sapier1 |
imho xz is a fair solution not beeing overcomplicated while providing much benefit |
| 17:36 |
|
QwertyCyclone joined #minetest-dev |
| 17:51 |
|
neko259 joined #minetest-dev |
| 17:52 |
sapier1 |
https://github.com/minetest/minetest/pull/774 better? |
| 17:58 |
|
Akien joined #minetest-dev |
| 18:00 |
|
Zeitgeist_ joined #minetest-dev |
| 18:01 |
|
ssieb joined #minetest-dev |
| 18:42 |
|
sokomine joined #minetest-dev |
| 18:42 |
sokomine |
would it be possible to teach mt not to self-destruct if there's no more space on disk? |
| 18:43 |
Tesseract |
if (space_on_disk < MIN_SPACE) { throw std::exception("Not enough space on disk")} |
| 18:44 |
sapier1 |
sokomine do you think something like disabling mapgen instead? |
| 18:45 |
Tesseract |
There is a read-only mode for the map. You would just have to trigger that. |
| 18:46 |
sokomine |
started it with no space left free, and instead of complaing, it just happily deleted favoriteservers.txt and minetest.conf. those ought to be restorable...there have been other occasions when it deleted world config files, player config files etc |
| 18:46 |
sapier1 |
ok that's like that and even better yes |
| 18:46 |
sapier1 |
what ? deleted those files? |
| 18:46 |
sapier1 |
it never should delete those files unless a new one is already present |
| 18:46 |
sokomine |
yes, something like what tesseract wrote might be a good idea. no point in running a server if it can't be run anyway |
| 18:47 |
sapier1 |
yes but that's not the issue you actually mentioned ;) |
| 18:47 |
sokomine |
not really deleted. set to zero bytes. as it loves to do when space is tight :-( |
| 18:47 |
sapier1 |
those crucial config files never shall be deleted without having a backup |
| 18:47 |
sapier1 |
that's same as deleting |
| 18:48 |
sapier1 |
a sane solution would write the new file and rename it to minetest.conf for example |
| 18:49 |
|
iqualfragile_ joined #minetest-dev |
| 18:49 |
sokomine |
luckily, i was puzzled by the strange font and didn't start a world. it would probably have been set to zero as well (at least the config files. and if those change the mapseed changes and the world starts looking ugly at best) |
| 18:53 |
sokomine |
and the first mapgen-bug that happened on redcrabs server was due to low disk space as well. detecting too low disk space may save a lot of buildings |
| 19:01 |
celeron55 |
sapier1: it's the long running matter of minetest not writing to a temporary file and then moving into place |
| 19:01 |
celeron55 |
nobody has wanted to ever fix it |
| 19:02 |
celeron55 |
the problem and the fix has been always known; it's the coder what is missing |
| 19:02 |
sapier1 |
I guess I should write some lines of code to trigger someone to write it himself ... |
| 19:02 |
sapier1 |
sorry I'm a little bit ironic today |
| 19:02 |
celeron55 |
8D |
| 19:03 |
celeron55 |
it shouldn't be taken too personally if things happen to take multiple iterations |
| 19:03 |
sokomine |
perhaps each individual occourance of that bug is too annoying to one person only each time and only for a short time :-( |
| 19:03 |
celeron55 |
the first ones always serve as inspiration and proposals |
| 19:03 |
celeron55 |
and as initial testing |
| 19:04 |
sapier1 |
if I did take this to personaly I'd have left some hours ago ... but I'm reasonable enough to realize if some changes really are in right direction (in most parts) |
| 19:05 |
sapier1 |
no sokomine this bug just is to simple to be fixed ;-) |
| 19:07 |
|
Jordach_ joined #minetest-dev |
| 19:12 |
|
kaeza joined #minetest-dev |
| 19:22 |
kahrl |
10 print "Hello World!"; 20 goto 10 |
| 19:23 |
sapier1 |
hello kahrl ... the one I was looking for |
| 19:23 |
sapier1 |
what's your intention about the http thing? |
| 19:23 |
kahrl |
oh okay, was going to ask about the lua thing first, but alright |
| 19:24 |
kahrl |
if it turns out to be needed we can add your async thing anyway |
| 19:24 |
sapier1 |
that's mostly fine ... I guess the core modules independent design was to ambitions for minetests c style |
| 19:24 |
kahrl |
does loading favorite servers from a file really take any noticeably amount of time? |
| 19:24 |
kahrl |
s/bly/ble |
| 19:25 |
sapier1 |
it's not the loading time but the parsing issue |
| 19:25 |
kahrl |
is jsoncpp that slow? |
| 19:25 |
sapier1 |
sorry I think we're talking about different things |
| 19:25 |
kahrl |
I can't really believe that |
| 19:26 |
kahrl |
maybe; I haven't really looked at the serverlist loading code |
| 19:26 |
sapier1 |
my aproach aimed towards a generic threading interface that could be used for different things not only http download |
| 19:27 |
kahrl |
I think SimpleThread is fine for that |
| 19:27 |
sapier1 |
the favorites list was only a proof of concept ... it's slow when you don't have a online connection and need to wait for timeout |
| 19:27 |
sapier1 |
no it isn't |
| 19:27 |
kahrl |
or do you mean coding threads in lua? |
| 19:27 |
sapier1 |
you need a way to pass back the result |
| 19:27 |
sapier1 |
starting a thread is only half of the job |
| 19:28 |
sapier1 |
no not lua ... that's a thing I suggested months ago without success this is a interface to make asyncronous lua api calls only |
| 19:29 |
sapier1 |
favourites list is one example |
| 19:29 |
sapier1 |
e.g. you request the favorite list to be downloaded |
| 19:29 |
sapier1 |
if it's completed you get an event |
| 19:29 |
celeron55 |
my view on things is that it's generally best to actually code fast code and only do the things asynchronously that really need to be; it limits the variety of bugs that can happen |
| 19:29 |
sapier1 |
if it never completes the gui is still responsive |
| 19:29 |
sapier1 |
celeron you can't code your internet connection |
| 19:30 |
kahrl |
httpfetch solves that problem |
| 19:30 |
celeron55 |
of course a network operation should be done asynchronously |
| 19:30 |
sapier1 |
no it doesnÄ't |
| 19:30 |
kahrl |
sapier1: why not? |
| 19:30 |
sapier1 |
what will the downloaded serverlist be good for? |
| 19:30 |
sapier1 |
we don't have a json parser in lua |
| 19:31 |
kahrl |
you can make httpfetch_async calls in cpp too |
| 19:31 |
sapier1 |
and how to pass back the result to lua? |
| 19:31 |
kahrl |
call a callback? |
| 19:31 |
sapier1 |
not an option for mainmenu |
| 19:31 |
celeron55 |
also why not download the server list in lua and just call a C++ function to parse it |
| 19:32 |
kahrl |
celeron55: or that |
| 19:32 |
sapier1 |
is another way to do it but this way you need to rewrite everything |
| 19:32 |
sapier1 |
we already had code to download as well as parse |
| 19:32 |
kahrl |
it's really strange to me that a file called convert_json.cpp contains HTTP fetching code right now |
| 19:32 |
celeron55 |
everything? |
| 19:32 |
celeron55 |
not likely |
| 19:33 |
sapier1 |
names ... |
| 19:33 |
sapier1 |
of course we have code that downloads a and parses in json |
| 19:34 |
kahrl |
I think it's unneeded coupling |
| 19:34 |
kahrl |
what if you want to download something that is not json? |
| 19:34 |
sapier1 |
maybe but the way you suggest you need a generic json -> lua converter |
| 19:34 |
sapier1 |
of course this is by far best solution |
| 19:34 |
kahrl |
doesn't sound hard |
| 19:35 |
sapier1 |
no but in doing so you move error checking to lua too |
| 19:35 |
kahrl |
sure, why not? |
| 19:35 |
sapier1 |
imho errors should be recognized as soon as possible |
| 19:36 |
kahrl |
then you'd have to write a json parser yourself and abort as soon as you see an unknown key ;) |
| 19:36 |
celeron55 |
here's a pure lua json parser in 375 lines: http://hg.prosody.im/trunk/file/tip/util/json.lua |
| 19:36 |
celeron55 |
8) |
| 19:36 |
sapier1 |
first converting a maybe 1mb json table to lua just to realize it's a modstore list instead of a favourites list seems wrong to me |
| 19:36 |
celeron55 |
(and encoder) |
| 19:36 |
celeron55 |
(and a test for them) |
| 19:36 |
kahrl |
sapier1: unlikely to happen, so doesn't seem like a big problem |
| 19:37 |
sapier1 |
sorry why do we still want to move code that obviously isn't fast if you don't have jit |
| 19:37 |
sapier1 |
it's unlikely to happen to not have an internet connection too still it seems to be a problem for some ppl |
| 19:37 |
celeron55 |
(anyway making C code for converting json to lua would probably be best) |
| 19:38 |
PilzAdam |
if you dont have one its not a problem, the problem is if its slow |
| 19:38 |
celeron55 |
it's largely completely trivial |
| 19:38 |
sapier1 |
it's a parser ... as long as no errors occur it's trivial catching all error cases isn't trivial |
| 19:38 |
sapier1 |
and still the callback issue remains |
| 19:39 |
kahrl |
engine.async_handler? |
| 19:39 |
sapier1 |
kahrl's http threads are just another threading system limited to download |
| 19:40 |
sapier1 |
where to trigger? |
| 19:40 |
sapier1 |
you can't trigger this from the executed thread |
| 19:40 |
kahrl |
check httpfetch_async_get in guiEngine's main loop |
| 19:40 |
sapier1 |
add it |
| 19:41 |
sapier1 |
and if you're already doing so plz add id's to issue multiple parallel downloads |
| 19:41 |
kahrl |
of course parallel downloads will be supported |
| 19:42 |
sapier1 |
btw celeron55 fast code is worth nothing ... I just removed pathfinding from mobf because of even A* is way to slow |
| 19:42 |
sapier1 |
the only way to use it would be asyncronous to not interfere with server main loop |
| 19:43 |
kahrl |
sapier1, use an incremental variant of A*? |
| 19:44 |
sapier1 |
doesn't help A* may be used for 5 or 50 mobs in same server step no way to predict |
| 19:44 |
Tesseract |
IMO Lua should have access to JSON. Something like minetest.http_get("<serverlist url>", function(result) menu.serverlist = minetest.parse_json(result) end) |
| 19:44 |
kahrl |
A* is slow when no path exists, which can be the case very often |
| 19:45 |
sapier1 |
exactly and risk of no path to exist increases drasticaly the more mobs try to find a path |
| 19:46 |
sapier1 |
thus the only sane way to use A* would be use as much cpu power as not used by more important tasks |
| 19:46 |
sapier1 |
but that can't be done right now |
| 19:46 |
kahrl |
perhaps maintain a list of connected components |
| 19:47 |
kahrl |
and immediately return that the path doesn't exist if the endpoints are in different components |
| 19:47 |
sapier1 |
what do you mean with components? |
| 19:47 |
kahrl |
sets of connected nodes |
| 19:47 |
sapier1 |
that compinent list needs to be updated on any map change |
| 19:47 |
kahrl |
of course |
| 19:48 |
sapier1 |
so you add more ram usage and shift cpu power to building ;-) |
| 19:48 |
kahrl |
and updated on loading and unloading of mapblocks too |
| 19:48 |
sapier1 |
possible ... maybe even a setup exists where this works ... but infrastructure for keeping that information is a lot of work |
| 19:49 |
kahrl |
of course it would need to optional, no need to calculate all that without some mobs |
| 19:49 |
kahrl |
to be* |
| 19:49 |
sapier1 |
for now benefit of pathfinding movement to more simple movement isn't that big it'd be worth it |
| 19:50 |
kahrl |
yeah, makes sense to get the basic system working and performant first before working on this |
| 19:50 |
sapier1 |
there are some cases where pathfindig results in more smart mobs but most time difference is hardly noticable |
| 19:50 |
kahrl |
e.g. the entity duplication issues |
| 19:51 |
sapier1 |
one situation is e.g. if you dig a U and place a mob inside ... without pathfinding it'll never realize to move back to get to the other side |
| 19:52 |
kahrl |
you could make A* limited so that it only tries a very limited amount of non-straight paths |
| 19:52 |
kahrl |
should have good performance while doing the pathfinding job in simple cases like the U |
| 19:53 |
sapier1 |
not exactly |
| 19:53 |
sapier1 |
A* is no wonderweapon it's only as good as your heuristic fits your situation |
| 19:53 |
sapier1 |
if you optimize it for U it may terribly fail for L for example ;-) |
| 19:54 |
sapier1 |
the current A* algorithm uses most common manhattan distance heuristic |
| 19:56 |
sapier1 |
something different kahrl what do you think about 774 640 and 418? |
| 19:57 |
kahrl |
haven't thought about them |
| 19:58 |
sapier1 |
plz think about them ;-) need them or something different for improving mobs |
| 20:00 |
kahrl |
well for #774 I don't know a bit about model animation |
| 20:02 |
kahrl |
wait why XZScalar and not hypot? |
| 20:02 |
sapier1 |
ok but the other ones? |
| 20:03 |
kahrl |
what did you mean by "if you really want to add this you need a completely different system"? |
| 20:04 |
sapier1 |
movement has 3 directions ... simplified this could be mapped to 2 |
| 20:05 |
sapier1 |
still if you'd specified 2 different orientations you'd need 2 animations beeing played at same time |
| 20:05 |
sapier1 |
and y movement animations aren't used anywhere by now |
| 20:06 |
sapier1 |
so 1) not used for anything and noone has any common usecase |
| 20:06 |
sapier1 |
2) way more complex |
| 20:06 |
sapier1 |
3) no support for multiple animations at a single model at same time |
| 20:06 |
kahrl |
can't you just take the norm of m_velocity in updateAnimationSpeed()? |
| 20:07 |
sapier1 |
yes but what should this be usefull? a mob for example dropping straigt down will run like hekk |
| 20:07 |
sapier1 |
-ll |
| 20:07 |
kahrl |
PA's example of a bird |
| 20:08 |
sapier1 |
do you now of any bird moving up in a staight line? |
| 20:08 |
PilzAdam |
yes, Kolibri can AFAIK |
| 20:08 |
PilzAdam |
"hummingbird" in english |
| 20:08 |
sapier1 |
ok pilzadam implement it in simplemobs and add the feature when needed ;-P |
| 20:08 |
kahrl |
well, we're also not trying to be 100% realistic |
| 20:09 |
PilzAdam |
just thinking about mobs here is too restrictive |
| 20:09 |
sapier1 |
so what do you prefere using y too resulting in constant animation failures in most common drop case |
| 20:09 |
kahrl |
but I guess if the need arises support for using the norm of the whole vector can be added later |
| 20:09 |
sapier1 |
or a small (most likely unnoticable error) for not even implemented kolibris |
| 20:10 |
kahrl |
well, of course it would just use X and Z unless Y is specifically enabled |
| 20:10 |
PilzAdam |
a new parameter |
| 20:10 |
sapier1 |
if you want an additional parameter this can be added later thus is no reason to NOT add this one |
| 20:11 |
kahrl |
the most generic way would probably to define a matrix A and use sqrt(x' * A * x) |
| 20:11 |
sapier1 |
there's always a thing to make even better I'm anoyed to be asked for features nobody uses just to have an excuse to not add my commits |
| 20:12 |
kahrl |
as I said I don't know about animations so I wouldn't be the one to OK your commit anyway |
| 20:13 |
sapier1 |
I don't deny y movement would be fine too but it's of very limited use and at least for me it's not worth the effort ... it can be added afterwards if someone really needs it |
| 20:18 |
PilzAdam |
I dont like this "design by request" |
| 20:18 |
kahrl |
typo in 640: serachup |
| 20:18 |
PilzAdam |
we should think ahead |
| 20:19 |
kahrl |
and methods of ServerEnvironment should be called getSurface, not get_surface |
| 20:19 |
kahrl |
should it be a method of ServerEnvironment anyway? |
| 20:19 |
kahrl |
not ServerMap or Map? |
| 20:20 |
|
khonkhortisan joined #minetest-dev |
| 20:22 |
kahrl |
there are quite similar methods ServerEnvironment::line_of_sight, ClientMap::isOccluded, ServerEnvironment::get_surface, wonder if they can be merged into a single one |
| 20:23 |
sapier1 |
no they're completely different |
| 20:23 |
sapier1 |
line of sight just tells true/false get_surface tells position of surfacde |
| 20:23 |
sapier1 |
isOccluded could be similar to line of sight yes |
| 20:25 |
kahrl |
line_of_sight and isOccluded could return the occlusion position as well |
| 20:25 |
kahrl |
if there is no such position -> not occluded |
| 20:25 |
kahrl |
of course they check different nodedef members than get_surface |
| 20:26 |
sapier1 |
true you'd need to specify what to look for too |
| 20:26 |
kahrl |
perhaps a pointer-to-member of ContentFeatures |
| 20:26 |
kahrl |
that might get weird though |
| 20:27 |
sapier1 |
don't know |
| 20:30 |
kahrl |
or simply a bool (*)(const ContentFeatures&) |
| 20:32 |
kahrl |
anyway, about the cleanup thing |
| 20:32 |
kahrl |
why did you want to completely separate the two lua APIs? |
| 20:34 |
sapier1 |
primary intention was to not interfere with modapi and of course modapi was built in a way that reuse of core components wasn't possible |
| 20:35 |
sapier1 |
but as you changed scriptapi back to close linkage to modding modules this issue is gone |
| 20:36 |
kahrl |
what do you mean by close linkage? |
| 20:36 |
kahrl |
the decision what modules go into each modding api is still in script/lua_api/ |
| 20:36 |
kahrl |
script/lua_api/luaapi.cpp to be precise |
| 20:37 |
sapier1 |
exactly original code wasn't intended to have a single code location that needs to now what to initialize |
| 20:37 |
sapier1 |
the for loop you removed |
| 20:38 |
sapier1 |
the way you do it it isn't even necessary to derive the classes they're derived right now |
| 20:38 |
kahrl |
yeah, but that makes it hard to define multiple different modding APIs |
| 20:38 |
kahrl |
e.g. what if you want to add a client side modding API |
| 20:38 |
sapier1 |
yes that wasn't a design goal for scriptapi noone thought about making main menu lua that time |
| 20:38 |
sapier1 |
client side modding api needs to be completely different |
| 20:39 |
kahrl |
not completely; it could easily reuse some parts from l_util.cpp |
| 20:39 |
sapier1 |
it'd be absolutely insane to add a lua engine beeing that powerfull executing code sent by server |
| 20:39 |
kahrl |
(remove the settings part, maybe) |
| 20:39 |
sapier1 |
no no no |
| 20:39 |
sapier1 |
remove anything with file system access too |
| 20:40 |
kahrl |
I never said to leave those in... |
| 20:40 |
sapier1 |
remove debug features process launching ... |
| 20:40 |
sapier1 |
serialization needs to be redone too |
| 20:41 |
sapier1 |
there's a lot of work to be done for clientside and I don't believe it's safe to start with an insecure engine trying to harden it |
| 20:41 |
sapier1 |
at least I will not take that risk |
| 20:42 |
sapier1 |
for mainmenu and modapi this seems more reasonable but you should rethink the deived things too I guess not everything is usefull if doing it this way |
| 20:43 |
kahrl |
yeah, I'm not happy about how ScriptApi is derived from everything |
| 20:43 |
kahrl |
what would you suggest? |
| 20:43 |
sapier1 |
make it c again ... you already dropped the main intention so no need to keep the other relicts |
| 20:44 |
kahrl |
ummm |
| 20:44 |
sapier1 |
main intention == hide what script language is behind it from minetest core |
| 20:44 |
kahrl |
I thought the main intention was to not have a huge single cpp with everything |
| 20:44 |
sapier1 |
as mainmenu is integral part of core this isn't possible if you merge it by definition |
| 20:44 |
kahrl |
and you can't do that now? all the lua calls are in script/ now |
| 20:45 |
kahrl |
in fact it's more possible now than before, as the lua calls from guiEngine.cpp and guiLuaApi.cpp are in script/ now |
| 20:45 |
sapier1 |
you can't hide it from scripts but engine doesn't know anything about lua |
| 20:45 |
sapier1 |
no it isn't |
| 20:46 |
sapier1 |
you could've replaced lua by e.g. python without touching mainmenu before |
| 20:46 |
kahrl |
but I think it's highly unlikely that we'll switch any time soon so that's an academic discussion |
| 20:46 |
sapier1 |
now you need to replace both ... I know both isn't very likely |
| 20:46 |
kahrl |
(there's so much lua around by now) |
| 20:46 |
sapier1 |
most discussions within minetest are academic ;-) |
| 20:47 |
sapier1 |
remember y ... wich noone uses or intends to use |
| 20:48 |
sapier1 |
as I said the way the classes are derived is based on the intention to separate modapi completely from core if this isn't possible anymore it should be redone too |
| 20:48 |
sapier1 |
if not doing so you stop at half way to cleanup |
| 20:49 |
kahrl |
I still don't get what you mean by "separate modapi completely from core" |
| 20:49 |
sapier1 |
but I'm not sure what code really is reused? error handlers? settings ? some init things ? thats all is there more? |
| 20:50 |
kahrl |
how are Register lines scattered throughout script/lua_api different from one luaapi_init_game function? |
| 20:50 |
sapier1 |
my intention was to make moding a completely separated part with defined interface |
| 20:50 |
sapier1 |
the luaapi_init_game needs to know what to initialize |
| 20:51 |
sapier1 |
that wasn't necessary before |
| 20:51 |
kahrl |
tbh I find it cleaner than the macro hacks |
| 20:51 |
sapier1 |
the macro things are only formal |
| 20:52 |
sapier1 |
I added a shell around scriptapi to separate it and ease maintenance |
| 20:52 |
kahrl |
also the only thing that calls luaapi_init_game is ScriptApi |
| 20:52 |
sapier1 |
of course it's benefits would've been visilble in some months/years not right niw |
| 20:53 |
kahrl |
are you saying someone might want to replace everything in script/lua_api but not make a small change in ScriptApi? |
| 20:53 |
sapier1 |
I don't say your way of doing it is bad ... it's just completely opposit direction |
| 20:54 |
sapier1 |
while I tried to encapsulate and isolate the scriptapi you reintegrated it to core |
| 20:54 |
kahrl |
I still don't understand what that means, but I think I never will |
| 20:55 |
sapier1 |
ok have a look at one of our main problems in minetest, |
| 20:55 |
sapier1 |
changeing one thing here may result in breakage there |
| 20:55 |
kahrl |
_no one_ except files in script/ even includes any header from script/lua_api |
| 20:55 |
kahrl |
and they already do so for other reasons, e.g. s_item.cpp includes l_item.h |
| 20:56 |
sapier1 |
kahrl I don't say it's a big difference it's a rather small one but the effect in long term is completely different |
| 20:57 |
sapier1 |
yes they do so for other imho wrong reasons ;-) |
| 20:58 |
sapier1 |
mainmenu and modapi don't have much in common except of beeing both lua and using both settings |
| 20:59 |
sapier1 |
maybe there'd even be a way to make scriptengine even more generic making mainmenu and scriptapi a derived object of that engine |
| 20:59 |
kahrl |
even with the old code you could make a small change, e.g. call fs::RecursiveDeleteContent("..") in l_debug() ;) |
| 20:59 |
kahrl |
just saying that almost no system has full isolation |
| 21:00 |
sapier1 |
I never told any of the lua apis to be safe ... my security fixes have been rejected months ago |
| 21:00 |
sapier1 |
I will not try to add any of them again as It's wasted time |
| 21:01 |
kahrl |
the reason I started doing this is that I wanted to add some utility functions to both APIs |
| 21:01 |
sapier1 |
but I will stop using minetest for sure if client side lua is done that stuporous way (in tems of security) the modapi has been done |
| 21:01 |
kahrl |
urlencode and urldecode in this case |
| 21:02 |
kahrl |
and I saw that I had to repeat that code |
| 21:02 |
sapier1 |
what's urlencode worth if cou can call "os.execute("rm /etc/*") |
| 21:02 |
kahrl |
and other things, e.g. for some reason the mainmenu has setting_setbool but the game API doesn't |
| 21:02 |
kahrl |
what does that have to do with anything |
| 21:03 |
sapier1 |
as I said maybe the component design could be used to merge both code reuse as well as isolation |
| 21:04 |
sfan5 |
what is so bad about mods not being totally isolated? |
| 21:05 |
sapier1 |
less code coupling --> less sideeffects --> less effort to find bugs |
| 21:05 |
sapier1 |
of course removing a single code coupling wont make it good at once |
| 21:06 |
sapier1 |
but with one thing kahrl is right the scriptapi design is bad for component reuse in different engines |
| 21:06 |
kahrl |
I think I already removed some code coupling, master has 6305 total included files whereas omnicleanup has 5131 ;) |
| 21:07 |
kahrl |
counted by my trusted depgraph.py |
| 21:07 |
sapier1 |
what did you remove? |
| 21:07 |
kahrl |
lots of includes from header files |
| 21:07 |
kahrl |
moved some stuff around, changed includes to forward declarations (if needed at all) |
| 21:07 |
sapier1 |
good ... still Imho those init functions aren't the right direction |
| 21:08 |
sapier1 |
but of course they're the most obvious way of doing it |
| 21:08 |
kahrl |
it's also easy to understand so anyone who wants to add a new module should be able to |
| 21:09 |
kahrl |
not that it was hard with your system, but the macros weren't really documented |
| 21:09 |
sapier1 |
it doesn't feel right to have one class beeing a mainmenu or a modapi dependent on what you compile ;-) |
| 21:09 |
kahrl |
yeah, that thing I don't like too much |
| 21:10 |
sapier1 |
I'm not very good in documentation yes |
| 21:10 |
kahrl |
says the only one who doxygens his headers :P |
| 21:10 |
sapier1 |
and the macros have been there to reduce code size ;-P |
| 21:11 |
sapier1 |
you told me not to doxygenify in mintest so I didn't even try to |
| 21:11 |
sapier1 |
I'm very bad in deciding what is obvious and what needs explanation so either I document everything or wrong thing |
| 21:11 |
kahrl |
eh, it doesn't hurt to do it if you write whole new subsystems etc. |
| 21:12 |
kahrl |
but don't make a huge effort to add it to code that doesn't need it |
| 21:12 |
sapier1 |
that's what I said I'm not good in deciding what needs it and what nor ;-P |
| 21:13 |
sapier1 |
imho best way would be a base class engine that can be derived to mainmenu / modapi / clientapi |
| 21:13 |
sapier1 |
sad thing is that class would even require lua lib features to be configurable to be usefull for clientapi |
| 21:14 |
kahrl |
sounds like a plan; what would ModApiBase::getScriptApi() return? |
| 21:14 |
sapier1 |
I suggest this shall return a engine pointer |
| 21:14 |
sapier1 |
but wait do we have dynamic casts available? |
| 21:15 |
sapier1 |
if not the engine pointer can't be used |
| 21:15 |
kahrl |
as long as it's just used for our own classes, we do |
| 21:15 |
kahrl |
(it's not available for irrlicht classes, for example) |
| 21:15 |
kahrl |
what would be the performance impact of a dynamic_cast on every lua api call? |
| 21:16 |
sapier1 |
of course but I don't think it'd be a major one |
| 21:16 |
sapier1 |
lua calls aren't high frequency calls |
| 21:16 |
kahrl |
really? |
| 21:16 |
sapier1 |
really |
| 21:17 |
sapier1 |
high frequenc == x per ns |
| 21:17 |
sapier1 |
I assume lua is in x per ms area ... but that's a guess |
| 21:18 |
kahrl |
maybe there should be classes above ModApiBase |
| 21:18 |
kahrl |
one for in-game APIs and one for mainmenu APIs |
| 21:18 |
kahrl |
they could return the specialized ScriptApi |
| 21:18 |
sapier1 |
not sure |
| 21:18 |
kahrl |
s/classes above/subclasses of |
| 21:19 |
sapier1 |
problem with current design is that a component is registred on constructor |
| 21:19 |
kahrl |
not with omnicleanup |
| 21:19 |
sapier1 |
yes but there you have close coupling between component and main class |
| 21:20 |
sapier1 |
so either increase couling level as you do in omnicleanuo |
| 21:20 |
sapier1 |
or replace by some component registry ... later one sounds like overkill at first glance |
| 21:20 |
kahrl |
it does |
| 21:21 |
sapier1 |
hmm actually that registry does already exist |
| 21:21 |
sapier1 |
if an id was added when a component registers |
| 21:22 |
sapier1 |
initialization could be done by id |
| 21:22 |
sapier1 |
reducing coupling from header to configuration coupling ... not a big difference |
| 21:25 |
sapier1 |
but discussion doesn't make any sense as I wont do it myself this time it's up to you to find a reasonable way to do it |
| 21:25 |
kahrl |
making each component know in which modding APIs it is used is also a kind of coupling |
| 21:26 |
kahrl |
(if I'm getting right what you're saying) |
| 21:26 |
sapier1 |
not the component |
| 21:27 |
sapier1 |
[new top class] --> derived from --> [current class components registred to] |
| 21:27 |
sapier1 |
later one is extended by a call init_component(L,"someid") |
| 21:28 |
sapier1 |
but as I said this is just a minor decoupling as the new class needs to know at least the ids |
| 21:28 |
sapier1 |
another question why did you remove the return value from API_FCT? |
| 21:28 |
kahrl |
registerFunction never returns failure |
| 21:29 |
sapier1 |
and why not fix that? |
| 21:29 |
kahrl |
it's not a problem to assert and abort the program if that fails |
| 21:29 |
kahrl |
imo |
| 21:30 |
kahrl |
or throw a LuaError or something if you want to be fancy and handle the error |
| 21:30 |
sapier1 |
if someone extends registerFunction by duplicate check returning false in this case for exaple? |
| 21:31 |
sapier1 |
that's the //TODO check presence first! |
| 21:31 |
|
Neological joined #minetest-dev |
| 21:31 |
kahrl |
ah, I wondered what that was about |
| 21:32 |
sapier1 |
yea I intended to return false in that case |
| 21:32 |
sapier1 |
obviously I forgot to add |
| 21:32 |
kahrl |
adding a duplicate there is really a programming error so an assert is fine |
| 21:32 |
sapier1 |
it's not an hard error |
| 21:33 |
kahrl |
it is, somebody made a mistake that should be fixed immediately |
| 21:33 |
sapier1 |
you can still continue most of time with a single api call missing |
| 21:33 |
kahrl |
well that's what it does currently |
| 21:34 |
sapier1 |
imho assert is only legit if continuing most likely will cause damage to anything |
| 21:34 |
sapier1 |
in this case most likely nothing bad will happen |
| 21:35 |
kahrl |
if you want to continue, what is the return value for? |
| 21:35 |
kahrl |
just log to e.g. errorstream |
| 21:35 |
sapier1 |
registerFunction is a base function not knowing if this situation is a problem or not the caller knows |
| 21:36 |
sapier1 |
maybe there's even a parameter missing overwrite |
| 21:38 |
kahrl |
I don't foresee such a situation coming up |
| 21:38 |
sapier1 |
security |
| 21:38 |
kahrl |
? |
| 21:38 |
sapier1 |
overwrite builtin fct |
| 21:39 |
kahrl |
API_FCT isn't meant for such anyway |
| 21:39 |
kahrl |
stuff like that should be done by hand |
| 21:39 |
sapier1 |
no it shouldn't |
| 21:39 |
sapier1 |
you want to reuse code |
| 21:40 |
sapier1 |
i will for sure not fetch 20 function names from lua set it push it back |
| 21:40 |
sapier1 |
:-) |
| 21:40 |
kahrl |
adding full security would mean major changes anyway |
| 21:40 |
sapier1 |
no it wouldn't |
| 21:40 |
kahrl |
it's not like registerFunction couldn't be changed |
| 21:41 |
sapier1 |
no it wouldn't the design is already prepared for security ... main changes would be on mod side |
| 21:41 |
kahrl |
you said it was rejected |
| 21:42 |
sapier1 |
yes it was but I don't add designs that are bad |
| 21:42 |
kahrl |
so what's the point? |
| 21:42 |
sapier1 |
the features aren't included but they'd be easy to implement if for some reason ppl get sane |
| 21:43 |
kahrl |
that precondition will never be satisfied |
| 21:43 |
sapier1 |
that's not the point ... you see at current api what happens if you design to current usecase |
| 21:44 |
sapier1 |
it perfectly matched single lua case ... but was proofen wrong when mainmenu was switched to lua too |
| 21:45 |
sapier1 |
hmm I hate the guy doing that ;-) |
| 21:46 |
kahrl |
you don't think you can refactor stuff if it doesn't satisfy the current use case anymore? |
| 21:46 |
sapier1 |
you can refactor twice a week but noone is willing to relearn code structure that often |
| 21:48 |
kahrl |
I don't have a problem with doing that, maybe others do |
| 21:48 |
sapier1 |
but I guess we wont get to a common point the difference between the two aproaches is just to small to give a clean result ... I prefere the decoupled way you the more c style way both have benenfits |
| 21:49 |
kahrl |
most of the time you don't even need to understand 100% of the (refactored) codebase to do something productive |
| 21:49 |
sapier1 |
that's visible everywhere in minetest code .... /ironic |
| 21:50 |
sapier1 |
that's why we're looking for the duplication glitch for months now |
| 21:50 |
sapier1 |
noone really understands what happens |
| 21:50 |
kahrl |
but that code didn't even change once ;) |
| 21:51 |
kahrl |
maybe except for the 49 -> configurable limit |
| 21:51 |
sapier1 |
I guess it will be gone once you remove my disappear fix ... replacing one performance killer bug by an annoying one ... still the real problem most likely isn't my fix but only triggered by it |
| 22:01 |
|
sapier1 left #minetest-dev |
| 22:06 |
kahrl |
does anyone else have an opinion on these issues? |
| 22:06 |
kahrl |
e.g. about how to register modding API modules |
| 22:06 |
|
mrtux joined #minetest-dev |
| 22:43 |
|
kaeza joined #minetest-dev |
| 22:49 |
iqualfragile_ |
pitriss|idle: thanks for telling us that you are now ideling, what a incredibly relevant information |
| 23:12 |
Tesseract |
pitriss|idle: http://kylej.name/irc-away-status.html |
| 23:19 |
PilzAdam |
... another one |
| 23:21 |
|
jin_xi joined #minetest-dev |
| 23:39 |
|
jin_xi joined #minetest-dev |
