| Time |
Nick |
Message |
| 00:00 |
asl |
i talk about some memory leak in minetest a few days/weeks ago, after running minetest for awhile, it slowly hogging the ram and before you know it, it use up all the memory and freeze the whole os, exiting to the menu doesn't free the memory, only closing minetest then the memory would be free |
| 00:01 |
VanessaE |
huh. |
| 00:01 |
asl |
it slowly hog more and more memory as more block/chunk of the map get loaded and that's is the only lead i got |
| 00:01 |
VanessaE |
[06-17 20:00] <VanessaE> Jordach: also, 6.133 GB with HDX 256 at Creative's spawn after pitching and panning my view around and letting every last bit of map around me load up |
| 00:01 |
VanessaE |
[06-17 20:01] <VanessaE> no preload, all settings enabled except for parallax, have not opened the inventory yet. |
| 00:12 |
|
Eater4 joined #minetest-dev |
| 00:42 |
VanessaE |
Ok after enabling some swap, Minetest uses 14.342 GB virtual, and somewhere in the 12 GB resident range, with HDX 512, just standing here looking around at the spawn on my Creative server. |
| 00:42 |
VanessaE |
THAT'S FUCKING INSANE. |
| 00:42 |
VanessaE |
the G*d damn pack is only ~420 MB. |
| 00:42 |
VanessaE |
and I am NOT using preload visuals |
| 00:43 |
VanessaE |
so there's no way in hell it should be using this much, this soon. |
| 00:43 |
VanessaE |
all I'm doing is standing at the spawn, looking around. |
| 00:43 |
VanessaE |
FPS: 3-4. |
| 00:45 |
VanessaE |
and that's with the view range turned all the way down to 5m. |
| 00:45 |
VanessaE |
what is the problem here? |
| 00:50 |
VanessaE |
hello? |
| 00:51 |
VanessaE |
and yes, I'm ranting |
| 00:56 |
Sokomine |
whatever the problem is, hope it can be fixed. less good hardware may profit from such fixes as well |
| 01:04 |
VanessaE |
well if Jordach can do the same server with less than half the usage, and roughly equivalent CPU and graphics power, but under Windows, then surely it can |
| 01:04 |
VanessaE |
but does anyone care? |
| 01:04 |
VanessaE |
or is everyone obsessed with the server? |
| 01:04 |
VanessaE |
(except RealBadAngel, whose focus is on shaders) |
| 01:32 |
|
Megaf joined #minetest-dev |
| 02:36 |
|
Eater4 joined #minetest-dev |
| 02:38 |
VanessaE |
if I turn off aniso/mipmap, it barely even touches the RAM usage (not enough to even measure). |
| 02:38 |
VanessaE |
(and gives me back a ton of framerate, probably because of GPU overload). |
| 02:38 |
VanessaE |
if I turn off normalmaps, that gains back about 2.5GB, but still leaves me using over 9.5 GB of RAM. |
| 02:39 |
VanessaE |
I simply can't use any less than that, and that's still almost twice the usage Jordach was getting with windows, and he was using normalmaps. |
| 02:39 |
VanessaE |
someone has to explain this. |
| 02:45 |
Exio4 |
i've been trying, i seem to end with the resource usage as a lot vs the win build (using latest's sfan5 build at the moment, cb3b42e) against latest git |
| 02:45 |
Exio4 |
with same settings it ended being as much as 375% (3.75x :P) |
| 02:48 |
VanessaE |
^^^ that is, his experience mirrors mine, only worse. |
| 02:57 |
VanessaE |
https://github.com/minetest/minetest/issues/1386 |
| 05:25 |
|
Miner_48er joined #minetest-dev |
| 05:46 |
|
Hunterz joined #minetest-dev |
| 05:53 |
|
grrk-bzzt joined #minetest-dev |
| 06:12 |
|
LemonLake joined #minetest-dev |
| 06:17 |
|
werwerwer_ joined #minetest-dev |
| 06:23 |
|
werwerwer_ joined #minetest-dev |
| 06:23 |
|
NakedFury joined #minetest-dev |
| 07:09 |
|
OldCoder joined #minetest-dev |
| 07:35 |
|
CraigyDavi_ joined #minetest-dev |
| 08:13 |
|
CraigyDavi joined #minetest-dev |
| 08:15 |
|
CraigyDavi__ joined #minetest-dev |
| 08:37 |
|
kaeza joined #minetest-dev |
| 08:38 |
|
CraigyDavi_ joined #minetest-dev |
| 09:24 |
|
kaeza joined #minetest-dev |
| 09:55 |
|
restcoser joined #minetest-dev |
| 10:03 |
|
Jordach joined #minetest-dev |
| 10:43 |
|
Eater4 joined #minetest-dev |
| 10:46 |
|
proller joined #minetest-dev |
| 11:01 |
|
ImQ009 joined #minetest-dev |
| 11:26 |
|
CraigyDavi joined #minetest-dev |
| 11:28 |
|
CraigyDavi__ joined #minetest-dev |
| 11:29 |
|
Megaf joined #minetest-dev |
| 11:39 |
|
CraigyDavi_ joined #minetest-dev |
| 11:43 |
|
vifino joined #minetest-dev |
| 11:49 |
|
alexxss joined #minetest-dev |
| 12:03 |
|
khonkhortisan joined #minetest-dev |
| 12:04 |
|
Megaf_ joined #minetest-dev |
| 12:08 |
|
EvergreenTree joined #minetest-dev |
| 12:52 |
|
hmmmm joined #minetest-dev |
| 12:54 |
RealBadAngel |
hi hmmmm, whats up? |
| 12:55 |
hmmmm |
skipping work today |
| 12:56 |
RealBadAngel |
i do have 2 weeks off |
| 12:56 |
hmmmm |
well good for you |
| 12:56 |
hmmmm |
hopefully I'll have more time soon |
| 12:57 |
RealBadAngel |
i will also have a bit more time later, i will work as a coder soon |
| 12:57 |
RealBadAngel |
and propably will work at home |
| 12:58 |
hmmmm |
yeah same here, work at home seems great |
| 12:58 |
hmmmm |
today i have the final interview for this new job |
| 12:58 |
hmmmm |
3 hours long |
| 12:59 |
hmmmm |
all with cell phone voice quality |
| 13:01 |
RealBadAngel |
and you have this job? |
| 13:01 |
hmmmm |
i will. i'm switching over |
| 13:02 |
RealBadAngel |
cool |
| 13:03 |
RealBadAngel |
about my 2 weeks off, im gonna spend them on coding |
| 13:03 |
RealBadAngel |
i already started with some small things |
| 13:03 |
hmmmm |
lol, i know exactly what i need to get done |
| 13:04 |
hmmmm |
which involves more trial and error |
| 13:06 |
RealBadAngel |
after im done with several small features, im gonna focus on two things |
| 13:07 |
RealBadAngel |
rendering buffers and mesh drawtype |
| 13:08 |
|
werwerwer joined #minetest-dev |
| 13:15 |
RealBadAngel |
- |
| 13:15 |
RealBadAngel |
+-+-- |
| 13:15 |
RealBadAngel |
+- |
| 13:16 |
RealBadAngel |
ooops |
| 13:17 |
|
proller joined #minetest-dev |
| 13:24 |
|
kaeza joined #minetest-dev |
| 13:37 |
RealBadAngel |
hmmmm, any plans on pushin mgv7 forward? |
| 13:38 |
RealBadAngel |
also, i was working lately on tooltips for some formspec elements and now i agree with ShadowNinja |
| 13:39 |
RealBadAngel |
we definitely have to drop that shit, it leads to nowhere |
| 13:39 |
RealBadAngel |
adding new features is pain in the ass, keeping compability is almost impossible |
| 13:40 |
RealBadAngel |
we have to use just tables |
| 13:40 |
RealBadAngel |
sooner we drop strings the better |
| 13:42 |
|
diemartin joined #minetest-dev |
| 13:50 |
|
PilzAdam joined #minetest-dev |
| 13:52 |
|
Hunterz joined #minetest-dev |
| 14:04 |
hmmmm |
yes, i would like to move mgv7 forward |
| 14:12 |
|
Krock joined #minetest-dev |
| 14:16 |
|
NakedFury joined #minetest-dev |
| 14:17 |
ShadowNinja |
So I rewrote the server list in Python: http://sprunge.us/QEHP?python |
| 14:18 |
ShadowNinja |
It isn't feature-complete just yet, but it has some advantages, such as lots more checks on the server data. |
| 14:23 |
|
alexxss joined #minetest-dev |
| 14:25 |
|
LemonLake joined #minetest-dev |
| 14:36 |
RealBadAngel |
ShadowNinja, so, are we moving to tables instead of strings? |
| 14:36 |
RealBadAngel |
im ready to help with that |
| 14:37 |
|
diemartin joined #minetest-dev |
| 14:37 |
sfan5 |
merging in 10 mins: https://github.com/minetest/minetest/pull/1375 |
| 14:46 |
|
Krock joined #minetest-dev |
| 14:50 |
ShadowNinja |
RealBadAngel: Yes, do you think you can code that? You'll have to use JSON or core.serialize for sending over the network and the client should still support the old format for a release or two. |
| 14:51 |
ShadowNinja |
I know Lua, but not network or client. |
| 14:52 |
|
PenguinDad joined #minetest-dev |
| 14:59 |
|
Eater4 joined #minetest-dev |
| 15:09 |
|
crazyR joined #minetest-dev |
| 15:13 |
|
GhostDoge joined #minetest-dev |
| 15:18 |
|
pitriss joined #minetest-dev |
| 15:20 |
|
vifino_ joined #minetest-dev |
| 15:20 |
RealBadAngel |
ShadowNinja, i think serializing/deserializing could be better, readability is not the point here |
| 15:21 |
RealBadAngel |
about old format... im not sure |
| 15:22 |
RealBadAngel |
i think we should rather release 0.4.10 soon as last version with formspecs and go for new stuff |
| 15:23 |
RealBadAngel |
a) we havent released stable for a long time already, theres lotsa features onboard already |
| 15:23 |
|
Piggybear87 joined #minetest-dev |
| 15:23 |
RealBadAngel |
b) it will give us some time till next release to work on new system |
| 15:24 |
|
kaeza joined #minetest-dev |
| 15:24 |
RealBadAngel |
my proposal is, lets gather all the possible fixes we have around |
| 15:24 |
RealBadAngel |
till the end of the week, lets say |
| 15:25 |
RealBadAngel |
and then we can start pushing new code |
| 15:25 |
RealBadAngel |
i do have at least 2 weeks off just for coding |
| 15:26 |
RealBadAngel |
so i will be definitely hyper active |
| 15:31 |
|
kaeza joined #minetest-dev |
| 15:31 |
VanessaE |
I don't recommend dropping support for formspecs for a very LONG time, if ever |
| 15:31 |
VanessaE |
though making them as deprecated and basically never talking about them, is a good idea |
| 15:31 |
VanessaE |
marking* |
| 15:34 |
sfan5 |
I think it's ok to make a new release.. http://sprunge.us/XfiT |
| 15:34 |
RealBadAngel |
as i said, next weekend |
| 15:35 |
RealBadAngel |
if we do have some fixes, push them and go |
| 15:35 |
sfan5 |
how about next friday? |
| 15:35 |
sfan5 |
I won't be having much time next saturday |
| 15:35 |
|
Hunterz joined #minetest-dev |
| 15:44 |
|
kaeza joined #minetest-dev |
| 15:48 |
Krock |
yay! a new version! |
| 15:54 |
RealBadAngel |
sfan5, you mean 27.06? |
| 15:54 |
sfan5 |
yes |
| 15:55 |
RealBadAngel |
its ok with me |
| 15:55 |
RealBadAngel |
enough time to gather forsaken fixes and work on needed ones |
| 15:56 |
|
sapier joined #minetest-dev |
| 15:56 |
VanessaE |
how about using REAL irrlicht particles instead of minetest entities for particle spawners? too late for that? :) |
| 15:56 |
RealBadAngel |
i think not for this release |
| 15:56 |
sfan5 |
VanessaE: irrlicht particles can't have collision IIRC |
| 15:56 |
VanessaE |
didn't think so. |
| 15:56 |
VanessaE |
sfan5: so don't use them when collisions are needed? |
| 15:57 |
RealBadAngel |
lets focus on bugfixes right now |
| 15:57 |
sapier |
entities for particles? hope you're not talking about increasing those :-) |
| 15:57 |
RealBadAngel |
we do have a few issues open |
| 15:57 |
sapier |
numbers |
| 15:57 |
* VanessaE |
shrugs and gives up. |
| 15:58 |
RealBadAngel |
VanessaE, dont give up, but this is like new feature, not a bugfix |
| 15:58 |
|
kaeza joined #minetest-dev |
| 15:58 |
VanessaE |
RealBadAngel: it would be a bugfix, imho, because particle spawners are unusable in their current state. |
| 15:58 |
RealBadAngel |
same as formspecs |
| 15:58 |
VanessaE |
no, I mean literally |
| 15:59 |
sapier |
vanessae you forgot about png being compressed images while textures arent |
| 15:59 |
VanessaE |
formspecs at least work |
| 15:59 |
RealBadAngel |
to some point |
| 15:59 |
VanessaE |
particle spawners cause a horrible performance hit when they're used |
| 15:59 |
VanessaE |
and this should not happen |
| 15:59 |
VanessaE |
sapier: I did not forget. |
| 15:59 |
sapier |
meaning each of your 512hdx textures is at leas 1MB ram |
| 15:59 |
RealBadAngel |
what do you think, how much it takes to compare two formspec strings? |
| 16:00 |
VanessaE |
sapier: but that doesn't explain why Linux uses 2 to 3 times as much RAM as Windows under the same conditions, settings, and hardware capabilities. |
| 16:00 |
sapier |
that's true |
| 16:00 |
VanessaE |
sapier: ok, 3400 * 1 MB. big deal. that's only 3.4 GB. |
| 16:02 |
VanessaE |
excuse me, 3279 * 1 MB. |
| 16:02 |
sapier |
I'm against a fixed schedule for formspec because there's noone who wants to do that work right now, everyone demands it to be replaced but once someone is asked to do it that one usually becomes very very silent |
| 16:02 |
RealBadAngel |
sapier, me and SN |
| 16:02 |
VanessaE |
even if you include normalmaps, that's only 1855 more, or 5134. |
| 16:03 |
RealBadAngel |
we want to work on that |
| 16:03 |
sapier |
don't get me wrong I'm not against doing it in a better way but it has to provide all current features and compatibility code |
| 16:03 |
RealBadAngel |
we will see |
| 16:03 |
VanessaE |
sapier: if your 1MB-per-texture guess is correct, then that's 5134 MB for every last texture in existence for the HDX 512px pack and its normalmaps, and that would be a perfectly reasonable amount. |
| 16:03 |
sapier |
and I'm against doing a release prior merging android port too it's 95% done |
| 16:04 |
sapier |
1mb per texture isn't a gues but a exact calculation |
| 16:04 |
RealBadAngel |
we cant delay releases forever on the other hand |
| 16:04 |
sapier |
512px * 512px * 4 bytes |
| 16:04 |
RealBadAngel |
theres too much code in already |
| 16:04 |
VanessaE |
sapier: ok, exact calculation. that makes it even worse. |
| 16:05 |
sapier |
it's been waiting for 6 months now why do you wanna delay android support till christmas |
| 16:05 |
RealBadAngel |
modders do need stable releases |
| 16:05 |
VanessaE |
sapier: that means I'm losing no less than 7-8 GB of RAM to some random leak. |
| 16:05 |
sapier |
especially as it's about 2 weeks prior merge |
| 16:05 |
RealBadAngel |
we can wait 2 weeks |
| 16:05 |
RealBadAngel |
its just about we have chosen |
| 16:06 |
RealBadAngel |
27.06 or lets say end of the month |
| 16:06 |
RealBadAngel |
it is enough for you? |
| 16:06 |
sapier |
modders do need a stable version for about 4-5 months now ... our build schedule is plain crap |
| 16:06 |
sapier |
depends on how active ppl are at reviewing the remaining changes |
| 16:07 |
RealBadAngel |
i do have 2 weeks off |
| 16:07 |
RealBadAngel |
started yesterday |
| 16:07 |
Jordach |
why should we remove formspecs? |
| 16:07 |
RealBadAngel |
because theyre dead end |
| 16:07 |
Jordach |
not good enough answer |
| 16:07 |
RealBadAngel |
overengineered |
| 16:07 |
sapier |
jordach in mid to long term they have to be replaced by a more generic mechanism but my personal opinion is this will take at least 2-3 releases |
| 16:08 |
RealBadAngel |
more features we add its gettin worse |
| 16:08 |
sapier |
come one rba just because they don't fit your current requirements ;-) |
| 16:08 |
RealBadAngel |
no |
| 16:08 |
RealBadAngel |
i can see we are standing on the edge |
| 16:08 |
sapier |
any generic implementation will be way more complicated then formspec |
| 16:08 |
RealBadAngel |
tables.... |
| 16:08 |
sapier |
most likely we need a gui designer for it |
| 16:09 |
RealBadAngel |
what we do need is just to transfer lua tables to c++ side |
| 16:09 |
sapier |
lol |
| 16:09 |
RealBadAngel |
and put the elements into existing structures |
| 16:09 |
RealBadAngel |
without strings parser |
| 16:09 |
sapier |
sorry but believing c++ is the answer is almost always wrong |
| 16:10 |
RealBadAngel |
no |
| 16:10 |
RealBadAngel |
i said on c++ side everythin is ok |
| 16:10 |
sapier |
and next time irrlicht changes all of our gui api is broken |
| 16:10 |
RealBadAngel |
we need just flexibility tables can provide |
| 16:11 |
RealBadAngel |
changing an element, adding new one |
| 16:11 |
Jordach |
what i'm thinking is a master table, and then other tables inside said table, containing the data, such as slots[1] = "itemstring <number of item>" |
| 16:11 |
RealBadAngel |
piece of cake while using tables |
| 16:11 |
|
Garmine joined #minetest-dev |
| 16:12 |
RealBadAngel |
think of a table like of a folder |
| 16:12 |
sapier |
I don't believe that's gonna be siginificant more readable but way more hard to parse |
| 16:12 |
RealBadAngel |
put into root size, backgrounds, etc |
| 16:12 |
RealBadAngel |
and then in parent elements |
| 16:12 |
Jordach |
sapier, considering i get headaches from current formspecs - yes, that'd probably help in the long run |
| 16:13 |
sapier |
yes but in long run we shouldn't invent another proprietary format as we already did with formspec but use some more common one |
| 16:13 |
RealBadAngel |
cmon, tables are what we do have |
| 16:13 |
RealBadAngel |
we dont have to invent anything |
| 16:14 |
RealBadAngel |
just iterate over the table and send it to c++ side |
| 16:15 |
RealBadAngel |
adding new features will be nothing more like adding new field |
| 16:15 |
sapier |
sorry I don't believe that's gonna provide a real benefit especially on guessing the amount of work required, but you're free to proove me wrong |
| 16:16 |
RealBadAngel |
that will give us flexibility we dont have |
| 16:17 |
RealBadAngel |
generating complex formspecs is lookin as a bad joke |
| 16:17 |
RealBadAngel |
see UI's code |
| 16:17 |
sapier |
well usually flexibility adds complexity too |
| 16:17 |
RealBadAngel |
complexity we have ^2 alreadty |
| 16:17 |
sapier |
formspecs benefit is it's quite easy to get started |
| 16:17 |
RealBadAngel |
without ANY flexibility |
| 16:18 |
RealBadAngel |
for simple forms, yes |
| 16:18 |
sapier |
you don't need to do complex things while a table thingy might be complex for simple things too |
| 16:18 |
RealBadAngel |
but it evolved into something worth monthy python's award of the year |
| 16:19 |
RealBadAngel |
in current state formspecs are a bad joke just |
| 16:19 |
RealBadAngel |
they were good for signs |
| 16:19 |
RealBadAngel |
and for that we can leave them in the engine |
| 16:20 |
RealBadAngel |
but UI screams for something usable and flexible |
| 16:20 |
sapier |
noone stops you from implementing a better suggestion rba ... but don't you have enough work with shaders? ;-) |
| 16:20 |
RealBadAngel |
code that builds single string out of hundreds of pieces? oh cmon |
| 16:21 |
RealBadAngel |
i believe even UI can hit thousand rite now |
| 16:21 |
RealBadAngel |
now try to debug such string |
| 16:22 |
RealBadAngel |
its DEAD END |
| 16:22 |
sapier |
noone is questionong that formspecs should be replaced but noone is there to do the work too |
| 16:22 |
|
rubenwardy joined #minetest-dev |
| 16:24 |
RealBadAngel |
sn said that about two weeks ago |
| 16:24 |
RealBadAngel |
now after my attempt to add tooltips joined him |
| 16:25 |
sapier |
ok is there anyone who wants to rewrite formspecs as well as main menu? |
| 16:26 |
RealBadAngel |
are you blind or what? :P |
| 16:26 |
RealBadAngel |
me and sn |
| 16:27 |
RealBadAngel |
i can see its not that hard to do |
| 16:27 |
sapier |
then start doing it ... but believe me 2 weeks is far from enough |
| 16:27 |
RealBadAngel |
huh |
| 16:27 |
RealBadAngel |
try me |
| 16:28 |
sapier |
as I said I'd be glad if you proof me to be wrong |
| 16:28 |
RealBadAngel |
before month ends you will have that |
| 16:29 |
RealBadAngel |
and be ready to buy crate of beer for both of us :P |
| 16:30 |
sapier |
don't forget about doc and don't break any mod |
| 16:31 |
sapier |
and of course, it's up to you to persuade modders your's is really better ;-P |
| 16:32 |
sapier |
still RealBadAngel I'd prefere if you did things really providing benefit like doing the shaders |
| 16:32 |
sapier |
formspec is ugly but not broken |
| 16:33 |
sapier |
and debugging a lua table isn't better then debugging a string |
| 16:37 |
sapier |
comments? https://github.com/minetest/minetest/pull/1373 I'd like to merge it |
| 16:37 |
Eater4 |
sapier: I do not understand how to use (your) faction mod |
| 16:39 |
VanessaE |
sapier: any regression potential? |
| 16:39 |
sapier |
none I know about |
| 16:40 |
sapier |
it's just an addon |
| 16:40 |
sapier |
so where nothing happened before something will happen ... of course if someone relied on nothing to happen (that'd be silly) there might be issues |
| 16:40 |
VanessaE |
you mean like how the old signs formspecs were? ;) |
| 16:41 |
* Krock |
likes the new dropdown box |
| 16:42 |
sapier |
it's not new ... just the behaviour |
| 16:43 |
Krock |
I see |
| 16:44 |
|
zat joined #minetest-dev |
| 16:44 |
sapier |
by now you had to read it's content on pressing some button ... you can do this in future too but now you can react immediatly once it's changed |
| 16:45 |
|
kaeza joined #minetest-dev |
| 16:45 |
Krock |
list boxes already have this feature, so it's good to have it there too |
| 16:47 |
|
jin_xi joined #minetest-dev |
| 16:48 |
sapier |
did anyone test it by now? |
| 16:50 |
|
Calinou joined #minetest-dev |
| 16:54 |
Krock |
just merge it - the revert function exists when something went wrong |
| 16:54 |
kaeza |
... |
| 16:55 |
sapier |
well reverting things is last thing we wanna do |
| 17:12 |
sapier |
ok after doing some additional testing I'm gonna merge 1373 now |
| 17:14 |
sapier |
could someone please test this changes https://github.com/minetest/minetest/pull/1359 they provide up to 20% more fps |
| 17:14 |
RealBadAngel |
can you squash them? |
| 17:15 |
RealBadAngel |
git rebase - i HEAD~8 |
| 17:15 |
Megaf |
sapier: Im testing #1359 when I get home |
| 17:16 |
sapier |
pushing #1373 now |
| 17:17 |
Megaf |
sapier: VanessaE: in unified_inventory, It wont be possible to click on an item if the text from chat/server is at the same "height" of the item row. |
| 17:17 |
VanessaE |
Megaf: not limited to Unified Inventory. |
| 17:17 |
Calinou |
no disable_jump? lua_api.txt talks about it, but it has no effect: I can jump on a nodebox that uses it, even if nothing is below and it and besides it (to be sure there are no collision errors) |
| 17:17 |
VanessaE |
any formspec is covered by the chat area. |
| 17:18 |
VanessaE |
Megaf: it also affects pipeworks' mese sorting tubes' formspecs (the white button is inaccessible while chat is enabled) |
| 17:18 |
Krock |
Agh I really must buy a new PC in the next days... I'd like to test those commits but the compiling time of 31min ppisses meoff |
| 17:18 |
RealBadAngel |
build it incrementally |
| 17:18 |
sapier |
or use make -j<number of cores+1> |
| 17:18 |
Calinou |
RealBadAngel, isn't this the default? |
| 17:19 |
Calinou |
when you modify only one file, only this file and a few more ones are recompiled |
| 17:19 |
sapier |
depends on what is modified |
| 17:19 |
Krock |
sapier, make -j 2 :P |
| 17:19 |
RealBadAngel |
it is, but maybe he continuosly is building mc in new folder |
| 17:19 |
RealBadAngel |
*mt |
| 17:19 |
sapier |
we've got a insane header coupling within mt |
| 17:20 |
RealBadAngel |
sapier, btw, could you fix tooltips rectangles resizing while in mainmenu? |
| 17:21 |
sapier |
there's no simple way to do this |
| 17:21 |
RealBadAngel |
pro tip, it works correctly while in game |
| 17:21 |
sapier |
I already know why it happens |
| 17:21 |
RealBadAngel |
without that, my tooltips commit is useless |
| 17:22 |
sapier |
mainmenu is a fixed size formspec thus viewport is set to 800x600 |
| 17:22 |
sapier |
no matter how big window is |
| 17:22 |
Megaf |
[14:18:09] <Krock> Agh I really must buy a new PC in the next days... I'd like to test those commits but the compiling time of 31min ppisses meoff |
| 17:22 |
VanessaE |
sapier: but the bounding boxes go way beyond 800px wide. |
| 17:22 |
Megaf |
It takes 3 minutes to compile on my ARM board Krock |
| 17:22 |
VanessaE |
like, 3000+ pixels. |
| 17:23 |
sapier |
calculation error? |
| 17:23 |
Megaf |
Krock: try -DBUILD_REDIS=0 -DBUILD_LEVELDB=0 -DBUILD_SERVER=0 options |
| 17:23 |
VanessaE |
sapier: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2006152014%20-%2008%3a54%3a20%20PM.png |
| 17:23 |
Krock |
Megaf, leveldb doesn't work, I don't have redis libs, server is in client too |
| 17:24 |
Megaf |
yep, so you can disable support for them |
| 17:24 |
VanessaE |
sapier: I can reproduce ^^^^^ that with as much as 3000 pixels of separation between the pointer and the NOT-focused Minetest window :) |
| 17:24 |
sapier |
that's something completely different |
| 17:24 |
sapier |
that's checkboxes having fixed lenght |
| 17:24 |
Megaf |
[14:18:01] <VanessaE> Megaf: it also affects pipeworks' mese sorting tubes' formspecs (the white button is inaccessible while chat is enabled) |
| 17:24 |
Megaf |
That's really bad |
| 17:25 |
sapier |
fix for this should be easy |
| 17:25 |
Megaf |
Can't chat be sent a layer before that? |
| 17:25 |
sapier |
I'll push the fix direct |
| 17:26 |
Megaf |
Please, and thanks. |
| 17:27 |
VanessaE |
Megaf: he's talking about the main menu glitch, not the chat thing. |
| 17:27 |
Megaf |
oh |
| 17:27 |
Megaf |
too bad |
| 17:27 |
Megaf |
=/ |
| 17:27 |
Megaf |
And I don't get that menu glitch here |
| 17:27 |
kaeza |
<Calinou> when you modify only one file, only this file and a few more ones are recompiled |
| 17:27 |
kaeza |
because C++ |
| 17:27 |
sapier |
you don't have tooltips so you don't see it |
| 17:27 |
VanessaE |
Megaf: you don't have the patch in place that was used to gen... yeah |
| 17:28 |
sapier |
megaf I once did a fix for this but someone had a better way to do it ... sadly I don't remember who |
| 17:28 |
VanessaE |
sapier: "better" fixes, imho, are useless if they aren't committed :P |
| 17:29 |
Megaf |
indeed |
| 17:29 |
VanessaE |
(so whosever better way it was botched it by blocking you and not following through with their idea) |
| 17:30 |
sapier |
well I thought it was and realized months later it wasnt |
| 17:30 |
Megaf |
A fix that fixes and dont cause regreations/performance loss is a good fix |
| 17:30 |
RealBadAngel |
i can live with tooltips just on checkboxes box |
| 17:30 |
RealBadAngel |
but resizing have to be done |
| 17:38 |
RealBadAngel |
sapier? can you fix that mainmenu resizing? |
| 17:39 |
sapier |
no |
| 17:40 |
sapier |
but I can fix those bounding boxes causing the bug in vanessaE's screenshot |
| 17:40 |
RealBadAngel |
bounding boxes are not a problem |
| 17:40 |
RealBadAngel |
position of the rectangles is the real problem |
| 17:41 |
sapier |
if you want your tooltips to use full screen size use porting::getWindowSize() to get the real screen size not the menu size |
| 17:41 |
RealBadAngel |
tooltips rectangles doesnt match elements after resizing |
| 17:41 |
VanessaE |
RealBadAngel: um, that screenshot was taken with the window at its default size... |
| 17:41 |
sapier |
sorry I lost track what are we talking about now |
| 17:42 |
RealBadAngel |
VanessaE is talking about hardcoded rectangles for checkboxes |
| 17:42 |
RealBadAngel |
which is wrong but not critical |
| 17:43 |
RealBadAngel |
im talkin bout that defined rectangle which is used to check whenever cursor points the element is broken while in main menu |
| 17:43 |
RealBadAngel |
it works ingame |
| 17:43 |
RealBadAngel |
so i cannot define them another way |
| 17:43 |
RealBadAngel |
theyre not scaled to respect viewport changes |
| 17:44 |
sapier |
I don't think so |
| 17:44 |
VanessaE |
why would they scale if the main menu doesn't change size anyway? |
| 17:44 |
sapier |
I'll have look at your code but I think you did something wrong |
| 17:44 |
RealBadAngel |
they do work properly ingame |
| 17:45 |
RealBadAngel |
whenever you rescale viewport in mainmenu theyre shifted |
| 17:45 |
VanessaE |
so you meant the *origin* moves |
| 17:45 |
RealBadAngel |
yes |
| 17:45 |
VanessaE |
not that the size of the target bit changes |
| 17:45 |
VanessaE |
target box* |
| 17:46 |
RealBadAngel |
same code is used for all the elements no matter ingame or mainmenu |
| 17:46 |
RealBadAngel |
in game all is ok |
| 17:47 |
sapier |
why don't you just ask irrlicht what element the cursor is at? that's what the engine is for? |
| 17:47 |
RealBadAngel |
ok, keep asking me to trash that formspec and related code |
| 17:47 |
RealBadAngel |
and i will do so |
| 17:48 |
sapier |
give me a few minutes to finish the bounding boxes then I'm gonna show you how to do the tooltips without own rects |
| 17:48 |
sapier |
irrlicht already does this for us so we don't need to reimplement it |
| 17:48 |
RealBadAngel |
we already did long time ago |
| 17:49 |
sapier |
+if (tooltip_x + tooltip_width > (s32)screenSize.X) +tooltip_x = (s32)screenSize.X - tooltip_width - 15; |
| 17:49 |
RealBadAngel |
im asking you to make it work in mainmenu |
| 17:49 |
sapier |
that's causing the issue as screenSize isn't really screensize there |
| 17:50 |
sapier |
but that doesn't actually matter using own rects while irrlicht already has them is broken anyway |
| 17:50 |
sapier |
and yes I know that's in there for some time |
| 17:50 |
RealBadAngel |
since always... |
| 17:51 |
sapier |
obviously the one implementing it didn't know she/he could make irrlicht do the work |
| 18:05 |
RealBadAngel |
if so, its really let the engine do that |
| 18:05 |
RealBadAngel |
*better |
| 18:14 |
|
lemonlake joined #minetest-dev |
| 18:14 |
|
lemonlake joined #minetest-dev |
| 18:15 |
sapier |
can someone explain to me why I always have to find bugs at locations where noone expects bugs ... text width calculation is broken |
| 18:15 |
lemonlake |
because you look in areas where nobody looks |
| 18:15 |
RealBadAngel |
hmmm, broken? |
| 18:16 |
RealBadAngel |
it worked for me correctly, it is takin into account \n 's |
| 18:16 |
RealBadAngel |
and returnin length of the longest line |
| 18:16 |
sapier |
according to irrlicht doc's it's supposed to calculate lengths in pixels a string would be rendered to |
| 18:16 |
sapier |
but that's wrong |
| 18:16 |
sapier |
it's way below that length |
| 18:16 |
rubenwardy |
I have tested #1359 The view difference doubles for me when keeping the same fps. Overwise it goes from 23fps -> 29/30 fps. |
| 18:16 |
RealBadAngel |
for tooltips it is working more than perfect |
| 18:17 |
RealBadAngel |
it is height that is broken |
| 18:17 |
RealBadAngel |
i had to manually count the lines |
| 18:17 |
sapier |
hmm |
| 18:17 |
RealBadAngel |
look at my commit |
| 18:17 |
sapier |
what do you use? font->getDimension() |
| 18:17 |
sapier |
? |
| 18:17 |
RealBadAngel |
getWidth and getHeight |
| 18:18 |
RealBadAngel |
lemme check |
| 18:18 |
sapier |
hmm you use the created element |
| 18:21 |
RealBadAngel |
http://pastebin.com/CypR7kGF |
| 18:22 |
sapier |
yes ... sadly I can't do it that way because I don't have a gui element by that time |
| 18:24 |
RealBadAngel |
thats why i wasnt able to calculate proper width for checkbox |
| 18:26 |
|
vifino joined #minetest-dev |
| 18:40 |
RealBadAngel |
sapier, indeed irrlicht have tooltips |
| 18:40 |
RealBadAngel |
but its not enough for u |
| 18:40 |
RealBadAngel |
us |
| 18:41 |
RealBadAngel |
we do have our own gui elements, like itemstacks, itemimagebuttons, imagebuttons etc |
| 18:41 |
sapier |
hmm didn't even notice you didn't use the irrlicht tooltips |
| 18:41 |
sapier |
I was talking about detecting where the mouse cursor is only |
| 18:42 |
RealBadAngel |
its not my code |
| 18:42 |
RealBadAngel |
i havent invented that, but i can see now why it was done in the first place |
| 18:43 |
sapier |
as I understand why labels have fixed size ... the one implementing it most likely didn't want to look for the getDimension bug |
| 18:43 |
RealBadAngel |
theres way around that |
| 18:44 |
sapier |
what do you suggest? |
| 18:44 |
RealBadAngel |
make invisible label of same text and check its width |
| 18:44 |
sapier |
that's a ugly hack |
| 18:44 |
RealBadAngel |
but will work for sure |
| 18:44 |
sapier |
well mine is ugly too ... but at least way more performant ;) |
| 18:45 |
sapier |
I'm just gonna multiply witdth by 1.5 ... still not correct but way better then fixed 300 |
| 18:45 |
RealBadAngel |
that could be generic function that will create label examine it, delete and return dimensions |
| 18:45 |
sapier |
still it'd create a gui element |
| 18:45 |
RealBadAngel |
wont work with different fonts |
| 18:46 |
RealBadAngel |
vanessa will be bitching about it for sure ;) |
| 18:46 |
RealBadAngel |
shes using larger font |
| 18:46 |
sapier |
I'll not add something causing that much additional memory operations as quick n dirty hack |
| 18:46 |
sapier |
I'll look for the original bug later but for not it's at least better then the current state |
| 18:46 |
RealBadAngel |
lables are not time critical |
| 18:47 |
sapier |
but memory operations cause heap fragmentation |
| 18:47 |
|
Krock left #minetest-dev |
| 18:47 |
sapier |
I know we already do to much but adding additional ones wont make it better ... and may even cause ghost texts |
| 18:47 |
RealBadAngel |
not a big deal while in a menu |
| 18:47 |
RealBadAngel |
you can clear whole stack while leaving |
| 18:48 |
sapier |
fragmentation doesn't vanish once you enter game and it's in game formspec too |
| 18:48 |
sapier |
no you can't clear stack |
| 18:48 |
sapier |
heap |
| 18:48 |
sapier |
stack is always cleared but not heap |
| 18:59 |
sapier |
hmm no I don't like hacks ... that 1.5 is too ugly I'm gonna spend the time for a real fix |
| 19:02 |
|
OldCoder joined #minetest-dev |
| 19:02 |
|
nore joined #minetest-dev |
| 19:03 |
sapier |
argh ... |
| 19:03 |
sapier |
it's not the calculation being broken ... |
| 19:03 |
sapier |
a checkBOX isn't just the text only but a box in front of it .. |
| 19:17 |
sapier |
https://gist.github.com/sapier/b4b3de15c639f16af352 fixes labels as well as vertlabels too |
| 19:17 |
sapier |
any comments? |
| 19:30 |
|
LemonLake joined #minetest-dev |
| 19:30 |
|
nore joined #minetest-dev |
| 19:37 |
|
Fresh_me_ joined #minetest-dev |
| 20:02 |
|
BlockMen joined #minetest-dev |
| 20:16 |
|
ImQ009 joined #minetest-dev |
| 20:30 |
|
proller joined #minetest-dev |
| 20:35 |
RealBadAngel |
sapier, its ok, but its not what i asked for... |
| 20:35 |
sapier |
it's not supposed to be your fix |
| 20:36 |
sapier |
that's the fix for vanessaE's issue only once it's done I'm gonna have a look at your issue ... at least if you could explain to me whats wrong because I haven't really understood it by now |
| 20:37 |
sapier |
I'm gonna push this now and look for your issue right after it |
| 20:40 |
RealBadAngel |
ok |
| 20:41 |
|
smoke_fumus joined #minetest-dev |
| 20:41 |
RealBadAngel |
for tooltip you define rect which is checked later |
| 20:41 |
sapier |
ok pushed now please explain to me what's wrong |
| 20:43 |
RealBadAngel |
after resizing window in mainmenu, rectangles for tooltips do not match elements anymore |
| 20:43 |
RealBadAngel |
they do work without problems ingame |
| 20:44 |
sapier |
well first of all please fix your tooltip patch breaking all mods while I find out whats wrong |
| 20:44 |
RealBadAngel |
lol |
| 20:44 |
RealBadAngel |
show me such mod in the first place |
| 20:44 |
sapier |
mobf |
| 20:45 |
RealBadAngel |
what mobf has to do with imagebuttons? |
| 20:45 |
sapier |
the menu does heavyly use checkboxes for settings and I'm extremely annoyed because I already have 3 different settings menus to match different apis |
| 20:45 |
sapier |
no but checkboxes |
| 20:45 |
sapier |
which you have broken too |
| 20:45 |
|
Piggybear87 joined #minetest-dev |
| 20:46 |
RealBadAngel |
so throw away code for anything but buttons |
| 20:46 |
RealBadAngel |
because any rectangle is wrong |
| 20:46 |
sapier |
you don't have to throw it away why don't you just ADD your code like everyone else?? |
| 20:46 |
RealBadAngel |
ok i will, but its not like 5 seconds |
| 20:47 |
sapier |
ok I'm gonna do it myself if you think its a big issue |
| 20:47 |
RealBadAngel |
and i have to think how the hell im supposed to guess what user gave as parameter |
| 20:47 |
RealBadAngel |
that is about imagebuttons especially |
| 20:48 |
sapier |
of course you can add this for exactly where you need it but thats selfish |
| 20:49 |
RealBadAngel |
its not elements code broken |
| 20:49 |
RealBadAngel |
regenerateGUI is broken for mainemenu |
| 20:49 |
RealBadAngel |
all the elements and rectangles work ingame |
| 20:50 |
RealBadAngel |
imagebuttons defined same way work perfectly ingame, but are broken in mainmenu |
| 20:51 |
RealBadAngel |
try to display item in mainmenu, it will be broken too |
| 20:51 |
|
Piggybear87 joined #minetest-dev |
| 20:54 |
RealBadAngel |
apply my patch and check tooltip for "Bumpmapping" |
| 20:55 |
RealBadAngel |
ive added this one |
| 20:55 |
|
Miner_48er joined #minetest-dev |
| 20:56 |
RealBadAngel |
well, you can try this even without my patch |
| 20:57 |
RealBadAngel |
add tooltip to game buttons |
| 20:57 |
RealBadAngel |
its using imagebuttons |
| 20:58 |
sapier |
no it's not broke you assume local screensize variable provides real screensize thats wrong |
| 20:58 |
sapier |
true it's name is missleading but I told this about 3-5 times now |
| 20:58 |
sapier |
do I understand correct that you did even reorder image button parameters? |
| 20:59 |
RealBadAngel |
ok, i will try that |
| 21:00 |
RealBadAngel |
yes i did but i will make it to be compatible |
| 21:00 |
RealBadAngel |
i mean i will put tooltip at the end |
| 21:00 |
RealBadAngel |
which is ofc wrong, but let it be |
| 21:01 |
RealBadAngel |
i wanted to keep convention, name, label, tooltip |
| 21:01 |
|
tomreyn joined #minetest-dev |
| 21:01 |
|
tomreyn joined #minetest-dev |
| 21:02 |
RealBadAngel |
but propably its easier to have things fucked up in the engine than edit some mod |
| 21:03 |
sapier |
well rba that's what happens if it's not done from begining ... curse of compatibility |
| 21:03 |
RealBadAngel |
fuck it |
| 21:03 |
RealBadAngel |
we will be sorry about that sooner or later |
| 21:04 |
RealBadAngel |
we are all the time anyway |
| 21:04 |
sapier |
but that's the way it is ... it's hard for us true, but do you know how annonying it is for modders to always have to update their mods with each version? |
| 21:05 |
RealBadAngel |
why my mod that uses formspec extremaly heavily is not affected? |
| 21:05 |
RealBadAngel |
but some mod that uses a few boxes is? |
| 21:06 |
RealBadAngel |
now we are makin formspecs even slower |
| 21:06 |
RealBadAngel |
constantly checking elements length, if 5 if 6 or 6 or 8 or maybe 9 |
| 21:07 |
RealBadAngel |
and each combination of above, even in function code |
| 21:07 |
RealBadAngel |
its not compability, its insanity |
| 21:07 |
sapier |
so you're gonna volonteer to update all broken mods? |
| 21:07 |
RealBadAngel |
well, at least im sure i will cut that shit with tables |
| 21:07 |
sapier |
if not stop complaining |
| 21:08 |
RealBadAngel |
you could probably count to a few |
| 21:08 |
RealBadAngel |
with broken mods |
| 21:08 |
sapier |
checkboxes aren't some obscure never used gui elements you're free to change on every release |
| 21:09 |
sapier |
expecially if the only benefit is some more nice parameter order |
| 21:09 |
RealBadAngel |
ok ok, i said i will change that today |
| 21:10 |
sapier |
if we really wanna do things like that lets add some formspec version field and add a second parser ... not sure if you wanna do that much work for a single moved parameter |
| 21:10 |
RealBadAngel |
after that patch i dont wanna work on formspecs anylonger, it just made me sure theyre dead end |
| 21:11 |
sapier |
nothing is more permanent then temporary solutions ;-) |
| 21:11 |
RealBadAngel |
adding more features will make them even more complicated and slower |
| 21:11 |
sapier |
yes |
| 21:12 |
RealBadAngel |
we do have tables |
| 21:12 |
sapier |
and at some point adding new features will be more painfull then rewriting it in total ... that's the point where switch will be realistic |
| 21:12 |
sapier |
of course that point is highly subjective |
| 21:12 |
RealBadAngel |
i feel like im already there |
| 21:13 |
RealBadAngel |
motivated enough to code it |
| 21:13 |
sapier |
well look for some generic gui language used by someone else then as and suggest how to integrate it to minetest |
| 21:15 |
proller |
html |
| 21:16 |
sapier |
well if you're talking about html5 maybe |
| 21:23 |
crazyR |
+1 ^ |
| 21:23 |
crazyR |
sorry had to add my 2 pence worth lol |
| 21:28 |
RealBadAngel |
why the duck using anything else than a simple table? |
| 21:30 |
RealBadAngel |
easy to modify on the lua side, easy to transfer to the engine |
| 21:30 |
RealBadAngel |
on the engine side whole parser thing (almost whole) will become obsolete |
| 21:31 |
RealBadAngel |
and we will just read the table and fill existing structures |
| 21:32 |
RealBadAngel |
also problem of varying number of variables will just not apply there |
| 21:33 |
RealBadAngel |
theres no point in bringin there another language |
| 21:36 |
sapier |
https://gist.github.com/sapier/81453b7c276ec902d2b7 |
| 21:37 |
|
VargaD_ joined #minetest-dev |
| 21:38 |
Megaf_ |
sapier; how do I add this to my fork? https://github.com/minetest/minetest/pull/1359 |
| 21:38 |
sapier |
no matter if it's a table or something else rba you DO define another formspec language on implementing it |
| 21:38 |
sapier |
and that's another proprietary one |
| 21:38 |
sapier |
ah ... you remember me I have to push the rebased version of this one |
| 21:41 |
RealBadAngel |
sapier, ok, push it |
| 21:41 |
sapier |
have you tested it? |
| 21:41 |
sapier |
is your issue fixed? |
| 21:43 |
RealBadAngel |
wait a sec, will test it a bit more |
| 21:44 |
Megaf |
aff, I hate github, it doesnt make sense at all |
| 21:44 |
Megaf |
I created by mistake pull requests to sapier's fork and minetest already |
| 21:44 |
ShadowNinja |
sapier: Your gist has style issues but looks good otherwise. |
| 21:45 |
sapier |
where do I have to fix? |
| 21:45 |
ShadowNinja |
sapier: spaces around binary operators. And maybe use string.empty() instead of string != "". |
| 21:46 |
ShadowNinja |
sapier: You're missing an if in parseButton I think. |
| 21:47 |
sapier |
where? |
| 21:48 |
RealBadAngel |
and it doesnt apply to current sources |
| 21:48 |
ShadowNinja |
sapier: if (!tooltip.empty()) missing before spec.tooltip = tooltip; |
| 21:48 |
sapier |
strange, thought I did base on it |
| 21:48 |
RealBadAngel |
http://pastebin.com/F3ct5sZr |
| 21:49 |
sapier |
ShadowNinja I don't wanna change all usages in there and there are way more then the new ones |
| 21:49 |
ShadowNinja |
sapier: O.K. Either way, but fix the if. |
| 21:49 |
sapier |
ahh ... usuall diff error on copying from console .. sorry |
| 21:49 |
sapier |
what if? |
| 21:49 |
sapier |
I don't see it |
| 21:50 |
sapier |
can you be a little bit more precise? ;-) |
| 21:52 |
ShadowNinja |
sapier: In parseButton it doesn't check if the tooltip is empty before setting it, but it does in other placed. |
| 21:52 |
ShadowNinja |
-d+s |
| 21:52 |
sapier |
hmm is this necessary? |
| 21:53 |
Megaf |
[14:14:15] <sapier> could someone please test this changes https://github.com/minetest/minetest/pull/1359 they provide up to 20% more fps |
| 21:53 |
Megaf |
It wont compile http://paste.debian.net/105724/ |
| 21:54 |
sapier |
oops pushed wron version |
| 21:54 |
sapier |
give me a few minutes to cleanup the tooptip things |
| 21:54 |
Megaf |
ok |
| 21:56 |
sapier |
what about removing those ifs around tooltip comletely |
| 21:56 |
ShadowNinja |
sapier: Also, use simply tostring, or rely on Lua's automatic string conversion, when converting booleans to strings. dump is designed for more complex values and it's output is undefined since it's only for humans to read (normally for debugging). |
| 21:57 |
sapier |
I don't see any lua code in there Shadow |
| 21:57 |
ShadowNinja |
sapier: If the empty string is interpreted as no tooltip just set it directly without a seperate tooltip variable. |
| 21:58 |
ShadowNinja |
sapier: Lua code where? |
| 21:58 |
|
paramat joined #minetest-dev |
| 21:59 |
sapier |
in that diff there ain't lua code |
| 22:00 |
ShadowNinja |
sapier: Also, tbl.X is equivalent to tbl["X"], but shorter and simpler. Why do you use the second format in the mainmenu so much? |
| 22:00 |
ShadowNinja |
sapier: Yes, I know. Did I say there was? |
| 22:00 |
ShadowNinja |
sapier: Oh, not in that patch. |
| 22:00 |
sapier |
then I don't know how it's related to it ;-) |
| 22:01 |
ShadowNinja |
sapier: I was refering to usage of dump() in mainmenu/tab_settings.lua. |
| 22:01 |
ShadowNinja |
I was reviewing a related PR. |
| 22:01 |
sapier |
most likely because I started to use it and kept that style |
| 22:02 |
ShadowNinja |
RealBadAngel: Can you feasably fix https://github.com/minetest/minetest/issues/1388 ? |
| 22:04 |
sapier |
https://gist.github.com/sapier/b4b3de15c639f16af352 ready to merge? |
| 22:06 |
ShadowNinja |
sapier: Can you just do spec.tooltip = parts[4]; instead of using a seperate temporary variable? |
| 22:06 |
sapier |
no |
| 22:06 |
sapier |
parts 4 is optional |
| 22:06 |
sapier |
so it might be a out of bounds access |
| 22:07 |
ShadowNinja |
sapier: I mean in the appropriate if block. |
| 22:08 |
ShadowNinja |
(((parts.size() >= 5) && (parts.size() <= 9)) && (parts.size() != 6)) < Unnecessary grouping. |
| 22:08 |
sapier |
possible but more understandable at least to me |
| 22:09 |
paramat |
hmmmm, please could you look at this pull request for a linear lighting table? https://github.com/minetest/minetest/issues/1362 seems to me there must be good reasons for an exponential table, unfortunately the pull is popular and may be merged soon unless someone who understands lighting better than me explains |
| 22:11 |
ShadowNinja |
paramat: It's a issue, not a pull request. Although it does suggest a very specific code change. |
| 22:11 |
sapier |
https://gist.github.com/sapier/81453b7c276ec902d2b7 now ready to merge? |
| 22:12 |
hmmmm |
the reason for an exponential decay is because minecraft does it |
| 22:12 |
hmmmm |
now, I'll agree that lights are too dark |
| 22:12 |
hmmmm |
but that's because the range of light is so limited |
| 22:12 |
hmmmm |
because there are only 4 bits for lighting |
| 22:12 |
ShadowNinja |
sapier: Line 91, you still create the variable but don't use it. |
| 22:13 |
ShadowNinja |
sapier: And in other places. Otherwise it's fine. |
| 22:13 |
sapier |
could someone enable unused variable warnings? :-) |
| 22:14 |
hmmmm |
I think it could be worthwhile trying to remove the day night ratio, add 4 bits to the light values, and make day/night happen with hardware lighting |
| 22:14 |
hmmmm |
scene lighting |
| 22:14 |
hmmmm |
having hardware lighting for light source nodes isn't even entirely necessary |
| 22:15 |
hmmmm |
but, I think we discussed how we would do it if we wanted light source nodes to use scene lighting, by dynamically calculating lightmaps |
| 22:15 |
hmmmm |
which could be done alongside the mesh gen |
| 22:16 |
hmmmm |
adding 4 bits to light would be a decent step toward the greater goal of removing node lighting information |
| 22:20 |
|
asl joined #minetest-dev |
| 22:22 |
sapier |
I'm pushing the tooltip fix now |
| 22:24 |
|
BlockMen left #minetest-dev |
| 22:27 |
|
Fresh_me_ joined #minetest-dev |
| 22:45 |
sapier |
https://github.com/minetest/minetest/pull/1359 pushed a rebased version |
| 22:47 |
paramat |
thanks, seems to me linear table would produce a different attenuation of light around light sources of different levels, exponential makes a consistent drop from node to node. i sensed a disturbance in the force, seems linear would break so much other stuff. oops yes it is an issue :) |
| 22:48 |
|
VanessaE joined #minetest-dev |
| 23:06 |
paramat |
hmmmm, there are now 3 voxelmanip floatland mods, 2 by me, and HeroOfTheWinds is working on large undergrond caverns, so i feel indev mapgen (and math mapgen) can now be removed. BTW here's my new mapgen https://forum.minetest.net/viewtopic.php?f=9&t=9296 |
| 23:07 |
proller |
+1 for removing indev and math |
| 23:08 |
sapier |
is a lua based mapgen already fast enough? |
| 23:14 |
paramat |
my simple floatland mods are 2 sec per chunk non luaJIT, probably a little slow for a server. however i think hmmmmm is planning a core 'aether' type mod |
| 23:14 |
paramat |
(not mod, mapgen) |
| 23:35 |
|
sapier left #minetest-dev |
| 23:48 |
|
iqualfragile joined #minetest-dev |
