| Time |
Nick |
Message |
| 00:14 |
|
sapier left #minetest-dev |
| 01:47 |
iqualfragile |
minetest realy need so me paralisation for some searches |
| 02:10 |
iqualfragile |
& minetest realy needs a primitive for on and of (as used in furnances and mesecons etc |
| 02:10 |
iqualfragile |
) |
| 02:10 |
iqualfragile |
because otherwise its freaking impossible to destroy blinking wires and i suspect that a high amount of bandwidth might be wasted |
| 03:08 |
ShadowNinja |
Wut? I can't parse that first sentence iqualfragile. |
| 03:15 |
iqualfragile |
minetest should execute some things in paralel |
| 03:15 |
iqualfragile |
for example pathfinding could be done in another process |
| 03:16 |
ShadowNinja |
Ah, yes, that's what the Async API is for, although only the mainmenu has access to it ATM. |
| 03:17 |
|
Miner_48er joined #minetest-dev |
| 03:33 |
|
jin_xi joined #minetest-dev |
| 04:07 |
|
ShadowBot joined #minetest-dev |
| 04:07 |
|
BrandonReese joined #minetest-dev |
| 05:10 |
|
kaeza joined #minetest-dev |
| 05:27 |
|
nore joined #minetest-dev |
| 05:51 |
xiong |
Is it acceptable to nest modpacks (so long as each enclosed dir contains an empty modpack.txt)? |
| 05:51 |
nore |
IIRC yes |
| 05:52 |
xiong |
Thanks, nore. |
| 06:01 |
xiong |
Is any work being done towards cascading or included minetest.conf files; and/or managing sets of mods in git? Anything of which I should be aware before I start breaking trail? |
| 06:02 |
BrandonReese |
something like apache does with it's conf.d directory, loads all files in the directory as a config file? |
| 06:03 |
xiong |
Hi, BrandonReese. Some sort of management, you know. Installing a mod is not as simple as dropping it into a dir; there's hair all over. |
| 06:04 |
* BrandonReese |
nods |
| 06:04 |
xiong |
At minimum, I should think it obvious, any mod that accepts config of any sort should ship with its own minetest.conf -- if only as documentation. |
| 06:05 |
xiong |
If that mod-specific file can't be included or called from the main file then this loses half of its usefulness. |
| 06:06 |
BrandonReese |
true. Maybe if the mod includes a minetest.conf or mod.conf file in the mod folder that file is automatically processed like minetest.conf, which I think it kind of what you are getting at |
| 06:06 |
xiong |
As I understand it, that's not now the case. |
| 06:06 |
BrandonReese |
right. |
| 06:07 |
xiong |
I'm of two minds about multiple config files for a given application; there's much to be said for separation of concerns but also for the convenience of knowing that all your conf is in one place. Some mods, the only conf demanded is a line to enable. |
| 06:09 |
xiong |
I think it should be a user choice whether to rely on one big file or join several small ones. The small files might not even be mod-specific; one guy might say "I want all my worlds to be like *this* but I want world 5 to have *that* and *that*." |
| 06:09 |
BrandonReese |
I just remembered some mods are doing their own config file, like technic, pipeworks, moretrees, landrush :) |
| 06:10 |
xiong |
That's another issue -- the private config file. I don't approve... and I'm doing that now. But then, that mod is planned to be half-written in Perl; and the Perl is the only part written so far. |
| 06:10 |
BrandonReese |
I think for multiple worlds it makes the most sense, you have one base file, then load a supplimentary file or files from a directory to fine tune the server config for that world |
| 06:11 |
xiong |
But then, there's also a reason to keep secret the contents of the private conf; so there's that. |
| 06:11 |
VanessaE |
my hods have private config files only because I didn't, at the time those options were added, read config values from minetest.conf. |
| 06:11 |
VanessaE |
mods* |
| 06:11 |
VanessaE |
didn't know how to, that is. |
| 06:12 |
xiong |
Well, VE, if I complain about what you did then it's the pot calling the kettle black. But I do not think it's the right way. |
| 06:12 |
BrandonReese |
I like the private/per world config files. For the sole fact it makes it easy to configure mods differently per world |
| 06:13 |
xiong |
Anyway, I'm working toward an external solution that will concatenate multiple conf files and generate the one big one demanded by the engine. Before I do that I just wanted to check that there wasn't another solution. |
| 06:13 |
xiong |
Everyone will see the feature through a different lens, BR. Which is a good thing. |
| 06:14 |
BrandonReese |
yep |
| 06:15 |
xiong |
In general, I'm working toward a solution for juggling mods for a server through a shell; that does not fight with git, either. And trying to do as little original work as possible. |
| 06:15 |
xiong |
One would like commands as simple as $ borkbork snow enable |
| 06:16 |
xiong |
Or $ borkbork snow checkout <SHA> ... which gets tricky because git doesn't tolerate having its entire dir deleted. |
| 06:18 |
BrandonReese |
You should be able to do a git --reset hard <SHA> instead of deleting the folder and recloning it |
| 06:18 |
xiong |
Um, I mean to say that $ borkbork snow disable -- is not a problem if we go through minetest.conf; but if we delete the dir then we have a devil of a time re-enabling it later. |
| 06:18 |
xiong |
Ah, you are still thinking in terms of one big repo, though, yes? |
| 06:19 |
xiong |
Yet to preserve the integrity of each mod, each mod must be in its own little repo. |
| 06:19 |
xiong |
Otherwise the link to upstream is broken; and there's no obvious way to push to a fork and offer a pull req. |
| 06:20 |
BrandonReese |
No, I'm thinking of individual repos. My setup now is I have a mods folder outside of minetest, git repos when they have one, I symlink from minetest/mods to the mods I want in this outside folder. |
| 06:20 |
xiong |
On the other hand, once one has juggled mods successfully and got a set of them to play nice together -- one would then like to be able to push that and publish the working set. So one needs both the super repo and the subs. |
| 06:21 |
xiong |
Okay, that's another approach I've considered: symlink shootout. |
| 06:21 |
BrandonReese |
I originally did that before the world.mt file because deleting symlinks when I didn't want a mod was eaiser than deleting or moving directories |
| 06:22 |
xiong |
Then there's the two-shelf model, where there's a shelf full of books *and* the one big volume... and you copy back and forth. |
| 06:22 |
|
ImQ009 joined #minetest-dev |
| 06:23 |
xiong |
Lately I've been looking into git-specific strategies, starting with git submodules, which turns out to be a tarpit. Also git subtrees, which also looked good; but apparently bind even tighter than submodules. |
| 06:24 |
xiong |
Today I fussed with gitslave, which binds more loosely, which is good; but is specifically tailored for big projects that contain little projects more or less all done in-house; the home page contents are about half devoted to workarounds for the foreign-repos case. Obviously not a great fit. |
| 06:26 |
xiong |
It's the best approach so far but just way too complex -- overpowered and still does not cover our use-case? http://gitslave.sourceforge.net/tutorial-basic.html |
| 06:26 |
xiong |
Something is wrong with a solution whose *basic* tutorial is that long. |
| 06:27 |
xiong |
We want (a) enable this mod; (b) checkout a different SHA for this mod; (c) disable this mod; and we want to be able to push or pull either the whole thing or any given mod by itself. Simple... in conception. |
| 06:30 |
BrandonReese |
Oh I think I see kind of what you are wanting to do. Yeah pretty complicated to get started it looks like |
| 06:30 |
xiong |
If I don't plan ahead for these tasks then they may be very difficult to do later. |
| 06:31 |
xiong |
I would very much appreciate it if you were able to push your entire world and I could pull it and fiddle with it. |
| 06:31 |
BrandonReese |
failing to plan is planning to fail |
| 06:31 |
BrandonReese |
I'll zip it up so you can download it. Probably do that tomorrow. I should really head to bed |
| 06:31 |
xiong |
However I don't want your world in the shape of a dead stack of trees; my fiddling might reasonably take the shape of pulling upstream. |
| 06:32 |
xiong |
I'll take the zip! Thanks. But it's not what I think serves all of our needs best. Have a nice nap, BrandonReese. |
| 06:33 |
xiong |
Um, zip minus the map itself, neither of us wants to horse that whole big thing around. |
| 06:33 |
BrandonReese |
Oh, I thought that's what you wanted |
| 06:34 |
xiong |
Oh no, the map is of the least interest. If it were smaller I'd not mention it but yours must be up to several GB by now. |
| 06:34 |
BrandonReese |
I'll see what I can do about getting the rest of it in a repo. Maybe send me a forum PM of what exactly you want. |
| 06:34 |
xiong |
The main interest is the setup, the conf, the mods. |
| 06:34 |
BrandonReese |
ok |
| 06:35 |
xiong |
Quite honestly I thought your conf would be enough to tell all. But the specific versions of each mod are critical; and then there's those private conf files and, dunno, mods you've edited on the spot. |
| 06:36 |
xiong |
I progress from blindness to blindness... in hope of less darkness. |
| 06:37 |
xiong |
Anyway, nice chat you, have a nice sleepy... |
| 06:44 |
|
us_0gb joined #minetest-dev |
| 08:06 |
|
werwerwer_ joined #minetest-dev |
| 08:25 |
|
us_0gb joined #minetest-dev |
| 09:02 |
nore |
I have an idea to fix #944: |
| 09:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/944 -- bug: item loss due to moving items out of output-only inventory to an occupied slot |
| 09:03 |
nore |
instead of storing the stack that is under the pointer in an inventory slot, |
| 09:04 |
nore |
store it instead in a special place, and generate metadata_inventory_take/put events (so no metadata_inventory_move anymore, since they won't be needed) |
| 09:05 |
nore |
metadata_inventory_move == metadata_inventory_take then metadata_inventory_put |
| 09:05 |
nore |
any thoughts? |
| 09:37 |
|
sapier joined #minetest-dev |
| 09:42 |
nore |
hi sapier... are inventories in the client/server for you? |
| 10:01 |
sapier |
I think so yes, but I don't know that much about that part yet. If I remember correct a similar suggestion was written here some days ago. Seems to be a valid way to do it |
| 10:22 |
|
rsiska joined #minetest-dev |
| 10:27 |
|
PilzAdam joined #minetest-dev |
| 10:30 |
|
Guest69047 joined #minetest-dev |
| 10:58 |
|
Calinou joined #minetest-dev |
| 11:12 |
nore |
sapier, found it: http://irc.minetest.ru/minetest-dev/2013-12-23#i_3510867 |
| 11:13 |
nore |
well, the conclusion was that get_lists would be useful, which have been added yesterday... |
| 11:39 |
PilzAdam |
/builtin/forceloading.lua:25: attempt to compare string with number |
| 11:39 |
PilzAdam |
add a tonumber() arround setting_get() |
| 11:43 |
xyz |
lol |
| 11:44 |
sapier |
does anyone understand why a mutex protecting the client list is called m_con_mutex? |
| 11:46 |
xyz |
thinking about it, the idea to save list of blocks to forceload is really weird |
| 11:47 |
PilzAdam |
doesnt Minetest generate blocks that are forceloaded? |
| 11:47 |
|
salamanderrake joined #minetest-dev |
| 11:48 |
xyz |
to properly use it this way mods will have to do very complex shit |
| 11:48 |
xyz |
like keeping list of blocks that this mod managed to get loaded |
| 11:48 |
xyz |
saving it to a file as well |
| 11:49 |
xyz |
it's really hard to keep this in sync |
| 11:49 |
xyz |
probably a better idea would be just to not "keep the forceloaded areas after restart" |
| 11:50 |
sapier |
https://gist.github.com/sapier/8383662 ShadowNinja VanessaE could one of you test if this fixes the client connect race condition causing hud not beeing shown? |
| 11:51 |
|
jin_xi joined #minetest-dev |
| 11:51 |
|
mrtux joined #minetest-dev |
| 11:51 |
|
darkrose joined #minetest-dev |
| 11:51 |
|
Exio4 joined #minetest-dev |
| 11:51 |
|
Kray joined #minetest-dev |
| 11:51 |
sapier |
btw this is practically splitting the conlock to quite small parts so next would be env lock |
| 11:52 |
xyz |
nore: ^^^^ |
| 11:52 |
PilzAdam |
minetest.get_position_from_hash() isnt documented in lua-api.txt |
| 11:59 |
|
grrk-bzzt joined #minetest-dev |
| 11:59 |
PilzAdam |
forceloaded blocks are emerged with allow_generate=false ... |
| 12:26 |
|
Gethiox2 joined #minetest-dev |
| 12:31 |
|
bas080 joined #minetest-dev |
| 12:45 |
|
MMN-o joined #minetest-dev |
| 12:50 |
nore |
PilzAdam, I thought I had put a tonumber there... have you already fixed it, or not? |
| 12:54 |
nore |
https://github.com/Novatux/minetest/commit/9a7ebd2a7c4e56e9fb56c94057b7c0b8a734f9bd <-- PilzAdam, is it ok for merging? |
| 12:55 |
nore |
xyz, so you think blocks should not be saved from forceloading after restart? |
| 12:59 |
|
e1z0 joined #minetest-dev |
| 13:20 |
|
e1z0 joined #minetest-dev |
| 13:31 |
PilzAdam |
nore, yes |
| 13:31 |
nore |
ok |
| 13:31 |
nore |
pushed |
| 13:32 |
nore |
what was that thing about allow_generate? |
| 13:34 |
sapier |
if I understand correct pilzadam meant that it isn't usefull to forceload a non generated block ... correct interpretation? |
| 13:34 |
PilzAdam |
yep |
| 13:34 |
nore |
that's strange, because it loads blocks the same way a player does... |
| 13:35 |
nore |
and the player generates blocks... |
| 13:35 |
PilzAdam |
you have to change env.cpp:1150 to true |
| 13:35 |
PilzAdam |
I may be wrong, though |
| 13:36 |
nore |
how did the player generate the world previously then? |
| 13:37 |
PilzAdam |
in RemoteClien::GetNextBlocks() ? |
| 13:37 |
PilzAdam |
+t |
| 13:38 |
nore |
ah... so it was not in the activate code |
| 13:38 |
nore |
anyway, those blocks near the player need to be generated too, so I will do that fix |
| 13:39 |
nore |
should I push the fix? |
| 13:39 |
sapier |
are you sure about the generation thing? |
| 13:39 |
PilzAdam |
what fix? |
| 13:40 |
PilzAdam |
sapier, not at all |
| 13:40 |
nore |
the change from "false" to "true" |
| 13:40 |
PilzAdam |
better dont do that |
| 13:40 |
sapier |
I'd like to have someone who knows generation code better then me to judge this change |
| 13:40 |
PilzAdam |
I guess its there for a reason |
| 13:40 |
nore |
perhaps test it a but before... |
| 13:41 |
sapier |
I have quite a lot of work with locks because of minetest doesn't honor clients need to be initialized prior sending messages to them ... did work on pure chance by now |
| 13:42 |
sapier |
generating things that haven't been generated before may cause similar effects |
| 13:42 |
sapier |
+timing |
| 13:46 |
nore |
... it does not seem to work correctly (even with the change) |
| 13:46 |
nore |
minetest.after(5, function() print(minetest.forceload_block({x = 0, y = -2000, z = 0})) end) |
| 13:46 |
nore |
minetest.after(30, function() print(dump(minetest.get_node({x = 0, y = -2000, z = 0}))) end) |
| 13:46 |
nore |
^ this code prints "ignore" |
| 13:46 |
sapier |
timing effects usually don't occur on your machine ... those I'm fixing right now don't occur for me too |
| 13:46 |
|
Megaf joined #minetest-dev |
| 13:47 |
sapier |
of course you could be right too ... I just don't know |
| 13:47 |
nore |
well, anyway, PilzAdam's change was not enough |
| 13:49 |
sapier |
If you're not sure about it ask someone who knows that code it's not a shame |
| 13:50 |
nore |
of course... ;) I will wait a bit (who should I ask? hmmmm?) |
| 13:52 |
sapier |
yes hmmmm should be best to ask about this issue |
| 13:53 |
sapier |
talking about asking PilzAdam how skilled are you in terms of multithreading and locking? |
| 13:54 |
PilzAdam |
I have no experience in c++ with it |
| 13:54 |
sapier |
:-/ someone should check that patch I referenced some lines up spliting the conlock/clientslock is quite risky and I guess I didn't see any sideeffect |
| 14:22 |
|
ImQ009_ joined #minetest-dev |
| 14:29 |
|
ImQ009 joined #minetest-dev |
| 14:29 |
|
zat joined #minetest-dev |
| 14:57 |
|
hmmmm joined #minetest-dev |
| 15:12 |
|
Yepoleb_ joined #minetest-dev |
| 15:17 |
|
iqualfragile joined #minetest-dev |
| 15:41 |
|
bas080 joined #minetest-dev |
| 15:44 |
nore |
hmmmm, forceloading does not generate new blocks... do you have an idea about that? |
| 15:46 |
|
Evolykane joined #minetest-dev |
| 16:04 |
|
VanessaE joined #minetest-dev |
| 16:25 |
|
kaeza joined #minetest-dev |
| 16:35 |
|
Zeitgeist_ joined #minetest-dev |
| 16:35 |
|
Zeitgeist_ joined #minetest-dev |
| 16:39 |
|
salamanderrake joined #minetest-dev |
| 16:44 |
|
ImQ009 joined #minetest-dev |
| 16:52 |
|
Calinou joined #minetest-dev |
| 17:16 |
|
ImQ009 joined #minetest-dev |
| 17:33 |
xyz |
nore: yes, that was my point |
| 17:34 |
|
EvergreenTree joined #minetest-dev |
| 17:34 |
|
EvergreenTree joined #minetest-dev |
| 17:53 |
sfan5 |
src/jthread/win32/jsemaphore.cpp:64: error: ‘assert’ was not declared in this scope |
| 17:53 |
sfan5 |
someone fix that pls |
| 17:58 |
ShadowNinja |
I'll merge formspec_table soon if it still works and nobody has any objections. (I haven't heard any yet) |
| 18:02 |
ShadowNinja |
sapier: Can you look at #862? It needs to be rebased now, but you probably know best how to do that... |
| 18:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/862 -- Add the option to bind to a specific address by ShadowNinja |
| 18:02 |
|
EvergreenTree joined #minetest-dev |
| 18:03 |
|
EvergreenTree joined #minetest-dev |
| 18:08 |
xyz |
https://github.com/freeminer/freeminer/commit/165b5244ff867fefae7b40f101b6947cb6dda849 |
| 18:11 |
Kray |
i like it how there's almost no mention of minetest in any material related to freeminer |
| 18:13 |
xyz |
do you mean i should mention minetest in every commit message? |
| 18:14 |
Kray |
no |
| 18:14 |
xyz |
then what's the problem? |
| 18:22 |
ShadowNinja |
xyz: That looks good. |
| 18:24 |
|
Evolykane joined #minetest-dev |
| 18:28 |
|
grrk-bzzt joined #minetest-dev |
| 18:29 |
ShadowNinja |
I've rebased #675 and ammended it with proller's patch. Any objections to merging it? |
| 18:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/675 -- Allow vertical axis particle rotation constraint by khonkhortisan |
| 18:30 |
VanessaE |
+1 |
| 18:58 |
|
VargaD_ joined #minetest-dev |
| 19:11 |
|
bas080 joined #minetest-dev |
| 19:55 |
nore |
ShadowNinja, perhaps you could fix #944 now that InvRef:get_lists() is in... |
| 19:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/944 -- bug: item loss due to moving items out of output-only inventory to an occupied slot |
| 19:55 |
nore |
anyway, gtg |
| 19:58 |
|
Calinou joined #minetest-dev |
| 19:58 |
ShadowNinja |
No, I don't know how get_lists helps with that bug. |
| 19:59 |
nore |
(well, from what I read of the last discussion, it was about serializing the player inv for the new optional "holding" stack) |
| 19:59 |
nore |
there: http://irc.minetest.ru/minetest-dev/2013-12-23#i_3510867 |
| 20:00 |
Sokomine |
ah. yes, thanks for the idea, nore. hope that gets fixed. i'm not versed enough in the code to really fix it. my approach would be to check - prior to actually taking the content out of the slot - if there's either a willing receiving slot in the players inventory or if the slot something was taken from is willing to take what the player had in his inv. else deny the move |
| 20:00 |
Sokomine |
a new holding stack might solve that, yes |
| 20:02 |
nore |
anyway, I have really got to go now |
| 20:02 |
nore |
bye |
| 20:03 |
ShadowNinja |
That's just for mods like bones to get all of the lists. But they need a place to store that. Maybe you could punch bones to have them restore all of your inv, and drop anything that doesn't fit. |
| 20:04 |
Sokomine |
can't bones move surplus stuff into the player's crafting grid? that's where the items most likely where stored previously anyway |
| 20:05 |
|
NakedFury joined #minetest-dev |
| 20:44 |
|
sapier1 joined #minetest-dev |
| 21:06 |
|
grrk-bzzt joined #minetest-dev |
| 21:40 |
|
smoke_fumus joined #minetest-dev |
| 22:36 |
sapier1 |
we've got a problem with the recent added on_prejoin handler |
| 22:37 |
sapier |
it's called prior client is initialized, therefore doing anything causing messages beeing sent to client in there may cause issues |
| 23:22 |
ShadowNinja |
xyz: Can you push your patch to Minetest? |
| 23:25 |
xyz |
ShadowNinja: what patch? |
| 23:27 |
ShadowNinja |
xyz: The one that fixed the switch statement be adding breaks and checked for a zero division error. |
| 23:28 |
xyz |
ah, ok |
| 23:55 |
|
us_0gb joined #minetest-dev |
