| Time |
Nick |
Message |
| 00:04 |
|
rambomedic joined #minetest-dev |
| 00:37 |
|
SmugLeaf joined #minetest-dev |
| 00:54 |
|
sapier left #minetest-dev |
| 01:01 |
|
Taoki joined #minetest-dev |
| 01:05 |
|
Shardvexz joined #minetest-dev |
| 01:15 |
|
BrandonReese joined #minetest-dev |
| 01:20 |
|
SmugLeaf joined #minetest-dev |
| 01:21 |
|
darkrose joined #minetest-dev |
| 01:26 |
|
kaeza joined #minetest-dev |
| 01:56 |
|
diemartin joined #minetest-dev |
| 03:17 |
|
SmugLeaf joined #minetest-dev |
| 03:43 |
|
kaeza joined #minetest-dev |
| 03:49 |
|
CraigyDavi joined #minetest-dev |
| 03:54 |
|
CraigyDavi_ joined #minetest-dev |
| 05:11 |
|
CraigyDavi joined #minetest-dev |
| 05:21 |
|
ImQ009 joined #minetest-dev |
| 06:17 |
|
nore joined #minetest-dev |
| 07:35 |
|
Calinou joined #minetest-dev |
| 07:44 |
|
PenguinDad joined #minetest-dev |
| 07:48 |
|
restcoser joined #minetest-dev |
| 08:03 |
|
ImQ009 joined #minetest-dev |
| 08:15 |
|
loggingbot_ joined #minetest-dev |
| 08:15 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 09:11 |
|
jin_xi joined #minetest-dev |
| 09:17 |
|
sapier joined #minetest-dev |
| 09:41 |
|
psedlak joined #minetest-dev |
| 09:42 |
|
proller joined #minetest-dev |
| 09:47 |
|
darkrose joined #minetest-dev |
| 09:54 |
|
john_minetest joined #minetest-dev |
| 11:26 |
|
PenguinDad joined #minetest-dev |
| 11:41 |
sapier |
did anyone experience strange crafting behaviour lately? |
| 11:42 |
|
Zeitgeist_ joined #minetest-dev |
| 11:42 |
|
Zeitgeist_ joined #minetest-dev |
| 11:42 |
sapier |
e.g. craft view not beeing updated, right click resulting in whole stack being placed, or complete stack beeing moved |
| 11:43 |
|
Eater4 joined #minetest-dev |
| 11:43 |
|
[PavelS] joined #minetest-dev |
| 11:45 |
|
iqualfragile joined #minetest-dev |
| 11:50 |
|
jin_xi joined #minetest-dev |
| 12:06 |
jin_xi |
if you have no mods and doublecklick on the empty mods lists first entry in the world->configure menu modmgr.lua attemts to index local 'mod' (a nil value) |
| 12:07 |
|
proller joined #minetest-dev |
| 12:11 |
|
PilzAdam joined #minetest-dev |
| 12:20 |
|
Jordach joined #minetest-dev |
| 12:56 |
sapier |
jin_xi I'm gonna fix it in mainmenu cleanup patch oo |
| 13:17 |
|
RealBadAngel joined #minetest-dev |
| 13:25 |
|
PilzAdam joined #minetest-dev |
| 15:01 |
|
Calinou joined #minetest-dev |
| 15:02 |
|
hmmmm joined #minetest-dev |
| 15:04 |
|
restcoser joined #minetest-dev |
| 16:05 |
|
OldCoder joined #minetest-dev |
| 16:08 |
|
Jordach joined #minetest-dev |
| 16:11 |
Calinou |
in mgv6, how easy would it be to add snow biomes, in addition to the deserts? |
| 16:11 |
sfan5 |
in C++? |
| 16:13 |
Calinou |
yes :) |
| 16:14 |
Calinou |
I'd like to see such a thing, that's why I'm asking :P |
| 16:15 |
sfan5 |
not that hard |
| 16:21 |
hmmmm |
mapgen v6 is not to be modified in any way such that its output is changed |
| 16:21 |
hmmmm |
if you want to change mapgen v6, put it in indev |
| 16:22 |
hmmmm |
anyway I have plans to backport the biome thing to v6 eventually |
| 16:22 |
hmmmm |
sfan5, your mapgen v5 branch uses mapgen v6 from version 4.2 |
| 16:22 |
hmmmm |
0.4.2 |
| 16:22 |
hmmmm |
mapgen v5 is from 0.3.0 |
| 16:24 |
|
kaeza joined #minetest-dev |
| 16:26 |
sfan5 |
hmmmm: yes, celeron55 already told me |
| 16:34 |
|
kaeza joined #minetest-dev |
| 16:38 |
Calinou |
probably a bug: if you set a smaller visual scale to an entity, and a player is attached to it, the player model scale changes |
| 16:38 |
Calinou |
<hmmmm> mapgen v6 is not to be modified in any way such that its output is changed |
| 16:38 |
Calinou |
why? |
| 16:41 |
sapier |
isn't mapgenv6 frozen as it's stable? |
| 16:42 |
Calinou |
makes no sense |
| 16:43 |
sapier |
why not? hmmmm is working on v7 so unless there's a major bug why change v6 and cause broken maps? |
| 16:44 |
Calinou |
v7 is not finished yet and few people use it |
| 16:44 |
Calinou |
isn't it the goal to have multiple mapgens? even v5 |
| 16:45 |
|
BlockMen joined #minetest-dev |
| 16:53 |
hmmmm |
calinou, stable mapgens are NOT to be modified |
| 16:53 |
hmmmm |
that's something that minetest of old and minecraft do |
| 16:53 |
|
Shardvexz joined #minetest-dev |
| 16:54 |
hmmmm |
they happily break compatibility or create inconsistencies with maps created with the SAME mapgen from older versions |
| 16:54 |
hmmmm |
this is something that MINETEST DOES NOT DO |
| 16:54 |
hmmmm |
if you want to go break peoples' maps, please seek a job at Mojang |
| 16:54 |
PenguinDad |
john_minetest: it's not fixed yet |
| 17:07 |
Calinou |
most people don't have an aversion against map breaking |
| 17:07 |
Calinou |
it's not a life |
| 17:17 |
|
EvergreenTree joined #minetest-dev |
| 17:18 |
|
EvergreenTree joined #minetest-dev |
| 18:04 |
|
cg72 joined #minetest-dev |
| 18:39 |
* VanessaE |
pokes hmmmm with #1270 |
| 18:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/1270 -- Impossible "Invalid block data" situation in a map |
| 18:42 |
|
BrandonReese joined #minetest-dev |
| 18:54 |
|
werwerwer joined #minetest-dev |
| 19:00 |
RealBadAngel |
i agree with Calinou, breakin a map or server for sake of having better one is not an issue |
| 19:01 |
RealBadAngel |
mankind evolves that way all the time |
| 19:07 |
|
john_minetest left #minetest-dev |
| 19:16 |
VanessaE |
I wouldn't call having an optional setting "breaking" the map. Why do these snow biomes have to be forced-on? Why can't they be enabled by default only for NEW maps but disabled for existing maps (unless the admin goes in and adds some flag to map_meta.txt). As long as such a biome uses perlin settings compatible with SPlizard's snow biomes mod and/or paramat's snowdrift or can be made to do so, what's the issue then? |
| 19:20 |
VanessaE |
(obviously the use of perlin settings compatible with those mods would only be needed for maps that use those mods so that they become less necessary) |
| 19:21 |
BlockMen |
RealBadAngel, the mankind is a bad example. see how nobody has learned from two world wars last 100 years |
| 19:23 |
BlockMen |
and what would break the maps? |
| 19:37 |
VanessaE |
BlockMen: mapblocks that suddenly go from e.g. grass to a frigid snow biome |
| 19:38 |
VanessaE |
because snow was added after that grass was generated but before the neighboring mapblocks were |
| 19:38 |
VanessaE |
(for example) |
| 19:38 |
VanessaE |
same thing happens when you add e.g. SPlizard's snow biomes mod to an existing map |
| 19:39 |
VanessaE |
which is why you have to use it with paramat's snowdrift mod so that old map areas will gradually transform. |
| 19:43 |
BlockMen |
VanessaE, ic. thx |
| 19:43 |
BlockMen |
and hmmm does not change that because a changed mapgen would break maps? |
| 19:43 |
BlockMen |
or did i got that wrong? |
| 19:44 |
VanessaE |
that's the theory, or certainly the truth if such a biome were enabled by default in all cases. |
| 19:44 |
VanessaE |
(hence my above suggestion) |
| 19:45 |
GhostDoge |
maybe a mg_flag for it? |
| 19:45 |
VanessaE |
honestly though, mgv6 is so entrenched that mgv7 really has no chance unless it can be made to be 100% compatible with maps generated under v6 |
| 19:45 |
VanessaE |
GhostDoge: see above. |
| 19:46 |
BlockMen |
well, i like your suggestion that it only applies on new maps |
| 19:58 |
RealBadAngel |
BlockMen, evolution is about breakin everything and replacing with better solutions |
| 19:59 |
RealBadAngel |
and mandkind is rather best example of it |
| 20:00 |
RealBadAngel |
and faster the changes are applied, further it goes |
| 20:00 |
BlockMen |
no, evolution is the "win" of something in a special setting |
| 20:00 |
BlockMen |
if the setting changed the "best" is really fast gone |
| 20:00 |
RealBadAngel |
ask your grandpa how he played minetest |
| 20:00 |
BlockMen |
development is not always a pro |
| 20:01 |
RealBadAngel |
in the first place he will say but we havent got any computers.... |
| 20:01 |
RealBadAngel |
and btw |
| 20:02 |
RealBadAngel |
war makes progress even faster |
| 20:02 |
BlockMen |
RealBadAngel, so you want war for faster "progress"? |
| 20:02 |
BlockMen |
great... |
| 20:03 |
RealBadAngel |
lol no |
| 20:03 |
RealBadAngel |
i just commented out facts |
| 20:03 |
BlockMen |
another fact: without the fast technical development the world was would never been possible |
| 20:03 |
BlockMen |
*world war |
| 20:04 |
BlockMen |
at least not with that many million dead |
| 20:05 |
sapier |
discussions about world wars please in minetest ;-) |
| 20:05 |
RealBadAngel |
no, wars are started for simpler reasons |
| 20:06 |
BlockMen |
its about technical development, so #-dev is fine :P |
| 20:06 |
BlockMen |
sapier, https://github.com/minetest/minetest/pull/1265#issuecomment-42142461 |
| 20:06 |
RealBadAngel |
but when theyre started, sides are lookin for solutions to take advantage |
| 20:06 |
VanessaE |
ANYWAY |
| 20:06 |
RealBadAngel |
and there comes development |
| 20:07 |
sapier |
what's the issue Blockmen? |
| 20:07 |
BlockMen |
look at the image again, sapier |
| 20:07 |
sapier |
and? |
| 20:07 |
BlockMen |
the bar moves upwards? |
| 20:08 |
sapier |
because of relative alignment |
| 20:08 |
BlockMen |
the c++ bars do not, and that is the correct bahavior |
| 20:08 |
sapier |
you can't have fixed and relative alignment same time |
| 20:08 |
BlockMen |
furthermore is listed three issues |
| 20:08 |
BlockMen |
s/is/i have |
| 20:09 |
sapier |
and you can't hide the current ones too can you ? |
| 20:09 |
BlockMen |
and have you tried this with 1920x res? it is just crap to position statbars that way |
| 20:09 |
BlockMen |
sapier, yes you can |
| 20:09 |
sapier |
how? |
| 20:09 |
BlockMen |
with flags? |
| 20:10 |
BlockMen |
they only change c++ statbars |
| 20:10 |
sapier |
I'll find out how to check them |
| 20:10 |
BlockMen |
no, dont |
| 20:10 |
BlockMen |
just move it to default |
| 20:10 |
BlockMen |
and fix the offset stuff |
| 20:11 |
sapier |
offset isn't a trivial fix |
| 20:11 |
BlockMen |
no fix no switch (IMO) |
| 20:11 |
sapier |
btw why is this a issue it's been same for food without any complains by now |
| 20:12 |
BlockMen |
for food? what are you talking about? |
| 20:12 |
sapier |
ok I'm gonna fix it for builtin only |
| 20:12 |
sapier |
well you've got your food mod you never complained about it's relative position and now as I fix other issues you add an additional requirement |
| 20:12 |
BlockMen |
sapier, no. thats wrong way. then you have always offset for hunger and health bars |
| 20:13 |
BlockMen |
and i complained https://forum.minetest.net/viewtopic.php?p=137678#p137678 |
| 20:13 |
BlockMen |
but i had not the intension to remove c++ stat bars |
| 20:13 |
BlockMen |
so it was no need to set it in a prior position |
| 20:14 |
sapier |
still there's no really sane way to fix it you can't mix up absolute and relative positioning for a generic solution |
| 20:15 |
sapier |
the only way to do it that way is creating a specialized hud element (2stat+1itembar) but that's exactly what we want to get rid of |
| 20:15 |
BlockMen |
sapier, a flag like "sticky = true" maybe? |
| 20:15 |
VanessaE |
sapier: I told you so. |
| 20:15 |
sapier |
sticky to what? |
| 20:15 |
BlockMen |
to hotbar |
| 20:15 |
sapier |
lol |
| 20:15 |
sapier |
that's crap |
| 20:16 |
BlockMen |
no, thats the only way to mess not up the statbars with different res |
| 20:16 |
sapier |
why not sticky to upper left corner |
| 20:16 |
BlockMen |
or show a better solution |
| 20:16 |
sapier |
or sticky to 10,10 |
| 20:16 |
VanessaE |
sapier: the fucking statbars and hotbar NEED TO SCALE TO THE WINDOW SIZE |
| 20:16 |
sapier |
pixels of course |
| 20:16 |
VanessaE |
(on PCs) |
| 20:16 |
sapier |
wtf you wanted it to be ecactly 16 px |
| 20:16 |
sapier |
and it will scale according to celerons (crazy) scaling factor |
| 20:16 |
BlockMen |
sapier, no offense, but design is not your profession |
| 20:17 |
VanessaE |
sapier: I wanted it to be 16px in lieu of a better design since you were opposed to a better design :P |
| 20:17 |
VanessaE |
a better design has those statbars being about 2x their size as shown in BlockMen's screenshot, roughly. |
| 20:17 |
VanessaE |
and scaled smoothly with the window size |
| 20:18 |
sapier |
guys don't thart this shit discussion again once I'm doing it as it was before you tell me you want it different if I'm doing it different you want it same as before no matter how crazy this is |
| 20:18 |
sapier |
I'll fix the hiding issue and maybe the offsets but I'm not gonna add scaling beyond the way it was before forget about it |
| 20:18 |
VanessaE |
why not? |
| 20:18 |
VanessaE |
it looks like shit |
| 20:19 |
sapier |
because YOU wanted it to look that way don't tell me now that you can see what you requested to change it back |
| 20:19 |
VanessaE |
that statbar definitely doesn't follow the hotbar's scale (if it did, it'd be almost 2x the size shown in the screenshot) |
| 20:19 |
sapier |
it still follows hotbar scale |
| 20:19 |
VanessaE |
[05-04 16:16] <sapier> and it will scale according to celerons (crazy) scaling factor <------ no, it doesn't. |
| 20:20 |
celeron55 |
if someone is asking via email to participate in development with C++ and blender background with a fairly crappy message, should i give any pointers? |
| 20:20 |
sapier |
then it's a bug but it's only two scaling levels so you probably don't notice |
| 20:20 |
BlockMen |
VanessaE, on my screenshot is a lua statbar (IDK if that matters) |
| 20:20 |
celeron55 |
i'd guess clever enough people will figure out not to ask me |
| 20:20 |
khonkhortisan |
direct them to the bug list? |
| 20:20 |
VanessaE |
BlockMen: whether it is or not, it's too damned small |
| 20:21 |
VanessaE |
celeron55: and direct them to speak with Taoki and Jordach, I think. |
| 20:21 |
sapier |
are those the original statbars or your own ones? |
| 20:21 |
Jordach |
? |
| 20:21 |
sapier |
BlockMen: ? |
| 20:22 |
BlockMen |
these are lua statbars and behave like your builtin one (except that it doesnt move kilometers left on higher resolution), sapier |
| 20:22 |
celeron55 |
i'll answer with these links https://forum.minetest.net/viewtopic.php?f=7&t=175 https://forum.minetest.net/viewtopic.php?f=7&t=9177 |
| 20:22 |
VanessaE |
BlockMen, sapier, I just checked my local copy of minetest_game and my default HUD statbar is consistent with Blockmen's. |
| 20:22 |
VanessaE |
well ALMOST consistent. |
| 20:23 |
sapier |
almost is different from consistent |
| 20:23 |
VanessaE |
which means either it doesn't scale properly, or Blockmen's statbar is busted in some other way, because my statbars are slightly larger relative to my hotbar, at 1600x1200 than his are on his 1920x1080 screenshot. |
| 20:24 |
sapier |
then he didn't read the error message telling him about using deprecated api |
| 20:24 |
VanessaE |
no, strike that |
| 20:24 |
BlockMen |
lua statbars shouldnt scale different than the c++ does |
| 20:24 |
VanessaE |
they don't scale AT ALL |
| 20:24 |
BlockMen |
i had no error msg |
| 20:24 |
VanessaE |
they don't change size between the default window size of 800x600 and maximized to 1600x1200. |
| 20:24 |
sapier |
BlockMen: did debug or release build? |
| 20:24 |
BlockMen |
release |
| 20:25 |
BlockMen |
debug under MSVC is a pain |
| 20:25 |
sapier |
ok VanessaE then there's a bug they should change exactly once |
| 20:25 |
VanessaE |
at 800x600, the hearts are just a bit longer than 4 hotbar slots, at 1600x1200, their length is about 3 hotbar slots. |
| 20:25 |
sapier |
in release build all deprecation warnings are disabled by default you should enable them manually |
| 20:25 |
VanessaE |
but the hotbar is definitely larger at 1600x1200 |
| 20:25 |
sapier |
and set to error for developing mods |
| 20:26 |
BlockMen |
VanessaE, yes. the hotbar scales fine |
| 20:27 |
sapier |
so does builtin statbar |
| 20:27 |
VanessaE |
sapier: so scaling of the statbars is busted. :) |
| 20:27 |
VanessaE |
no it does NOT! |
| 20:28 |
BlockMen |
IMO all statbars (wether c++ or lua) should scale like the hotbar. and the statbars should be able to have a hotbar size offset |
| 20:28 |
BlockMen |
then they would finally be useable |
| 20:28 |
sapier |
they do |
| 20:28 |
BlockMen |
no, they are not |
| 20:28 |
sapier |
if you use correct api they do |
| 20:28 |
VanessaE |
sapier: I am comparing the screenshots side-by-side. |
| 20:28 |
VanessaE |
the statbars are IDENTICAL pixel for pixel between 800x600 and 1600x1200. |
| 20:29 |
VanessaE |
and I am using git HEAD of minetest_game and one commit behind on minetest engine. |
| 20:29 |
VanessaE |
default textures. |
| 20:29 |
BlockMen |
and with that pull its the same |
| 20:30 |
BlockMen |
same pixel size |
| 20:30 |
VanessaE |
sapier: http://digitalaudioconcepts.com/vanessa/extra/statbars2.png |
| 20:30 |
BlockMen |
*well, not tested > 1366x |
| 20:30 |
VanessaE |
top one is 800x600 default window, bottom is maximized 1600x1200 |
| 20:31 |
VanessaE |
that's the default HUD statbars present in minetest_game and/or the engine. still think they're being scaled? :P |
| 20:31 |
ShadowNinja |
sapier: Modpacks aren't mods, they're just folders, if fact the modpack.txt requirement could be changed to a "no init.lua" requirement. Their names are irrelevant. They shouldn't be stored for anything other than display in the list. |
| 20:31 |
sapier |
http://de.tinypic.com/r/2mwgjt4/8 |
| 20:31 |
sapier |
that's normal |
| 20:32 |
sapier |
http://de.tinypic.com/r/o8utd4/8 and that's the one and only bigger level supported by celeron |
| 20:33 |
VanessaE |
sapier: G*d damn it look at the screenshot |
| 20:33 |
sapier |
is this my version or current master? |
| 20:33 |
* VanessaE |
fumes |
| 20:33 |
VanessaE |
current master |
| 20:33 |
ShadowNinja |
sapier: I also thought that a main init.lua with a variable passed was better than having duplicate setlocale/print/etc lines in every entrance point's init.lua. |
| 20:33 |
VanessaE |
one commit behind at the moment |
| 20:33 |
sapier |
of course current master isn't fixed VanessaE |
| 20:33 |
ShadowNinja |
*Continues reading backlog* |
| 20:34 |
VanessaE |
well shit why didn't you tell me you were still testing with a modified branch? |
| 20:34 |
sapier |
well we're talking about a pull request VanessaE *smile* |
| 20:37 |
BlockMen |
sapier, http://i.imgur.com/OIVvrlR.png |
| 20:37 |
BlockMen |
ok, scaling seems correct |
| 20:37 |
BlockMen |
still, it should not be in builtin |
| 20:37 |
BlockMen |
just move it to default |
| 20:37 |
BlockMen |
and that offsets are not acceptable |
| 20:38 |
sapier |
ok then let it do RealBadAngel you want things that can't be done in a reasonable way with reasonable abount of work |
| 20:39 |
BlockMen |
im fine if you just fix the scaling with you pull |
| 20:39 |
sapier |
I'm not gona implement a layouting language for hud api and that's the only generic way to get all your requirements |
| 20:39 |
BlockMen |
but then dont remove the c++ one |
| 20:40 |
sapier |
then it's of no use |
| 20:40 |
VanessaE |
sapier: ok now I feel 100% stupid. |
| 20:41 |
sapier |
sorry to waste your time but I can't fix all your requests within a the time I wanna spend for this issue, this has to be done by someone else |
| 20:43 |
VanessaE |
sapier: if I'd realized this were about your pull I'd have shut up sooner :) |
| 20:43 |
sapier |
the only way to do what you want is extending hud api to allow dpi as well as relative positioning of elements with arbitrary origins e.g. having a hud element beeings positioned relative to another |
| 20:44 |
BlockMen |
sapier, or just an option to use hotbar size as offset |
| 20:44 |
BlockMen |
that would solve the issues i mentioned |
| 20:44 |
sapier |
wekk itÄs useless the hud api is fucked up and I don't intend to rewrite it in total to fix a small bug |
| 20:46 |
BlockMen |
furthermore the breath and health events could be useful for other cases |
| 20:46 |
BlockMen |
if you say so...fine. then all stays as it for now |
| 20:46 |
ShadowNinja |
~tell john_minetest No, #802 isn't fixed. It would be trivial to fix though. |
| 20:46 |
ShadowBot |
ShadowNinja: O.K. |
| 20:46 |
sapier |
you can extract it I'm not gonna waste additional time in this topic |
| 20:47 |
ShadowNinja |
PilzAdam: ^ |
| 20:48 |
ShadowNinja |
sapier: I believe RBA and VanessaE have (a) normalmap script(s). |
| 20:48 |
sapier |
I already talked to rba ShadowNinja but thanks |
| 20:48 |
VanessaE |
ShadowNinja: minetest engine, util/ directory |
| 20:49 |
VanessaE |
generate-texture-normals.sh |
| 20:49 |
VanessaE |
needs gimp and gimp normalmap plugin |
| 20:49 |
sapier |
I don't seem to have later one |
| 20:50 |
VanessaE |
https://code.google.com/p/gimp-normalmap/ |
| 20:50 |
VanessaE |
I believe that's the one I use |
| 20:50 |
VanessaE |
(the one in my software repo is broken) |
| 21:12 |
|
ImQ009 joined #minetest-dev |
| 21:12 |
|
EvergreenTree joined #minetest-dev |
| 21:17 |
|
rambomedic joined #minetest-dev |
| 21:29 |
|
rambomedic joined #minetest-dev |
| 21:30 |
|
rdococ joined #minetest-dev |
| 21:42 |
|
OldCoder joined #minetest-dev |
| 21:50 |
|
Jordach joined #minetest-dev |
| 22:36 |
|
Anchakor joined #minetest-dev |
| 22:46 |
|
EvergreenTree joined #minetest-dev |
| 22:53 |
|
sapier joined #minetest-dev |
| 22:54 |
sapier |
BlockMen: #1265 check if disabling hud works as expected ... found a way how to fix the offsets while I almost fell asleep |
| 22:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/1265 -- Fix heart + bubble bar size on different texture packs by sapier |
| 22:54 |
VanessaE |
sapier: what's the change? |
| 22:55 |
sapier |
changeing behaviour of offset to not be a fixed pixel offset but scale to dpi factor |
| 22:55 |
VanessaE |
*looks at commit* |
| 22:55 |
VanessaE |
yes, I see that |
| 22:55 |
VanessaE |
a lot simpler than you expected huh? |
| 22:55 |
sapier |
well it's an additional change to api |
| 22:56 |
sapier |
and will only fix a simple class of alignment tasks |
| 22:56 |
sapier |
as soon as you're slightly away from edge this will not work |
| 22:56 |
VanessaE |
I don't expect it'll get TOO complicated in practice anyway, two or three columns worth of statbars, maybe two or three rows in the worst case |
| 22:57 |
VanessaE |
(that'd be 9 statbars. would anyone have that many?) |
| 22:57 |
sapier |
as long as those rows are directly attached it may work once there's any relative movement between sem you don't have a chance to fix it |
| 22:58 |
BlockMen |
sapier, was working on that aswell (since you closed it) |
| 22:58 |
BlockMen |
but i added a flag "sticky" to allow both |
| 22:59 |
sapier |
so you added a hack to get a even more hacky way of toing it? |
| 22:59 |
sapier |
-t+d |
| 22:59 |
BlockMen |
why hacky? it allows modders to scale offset or not |
| 22:59 |
VanessaE |
sapier: in the tradition of minetest. hacks on top of tweaks on top of kludges :) |
| 22:59 |
sapier |
coud you guys only a single time do something in a clean way? we wouldn't have to discuss for ages if hud would've been done in a sane way from the beginning |
| 23:00 |
sapier |
and how is sticky supposed to work at all can you explain to me? |
| 23:01 |
BlockMen |
if you add "sticky" to definition (of statbar) the offset is scaled aswell, if not it stays at the set pixel value |
| 23:01 |
BlockMen |
idk what is hacky at that |
| 23:01 |
sapier |
scaled to what? |
| 23:03 |
sapier |
guess it's almost same solution except you most likely missed user scale factor ;-) still ... is there any sane reason not to scale to dpi and user scale? |
| 23:03 |
VanessaE |
RealBadAngel: would you please take these messages out of the damn chat area? --> Could not load image "xxxxx_normal.png" while building texture / Creating a dummy image for "xxxxx_normal.png" |
| 23:03 |
sapier |
the image themselfs will still scale no matter what your sticky bit tells |
| 23:04 |
sapier |
unless you stop them from scaling too ... but that is exactly what has ben called the bug this is all about |
| 23:05 |
BlockMen |
"you most likely missed user scale factor", what?? |
| 23:06 |
BlockMen |
and i dont really care, i wanted keep it for backwards compatibility |
| 23:06 |
sapier |
forget about it, just check if enabling disabling works |
| 23:06 |
BlockMen |
and there may be uses for having a pixel precise offset i guess |
| 23:06 |
sapier |
mine is backward compatible too as scaling is only aplied if you use new api |
| 23:07 |
sapier |
and old api is supposed to die as soon as possible ... whenever this will be |
| 23:07 |
sapier |
I don't see how pixel precise offset for non pixel precise images is supposed to work? |
| 23:07 |
BlockMen |
sapier, dont do that with builtin |
| 23:08 |
BlockMen |
why the heck dont you put in in default? |
| 23:08 |
sapier |
it's builtin now and it's gonna be builtin later ... if you wanna change this you can fight for it later I will not change it now |
| 23:09 |
BlockMen |
starbar is c++ now so it will stay c++ |
| 23:09 |
BlockMen |
^ same argumentation |
| 23:09 |
BlockMen |
give me a good reason |
| 23:09 |
sapier |
in case you get an ok from all other core devs I may consider moving it but I will not discuss this topic with another one for you |
| 23:09 |
BlockMen |
you did not even discuss moving it to default |
| 23:10 |
sapier |
you see I don't have any interest in discussing this because I really don't care except of not wanting to discuss about it |
| 23:11 |
sapier |
moving to default will need changes in minetest_game too ...and this is known to be reason to discuss |
| 23:12 |
sapier |
hmm I really don't want to do this work but you're free to do it once it's merged, I wont block it |
| 23:12 |
BlockMen |
sapier, and i havent tested, but i guess it will not work that way. it checks flags only on_leave and on_join |
| 23:12 |
BlockMen |
so you can remove them at any time |
| 23:12 |
BlockMen |
*cant |
| 23:12 |
sapier |
you can as far as I remember init is called for each change |
| 23:14 |
BlockMen |
it is changed every join, health and breath change |
| 23:14 |
BlockMen |
so no, you cant hide them every time |
| 23:14 |
sapier |
well it's only changed if it needs to be changed |
| 23:14 |
BlockMen |
what? |
| 23:14 |
BlockMen |
its a minus in comparison to now |
| 23:14 |
sapier |
hmm true it might be visible till first change of health or breath |
| 23:15 |
BlockMen |
and that can be long time |
| 23:15 |
sapier |
for breath this most likely isn't an issue |
| 23:15 |
BlockMen |
sapier, and that things get moved to games isnt a problem at all, see tree growing, see thirs person view |
| 23:15 |
BlockMen |
s/s/d |
| 23:16 |
sapier |
you can do it if you want to do it |
| 23:16 |
sapier |
I wont |
| 23:16 |
BlockMen |
no, you want switch to lua statbars |
| 23:16 |
BlockMen |
then its your part to do it in a sane way |
| 23:16 |
sapier |
in this case I'll demand it to stay in core as it was now |
| 23:17 |
sapier |
this is ridiculous expecting to fix other things while fixing bugs is very very bad style |
| 23:17 |
BlockMen |
sapier, so after doin 99% of work you skip it because it just needs to be moved to default? |
| 23:17 |
sapier |
if you don't stop behaving that silly I promise I'm gonna expect you to fix all bugs around your next commit too |
| 23:17 |
|
grrk-bzzt joined #minetest-dev |
| 23:18 |
BlockMen |
sapier, you want do the switch. then you have to keep features we already have |
| 23:18 |
BlockMen |
and hiding hud elements every time is a feature like that |
| 23:18 |
sapier |
It's core feature and it's gonna stay in core for the time beeing |
| 23:18 |
BlockMen |
and you still cant say a sane reason why it has to be in builtin |
| 23:20 |
sapier |
of course, it's been builtin by now is as sane as reason as having to reorganize code on fixing scaling of statbar |
| 23:20 |
sapier |
I'm gonna fix the possibly shown to long statbar but I will not move it |
| 23:21 |
BlockMen |
so you add more hacks and unneded functions just to keep it at builtin? |
| 23:21 |
BlockMen |
wow, im really impressed |
| 23:21 |
BlockMen |
by you stupidness |
| 23:22 |
BlockMen |
*your |
| 23:22 |
sapier |
BlockMen we're done I do accept different opions but I do not accept getting personal |
| 23:23 |
VanessaE |
sapier: does your pull work properly right now? |
| 23:23 |
BlockMen |
sapier, you started getting personal : "sapier: if you don't stop behaving that silly " |
| 23:23 |
BlockMen |
that not nicer than what i said |
| 23:23 |
sapier |
there's a slight but important difference |
| 23:26 |
VanessaE |
well I guess it doesn't (note to self: learn to read). |
| 23:26 |
VanessaE |
sapier: when it does, why not just push it, and worry about this whole move-it-into-minetest_game-default argument later? |
| 23:28 |
sapier |
actually VanessaE that's what I intended to do |
| 23:28 |
VanessaE |
ok |
| 23:29 |
sapier |
well the fix is ready but without testing I can't tell for sure if it works |
| 23:29 |
BlockMen |
sapier, tree growing was also builtin but is game part now |
| 23:29 |
BlockMen |
so, please, tell me another reason for putting it in builtin |
| 23:31 |
sapier |
huds are now hidden immediatly vanessaE do you have a way to test it? |
| 23:31 |
sapier |
I could push and fix the bugs later too but I don't really wanna do this |
| 23:33 |
sapier |
but considering the amount of time I wasted on discussing nonsense for this issue I really think about doing it this way |
| 23:34 |
VanessaE |
you mean hidden at game-start? |
| 23:34 |
sapier |
hidden once someone calles hud_set_flags() |
| 23:35 |
sapier |
previous this commit they would've been hidden on first change |
| 23:35 |
sapier |
which is obviously not intended |
| 23:36 |
sapier |
I want to get this damn thing done everytime discussing about it ends in a desaster |
| 23:36 |
sapier |
who did add luahud? I wanna thank him/her? |
| 23:40 |
VanessaE |
no clue :) |
| 23:41 |
VanessaE |
now so that I understand it, why exactly should/are the statbars being hidden upon calling that function? |
| 23:41 |
VanessaE |
I've been trying to follow but honestly, the argument hid the real discussion |
| 23:42 |
sapier |
because it's been that way by now |
| 23:43 |
BlockMen |
VanessaE, e.g for mods that want reorganize hud |
| 23:55 |
|
sapier left #minetest-dev |
