Time |
Nick |
Message |
00:08 |
PilzAdam |
~ tell sapier your new chat menu double-posts when clicking the button to send |
00:08 |
ShadowBot |
PilzAdam: O.K. |
00:11 |
VanessaE |
well that explains that. |
00:24 |
|
iqualfragile joined #minetest-dev |
00:41 |
|
Fresh_me_ joined #minetest-dev |
01:36 |
ShadowNinja |
PilzAdam: Hey! I found that bug! ;-) I told him but haven't received a response. |
01:39 |
|
domtron joined #minetest-dev |
02:25 |
|
spillz joined #minetest-dev |
02:26 |
spillz |
!tell sapier placing blocks still unresponsive in latest apk (dig works) |
02:26 |
ShadowBot |
spillz: O.K. |
06:10 |
|
PenguinDad joined #minetest-dev |
06:21 |
|
khonkhortisan joined #minetest-dev |
06:24 |
|
proller joined #minetest-dev |
06:35 |
|
grrk-bzzt joined #minetest-dev |
06:42 |
|
diemartin joined #minetest-dev |
06:56 |
|
alexxs joined #minetest-dev |
07:03 |
|
smoke_fumus joined #minetest-dev |
07:15 |
|
salamanderrake joined #minetest-dev |
08:35 |
|
Anchakor_ joined #minetest-dev |
08:55 |
|
Anchakor_ joined #minetest-dev |
08:59 |
|
ImQ009 joined #minetest-dev |
09:08 |
|
sapier joined #minetest-dev |
09:28 |
|
Jordach joined #minetest-dev |
09:37 |
sapier |
http://animalsmod.comuf.com/downloads/Minetest-debug_variant1.apk http://animalsmod.comuf.com/downloads/Minetest-debug_variant2.apk ... opinions about the crunch button? I prefere the variant where button is next to jump |
09:44 |
|
CheapSeth joined #minetest-dev |
10:33 |
|
ShadowBot` joined #minetest-dev |
10:45 |
|
Calinou joined #minetest-dev |
10:56 |
|
Saunterer joined #minetest-dev |
11:57 |
|
Zeitgeist_ joined #minetest-dev |
12:20 |
|
tomreyn joined #minetest-dev |
12:34 |
|
RealBadAngel joined #minetest-dev |
12:38 |
|
rsiska joined #minetest-dev |
12:53 |
|
EvergreenTree joined #minetest-dev |
12:56 |
|
nore joined #minetest-dev |
13:24 |
|
PilzAdam joined #minetest-dev |
14:01 |
|
lanxu joined #minetest-dev |
14:01 |
|
celeron55 joined #minetest-dev |
14:04 |
|
Jordach joined #minetest-dev |
14:06 |
|
yno joined #minetest-dev |
14:06 |
|
Jordach joined #minetest-dev |
14:07 |
|
GhostDoge joined #minetest-dev |
14:10 |
sapier |
Any opinion about adding a style rule member functions of a class only used by the class itself HAVE TO BE private? I thought this is common sense. |
14:11 |
proller |
what if in next day you want to use this function outside? |
14:11 |
proller |
same with variables |
14:12 |
sapier |
I've never read a more silly question proller, if you want to use it outside you're changeing code anyway so you can make it public too |
14:13 |
proller |
but its wrong with variables |
14:13 |
sapier |
but if you wanna use a private function you should think about that twice as those functions shouldn't be touched from outside |
14:13 |
proller |
you must delete m_ from name |
14:13 |
sapier |
no it isn't it's very bad style to manipulate class internal variables without telling the class about it |
14:13 |
proller |
or make stipid accessors |
14:13 |
RealBadAngel |
hi |
14:13 |
RealBadAngel |
http://pastebin.com/j13pWmCB |
14:14 |
RealBadAngel |
^^ united node shader thx to core changes i made |
14:14 |
RealBadAngel |
vertex one ofc |
14:15 |
sapier |
using class variables form outside is allways something to avoid |
14:15 |
proller |
again your imagined world 8( |
14:15 |
sapier |
if a class is a storage class only you're right proller but those should be pod stucts anyway |
14:17 |
sapier |
e.g. hud ... hud class is responsible for drawing all the hud elements on screen, it's got lots of own code doing things with it's member variables ... the specialized draw functions shouldn't ever be called from outside |
14:17 |
sapier |
as well as it's crap do calculate displaycenter and changed screen size from outside and then tell hud to check if the value you just suplied has changed |
14:18 |
sapier |
a clean way would be telling hud about current screen size and let it decide itself if something has to be done |
14:19 |
sapier |
why I'm at hud right now? because hud needs to deal with different screen dpi's on android ... which is impossible if everyone messes around with it's internal variables |
14:19 |
RealBadAngel |
HUD shouldnt be even aware of current display size |
14:20 |
sapier |
as I said it has to be aware to handle different dpi's |
14:20 |
Exio4 |
looks like OOP problems |
14:20 |
sapier |
unless you wanna define another class beeing aware of screen and dpi which is gonna tell hud about it's element size |
14:20 |
RealBadAngel |
it should work on arbitral coords which should be recalculated to actual screen proportions |
14:21 |
sapier |
and how do you wanna recalculate without knowing ? ;-) |
14:22 |
RealBadAngel |
knowing in sense of makin something, anything inside of HUD code depending on resolution |
14:23 |
sapier |
true, for time beeing I just wanna fix builtin hud elements, lua based ones can be handled afterwards |
14:24 |
RealBadAngel |
hud coords to screen coords shall be last step and without any dirty tricks |
14:24 |
sapier |
as far as I remember lua elements are specified with absolute coords ... which is silly but it's done this way right now |
14:24 |
RealBadAngel |
so rescaling window shall effect with same positions for all the elements |
14:24 |
RealBadAngel |
now its fucked up |
14:25 |
|
hmmmm joined #minetest-dev |
14:25 |
RealBadAngel |
hi hmmmm |
14:25 |
RealBadAngel |
hmmmm, take a look: http://pastebin.com/j13pWmCB |
14:25 |
sapier |
we cannot scale gui elements same way as images |
14:25 |
sapier |
that's plain impossible in irrlicht |
14:25 |
RealBadAngel |
we can scale bounding boxes |
14:26 |
RealBadAngel |
and then fit elements in there |
14:26 |
sapier |
it's not very helpfull if it's working for some elements but not for others |
14:26 |
RealBadAngel |
it has to work for all of them |
14:26 |
sapier |
and btw we don't even wanna scale in all situations |
14:27 |
RealBadAngel |
1:1 is also a scaling |
14:27 |
sapier |
no it's not 1:1 in any case |
14:28 |
sapier |
sometimes we wanna scale sometimes not |
14:28 |
sapier |
it's dependent on dpi AND screensize |
14:28 |
RealBadAngel |
lemme rephrase it. i want same coords system for all the elements |
14:28 |
RealBadAngel |
now, even labels and textfields have different ones |
14:28 |
RealBadAngel |
its insane |
14:28 |
sapier |
you can add this in a second step as I don't wanna rewrite whole hud right now |
14:29 |
sapier |
that's rewriting formspec too which I wont do for sure anytime soon |
14:29 |
RealBadAngel |
SN wants |
14:29 |
RealBadAngel |
with tables instead of strings |
14:29 |
sapier |
it'd be great if this was true but it's not done this way and fixing it breaks anything |
14:30 |
sapier |
-any + every |
14:30 |
hmmmm |
that is one concern i have with my own universal formspec idea - it'd break compatibility with older clients |
14:30 |
sapier |
you'll have to fix mainmenu ingame menus, any mod around |
14:30 |
RealBadAngel |
sometimes you have to trash everything in order to get things done in a good way |
14:31 |
hmmmm |
btw guys did i tell you about the universal formspec idea |
14:31 |
sapier |
well you're free to do so but it's not what I'm gonna do |
14:31 |
hmmmm |
formspecs are represented in memory by a set of objects, at the language level |
14:31 |
hmmmm |
everything else - the stupid string format, lua tables, even json - are just serialized forms of this internal representation |
14:31 |
RealBadAngel |
sapier, i wont touch that code, i have enough work on gfx ;) |
14:32 |
hmmmm |
over the wire it'll get seralized to json probably |
14:32 |
hmmmm |
yea? no? |
14:32 |
sapier |
where's the benefit hmmmm? |
14:32 |
hmmmm |
the idea is that you should be able to specify formspec in any sort of key value structure |
14:32 |
hmmmm |
sapier, extreme flexibility. |
14:33 |
sapier |
for what I understood you just add another layer of indirection |
14:33 |
hmmmm |
there are some new features we'd like in formspecs that you can't really encode in that dumb unflexible string format |
14:33 |
sapier |
another proprietary gui specification language different but not better then formspec |
14:34 |
hmmmm |
and you'd be able to make an "open" gui specification language frontend to this as well if you'd like |
14:34 |
sapier |
why not implement a rendering engine for some already existing gui language? |
14:34 |
hmmmm |
why implement a rendering engine in the first place |
14:34 |
sapier |
yes that's a lot of work but it's gonna be same for your language if it's supposed to be as flexible as the existing ones |
14:34 |
hmmmm |
this entire thing is so fubar |
14:35 |
RealBadAngel |
guys, UnifiedInventory is pretty complex example of usage of formspec |
14:35 |
sapier |
you're always free to do what you like hmmmm but I'm not sure if this is worth it ... my own opinion is it's not but this is something everyone has to decide himself |
14:35 |
RealBadAngel |
even strings handled smart can do miracles |
14:36 |
sapier |
yes formspec is already quite flexible, I've written mainmenu I trust me ;-) |
14:36 |
hmmmm |
i disagree because my idea encompasses everybody elses' |
14:36 |
hmmmm |
it's a strict enhancement |
14:36 |
hmmmm |
people are free to use whichever frontend language they'd like to specify the gui |
14:36 |
hmmmm |
sure it might be a little bit more effort but |
14:36 |
sapier |
no hmmmm it's about half a year of work without guarantee to be better |
14:36 |
hmmmm |
it's like mainmenu |
14:36 |
hmmmm |
half a year !? i don't estimate that long at all |
14:37 |
RealBadAngel |
heheh |
14:37 |
sapier |
:-) I thought mainmenu is just a few weeks too |
14:37 |
RealBadAngel |
hmmm, just code it |
14:37 |
hmmmm |
yeah but i' malready working on something completely different |
14:37 |
RealBadAngel |
so make a pause to code it |
14:37 |
hmmmm |
map overgeneration will solve more problems than just biomes |
14:37 |
sapier |
so no need to discuss about things noone has time to implement ;) |
14:38 |
hmmmm |
and it'll pave the way for finishing mapgen v7 |
14:38 |
RealBadAngel |
im doing same things with shaders, when i need a pause i code something else |
14:38 |
RealBadAngel |
just to refresh my mind |
14:39 |
sapier |
I wanna finish android port so I can push the final parts of my network fixes ... after this is done and (most) bugs are removed I'm gonna look for mobf again .. :-) then it's most likely end of year |
14:39 |
RealBadAngel |
have you two read the vertex shader code i pastebined earlier? |
14:40 |
hmmmm |
yeah |
14:40 |
RealBadAngel |
i do have now complete control over the shaders :) |
14:40 |
hmmmm |
it looks like shader code |
14:41 |
hmmmm |
did you want me to look for anything in particular? |
14:41 |
RealBadAngel |
you should notice one thing: its a node shader, one for all |
14:42 |
RealBadAngel |
one code, many instaces |
14:42 |
RealBadAngel |
no more copy pasta :) |
14:43 |
sapier |
great! :-) |
14:43 |
hmmmm |
i just had pasta last night |
14:43 |
RealBadAngel |
remember that taste, it wont happen again ;) |
14:44 |
hmmmm |
i thought it was pretty tasty |
14:44 |
RealBadAngel |
hmmm, have you tried playin with generated normals? |
14:44 |
hmmmm |
no.. |
14:44 |
hmmmm |
i never did any graphics related things aside from the alpha shader |
14:45 |
RealBadAngel |
just try it |
14:45 |
RealBadAngel |
game with even default 16x textures looks like from another century |
14:46 |
RealBadAngel |
im fuckin proud of the final effect |
15:01 |
|
Zeitgeist_ joined #minetest-dev |
15:03 |
|
alexxs joined #minetest-dev |
15:04 |
|
EvergreenTree joined #minetest-dev |
16:32 |
|
NakedFury joined #minetest-dev |
17:01 |
|
Calinou joined #minetest-dev |
17:13 |
nore |
can I push that commit? https://github.com/Novatux/minetest/commit/859fd3102f55bc7cf1d3fdc18d8c1977562af748 |
17:15 |
sapier |
seems to be fine ... nore can you try to fix the digging in my android branch? I don't have an idea how to adapt it to your offset changes |
17:15 |
nore |
sapier, do you have a link to the relevant code please? |
17:18 |
sapier |
https://github.com/sapier/minetest/blob/android_3/src/touchscreengui.cpp L 471 ... this did give a valid shootine before but now it doesn't seem to match the offseted one. It's used at game.cpp L 2715 ... the way I tried to fix it there doesn't work |
17:24 |
nore |
how do you change a shootline? |
17:25 |
nore |
btw: how do we do when there are license violations? |
17:25 |
nore |
s/how/what |
17:26 |
|
EvergreenTree joined #minetest-dev |
17:26 |
|
PenguinDad joined #minetest-dev |
17:28 |
nore |
sapier, could you try shootline.start += intToFloat(camara_offset, BS), and same with shootline.end? |
18:07 |
celeron55 |
what about we add a page on either the main site or the wiki that very shortly describes the history of minetest and then explains all the versions out there |
18:08 |
celeron55 |
it would be handy to link such a one to people that are wondering about updating a 0.3.1 or aren't satisfied with the 0.4 series or whatever |
18:11 |
celeron55 |
like "development of 0.3 was ended on <date> and now we have 0.4 which your linux distro might not have in it's repository; you should do this and that to get it; alternatively there is minetest-classic and freeminer that attempt to do things X and Y" |
18:11 |
celeron55 |
(with better structure and a bit more information than on that line) |
18:12 |
celeron55 |
something that would answer and come up as the first result for the google search "minetest versions" |
18:13 |
celeron55 |
i guess i'll do it if nobody is interested; i wonder on what site it should be in |
18:22 |
|
e1z0 joined #minetest-dev |
18:33 |
|
e1z0 joined #minetest-dev |
18:53 |
|
rubenwardy joined #minetest-dev |
19:56 |
|
werwerwer_ joined #minetest-dev |
19:59 |
|
kaeza joined #minetest-dev |
20:25 |
|
PenguinDad joined #minetest-dev |
20:42 |
|
EvergreenTree joined #minetest-dev |
20:54 |
|
grrk-bzzt joined #minetest-dev |
21:00 |
|
domtron joined #minetest-dev |
21:05 |
|
CheapSeth joined #minetest-dev |
21:37 |
|
Amaz joined #minetest-dev |
21:38 |
|
PenguinDad joined #minetest-dev |
21:47 |
|
hax404 joined #minetest-dev |
22:24 |
|
Amaz joined #minetest-dev |
22:47 |
|
casimir joined #minetest-dev |
23:08 |
|
EvergreenTree joined #minetest-dev |
23:21 |
|
rsiska joined #minetest-dev |
23:52 |
|
sapier joined #minetest-dev |