Time |
Nick |
Message |
00:26 |
|
sapier left #minetest-dev |
00:28 |
|
OldCoder joined #minetest-dev |
00:29 |
|
Taoki joined #minetest-dev |
00:48 |
|
hmmmm joined #minetest-dev |
01:57 |
|
NakedFury joined #minetest-dev |
01:57 |
|
PenguinDad joined #minetest-dev |
03:08 |
|
Miner_48er joined #minetest-dev |
04:51 |
|
harrison joined #minetest-dev |
04:56 |
|
zat joined #minetest-dev |
05:43 |
|
Hunterz joined #minetest-dev |
06:14 |
|
Zeno` joined #minetest-dev |
06:15 |
|
hmmmm joined #minetest-dev |
06:16 |
Zeno` |
hi hmmmm |
06:16 |
hmmmm |
hello zeno` |
06:18 |
Zeno` |
hmmmm see this: https://github.com/minetest/minetest/issues/1559 ? |
06:19 |
hmmmm |
it's really not that simple |
06:19 |
hmmmm |
that's caused by some very obscure bug |
06:19 |
Zeno` |
I think I know one reason that causes that behaviour: changing the mapgen params on an already generated map (I mean a map that already has areas mapgenned) |
06:19 |
Zeno` |
I can duplicate it |
06:19 |
hmmmm |
it's not like we say, "oh! let's keep running the cave generation in old chunks!" |
06:20 |
Zeno` |
but, that's just *one* potential reason |
06:20 |
Zeno` |
Just thought I'd let someone know |
06:20 |
hmmmm |
if you change the mapgen params on a map that's already been created, it'll ignore those and keep using the parameters it had been created with |
06:20 |
Zeno` |
it doesn't seem to for me |
06:22 |
Zeno` |
I change the values in world.mt to crazy values, I get crazy landscapes |
06:22 |
Zeno` |
*shrug* |
06:22 |
Zeno` |
I'll investigate more later |
06:23 |
Zeno` |
are the mapgen parameters duplicated in the database (leveldb) ? |
06:25 |
|
hmmmm joined #minetest-dev |
06:29 |
hmmmm |
no |
06:29 |
hmmmm |
the database file only contains map block data |
06:29 |
hmmmm |
the map metadata is stored in map_meta.txt |
06:42 |
Zeno` |
so how does changing it "it'll ignore those and keep using the parameters it had been created with" |
06:46 |
hmmmm |
you might be confused |
06:47 |
|
twoelk joined #minetest-dev |
06:47 |
hmmmm |
you're supposed to change mapgen parameters in the minetest configuration file |
06:47 |
hmmmm |
mapgen parameters that are stored in map_meta.txt are not meant to be modified by end users and are there to preserve map settings |
06:48 |
Zeno` |
I bet many people do change them, supposed to or not |
06:48 |
Zeno` |
I'm just saying, that's all. :) |
06:49 |
hmmmm |
so you want them to be hidden better? |
06:49 |
Zeno` |
I don't think that's a solution any more than you do :p |
06:49 |
Zeno` |
I merely raised the point as a "potential" source for these hard to find / obscure bugs |
06:49 |
Zeno` |
which may not be "bugs" as such |
06:51 |
Zeno` |
I.e. I'm just suggesting that maybe (at least once in a while) such things may be end user error |
06:51 |
hmmmm |
most "bugs" end up as user error because too much trust is placed in the user |
06:51 |
Zeno` |
Well, it's open source. You can't hide things |
06:51 |
hmmmm |
it just doesn't seem right to restrict those who know what they're doing thanks to people who don't |
06:52 |
Zeno` |
I'm not suggesting that as a solution :) |
06:52 |
hmmmm |
major web browsers are removing features |
06:52 |
Zeno` |
I'm suggesting that maybe there is no bug at all |
06:52 |
hmmmm |
that's one way |
06:52 |
Zeno` |
Yeah, a very annoying way |
06:52 |
hmmmm |
minetest is nowhere nearly as mature as, say, firefox though |
06:52 |
hmmmm |
removing features is possibly the worst thing that could be done |
06:53 |
Zeno` |
I agree |
06:53 |
twoelk |
if it is a user mistake it can be described in some doc, like see we told you not to do that |
06:53 |
Zeno` |
twoelk, so perhaps the solution is just that... |
06:53 |
Zeno` |
*if* that is the source of the error |
06:54 |
twoelk |
but from a user about a problem related or not, I played a lot with this file described here https://forum.minetest.net/viewtopic.php?p=150822#p150822 |
06:54 |
Zeno` |
I know that it *can* cause that bug... I don't know if that's what people are seeing it are actually doing that though |
06:54 |
twoelk |
I moved around a very high building that triggered some mapgen a lot of times |
06:55 |
twoelk |
sometimes caves but often only grass toppings |
06:55 |
twoelk |
I tried preloading the area, flying around whatever |
06:56 |
twoelk |
It seemed that mapgen got interested again once the area contained some stone |
06:57 |
hmmmm |
that can happen if a block is already exists, is generated, and stored in the database, but is not marked with the "generated" flag |
06:57 |
hmmmm |
which is caused by some very difficult to track bug |
06:58 |
Zeno` |
potentially map_meta.txt has another subtle error though... the precision of floats that the Lua lib is compiled with (you can, for example, change it to compile with float instead of double [or the other way around... I can't remember the default]). This would *potentially* cause very small errors or differences in real numbers |
06:58 |
hmmmm |
that's pretty moot because floating point numbers are expected to have errors in them |
06:59 |
twoelk |
so it might be something saved wrong to the database? |
06:59 |
twoelk |
has this been reported from all database kinds then? |
06:59 |
hmmmm |
this could happen if the block is unloaded as it's being generated |
07:00 |
Zeno` |
hmmmm, that's correct but if you round a float vs. a double (both initialised with a constant) there *can* be differences in the result (easily) |
07:00 |
hmmmm |
it has nothing to do with the database, but rather an internal logic error or maybe a race condition |
07:01 |
Zeno` |
I'm no so sure about the race condition myself. The simplest answer, to me, is that people are changing map_meta.txt by hand (I've done it) |
07:01 |
Zeno` |
There's nowhere saying it's a bad idea, so why not? |
07:02 |
twoelk |
I definitly did not change any map_meta.txt on that map |
07:03 |
twoelk |
If mapgen is not to touch allready generated area, I would rather think it is bypassing that |
07:04 |
twoelk |
maybe as a user comes along it imposes a change by the user |
07:05 |
Zeno` |
I wouldn't *expect* changes to map_meta.txt to affect already generated areas either |
07:05 |
hmmmm |
somebody brought up mapgen params |
07:05 |
hmmmm |
i was just explaining that |
07:05 |
Zeno` |
I can't think of anything I'd *expect* to change already generated areas |
07:05 |
hmmmm |
changes to map_meta.txt actually might do this however. in particular, chunksize |
07:06 |
Zeno` |
hmm, yes |
07:06 |
Zeno` |
or seed |
07:06 |
hmmmm |
no, not seed |
07:06 |
Zeno` |
well, not seed if chunsize remains constant |
07:12 |
|
nore joined #minetest-dev |
07:12 |
twoelk |
regarding the tall building, when it happened, caves would munch any node kind but only "natural" nodes such as stone or sand would be replaced, while the grass topping would be placed ontop of anything like them torches at the top |
07:13 |
hmmmm |
it could be that the block is silently failing to save |
07:13 |
twoelk |
so the glass parts might be gone but not replaced |
07:13 |
hmmmm |
if the server in question is out of date |
07:14 |
twoelk |
so it should happen more often on old servers/hardware? |
07:15 |
hmmmm |
old servers that haven't been updated to prevent this kind of thing |
07:15 |
hmmmm |
actually come to think of it, this is exactly what would be caused by a block that failed to save before the semi-recent fix |
07:16 |
twoelk |
well my playing with the tall building was a local singleplayer map made that day although on an old computer ;-P |
07:19 |
twoelk |
so a map should, for example be converted to another database and back to force a rewrite that might fix old issues |
07:21 |
twoelk |
I don't think this will cover all cases, something is happening on new maps as well |
07:29 |
Zeno` |
ugh |
07:30 |
Zeno` |
so bug fixes are now "enhancements" hehe |
07:43 |
* twoelk |
wonders what events actually trigger mapgen |
07:55 |
Zeno` |
class EmergeManager looks after it all (I think) |
07:56 |
Zeno` |
and MapgenFactory |
07:56 |
Zeno` |
lol @ "factory" |
07:56 |
Zeno` |
Java style |
08:07 |
|
Jordach joined #minetest-dev |
08:08 |
|
Hunterz joined #minetest-dev |
09:39 |
|
proller joined #minetest-dev |
09:40 |
|
GhostDoge joined #minetest-dev |
09:46 |
|
PilzAdam joined #minetest-dev |
10:29 |
|
sapier joined #minetest-dev |
11:09 |
Exio4 |
OOP design pattern's book was written in C++ if i remember correctly |
11:12 |
sapier |
"design patterns" ... well if ppl know what those are good for they may help discussing about things ... but at least what I experienced lot of ppl not knowing what they do hide their missing knowledge behind shiny pattern names |
11:16 |
Zeno` |
meh, sedgewick? |
11:17 |
Zeno` |
sapier, why is my buf fix now an... enhancement? |
11:17 |
Zeno` |
bug* |
11:18 |
sapier |
which one? |
11:18 |
Zeno` |
can't remember... l-system trees not being random |
11:19 |
sapier |
adding randomness seemd to be an enhancement to me as it does work without too ... yet the result is way better with it ... isn't it? |
11:19 |
Zeno` |
whether it's a bug or not is probably debatable, but the biggest mod that uses l-system tree is moretrees |
11:19 |
Zeno` |
no, without that change all the trees look the same because the seed is the same |
11:20 |
sapier |
that's not nice but still correct |
11:20 |
Zeno` |
unless VE changes moretrees to pass a random see via Lua |
11:20 |
Zeno` |
if it's not a bug then I think the documentation should be updated |
11:21 |
sapier |
hmm are you trying to tell me it's a core workaround for a mod bug? |
11:21 |
Zeno` |
to stress that unless random_seed (or whatever it's called) is supplied via Lua all the trees will look the same |
11:21 |
sapier |
can random seed be passed from lua there? |
11:21 |
Zeno` |
yeah it can |
11:22 |
sapier |
if I pass a random seed will this one be used after your fix? |
11:22 |
sfan5 |
sapier: if you want to save space for minetest then make the button have less width to not make them look so compressed |
11:22 |
Zeno` |
yes |
11:22 |
Zeno` |
if you explicitly set random_seed then that will be used |
11:22 |
Zeno` |
if you do not set a seed then the seed with will random |
11:22 |
sapier |
Zeno`: ok then your fix at least doesn't break things |
11:23 |
sapier |
because e.g. if someone intentionally wants to create exactly same bugs a forced random seed would be bad |
11:23 |
sapier |
sfan5: where did I want to save space? |
11:23 |
Zeno` |
I made sure of that :) I debated for many days whether or not this was needed. A fixed seed is useful for debugging |
11:24 |
sfan5 |
<sapier> [...] 4) intentional to save room for minetest |
11:24 |
Zeno` |
But you can intentionally create the same PNRG sequence after the patch (by supplying a fixed seed) |
11:24 |
sfan5 |
jump and descend buttons |
11:25 |
sapier |
sfan5: ahh now I'm back with you ... problem with "less width" is my fingers have some fixed width while I can place them at the lower end of screen I can't cut them into pieces ... well maybe I could but I wont do for sure ;-P |
11:25 |
Zeno` |
At the moment every mod I have looked at (mostly moretrees I admit) assumes that the trees will be random in some way; they won't currently because the PNRG seed is always 0 (because none of the mods I've looked at supply a random seed from Lua) |
11:26 |
Zeno` |
why do I keep typing PNRG? lol |
11:27 |
sfan5 |
Zeno`: it genrates Pseudo-numbers! :P |
11:27 |
Zeno` |
yeah I should be type PRNG though :p |
11:27 |
sapier |
sfan5: I understand your issues but changing that gui should only be done by checking more then one device, I understand that this ui isn't perfect maybe not even good for your device. Yet I refuse to completely optimize it to your device if this means breaking other devices. |
11:28 |
Zeno` |
in any case, either the patch needs to be applied or Lua API updated. Either will work. |
11:28 |
Zeno` |
Lua API docs* |
11:28 |
sfan5 |
sapier: just do whatever you want to make the button not look compressed |
11:28 |
sfan5 |
ugly buttons is far worse than buttons that are too big or too small |
11:29 |
sapier |
if buttons cover 2/3 of screen that's bad too |
11:29 |
|
proller joined #minetest-dev |
11:29 |
Zeno` |
If the patch is not applied VE will just have to update moretrees (although I think I agree with her that setting the seed in C++ is probably more efficient) |
11:29 |
sfan5 |
thats not what I mean |
11:29 |
sapier |
especially if it's a tablet screen |
11:29 |
sfan5 |
buttons being _a bit_ too small or too big is not as bad as buttons looking ugly |
11:29 |
sapier |
sfan5: but that's why this button placement was initially done |
11:30 |
sfan5 |
whatever |
11:30 |
sfan5 |
just try to make them look less ugly |
11:30 |
sapier |
sfan5: If I could do that I would ;-) but I'm still no designer and wont get one anytime soon ;-) |
11:30 |
Zeno` |
I have a saying: "ugly is the eye of the beholder" |
11:30 |
Zeno` |
I came up with that myself |
11:30 |
sfan5 |
button.width = button.width * 0.75 |
11:30 |
Zeno` |
no help |
11:30 |
sfan5 |
that should solve it |
11:31 |
sapier |
no |
11:31 |
sapier |
that'd waste room on screen |
11:31 |
sapier |
not fix the issue |
11:31 |
sapier |
your issue is "buttons are ugly" but your solution is "change the ui" ... that's crap |
11:32 |
sfan5 |
how would you fix that w/o changing the UI? |
11:32 |
sapier |
a different pictogram maybe? |
11:32 |
sapier |
something not looking compressed but showing the meaning |
11:34 |
sapier |
btw someone wanted to implement some sort of "drag dot" ui ... I wouldn't have problem with replacing the ui in total ... I just don't have time to do it myself ... and even less interest in fighting for that ui ... because as usual in ui there'll be as many ppl not liking as liking it |
11:35 |
Zeno` |
why should there be fighting? :( |
11:35 |
sapier |
this is minetest |
11:42 |
Zeno` |
oh yeah |
11:42 |
Zeno` |
forgot |
11:49 |
|
ImQ009 joined #minetest-dev |
11:50 |
sapier |
but still I know android ui isn't perfect I have no problem replacing the graphics with better ones but for ui I changes I demand more then one opinion about one particular device |
11:56 |
sapier |
hmm maybe we should create a gallery how things look like on different devices, as screenshots aren't enough to show |
11:56 |
sapier |
we'd need to scale the image to devices screen dpi |
11:56 |
Zefram_Fysh |
that sounds useful |
11:56 |
sapier |
well but a lot of work too |
11:57 |
Zefram_Fysh |
it's annoying how those two things are often correlated |
11:57 |
sapier |
ui highly depends on screen size and dpi and we don't have any experience in those things yet |
11:58 |
sapier |
minetest just didn't handle them a few versions ago and the current way of doing it is obviously bugged as hell |
11:59 |
sapier |
I wonder if it's worth adding scalable non freetype fonts |
11:59 |
Zefram_Fysh |
would making freetype a hard dependency be a problem? |
12:00 |
sapier |
well depends |
12:00 |
sapier |
freetype implementation for irrlicht is bugged as hell |
12:01 |
Zefram_Fysh |
hmm |
12:01 |
sapier |
it doesn't handle a lot of font errors |
12:01 |
sapier |
except of crashing of course |
12:01 |
Zefram_Fysh |
maybe it would be worth fixing that |
12:01 |
sapier |
hmm |
12:02 |
sapier |
well looking at our fallback freetype font 4.4 mb ... adding 3mb of scalable non freetype fonts doesn't look as bad as I thought |
12:03 |
Zefram_Fysh |
sure, the data size isn't terrible, but it's a pain to maintain parallel implementations of the font stuff |
12:03 |
Zeno` |
maybe *that* doesn't look bad, but the fonts will |
12:03 |
Zefram_Fysh |
fewer options to consider for the gallery of UI appearance |
12:04 |
sapier |
as irrlicht doesn't support freetype anyway we'd always have a fallback |
12:05 |
Zeno` |
freetype rendering is probably more complicated than the entire irrlicht code base |
12:05 |
Zeno` |
there is some serious crap that needs to be done to render fonts correctly |
12:06 |
sapier |
possible but I won't rewrite freetype for sure nor will I look for errors in there ;-) |
12:06 |
Zeno` |
the freetype mailing list is very active. If an error is found it's usually fixed within days |
12:07 |
sapier |
freetype isn't the problem irrlicht is |
12:08 |
Zeno` |
In that case my answer to "sapier> I wonder if it's worth adding scalable non freetype fonts" would be a definite NO |
12:08 |
Zeno` |
they'll almost certainly look like crap |
12:09 |
sapier |
for what reason? right now non scalable fonts are defacto same as freetype fonts |
12:09 |
sapier |
with one small difference |
12:09 |
sapier |
they're prerendered while freetype fonts are rendered otf prior beeing passed to irrlicht |
12:10 |
sapier |
and no they don't look like crap they look almost identical |
12:11 |
sapier |
the only difference is freetype will render any font sizes .. while non ft fonts will have to be there in some chosen intervals ... most likely the ones the irrlich font tool suggests |
12:11 |
|
Garmine joined #minetest-dev |
12:12 |
sapier |
but without scaling formspecs discussion is almost useless |
12:12 |
sapier |
only android port would benefit |
12:13 |
Zeno` |
If I build with freetype disabled though the fonts are terrible |
12:13 |
Zeno` |
why is that? Hinting or something going wrong? |
12:14 |
|
GhostDoge joined #minetest-dev |
12:14 |
Zeno` |
They don't look the same at all to me |
12:15 |
sapier |
because the font used for non freetype mode is crap ;-) |
12:15 |
Zeno` |
heh, maybe |
12:17 |
sapier |
https://github.com/minetest/minetest/pull/1561 you can try this one, to see fonts scaling set screen_dpi to a higher value. Yes menu will be broken I'm adressing this in another pull ... even more controversial as it fixes formspec positioning mechanism too |
12:18 |
|
DogePony joined #minetest-dev |
12:21 |
|
PenguinDad joined #minetest-dev |
12:30 |
|
Megaf joined #minetest-dev |
13:21 |
|
NakedFury joined #minetest-dev |
13:40 |
|
OldCoder joined #minetest-dev |
13:43 |
|
Jordach joined #minetest-dev |
13:48 |
|
asl joined #minetest-dev |
13:48 |
|
hmmmm joined #minetest-dev |
13:52 |
|
rubenwardy joined #minetest-dev |
14:01 |
|
casimir joined #minetest-dev |
14:10 |
|
NakedFury joined #minetest-dev |
14:36 |
|
ImQ009 joined #minetest-dev |
14:44 |
sapier |
https://github.com/minetest/minetest/pull/1565/files realbadangel_ please base your subtab thingy for settings on this one |
15:07 |
|
Calinou joined #minetest-dev |
15:30 |
|
AnotherBrick joined #minetest-dev |
15:36 |
|
proller joined #minetest-dev |
15:40 |
|
zat joined #minetest-dev |
15:50 |
|
twoelk joined #minetest-dev |
15:57 |
|
ImQ009 joined #minetest-dev |
16:03 |
|
^v joined #minetest-dev |
16:04 |
|
Hunterz joined #minetest-dev |
16:21 |
sfan5 |
this idea just came up in #minetest: http://sprunge.us/XMfU |
16:22 |
sfan5 |
and having opinions would be quite nice |
16:26 |
PilzAdam |
why abuse the serverlist for that? |
16:28 |
sfan5 |
how else do you tell people with old clients to update? |
16:30 |
PilzAdam |
a message box at startup would be better |
16:30 |
sfan5 |
how exactly to you think about implementing that into versions already released? |
16:31 |
sfan5 |
s/to/do/ |
16:31 |
Calinou |
more important would be server banning from master |
16:31 |
Calinou |
but you can add update notification too :) |
16:31 |
Calinou |
Debian will have to censor it out |
16:31 |
Calinou |
(idea: add minetest.conf setting for update check, to make it easy to remove by Debian and such) |
16:33 |
PilzAdam |
sfan5, it would obviously be for future outdated versions |
16:34 |
VanessaE |
PilzAdam: so, in other words...useless for the current situation. |
16:34 |
PilzAdam |
also there is actually nothing wrong with using 0.4.8, so "blocking" the serverlist with entries isn't good |
16:34 |
VanessaE |
and there is. |
16:34 |
VanessaE |
old clients can't use some modern features. |
16:35 |
VanessaE |
hell even your/my signs don't work on certain old clients |
16:35 |
PilzAdam |
thats only if old clients connect to new servers |
16:35 |
PilzAdam |
they should get a message from the server then |
16:35 |
VanessaE |
yeah, and? |
16:36 |
VanessaE |
how are you gonna get a message to the old client if it doesn't support any message-passing protocol? |
16:36 |
PilzAdam |
minetest.chat_send_player()? |
16:36 |
VanessaE |
server-side mods aren't allowed to detect client versions |
16:37 |
VanessaE |
unless this was changed recently, which I doubt. |
16:37 |
PilzAdam |
also doesn't the client get a warning anyway if connecting to a server with a different protocol version? |
16:38 |
VanessaE |
only if the client isn't somehow patched to work around that. |
16:38 |
VanessaE |
we're not talking protocol differences, we're talking about clients doing shit just plain wrongly that is otherwise theoretically "right" |
16:38 |
VanessaE |
i.e. you send a block to the client, it displays it upside down or something |
16:39 |
VanessaE |
s/block/block's textures/ |
16:40 |
PilzAdam |
add a sign "If you see this block upside down upgrade your Minetest version" to the spawn in your server ;-) |
16:40 |
VanessaE |
hard to make that work if the user can't read the sign :) |
16:41 |
VanessaE |
(that's a real example of such a failure - because the texture for the text is blacked-out due to some GPU/driver bug in iOS devices) |
16:42 |
PilzAdam |
btw, why are blocks displayed upside-down when old clients connect? |
16:42 |
|
Calinou joined #minetest-dev |
16:42 |
PilzAdam |
what broke it and why wasn't a compatibility layer added? |
16:47 |
VanessaE |
the upside down block was hypothetical |
16:47 |
VanessaE |
the sign one was real |
16:48 |
VanessaE |
the problem is these "old clients" are often tablets/phones running not Minetest but buildcrap |
16:48 |
VanessaE |
we can't ban them |
16:48 |
VanessaE |
we can't patch them |
16:48 |
VanessaE |
we can't kick them off |
16:48 |
VanessaE |
and we can't send server-->client messages reliably |
16:49 |
VanessaE |
but we CAN use the server list to inform users. |
16:49 |
VanessaE |
and there's little or nothing that the buildcrap guys can do to "protect" against that without totally breaking the server list. |
16:51 |
PilzAdam |
ah, so you want to do what the main reason is why mods are not allowed to get the client version |
16:51 |
VanessaE |
uh, no |
16:51 |
|
zat joined #minetest-dev |
16:52 |
VanessaE |
the main reason for mods not being given server/client version is, as I thought, to prevent general breakage or reliance on versioning. |
16:52 |
VanessaE |
this is an upgrade notice |
16:52 |
VanessaE |
big difference |
16:53 |
sfan5 |
<Calinou> more important would be server banning from master |
16:53 |
sfan5 |
we can already do tha |
16:53 |
sfan5 |
t |
16:56 |
|
hmmmmm joined #minetest-dev |
16:58 |
Calinou |
ah |
17:15 |
|
Krock joined #minetest-dev |
17:29 |
sapier |
imho no matter what we do (maybe except of autoupdating user clients to master) wouldn't help VanessaE as she can't stick to a stable version but always has to use bleeding edge master code ;-P |
17:30 |
sapier |
And for what I believe even if we did have a "stable" branch only merging bugfixes but no new features she wouldn't use it ... Would you VanessaE? |
17:31 |
VanessaE |
you never know :P |
17:32 |
Zefram_Fysh |
sapier: have you noticed a problem with Irrlicht tab controls, where the hotspots of the tabs don't match their visual extent? Irrlicht computes hotspots based on how the tabs would render using the font that's current when button is pressed, which doesn't necessarily match the font that was used for drawing |
17:33 |
sapier |
Zefram_Fysh: that could be a problem |
17:33 |
Zefram_Fysh |
I think it would arise with your formspec patch. it arises with my version, and it's just about the last thing standing in the way of me declaring my patch complete |
17:34 |
sfan5 |
sapier: telling users to update doesn't help? |
17:34 |
sapier |
well it doesn't happen for main menu right now as there the default font is used |
17:34 |
sapier |
but it could happen for tabs in game |
17:34 |
VanessaE |
sapier: the whole damn point is telling users to update if they're using a stable that's older than the current stable, THAT IS ALL. |
17:34 |
Zefram_Fysh |
the Irrlicht innards are godawful wrt font selection. different GUI element types have different rules for it |
17:34 |
VanessaE |
jesus christ, why is this so hard to grasp? |
17:34 |
sfan5 |
lol |
17:34 |
VanessaE |
and any proposal that involves changing the client WILL NOT WORK |
17:35 |
Zefram_Fysh |
for me it's happening on the main menu, because that's not using the default font |
17:35 |
sapier |
sfan5: I was talking about helping VanessaE ... to get this done we could write the text "update to latest master" hardcoded to menu ;-) |
17:35 |
VanessaE |
sapier: s/latest master/0.4.10-release/ |
17:36 |
sapier |
only until next nice feature in master making stable slightly less advanced then you'll complain about "those old outdated stable clients" |
17:36 |
VanessaE |
sapier: I may code for dev, but my servers try to stick to working with *stable* |
17:36 |
VanessaE |
but telling users it's olay to keep using 0.4.7? FUCK NO |
17:37 |
sfan5 |
sapier: all I propose is displaying a message to people with <= 0.4.8 |
17:37 |
sapier |
Zefram_Fysh: for what I see the only option is make mainmenu use the default font ;-) |
17:37 |
sapier |
sorry sfan5 I'm with pilzadam why abusing serverlist for things like that |
17:38 |
sfan5 |
tell me how to do it otherwise |
17:38 |
VanessaE |
sapier: in other words I don't give two shits if the CLIENT can run my mods, I only care if my servers can run them, and if the client can properly display what the server sends. that means using a -release client. and 0.4.10-release is more than new enough. |
17:38 |
sapier |
Why do it at all? |
17:38 |
Zefram_Fysh |
I guess I can contrive that, or I was also thinking about ways to make tab controls always use the default font regardless of context |
17:38 |
VanessaE |
sapier: but anything older than 0.4.9 doesn't even work with those signs, and you KNOW that! |
17:38 |
sfan5 |
sapier: because we can't be backwards compatible to every release |
17:38 |
VanessaE |
you know how much of a pain in the ass it is to deal with old clients |
17:38 |
sfan5 |
and the whole texture modifier stuff |
17:38 |
VanessaE |
how they drag server performance down |
17:38 |
VanessaE |
etc etc etf |
17:38 |
VanessaE |
etc* |
17:38 |
sapier |
Zefram_Fysh: that's crap you can't use small default font if all other menu fonts are scaled up |
17:38 |
Zefram_Fysh |
it's also possible to leave the form's font selected in the skin, but that affects things like chat that use it |
17:39 |
sapier |
that'd be one of those inconsistency things formspec already suffer from |
17:39 |
Zefram_Fysh |
to get consistently not-crap results we're going to have to fix Irrlicht, I think |
17:40 |
sapier |
so because you guys don't like 0.4.8 clients on YOUR servers we shall bug all 0.4.8 users which may even want to play on other servers running 0.4.8? |
17:40 |
sapier |
Zefram_Fysh: you're right ... go back in time and fix irrlicht 1.7 |
17:40 |
sfan5 |
if they want to play on 0.4.8 servers they use 0.4.8 for those and 0.4.10 for the othersw |
17:40 |
sfan5 |
-w |
17:41 |
sapier |
sfan5: and how do you think they'll find 0.4.8 servers if you break serverlist? |
17:41 |
sfan5 |
did you even read |
17:41 |
sfan5 |
I proposed adding a notice at the top |
17:41 |
sfan5 |
not replacing the servers |
17:41 |
sapier |
if you want to tell ppl about not joining add it in description it's shown on client tab |
17:42 |
sfan5 |
you don't want to understand it, do you? |
17:42 |
sapier |
this description is server specific |
17:42 |
sapier |
why bother all users because some servers want to tell them not to join? |
17:43 |
sfan5 |
some servers? |
17:43 |
sapier |
Zefram_Fysh: I was serious, you're right that this is a irrlicht bug but that doesn't help us as we won't tell ppl sorry but you need next version of irrlicht for about the next 2 years ;-) |
17:44 |
sfan5 |
sapier: I heard you volunteer to maintain compatibility code (in mods) for 0.4.1? |
17:44 |
sapier |
compatibility is mod owner resposibility ... noone forces you to do it |
17:44 |
Zefram_Fysh |
yeah. I'm still looking at workaround options. it may be possible to wrap the tab control class or something |
17:44 |
sfan5 |
are you serious? |
17:44 |
VanessaE |
MOD OWNER? |
17:45 |
VanessaE |
wtf? |
17:45 |
sapier |
owner/writer/developer |
17:45 |
sfan5 |
do you fucking expect any modder to support old crap |
17:45 |
VanessaE |
now I know you're deliberately misunderstanding. |
17:45 |
sfan5 |
do you? |
17:45 |
VanessaE |
why should continue to cater to 0.4.4? |
17:45 |
VanessaE |
or even 0.4.9? |
17:45 |
sapier |
No I don't it's mod writers decision if she/he wants to be compatible or not this ain't a core matter |
17:46 |
sfan5 |
so everyone should just set a higher minimum protocol version? |
17:46 |
sapier |
wtf |
17:46 |
VanessaE |
server list reads: Please update, your / client is outdated / 0.4.10 is available from / www.minetest.net / <some server here> / <another server here> / <another server> / etc etc etc |
17:46 |
VanessaE |
that's ALL |
17:46 |
VanessaE |
jesus fuck |
17:47 |
sapier |
Just open up a message box on join "Minimum required client version is ..." |
17:47 |
VanessaE |
sapier: that means changing the client. |
17:47 |
VanessaE |
you can't reliably detect client versions from a mod. |
17:47 |
sapier |
no it doesn't |
17:47 |
sapier |
you don't |
17:47 |
VanessaE |
then how do you propose to detect if the client is outdated? |
17:48 |
Zefram_Fysh |
think sapier is proposing to show the message box to all clients, requiring the actual player to do the version comparison |
17:48 |
sapier |
you don't have to, just post that message on initial connect, save whom has been told about and clear that list on each new version of your server |
17:48 |
proller |
also lets start show ads in ingame serverlist |
17:48 |
VanessaE |
that's STUPID |
17:48 |
VanessaE |
shut up, proller |
17:48 |
sfan5 |
what |
17:48 |
proller |
sell viagra or drugs |
17:48 |
sapier |
I'm not proud to tell it but proller is right this time |
17:48 |
sfan5 |
do you expect people to know which version they use? |
17:48 |
VanessaE |
this is not a slippery slope argument here |
17:49 |
sfan5 |
what about the buildcrap people? |
17:49 |
sfan5 |
and do you expect people to care if it "just works" |
17:49 |
sapier |
I don't care about the buildcrap ppl as they're not using minetest, I can't patch their bugs away anyway |
17:49 |
sfan5 |
no |
17:49 |
VanessaE |
sapier: you can't tell every user to update. that's just plain stupid |
17:49 |
sfan5 |
they're not using minetest |
17:49 |
sfan5 |
ofc not |
17:49 |
VanessaE |
and you can't patch existing clients |
17:49 |
VanessaE |
that's ludicrous and impossible |
17:50 |
VanessaE |
you have to do this either from the minetest server, which is impossible because we can't detect client versions, or from the master server list. |
17:50 |
VanessaE |
s/we/mods/ |
17:50 |
sapier |
VanessaE: nothing is impossible I gues we could even patch current clients if we abused some security flaws in minetest |
17:50 |
VanessaE |
what? |
17:50 |
sfan5 |
what |
17:51 |
VanessaE |
YOU, talk about abusing a security flaw?! |
17:51 |
VanessaE |
are you insane? |
17:51 |
sfan5 |
^ |
17:51 |
sapier |
(19:49:53) VanessaE: and you can't patch existing clients |
17:51 |
sfan5 |
and how do you reliably want to patch hundreds of different compiled versions by abusing e.g. a buffer overflow? |
17:51 |
sfan5 |
pls tell me |
17:51 |
sapier |
that's wrong ... we can but we wont do it that way |
17:51 |
sfan5 |
(was probably mostly a joke anyway) |
17:52 |
sfan5 |
and which security flaw are you talking about? |
17:52 |
VanessaE |
you can't patch that which you don't have suitable code to patch |
17:52 |
VanessaE |
you'd be better off inserting a patch guaranteed to crash the client with a "you're outdated, go fuck off" error. |
17:52 |
sapier |
most easy way to patch minetest most likely would be make server send a model with prefixed minetst binary path |
17:53 |
sapier |
hmm no might not work |
17:53 |
VanessaE |
nice.. go ahead and put that in the public log. |
17:53 |
sfan5 |
and how would that patch things? |
17:53 |
sapier |
it'll be a little more complicated |
17:53 |
sfan5 |
that isn't even a secrity bug |
17:53 |
sfan5 |
irrlicht will say: nope, not a .x or .b3d, can't load that |
17:53 |
sfan5 |
security* |
17:53 |
proller |
sapier, start code binary update system now!! |
17:53 |
sapier |
overwriting minetest.exe by a model sent from server wouldn't be a security bug? ;-) |
17:53 |
sfan5 |
yes |
17:53 |
sfan5 |
because everyone uses windows |
17:54 |
sfan5 |
and what? |
17:54 |
sfan5 |
how do you plan to write an arbritary file? |
17:54 |
proller |
now biggest issue of minetest is lack of binary updates!! |
17:54 |
sapier |
lol sfan5 irrlicht's file checks are a bad joke I'm quite sure I could make irrlicht execute almost any code by giving it a broken file |
17:55 |
sfan5 |
they go to client/cache/media/<hash> not client/cache/media/<path> |
17:55 |
sfan5 |
sapier: yes, because ASLR and DEP are totally trivial to defeat |
17:56 |
sapier |
to be honest for someone really knowing what to do they are |
17:56 |
sfan5 |
*sigh* |
17:56 |
sapier |
or having the right toolkit |
17:56 |
sfan5 |
a toolkit doesn't help defeat ASLR |
17:56 |
sapier |
yet back to our original topic abusing server list to provide information required by (some) server owners |
17:56 |
sfan5 |
hmm |
17:57 |
sapier |
No ... you didn't give me any reason to change my mind about that one |
17:57 |
sfan5 |
maybe we should support 0.3 clients to 0.4 servers? |
17:57 |
sfan5 |
that matches your principle of total backwards-compat. even if that is complete shit |
17:57 |
sapier |
nope because 0.3 is not 0.4 and 0.5 will not be 0.4 too |
17:57 |
* VanessaE |
triple-facepalms |
17:58 |
sapier |
by now we handle things this way ... if this is right or not is not subject of this debate |
17:58 |
PenguinDad |
sapier: and 0.4.7 is not 0.4.10 |
17:58 |
VanessaE |
sapier: s/some server owners/all server owners/ |
17:58 |
sapier |
PenguinDad: true but by now compatibility break is supposed to cause 0.X.0 version number to change |
17:58 |
VanessaE |
ALL server owners will have this problem eventually. |
17:59 |
sfan5 |
<sapier> PenguinDad: true but by now compatibility break is supposed to cause 0.X.0 version number to change |
17:59 |
sfan5 |
[citation needed] |
17:59 |
VanessaE |
and frankly, we're getting tired of having to tell our users constantly to upgrade their busted, outdated, obsolete clients. |
17:59 |
sapier |
see our issue list there are various things marked as 0.5 because of compatibility break |
17:59 |
sfan5 |
hm |
17:59 |
sfan5 |
we shouldn't add any features |
18:00 |
sfan5 |
they break compat. too |
18:00 |
sapier |
btw each new version has new nice features that can't be used with older clients we could just add a hardcoded text "update to latest client" |
18:00 |
sfan5 |
hardcoded text where? |
18:01 |
VanessaE |
sapier: upgrade to LATEST RELEASE |
18:01 |
sapier |
right on top of mainmenu maybe |
18:01 |
VanessaE |
jesus christ in a handbasket |
18:01 |
sfan5 |
and how would that help people with 0.4.8? |
18:01 |
VanessaE |
sapier: and how would existing clients see that? |
18:01 |
sapier |
why do you wanna make 0.4.8 ppl to update? |
18:01 |
VanessaE |
it HAS to be done with the minetest server or the master server list in order to reach all old clients |
18:01 |
VanessaE |
because old clients are busted with some of the most basic crap |
18:01 |
VanessaE |
and you can't fix them |
18:01 |
sfan5 |
sapier: because minetest is not 100% backwards-compatible?? |
18:02 |
sapier |
minetest isbackward compatible ... your mods aren't |
18:02 |
sfan5 |
no |
18:02 |
sfan5 |
minetest is not backwards-compatible |
18:02 |
sfan5 |
every single addition to formspecs or texture modifiers are not backwards-compat. |
18:02 |
sapier |
I can connect to latest server with 0.4.1 client and do all the basic stuff |
18:02 |
sfan5 |
you can't blame mods to use them |
18:02 |
sfan5 |
basic stuff? |
18:02 |
sfan5 |
lol |
18:02 |
proller |
basic lag |
18:03 |
sfan5 |
you say we should reduce minetests function to basic stuff? |
18:03 |
sapier |
if you don't like it this way we can just make server check client version and kick all old clients as this will be the only way to enforce compatibility |
18:03 |
sfan5 |
wat |
18:04 |
sfan5 |
WAT |
18:04 |
VanessaE |
sapier: I repeat, I code for latest dev ON THE SERVER, but I try to make sure my code works for LATEST RELEASE ON THE CLIENT |
18:04 |
sfan5 |
I don't want to enforce compat. |
18:04 |
VanessaE |
what part of what don't you get? |
18:04 |
sapier |
rigth now we did always try to add things in a way old clients still can do what they could do before |
18:04 |
VanessaE |
in other words I don't give two shits if the client is newer than latest release usually. |
18:04 |
VanessaE |
I only care if the server is. |
18:04 |
sfan5 |
sapier: then you need to remove all of your formspec additionas |
18:04 |
VanessaE |
only if there's some major feature that breaks things, as you well know. |
18:04 |
sfan5 |
additions* |
18:05 |
sapier |
sfan5: noone forces a server owner to use them? running a 0.4.10 server with old mods will result in 0.4.1 client to have ALL the features provided by server |
18:05 |
sfan5 |
aswell as broken formspecs |
18:06 |
sapier |
for sure not as those old mods wont send the new style formspecs |
18:06 |
VanessaE |
sapier: so...what you're saying is server owners shouldn't bother with new features at all? |
18:06 |
sfan5 |
please tell me someone who uses 0.4.1 mods on a 0.4.10 server? |
18:06 |
sfan5 |
s/?// |
18:07 |
sfan5 |
"<someone> have a choice" is the worst excuse |
18:07 |
sapier |
sfan5: I don't care what you believe to be "most common usecase" ... for me it's enough someone could do it that way |
18:07 |
sfan5 |
WAT |
18:08 |
VanessaE |
sapier: look at the master list. |
18:08 |
VanessaE |
now. |
18:08 |
sapier |
and using those old mods is supposed to work perfectly fine |
18:08 |
VanessaE |
right now. this instant. |
18:08 |
sfan5 |
"someone could possibly use 0.4.1 mods with 0.4.10 so we don't need to tell people to update! lololololol" |
18:08 |
VanessaE |
what is the oldest server version you see there? |
18:08 |
VanessaE |
and what is the most common version? |
18:08 |
sapier |
what exactly is this supposed to tell me except of some temporary snapshot? |
18:08 |
VanessaE |
answer: 0.4.9, and 0.4.10, respectively. |
18:08 |
VanessaE |
it's called statistics. |
18:09 |
sfan5 |
"temporary snapshot" |
18:09 |
sfan5 |
what |
18:09 |
VanessaE |
no matter how often you look at this page, you'll get similar results. |
18:09 |
sfan5 |
it's not like half of the servers might migrate to 0.4.1 mods next day |
18:09 |
sapier |
so redcrab did update to 0.4.10 now? |
18:09 |
VanessaE |
is redcrab on this list? no. |
18:09 |
VanessaE |
we don't care what he runs |
18:09 |
sfan5 |
oh |
18:09 |
VanessaE |
he can't even bother to reply to his emails/forum posts anymore |
18:09 |
sfan5 |
another great thing |
18:09 |
sapier |
ok if you don't care why should I care |
18:09 |
VanessaE |
because G*d damn it he runs 0.4.4 |
18:09 |
sfan5 |
"someone might be running 0.4.1 in his private network composed of 1 person, we need to support it" |
18:10 |
VanessaE |
do you even realize how outdated that is? |
18:10 |
VanessaE |
that is to minetest what kernel 2.2 is to Linux |
18:10 |
sapier |
so why do we even discuss about compatibility if you drop it as soon as it fits your needs? |
18:11 |
VanessaE |
because there has to be a threshold beyond which we don't care? |
18:11 |
sfan5 |
Minetest has basic backwards-compat. but that doesn't mean we shouldn't tell people not to update to the latest version if they use an outdated one |
18:11 |
VanessaE |
do you care if MOBF still works with 0.4.1? |
18:11 |
sfan5 |
^ |
18:11 |
sapier |
then make us show this in version numbers and we're done |
18:11 |
sfan5 |
I still need citation that the x in 0.x.y marks compatibility |
18:12 |
VanessaE |
sfan5: only based on Minetest history, I think. |
18:12 |
sapier |
VanessaE: yes I do provide old version of mob for those using old servers |
18:12 |
VanessaE |
0.3.x isn't compatible with 0.4.x, and 0.5.x is expected to break a lot of stuff as well |
18:12 |
sfan5 |
sapier: you said something different |
18:12 |
VanessaE |
sapier: no, I mean the current code. |
18:12 |
VanessaE |
what's at git HEAD of your repo |
18:12 |
sfan5 |
sapier: you said you expect basic stuff to work with 0.4.1 cleient <-> 0.4.10 servers |
18:12 |
sfan5 |
then that needs to apply to mobf too |
18:12 |
sapier |
no because I tell them what minimum version to use |
18:12 |
VanessaE |
there. |
18:13 |
VanessaE |
you said it. |
18:13 |
sapier |
but I don't force anyone |
18:13 |
VanessaE |
"minimum verson" |
18:13 |
sfan5 |
wat |
18:13 |
sapier |
and I don't add something to mobf preventing usage |
18:13 |
VanessaE |
"minimum version" ** == "I don't care if this works with <minimum version - 1> |
18:13 |
sfan5 |
^ |
18:13 |
VanessaE |
and we're not proposing doing this with the server list either. |
18:13 |
VanessaE |
there would be messages there, but the list will still work |
18:14 |
sapier |
you're mixing up things you want us to force add something to serverlist which is not related to any version at all |
18:14 |
VanessaE |
all of the servers will still be in the list! |
18:14 |
sfan5 |
what |
18:14 |
VanessaE |
there will just be a header above them that the user can see |
18:14 |
VanessaE |
that's all |
18:14 |
sfan5 |
not related to any version? |
18:14 |
VanessaE |
a fake server or three in the list that is enough to display a message |
18:14 |
sapier |
no matter what client someone will use no matter what server he's gonna try to connect he'll have that crapy message in server list |
18:14 |
VanessaE |
um, the list is there prior to connecting to a server, derp |
18:14 |
sapier |
just because you don't want to make your server tell him on connect |
18:14 |
sfan5 |
1) why is that message crappy? 2) Not if they use an up-to-date verion |
18:15 |
sfan5 |
version* |
18:15 |
VanessaE |
update client --> no more message |
18:15 |
sapier |
because it's a server list and not a "some message for all users" box |
18:15 |
sfan5 |
how do you plan to inform users _in the main menu_ in 0.41? |
18:15 |
sfan5 |
0.4.1* |
18:16 |
sfan5 |
(w/o using the server list) |
18:16 |
sapier |
did anyone of you even test how clients would react to that message? |
18:16 |
sfan5 |
react? |
18:16 |
sfan5 |
what message? |
18:16 |
sapier |
if you abuse server list? |
18:16 |
VanessaE |
wat |
18:16 |
VanessaE |
it's just servers in the list |
18:16 |
sfan5 |
the client reacts by executing some code and displaying it |
18:17 |
sapier |
you add invalid data in there ... if unexpectedly someone added a check there or did some evaluation in worst case you cause a crash |
18:17 |
sfan5 |
uh |
18:17 |
sapier |
did you check it or not? |
18:17 |
VanessaE |
three or four server entries at the top of the list sent to the client that when displayed spell out an "upgrade recommended" notice in the list |
18:17 |
VanessaE |
invlaid data wat? |
18:17 |
VanessaE |
invalid* |
18:17 |
sfan5 |
invalid data != fake data |
18:18 |
sfan5 |
you mixed something |
18:18 |
VanessaE |
using the servers' descriptions is not invalid |
18:18 |
sfan5 |
and someone adding a check.. uh |
18:18 |
sfan5 |
maybe the dev team knows about this |
18:18 |
sapier |
did anyone of you even test it? |
18:18 |
VanessaE |
as long as the data exactly matches the specification the clients expect, then it's not invalid |
18:18 |
sfan5 |
why would we need to? |
18:18 |
VanessaE |
how can we test what you and PilzAdam vetoed? |
18:18 |
sfan5 |
why do we even need to test this? |
18:19 |
sapier |
serverlist is configurable you can make it download anything |
18:19 |
VanessaE |
sapier: so you're saying that every server that ever joins the list requires every client to be tested? |
18:19 |
sapier |
sfan5: because you suggest to abuse it and claim old clients wont be harmed |
18:19 |
VanessaE |
sapier: to clients, this would look like four new servers have connected. THAT IS ALL. |
18:19 |
sfan5 |
sapier: adding fake data != abuse |
18:19 |
sfan5 |
and if you say it doesn't work, how about proving that? |
18:20 |
sapier |
sfan5: in worst case that change might cause old clients to crash immediatly (i don't expect it but it is possible) |
18:20 |
sfan5 |
yes |
18:20 |
sfan5 |
if they crash on well-formed data |
18:20 |
sfan5 |
thats not our fault |
18:20 |
sapier |
YOU want this abuse so it's up to you to proove it's not wrong |
18:20 |
sfan5 |
no |
18:20 |
VanessaE |
prove it's not wrong? |
18:20 |
VanessaE |
er... |
18:20 |
sapier |
what's ip address of "Update to" ? |
18:20 |
|
luizrpgluiz joined #minetest-dev |
18:20 |
sfan5 |
sapier: 0.0.0.0 / 127.0.0.1 |
18:20 |
|
ImQ009 joined #minetest-dev |
18:21 |
luizrpgluiz |
hi |
18:21 |
sfan5 |
if the client crashes on seeing 127.0.0.1 in the serverlist |
18:21 |
sfan5 |
that would be just plain stupid |
18:21 |
sapier |
proove it |
18:21 |
sfan5 |
no, you prove it |
18:21 |
sfan5 |
seriously |
18:21 |
sfan5 |
how the fuck do you thing the client is magically going to crash if it sees 4 new servers on the list? |
18:21 |
sfan5 |
tellme |
18:22 |
sapier |
I will not continue this discussion unless someone provides new information and better reason to do it till that I'll not agree as PilzAdam didn't |
18:22 |
sfan5 |
oh |
18:22 |
sfan5 |
you refuse to provide arguments |
18:22 |
sfan5 |
can I see this as deafeat? |
18:22 |
sfan5 |
defeat? |
18:23 |
VanessaE |
sapier: you are the one asserting it will break clients. |
18:23 |
VanessaE |
sfan5: implement it. sapier: prove it doesn't work. |
18:23 |
sapier |
I provided all my arguments and did honor yours, result beeing your's not changing my mind |
18:23 |
VanessaE |
basic science. |
18:23 |
sapier |
ok noone did proove my recent patches don't work so I'm gonna merge them |
18:23 |
VanessaE |
"Extraordinary claims require extraordinary evidence" |
18:23 |
sfan5 |
sapier: please prove that the client will crash from seeing 4 new ordinary servers |
18:23 |
sfan5 |
sapier: thats not how it owrks |
18:23 |
sfan5 |
works* |
18:24 |
sapier |
I don't have to provide anything to not agree to abusing server list as messagebox |
18:24 |
sfan5 |
you do |
18:24 |
VanessaE |
sfan5: the REAL trick would be inserting objects into the users' "favorites" list ';) |
18:25 |
* VanessaE |
hides |
18:25 |
sfan5 |
you have to prove that the client will crash on sight of ordinary servers |
18:25 |
sfan5 |
VanessaE: lol |
18:25 |
VanessaE |
sapier: you made the assertion. science requires YOU to prove your assertion. |
18:25 |
sapier |
what does client crash have to do with you abusing server list? it's only one possible no go |
18:25 |
sfan5 |
uh |
18:25 |
sfan5 |
you brough the argument up |
18:25 |
VanessaE |
wait, now the clients won't crash? |
18:26 |
sfan5 |
why are you asking us how that has something to do with each other? |
18:26 |
sfan5 |
<sapier> you add invalid data in there ... if unexpectedly someone added a check there or did some evaluation in worst case you cause a crash |
18:26 |
sapier |
I claim this might cause a crash as of science this theory is correct until you prove it to be false |
18:26 |
sfan5 |
lolno |
18:26 |
VanessaE |
kahrl: smartass ;) |
18:26 |
sfan5 |
it is incorrect until you prove it |
18:26 |
VanessaE |
sapier: ^^^^ did that quit message kill your IRC client? :P |
18:26 |
sfan5 |
and a theory is not correct |
18:27 |
sfan5 |
a theory is a theory |
18:27 |
VanessaE |
sapier: that's not how science works |
18:27 |
VanessaE |
you form a hypothesis and YOU test it |
18:27 |
sfan5 |
a theory becomes a <fill me in, VanessaE> when it's true |
18:27 |
sfan5 |
oh |
18:27 |
sfan5 |
"fact" |
18:27 |
sfan5 |
maybe |
18:27 |
VanessaE |
perhaps :) |
18:28 |
luizrpgluiz |
excuse me, sorry I dropped in a parachute, but this discussion leads to the minetest or to the IRC server? |
18:28 |
sapier |
I still won't agree no matter how often you repeat your wrong arguments |
18:28 |
VanessaE |
hypothesis: clients will crash. theory: bad data causes function X to return Y which causes function Z to segfault. <test test test test test> Unable to confirm hypothesis. theory discarded. |
18:28 |
VanessaE |
THAT is basic science. |
18:28 |
sfan5 |
wrong arguments? |
18:28 |
sfan5 |
which arguments are wrong and why? |
18:28 |
sfan5 |
can you indicate that? |
18:29 |
sapier |
"All clients have to update to use servers" <<< that's wrong |
18:29 |
sfan5 |
who said they have to? |
18:29 |
sfan5 |
We only say that they get a notice |
18:29 |
VanessaE |
no one said they had to update to use the server list. |
18:29 |
sapier |
if this isn't true then why damn abuse the serverlist? |
18:29 |
VanessaE |
SCROLL DOWN A BIT |
18:29 |
sfan5 |
nobody prevents them from using the server list |
18:31 |
sapier |
You don't even provide a solution for future versions but only a hacky workaround for old ones |
18:31 |
VanessaE |
[08-19 13:50] <VanessaE> server list reads: Please update, your / client is outdated / 0.4.10 is available from / www.minetest.net / ----- SCROLL DOWN TO HERE -------- <some server here> / <another server here> / <another server> / etc etc etc |
18:31 |
sapier |
VanessaE: and this is gonna be all you see on some android clients ... even with latest client ... great picture |
18:31 |
VanessaE |
fAIL |
18:31 |
VanessaE |
with latest client: no messages |
18:32 |
VanessaE |
only real servers. |
18:32 |
sapier |
if you add it to serverlist everyone will see it |
18:32 |
VanessaE |
where "latest client" = Buildcraft 2 or your Android client (both are 0.4.10) |
18:32 |
VanessaE |
NOP! |
18:32 |
sfan5 |
heard of parsing user agents? |
18:32 |
VanessaE |
NO! |
18:32 |
VanessaE |
only OLD CLIENTS WILL SEE THE MESSAGES! |
18:32 |
VanessaE |
jesus fuck |
18:33 |
sapier |
Still why abuse serverlist |
18:33 |
sfan5 |
because you can't get it into the mainmenu of the older clients any other way? |
18:33 |
sapier |
provide a real solution first and then we can talk about hacky workarounds |
18:33 |
sfan5 |
that is a solution |
18:33 |
sfan5 |
but only for old clients |
18:33 |
sfan5 |
we can worry about a solution for new clients later |
18:34 |
sfan5 |
it's still time until 0.4.12 |
18:34 |
sapier |
If you believe this to be a solution why don't you get a majority of core devs? |
18:34 |
sfan5 |
not everyone has commented |
18:34 |
sfan5 |
and maybe because you do not understand it all |
18:34 |
sapier |
then make them comment and get a majority |
18:34 |
sfan5 |
make them comment, what? |
18:35 |
sfan5 |
please tell me how to make people comment? |
18:35 |
sfan5 |
s/?/ |
18:35 |
sfan5 |
/ |
18:35 |
sapier |
You'll not get my agreement get your ok from others |
18:35 |
sfan5 |
soo.. is "you didn't get agreement from others" an ok argument? |
18:36 |
sfan5 |
if so, please remove all of your android stuff from the repo |
18:36 |
sfan5 |
you didn't get agreement from everyone |
18:36 |
sfan5 |
see the problem with your "argument"? |
18:36 |
sapier |
right now you've got 2:2 |
18:37 |
sfan5 |
VanessaE is not a core dev |
18:37 |
sapier |
2 explicit disagreements against 2 agreements |
18:37 |
sfan5 |
1:2 |
18:37 |
sapier |
even wors |
18:37 |
sfan5 |
lolwat |
18:37 |
|
luizrpgluiz left #minetest-dev |
18:37 |
sapier |
still I'd consider vanessaE close to core dev so I'd accept her opinion |
18:37 |
|
NakedFury joined #minetest-dev |
18:38 |
sfan5 |
anyway |
18:38 |
sfan5 |
what (real) arguments are left against it? |
18:38 |
|
Miner_48er joined #minetest-dev |
18:38 |
sapier |
Imho abusing the serverlist as message box is wrong ... especially if you don't provide a solution for future versios |
18:38 |
sapier |
versions |
18:39 |
sfan5 |
<sfan5> we can worry about a solution for new clients later |
18:39 |
sfan5 |
<sfan5> it's still time until 0.4.12 |
18:39 |
sfan5 |
the biggest problem for servers owners now is that people are using very outdated versions |
18:39 |
sapier |
sfan5: I don't believe you to implement that solution ... quite simple ... not for 0.4.11 not for 10.0 |
18:39 |
sfan5 |
s/for server owners/ |
18:39 |
sfan5 |
/ |
18:39 |
sapier |
I believe once you've got that hack you'll never look at a real solution again |
18:39 |
sfan5 |
sapier: thats not an argument |
18:40 |
sapier |
you proved this with color table in past |
18:40 |
sfan5 |
color table |
18:40 |
sfan5 |
lol |
18:40 |
sapier |
I don't forget things like that |
18:40 |
sfan5 |
why do we need a color table? |
18:40 |
sfan5 |
(need, not want) |
18:40 |
sapier |
who needs that message? .. (20:40:29) sfan5: (need, not want) |
18:41 |
sfan5 |
thats not an argument |
18:41 |
sfan5 |
so you're out of arguments? |
18:41 |
sfan5 |
guess we don't need a color table |
18:41 |
sapier |
oh once I tell it it's not an argument but if you use it it is ... sorry with this rules I end this discussion now |
18:42 |
sfan5 |
what is not an argument? |
18:42 |
sfan5 |
mhm |
18:42 |
sfan5 |
anyway |
18:42 |
sfan5 |
this |
18:42 |
sfan5 |
this |
18:43 |
sfan5 |
is exactly why we never get anything done |
18:43 |
sapier |
provide a solution then we can talk about a hack |
18:43 |
sfan5 |
thats a solution |
18:43 |
VanessaE |
any solution would require a protocol change...... |
18:43 |
sfan5 |
a limited solution |
18:43 |
sfan5 |
not a hack |
18:43 |
VanessaE |
a proper solution that is. |
18:44 |
VanessaE |
or not. |
18:44 |
sapier |
VanessaE: Simplest way for a real solution would just download a "latest news" file and show it |
18:44 |
VanessaE |
it would at least require clients to check the minetest.net website for updates anyway |
18:45 |
Calinou |
we could have in-game news display too |
18:45 |
Calinou |
if we have version check, that's possible |
18:45 |
Calinou |
this is important for keeping community around |
18:45 |
sfan5 |
PilzAdam: have you been watching the discussion? |
18:45 |
sapier |
I don't think anyone sane would've followed that discussion ;-) |
18:46 |
PilzAdam |
only the "but you have to prove!" part |
18:46 |
PilzAdam |
quite amusing |
18:46 |
VanessaE |
sapier: then 90% of this channel would follow :) |
18:46 |
sapier |
PilzAdam: only because of not beeing part of it ;-P |
18:46 |
sfan5 |
PilzAdam: not changed your mind? |
18:47 |
PilzAdam |
I still don't like making the serverlist less usable by "blocking" it |
18:47 |
|
twoelk joined #minetest-dev |
18:47 |
VanessaE |
PilzAdam: not blocking. |
18:47 |
VanessaE |
PilzAdam: amending. |
18:47 |
VanessaE |
the rest of the list is still there. just scroll down. |
18:47 |
sapier |
nice euphemism |
18:48 |
VanessaE |
hell the top couple of real entries will still be visible on most devices won't they? |
18:48 |
sfan5 |
PilzAdam: unless you use outdated version it will not affect you |
18:49 |
VanessaE |
buildcrap looks to have about 5 entries' worth of space in its list, from checking screenshots on the google |
18:49 |
VanessaE |
in the window I mean |
18:50 |
PilzAdam |
sfan5, I am aware of that |
18:51 |
|
khonkhortisan joined #minetest-dev |
18:52 |
sapier |
https://github.com/minetest/minetest/pull/1557 suggestions? |
18:53 |
sapier |
sfan5: all of your issues fixed in there? |
18:54 |
PilzAdam |
core.is_yes(core.setting_get("mod_profiling")) <- isnt there setting_getbool()? |
18:54 |
sfan5 |
looking at it right now |
18:54 |
sfan5 |
hm |
18:54 |
sfan5 |
yea |
18:54 |
sfan5 |
there is a setting_getbool |
18:54 |
sfan5 |
and that should be used |
18:55 |
sapier |
nice when was that one added? |
18:55 |
sfan5 |
hm |
18:55 |
PilzAdam |
its there since... ever? |
18:55 |
sfan5 |
yeah |
18:55 |
sapier |
hmm but no set_bool |
18:56 |
|
AnotherBrick joined #minetest-dev |
18:56 |
sapier |
guess whoever did add this never heared about api symmetry |
18:56 |
PilzAdam |
minetest.get_time_us() ^ get time in us <- at least spell it "microseconds" in the description |
18:56 |
PilzAdam |
some people might think you can get the time in the united states |
18:57 |
sapier |
ok |
18:57 |
PilzAdam |
also can you filter the output by mod? |
18:57 |
PilzAdam |
e.g. /save_mod_profile mobf |
18:58 |
sapier |
not yet |
18:59 |
sapier |
but should be a minor change |
18:59 |
sapier |
I'll add that feature |
18:59 |
PilzAdam |
yea, can be done later |
18:59 |
sapier |
should be only a couple of lines |
18:59 |
PilzAdam |
what does "min %" mean? percentage of what? |
18:59 |
sapier |
of a server step |
18:59 |
sapier |
I'll improve doc |
19:00 |
sapier |
-doc + output |
19:00 |
PilzAdam |
also it's "type" in english, not "typ" |
19:01 |
PilzAdam |
everything else seems good |
19:03 |
|
rubenwardy left #minetest-dev |
19:12 |
sapier |
you guys know that get_bool is only available for other settings file don't you? |
19:13 |
sapier |
not for our main settings file ;-) |
19:16 |
PilzAdam |
hm? |
19:17 |
sapier |
core.setting_get() works, but there ain't a core.setting_get_bool() ... or is there a way to get the object of our internal settings? |
19:17 |
PilzAdam |
its setting_getbool() |
19:17 |
PilzAdam |
without the second _ |
19:18 |
PilzAdam |
and there is also a minetest.setting_setbool() |
19:18 |
sapier |
crap who did design lua api? |
19:18 |
sapier |
I don't use the outdated "minetest" prefix in new code |
19:18 |
PilzAdam |
yea, I was copying from lua_api.txt |
19:18 |
sapier |
we've got get_pos getpos getbool get_bool ... |
19:19 |
sapier |
all with "depends where you are right now" |
19:21 |
sapier |
PilzAdam we need to fix lua_api.txt .. at least I don't find things in there any more ... even if I know it's in there |
19:22 |
sapier |
you can't expect some newbie to use it if not even ourselfs can really use it any longer ;-) |
19:23 |
PilzAdam |
you can split it into several files, but please keep the current version too |
19:23 |
VanessaE |
don't split it, that'll just make searching it even harder. |
19:23 |
sapier |
I don't think splitting alone would help |
19:27 |
VanessaE |
if you can't find something in the API, either your search terms are bad (not very likely), or the API is worded badly. |
19:27 |
VanessaE |
I would guess quite strongly the latter. |
19:27 |
VanessaE |
splitting the API will solve neither of those problems. |
19:27 |
VanessaE |
and only make the result of both problems worse. |
19:28 |
VanessaE |
because then you have to try to remember "wait, was mintest.foo() in lua_api_visuals.txt, or was it in lua_api_graphics.txt, or...?" |
19:28 |
sapier |
yet the doc is a open issue to me the current state is ... well ... not good |
19:28 |
VanessaE |
I agree |
19:28 |
VanessaE |
and you know I've had my opinions of it. |
19:28 |
VanessaE |
the grammar sucks, it's badly organized, it lacks good examples, ... |
19:28 |
VanessaE |
but when I've complained, people point at that Wiki site instead |
19:28 |
VanessaE |
as if that's particularly good substitute for a searchable txt file |
19:29 |
sapier |
I hate that damn wiki ... maybe because of that silly kitten thing ... but only because of it |
19:29 |
sapier |
+not |
19:29 |
VanessaE |
the wiki has too many circular references. |
19:30 |
VanessaE |
I think I'm clicking on a link for more info, all I get is the same thing I'd find in lua_api.txt, and links from the page I ended up on take me back to where I was already, usually. |
19:31 |
PilzAdam |
VanessaE, examples shouldn't be in lua_api.txt |
19:32 |
PilzAdam |
it only bloats the file |
19:32 |
VanessaE |
PilzAdam: there are many places in the lua_api.txt that don't even explain what the *output* of a given function is |
19:32 |
VanessaE |
and no, I can't list them now |
19:32 |
VanessaE |
I just run into them every so often |
19:33 |
sapier |
can we add a rule "you may not mention coding style issues in lines not changed in a follow up review"? |
19:33 |
VanessaE |
and yes, there should be examples, even if an example is one line. |
19:33 |
PilzAdam |
what has this to do with examples? |
19:33 |
VanessaE |
PilzAdam: because an example is directly related to the function's output? table in -> table out, two sets of coords in --> single item out? |
19:34 |
Zefram_Fysh |
examples can be a useful way of explaining an API, and can to some extent make up for poor expository text. but I'd rather have good exposition to start with |
19:41 |
|
Eater4 joined #minetest-dev |
19:49 |
sapier |
sfan5: suggestions how to do a better initialization? |
20:00 |
sapier |
https://github.com/minetest/minetest/pull/1557 pushing in a few minutes |
20:04 |
Zefram_Fysh |
cool! |
20:12 |
|
vifino joined #minetest-dev |
20:15 |
|
proller joined #minetest-dev |
20:16 |
sapier |
last chance to vetoß |
20:16 |
sapier |
-ß+? |
20:16 |
casimir |
Tested is just now. No problems. |
20:17 |
casimir |
And I realized how consuming the leavedecay abm is. |
20:17 |
sfan5 |
sapier: read my comments |
20:18 |
sapier |
sfan5: I already fixed them if you didn't add some the last 10s |
20:18 |
sapier |
btw I just merged it |
20:18 |
sfan5 |
ik |
20:18 |
sfan5 |
and that wasn't in the last seconds |
20:18 |
sfan5 |
and you can rewrite history for 10 minutes |
20:19 |
sapier |
which one of your comments was not honored? |
20:19 |
sapier |
ah those you wrote while I was preparing for merge |
20:20 |
sapier |
you do keep som issues back till I fixed the other ones on purpose don't you? |
20:21 |
sapier |
ok rewrote history done now? |
20:24 |
sapier |
https://github.com/minetest/minetest/pull/640 any chance to get this in if I rebase it? |
20:27 |
PilzAdam |
sapier, shouldn't it run from the top to find the actual surface instead of caves? |
20:27 |
sapier |
well if there's a tree you'll find a tree |
20:27 |
sapier |
so either way it's wrong some time |
20:28 |
PilzAdam |
checking for a tree is easier than checking for a cave (in a mod) |
20:28 |
PilzAdam |
and moving additional 5 - 6 nodes should be fast in mods |
20:28 |
sapier |
well I can change it ... as I don't really care |
20:29 |
sapier |
but trees are way more common then caves |
20:29 |
PilzAdam |
or make it more generic and allow arbitrary direction (i.e. a step vector) and arbitrary attributes to be checked |
20:30 |
PilzAdam |
(so one could search for dirt_with_grass) |
20:30 |
sapier |
if you insist in making this a generic evaluation function I'll just gonna drop it |
20:31 |
sapier |
I wont spend a day in making this a perfect solution for everything, there are lot of ppl out there needing this way more then me |
20:31 |
PilzAdam |
it was just an idea |
20:31 |
sapier |
I know ... it's always an idea (generally speaking) ... and in the end a simple feature becomes a quite complex task and ppl comlain about complexity ;-) |
20:32 |
sapier |
I'm closing it it's not worth the effort required to get it in shape |
20:32 |
sapier |
... if other ppls features just would be evaluated same way .. |
20:35 |
|
ImQ009 joined #minetest-dev |
20:35 |
casimir |
Found that I have an quite old pull request open https://github.com/minetest/minetest/pull/875 |
20:36 |
|
exio4 joined #minetest-dev |
20:37 |
sapier |
casimir: is it still valid? |
20:38 |
casimir |
Yes |
20:39 |
sapier |
how to test? |
20:40 |
casimir |
Place sand one node above grass and let it fall. |
20:43 |
casimir |
It's not necessarily a bug, but it seems illogical when things get dropped that are supposed to be buildable to. |
20:53 |
sapier |
even after reading this 10 times I don't understand what this is gonna be to change guess only way to find out is trying |
20:58 |
sapier |
VanessaE: you're running https://github.com/minetest/minetest/pull/1475 for about a week now true? |
21:03 |
casimir |
Currently when some node, like sand, falls and would land inside a node that is non walkable e.g. papyrus, the papyrus is dropped as item. |
21:03 |
sapier |
I don't consider this to be that wrong |
21:04 |
casimir |
When it lands inside a node that is buildable to it also dropps that as item. |
21:04 |
sapier |
ah |
21:04 |
sapier |
ok so first is correct but last isn't? |
21:06 |
casimir |
Yes, it is more logical when the node is just removed. As this is the reason why there is buidable_to. |
21:06 |
|
exio41 joined #minetest-dev |
21:07 |
sapier |
sounds correct to me ... any other coredev same opinion? |
22:21 |
VanessaE |
sapier: yes, I'm still running that patch |
22:21 |
VanessaE |
not sure how long now, but at least since you had me initially try it, but I have not updated the server in a while. |
22:21 |
sapier |
so your opinion good to merge? |
22:21 |
VanessaE |
the commit in my local repo is dated Aug 8 |
22:22 |
VanessaE |
have there been any changes to it since then? |
22:22 |
VanessaE |
(it looks the same to me) |
22:23 |
sapier |
no I didn't touch that one in a while ... to busy doing crazy discussions ... again ;-) |
22:24 |
VanessaE |
then I'd say it's good, but until those huge lag spikes in minetest_game are solved, it's hard to be 100% sure |
22:24 |
VanessaE |
(assuming it is in fact minetest_game and not something lower-level) |
22:25 |
sapier |
havent those spikes been before too? |
22:25 |
VanessaE |
what? |
22:26 |
VanessaE |
OH |
22:26 |
VanessaE |
yes, they happened before this patch |
22:26 |
VanessaE |
but until they're solved, it's hard to see the improvement |
22:27 |
sapier |
actually you should see immediate improvement if you dig a lot of nodes for example |
22:27 |
VanessaE |
yes, that much I've noticed |
22:27 |
VanessaE |
though sometimes lag still gets the better of me |
22:31 |
VanessaE |
regarding the surfaces discussion I missed, why not just take the function from plants_lib and rewrite it to C++ ? |
22:31 |
VanessaE |
it's generic and elegant |
22:31 |
sapier |
do it |
22:31 |
VanessaE |
ha! |
22:31 |
sapier |
I did this once did rebase it 3 times by now I wont do it again, quite simple |
22:31 |
VanessaE |
(that was directed more at others than you really) |
22:32 |
sapier |
I tried this version as I alread did have it available, it's not been accepted so I'm done with it now, as noone else usually cares chances that feature will be done are quite low now |
22:33 |
VanessaE |
besides, yours is more of a "find the surface in this 1x1 column" function isn't it? mine finds whole, flat 2d(ish) surfaces. |
22:35 |
sapier |
it's find surface at exactly this 2d position within a certain height range |
22:35 |
sapier |
quite a simple task but doing it in lua spends a lot of time |
22:35 |
VanessaE |
yeah, my code solves a different problem then :) |
22:36 |
VanessaE |
yours is probably suitable for the job it was aimed at |
22:36 |
VanessaE |
spawning players, animals, etc |
22:37 |
VanessaE |
kinda surprised that didn't make it in yet, that IS a needed function. |
22:38 |
sapier |
I hate that damn text overlaying formspecs |
22:38 |
VanessaE |
yes |
22:38 |
VanessaE |
that definitely needs fixed |
22:38 |
sapier |
Zefram_Fysh: I've got a solution for our tab problem |
22:38 |
VanessaE |
I have to field complaints of "pipeworks mese sorting tube buttons don't work!" or parts of Unified Inventory similarly |
22:39 |
|
twoelk joined #minetest-dev |
22:40 |
sapier |
it's quite ugly if your tab header is right wihin the "unclickable" area |
22:41 |
VanessaE |
yeah |
22:41 |
sapier |
some workarounds are quite ironic |
22:41 |
sapier |
to make tabheaders work with variable fonts you have to disable them |
22:41 |
VanessaE |
tabs at the bottom? /hides |
22:44 |
sapier |
because if you disable the tabheader the event is passed to formspec menu and there you can detect it's actually been meant for tabheader, switch to correct font, enable tabheader pass event, disable tabheader revert font |
22:45 |
VanessaE |
talk about hacky |
22:47 |
sapier |
actually there's only two changes to forms left im my patch, button alignment and image size ... if I did change those back forms would look almost same as before |
22:48 |
sapier |
same crapy positioning, same messed up positions on scaling ... but at least at default screen size they'd be same again |
22:50 |
sapier |
well as there's noone having nuts enough to agree to fixing the formspec mess I'm gonne revert those positioning fixes |
22:54 |
sapier |
hmm maybe I should've read ShadowNinja's comment first ... |
22:57 |
VanessaE |
well you can always revert the revert :) |
22:57 |
sapier |
usually not because I don't keep old experimental versions |
22:58 |
VanessaE |
github does |
22:58 |
VanessaE |
the code is still there. |
22:58 |
VanessaE |
oh, you merged the profiler? |
22:58 |
VanessaE |
\o/ |
22:59 |
Zefram_Fysh |
re formspec, my patch is complete, I'm working on screenshots to demonstrate it. will be done soon |
22:59 |
sapier |
I want the code not the screenshot ;-P |
23:03 |
sapier |
VanessaE: where to find circular saw mod? |
23:04 |
VanessaE |
it's in moreblocks |
23:04 |
sapier |
ok how to show it's formspecs? |
23:04 |
VanessaE |
in dreambuilder, you can just search "saw", grab one, place it, right click on it |
23:05 |
VanessaE |
you can place wood or stone or a whole shitload of other stuff into the "Input" slot. |
23:06 |
sapier |
how to place? |
23:06 |
VanessaE |
just right click to place it like any other block |
23:06 |
sapier |
ahh got chain saw not circular saw |
23:06 |
VanessaE |
haha |
23:06 |
VanessaE |
yeah, Sokomine should have called it a "table saw" rather than a circular saw |
23:06 |
VanessaE |
(to me, the latter is hand-held) |
23:07 |
sapier |
any other formspecs in dreambuilder? |
23:07 |
VanessaE |
Color machine |
23:07 |
VanessaE |
that one's pretty complex |
23:07 |
VanessaE |
have some wood AND some wooden fences in your inventory to use for testing |
23:07 |
VanessaE |
(it operates differently depending on whether you're handing it a craft item or a node) |
23:07 |
sapier |
how to get it? |
23:08 |
VanessaE |
search "color" I think |
23:08 |
VanessaE |
:) |
23:08 |
sapier |
spray booth? |
23:08 |
VanessaE |
that's the one |
23:08 |
sapier |
I hate enter leaving inventory |
23:08 |
VanessaE |
"search words" -> tab -> space |
23:09 |
VanessaE |
keyboard trick I figured out to avoid that. |
23:09 |
VanessaE |
to see the more complex part of the formspec, "show supported blocks" |
23:09 |
sapier |
ok color machine is completely messed up if you have scaling fonts |
23:10 |
VanessaE |
eep |
23:11 |
VanessaE |
also, technic CNC machine |
23:11 |
VanessaE |
(search "cnc", looks like a grey spray booth) |
23:11 |
VanessaE |
needs I think LV power to operate but you don't need to run it to see the formspec |
23:11 |
sapier |
everythin relying on button to have fixed size ... wonder how messed up they already are on android |
23:12 |
VanessaE |
*scratches head* what else have we got in DB that's reasonably "busy"... |
23:14 |
|
ImQ009_ joined #minetest-dev |
23:22 |
VanessaE |
that's all I can think of at the moment :) |
23:23 |
VanessaE |
unless you wanna test larger text entry forms. signs and LuaControllers that use those. |
23:24 |
sapier |
spraybooth passes button height which was ignored by now ... that's why buttons get bigger |
23:24 |
sapier |
at least that one could be fixed |
23:24 |
VanessaE |
right. since their relative dimensions are fixed (or supposed to be), if you pass the height, the width should follow |
23:24 |
sapier |
hmm ... no not completely |
23:25 |
sapier |
button height was completely useless by no |
23:25 |
sapier |
now |
23:25 |
sapier |
guess making it useless again will cause less harm then fixing that bug |
23:25 |
VanessaE |
heh |
23:25 |
VanessaE |
well that's something that can be addressed later |
23:26 |
sapier |
no it ain't as that is one of the major glitches |
23:26 |
VanessaE |
incremental changes might be easier to adapt to than "holy fuck, everything broke all at once" :) |
23:26 |
VanessaE |
oh. damn. |
23:26 |
sapier |
I'll not touch it for sure later |
23:26 |
sapier |
and as modder I'd prefere to fix my forms once instead of once per month |
23:26 |
VanessaE |
true |
23:27 |
VanessaE |
unless it's so utterly broken that you end up having to do a complete rewrite |
23:28 |
* VanessaE |
hides behind the rubble known as "old version of plants_lib" ;-) |
23:29 |
sapier |
colormachine even uses different button heights :-) funny |
23:29 |
sapier |
noone ever complained about their buttons not resizing as requested |
23:29 |
VanessaE |
the result of some hack to get around a bug in the formspec code probablyt |
23:29 |
* VanessaE |
pokes Sokomine |
23:29 |
VanessaE |
just about time for her to be getting out of bed now |
23:30 |
sapier |
1:30 am? |
23:31 |
VanessaE |
oh that's right |
23:31 |
VanessaE |
I keep forgetting she's over on your side of the pond, not down Under |
23:32 |
VanessaE |
still, she's usually up around this time when it's hot outside. says it's usually cooler in the house at night |
23:33 |
sapier |
hmm sorry vanessae but it's quite cold in germany atm |
23:33 |
* VanessaE |
shrugs |
23:34 |
VanessaE |
it's what she said the other day |
23:35 |
sapier |
it's cold for about 2 weeks now |
23:35 |
VanessaE |
hm, maybe not just "the other day" then :) |
23:35 |
|
paramat joined #minetest-dev |
23:35 |
VanessaE |
*checks logs* |
23:35 |
VanessaE |
shit that was almost a month ago now |
23:35 |
VanessaE |
where'd the time go? |
23:36 |
|
hmmmmm joined #minetest-dev |
23:36 |
exio4 |
who knows! |
23:36 |
VanessaE |
Aug 15 2014 23:27:54 <Sokomine> yes. was very hot the past weeks. at night it was far better |
23:36 |
VanessaE |
ok not a month ago, a few days. |
23:36 |
VanessaE |
(looked at the wrong log) |
23:36 |
VanessaE |
maybe it's just cold where you are? ;) |
23:37 |
sapier |
it's cold everywhere in germany right now, |
23:38 |
* VanessaE |
shrugs :) |
23:38 |
VanessaE |
no matter |
23:39 |
sapier |
color machine would be quite some work |
23:40 |
sapier |
didn't Zefram_Fysh just want to do a few screenshots prior showing us his code? |
23:40 |
VanessaE |
that's what he said but he's very meticulous about making things be *just* right |
23:40 |
VanessaE |
so I give him plenty of space. he's *that* good. |
23:54 |
Zefram_Fysh |
ready now. git://git.fysh.org/zefram/minetest/minetest_engine.git branch zefram/form_scale -- http://81.2.79.47:8989/gitweb/?p=zefram/minetest/minetest_engine.git;h=refs/heads/zefram/form_scale -- screenshots at http://www.fysh.org/~zefram/tmp/form_scale.html |
23:56 |
Zefram_Fysh |
took me a while to sort out the screenshot toolchain. sorry to keep you all waiting |
23:57 |
sapier |
I'm ignoring that IGUIEvent thingy as it's not required |
23:57 |
Zefram_Fysh |
I fixed the tab-control font thing by creating a child of the tab control that intercepts its events and wraps OnEvent with setting the skin font. I'd like to compare that against the solution that you've mentioned |
23:58 |
VanessaE |
Zefram_Fysh: wow, you've got your screen brightness seriously tweaked. anyway everything looks right to me. |
23:59 |
Zefram_Fysh |
I've got inconsistent results about the gamma of those files. different tools displaying them at different brightness, and I'm not sure which is correct |
23:59 |
VanessaE |
Zefram_Fysh: this is correct brightness, for reference: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2008172014%20-%2006%3a05%3a11%20PM.png |