| Time |
Nick |
Message |
| 00:38 |
hmmmm |
alright, first off, why is TOCLIENT_HUD_BUILTIN_ENABLE that |
| 00:38 |
hmmmm |
why isn't this a more general TOCLIENT_HUD_FLAG_UPDATE |
| 00:38 |
hmmmm |
i don't get why it needs to be so specific |
| 00:39 |
hmmmm |
why is there an id field and why is it a u8 which is completely inconsistent with the rest of the hud packets |
| 00:39 |
hmmmm |
why are the flag checks in game.cpp and not in hud.cpp? why should game.cpp be concerned with that at all? |
| 00:40 |
hmmmm |
and then to add yet another dash of inconsistency, drawHotbar gets passed player->hud_flags for whatever reason |
| 00:40 |
hmmmm |
but not the others |
| 00:41 |
hmmmm |
then look at that, you have both a flags field and a bit enum field |
| 00:41 |
hmmmm |
why did you commit this as-is, celeron |
| 00:41 |
hmmmm |
now i need to waste my time to go and fix it |
| 00:44 |
RealBadAngel |
https://github.com/minetest/minetest/pull/684 |
| 00:44 |
RealBadAngel |
im done with engine part, now coding Lua side for it |
| 00:46 |
hmmmm |
wow that's really tight looking code |
| 00:47 |
RealBadAngel |
my first commit with ZERO deletions ;) |
| 00:48 |
|
dexter0 joined #minetest-dev |
| 00:57 |
RealBadAngel |
hmmmm, any objections about glasslike? |
| 00:57 |
hmmmm |
no |
| 00:58 |
RealBadAngel |
ok, i will pull craft recipes for new glass types in half an hour or so |
| 00:59 |
VanessaE |
hmmmm: seen pilzadam's comment about the new alpha glass? |
| 00:59 |
RealBadAngel |
need to prepare also textures |
| 00:59 |
hmmmm |
if he has something to say about it that he wanted me to see, he can tell me it directly |
| 00:59 |
VanessaE |
he did :) |
| 01:00 |
hmmmm |
i saw nothing of the sort |
| 01:01 |
RealBadAngel |
hmmm, could you merge the drawtype then? we (me and VanessaE) will work on common |
| 01:01 |
hmmmm |
in a bit |
| 01:02 |
|
EduardeCalibal joined #minetest-dev |
| 01:03 |
RealBadAngel |
btw, maybe make streaks on glass with some alpha now? |
| 01:03 |
hmmmm |
what? |
| 01:03 |
hmmmm |
don't use the alpha channel feature |
| 01:04 |
hmmmm |
maybe sometime later when transparency sorting is fixed without shaders |
| 01:04 |
RealBadAngel |
ok |
| 01:04 |
RealBadAngel |
but i will try how it could look like |
| 01:05 |
VanessaE |
hmmmm: can't find it now, but basically it was a rehash of what you already knew. |
| 01:05 |
hmmmm |
the only reason why i added it was because, in the vast majority of cases, it looks acceptable |
| 01:05 |
hmmmm |
then why did he repeat it? |
| 01:05 |
VanessaE |
guess he felt the need to comment :) |
| 01:06 |
VanessaE |
with shaders, it just doesn't work at all. without, you get water alpha conflict |
| 01:06 |
hmmmm |
with shaders it does work, i tested it |
| 01:08 |
VanessaE |
Apr 24 2013 06:47:29 <PilzAdam>this new "use_texture_alpha" is unusable; with shaders enabled it doesnt work at all and without shaders its extremly glitchy above water |
| 01:08 |
VanessaE |
there it is. had to grep through my logs...and that was just today. |
| 01:09 |
VanessaE |
I have to wonder if his video card even handles shaders |
| 01:26 |
|
ecube joined #minetest-dev |
| 01:31 |
|
ryjyd joined #minetest-dev |
| 01:47 |
hmmmm |
does anybody have any objections to this? https://github.com/sapier/minetest/commit/8931f8c466a685518b3a4b85ae0d2e77ff1d8b29 |
| 01:48 |
RealBadAngel |
i dont |
| 01:48 |
RealBadAngel |
http://i.imgur.com/CC188lQ.png |
| 01:49 |
RealBadAngel |
how do you like it? |
| 01:49 |
hmmmm |
looks nice |
| 01:49 |
RealBadAngel |
wooden framed glass (clean + streaked) and to the right steel-framed |
| 01:50 |
RealBadAngel |
clean is made using obsidian glass |
| 02:05 |
|
kaeza joined #minetest-dev |
| 02:09 |
hmmmm |
hm |
| 02:09 |
hmmmm |
hey kaeza |
| 02:10 |
|
kaeza1 joined #minetest-dev |
| 02:10 |
hmmmm |
you know, i was looking at TOCLIENT_HUD_BUILTIN_ENABLE and i couldn't help but to want to generalize that a bit more than it is |
| 02:11 |
kaeza1 |
hmmmm, hm? |
| 02:11 |
hmmmm |
let's talk about hud |
| 02:11 |
hmmmm |
every feature ends up eventually having a flags field, let's face it |
| 02:12 |
hmmmm |
now it seems that the structure of your packet has a u8 as an id whereas other hud commands have u32 ids |
| 02:12 |
kaeza1 |
hmmmm, that's because there are'n many builtin items |
| 02:12 |
kaeza1 |
aren't* |
| 02:12 |
hmmmm |
of course |
| 02:13 |
hmmmm |
but you also don't have many flags for them |
| 02:13 |
hmmmm |
you have only one for each - i guess we can call it "is_visible" |
| 02:13 |
hmmmm |
now let's be honest here |
| 02:14 |
hmmmm |
there aren't going to be many attributes that all builtin hud items have in common |
| 02:14 |
hmmmm |
what if we dropped the id field completely and had a flag for each hud item's visibility instead? |
| 02:14 |
hmmmm |
and this flags field describes the player's entire HUD |
| 02:26 |
hmmmm |
i guess not :/ |
| 02:26 |
VanessaE |
he'll return. wireless glitch probably. |
| 02:26 |
Exio |
his is using a 3g (or 2g?) |
| 02:26 |
VanessaE |
Exio: 3g I think. |
| 02:27 |
Exio |
i mean, maybe his network is working in 2g-mode and that can be the why of the timeouts :P |
| 02:27 |
VanessaE |
no idea. |
| 02:30 |
RealBadAngel |
https://github.com/minetest/common/pull/38 |
| 02:31 |
hmmmm |
so it seems prestidigitwhatever is attempting to reel me into an e-argument with him |
| 02:32 |
hmmmm |
that guy's really lookin' for a fight |
| 02:34 |
RealBadAngel |
so all the code for new glasslike is here |
| 02:35 |
VanessaE |
RealBadAngel: see pm's. this code should not be merged yet. |
| 02:35 |
VanessaE |
sorry guys, I gotta speak up on this. |
| 02:42 |
RealBadAngel |
hmmm, the thing VanessaE is talkin about is another feature for core part |
| 02:42 |
RealBadAngel |
this lua code can be merged as-is |
| 02:48 |
EduardeCalibal |
Hey, how I serialize user data? |
| 02:48 |
EduardeCalibal |
:-o |
| 02:50 |
EduardeCalibal |
I am working in a function to copy constructions from a game to another but the metadata is lost, if I store the metadata in the table the serialize function give me a error... :-/ |
| 03:00 |
VanessaE |
ok, here's an idea then. |
| 03:00 |
VanessaE |
regarding the framed glass |
| 03:01 |
VanessaE |
swap the order of the two textures - place the "glass surface" first, followed by the frame. |
| 03:01 |
VanessaE |
make the new drawtype respect that order. |
| 03:01 |
VanessaE |
then push engine *and* common to upstream. |
| 03:01 |
VanessaE |
changes thereof I mean |
| 03:01 |
VanessaE |
then we can work on the expanded version later on |
| 03:02 |
VanessaE |
this way no changes need to happen on the Lua side, so modders will not get as pissed :) |
| 03:07 |
VanessaE |
my idea for the future of this is: [04-24 22:45] <VanessaE> images = {"glass_streaks.png", "top_bottom_bezels.png", "left_right_bezels.png", "top_bottom_edges.png", "left_right_edges.png"} |
| 03:07 |
VanessaE |
(RBA talked in private already) |
| 03:08 |
VanessaE |
basically, pieces of the two bezel images would be projected over the nodeboxes for those parts of the glass that have one or more visible corners, while the two "edges" images would be cut apart and used to tile up/down/sideways along 2-or-more-node runs of a frame |
| 03:09 |
VanessaE |
that way corner images don't get tiled all over the place and break the intended seamlessness of the surface. |
| 03:10 |
|
kaeza joined #minetest-dev |
| 03:11 |
kaeza |
sorry, been having network problems tonight. They seem to be fixed now |
| 03:12 |
Exio |
hmmmm: ^ |
| 03:17 |
VanessaE |
where top/bottom/left/right are relative to a single face as viewed straight on |
| 03:18 |
VanessaE |
so much for him having fixed his connectivity issue. |
| 03:35 |
|
kaeza joined #minetest-dev |
| 03:36 |
kaeza |
I guess they were not fixed after all... |
| 03:36 |
VanessaE |
[04-24 23:18] <VanessaE> so much for him having fixed his connectivity issue. |
| 03:46 |
|
kaeza joined #minetest-dev |
| 03:48 |
hmmmm |
kaeza, like i was saying earlier before you dropped, what if we removed the ID field from the packet and just left it as a flags field for the HUD in general |
| 03:48 |
kaeza |
hmmmm, can you explain the idea in more detail? perhaps the API could use a table, and the protocol a simple u32 |
| 03:48 |
kaeza |
ah |
| 03:49 |
hmmmm |
so do you approve? |
| 03:49 |
kaeza |
hmm |
| 03:49 |
hmmmm |
it'd simplify the packet a bit and make it more generalized |
| 03:49 |
hmmmm |
for things other than setting hud elements to visible/invisible |
| 03:50 |
kaeza |
I'm not sure about that |
| 03:51 |
kaeza |
I think this will complicate things |
| 03:51 |
hmmmm |
why's that? it'd be the opposite, i'd be removing a field from a packet |
| 03:53 |
kaeza |
give me a sec while I try to connect from Linux |
| 03:55 |
|
kaeza joined #minetest-dev |
| 03:55 |
kaeza |
there |
| 03:57 |
|
ssieb joined #minetest-dev |
| 04:00 |
kaeza |
so... do you have something in mind for the API? |
| 04:00 |
kaeza |
something sane? |
| 04:01 |
kaeza |
remember that Lua is bad with bitfields |
| 04:02 |
hmmmm |
don't we have bitop now? |
| 04:02 |
VanessaE |
luajit has. |
| 04:02 |
VanessaE |
lua vanilla doesn't. |
| 04:02 |
hmmmm |
i thought we agreed to add bitop to vanilla lua |
| 04:03 |
VanessaE |
we did,. |
| 04:03 |
VanessaE |
. |
| 04:03 |
hmmmm |
grr |
| 04:03 |
VanessaE |
I was beginning to wonder why that hadn't been added yet. |
| 04:03 |
hmmmm |
that's RBA's area |
| 04:03 |
hmmmm |
but anyway that doesn't even matter |
| 04:03 |
VanessaE |
I think it is safe to say he's been a bit..busy |
| 04:03 |
hmmmm |
flags in lua, see register_ore() |
| 04:04 |
hmmmm |
i settled on a comma-delimited string of flag names |
| 04:04 |
kaeza |
that could be an option |
| 04:04 |
hmmmm |
anyway i'd be the one changing this kaeza |
| 04:04 |
hmmmm |
so don't sweat |
| 04:04 |
hmmmm |
and an added advantage to this is you wouldn't need to send more than one packet to disable the hud elements |
| 04:04 |
kaeza |
yeah, whatever |
| 04:04 |
kaeza |
go on |
| 04:06 |
kaeza |
I may as well not have bothered to add it |
| 04:09 |
hmmmm |
sorry |
| 04:10 |
hmmmm |
just trying to make things 100% optimal |
| 04:14 |
hmmmm |
i would've changed it all anyway when eventually the builtin hud elements become not-built-in |
| 04:14 |
Exio |
hmmmm: small thingy - mapgen_v6.cpp:271-275, can't that get changed to a return rangelim? :P |
| 04:15 |
hmmmm |
(which requires a good way to do client-side prediction which we don't yet have) |
| 04:15 |
hmmmm |
yes it can be |
| 04:15 |
hmmmm |
the reason why it's not is because that's taken directly from the 0.3.x mapgen |
| 04:15 |
Exio |
ah |
| 04:19 |
kaeza |
hmmmm, the current system makes it so you can disable individual items without regard to other items |
| 04:19 |
kaeza |
what you propose is to set the entire thing with one call |
| 04:19 |
hmmmm |
that shouldn't really be too much of a problem from lua |
| 04:20 |
hmmmm |
you can keep track of what you've already disabled |
| 04:20 |
hmmmm |
and if it's not, i can just add a mask parameter too |
| 04:20 |
kaeza |
in the current scheme, a mod can disable the crosshair to show it's own with an image HUD item |
| 04:20 |
hmmmm |
yeah about that though |
| 04:20 |
hmmmm |
there's been a demand for an image crosshair that's client-side only |
| 04:21 |
kaeza |
so... complicate thing |
| 04:21 |
kaeza |
+s |
| 04:22 |
kaeza |
I'd agree with using a table though |
| 04:22 |
hmmmm |
i don't know, it seems like people are going bonkers over minor details like that |
| 04:22 |
kahrl |
can't the crosshair (in its current state) be moved to lua? |
| 04:22 |
hmmmm |
we already have a way to do an image for a crosshair |
| 04:22 |
hmmmm |
yes it can be |
| 04:22 |
kahrl |
if it uses a texture client can override it |
| 04:22 |
kaeza |
when the field is true, the item is shown, when false, it's hidden, and when nil, it's unchanged |
| 04:23 |
hmmmm |
sure |
| 04:23 |
hmmmm |
that's not hard to do |
| 04:23 |
hmmmm |
that's just the lua bit of this |
| 04:23 |
hmmmm |
so you want me to add a mask too. simple enough |
| 04:26 |
kaeza |
as I said, do whatever you want to |
| 04:26 |
kaeza |
I'm not touching any engine-related changes from now on |
| 04:26 |
hmmmm |
what why not |
| 04:29 |
kaeza |
because I don't know how to write "100% optimal" code, and may as well not bother trying to do so |
| 04:29 |
hmmmm |
noo |
| 04:30 |
hmmmm |
it's just because this was rushed without much feedback |
| 04:30 |
hmmmm |
besides, there's room for improvement for everything |
| 04:30 |
hmmmm |
i'm sorry, i didn't mean for you to take it the wrong way |
| 04:31 |
hmmmm |
i guess i'm a bit of a neat freak... when it comes to pieces of code that i mostly did myself, i get over-protective about it and i feel like everything needs to be perfect |
| 04:31 |
kahrl |
kaeza: it's not like minetest is 100% optimal code... |
| 04:31 |
hmmmm |
but the rest of it is like "nah, not mine, i don't give a crap" |
| 04:31 |
kaeza |
kahrl, IKR :P |
| 04:35 |
hmmmm |
so kaeza, please don't stop on writing code for the core |
| 04:35 |
hmmmm |
besides, the other things you added were 100% perfect, i didn't change anything at all with that |
| 04:35 |
kaeza |
hmmmm, if you think this will be easier for the modder, then do it |
| 04:36 |
hmmmm |
well of course it's not going to be easier for the modder, it just makes the code cleaner and reduces the number of packets needed to be sent |
| 04:36 |
kaeza |
the protocol is not of importance here, because this will be done mostly on load |
| 04:36 |
hmmmm |
well |
| 04:36 |
kaeza |
err... not *very* important |
| 04:36 |
hmmmm |
this will be easier for the modder as well because you'd be able to do all of this with a single call |
| 04:37 |
hmmmm |
i plan on using the table idea |
| 05:13 |
|
ImQ009 joined #minetest-dev |
| 06:02 |
VanessaE |
weird error, and I didn't think to take a screenshot of it - tonight's commits may cause a REALLY WEIRD drawtype confusion when used on a server that's a couple days old |
| 06:03 |
VanessaE |
many things became either plantlike or raillike |
| 06:03 |
VanessaE |
until I restarted the server to make it current with the client |
| 06:04 |
VanessaE |
(particularly if the object was a nodebox or already plantlike) |
| 06:09 |
VanessaE |
oh shit |
| 06:10 |
VanessaE |
it's happening on older servers |
| 06:10 |
VanessaE |
current git cannot be used on anything older than a couple of days |
| 06:10 |
VanessaE |
current git *client* that is |
| 06:10 |
VanessaE |
major regression |
| 06:12 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/screenshot_1070719285.png |
| 06:13 |
VanessaE |
those are supposed to be slabs, this house has existed for several months. Also note the torch near the bottom right of the image, and the window shutters at the right |
| 06:16 |
|
darkrose joined #minetest-dev |
| 06:18 |
VanessaE |
my last known good build was 3 days ago, commit 37e6d135 |
| 06:21 |
kaeza |
minor idea: being able to save JPEG screenshots |
| 06:21 |
VanessaE |
jpeg for a screenshot? blasphemy. :) |
| 06:22 |
kaeza |
VanessaE, for some, a ~80 KB jpeg file is better than a ~1MB png file :) |
| 06:22 |
kaeza |
(both for disk space and network) |
| 06:22 |
|
bookwar joined #minetest-dev |
| 06:22 |
VanessaE |
746kB :) |
| 06:23 |
kaeza |
not so much difference |
| 06:25 |
kaeza |
anyway, I can't come up with new ideas |
| 06:26 |
VanessaE |
well |
| 06:26 |
VanessaE |
it's okay if things need tweaked after you come up with an idea |
| 06:27 |
VanessaE |
that's how collaborative programming works :) |
| 06:27 |
kaeza |
yep I know, I was just a bit pissed off for something unrelated and over reacted |
| 06:28 |
kaeza |
I think the change in HUD API may be better after all |
| 06:28 |
VanessaE |
well I dunno that I'll actually be using that, but who knows |
| 06:29 |
kaeza |
I can prolly code it in a few hours (like I did with my last commit) bu hmmmm said he wants to do it |
| 06:31 |
kaeza |
BTW, I saw flowers are now in minetest_game |
| 06:31 |
VanessaE |
not yet |
| 06:32 |
kaeza |
ah yes, it was a pull request :P |
| 06:32 |
kaeza |
...or did I misread that? |
| 06:32 |
VanessaE |
damn it why can't there be someone on right now who can fix this? |
| 06:32 |
VanessaE |
ok, a user on my server who is running 0.4.6-old-and-crusty ;) from the main website says some stuff on the server (which is at git HEAD at the moment) looks "flat" |
| 06:37 |
darkrose |
o.0 |
| 06:37 |
VanessaE |
rewinding back to commit 36747794[...] |
| 06:42 |
VanessaE |
ok, current git client cannot be used with a server of that commit or older for sure. |
| 06:43 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/screenshot_1072572201.png |
| 06:44 |
VanessaE |
this is NOT what those structures look like. |
| 06:44 |
VanessaE |
looks fine if I connect with a client from the same build. |
| 06:48 |
VanessaE |
that 0.4.6-rusted-out ;) user on my server says everything looks normal now. |
| 06:54 |
|
bookwar left #minetest-dev |
| 07:34 |
|
ImQ009 joined #minetest-dev |
| 07:52 |
|
emptty joined #minetest-dev |
| 08:19 |
|
darkrose joined #minetest-dev |
| 08:19 |
|
darkrose joined #minetest-dev |
| 08:20 |
celeron55 |
ummm |
| 08:20 |
celeron55 |
VanessaE: that could be a somewhat serious problem |
| 08:20 |
VanessaE |
I would say so. :) |
| 08:20 |
celeron55 |
has someone modified ContentFeatures? |
| 08:21 |
VanessaE |
the first screenshot (brick house, stone-brick roof) was on redcrab.suret.net:30401 (which I think is still late 0.4.4) while using client from git HEAD |
| 08:21 |
VanessaE |
I'm not sure, but I do seem to recall seeing some discussion about *possibly* doing so |
| 08:22 |
celeron55 |
it seems like no |
| 08:22 |
celeron55 |
zero changes since 0.4.6 |
| 08:23 |
celeron55 |
(i was first wondering whether my usage of git is just broken, but there just weren't any results 8D) |
| 08:24 |
VanessaE |
could that new drawtype RBA added be at fault? or the alpha thing hmmmm put in? |
| 08:24 |
VanessaE |
those are the only two I coul deven begin to suspect, since I don't know the engine that well |
| 08:26 |
celeron55 |
oh no |
| 08:26 |
VanessaE |
? |
| 08:26 |
celeron55 |
i hadn't pulled minetest/minetest since yesterday or so |
| 08:26 |
celeron55 |
this is due to RBA's framed stuff |
| 08:26 |
VanessaE |
shit |
| 08:27 |
celeron55 |
RealBadAngel: fuck |
| 08:27 |
celeron55 |
and shit |
| 08:27 |
VanessaE |
guess I wasn't far off when I suggested not to merge it yet :D |
| 08:28 |
VanessaE |
(but for a completely different reason) |
| 08:28 |
celeron55 |
RealBadAngel: you should realize you are dealing with network serialization |
| 08:29 |
kaeza |
celeron55, any comments on changing the HUD API as hmmmm said? |
| 08:30 |
celeron55 |
also hmmmm committed this, screw that too |
| 08:50 |
VanessaE |
"celeron55 authored in a minute" |
| 08:50 |
VanessaE |
time travel much? ;) |
| 09:00 |
VanessaE |
celeron55: I think that's got it. |
| 09:08 |
VanessaE |
seems good, new build posted on my thread. |
| 09:16 |
|
darkrose joined #minetest-dev |
| 09:16 |
|
darkrose joined #minetest-dev |
| 09:24 |
celeron55 |
kaeza: my comment is that don't be concerned about hmmmm |
| 09:25 |
celeron55 |
he really pisses anyone off unless you know that it's the only way he is able to talk 8) |
| 09:25 |
celeron55 |
i do think that hmmmm's suggestions are more about overcomplicating stuff than making them cleaner |
| 09:26 |
celeron55 |
also, bitfields in lua are bullshit |
| 09:26 |
kaeza |
heh |
| 09:26 |
kaeza |
that's what I told him |
| 09:49 |
|
PilzAdam joined #minetest-dev |
| 10:00 |
|
proller joined #minetest-dev |
| 10:24 |
|
darkrose joined #minetest-dev |
| 10:24 |
|
darkrose joined #minetest-dev |
| 11:00 |
|
Calinou joined #minetest-dev |
| 11:45 |
|
kaeza1 joined #minetest-dev |
| 12:20 |
EduardeCalibal |
celeron55, I need help, I converted userdata from the get_meta function to tables and stored in a file, when I retrieve this data and set back to nodes with meta:from_table() the game instaltly crash. How I will solve this? |
| 12:21 |
EduardeCalibal |
Detail, this work if I only store in a table and transfer back to another node. I think I lost the 'userdata' status of my data and now I need convert back but I don't know how... |
| 12:22 |
PilzAdam |
this is the wrong channel for modding questions |
| 12:22 |
EduardeCalibal |
Ops, sorry. |
| 12:22 |
PilzAdam |
go to #minetest or #minetest-mods and ask your question there |
| 12:23 |
EduardeCalibal |
Well, the game crash then still a mod question? |
| 12:23 |
PilzAdam |
it would also be helpful if you show us your code |
| 12:23 |
EduardeCalibal |
Ok. |
| 12:23 |
PilzAdam |
the game crashes if mods are wrong, so yes, its still a modding question |
| 13:11 |
|
iqualfragile joined #minetest-dev |
| 13:20 |
|
hmmmm joined #minetest-dev |
| 13:39 |
|
ImQ009 joined #minetest-dev |
| 13:39 |
|
iqualfragile joined #minetest-dev |
| 13:58 |
|
iqualfragile joined #minetest-dev |
| 13:58 |
celeron55 |
hmmmm: i request you to (per each situation) either not be so overly controlling about things or alternatively just do things yourself |
| 13:59 |
celeron55 |
even if you don't care a tiny bit about niceness, think about it in terms of productivity |
| 14:01 |
celeron55 |
and i request you to do those decisions early, not after you have already talked yourself into being the only one who can ever do it in an acceptable way |
| 14:04 |
celeron55 |
kaeza's code is good enough for our standards |
| 14:04 |
celeron55 |
if you draw the line elsewhere, you will have to adjust it |
| 14:13 |
|
iqualfragile joined #minetest-dev |
| 14:20 |
|
kaeza joined #minetest-dev |
| 14:45 |
RealBadAngel |
hi all |
| 14:45 |
RealBadAngel |
celeron55, whats wrong with my pull? |
| 14:46 |
Exio |
check the order |
| 14:50 |
RealBadAngel |
? |
| 14:51 |
PilzAdam |
RealBadAngel, you broke compatibility to old clients by adding NDT_GLASSLIKE_FRAMED in the middle of the NodeDrawType enum |
| 14:51 |
PilzAdam |
so you basically changed the numbers for half of the drawtypes |
| 14:51 |
RealBadAngel |
holy shit |
| 14:52 |
RealBadAngel |
i didnt realize it, i just inserted it next to glasslike |
| 14:52 |
PilzAdam |
generally always append to enums, dont insert |
| 14:53 |
RealBadAngel |
this was the last thing for me to do |
| 14:53 |
RealBadAngel |
i just copied all the stuff takin glasslike |
| 14:53 |
PilzAdam |
"everything else done? – lets break something >:)" :-p |
| 14:53 |
RealBadAngel |
and made entry next to it |
| 14:54 |
RealBadAngel |
tested it, all worked fine |
| 14:54 |
RealBadAngel |
pushed to my git, reget, compiled again |
| 14:54 |
|
emptty joined #minetest-dev |
| 14:54 |
RealBadAngel |
so double checked, then pulled to main |
| 14:55 |
RealBadAngel |
sorry, it was not intentional |
| 14:55 |
RealBadAngel |
also i asked vanessae to get the sources from my git and test it before pulling |
| 14:56 |
RealBadAngel |
she said no, im only downloading sources from main tree |
| 14:56 |
PilzAdam |
you dont have to explain yourself |
| 14:56 |
PilzAdam |
things like that happen |
| 14:56 |
PilzAdam |
just dont do it again |
| 14:57 |
RealBadAngel |
but things like fuck, shit, you should know makes me sad |
| 14:57 |
kaeza |
it's kinda hard to spot these things when testing |
| 14:57 |
RealBadAngel |
when im extremaly caerefull postin anythin |
| 14:58 |
kaeza |
because that bug was unrelated to the spirit of the change, you had no way to see that |
| 14:58 |
PilzAdam |
hmmmm, use_texture_alpha doesnt work with shaders enabled for me. with this https://github.com/PilzAdam/common/commit/fb04d3f0ba5cec84757b84e437aaff2bd1a234b6 the alpha is ignored and with normal drawtype its not drawn at all |
| 14:58 |
PilzAdam |
(with shaders enabled) |
| 14:59 |
PilzAdam |
(the texture is 0 |
| 14:59 |
PilzAdam |
(the texture is 20% transparent) |
| 14:59 |
RealBadAngel |
i can see its fixed already |
| 15:00 |
RealBadAngel |
thx celeron55, i learned something new again |
| 15:01 |
kaeza |
to tell the truth, enums are kind or a blessing and a curse at the same time |
| 15:02 |
PilzAdam |
RealBadAngel, what do you think: https://github.com/PilzAdam/common/commits/flowers |
| 15:02 |
RealBadAngel |
regarding VanessaE proposal of rotating textures to make frames beveled at corners |
| 15:02 |
PilzAdam |
http://ompldr.org/vaTd2bA |
| 15:02 |
RealBadAngel |
definitely will not be made, because: |
| 15:02 |
RealBadAngel |
a) its an effect only for 64x or higher texture packs |
| 15:03 |
RealBadAngel |
b) will double computations needed to make those fancy corners |
| 15:03 |
RealBadAngel |
c) will require insane ammount of textures to make it properly |
| 15:04 |
RealBadAngel |
in case of default 16x16 game textures we are talkin about rotating 1 (sic!) pixel textures |
| 15:04 |
RealBadAngel |
i definitely refuse to code this eyecandy |
| 15:06 |
kaeza |
PilzAdam, that's great |
| 15:06 |
RealBadAngel |
PilzAdam, im ok with it |
| 15:06 |
kaeza |
It's finally a way to get wool in vanilla game |
| 15:06 |
RealBadAngel |
but hold on |
| 15:07 |
RealBadAngel |
the screenshot is from actual usage of the mod? |
| 15:07 |
PilzAdam |
yes |
| 15:07 |
RealBadAngel |
are there not TOO many flowers out there? |
| 15:07 |
Exio |
PilzAdam: it works for me with a 50%~ transparent image |
| 15:08 |
RealBadAngel |
i can see only flowers around and almost no grass at all |
| 15:08 |
PilzAdam |
RealBadAngel, its just a region with many flowers |
| 15:09 |
PilzAdam |
there are also regions without anything, with grass only, grass and a few flowers, only a few flowers and no grass, etc. |
| 15:20 |
|
emptty joined #minetest-dev |
| 15:24 |
RealBadAngel |
ah so, then no objections at all |
| 15:24 |
RealBadAngel |
we need flowers |
| 15:37 |
celeron55 |
i'm mostly worried that somebody will some day commit something that modifies such an enum that gets saved on disk |
| 15:38 |
celeron55 |
we might need to start handling the on-disk saving by first documenting format changes, then implementing them |
| 15:39 |
celeron55 |
but it's hard as of now because what gets saved on disk is bit of a mess; stuff that is able to break things propagates from quite high up into there |
| 15:39 |
celeron55 |
that's actually why this exists https://github.com/celeron55/minetest-worldtest |
| 15:41 |
celeron55 |
somebody should probably automate that on a server that reports somewhere publicly |
| 15:44 |
celeron55 |
also the map patch that it uses for 0.4.1 and 0.4.3 won't work in current versions |
| 15:44 |
|
Calinou joined #minetest-dev |
| 15:44 |
celeron55 |
actually server patch |
| 15:47 |
hmmmm |
[10:04 AM] <celeron55> kaeza's code is good enough for our standards |
| 15:47 |
hmmmm |
mine too |
| 15:47 |
hmmmm |
but this isn't about code, it's about the manner in which the feature is carried out |
| 15:48 |
hmmmm |
i just think it's more ideal to send a _single_ packet describing the entire state of the builtin hud (or maybe hud in general) rather than have 4 separate sends that do exactly one thing each |
| 15:48 |
|
rubenwardy joined #minetest-dev |
| 15:48 |
celeron55 |
that means the server always has to fully know the previous state |
| 15:48 |
celeron55 |
it may or may not be what we want, that's a design question |
| 15:48 |
hmmmm |
at first, sure |
| 15:48 |
hmmmm |
but i mentioned that i'd add a mask field as well |
| 15:49 |
hmmmm |
eliminating that problem |
| 15:49 |
kaeza |
that just adds complication to the code |
| 15:49 |
kaeza |
instead of making it cleaner |
| 15:49 |
hmmmm |
a single bit operation? |
| 15:50 |
celeron55 |
well, make the patch and show us before merging, that'll make everything clear |
| 15:50 |
hmmmm |
sure, i need to actually write it first |
| 15:50 |
hmmmm |
i just got home |
| 15:50 |
hmmmm |
now let's see the shader problem |
| 15:50 |
celeron55 |
don't do bit operations in lua though; it's tasteless and unclean |
| 15:50 |
hmmmm |
i fear that the way i did the per-pixel alpha blending in the shaders is wrong |
| 15:51 |
hmmmm |
no, no, we've already decided that we're passing a table with true/false |
| 15:52 |
hmmmm |
so for example, flags = {wielditem=true, crosshair=false, somethingelse=false} would create a mask that modifies the bits wielditem, crosshair, and somethingelse, so the latter two are set to false while the first is set to true, and no other bits are affected |
| 15:52 |
|
dexter0 joined #minetest-dev |
| 15:52 |
hmmmm |
it's clean from the lua side and the code side as well since it's so simplistic |
| 15:52 |
celeron55 |
and also, don't add any unreasonably low limits like 32 for amounts of things in the hud |
| 15:52 |
hmmmm |
it also avoids needing an enum |
| 15:52 |
hmmmm |
erm |
| 15:52 |
hmmmm |
32 things for the builtin hud |
| 15:52 |
celeron55 |
for the builtin hud, 32 is fine, yes |
| 15:52 |
kaeza |
that's another thing for consideration IMHO |
| 15:53 |
hmmmm |
about that |
| 15:53 |
kaeza |
my code allows up to 256 items |
| 15:53 |
hmmmm |
i believe that the builtin hud items won't be lua-ized for quite some time |
| 15:53 |
hmmmm |
and if they do, it'd be a large enough change to warrant changing all of these things as well |
| 15:53 |
celeron55 |
true, maybe never |
| 15:53 |
hmmmm |
so it doesn't matter too much |
| 15:53 |
celeron55 |
but they must be disableable for special usage |
| 15:54 |
hmmmm |
that they are |
| 15:55 |
hmmmm |
as an aside, more than 32 HUD items is kind of ridiculous |
| 15:56 |
kaeza |
maybe |
| 15:56 |
hmmmm |
we might need to set a limit to the number of total hud items per player so the client isn't bogged down with this crap. but then again, there are other more effective ways for a server to kill a client |
| 15:56 |
celeron55 |
we need to provide for hacks that come from the lua side, just because it's nice to let people to do things via hacks if we don't have resources to implement them properly |
| 15:57 |
celeron55 |
it feeds innovation which is good |
| 15:57 |
kaeza |
hmmmm, that's not the job of the engine |
| 15:57 |
kaeza |
if mods define 1284194 hud items it's the fault of the player for using so many mods |
| 15:58 |
kaeza |
(I mean, the server owner) |
| 15:58 |
celeron55 |
well, one million hud items is kind of an overstatement 8) but anyways |
| 15:59 |
hmmmm |
one of these days i'm going to write a mod that spams the player with porn banner ads and annoying sound ads |
| 15:59 |
RealBadAngel |
'640K is more memory than anyone will ever need.' |
| 15:59 |
kaeza |
hmmmm, don't give me ideas :P |
| 15:59 |
hmmmm |
"5 cars is more than anyone will ever need" |
| 15:59 |
celeron55 |
there's barely one million pixels on the screen (well, usually two million) 8) |
| 15:59 |
hmmmm |
trufax^ |
| 16:00 |
celeron55 |
of course you could draw each pixel with a single hud element |
| 16:00 |
kaeza |
I'm going to show jordan4ibanez that you can show dancing cats on the HUD 8) |
| 16:00 |
celeron55 |
i wonder how that'd perform 8D |
| 16:01 |
|
serengeor joined #minetest-dev |
| 16:01 |
kaeza |
celeron55, think of the average internet user installing search bars into IE :) |
| 16:01 |
hmmmm |
you know, when i first brought up the potential for abuse in that manner, somebody in #minetest actually said that it'd be a great way for minetest servers to be ad-supported |
| 16:01 |
* hmmmm |
cringes |
| 16:02 |
celeron55 |
well i don't care if somebody does that |
| 16:02 |
|
rubenwardy joined #minetest-dev |
| 16:02 |
celeron55 |
some people seem to tolerate ads and if that's the kind of thing they want, whatever |
| 16:03 |
hmmmm |
and then when there's finally client-side lua, there'll be an adblock plus for minetest |
| 16:03 |
celeron55 |
minetest is eventually going to become an operating system |
| 16:03 |
celeron55 |
it's unevitable 8D |
| 16:04 |
Exio |
emacstest |
| 16:04 |
Calinou |
minemacs |
| 16:05 |
Calinou |
includes: "RMS Block" |
| 16:05 |
hmmmm |
sure, add the built-in webbrowser that somebody was proposing |
| 16:05 |
Exio |
and then mt will have everything but a game |
| 16:06 |
celeron55 |
then people will invent something like using terasology inside minetest, just like some people use vim in emacs |
| 16:07 |
Calinou |
JVM in minetest |
| 16:07 |
Calinou |
^ we need that |
| 16:08 |
hmmmm |
agh |
| 16:08 |
hmmmm |
pilz is right |
| 16:08 |
hmmmm |
i think it's because i didn't convert to RGB correctly |
| 16:09 |
hmmmm |
i'm sure there's a simple way to get translucency with shaders working 100% |
| 16:10 |
PilzAdam |
hmmmm, I prefer "Adam" |
| 16:10 |
hmmmm |
right now the unsolved problem is that the backface for the other texture isn't drawn, so if you have something like lava flowing in behind a translucent block, you might not see it at certain angles |
| 16:10 |
hmmmm |
okay |
| 16:10 |
hmmmm |
i can't get used to that but i'll try |
| 16:11 |
Calinou |
and in other angles, it will look like the lava is in front of it :P |
| 16:11 |
Calinou |
even notch can't code real transparency sorting that accounts that |
| 16:11 |
hmmmm |
if shaders are disable |
| 16:11 |
hmmmm |
disabled |
| 16:12 |
hmmmm |
notch isn't really that great though |
| 16:12 |
hmmmm |
but yes, this is a definite calling to implement transparency sorting. anybody have any ideas? |
| 16:12 |
RealBadAngel |
PilzAdam, can you push the recipes and defs for glass? |
| 16:12 |
PilzAdam |
RealBadAngel, no |
| 16:12 |
RealBadAngel |
why? |
| 16:12 |
PilzAdam |
Im not sure about it |
| 16:12 |
RealBadAngel |
what makes you think so? |
| 16:13 |
PilzAdam |
I would be fine with adding it to the build game |
| 16:13 |
RealBadAngel |
this is just content |
| 16:14 |
RealBadAngel |
i dont see a poin in limitin it to just build game |
| 16:14 |
PilzAdam |
its just a complete useless node |
| 16:14 |
PilzAdam |
we alread have glass |
| 16:15 |
RealBadAngel |
we do have different kinds of stones |
| 16:15 |
RealBadAngel |
bricks etc |
| 16:15 |
PilzAdam |
its just there for decoration, and so its useful for build game, but nor for survival |
| 16:15 |
RealBadAngel |
why glass shall be one and only? |
| 16:15 |
RealBadAngel |
survival means also gather resources and make your world better |
| 16:16 |
PilzAdam |
yes, but this glass goes too far |
| 16:16 |
RealBadAngel |
with limiting possible targets you take off half of the gameplay |
| 16:16 |
PilzAdam |
really? this glass is half of the gameplay? |
| 16:17 |
Exio |
i'm a survival player - and i like the idea of "amazing builds" what are built when manually-gathered resources |
| 16:17 |
RealBadAngel |
i spent almost a month building automated tree farm in minetest survival single player game |
| 16:17 |
RealBadAngel |
which required tremendous logic to control all the stuff |
| 16:17 |
RealBadAngel |
just for fun building it |
| 16:18 |
RealBadAngel |
and you call glass 'too much"? i should fire up mc now and make some screenshots of my singleplayer world just for you |
| 16:18 |
RealBadAngel |
to show you what survival means |
| 16:18 |
PilzAdam |
Im not against adding more resources for survival players, but Im against making the same node slightlty different for decoration purposes |
| 16:19 |
PilzAdam |
and bricks and stone are not the same node slightly modified |
| 16:20 |
RealBadAngel |
i wont agree to limit it to just one game mode, i will release the glass in technic modpack then |
| 16:20 |
|
dexter0 joined #minetest-dev |
| 16:20 |
PilzAdam |
really? you want it in all game modes or not at all? |
| 16:21 |
RealBadAngel |
who plays build game?? |
| 16:21 |
hmmmm |
pilzadam, is this supposed to be the desired translucency of ice? http://ompldr.org/vaTd4Yw |
| 16:21 |
RealBadAngel |
im not |
| 16:21 |
|
kaeza1 joined #minetest-dev |
| 16:21 |
PilzAdam |
hmmmm, ummm.... yes? |
| 16:21 |
hmmmm |
what's the ummm for |
| 16:21 |
hmmmm |
why not just say yes |
| 16:21 |
hmmmm |
but okay |
| 16:22 |
RealBadAngel |
pull request is cancelled |
| 16:22 |
hmmmm |
that was simple, all i had to do was transform the alpha channel too |
| 16:22 |
PilzAdam |
I guess you just took the image from the commit I linked? I just have made it randomly transparent and wasnt able to test it in-game |
| 16:22 |
hmmmm |
well with that image i was able to see that it didn't work properly |
| 16:22 |
PilzAdam |
so the "ummmm" just says "I will look at it if the engine code work" |
| 16:23 |
kahrl |
it looks deceptively simple, so it might be wrong, but I might have fixed the "Meshbuffer ran out of indices" problem |
| 16:23 |
kahrl |
http://codepad.org/GjdCbsds |
| 16:23 |
kahrl |
shall I make a pull request? |
| 16:24 |
hmmmm |
wait |
| 16:24 |
hmmmm |
'might have fixed' |
| 16:24 |
kahrl |
I only tested it with allfaces nodes |
| 16:25 |
hmmmm |
i thought the problem was that there were too many for that single buffer and you'd need to allocate a new buffer |
| 16:25 |
kahrl |
I know the fix won't work with nodeboxes that contain more than 65535 indices, but I don't know if there are any |
| 16:25 |
kahrl |
yes, that's what it does |
| 16:25 |
hmmmm |
i don't see any allocations though |
| 16:26 |
kahrl |
if the for loop finds no valid meshbuffer, it allocates a new one below |
| 16:26 |
hmmmm |
ah. |
| 16:26 |
hmmmm |
makes sense... this doesn't leak any meshbuffers, right? |
| 16:26 |
kahrl |
it don't see any reason it should |
| 16:26 |
kahrl |
I* |
| 16:27 |
hmmmm |
sorry, just sorta paranoid about memory leaks because we just wrestled with so many of them |
| 16:27 |
kahrl |
I know, I've been guilty a few times in the past :( |
| 16:27 |
hmmmm |
sure, make a pull request - thank you for the fix, and welcome back |
| 16:29 |
PilzAdam |
so, what about this one? https://github.com/PilzAdam/minetest/commit/05af955a3741f49fa3e04611ac717c57fba3e935 |
| 16:29 |
kahrl |
actually it will work with ridiculously complex nodeboxes |
| 16:30 |
kahrl |
since those call collector->append for each box separately |
| 16:30 |
hmmmm |
https://github.com/minetest/minetest/commit/ddd2b18321a6dad82c4618bfb8f797579d4d6666 |
| 16:30 |
kahrl |
PilzAdam: :) |
| 16:31 |
hmmmm |
heh, i was going to do that |
| 16:31 |
hmmmm |
you made a separate branch for that!? |
| 16:32 |
PilzAdam |
I always push to branches |
| 16:32 |
PilzAdam |
I push it now |
| 16:32 |
hmmmm |
wow :)! look at the commit logs |
| 16:33 |
hmmmm |
it's not flooded with kwolekr anymore |
| 16:34 |
PilzAdam |
hmmmm, wielditem and inventory image of ice look awesome now! |
| 16:34 |
hmmmm |
kool |
| 16:34 |
PilzAdam |
the actual nodes above water are still too glitchy :-/ |
| 16:35 |
hmmmm |
there's a call to fix that |
| 16:35 |
hmmmm |
i don't think i'll be the one to do it |
| 16:35 |
Exio |
https://github.com/minetest/minetest/pull/662 - what about this? |
| 16:35 |
* PilzAdam |
looks at kahrl |
| 16:36 |
PilzAdam |
Exio, seems ok to me |
| 16:37 |
Exio |
(and random fixes what are in the pull request page - https://github.com/minetest/minetest/pull/648 https://github.com/minetest/minetest/pull/670 ?) |
| 16:38 |
PilzAdam |
has someone tested the serverlist thing yet? |
| 16:39 |
hmmmm |
the first one ought to be tested first, since the last time we merged something that modified build-related things it totally messed things up |
| 16:39 |
hmmmm |
the second one, celeron seems skeptical of but i believe it's good to merge |
| 16:42 |
kahrl |
https://github.com/minetest/minetest/pull/686 |
| 16:43 |
PilzAdam |
tested sapiers collission thing, works fine |
| 16:44 |
PilzAdam |
I would like to merge it, any objections? |
| 16:44 |
thexyz |
don't you think we should add kahrl to the minetest team? |
| 16:44 |
hmmmm |
that's sorta celeron's job |
| 16:45 |
thexyz |
well, I have all needed permissions at github to do that |
| 16:45 |
hmmmm |
besides, he might want to stay as an additional contributor because honestly minetest is a huge time sucker |
| 16:45 |
kahrl |
^ |
| 16:45 |
thexyz |
okay |
| 16:46 |
kahrl |
I don't always have as much time as this week, sadly |
| 16:47 |
kahrl |
and I don't really play minetest very often |
| 16:48 |
RealBadAngel |
PilzAdam, https://github.com/RealBadAngel/technic/commit/4b0aef17a0d7a834adf31b26fb0418eaca7ea958 |
| 16:48 |
RealBadAngel |
and sidenote, techinc will go game mode. |
| 16:50 |
hmmmm |
hah |
| 16:50 |
hmmmm |
i don't play minetest ever |
| 16:50 |
RealBadAngel |
i do |
| 16:51 |
RealBadAngel |
and i code to improve my gameplay |
| 16:51 |
RealBadAngel |
and i dont play build at all |
| 16:53 |
RealBadAngel |
if common and minetest_game is goin to be mc twisted and with limited to minimum content its not my game mode simply |
| 16:53 |
RealBadAngel |
thus my mods will not support them too |
| 16:54 |
|
dimeshake left #minetest-dev |
| 16:54 |
hmmmm |
woah wait a minute |
| 16:54 |
hmmmm |
https://github.com/minetest/minetest/commit/e703c5b81f87550e636ebb1ebb1eb64027a44687#L1L2116 |
| 16:54 |
hmmmm |
builtin hud enable/disable wouldn'tve worked anyway, look at the bug |
| 16:54 |
PilzAdam |
https://github.com/minetest/minetest/commit/88ffb3f73bb16c6680ee10a8e804a699e366edd8 |
| 16:54 |
hmmmm |
err nevermind |
| 16:55 |
hmmmm |
i could've sworn the flag field was a u32 |
| 16:55 |
hmmmm |
:) dumb dumb me |
| 16:56 |
RealBadAngel |
goin to take a nap after work, laters |
| 16:56 |
Calinou |
<hmmmm> i don't play minetest ever |
| 16:57 |
Calinou |
hello linus torvalds, do you still read code? |
| 16:58 |
hmmmm |
huh? |
| 16:58 |
hmmmm |
erm anyway |
| 16:59 |
hmmmm |
i've noticed a recent trend where people add client events for things that do not require client events (such as setting a number for a player) |
| 16:59 |
|
iqualfragile joined #minetest-dev |
| 16:59 |
hmmmm |
presumably this is done for thread-safety, except the client event queue isn't thread safe anyway |
| 17:00 |
hmmmm |
...and it happens that the client's connection is handled in the game loop |
| 17:03 |
PilzAdam |
why wasnt object <-> object collision added to the changelog for 0.4.6? |
| 17:15 |
|
serengeor joined #minetest-dev |
| 17:17 |
kaeza1 |
[13:54:43] <hmmmm> builtin hud enable/disable wouldn'tve worked anyway, look at the bug |
| 17:17 |
kaeza1 |
wut |
| 17:17 |
hmmmm |
no nevermind |
| 17:17 |
hmmmm |
that was just me being stupid.. i could've sworn that flags was a u32 |
| 17:18 |
kaeza1 |
ah I see |
| 17:18 |
hmmmm |
in that case the code wouldn't work because values are big endian and it would always read 0 |
| 17:18 |
kaeza1 |
nope |
| 17:19 |
kaeza1 |
it uses readU8() |
| 17:19 |
hmmmm |
well, yeah, i see that.. |
| 17:19 |
kaeza1 |
the only u32 there is player->hud_flags |
| 17:19 |
hmmmm |
oh, that's where i got u32 from |
| 17:19 |
hmmmm |
why is there that inconsistency? |
| 17:20 |
kaeza1 |
inconsistency? |
| 17:20 |
hmmmm |
well, yeah, if you send a u8 but it's actually a u32 in the structure |
| 17:20 |
kaeza1 |
erhm... because of speed? |
| 17:20 |
hmmmm |
3 more bytes? |
| 17:21 |
hmmmm |
i'd be way more worried about latency |
| 17:21 |
kaeza1 |
anyway, I'm used to use 32-bit types even for things that count from 1 to 10 |
| 17:21 |
kaeza1 |
wut |
| 17:21 |
kaeza1 |
the packet uses 2 u8's |
| 17:21 |
kaeza1 |
one for id and one for the enable/disable flag |
| 17:21 |
hmmmm |
erm |
| 17:22 |
hmmmm |
from what i got, you said "i used a u8 when transferring it over the network because a u8 is faster to send than a u32, because there are less bytes" |
| 17:22 |
kaeza1 |
yep |
| 17:23 |
hmmmm |
but what i replied was, "but that doesn't matter, because 3 extra bytes in the same packet isn't very much, what would be noticably slower is latency on the other hand" |
| 17:23 |
kaeza1 |
wait wait wait |
| 17:23 |
hmmmm |
i didn't say all of that though, i compress what i say usually |
| 17:23 |
hmmmm |
i already talk too much |
| 17:25 |
kaeza1 |
ehrm... what I mean is I don't waste space in the packets when it's not needed |
| 17:25 |
kaeza1 |
let me rephrase that |
| 17:25 |
kaeza1 |
I don't make packets bigger than they need to |
| 17:26 |
kaeza1 |
but when computing the flags, I use an u32 |
| 17:27 |
hmmmm |
that could be misleading though, somebody adding more flags might've thought later on that they have 32 flags to work with and not 8 |
| 17:27 |
|
ssieb joined #minetest-dev |
| 17:28 |
hmmmm |
and then in order to add more flags you'd have to bump the protocol version |
| 17:28 |
kaeza1 |
ummm... I don't get what you mean |
| 17:28 |
kaeza1 |
the bit to set/unset is selected by the 'id' field |
| 17:28 |
kaeza1 |
(which can go up to 255) |
| 17:28 |
hmmmm |
but what if builtin hud items had more than 8 attributes someday |
| 17:28 |
kaeza1 |
the flags field is just a boolean |
| 17:29 |
hmmmm |
that is misleading |
| 17:29 |
kaeza1 |
... |
| 17:29 |
kaeza1 |
define 'attributes' |
| 17:29 |
hmmmm |
if the flags field is merely a boolean, then it should be is_visible or whatever and not marked as "flags" |
| 17:29 |
|
sapier joined #minetest-dev |
| 17:29 |
kaeza1 |
I think we are not in the same channel |
| 17:29 |
hmmmm |
attributes, flags |
| 17:30 |
hmmmm |
details about the hud item that may be described with a "yes" and "no" |
| 17:30 |
hmmmm |
being visible is one such detail |
| 17:30 |
kaeza1 |
hrm... I don't care about other attributes |
| 17:30 |
hmmmm |
exactly |
| 17:30 |
hmmmm |
but i do |
| 17:30 |
kaeza1 |
and celeron neither |
| 17:31 |
hmmmm |
and making such a change to the protocol that's shortsighted would necessarily result in a protocol change later on if you do need to change it |
| 17:31 |
hmmmm |
not caring about other things is okay if it won't break compatibility later on |
| 17:31 |
kaeza1 |
well, again, do what you must and overcomplicate the stuff |
| 17:31 |
Exio |
he wants a general and super-long-term solution |
| 17:32 |
VanessaE |
[04-25 12:21] <hmmmm> pilzadam, is this supposed to be the desired translucency of ice? http://ompldr.org/vaTd4Yw <--- make it more transparent. |
| 17:32 |
PilzAdam |
VanessaE, its unusable anyway, so we dont get transparent ice yet |
| 17:32 |
hmmmm |
vanessae, i fixed my part of the code... i asked if that's how transparent he intended it to be |
| 17:32 |
PilzAdam |
s/unusable/too glitchy above water/ |
| 17:32 |
hmmmm |
and i disagree, it's totally usable with shaders enabled |
| 17:33 |
PilzAdam |
VanessaE, you use a not run in place installation, right? can you test this: https://github.com/minetest/minetest/pull/648 ? |
| 17:33 |
hmmmm |
but that's the thing, without shaders it's definitely broken when around other transparent nodes |
| 17:34 |
hmmmm |
the reason why i added it is because people could still benefit from it in most other cases. but i wouldn't recommend default usage of it in its current state |
| 17:34 |
PilzAdam |
hmmmm, the water under the ice disappears sometimes with shaders, at big lakes covered with ice thats not good |
| 17:34 |
hmmmm |
that's another issue, but it's much more minor in comparison |
| 17:35 |
hmmmm |
and with a high enough alpha (like what ice has now), you wouldn't notice it |
| 17:36 |
PilzAdam |
you do notice it in big lakes, thats the problem |
| 17:36 |
hmmmm |
just don't use the feature at this point |
| 17:37 |
PilzAdam |
yes |
| 17:37 |
hmmmm |
when we add transparency sorting, then we'll flick the switch on |
| 17:37 |
* VanessaE |
catches up |
| 17:38 |
hmmmm |
minecraft has the same issues we do, if you looked at the april fool's release, it does have colored glass as well but the reason why it's not in the game is because it's too buggy to be usable around other transparent nodes |
| 17:38 |
|
Jordach joined #minetest-dev |
| 17:38 |
hmmmm |
but the difference between us and minecraft is that nodes are defined in lua |
| 17:38 |
Jordach |
and we have a working mod api |
| 17:39 |
hmmmm |
so if people want cool stuff that has a bug with it, they can |
| 17:39 |
VanessaE |
hmmmm: "how transparent" -- gotchya. |
| 17:39 |
Exio |
mod api? it'll get released for 1.3, er, 1.4, er, 1.5, er 1.6! |
| 17:39 |
Exio |
</minecraft> |
| 17:39 |
VanessaE |
(he should *still* make it more transparent though) |
| 17:40 |
VanessaE |
PilzAdam: sure, I'll try that pull in a little bit |
| 17:41 |
VanessaE |
hmmmm: got a link to a commit I can use to test the current state of alpha code? |
| 17:42 |
PilzAdam |
VanessaE, engine is already upstream and here is the transparent ice: https://github.com/PilzAdam/common/commit/fb04d3f0ba5cec84757b84e437aaff2bd1a234b6 |
| 17:43 |
VanessaE |
ok |
| 17:44 |
VanessaE |
bringing those two in now. |
| 17:48 |
VanessaE |
favorites list works now. |
| 17:49 |
Exio |
Zeg9 already tried it |
| 17:49 |
VanessaE |
I don't see any effect on the ice. No alpha for me. |
| 17:51 |
VanessaE |
(with or without shaders) |
| 17:52 |
PilzAdam |
VanessaE, have you updated the engine? |
| 17:52 |
PilzAdam |
serverlist fix merged |
| 17:53 |
|
kaeza2 joined #minetest-dev |
| 17:54 |
VanessaE |
PilzAdam: yep, applied those two patches to their respective repos and did a git pull on both. |
| 17:55 |
VanessaE |
wait, I know why |
| 17:55 |
VanessaE |
forgot to actually apply your alpha ice. |
| 17:56 |
PilzAdam |
http://en.wikipedia.org/wiki/Facepalm |
| 17:56 |
PilzAdam |
:-p |
| 17:56 |
VanessaE |
:P |
| 17:58 |
VanessaE |
ok, ice works. |
| 17:58 |
VanessaE |
it still needs to be a *little* more transparent (maybe by another 20% at most) |
| 17:59 |
VanessaE |
re: server list... too bad it doesn't store passwords. |
| 18:00 |
VanessaE |
for me, the ice looks better *without* shaders btw |
| 18:00 |
VanessaE |
the alpha is perfect then |
| 18:01 |
VanessaE |
(other than the already-discussed z-sorting issue) |
| 18:03 |
VanessaE |
with shaders, the faces behind another alpha item (e.g. water) disappear, so ice in water looks like just a 2D surface on top, and any ice under the water is invisible from above |
| 18:03 |
VanessaE |
but I guess that's known. |
| 18:03 |
VanessaE |
that applies to dropped ice entities too btw |
| 18:04 |
VanessaE |
I'd have to say though, on land it looks pretty good |
| 18:05 |
VanessaE |
even clouds seem to be layered behind it like they should be |
| 18:06 |
VanessaE |
backface culling needs to be disabled for these sorts of nodes though |
| 18:07 |
VanessaE |
or at the very least, make sure the upper faces are also removed |
| 18:11 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/screenshot_1113776348.png |
| 18:12 |
VanessaE |
that's two stacks of two ice blocks diagonally adjacent, with a single ice block in the space behind/between them. If you pan the camera down so that the middle block disappears, the upper face of it is still visible. |
| 18:12 |
VanessaE |
but I guess you knew that. |
| 18:18 |
VanessaE |
interestingly, the alpha works with HDX's ice texture also -- but that texture doesn't have an alpha channel. |
| 18:19 |
|
Jordach joined #minetest-dev |
| 18:21 |
Calinou |
it always works |
| 18:22 |
Calinou |
it's not done on texture, it's done on engine... bad for textureability :/ |
| 18:24 |
VanessaE |
That's what I thought (I don't always follow the conversation too well) |
| 18:27 |
hmmmm |
when you say "the alpha works", you mean "turns whatever it is into a shadowy, translucent block"? |
| 18:28 |
VanessaE |
yep |
| 18:28 |
VanessaE |
see the above screenshot |
| 18:28 |
hmmmm |
that's not a bug |
| 18:29 |
hmmmm |
you're simply using it in a manner that is not intended |
| 18:29 |
VanessaE |
heh |
| 18:29 |
hmmmm |
i guess the regular textures don't _have_ alpha channels |
| 18:29 |
VanessaE |
I didn't say it was a bug, per se. :) |
| 18:29 |
hmmmm |
or they're set to some default like 128 |
| 18:29 |
VanessaE |
actually, the regular ice texture has an alpha channel, but HDX's one does not. |
| 18:30 |
VanessaE |
it's no big deal, I'm just relaying my observations is all. |
| 18:31 |
|
proller joined #minetest-dev |
| 18:41 |
rubenwardy |
sokomine: https://gist.github.com/rubenwardy/b5cd1a01049e0c935ecf |
| 18:41 |
rubenwardy |
damn |
| 18:51 |
|
ShadowNinja_ joined #minetest-dev |
| 18:54 |
proller |
need to commit, any objections? https://github.com/proller/minetest/commit/aa31c1663695aba28f48facea08de2158b71676d |
| 18:55 |
PilzAdam |
proller, the change in indev mapgen seems rather random to me |
| 18:56 |
proller |
200 cause core dump |
| 18:56 |
proller |
150 - not |
| 18:56 |
PilzAdam |
oh |
| 18:56 |
proller |
its very rare |
| 18:57 |
proller |
need to better debug, but this small fix helps |
| 18:58 |
proller |
its like at generating cave larger than loaded area, and something goes wrong |
| 18:58 |
proller |
will commit! |
| 19:00 |
|
drizz joined #minetest-dev |
| 19:02 |
|
Deivan joined #minetest-dev |
| 19:04 |
|
sapier joined #minetest-dev |
| 19:13 |
|
iqualfragile joined #minetest-dev |
| 19:29 |
VanessaE |
regarding the favorites list, can we please make that store passwords (well, hashes thereof)? It's about useless otherwise :-/ |
| 19:31 |
sapier |
no use to create a hash if it's used directly to authenticate player |
| 19:31 |
VanessaE |
well what does the client send to the server? surely not plaintext?? |
| 19:31 |
sapier |
as far as I know its plaintext |
| 19:32 |
sapier |
but I'd have to look in code to be sure |
| 19:32 |
VanessaE |
ewwww |
| 19:32 |
sapier |
did you think minetest has any security features? ;-) |
| 19:33 |
kahrl |
it sends the hash |
| 19:33 |
sapier |
it does? wow |
| 19:33 |
VanessaE |
kahrl: oh good. in that case, store the hash in the favorites list |
| 19:33 |
sapier |
salted hash? |
| 19:33 |
kahrl |
not sure. it didn't use salt when I last check, might have been added since then |
| 19:34 |
kahrl |
checked* |
| 19:35 |
sapier |
I doubt ... but I'll have a look ... still if password is directly hashed without salt fetched from server it's useless to improve security |
| 19:35 |
|
Jordach joined #minetest-dev |
| 19:35 |
sapier |
if it's not salted you can use rainbow tables |
| 19:35 |
kahrl |
it's salted with the player name |
| 19:35 |
VanessaE |
sapier: better to use an unsalted hash than plaintext. |
| 19:36 |
sapier |
no in fact it's no difference |
| 19:36 |
VanessaE |
which one takes longer to break? |
| 19:36 |
kahrl |
although dictionary/bruteforce attacks are still possible for weak passwords |
| 19:36 |
sapier |
none |
| 19:37 |
kahrl |
or reusing the hash for a different server if you learn it |
| 19:37 |
sapier |
it's more difficult to fetch network communication than to break unsalted hash |
| 19:37 |
VanessaE |
well since it's salted, the point is moot |
| 19:38 |
sapier |
true |
| 19:38 |
VanessaE |
I call the favorites list useless because a single click automatically joins that server...which if you need a password (like 90% of the ones out there), means you immediately get a permission denied. |
| 19:38 |
|
StrayBytes joined #minetest-dev |
| 19:38 |
|
StrayBytes joined #minetest-dev |
| 19:38 |
VanessaE |
(I talk good English, really I does.) |
| 19:38 |
sapier |
so at least passwort is difficult to fetch ... but logging in without authentication is still as simple as reading network traffic |
| 19:39 |
sapier |
so maybe a "enter password" dialog should be added? |
| 19:40 |
VanessaE |
no |
| 19:40 |
VanessaE |
we already have a password entry field |
| 19:40 |
sapier |
not everyone wants his password saved |
| 19:40 |
VanessaE |
just store the damn password hash and send it to the chosen server -- like every other login-capable application is capable of these days. |
| 19:40 |
kahrl |
add a 'save password' checkbox/config setting? |
| 19:40 |
VanessaE |
fine, so provide a checkbox, "[X] Save Password" |
| 19:40 |
VanessaE |
ninja'd by kahrl. :) |
| 19:41 |
sapier |
good enough |
| 19:41 |
celeron55 |
well, pretty much any human-written sha1 hashes are very fast to crack with proper tools |
| 19:41 |
sapier |
I just don't want my password/hash saved automaticaly without having a choice |
| 19:42 |
celeron55 |
because sha1 is optimized for speed 8) it really is just for a tiny bit of protection from the worst script kiddie server admins |
| 19:42 |
sapier |
celeron if player/pwd hash is sent without encryption to server this can be read by attacker and used directly so no need to crack it |
| 19:42 |
celeron55 |
sapier: of course it can be |
| 19:43 |
celeron55 |
i once wrote a proposal of how to improve this thing in a simple way to overcome that |
| 19:43 |
celeron55 |
i wonder where that is, hmm |
| 19:44 |
celeron55 |
it's here: http://c55.me/minetest2/wiki/doku.php?id=dev:slight_authentication_improvement |
| 19:44 |
sapier |
I don't know your proposal so I can't tell anything about it. generally speaking I always have doubt if someone implements security features her/himself instead of using proven existing solutions |
| 19:45 |
celeron55 |
(the bottom of that page isn't written by me) |
| 19:45 |
sapier |
this suggestion seams to be at least a full security level better than current solution |
| 19:46 |
kahrl |
agreed |
| 19:46 |
kahrl |
for the hash function maybe use PBKDF2? or is that outdated already? |
| 19:47 |
sapier |
hmm I assume sha2 is fine for minetests security level ;-) |
| 19:47 |
celeron55 |
anything of which we can easily get hold of a small portable properly licensed implementation |
| 19:47 |
ShadowNinja |
celeron55: That sounds good but the salt would have to be random every time |
| 19:47 |
sapier |
but maybe use 256bit |
| 19:47 |
celeron55 |
sapier: no, sha is not fine |
| 19:47 |
kahrl |
BSD license would be fine so we could use OpenBSD's implementation |
| 19:48 |
kahrl |
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libutil/pkcs5_pbkdf2.c?rev=HEAD |
| 19:48 |
celeron55 |
unless you use it eg. by recursively running it over itself like 1000 times; but that's pretty much what pbkdf2 does, but it takes possible problems that come from it into account 8) |
| 19:48 |
sapier |
isn't openssl license quite free? |
| 19:48 |
sapier |
ohh .. openssl and windows |
| 19:49 |
celeron55 |
ShadowNinja: that would mean storing a plaintext password on the server |
| 19:49 |
ShadowNinja |
Just using a stronger hash won't work, you can just send the hash without determining the password |
| 19:49 |
celeron55 |
ShadowNinja: it's not how password security is done |
| 19:49 |
sapier |
"properly licensed" implementation as primary argument for a security algorithm sounds wrong to me |
| 19:50 |
celeron55 |
sapier: haha what |
| 19:50 |
celeron55 |
if you are serious in what that implies, go to hell |
| 19:50 |
VanessaE |
this is all still offtopic though. |
| 19:50 |
sapier |
there are few correct implementations out there but hundreds of wrong, if you only consider license you most likely will get one of the later |
| 19:51 |
celeron55 |
"properly licensed" = "compatible with lgpl"; and we make no exceptions to this |
| 19:51 |
celeron55 |
sapier: these days the world is full of good MIT/BSD implementations of everything, especially of security stuff |
| 19:51 |
sapier |
is openssl license really incompatible to lgpl? |
| 19:52 |
ShadowNinja |
No, the server would send a random salt or the client would generate a salt only good for that connection, the client would use that salt with the password and the server would then use that salt to check it, an attacker wouldn't be able to enter because the salt would be different for each connection. |
| 19:52 |
VanessaE |
celeron55: fuck it, go all out and pull stuff from that one hardened distro, I forget which one it was :) |
| 19:52 |
VanessaE |
(I keep thinking netbsd) |
| 19:52 |
ShadowNinja |
Tails? |
| 19:52 |
celeron55 |
ShadowNinja: ah that way; i think that's usually called a nonce |
| 19:55 |
sapier |
server stores hash of playername+pwd |
| 19:55 |
sapier |
sends salt to client |
| 19:55 |
sapier |
client hashes salt with hash of playername+pwd |
| 19:55 |
sapier |
server can check result |
| 19:56 |
ShadowNinja |
Exactly |
| 19:56 |
ShadowNinja |
Would that work? |
| 19:56 |
kahrl |
how will the initial password be set, by the way? |
| 19:56 |
sapier |
same as now |
| 19:56 |
celeron55 |
sapier: i don't care about openssl's license; openssl is terrible anyway 8) |
| 19:57 |
sapier |
salt to client |
| 19:57 |
sapier |
hmm |
| 19:57 |
sapier |
you're right |
| 19:57 |
celeron55 |
sapier: also, the license is incompatible with almost anything because of their naming clauses |
| 19:57 |
sapier |
I doubt that out lawyers don't even stop us from linking openssl to our products |
| 19:58 |
celeron55 |
kahrl: if that nonce stuff is used for regular auth, the first time needs to be as in my proposal |
| 19:58 |
VanessaE |
brb |
| 19:58 |
celeron55 |
we don't need even 1% of what openssl contains anyway; better use some more minimal library |
| 19:59 |
sapier |
do what you believe to be good still I strongly suggest to be very carefull when deciding for a library |
| 19:59 |
|
VanessaE joined #minetest-dev |
| 20:00 |
sapier |
your suggestion won't solve the initial problem celeron |
| 20:00 |
sapier |
I don't see a solution to fix the problem with initial password setting |
| 20:02 |
celeron55 |
i don't think that old proposal of mine would be particularly good; but i also think that your mindset to security will not result in anything useful either |
| 20:03 |
sapier |
I just wanted to stop this discussions, I've told my concerns, decision what to do isn't mine |
| 20:03 |
sapier |
I'm realistic enough to know my only possibilities are either accept the decision what ever it will be or leave ... for now I don't feel like leaving |
| 20:04 |
celeron55 |
i do have like 1000x more experience in cryptography (due to work) than when i wrote the current authentication stuff and would write proper encryption for login without using the most bloated of libraries out there |
| 20:04 |
celeron55 |
but it's once again a matter of where i want to put my time in |
| 20:04 |
celeron55 |
s/would/could/ |
| 20:05 |
celeron55 |
but |
| 20:06 |
sapier |
it's been bad for some time now it won't be a problem to stay like that for som months ... I just want to stop/slow down changes in wrong direction |
| 20:06 |
celeron55 |
in any case, in any proper implementation, there are only two options for logging in onto a server without entering a password: storing plaintext passwords on the client, or a proper private/public key authentication system |
| 20:07 |
sapier |
true and proper private public key seams to be a little bit overkill for minetest |
| 20:07 |
kahrl |
hmm? |
| 20:07 |
celeron55 |
the first is what web browsers do when they ask whether you want them to remember a password |
| 20:07 |
celeron55 |
sapier: well maybe or maybe not; it's quite easy when you know what you're doing |
| 20:07 |
kahrl |
can't you store the hashed password (salted w/ username) and use that as the basis for whatever fancy authentication scheme you use in the network protocol |
| 20:07 |
sapier |
yes ... that's where this discussion started, I wanted to have choice if client stores password or not |
| 20:08 |
celeron55 |
kahrl: yes; but from the standpoint of the protocol, that's the plaintext password |
| 20:08 |
kahrl |
as long as it's only stored on the user's machine and not sent over the network I wouldn't worry |
| 20:09 |
kahrl |
user is responsible for his machine security |
| 20:09 |
kahrl |
and it's better than storing the plaintext password |
| 20:09 |
sapier |
as any mod can send this password :-) |
| 20:09 |
kahrl |
not if you read the mod's code ;) |
| 20:10 |
celeron55 |
well, in any implementation that does no have an encrypted network protocol, it must go in an unencrypted and unhashed form to the server when the player registers or sets a new password |
| 20:10 |
sapier |
I don't wanna read that argument anymore as noone does this |
| 20:10 |
kahrl |
I do. Argument refuted ;) |
| 20:10 |
sapier |
lol I'm sorry but I don't believe you ;-) |
| 20:11 |
kahrl |
but I don't install hundreds of mods either |
| 20:11 |
kaeza |
soon: Fortknoxtest :D |
| 20:11 |
kaeza |
(C) 2013 Sapier |
| 20:12 |
sapier |
kaeza if ANY other person would think at least a little bit about security I wouldn't have to stand at a that extreme position to get at least a little bit really included ;-) |
| 20:13 |
sapier |
if you summarize about medium value of security positions found in minetest community (including my extreme position) you'll have what I personaly think needs to be done ;-) |
| 20:13 |
kaeza |
meh |
| 20:14 |
sapier |
but something completely different, is there any chance to trigger a travis build? |
| 20:14 |
kaeza |
I don't care what you do, but just don't get in anyone's way with your mod security |
| 20:14 |
kaeza |
now, I go back to code |
| 20:15 |
sapier |
kaeza have a look at commits of last 3 months I believe I don't stand in anyones way |
| 20:16 |
sapier |
hmm ... considering collision box commit maybe I do stand in someones way :-P |
| 20:17 |
kaeza |
well... the benefit may outweigh the problems |
| 20:18 |
sapier |
lol you won't realize benefit if by my pressing to add security features your computer will be saved by malware ;-) |
| 20:19 |
sapier |
but I still don't understand how travis system works is anyone here who does? |
| 20:20 |
celeron55 |
it's set up by thexyz |
| 20:20 |
sapier |
I assume I'll have to setup a vm containing gcc4.6 to find out if my patches work then |
| 20:26 |
kaeza |
hmmmm, misc: /home/diego/src/minetest/src/main.cpp:1694:28: warning: 'dtime' may be used uninitialized in this function [-Wuninitialized] |
| 20:27 |
kaeza |
err.... wrong line |
| 20:27 |
kahrl |
kaeza: I saw that warning but it's a false positive |
| 20:28 |
kaeza |
kahrl, I know, I just like a compilation to go with as less warnings as possible |
| 20:29 |
kaeza |
even if stuff is harmless |
| 20:29 |
celeron55 |
sapier: by the way, the insecure file and lua function restrictions are still on the list of things i want to merge as soon as they are made in the way that i see as good; ask me some day if there's something unclear about that |
| 20:30 |
celeron55 |
i think i did try to explain that a while back |
| 20:30 |
sapier |
I've put them "on hold" until the scriptapi changes are included. Is there any particular thing missing? |
| 20:30 |
|
VanessaE joined #minetest-dev |
| 20:31 |
sapier |
Imho I've already added your suggestions, maybe I didn't understand everything correct? |
| 20:32 |
sapier |
btw if we allow loading of debug module any "local func" will be useless as you may access any part of stack by using debug functions even local variables of other files |
| 20:34 |
celeron55 |
i think #495 is quite on the right track; i'll try to find the time to test it once you have painfully rebased it again 8) |
| 20:35 |
sapier |
thx ... I'll do that after the scriptapi patch is merged ... my time is limited too so merging to current just to merge to scriptapi later isn't quite a thing I want to do |
| 20:36 |
sapier |
as noone is eager to have security included I think setting priorities this way will be fine |
| 20:36 |
PilzAdam |
sapier, can you add a param to object definition to disable object <-> object collision for it? falling items stopping you is pretty annyoing, especially in the TNT mod (wich creates tons of them) |
| 20:37 |
celeron55 |
we have good security included in our user's heads and distribution channels currently, so there's nothing to worry about |
| 20:37 |
sapier |
hmm non solid objects shouldn't stop you pilzadam |
| 20:37 |
celeron55 |
but once the game can download mods by itself from a repository, then this must have been in place and well tested for a while before that happens |
| 20:38 |
PilzAdam |
sapier, the only way to disable it currently is set physical = false, but that also disables node collision |
| 20:39 |
sapier |
true.. hmm I'll have to think about it ... imho adding a real collision system would be correct way to fix this but it's a lot of work |
| 20:39 |
sapier |
with "real collision system" meaning some sort of "realistic" crashes |
| 20:40 |
kaeza |
just add void *p = NULL; *p = 0; |
| 20:40 |
kaeza |
there you have a reaalistic crash :D |
| 20:40 |
sapier |
hmm I believe nothing will happen if you add this |
| 20:40 |
sapier |
ohh first is a declaration |
| 20:40 |
sapier |
ok ok |
| 20:41 |
sapier |
realistic collision system would mean adding some sort of mass to each node ;-) if that was added collision s could be calculated quite easy ... but I'm not sure if this is a feature that is really wanted? |
| 20:42 |
sapier |
any opinions about it? |
| 20:42 |
kahrl |
if that means physics would be less glitchy I'd be for it |
| 20:43 |
kahrl |
as long as it's reasonable in terms of performance |
| 20:44 |
kahrl |
< is allowed to complain because he added some of the glitches in the first place |
| 20:46 |
sapier |
there will be a performance impact as it's adding additional calculations but imho this should be less than impact of o<->o collision |
| 20:46 |
|
salamanderrake joined #minetest-dev |
| 20:48 |
celeron55 |
well a properly optimized actual physics library shouldn't really take more resources than what MT's naive stuff takes now |
| 20:48 |
celeron55 |
but there would be problems in such |
| 20:48 |
sapier |
true but adding this is really lots of work ;-) |
| 20:48 |
celeron55 |
eg. player movement has become very finely tuned along the years |
| 20:49 |
celeron55 |
porting it to some library would be painful |
| 20:49 |
celeron55 |
also such a library would imply that we add proper support for rotation on every axis |
| 20:49 |
celeron55 |
and whatever |
| 20:50 |
celeron55 |
not a small thing in any way |
| 20:50 |
kahrl |
I don't think player movement would have to be 100% identical |
| 20:50 |
kahrl |
just make sure jumping up hills/stairs is not annoying, support sneak ladders and things like that |
| 20:50 |
VanessaE |
jeez, I mention the need to store a password in the favorites list and it morphs into a whole discussion on network security.7 |
| 20:50 |
VanessaE |
heh |
| 20:50 |
celeron55 |
no, but there are some things in place that make it much better than without those things |
| 20:50 |
VanessaE |
-7 |
| 20:50 |
celeron55 |
and those things aren't really standard physics library stuff |
| 20:51 |
kahrl |
yeah, I don't think just using any external library would work without investing lots of extra work |
| 20:51 |
|
VanessaE joined #minetest-dev |
| 20:52 |
sapier |
can someone merge this fix: https://github.com/minetest/minetest/pull/613 |
| 20:52 |
celeron55 |
if i did start MT from scratch, i would use a physics library; but now it's a wholly different situation |
| 20:58 |
hmmmm |
:( |
| 20:59 |
hmmmm |
my authentication idea is nonsense |
| 20:59 |
hmmmm |
and it's not really mine either |
| 21:00 |
hmmmm |
erm, the next level of security above that one would be SRP |
| 21:00 |
hmmmm |
and then above that is the server sending the client polymorphically modified authentication modules that the client executes and returns the result of |
| 21:00 |
hmmmm |
and so on |
| 21:01 |
hmmmm |
if you really think minetest password security is that important, perhaps you should use SRP, but that would require us to add libgmp as a dependency and it's easily another source file worth of code |
| 21:01 |
hmmmm |
but if it's that important to you...... besides, it's your time, not ours |
| 21:01 |
sapier |
lol ... and me is called overcomplicated ;-P ... btw who will protect client about malicious servers if server sends executable code ;-) |
| 21:02 |
hmmmm |
the obvious answer to that would be for us to buy a key from verisign and authenticate binaries with it |
| 21:03 |
sapier |
true .. who starts collecting money? |
| 21:03 |
hmmmm |
we'd use the donations that are typically put toward hosting |
| 21:04 |
hmmmm |
it was a joke though, don't get any ideas |
| 21:04 |
sapier |
I think this might be an option once all of the other security issues are fixed ... but that won't be for quite some time ;-) |
| 21:05 |
hmmmm |
SRP seems to be good enough for large commercial games |
| 21:05 |
celeron55 |
oh SRP |
| 21:05 |
celeron55 |
this seems worth investigating: http://freecode.com/projects/tinysrp |
| 21:08 |
hmmmm |
SEMinetest |
| 21:08 |
sapier |
i wonder when this battery will be depleted it told 7 minutes left 30 min ago :-) |
| 21:08 |
celeron55 |
looks pretty good; no bloated dependencies and builds right away in no time on this linux box |
| 21:09 |
celeron55 |
and the tarball has just a flat bunch of source files and few others |
| 21:09 |
sapier |
recent release 2001? |
| 21:09 |
|
Taoki joined #minetest-dev |
| 21:11 |
hmmmm |
it includes its own big number library? |
| 21:11 |
celeron55 |
it has a "stripped-down version of openssl" which actually means it basically has a few of it's bignum source files and some hash function |
| 21:12 |
sapier |
and openssl from 2001 should be checked for fixes that have been aplied to that code in openssl until now |
| 21:13 |
celeron55 |
i wouldn't guess there would be considerable bugs in '01 openssl's bignum stuff, but it's worth checking though |
| 21:17 |
|
TB`oFF|Vibe-X joined #minetest-dev |
| 21:19 |
celeron55 |
the most recent fixes that have a chance of mattering are at 0.9.6->0.9.6a (2001-04-05) |
| 21:20 |
celeron55 |
if 0.9.6a isn't used in there, that's easy to backport :P |
| 21:21 |
sapier |
are you sure 0.9.6a is maintained anymore and issues of later versions aren't present in 0.9.6a too? ;-) |
| 21:22 |
hmmmm |
the only way we'd know is with a complete source code audit |
| 21:22 |
celeron55 |
i'm sure any remaining issues in heavily actively used base code of openssl would have been found in 12 years 8) |
| 21:22 |
sapier |
this last minute of battery power already lasts for half almost 15 minutes :-) |
| 21:22 |
hmmmm |
let's go for it! |
| 21:22 |
celeron55 |
http://members.tripod.com/professor_tom/archives/libtinysrp-0.7.5.tar.gz |
| 21:23 |
celeron55 |
there's just 6k SLOC anyway 8) |
| 21:23 |
sapier |
I've already done 10 audits this month no need to do another one |
| 21:26 |
kahrl |
tinysrp is based on srp-1.7.1 which doesn't support SRP-6. is that a problem? |
| 21:27 |
hmmmm |
i believe so |
| 21:27 |
hmmmm |
also just an aside, if we're really doing SRP, you better go all-out and use SHA512 |
| 22:04 |
VanessaE |
since pilzadam's already gone... flowers got added to common and are included via game.conf in build and survival - any particular reason minetest_game doesn't also use them? |
| 22:15 |
|
drizz joined #minetest-dev |
| 22:15 |
|
ssieb joined #minetest-dev |
| 22:15 |
|
dzho joined #minetest-dev |
| 22:29 |
kaeza |
hmmmm, I mean to not be interrupted by misc stuff in there |
| 22:29 |
hmmmm |
oh |
| 22:30 |
hmmmm |
i'm trying to find another packet that only modifies the local player and nothing else |
| 22:31 |
Exio |
if you see any what does that - tell me |
| 22:31 |
Exio |
it'll be useful for looking for some code i want to try |
| 22:31 |
hmmmm |
nope |
| 22:31 |
hmmmm |
it seems to be quite reasonable |
| 22:32 |
hmmmm |
basically you see packets processed like this: |
| 22:32 |
hmmmm |
if it modifies some client data structure, it'll just change it right there in the packet handler |
| 22:32 |
hmmmm |
if it modifies a variable in the_game(), such as camera rotation or whatever, it'll use a client event for that |
| 22:33 |
hmmmm |
for example, TOCLIENT_HP, TOCLIENT_MOVEMENT, TOCLIENT_MOVE_PLAYER, etc. |
| 22:36 |
hmmmm |
why do people not line things up |
| 22:36 |
Exio |
k, thanks |
| 22:36 |
Exio |
and, line things up? what? |
| 22:36 |
hmmmm |
this is probably just my OCD but people who don't line assignment operations up are truly worse than hitler |
| 22:37 |
hmmmm |
who did the physics.... |
| 22:42 |
khonkhortisan |
what're line assignment operators? |
| 22:42 |
khonkhortisan |
or rather, the absense of? |
| 22:42 |
hmmmm |
player.cpp:63 |
| 22:42 |
hmmmm |
you might not want to look, it will probably cause eye damage |
| 22:43 |
khonkhortisan |
BS? I've dealt with it already |
| 22:43 |
hmmmm |
it's a bunch of BS |
| 22:43 |
hmmmm |
12 of them |
| 22:45 |
Exio |
taoki's code iirc |
| 22:45 |
khonkhortisan |
If you're not careful, you'll get a line like this m_vertices[i].Pos.rotateXZBy(atan2(ppos.Z/BS-m_pos.Z, ppos.X/BS-m_pos.X)/core::DEGTORAD+90); the positions really should be in the same units but they weren't at that specific place |
| 22:46 |
Taoki |
Which code exactly? Doesn't sound like me |
| 22:46 |
Exio |
https://github.com/minetest/minetest/blob/master/src/player.cpp#L64 |
| 22:46 |
khonkhortisan |
#define BS (10.0) |
| 22:46 |
khonkhortisan |
"to disallow plain casts" |
| 22:46 |
Taoki |
Ah, that. Those are the defaults for the physics settings |
| 22:47 |
hmmmm |
that doesn't bother you? |
| 22:47 |
hmmmm |
look at how they're all over the place |
| 22:47 |
Taoki |
What? What's all over the place, and what should bother me (if you mean my code)? |
| 22:47 |
khonkhortisan |
To set a variable: variable = number * 10; to get a variable: result = variable / 10; |
| 22:47 |
hmmmm |
the assignment operations |
| 22:48 |
hmmmm |
it's like you walk into a classroom and the desks are scattered everywhere |
| 22:48 |
Taoki |
I think they were meant to be modifiers to the defaults. Don't remember exactly why I did them, nor what's wrong about them |
| 22:48 |
hmmmm |
whatever |
| 22:48 |
khonkhortisan |
They are there to get in your way |
| 22:49 |
khonkhortisan |
We should just overload = to multiply or divide by BS |
| 22:49 |
Taoki |
Oh. I think they where there to not break compatibility with clients that didn't have the new physics code |
| 22:49 |
Taoki |
Or servers. Since if those default values wouldn't be there, clients would get no physics on old servers and be stuck |
| 22:50 |
Taoki |
hmmmm: ^ |
| 22:50 |
Taoki |
If you have a better way to prevent that, you can change the initializations, if it doesn't change how things work otherwise. You can even remove them if you wish, since the physics have been in for a long time and connecting to the previous server version should work |
| 22:50 |
hmmmm |
khonkhortisan: lol |
| 22:50 |
hmmmm |
taoki, no that's not what i was saying at all |
| 22:50 |
Taoki |
But it would break compatibility with servers under that change |
| 22:51 |
hmmmm |
apparently the assignments not being lined up does not phase you in the slightest |
| 22:51 |
Taoki |
ok. Still can't get it, sorry. Prolly cuz I'm a bit tired too. But I remember those definitions were necessary |
| 22:51 |
Taoki |
ah. You'd prefer they were all in one line? |
| 22:51 |
hmmmm |
n... no |
| 22:51 |
hmmmm |
in one column |
| 22:52 |
hmmmm |
but i already did it |
| 22:52 |
hmmmm |
http://pastebin.com/qpwY3kfC |
| 22:53 |
|
mrtux joined #minetest-dev |
| 22:55 |
Taoki |
Aah. You meant using tabs to keep the values in order. Yes, that does look better... I didn't notice it |
| 22:55 |
hmmmm |
not tabs, spaces |
| 22:55 |
hmmmm |
for lining operators up, use spaces |
| 22:55 |
Taoki |
I usually add tabs there, but whatever works |
| 22:55 |
hmmmm |
i don't get how somebody can't notice that |
| 22:55 |
hmmmm |
doesn't it hurt your eyes a little? |
| 22:56 |
khonkhortisan |
I put four/five spaces before my if to line up with my elseif/else if |
| 22:56 |
Taoki |
It does look better like that. But there are cases where I don't notice such detail |
| 22:56 |
Taoki |
I agree it's preferable though, and good to correct |
| 22:57 |
Taoki |
I do try to always keep code clean and readable. But some things slip past me too :P |
| 22:57 |
hmmmm |
i do small things like that if i'm working somewhere with code looking like that and it bothers me enough |
| 23:01 |
hmmmm |
khonkhortisan, if i recall correctly, you mentioned that the crosshair is a pixel off in each direction |
| 23:02 |
hmmmm |
let's see... according to http://irrlicht.sourceforge.net/docu/classirr_1_1video_1_1_i_video_driver.html, the beginning and ending positions are inclusive |
| 23:02 |
khonkhortisan |
Yes, It doesn't draw the end pixel |
| 23:02 |
hmmmm |
so let's assume displaycenter is (50, 50) |
| 23:02 |
khonkhortisan |
Or draw at all if the start and end are equal |
| 23:02 |
hmmmm |
it draws from (40, 50) to (60, 50) |
| 23:02 |
hmmmm |
that's 20 pixels |
| 23:03 |
hmmmm |
which is an even number |
| 23:03 |
hmmmm |
are you absolutely sure? "Draws a 2d line. Both start and end will be included in coloring. " |
| 23:04 |
khonkhortisan |
Shouldn't it be drawing 21 pixels? 10 left, the center, 10 right? |
| 23:05 |
hmmmm |
hmm |
| 23:05 |
hmmmm |
suppose we had a really small screen with a resolution of 2x2 |
| 23:05 |
hmmmm |
what would the displaycenter be |
| 23:05 |
Exio |
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
| 23:05 |
Exio |
between 40 to 60 |
| 23:05 |
hmmmm |
oh |
| 23:05 |
hmmmm |
:/ he's got me |
| 23:06 |
hmmmm |
so you're right, it should be drawing 21 pixels, and indeed it does |
| 23:06 |
hmmmm |
but you said it was still off |
| 23:06 |
khonkhortisan |
I'm seeing 10 left, 1 center, and 9 right when I take a screenshot |
| 23:06 |
kahrl |
I always thought rendering details like that were dependent upon the video driver |
| 23:06 |
khonkhortisan |
Also 10 up, 1 center, 9 down |
| 23:06 |
khonkhortisan |
They are. |
| 23:06 |
hmmmm |
kahrl, not when it says it explicitly in the irrlicht documentation |
| 23:06 |
khonkhortisan |
it's drawing from displaycenter-10 to displaycenter+10 |
| 23:06 |
khonkhortisan |
and it ends up lopsided |
| 23:07 |
kahrl |
hmmmm, might have been some guy testing it only on selected hardware and writing it into the docs |
| 23:07 |
hmmmm |
so anyway according to game.cpp:1418, displaycenter is screensize.X / 2, screensize.Y / 2 |
| 23:07 |
hmmmm |
so our display center would be (1, 1) |
| 23:07 |
hmmmm |
if we take displaycenter to be a literal coordinate, that'd be the right bottom pixel |
| 23:08 |
khonkhortisan |
topleft |
| 23:08 |
hmmmm |
er |
| 23:08 |
hmmmm |
top left? |
| 23:08 |
hmmmm |
how do you get that, lol. |
| 23:08 |
Exio |
0,0 0,1 1,0 1,1 |
| 23:09 |
khonkhortisan |
I did some tests at low coordinates with draw2DLine |
| 23:09 |
hmmmm |
X = 0 is at the right, though? that's hard to believe |
| 23:10 |
khonkhortisan |
X is ltr, Y is ttb |
| 23:10 |
hmmmm |
right |
| 23:10 |
hmmmm |
so it would be top right |
| 23:10 |
hmmmm |
not top left |
| 23:10 |
khonkhortisan |
left. |
| 23:10 |
hmmmm |
erm |
| 23:11 |
kahrl |
could antialiasing have an effect? |
| 23:11 |
khonkhortisan |
-Y |
| 23:11 |
khonkhortisan |
-X +X |
| 23:11 |
khonkhortisan |
+Y |
| 23:11 |
hmmmm |
so if kahrl is right on this and i suppose he is, it's something out of our control anyway and we shouldn't have to worry about it |
| 23:11 |
khonkhortisan |
The lines are solid. I hope it's not antialiasing. |
| 23:11 |
khonkhortisan |
I want to draw black outlines around the cursor and/or only draw the center pixel once so the alpha value is correct |
| 23:12 |
kahrl |
use an image? |
| 23:12 |
khonkhortisan |
If for some reason the image isn't there the crosshair loses its outline again |
| 23:14 |
Exio |
with https://github.com/minetest/minetest/pull/653? |
| 23:15 |
hmmmm |
do people still want that ^? |
| 23:15 |
hmmmm |
there's the HUD API now... |
| 23:15 |
hmmmm |
since i'm doing hud things i'd throw it in |
| 23:15 |
Exio |
#306 with support for changing crosshair_color/alpha. and updated to the actual code. |
| 23:15 |
Exio |
crosshair_color/alp`ha |
| 23:15 |
Exio |
alpha * |
| 23:16 |
Exio |
i personally use pink/purple crosshair/selectionbox |
| 23:43 |
kaeza |
hmmmm, some people want per-player textures, but I'd prefer it to be server-side as it is with the HUD API |
| 23:43 |
kaeza |
(I mean local textures) |
| 23:43 |
kaeza |
err... whatever, you get what I meant |
| 23:44 |
hmmmm |
hmm |
| 23:44 |
hmmmm |
this is a rather controversial topic... i'd rather get a vote on it |
| 23:44 |
kaeza |
actually... I think both can coexist |
| 23:45 |
|
Pentium44 joined #minetest-dev |
| 23:47 |
kaeza |
derp |
| 23:47 |
kaeza |
the selection box could've made configurable as well |
| 23:48 |
kaeza |
meh |
| 23:48 |
kaeza |
perhaps a per-client one (assuming there's none currently) |
| 23:51 |
Exio |
kaeza: ? |
| 23:51 |
Exio |
selectionbox_color? |
| 23:52 |
kaeza |
Exio, just talking to myself |
| 23:52 |
kaeza |
I know about that one ;) |
| 23:53 |
hmmmm |
if i am going to do this, i'll merge that pull request as-is |
| 23:54 |
hmmmm |
does anybody have a problem with this? https://github.com/EXio4/minetest/commit/b5e7d9bd419f96706006247ff6c74d2c34317061 |
| 23:56 |
kaeza |
looks good |
