| Time |
Nick |
Message |
| 00:11 |
PilzAdam |
ehm.. hmmmm, you know that only the first of these 3 commits works correctly? |
| 00:11 |
PilzAdam |
the second one actually messes favoriteservers.txt up, it breaks peoples data |
| 00:12 |
PilzAdam |
and the 3rd one shows the default header if the selected game doesnt provide one |
| 00:12 |
hmmmm |
great ;/ |
| 00:12 |
PilzAdam |
(there should be no header in this case) |
| 00:19 |
PilzAdam |
you should at least revert the one that breaks favoriteservers.txt |
| 00:21 |
hmmmm |
erhm |
| 00:22 |
hmmmm |
how about from now on i'll push sapier's commits to my own fork that's rebased against upstream, and you test that first, then verify things work before i push to upstream |
| 00:23 |
PilzAdam |
or you just read the logs of this channel |
| 00:23 |
hmmmm |
sapier didn't seem very concerned about it |
| 00:39 |
PilzAdam |
any objections: https://github.com/PilzAdam/minetest/commit/ab0872659a05ddce72ff4b36891416c21e496818 |
| 00:39 |
PilzAdam |
+? |
| 01:02 |
|
iqualfragile joined #minetest-dev |
| 03:16 |
|
ffoxin joined #minetest-dev |
| 04:38 |
|
neko259 joined #minetest-dev |
| 05:11 |
|
kaeza joined #minetest-dev |
| 05:37 |
|
ssieb joined #minetest-dev |
| 07:05 |
|
darkrose joined #minetest-dev |
| 07:05 |
|
darkrose joined #minetest-dev |
| 07:09 |
|
Zeg9 joined #minetest-dev |
| 08:08 |
|
serengeor joined #minetest-dev |
| 09:08 |
|
iqualfragile joined #minetest-dev |
| 09:12 |
|
Calinou joined #minetest-dev |
| 09:12 |
|
Weedy joined #minetest-dev |
| 09:12 |
|
Weedy joined #minetest-dev |
| 09:13 |
|
nyuszika7h joined #minetest-dev |
| 09:13 |
|
drizz joined #minetest-dev |
| 09:13 |
|
kahrl joined #minetest-dev |
| 09:15 |
|
darkrose joined #minetest-dev |
| 09:15 |
|
Neological joined #minetest-dev |
| 09:15 |
|
BrandonReese joined #minetest-dev |
| 09:15 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 09:15 |
|
Taoki joined #minetest-dev |
| 09:15 |
|
yno_ joined #minetest-dev |
| 09:15 |
|
toabi joined #minetest-dev |
| 09:15 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 09:16 |
|
BackupCoder joined #minetest-dev |
| 09:35 |
|
proller joined #minetest-dev |
| 10:06 |
|
kaeza joined #minetest-dev |
| 10:20 |
|
EdB joined #minetest-dev |
| 10:24 |
|
EdB joined #minetest-dev |
| 10:40 |
|
EdB joined #minetest-dev |
| 10:47 |
|
iqualfragile joined #minetest-dev |
| 10:54 |
|
EdB joined #minetest-dev |
| 10:57 |
|
Calinou joined #minetest-dev |
| 11:01 |
|
iqualfragile joined #minetest-dev |
| 11:11 |
|
proller joined #minetest-dev |
| 11:25 |
|
EdB_ joined #minetest-dev |
| 11:46 |
|
PilzAdam joined #minetest-dev |
| 12:11 |
|
proller joined #minetest-dev |
| 12:55 |
|
NakedFury joined #minetest-dev |
| 12:59 |
|
ffoxin joined #minetest-dev |
| 14:37 |
|
kaeza joined #minetest-dev |
| 14:44 |
|
Calinou joined #minetest-dev |
| 14:50 |
|
serengeor joined #minetest-dev |
| 14:57 |
|
Jordach joined #minetest-dev |
| 15:18 |
|
hmmmm joined #minetest-dev |
| 15:49 |
kahrl |
hi hmmmm, do you think these should be added? https://github.com/minetest/minetest/pull/818 |
| 15:52 |
hmmmm |
sure |
| 16:06 |
proller |
maybe merge https://github.com/minetest/minetest/pull/816 https://github.com/minetest/minetest_game/pull/188 ? |
| 16:09 |
hmmmm |
mmmm.. maybe. |
| 16:09 |
|
mrtux_ joined #minetest-dev |
| 16:16 |
proller |
i can if no objections |
| 16:19 |
kahrl |
can this be approximated somehow if shaders are disabled? |
| 16:19 |
Calinou |
would be very slow, and would edit the map |
| 16:19 |
Calinou |
these dynamic lights do not edit the map |
| 16:19 |
Calinou |
and are purely client side |
| 16:19 |
kahrl |
it's kind of weird to limit a big gameplay advantage to only those who have shaders |
| 16:20 |
kahrl |
for example in PvP people with shaders would have big advantages over those who don't |
| 16:21 |
kahrl |
Calinou: maybe setting a hardware light at the wield position |
| 16:21 |
Calinou |
hardware lights? |
| 16:23 |
kahrl |
it's obviously not the same as what people usually mean when they talk about "hardware lights in minetest" |
| 16:25 |
hmmmm |
i think there's some sort of limitation with lighting on a scene node.... or something |
| 16:32 |
celeron55 |
people with hacks have gameplay advantages over people with no hacks 8) |
| 16:33 |
Calinou |
lol |
| 16:33 |
Calinou |
kahrl: you usally don't play pvp on weak hardware anyway :P |
| 16:33 |
celeron55 |
anyway, it would be best to have some way of making pvp not so unfair |
| 16:34 |
* Calinou |
would like to see stu's armor/wield item mod in default game |
| 16:34 |
Anchakor |
make combat turn based :P |
| 16:41 |
Zeg9 |
just remove the damn enable_shaders setting |
| 16:41 |
Zeg9 |
hmm no, it would remove direct3d support :p |
| 16:42 |
kahrl |
just tell everyone without shaders that minetest takes place on a distant alien planet |
| 16:42 |
celeron55 |
many low-end things don't work at all or reasonably at all with shaders |
| 16:42 |
celeron55 |
maybe some kind of bi-yearly surveys should be made to get a hang of how many users use what 8) |
| 16:46 |
Jordach |
not to mention that users probably want things in the pulls of minetest_game |
| 16:47 |
* Zeg9 |
is motivated today |
| 16:47 |
Zeg9 |
third pull-request of the day: https://github.com/minetest/minetest/pull/819 |
| 16:47 |
Zeg9 |
^ fixes the server list that *someone* broke :P |
| 16:53 |
Taoki |
hmmmm: Any examples of how the voxel manipulator can be used to fill out an area (between two corners)? I've been trying for hours to do that, and even with the help of 2 people still couldn't figure it out |
| 16:53 |
Taoki |
Currently it fills out another area than the specified corners |
| 16:54 |
Taoki |
https://gist.github.com/PilzAdam/5957302 Last suggestion by PilzAdam. Almost works but it fills an incorrect space instead of the one specified. I don't know what to add since I can't understand how this works yet |
| 16:59 |
|
ecube joined #minetest-dev |
| 17:02 |
|
sapier joined #minetest-dev |
| 17:03 |
sapier |
fallback to default was exactly what has been told to me |
| 17:04 |
sapier |
I'm sorry guys but I can't make two opposit requirements work at same time |
| 17:05 |
Zeg9 |
sapier: https://github.com/minetest/minetest/pull/819 |
| 17:05 |
Zeg9 |
brb |
| 17:06 |
sapier |
what are the differences to my versionß |
| 17:07 |
|
neko259 joined #minetest-dev |
| 17:10 |
|
Calinou joined #minetest-dev |
| 17:13 |
hmmmm |
taoki, it's all completely documented and there are numerous examples |
| 17:13 |
|
ssieb joined #minetest-dev |
| 17:13 |
hmmmm |
setting literally every element like pilzadam does there works for him, but it won't necessarily work for you |
| 17:14 |
hmmmm |
i don't get how somebody can be trying *for hours* and not figuring out how to do it |
| 17:14 |
hmmmm |
why don't you look at that TNT mod? |
| 17:14 |
sapier |
https://gist.github.com/sapier/5959230 can someone verify that this is behaviour of menu headers ? |
| 17:14 |
Taoki |
hmmmm: I looked in the lua api, although functions are documented functionality is hard to figure out. I also searched examples and couldn't find any |
| 17:15 |
sapier |
I don't want to do it a fourth time |
| 17:15 |
hmmmm |
shadowninja and others didn't seem to have a problem... |
| 17:15 |
hmmmm |
first of all, taoki, why do you want to fill a space with air? |
| 17:16 |
Taoki |
hmmmm: http://pastebin.com/raw.php?i=LKA78BQ7 This is what I have now BTW |
| 17:16 |
Taoki |
hmmmm: A function co clear a selected box |
| 17:16 |
Taoki |
*to |
| 17:16 |
hmmmm |
yes, but for what purpose |
| 17:16 |
hmmmm |
there might be a better way to do what you'd like to do overall |
| 17:16 |
Taoki |
For buildings, and the node to import them (which also has a function to clear the area of nodes first) |
| 17:16 |
hmmmm |
so you'd like to clear a spot for buildings |
| 17:17 |
hmmmm |
and the buildings use the schematic, right? |
| 17:17 |
Taoki |
Well, old way was setting each node to air with the previous system which was very laggy |
| 17:17 |
Taoki |
Yes |
| 17:17 |
hmmmm |
you realize that with place_schematic, air nodes are placed? |
| 17:17 |
hmmmm |
this makes it unnecessary to clear an area first |
| 17:17 |
Taoki |
I know. I still need the separate clear function however |
| 17:17 |
hmmmm |
don't see why... |
| 17:17 |
Taoki |
Part of how my mod works. For natural buildings I also leave a border / space |
| 17:18 |
Taoki |
I also want to be able to empty out the marked area I work with first |
| 17:18 |
hmmmm |
well, i'd just like to point out that i anticipated people needing to clear the area first which is why i had place_schematic force placement of air |
| 17:18 |
hmmmm |
so you wanted to have a border |
| 17:19 |
sapier |
I realized that there have been some troubles with pull requests I updated I apologize ... I'm going to drop pulls and create new ones in future to avoid confusion |
| 17:19 |
hmmmm |
and when does this happen, taoki? on_generate? |
| 17:19 |
Taoki |
There's also the command to clear a marked area before importing or exporting any schematics |
| 17:19 |
Taoki |
hmmmm: No, I need the function to be called manually on a certain cube in the world |
| 17:20 |
Taoki |
Not on_generate, because if someone's editing an area they are already in a loaded place and set it up manuall |
| 17:20 |
hmmmm |
if you read my initial news post here http://forum.minetest.net/viewtopic.php?id=6396 you'd see there's a nice example of how to use it: |
| 17:20 |
hmmmm |
http://pastebin.com/x0DFYXQD |
| 17:20 |
hmmmm |
of course, some minor things have changed in the api since then but the way you manipulate the data is exactly the same |
| 17:23 |
Taoki |
I still don't see how to load only a certain area of data in the voxel manipulator and write it back. So I can simply select an area (at any nodes, regardless of mapblocks) and fill that |
| 17:23 |
hmmmm |
you can't load *just* a certain area |
| 17:24 |
hmmmm |
the area being loaded must be rounded out to mapblock boundaries |
| 17:24 |
hmmmm |
this is why there's a difference between a). what you asked for and b). what you got |
| 17:24 |
Taoki |
oh |
| 17:24 |
hmmmm |
you're supposed to only modify what you asked for |
| 17:24 |
Taoki |
In that case it might work to check the boundaries of each node when looping through the vm data |
| 17:24 |
hmmmm |
to make this task simple, i added the VoxelArea helper class |
| 17:25 |
hmmmm |
you might want to take a look at it, it's in builtin/voxelarea.lua |
| 17:25 |
hmmmm |
you create a new VoxelArea object by calling VoxelArea:new(), passing in the coordinates of MaxEdge and MinEdge of what was actually emerged |
| 17:26 |
hmmmm |
you get the index of the element you want inside of the data array by passing the absolute coordinates to VoxelArea:index() |
| 17:27 |
hmmmm |
and i don't get why I have to be the person to keep explaining how to use it |
| 17:27 |
hmmmm |
VoxelManip is mainstream, it's not like some wacky thing that I came up with and I'm the only one who understands |
| 17:28 |
Taoki |
Trying to use it now |
| 17:29 |
hmmmm |
it's stable too, so it's not like it's a problem on my end if it doesn't work 100% the way you'd expect it to |
| 17:30 |
celeron55 |
sapier: umm |
| 17:30 |
celeron55 |
sapier: what is your or someone else's problem now exactly? |
| 17:31 |
sapier |
My problem is that I guess I created some trouble to others as I don't want to do so I think this is best option |
| 17:32 |
celeron55 |
i'm not surprised at all if the background-making logic got screwed up in the menu remake |
| 17:32 |
hmmmm |
to be honest, sapier, i wouldn't be of much help (i'm not ignoring you) this is pilzadam's area, i honestly don't know what to expect from the menu headers |
| 17:32 |
sapier |
I was talking about my pull updates ... I know that I'm not guilty about the menu background things as those never have been specified correctly |
| 17:33 |
hmmmm |
and i don't really care either |
| 17:33 |
Taoki |
Ahh... seem to have gotten it working at last |
| 17:33 |
celeron55 |
sapier: i think the header/footer thing is quite obvious, but the background/footer might not be, am i correct? |
| 17:33 |
sapier |
I don't really care too how it works I just want some at least somehow final solution |
| 17:34 |
celeron55 |
ehm |
| 17:34 |
celeron55 |
background/overlay* |
| 17:34 |
|
diemartin joined #minetest-dev |
| 17:34 |
sapier |
ok so it's 3 cases not two as I assumed |
| 17:34 |
celeron55 |
it was somewhat messed up before and i predict it will be messed up now |
| 17:35 |
celeron55 |
so, there are three alternatives of how to draw the background: 1) clouds + game's overlay, 2) game background, 3) clouds |
| 17:35 |
sapier |
yes I already had that discussion to vanessa ... I don't care how it behaves if I don't need to change it twice a week ;-) |
| 17:36 |
celeron55 |
uhm |
| 17:36 |
sapier |
and there may be a texture pack too |
| 17:36 |
celeron55 |
so do you want a correct explanation of how it should work or not? |
| 17:36 |
sapier |
and in texture pack there may be game specific and default textures |
| 17:36 |
sapier |
in best case I want a correct version |
| 17:37 |
sapier |
but if "correct" depends on who I ask I'm fine with something stable too |
| 17:37 |
Taoki |
hmmmm: So just to be sure I understand. vm:read_from_map(min, max) doesn't get the area in nodes between min and max. But instead it gets the mapblocks touching this area... correct? |
| 17:37 |
Taoki |
Then voxelarea is used to filter nodes themselves |
| 17:37 |
hmmmm |
taoki, yes |
| 17:37 |
celeron55 |
i can tell it as how i designed it to work and implemented it before your menu update... it's quite complicated though |
| 17:37 |
Taoki |
ok. Good to know for the future. That confused me a lot today |
| 17:38 |
hmmmm |
would you mind showing me your final code? |
| 17:38 |
hmmmm |
i guarantee you're doing something dumb and i'd like to fix it |
| 17:38 |
sapier |
ok I guess the before state will be fine |
| 17:38 |
celeron55 |
sapier: so first you need to end up in a situation where you know whether you have the overlay available, and whether you have the background available |
| 17:39 |
celeron55 |
(this is for the singleplayer tab) |
| 17:40 |
celeron55 |
then if you don't have an overlay but have a background, show the background |
| 17:40 |
celeron55 |
else if you have an overlay, show it on clouds |
| 17:41 |
celeron55 |
else if menu clouds are enabled, show only clouds |
| 17:41 |
celeron55 |
else show a single-color background |
| 17:41 |
celeron55 |
that's how it worked |
| 17:41 |
sapier |
ok now how to decide which background to use? |
| 17:42 |
celeron55 |
order of preference: 1) texture pack, 2) game |
| 17:42 |
sapier |
ok |
| 17:42 |
sapier |
so what about mixed modes e.g. if texturepack specifies overlay but game specifies background? |
| 17:43 |
celeron55 |
that's why i mentioned the midway result - you don't care where they came from at that final choosing point |
| 17:43 |
celeron55 |
it makes it... somewhat handleable |
| 17:44 |
celeron55 |
as for the non-game themed background, the order of priority goes as: 1) texture pack, 2) clouds if enabled, 3) something else (the same solid color as the final else in before?) |
| 17:44 |
sapier |
not exactly that'll result in dual pass setting |
| 17:44 |
celeron55 |
dual pass with simple passes is better than a single extremely complicated pass... |
| 17:44 |
sapier |
only way to find out if a texture is correct is trying to use it atm |
| 17:44 |
celeron55 |
anyway, i agree that this is complicated; i am just explaining how it worked |
| 17:45 |
Zeg9 |
sapier: apparently, with your commit, the public server list still doesn't show sometimes (is name escaped? are [] escaped?) |
| 17:45 |
sapier |
yes I know zeg9 for some reason the exact same code used in minetest.escape doesn't work for [] |
| 17:46 |
sapier |
I already tried hours to find out why lua fails to find [] in strings, tried different escapes no success |
| 17:47 |
Zeg9 |
have you tried this one ? https://github.com/minetest/minetest/pull/819/files |
| 17:47 |
sapier |
celeron55 thanks I'm gonna update my gist and make sure everyone agrees with the way I understood it |
| 17:47 |
sapier |
zeg9 it's almost same as my changes in 815 |
| 17:47 |
celeron55 |
sapier: you can try to find a better logic of course but as long as one wants to satisfy the same audience as before, it's not really possible |
| 17:48 |
hmmmm |
really wish people could run string parsing formats by us before they implement it |
| 17:48 |
sapier |
yes I already realized nothing is more sacred than the old behaviour and of course exact pixel order :-) |
| 17:48 |
hmmmm |
string formats that need to be parsed* rather |
| 17:48 |
proller |
sapier, did you return "public" checkbox ? |
| 17:49 |
sapier |
"return"? |
| 17:49 |
hmmmm |
proller, it's been there for a while. |
| 17:49 |
Zeg9 |
sapier: found out. you didn't run fs_escape_string on spec.name |
| 17:49 |
proller |
it was before formspec |
| 17:49 |
celeron55 |
sapier: i still say that some day a full menu rework must be done to make the singleplayer/others difference more intuitive |
| 17:50 |
celeron55 |
anyone is free to propose a design for such |
| 17:52 |
sapier |
I'm completely with you ... my vision about formspec was to provide a basic menu and specified ones ... but I didn't calculate with communitys binding to old menu |
| 17:52 |
sapier |
specific ones |
| 17:53 |
sapier |
zeg9 great! thanks |
| 17:53 |
Zeg9 |
No problem :-P I can finally use this menu |
| 17:53 |
sapier |
I don't know how often I looked at this without realizing it |
| 17:59 |
VanessaE |
sapier: people are creatures of habit and don't like having things moved around too much if there isn't enough improvement to go with the move. |
| 18:00 |
VanessaE |
enough user-facing improvement, I mean |
| 18:00 |
VanessaE |
from a coders' standpoint, the lua menu is a good idea. |
| 18:01 |
VanessaE |
from a user's standpoint it'll be something like, "wtf? why was this moved around? I liked it where it was!!" etc etc |
| 18:01 |
sapier |
https://gist.github.com/sapier/5959230 ok plz review |
| 18:01 |
Zeg9 |
sapier: going with the bug fixes, have you got an idea why the mods won't show on a run_in_place=0 minetest? |
| 18:02 |
sapier |
no but it's difficult to test for me as I don't want to mess up my os with minetest files ... but I'm gonna try to find out whats wrong |
| 18:03 |
Zeg9 |
you could make a chroot |
| 18:03 |
sapier |
including all libs? I guess that's a little bit too much for my ssd ;-) |
| 18:04 |
Zeg9 |
:P |
| 18:04 |
Zeg9 |
I'll try to find out when I got time |
| 18:04 |
Zeg9 |
seems like I'm the only one interested in run_in_place=0 :/ |
| 18:04 |
sapier |
but I'll find a way once all more important bugs are fixed ... e.g. pilzadams "names get removed" ... I don't have any idea how that commit can remove names |
| 18:05 |
sapier |
maybe zeg9 ... in system install is a little bit messy for most os |
| 18:05 |
sfan5 |
sapier: I have a 32bit ubuntu raring chroot environment, its 392MB big |
| 18:05 |
sapier |
ok I guess I'll have that much available ... still some work to do |
| 18:06 |
Zeg9 |
sapier: sudo make install usually puts everything in /usr/local, which I can delete at any time, and run_in_place=0 is used for packages |
| 18:06 |
VanessaE |
sapier: that seems right to me, except on line 47, you meant 'game' there. |
| 18:06 |
sapier |
no I wanted to delete that line |
| 18:07 |
VanessaE |
er, right |
| 18:08 |
sapier |
ok once pilzadam is fine with that too I'm gonna fix it that way |
| 18:09 |
sapier |
VanessaE you do use public server list do you? |
| 18:09 |
VanessaE |
nope. |
| 18:09 |
sapier |
ok so no need to ask you about it |
| 18:10 |
VanessaE |
it's useless for me because of the false-doubleclick behavior (unless that's been fixed) and no storage of passwords. |
| 18:10 |
sapier |
no but I made updown buttons work |
| 18:10 |
sapier |
uhm updown keys of course |
| 18:11 |
VanessaE |
right |
| 18:11 |
sapier |
I'm sorry I'd like to do more but it's irrlicht |
| 18:12 |
VanessaE |
it's ok |
| 18:31 |
|
EdB joined #minetest-dev |
| 19:09 |
|
PilzAdam joined #minetest-dev |
| 19:16 |
sokomine |
i heard that rotation with schematics works now with param2/facedir as well. thank you for that! |
| 19:17 |
sokomine |
is there already a way to do the node-replacement as well? that's the only thing that still keeps me from using schematics (i'd like to have node xyz placed instead of abc in the schematic - *all* nodes of abc ought to become xyz when the schematic has been placed) |
| 19:25 |
|
Jordach joined #minetest-dev |
| 19:26 |
hmmmm |
not really sure why you'd need that |
| 19:27 |
hmmmm |
and even if you legitimately do need that sort of functionality, you're basically the only one using it and i'm not taking random feature requests that benefit a single person |
| 19:28 |
PilzAdam |
I would have some usecases for it too |
| 19:30 |
sfan5 |
just open the schematic in lua and replace all occurences of <a> in the node table with <b> |
| 19:31 |
PilzAdam |
sounds hacky |
| 19:31 |
sfan5 |
but works |
| 19:32 |
PilzAdam |
if I e.g. have a "general" schematic wich just uses "dirt" or "stone", then each time you read it youd have to change the file, place it and then change it back |
| 19:32 |
hmmmm |
not only that, but you'd only be able to switch to nodes with names that are equal or smaller in length |
| 19:33 |
sfan5 |
umm |
| 19:33 |
sfan5 |
you can extend the node table |
| 19:33 |
hmmmm |
you like doing all that nice & slow file manipulation? |
| 19:34 |
sfan5 |
I didn't say it was fast |
| 19:35 |
hmmmm |
if i were to advocate this node swapping, what i'd do is have the user supply an optional replacement list parameter to minetest.place_schematic and another field to the schematic decoration type which matches the node names and overrides them before the node names are resolved |
| 19:35 |
PilzAdam |
some kind of wrapper would be nice: schem = Schematic("/home/.../schem,mts"); local size = schem:get_size(); schem:set_alias("dirt", "default:dirt"); schem:place(pos) |
| 19:36 |
sapier |
PilzAdam can you tell me what's wrong with that reverted commit? I can't see anything that'd explain something beeing removed by it. |
| 19:37 |
PilzAdam |
it removes the name and description from favoriteservers.txz |
| 19:37 |
PilzAdam |
*txt |
| 19:37 |
sapier |
I assume there's some other bug that couldn't happen before due to public list not working at all |
| 19:38 |
PilzAdam |
well, you have to fix that other bug first, deleting data from users is not good |
| 19:38 |
sapier |
where are those names you're talking from I wasn't aware names are saved anywhere? |
| 19:38 |
PilzAdam |
https://gist.github.com/PilzAdam/5960570 |
| 19:39 |
PilzAdam |
this is my favoriteserver.txt |
| 19:39 |
sapier |
I don't do anything to that file directly but I gues I've got an idea where to look for it |
| 19:39 |
PilzAdam |
ehm, there are two empty lines at the end (the gist has removed them) |
| 19:40 |
sapier |
I guess it's removed by core due to information not beeing transfered from lua ... but I have to verify that |
| 19:42 |
|
iqualfragile joined #minetest-dev |
| 19:42 |
|
proller joined #minetest-dev |
| 19:46 |
sapier |
ok verified ... nothing is wrong with the reverted commit it just shows up a bug already present before |
| 19:46 |
proller |
and "public" ? |
| 19:47 |
sapier |
I don't know what you mean with "public" proller plz explain to me ;-) |
| 19:47 |
proller |
"public" checkbox in server start |
| 19:48 |
sapier |
ok now I know plz post to issue 814 so it won't be forgotten again |
| 19:48 |
PilzAdam |
its already there |
| 19:49 |
sapier |
it is? |
| 19:49 |
PilzAdam |
2nd comment: "EDIT: and the public server list still doesn't work." |
| 19:49 |
sapier |
can you clarify that a little bit more I read that as favourites |
| 19:50 |
sapier |
prollers feature is "announce to public serverlist checkbox" |
| 19:50 |
PilzAdam |
oh |
| 19:50 |
sapier |
is there a way to rerevert a commit? |
| 19:55 |
PilzAdam |
sure |
| 19:55 |
PilzAdam |
just revert the revert commit |
| 19:56 |
sapier |
lol ... that'll look interesting in commit log :-) |
| 19:58 |
|
ecube_ joined #minetest-dev |
| 19:58 |
|
dzho_ joined #minetest-dev |
| 20:03 |
|
Anchakor joined #minetest-dev |
| 20:06 |
|
kaeza joined #minetest-dev |
| 20:10 |
proller |
https://github.com/proller/minetest/commit/2bc58f04514e7b15cebd5bac250bffd5cfa4427d |
| 20:10 |
proller |
no objections? |
| 20:10 |
proller |
ok, will commit. |
| 20:11 |
sapier |
I'm fine |
| 20:11 |
proller |
its lost public checkbox |
| 20:12 |
PilzAdam |
wait, why does the formspec use dump()? |
| 20:12 |
PilzAdam |
you cant rely on a specific format of dump() |
| 20:12 |
* proller |
just copy-paste |
| 20:13 |
PilzAdam |
sapier? |
| 20:13 |
sapier |
it's used for a bool value |
| 20:14 |
sapier |
in this special case relying on it's output shouldn't be a problem |
| 20:15 |
PilzAdam |
change it to minetest.serialize() |
| 20:16 |
sapier |
there's no serialize in menu |
| 20:16 |
proller |
now i want to push, and if it need - replace dump in next commits |
| 20:17 |
PilzAdam |
well, then dofile("builtin/serialize.lua") |
| 20:17 |
sapier |
yes if this really has to be removed I want to have a special function cause if I can't rely on dump I can't on serialize either |
| 20:17 |
sapier |
both don't guarantee to return true/false only |
| 20:18 |
PilzAdam |
you can rely on serialize() |
| 20:18 |
sapier |
I wouldn't ever rely to serialize giving a special format |
| 20:18 |
PilzAdam |
then write your own function |
| 20:19 |
sapier |
that was the suggestion but not instantly |
| 20:20 |
sapier |
btw it's in there multiple times noone ever complained about it .. you too ;-) |
| 20:23 |
sapier |
PilzAdam did you check the header/background/overlay gist specification? |
| 20:23 |
PilzAdam |
hm? |
| 20:24 |
sapier |
https://gist.github.com/sapier/5959230 |
| 20:25 |
sapier |
I've changed this already 3 times due to some unknown requirements not beeing implemented I don't want to do a fiveth time :) next one has to be last |
| 20:27 |
PilzAdam |
"done" = dont continue? |
| 20:27 |
sapier |
yes |
| 20:27 |
PilzAdam |
then its wrong, overlay and background can both exist |
| 20:27 |
PilzAdam |
clouds = enable_clouds && not background |
| 20:28 |
PilzAdam |
also, dont try "default" header/footer in singleplayer tab |
| 20:28 |
sapier |
then we need to clarify again as I understood celeron55 if overlay is set background isn't used ... vanessae agreed to that gist too |
| 20:29 |
sapier |
VanessaE ? are you here atm? |
| 20:30 |
sapier |
I don't care how it's done if it's accepted by those using it |
| 20:32 |
sapier |
https://github.com/minetest/minetest/pull/815 rereverted the serverlist commit and fixed the favourites not beeing saved |
| 20:34 |
PilzAdam |
22:34:28: ERROR[main]: MAINMENU ERROR: error: /home/adam/Minetest/minetest/bin/../builtin/mainmenu.lua:694: attempt to index field 'favourites' (a nil value) |
| 20:35 |
sapier |
great what have you done :-) |
| 20:35 |
PilzAdam |
dunno |
| 20:35 |
PilzAdam |
it happens sometimes when I click on an entry, the address field is not set when it happens |
| 20:35 |
PilzAdam |
but everything else works perfectly fine |
| 20:37 |
PilzAdam |
can you remove the selection in the list if the user changes port or adress field? |
| 20:37 |
sapier |
ok I hate british american favo(u)rites |
| 20:37 |
sapier |
pushed a fix |
| 20:38 |
sapier |
hmm textfield changes aren't notified to lua atm but I guess I can add that .... but it's gonna creat a lot of load |
| 20:39 |
sapier |
maybe a "editbox enter" event would be an option |
| 20:39 |
sapier |
I wonder if I really have to add any tk feature to formspec until this is finished :) |
| 20:40 |
sapier |
can you verify it's not crashing anymore? |
| 20:40 |
PilzAdam |
yes |
| 20:40 |
sapier |
good |
| 20:40 |
PilzAdam |
well, it happened randomly before, and it didnt happen after I pulled your fix |
| 20:41 |
sapier |
I guess it's related to a doubleclick on favorites |
| 20:41 |
sapier |
at least that code was only executed on "doubleclick" |
| 20:41 |
PilzAdam |
when I click on "delete", the adress field is cleared, but another entry in the list is selected |
| 20:42 |
sapier |
I guess the address field should be updated instead of beeing cleared |
| 20:42 |
PilzAdam |
I would expect that the adress field gets set to the newly selected entry |
| 20:44 |
sapier |
hmm that's an interesting issue |
| 20:44 |
sapier |
address/port are always set to those saved in settings ... on deletion those are cleared while selection is preserved |
| 20:45 |
PilzAdam |
clearing the selection would be an option too |
| 20:45 |
PilzAdam |
so you cant accidentally remove several entries at once |
| 20:46 |
PilzAdam |
and clearing the adress field when no entry is selected is nice too |
| 20:46 |
sapier |
ok that'd be my suggestion too as it's tricky to evaluate what will be selected next depends on special cases e.g. last element is selected |
| 20:47 |
PilzAdam |
oh, the selection also kept if switching between favorite and public list |
| 20:47 |
PilzAdam |
(and fields are not updated) |
| 20:47 |
sapier |
ok I fix both at once |
| 20:48 |
PilzAdam |
create a new commit in that branch, Ill squash it when merging |
| 20:48 |
sapier |
was my intention |
| 20:49 |
sapier |
ok pushed |
| 20:51 |
PilzAdam |
do you want that "clear selection when changing adress field" thing now, or should I merge what currently is in the branch first? |
| 20:52 |
sapier |
sorry don't understand? |
| 20:52 |
sokomine |
hmmmm: you said "if i were to advocate this node swapping, what i'd do is have the user supply an optional replacement list parameter to minetest.place_schematicand another field to the schematic decoration type which matches the node names and overrides them before the node names are resolved" - that's exactly what i'd like to have! could that be done? it would not only be helpful for houses. other decorations will also profit |
| 20:53 |
PilzAdam |
<PilzAdam> can you remove the selection in the list if the user changes port or adress field? |
| 20:53 |
sapier |
Oh you're talking about the selection removal if someone edits address or port field? |
| 20:53 |
PilzAdam |
^ do you want to code that before merging? |
| 20:53 |
sapier |
ok that'll be a little bit more work I think those bugfixes are not critical atm |
| 20:53 |
sapier |
I'll do the editbox changes on a different branch |
| 20:54 |
PilzAdam |
k |
| 20:54 |
sapier |
it's more feature enhancement than bugfix |
| 20:54 |
PilzAdam |
yea |
| 20:54 |
PilzAdam |
Ill merge #815 then |
| 20:59 |
PilzAdam |
is that "cfav: nil" debug output removed? |
| 21:01 |
sapier |
I think yes but I'll check again |
| 21:01 |
PilzAdam |
yep, it is |
| 21:02 |
sapier |
yes it's fixed with the rereverted serverlist commit |
| 21:02 |
sapier |
can others comment a gist entry? |
| 21:02 |
sapier |
https://gist.github.com/sapier/5961251 did I miss anything? |
| 21:04 |
PilzAdam |
updated the issue |
| 21:05 |
PilzAdam |
sapier, check the first post in #814 |
| 21:05 |
sapier |
ahh there's something below |
| 21:08 |
PilzAdam |
"2) when you change the tab and then directly click on a world then a singleclick is enough to start it (maybe a can't fix)" <- it was also present before the Lua menu |
| 21:09 |
sapier |
ok so not maybe |
| 21:10 |
sapier |
I guess to fix those issues we need to issue some pull requests to irrlicht |
| 21:10 |
PilzAdam |
there was a issue about that IIRC.... |
| 21:10 |
sapier |
there's even a patch to add doubleclick support ... already some years old |
| 21:13 |
PilzAdam |
https://github.com/minetest/minetest/issues/586 this one? |
| 21:14 |
PilzAdam |
... or not |
| 21:14 |
PilzAdam |
is that issue still valid with the new menu? |
| 21:14 |
sapier |
no a patch for irrlicht |
| 21:17 |
sapier |
http://irrlicht.sourceforge.net/forum/viewtopic.php?t=3022 |
| 21:22 |
hmmmm |
christ, 2004 |
| 21:22 |
hmmmm |
erm, is it just me, or does it seem like a fork is in tune for irrlicht? |
| 21:22 |
sapier |
yes almost a decade |
| 21:23 |
hmmmm |
(no pun intended) |
| 21:23 |
hmmmm |
we'll call it Betterlicht |
| 21:23 |
sapier |
I'm not sure if we really can cope with the additional work |
| 21:23 |
hmmmm |
nah, just kidding |
| 21:24 |
sapier |
maybe we should first try to increase pressure towards irrlicht guys ;-) |
| 21:24 |
hmmmm |
but we'd be able to fix a lot of things that way |
| 21:24 |
sapier |
I only know about three atm |
| 21:25 |
sapier |
lisbox scroll position, double click, shaders |
| 21:25 |
hmmmm |
and transparency sorting |
| 21:25 |
hmmmm |
also, iirc, irrlicht can't tesellate |
| 21:26 |
sapier |
hmm did anyone try to post fixes for that problems to irrlicht? |
| 21:26 |
hmmmm |
nope |
| 21:27 |
hmmmm |
we'd be able to do some transparency sorting on our own a few ways, it seems like the best option of those is to render the transparent nodes to a separate framebuffer first |
| 21:27 |
hmmmm |
but of course everything would work out nicer if this was in irrlicht |
| 21:27 |
hmmmm |
oh, also, we'd be able to fix the VBO not getting dropped when a meshbuffer is deleted |
| 21:28 |
hmmmm |
honestly, pushing irrlicht people to do this won't help because they won't even fix things when they have the code offered to them on a golden platter |
| 21:28 |
hmmmm |
and even if we do get it changed, we still have to deal with older versions |
| 21:29 |
sapier |
maybe we haven't found the one that is interested in fixing it yet |
| 21:29 |
sapier |
yes but it'd be a matter of time until we can drop the workarounds |
| 21:29 |
hmmmm |
yeah.. maybe like two years |
| 21:30 |
sapier |
yes I didn't say what amount of time :) |
| 21:58 |
|
smoke_fumus joined #minetest-dev |
| 21:58 |
|
sapier left #minetest-dev |
| 23:44 |
|
drizz joined #minetest-dev |
