Time |
Nick |
Message |
00:17 |
|
Taoki[laptop] joined #minetest-dev |
00:25 |
iqualfragile |
can we make minetest save the date of the modification (just unix timestamp, possibly reduced precision) of mapblocks? |
00:25 |
iqualfragile |
that would make creating caching easier |
00:26 |
proller |
already saved |
00:26 |
iqualfragile |
proller: in minetest? it is? great |
00:26 |
iqualfragile |
proller: can you point me to the lines? |
00:27 |
proller |
but maybe not exact modify time |
00:27 |
iqualfragile |
what else? create time? |
00:27 |
iqualfragile |
or aproximate modify time? |
00:27 |
iqualfragile |
aproximate would be ok, i guess, ~ one hour or even less should be enought precision |
00:28 |
proller |
628 <--><-->writeU32(os, getTimestamp()); |
00:28 |
proller |
mapblock.cpp |
00:28 |
iqualfragile |
k, thanks |
00:29 |
proller |
739 <--><-->setTimestamp(readU32(is)); |
00:29 |
proller |
740 <--><-->m_disk_timestamp = m_timestamp; |
00:29 |
iqualfragile |
just looked at the storage backends, which just saved "data", assumed wrongly it would just be plain data |
00:36 |
|
steven2612 joined #minetest-dev |
00:43 |
|
Zeno` joined #minetest-dev |
00:43 |
Zeno` |
I may add a brightness option if there isn't one already |
00:44 |
Zeno` |
Mainly because I have a calibrated monitor and even day time is too "dark" |
00:44 |
Zeno` |
it's not dark but gives me eyestrain |
00:47 |
EvergreenTree |
If there is, it would probably go in minetest.conf |
00:47 |
Zeno` |
yeah, I couldn't see it... I look at the src and find out |
00:48 |
Zeno` |
I'm a C programmer, not C++, but I think I can manage something small like this =) |
00:51 |
EvergreenTree |
Well, it might not be small |
00:51 |
EvergreenTree |
depending upon how minetest works |
00:51 |
EvergreenTree |
:p |
00:52 |
Zeno` |
might not. Parsing minetest.conf will be. Surely the engine has gamma or something as well. I'll find out I guess |
00:54 |
Zeno` |
That's if I can pull myself away from playing heh |
01:47 |
kaeza |
has there been any work towards that ugly chatbox-blocks-formspec-buttons bug? |
03:12 |
|
Exio joined #minetest-dev |
05:59 |
|
darkrose joined #minetest-dev |
05:59 |
|
darkrose joined #minetest-dev |
06:01 |
|
proller joined #minetest-dev |
06:07 |
|
darkrose joined #minetest-dev |
06:22 |
sfan5 |
kaeza: irrlicht supports GUI skins |
06:22 |
kaeza |
huh? |
06:23 |
sfan5 |
<kaeza> has there been any work towards that ugly chatbox-blocks-formspec-buttons bug? |
06:23 |
sfan5 |
which bug exactly? |
06:23 |
sfan5 |
I thought you meant the GUI being not pretty in general |
06:23 |
kaeza |
the one where if there's too much chat you cannot click buttons |
06:23 |
sfan5 |
hm.. |
06:23 |
kaeza |
(buttons "behind" the chatbox" |
06:24 |
kaeza |
s/\"$/)/ |
07:03 |
|
jin_xi joined #minetest-dev |
07:12 |
|
ImQ009 joined #minetest-dev |
07:17 |
|
PenguinDad joined #minetest-dev |
07:28 |
|
kaeza1 joined #minetest-dev |
07:51 |
|
PenguinDad joined #minetest-dev |
08:26 |
|
restcoser joined #minetest-dev |
09:05 |
|
PenguinDad joined #minetest-dev |
09:49 |
|
proller joined #minetest-dev |
09:56 |
|
proller joined #minetest-dev |
10:19 |
|
darkrose joined #minetest-dev |
10:19 |
|
darkrose joined #minetest-dev |
10:49 |
|
kaeza joined #minetest-dev |
10:55 |
|
Jordach joined #minetest-dev |
10:56 |
|
Jordach joined #minetest-dev |
11:27 |
|
domtron joined #minetest-dev |
11:34 |
|
rdococ joined #minetest-dev |
11:36 |
|
kaeza joined #minetest-dev |
11:59 |
|
kaeza1 joined #minetest-dev |
12:12 |
|
PilzAdam joined #minetest-dev |
12:53 |
|
kaeza joined #minetest-dev |
13:02 |
|
domtron joined #minetest-dev |
13:03 |
|
hmmmm joined #minetest-dev |
13:27 |
|
kaeza joined #minetest-dev |
14:20 |
|
rubenwardy joined #minetest-dev |
14:54 |
|
ImQ009 joined #minetest-dev |
14:58 |
|
grrk-bzzt joined #minetest-dev |
15:25 |
|
rubenwardy joined #minetest-dev |
15:42 |
ShadowNinja |
VanessaE_: Can you update #225 to use override_item? sfan5: I fixed one of the issues, the other seems to be that nodes under 0 or so are shifted sideways by a block. |
15:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/225 -- Mouse frozen in center position |
15:43 |
ShadowNinja |
-> minetest_game |
15:49 |
|
zat joined #minetest-dev |
15:50 |
celeron55 |
maybe the bot should understand something like minetest_game/#225 |
16:07 |
rubenwardy |
mg/#225? |
16:07 |
rubenwardy |
maybe use $255 or something for minetest_game |
16:07 |
rubenwardy |
(maybe not a $) |
16:07 |
sfan5 |
no, too complicated |
16:08 |
rubenwardy |
well, minetest_game/#255 would still work. just mg/#255 for shorthand |
16:10 |
rubenwardy |
how about {{{{0x1111111111>>2}}}} |
16:10 |
rubenwardy |
* {{{{0b1111111111>>2}}}} |
16:29 |
|
BlockMen joined #minetest-dev |
16:30 |
BlockMen |
ShadowNinja, why updating? is minetest_game dead now or not. you guys should finally decide... |
16:31 |
ShadowNinja |
BlockMen: I chose "not dead". But I'm not sure if I'm in the majority. Having a seperate base_game might do it. |
16:31 |
ShadowNinja |
But then base_game has to be copied to minetest_game, since common was removed. |
16:32 |
BlockMen |
why having a seperate base_game? |
16:33 |
ShadowNinja |
BlockMen: Because minetest_game has become the base for most games. |
16:34 |
proller |
most ща 0 пфьуы |
16:34 |
proller |
of 0 games |
16:34 |
BlockMen |
huh? how is that a reason for a seperate base_game? |
16:41 |
ShadowNinja |
BlockMen: Becuase derived games have to either keep updating their copy of minetest_game or split and work on their copy seperately. |
16:41 |
|
Exio4 joined #minetest-dev |
16:42 |
|
domtron joined #minetest-dev |
16:43 |
BlockMen |
ShadowNinja, i dont see any problem there. since they provide their own games they have anyway different things in mind (else they wouldnt make own game) |
16:43 |
BlockMen |
so if "we" provide still an official game htat should be further developed it can be mt_game |
17:13 |
celeron55 |
one of the problem is that if all modders stick with minetest_game and expect every feature from it to exist, they mods won't work in anything else; and those games should not be forced to take everything from a hypotethical bloated minetest_game just in order to be able work |
17:13 |
celeron55 |
+s -y +to |
17:15 |
celeron55 |
one of the other problems is that because minetest_game is saved in worlds on thousands of computers, anything added to it cannot really be removed, ever, and there currently is no meaningful development direction for it (because different people want different things) |
17:15 |
|
Calinou joined #minetest-dev |
17:17 |
celeron55 |
those quite effectively mean that it has to be frozen and more focused ones must be taken into use instead |
17:19 |
celeron55 |
and they will then be starting from a level playing field instead of riding on minetest_game's automatic publicity which makes people hate each other less due to unfairness |
17:20 |
rubenwardy |
Pressing enter in the create a world also start the game, because it does not wait for the enter to be taken up. So the dialog enters, and then the play game is entered. |
17:20 |
celeron55 |
...none if this should have been new to anyone though |
17:23 |
|
EvergreenTree joined #minetest-dev |
17:37 |
sfan5 |
do mods have any possibility to detect which game they are running under? |
17:38 |
celeron55 |
https://forum.minetest.net/viewtopic.php?pid=138276 |
17:39 |
sfan5 |
shouldn't that topic be sticky? |
17:39 |
celeron55 |
that section is so low-traffic that it doesn't matter |
17:40 |
celeron55 |
sfan5: the original design of the subgame system is that each game would have their own base mod name but it looks like we can't go that way |
17:40 |
celeron55 |
so, maybe mods will need that |
17:41 |
celeron55 |
so the answer is no, as far as i know |
17:42 |
celeron55 |
it would be ideal if mods would provide their own feature-based version detection |
17:43 |
celeron55 |
so that if some mod needs something from the default mod, it could check that from default.features["something"] or something like that |
17:43 |
celeron55 |
because otherwise forking a game is impossible |
17:43 |
celeron55 |
without breaking modding |
17:43 |
celeron55 |
note that servers fork games all the time |
17:44 |
celeron55 |
and advanced players |
17:45 |
celeron55 |
actually, because of that, it should not be possible for a mod to look up the game name; it's wrong and uninteroperable |
17:45 |
sfan5 |
yeah |
17:45 |
sfan5 |
it's the same thing like getting the minetest version |
17:45 |
celeron55 |
yes |
17:46 |
rubenwardy |
Jordach's BfD game is completetely incompatible with default. You need to be able to detect in that case. |
17:46 |
celeron55 |
does it use the mod name "default"? |
17:47 |
rubenwardy |
It does |
17:47 |
celeron55 |
i don't think there is need for detection in that case; if it's not forked from minetest_game, it doesn't have any chance to be interoperable in this way anyway |
17:47 |
rubenwardy |
But it is empty |
17:47 |
celeron55 |
this feature-based detection is useful only if the game differs a bit from others but not too much |
17:48 |
BlockMen |
i think something like "minetest.get_game_name()" would be best solution |
17:48 |
BlockMen |
*or get_current_game() |
17:48 |
celeron55 |
it's the worst solution due to what i just said |
17:50 |
BlockMen |
oh, misread it then |
17:51 |
BlockMen |
and what would be the problem if a mod can get the game name? |
17:52 |
sfan5 |
BlockMen: https://github.com/minetest/minetest/pull/1143#issuecomment-34580868 read 2) |
17:53 |
BlockMen |
ah, ic. then nvm my suggestion |
17:54 |
rubenwardy |
subgames like BfD can just supply a flag to say what they are. (for example, BFD = true in default). |
17:54 |
sfan5 |
that is not a good idea |
17:55 |
sfan5 |
what if the game name collides with a global var a modder sets? |
17:55 |
celeron55 |
i assume that meant default.BFD = true |
17:55 |
celeron55 |
it's not a good idea due to the same reason for which the two other mentioned things are bad ideas |
17:55 |
celeron55 |
but we can't stop it |
17:57 |
|
Exio4 joined #minetest-dev |
17:57 |
|
Robby joined #minetest-dev |
17:58 |
celeron55 |
(we can recommend against it, though) |
17:59 |
rubenwardy |
It is a good idea, because BFD does not use default:itemname. |
17:59 |
rubenwardy |
it uses mapgen:dirt, etc |
18:00 |
|
Exio4 joined #minetest-dev |
18:01 |
celeron55 |
if mods insist on working on it and minetest_game-based games at the same time, then it may be the best option for it |
18:01 |
celeron55 |
because... there just isn't any other option |
18:02 |
celeron55 |
but that's going to be really messy and unscalable to many games; it's best if games that want to be universally moddable base themselves on minetest_game |
18:03 |
rubenwardy |
I agree |
18:07 |
|
nore joined #minetest-dev |
18:09 |
|
Megaf joined #minetest-dev |
18:11 |
|
iqualfragile joined #minetest-dev |
18:12 |
|
grrk-bzzt joined #minetest-dev |
18:20 |
|
proller joined #minetest-dev |
18:22 |
|
werwerwer_ joined #minetest-dev |
18:29 |
|
Zeitgeist_ joined #minetest-dev |
18:29 |
|
Zeitgeist_ joined #minetest-dev |
18:33 |
|
nore joined #minetest-dev |
18:46 |
BlockMen |
i think something like an "about this game" in mainmenu would be nice to have |
18:49 |
rubenwardy |
What would it contain? |
18:50 |
|
domtron joined #minetest-dev |
18:51 |
BlockMen |
a short description. i think its useful/necessary when games come along with the engine |
18:52 |
rubenwardy |
Oh, subgame |
19:02 |
|
werwerwer joined #minetest-dev |
19:21 |
BlockMen |
more opinions on that? ^ |
19:22 |
sfan5 |
good idea |
19:34 |
|
werwerwer_ joined #minetest-dev |
19:39 |
|
luizrpgluiz joined #minetest-dev |
19:39 |
luizrpgluiz |
hi devs |
19:40 |
|
luizrpgluiz left #minetest-dev |
19:52 |
|
BrandonReese joined #minetest-dev |
20:04 |
|
BlockMen left #minetest-dev |
20:48 |
|
webdesigner97 joined #minetest-dev |
20:49 |
|
grrk-bzzt joined #minetest-dev |
21:13 |
|
tomreyn joined #minetest-dev |
21:34 |
|
sfan5[iPod] joined #minetest-dev |
21:36 |
|
proller joined #minetest-dev |
22:33 |
|
BrandonReese joined #minetest-dev |
22:51 |
|
ShadowBot joined #minetest-dev |
22:53 |
|
emptty joined #minetest-dev |
22:53 |
emptty |
hello people |
22:53 |
emptty |
Do someone have an idea about this problem, please: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741737 |
22:54 |
emptty |
I don't see no main_menu.2.ogg in the source package |
22:54 |
emptty |
am I blind maybe? |
22:56 |
PilzAdam |
emptty, its not a problem at all |
22:57 |
emptty |
Ok, fine. |
22:57 |
PilzAdam |
it just looks if menu baground music files are available |
22:57 |
PilzAdam |
since there are none by default you see these messages |
22:57 |
emptty |
where could they come from ? |
22:59 |
PilzAdam |
users can could add their own music into the paths you see in the messages |
22:59 |
PilzAdam |
-can |
23:00 |
emptty |
ok |
23:00 |
emptty |
I'll tell that to the user, thanks for your help |