| Time |
Nick |
Message |
| 00:04 |
|
thexyz joined #minetest-dev |
| 03:30 |
|
Kacey joined #minetest-dev |
| 03:31 |
Kacey |
hi all |
| 03:52 |
|
Kacey left #minetest-dev |
| 05:26 |
|
toabi_ joined #minetest-dev |
| 05:28 |
|
Deiz joined #minetest-dev |
| 05:29 |
|
Sylvertech joined #minetest-dev |
| 05:30 |
Sylvertech |
Hey what are you thoughts about the Oculus Rift? |
| 05:30 |
|
ecube joined #minetest-dev |
| 05:34 |
hmmmm |
no idea, but now you've got me wondering if it's minetest core development-related |
| 05:36 |
|
ecube_ joined #minetest-dev |
| 05:38 |
Sylvertech |
Yes it is. |
| 05:39 |
Sylvertech |
Related, I mean. |
| 05:39 |
Sylvertech |
What I had in mind was rather simple. |
| 05:39 |
Sylvertech |
If a person's right hand is freed from the mouse and can move the camera with his head, |
| 05:39 |
Sylvertech |
then he can have it on the keyboard along the other one. |
| 05:40 |
Sylvertech |
The left hand would still be used for WASD movement and SPACE jumping and such, |
| 05:40 |
Sylvertech |
and the right hand can be used for dual wielding items. |
| 05:41 |
Sylvertech |
" K ", " O ", " P ", and " ' ". |
| 05:42 |
Sylvertech |
Or " L " and " : " for the two middle fingers. |
| 05:42 |
hmmmm |
sounds.... interesting. |
| 05:42 |
Sylvertech |
The control configuration really depends on one's preferences, but my point is that now one has about double the fingers to use. |
| 05:43 |
Sylvertech |
Imagine the implications for PVP when you're juggling a sword and an axe or something. |
| 05:43 |
Sylvertech |
Different attack speeds. |
| 05:44 |
Sylvertech |
Anyway, if one were to also consider Mount and Blade: Warband's control scheme, with four different directions of melee combat, |
| 05:44 |
Sylvertech |
the result would be pleasant. |
| 05:44 |
Sylvertech |
So? |
| 05:52 |
hmmmm |
i don't really have any opinions on that.. maybe others do |
| 05:52 |
hmmmm |
sounds complicated though |
| 05:52 |
|
dzho_ joined #minetest-dev |
| 05:54 |
VanessaE |
personally, |
| 05:54 |
VanessaE |
I think taking your right hand off the mouse is a bad idea. |
| 05:54 |
VanessaE |
never make the user shift hands from keyboard to mouse |
| 05:56 |
|
Sylvertech joined #minetest-dev |
| 06:04 |
Sylvertech |
So did anyone get what I said about the Oculus? |
| 06:04 |
|
ffoxin joined #minetest-dev |
| 06:06 |
|
Sylvertech|2 joined #minetest-dev |
| 06:09 |
VanessaE |
my only comment is that you should never require a user to shift their hands between keyboard and mouse |
| 06:09 |
VanessaE |
(re: your right-hand-keys idea) |
| 06:11 |
Sylvertech |
I was thinking about a person doing away with the mouse completly. |
| 06:11 |
Sylvertech |
If the Rift is available, that is. |
| 06:12 |
Sylvertech |
Soem people might not have it, which is why I suggested it be a SP feature, or perhaps only on certain servers for those who can afford it. |
| 06:12 |
VanessaE |
no way |
| 06:13 |
VanessaE |
keyboard+mouse is the most efficient way to play this sort of game |
| 06:13 |
VanessaE |
this isn't a turn-based RPG here |
| 06:13 |
Sylvertech |
Ok you're right. |
| 06:13 |
VanessaE |
it bears more similarity to a fps if anything |
| 06:13 |
Sylvertech |
But I just like the Oculus Rift. |
| 06:14 |
Sylvertech |
Anyway this is of secondary importance. |
| 06:14 |
Sylvertech |
No need to fret. |
| 06:14 |
|
Sylvertech|2 left #minetest-dev |
| 06:15 |
Sylvertech |
Sorry if this might be rude, but you have heard about the Oculus Rift, right? |
| 06:15 |
VanessaE |
nope. don't really care too much about it though. |
| 06:15 |
VanessaE |
this channel is not for that kind of discussion |
| 06:15 |
Sylvertech |
Sorry then. |
| 06:16 |
Sylvertech |
Isn't this considered a game feature, however? |
| 06:16 |
Sylvertech |
Anyway toodle-oo. |
| 06:55 |
|
Sylvertech|2 joined #minetest-dev |
| 06:55 |
|
Sylvertech|4 joined #minetest-dev |
| 07:47 |
|
dzho joined #minetest-dev |
| 09:02 |
|
Sylvertech joined #minetest-dev |
| 09:03 |
|
iqualfragile joined #minetest-dev |
| 09:12 |
|
Calinou joined #minetest-dev |
| 09:13 |
|
dzho joined #minetest-dev |
| 09:13 |
|
Jordach joined #minetest-dev |
| 09:13 |
|
Jordach joined #minetest-dev |
| 09:16 |
|
ecube joined #minetest-dev |
| 09:43 |
|
iqualfragile joined #minetest-dev |
| 09:49 |
|
PilzAdam joined #minetest-dev |
| 10:03 |
|
Jordach1 joined #minetest-dev |
| 10:06 |
|
Jordach1 joined #minetest-dev |
| 10:11 |
|
Sylvertech joined #minetest-dev |
| 10:18 |
|
Jordach joined #minetest-dev |
| 10:27 |
|
iqualfragile joined #minetest-dev |
| 10:41 |
|
jin_xi joined #minetest-dev |
| 10:45 |
RealBadAngel |
https://github.com/minetest/minetest/pull/516 |
| 10:46 |
RealBadAngel |
ive changed editbox in formspec |
| 10:47 |
RealBadAngel |
it was annoyin when inputing data or search strings that pressing enter causes to close the formspec |
| 10:48 |
RealBadAngel |
instead it just loose focus. when nothin is focused then enter can close the formspec |
| 10:48 |
PilzAdam |
so you have to hit enter twice in signs? |
| 10:48 |
RealBadAngel |
yes |
| 10:48 |
RealBadAngel |
or use button |
| 11:07 |
|
EdB joined #minetest-dev |
| 11:19 |
|
Sylvertech joined #minetest-dev |
| 11:36 |
|
Sylvertech joined #minetest-dev |
| 11:49 |
|
darkrose joined #minetest-dev |
| 12:31 |
|
Sylvertech| joined #minetest-dev |
| 13:52 |
|
Sylvertech joined #minetest-dev |
| 13:55 |
|
realbadangel_ joined #minetest-dev |
| 13:57 |
|
darkrose_ joined #minetest-dev |
| 14:00 |
|
darkrose joined #minetest-dev |
| 14:04 |
|
hmmmm joined #minetest-dev |
| 14:46 |
|
PilzAdam_ joined #minetest-dev |
| 15:40 |
|
Calinou joined #minetest-dev |
| 15:56 |
|
iqualfragile joined #minetest-dev |
| 16:15 |
realbadangel_ |
hi all |
| 16:17 |
RealBadAngel |
hmmmm, posted a fix for editbox in formspecs |
| 16:18 |
RealBadAngel |
https://github.com/minetest/minetest/pull/516 |
| 17:03 |
|
rubenwardy joined #minetest-dev |
| 17:11 |
hmmmm |
fix for editbox in formspecs? |
| 17:11 |
hmmmm |
what was broken? |
| 17:13 |
VanessaE |
hmmmm: in some cases, pressing enter after typing in some kind of input should merely cause the input line to lose focus, rather than actually close the window. Unified Inventory's search function, for example. |
| 17:14 |
VanessaE |
can't say I agree about how it changes sign formspecs though |
| 17:14 |
VanessaE |
(sorry RBA) |
| 17:14 |
PilzAdam |
I agree to the change |
| 17:14 |
VanessaE |
s/window/formspec/ |
| 17:14 |
PilzAdam |
pressing enter twice in signs isnt very hard |
| 17:14 |
VanessaE |
No, not at all |
| 17:15 |
VanessaE |
some people will be confused by the change, but it's not like you go around editing sign text continuously. |
| 17:15 |
VanessaE |
so that's okay if that's how it has to be |
| 17:16 |
hmmmm |
so you need to press enter twice in order to close a formspec when you had focus on a textbox? |
| 17:16 |
VanessaE |
hmmmm: that's the plan. |
| 17:16 |
hmmmm |
what.. why |
| 17:16 |
VanessaE |
well |
| 17:16 |
hmmmm |
that doesn't.. |
| 17:17 |
VanessaE |
in a sign, it's probably less sensible than enter-to-commit-and-close, but for example in Unified Inventory, focus currently defaults to the search field. When one hits enter, the logical assumption is that this will execute a search - but instead it just closes the formspec. |
| 17:17 |
hmmmm |
okay so i understand the problem |
| 17:17 |
hmmmm |
but why does this have to be the change |
| 17:18 |
hmmmm |
i assume pressing enter with the formspec in focus closes it |
| 17:18 |
hmmmm |
while pressing enter within the textedit's focus makes it lose focus |
| 17:18 |
VanessaE |
yes, that's the plan, but as it stands now, enter always closes the formspec. |
| 17:18 |
hmmmm |
when you press enter while focused on the textbox, does the formspec itself receive the enter event? |
| 17:18 |
VanessaE |
I don't think so, no. |
| 17:19 |
hmmmm |
this was originally designed with the intention of only accepting some input from some formspec |
| 17:20 |
hmmmm |
you don't have control over the actual code that gets executed though |
| 17:20 |
hmmmm |
so wait, explain to me how the formspec works. how do you specify the elements, what do you get to specify exactly |
| 17:20 |
hmmmm |
how do you interact with this all, through lua? |
| 17:21 |
PilzAdam |
https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L686 |
| 17:21 |
PilzAdam |
you basically list all the elements in a string |
| 17:21 |
hmmmm |
okay, that defines the interface, i knew that much already |
| 17:21 |
hmmmm |
but what actually gets the text when you enter it |
| 17:22 |
PilzAdam |
and when pressing a button this callback is called: https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L1515 |
| 17:22 |
hmmmm |
okay |
| 17:22 |
hmmmm |
so then why is quitMenu() called after accepting the input? |
| 17:22 |
PilzAdam |
s/button pressed/button pressed or hitting enter in a field |
| 17:22 |
hmmmm |
quitMenu() should be called by the acceptInput callback |
| 17:23 |
hmmmm |
the callback decides what to do after somebody entered text |
| 17:23 |
hmmmm |
it only makes sense to do this, instead of just changing behavior and having people press enter ....twice.... to do whatever, for some odd reason |
| 17:24 |
PilzAdam |
currently Lua cant close formspecs |
| 17:24 |
VanessaE |
didn't I suggest a separate function/callback/whatever before? |
| 17:24 |
hmmmm |
i'm sorry, i want to be an agreeable person but i can't agree with this. it's too odd and it doesn't make any sense to require the user to do such an ass backwards thing like press enter twice. they'll think THAT is a new bug |
| 17:24 |
VanessaE |
(well, maybe to RBA in private, we talked about this issue some weeks ago, without any solution at the time) |
| 17:24 |
hmmmm |
then why don't you add a Lua API to close formspecs? |
| 17:25 |
hmmmm |
that would be the solution; not this |
| 17:25 |
hmmmm |
maybe it's even easier |
| 17:25 |
PilzAdam |
if someone does this, an on_close() callback would be nice too |
| 17:25 |
hmmmm |
what does on_receive_fields return? |
| 17:26 |
PilzAdam |
nothing |
| 17:26 |
hmmmm |
well what the hell? |
| 17:26 |
PilzAdam |
maybe return true -> close formspec |
| 17:26 |
hmmmm |
shouldn't it return a boolean of whether or not to close the formspec |
| 17:26 |
hmmmm |
there's your answer |
| 17:26 |
hmmmm |
modify the api to have it return true if close, false if stay open |
| 17:26 |
hmmmm |
any other 'solution' to this is just weird and unacceptable |
| 17:27 |
hmmmm |
sometimes i wonder what minetest would be like if everybody just said yes to everything |
| 17:29 |
VanessaE |
heh |
| 17:29 |
RealBadAngel |
hmm, why dont you look at this from this point of view |
| 17:30 |
RealBadAngel |
editboxes are unusable by now |
| 17:30 |
RealBadAngel |
because if you press enter on any of them |
| 17:30 |
VanessaE |
to be fair, we've seen what MT almost became when everyone said 'no'... so a few yes's isn't so bad |
| 17:30 |
RealBadAngel |
whole formspec closes |
| 17:31 |
RealBadAngel |
there shall be exit editbox used for signs (like exit button) |
| 17:31 |
RealBadAngel |
and this one shall be used with signs |
| 17:32 |
RealBadAngel |
calling fucked up editbox behaviour a feature is a nonsense |
| 17:33 |
hmmmm |
realbadangel, if we changed on_receive_field to return whether or not it closes, this becomes a non-issue |
| 17:33 |
RealBadAngel |
i can add another type of editbox with is_exit flag set to use in simple inputs |
| 17:33 |
hmmmm |
just read the above solution |
| 17:34 |
RealBadAngel |
you dont get it. i do have 10 edit boxes. pressing enter on any closes formspec |
| 17:34 |
RealBadAngel |
let it be one of them command line of my computer |
| 17:34 |
RealBadAngel |
shall i avoid pressing enter in computer? |
| 17:35 |
hmmmm |
well then why would you all of them return true to close on enter? |
| 17:35 |
hmmmm |
have all of them* |
| 17:35 |
hmmmm |
then it would be the mod maker's fault |
| 17:35 |
RealBadAngel |
i just want them not to close the whole formspec |
| 17:36 |
RealBadAngel |
because theyre not supposed to be doing so |
| 17:36 |
RealBadAngel |
pressing enter shall send stored data |
| 17:36 |
RealBadAngel |
not close the application |
| 17:38 |
hmmmm |
yes... and what i proposed would solve that. |
| 17:38 |
hmmmm |
re-read it |
| 17:41 |
RealBadAngel |
first of all i dont like enter being able to close formspec but nvm |
| 17:41 |
RealBadAngel |
toggle I shall do it (or ESC) |
| 17:42 |
RealBadAngel |
"so then why is quitMenu() called after accepting the input?" this is hardcoded behaviour for enter |
| 17:43 |
hmmmm |
i was just going back and trying to make sense of this, i was wondering why it was designed like that in the first place |
| 17:44 |
hmmmm |
the original design is stupid, yes |
| 17:44 |
hmmmm |
we're fixing that though |
| 17:44 |
RealBadAngel |
it was designed only for signs |
| 17:44 |
VanessaE |
my guess is that the idea that enter should do anythign but accept-and-close simply never occurred. |
| 17:45 |
RealBadAngel |
there are two cases for enter (if not focused on editbox) quits |
| 17:45 |
RealBadAngel |
if focused on editbox accepts input and quits |
| 17:46 |
RealBadAngel |
if anybody is thrilled by having to press enter twice there shall be another kind of editbox with is_exit = true flag set |
| 17:46 |
RealBadAngel |
like for exit buttons |
| 17:47 |
RealBadAngel |
so it will accept input and quit |
| 17:48 |
RealBadAngel |
and such one shall be used for sign like formspecs |
| 17:53 |
RealBadAngel |
and with my change callback function is called |
| 17:54 |
RealBadAngel |
fields.editboxname holds then input |
| 18:07 |
|
Sylvertech| joined #minetest-dev |
| 18:11 |
hmmmm |
what's wrong with what i said.. |
| 18:22 |
RealBadAngel |
im lost with this lol. what do you propose exactly |
| 18:22 |
RealBadAngel |
? |
| 18:27 |
thexyz |
proller: http://forum.minetest.net/viewtopic.php?pid=73621#p73621 |
| 18:27 |
thexyz |
probably related to your changes |
| 18:29 |
proller |
celeron55 wrote about one curl flag for multithread |
| 18:30 |
thexyz |
hm.. |
| 18:30 |
thexyz |
22:29:18: ACTION[ServerThread]: announcing to not.exists |
| 18:30 |
thexyz |
*** longjmp causes uninitialized stack frame ***: ./bin/minetestserver terminated |
| 18:30 |
thexyz |
i thought i fixed all those flags |
| 18:31 |
thexyz |
yes, definetly |
| 18:32 |
proller |
wow |
| 18:32 |
thexyz |
all three curl_easy_perform(curl); are preceded with curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1); |
| 18:34 |
thexyz |
oh crap |
| 18:35 |
thexyz |
i forgot to rebuild minetest that time |
| 18:35 |
RealBadAngel |
<hmmmm> shouldn't it return a boolean of whether or not to close the formspec |
| 18:35 |
RealBadAngel |
<hmmmm> there's your answer |
| 18:35 |
RealBadAngel |
<hmmmm> modify the api to have it return true if close, false if stay open |
| 18:36 |
RealBadAngel |
how i could do that if theres hardcoded enter->quit behaviour there?? |
| 18:36 |
VanessaE |
hmmmm: <offtopic> status report on emergethread: it's still lagging by a few seconds from time to time, but the lockups seem to be pretty much history. Nice work. </offtopic> |
| 18:37 |
thexyz |
oh |
| 18:37 |
thexyz |
so lockups don't occur anymore? |
| 18:37 |
VanessaE |
thexyz: nope. not so far as I've seen |
| 18:37 |
thexyz |
great |
| 18:38 |
VanessaE |
what's the unit for the 'uptime' field? minutes? |
| 18:38 |
thexyz |
where? |
| 18:38 |
RealBadAngel |
not the seconds? |
| 18:38 |
VanessaE |
in the /status display |
| 18:38 |
thexyz |
seconds |
| 18:38 |
VanessaE |
ok. |
| 18:39 |
|
Taoki joined #minetest-dev |
| 18:39 |
VanessaE |
hm, uptime's only ~6900. musta crashed earlier *shrug*. |
| 18:39 |
VanessaE |
still, I haven't seen emergethread hard-lock at all since that big update. |
| 18:40 |
thexyz |
VanessaE: any logs? |
| 18:40 |
VanessaE |
didn't look. |
| 18:40 |
VanessaE |
probably some random mod |
| 18:40 |
thexyz |
can you upload debug.txt somewhere? |
| 18:42 |
VanessaE |
hm. *looks at log*.. whatever prompted the last restart didn't get logged. Oh well, it's not related to anything here. |
| 18:42 |
VanessaE |
it musta segfaulted or something. |
| 18:43 |
thexyz |
that's bad |
| 18:43 |
VanessaE |
if you're interested: http://pastebin.ubuntu.com/5582992/ |
| 18:44 |
thexyz |
bad |
| 18:44 |
VanessaE |
I'll run it through gdb later on and grab a backtrace if it dies again. |
| 18:50 |
hmmmm |
RealBadAngel, there's obviously no way around this without modifying the core |
| 18:50 |
VanessaE |
ok. it's running via gdb now (and it's a debug build) |
| 18:50 |
hmmmm |
the idea is to change the API so that it returns a boolean |
| 18:51 |
hmmmm |
so you do if (acceptInput()) quitMenu(); |
| 18:51 |
VanessaE |
I agree with hmmmm's idea, btw. |
| 18:52 |
RealBadAngel |
so you want to acceptInput wait for Lua callback to return a value? |
| 18:53 |
hmmmm |
yeah |
| 18:53 |
RealBadAngel |
ok, i will try this way |
| 18:58 |
RealBadAngel |
just a thought, doesnt that means need to rewrite all mods that used callbacks to make them return something? |
| 19:00 |
hmmmm |
yes |
| 19:04 |
RealBadAngel |
and all this because of 2 times enter needed? |
| 19:05 |
hmmmm |
absolutely |
| 19:05 |
RealBadAngel |
then i rather will like to see here edit box with default quit behavior |
| 19:06 |
RealBadAngel |
like other formspec elements |
| 19:06 |
RealBadAngel |
button_exit[<X>,<Y>;<W>,<H>;<name>;<label>] |
| 19:06 |
RealBadAngel |
^ When clicked, fields will be sent and the form will quit. |
| 19:06 |
RealBadAngel |
image_button_exit[<X>,<Y>;<W>,<H>;<texture name>;<name>;<label>] |
| 19:06 |
RealBadAngel |
^ When clicked, fields will be sent and the form will quit. |
| 19:06 |
RealBadAngel |
like this ones |
| 19:07 |
hmmmm |
that is ridiculous, who designed formspec |
| 19:07 |
PilzAdam |
RealBadAngel, thats too complicated |
| 19:07 |
hmmmm |
so you just want to follow suit with what the others did |
| 19:07 |
RealBadAngel |
dont even try to tell me that forcing all the mods outside to rewrite their code is not complicated |
| 19:08 |
hmmmm |
i'd rather break compatibility and do things the right way.... |
| 19:08 |
PilzAdam |
if you say return true in on_recieve_field will keep the formspec open, nothing will be broken |
| 19:08 |
RealBadAngel |
but this change would break everythin around |
| 19:08 |
jin_xi |
well, idk but i'd gladly update all my mods towards a saner formspec thing. |
| 19:10 |
RealBadAngel |
but with adding a editbox_exit element will fix everythin too |
| 19:10 |
hmmmm |
nevermind any of this, you've all forgotten to actually check whether or not it's possible for acceptInput to return a boolean |
| 19:10 |
RealBadAngel |
no need to change mods but the one and only default sign formspec |
| 19:10 |
hmmmm |
and it's not because it sends something over the network |
| 19:11 |
RealBadAngel |
i did not |
| 19:11 |
hmmmm |
so there are two possibilities here |
| 19:11 |
RealBadAngel |
im lookin at the code right now |
| 19:11 |
hmmmm |
1). add a textbox_exit[] |
| 19:11 |
hmmmm |
2). add an exit_formspec() lua API |
| 19:12 |
hmmmm |
something that would break no compatibility whatsoever would be to add a textbox_noexit[] (this would break the current formspec convention though) |
| 19:12 |
RealBadAngel |
it will not break, it will change it to logical behaviour |
| 19:13 |
hmmmm |
alright, i'm gonna have to be honest, what i would do is add a textbox_noexit formspec control and have the mods that don't want to exit after pressing enter use that |
| 19:13 |
hmmmm |
while all the others that were relying on the previous behavior will continue to do what they're doing |
| 19:13 |
RealBadAngel |
that can be done |
| 19:13 |
hmmmm |
and then some time in the future when formspec gets cleaned up, we'll fix all of this the right way |
| 19:13 |
jin_xi |
ay |
| 19:14 |
hmmmm |
but for now i guess it can be patched in this manner |
| 19:14 |
hmmmm |
it's not ideal, but at least it fixes the problem and doesn't add a new retarded bug that's easy to avoid |
| 19:14 |
RealBadAngel |
oke doke |
| 19:14 |
RealBadAngel |
will pull that today, its easy to code |
| 20:04 |
VanessaE |
someone needs to fix the bug where placing a block occasionally replaces the spot you right-clicked on (rather than placing it next to/on top of it) before 0.4.5, if possible |
| 20:08 |
PilzAdam |
has someone a log with --verbose of it? |
| 20:09 |
VanessaE |
dunno |
| 20:09 |
VanessaE |
I don't |
| 20:10 |
PilzAdam |
debug_log_level = 4 is very useful |
| 20:10 |
|
ShadowNinja joined #minetest-dev |
| 20:10 |
VanessaE |
oh, well I have that in place on my server already |
| 20:11 |
VanessaE |
oh sure, now that I try to reproduce it, it doesn't want to bug out. |
| 20:11 |
hmmmm |
it's difficult to reproduce |
| 20:12 |
hmmmm |
seems like a problem in lua though |
| 20:12 |
Exio |
i get that bug more times when using noclip and placing blocks "without air near" |
| 20:12 |
Exio |
or whatever you want to say that |
| 20:20 |
VanessaE |
also, another minor bug that shouldn't be too hard to fix, water flowing animation direction |
| 20:21 |
VanessaE |
it often appears to flow "upwards" when it clearly shouldn't. |
| 20:22 |
VanessaE |
I believe lava is similarly affected (but I haven't looked) |
| 20:59 |
PilzAdam |
should we bump the protocol version and move this https://github.com/minetest/minetest/blob/master/src/nodedef.cpp#L275 and this https://github.com/minetest/minetest/blob/master/src/nodedef.cpp#L339 to the correct place before releasing? |
| 21:00 |
hmmmm |
definitely not.. it's too late for that |
| 21:03 |
VanessaE |
-1000 |
| 21:03 |
VanessaE |
do *not* go changing the the protocol version for anything at this point |
| 21:06 |
FakeGoodDemon |
and celeron55->sempron66 |
| 21:07 |
FakeGoodDemon |
okay i'm done ;/ |
| 21:47 |
VanessaE |
http://forum.minetest.net/viewtopic.php?pid=73727#p73727 |
| 21:47 |
VanessaE |
THIS is fucking annoying |
| 21:47 |
VanessaE |
can we get this fixed before 0.4.5? |
| 21:47 |
VanessaE |
happens to me with all kinds of similar objects (default doors, homedecor doors and wall lights, signs, etc) |
| 21:50 |
* hmmmm |
has no idea about that |
| 21:50 |
hmmmm |
i'll stay out of it |
| 22:16 |
|
iqualfragile1 joined #minetest-dev |
| 22:27 |
|
ecube_ joined #minetest-dev |
| 22:37 |
|
mrtux joined #minetest-dev |
| 22:46 |
VanessaE |
a request has been made on my server that formspec images backgrounds be able to cover up the chat text |
| 22:47 |
VanessaE |
e.g. when the formspec opens, the F2 chat text should get buried behind the formspec. |
| 22:57 |
|
mrtux joined #minetest-dev |
| 23:54 |
|
ShadowNinja joined #minetest-dev |
| 23:55 |
VanessaE |
another accidental place node -> replaced node |
| 23:55 |
VanessaE |
18:56:00: ACTION[ServerThread]: VanessaEzekowitz places node homedecor:fence_chainlink at (98,32,-518) |
| 23:55 |
VanessaE |
(followed by the facedir message from homedecor) |
| 23:56 |
ShadowNinja |
VanessaE: can you use --verbose without causing too much lag? |
| 23:56 |
VanessaE |
sure |
| 23:56 |
ShadowNinja |
maybe we can get some useful info |
| 23:57 |
VanessaE |
holy shit |
| 23:57 |
VanessaE |
that is a metric assload of spew |
