| Time |
Nick |
Message |
| 00:22 |
|
cheapie joined #minetest-dev |
| 00:40 |
|
EvergreenTree joined #minetest-dev |
| 01:21 |
|
Kray_ joined #minetest-dev |
| 01:21 |
|
daspork_ joined #minetest-dev |
| 01:25 |
|
deltib joined #minetest-dev |
| 01:25 |
|
Taoki_1 joined #minetest-dev |
| 01:26 |
|
SmugLeaf joined #minetest-dev |
| 01:26 |
|
SmugLeaf joined #minetest-dev |
| 02:10 |
|
Miner_48er joined #minetest-dev |
| 02:15 |
|
OldCoder joined #minetest-dev |
| 03:21 |
|
mrtux_ joined #minetest-dev |
| 04:28 |
|
kaeza joined #minetest-dev |
| 05:10 |
|
proller joined #minetest-dev |
| 05:30 |
|
Exio4 joined #minetest-dev |
| 05:40 |
|
us`0gb joined #minetest-dev |
| 05:49 |
|
Eater4 joined #minetest-dev |
| 06:04 |
|
us`0gb joined #minetest-dev |
| 06:21 |
|
salamanderrake joined #minetest-dev |
| 06:21 |
|
Exio4 joined #minetest-dev |
| 07:15 |
|
darkrose joined #minetest-dev |
| 07:33 |
|
darkrose joined #minetest-dev |
| 08:24 |
|
Taoki[mobile] joined #minetest-dev |
| 08:32 |
|
troller joined #minetest-dev |
| 08:46 |
|
rsiska joined #minetest-dev |
| 08:53 |
|
Taoki[mobile] joined #minetest-dev |
| 09:30 |
|
kaeza joined #minetest-dev |
| 09:35 |
|
Jordach joined #minetest-dev |
| 09:37 |
|
Taoki[mobile] joined #minetest-dev |
| 09:43 |
|
smoke_fumus joined #minetest-dev |
| 10:14 |
|
proller joined #minetest-dev |
| 10:27 |
|
proller joined #minetest-dev |
| 11:23 |
|
restcoser joined #minetest-dev |
| 11:38 |
|
iqualfragile joined #minetest-dev |
| 11:38 |
|
PenguinDad joined #minetest-dev |
| 12:01 |
|
Shardvex joined #minetest-dev |
| 12:29 |
|
Saunterer joined #minetest-dev |
| 12:37 |
|
PilzAdam joined #minetest-dev |
| 12:57 |
|
hmmmm joined #minetest-dev |
| 13:20 |
|
proller joined #minetest-dev |
| 13:21 |
|
rubenwardy joined #minetest-dev |
| 14:04 |
|
zat joined #minetest-dev |
| 14:30 |
|
PilzAdam joined #minetest-dev |
| 14:31 |
Taoki_1 |
Hi. Can anyone help me out with something? Where would I go if I wanted to make the local player visible? As in for a code allowing 3rd person view |
| 14:32 |
Taoki |
Do I only need to look in content_cao.cpp, or is the server not sending appearance of local player either? |
| 14:33 |
PilzAdam |
Taoki, https://forum.minetest.net/viewtopic.php?id=5397 https://forum.minetest.net/viewtopic.php?id=7289 |
| 14:33 |
Taoki |
Nice. Might combine my code with yours then |
| 14:34 |
Taoki |
Finally getting around to implementing a lua function which can offset a player's camera |
| 14:34 |
Taoki |
I'm adding a flag for 3rd person view as well |
| 14:34 |
PilzAdam |
also #1114 |
| 14:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/1114 -- Add third person view by BlockMen |
| 14:35 |
Taoki |
That might be overriden by my patch. This does a lot more... lets you offset and transition the position / rotation / fov of the camera. Useful for vehicles, bed mode, etc |
| 14:38 |
Taoki |
I think I won't add the code to see your own player though... so people can combine my code with their own 3rd person system later. Will see |
| 14:40 |
|
werwerwer joined #minetest-dev |
| 14:40 |
|
proller joined #minetest-dev |
| 14:45 |
|
Garmine joined #minetest-dev |
| 14:46 |
|
BrandonReese joined #minetest-dev |
| 14:53 |
|
Shardvex joined #minetest-dev |
| 15:12 |
Taoki |
https://github.com/minetest/minetest/pull/1215 Scripted camera ready for testng, if anyone is interested |
| 15:16 |
sfan5 |
looks interesting |
| 15:18 |
|
rsiska joined #minetest-dev |
| 15:24 |
sfan5 |
https://github.com/minetest/minetest_game/pull/250 |
| 15:24 |
sfan5 |
^ comments please |
| 15:24 |
PilzAdam |
sfan5, should be done in a mod |
| 15:24 |
sfan5 |
I told you already |
| 15:25 |
|
iqualfragile joined #minetest-dev |
| 15:25 |
sfan5 |
people want new content by default, they do not want to install a mod for one shitty node |
| 15:25 |
sfan5 |
also you can't keep on denying any changes to minetest_game like it's your propertry |
| 15:25 |
sfan5 |
property* |
| 15:26 |
PilzAdam |
you asked for comments |
| 15:26 |
sfan5 |
I am not asking for a whole aspect of the game to be changed |
| 15:26 |
sfan5 |
I am asking for ONE FUCKING THING to be included |
| 15:26 |
sfan5 |
yes I did, but I did not say that I won't respond to comments |
| 15:30 |
sfan5 |
any other comments? |
| 15:32 |
|
sapier joined #minetest-dev |
| 15:33 |
Taoki |
hi sapier |
| 15:33 |
sapier |
hello |
| 15:34 |
Taoki |
how is? |
| 15:34 |
sapier |
I'm already looking at your patch ;-) |
| 15:35 |
Taoki |
Ah, ok :) Figured out what I wanted to ask xD |
| 15:35 |
sapier |
seems to be quite clean for first look |
| 15:36 |
sapier |
I wonder if there's a conflict to camera offset added by linking entitys |
| 15:39 |
sapier |
drawWieldedTool(LocalPlayer* player) I'd not pass whole player here |
| 15:40 |
sapier |
to be more precise I'd not change that function at all and do the check prior calling it |
| 15:42 |
|
Calinou joined #minetest-dev |
| 15:42 |
sapier |
camera.cpp L379 ... I'm not sure if this is how I'd expect it to behave ... but I don't know if there's a sane way to mix those two features at all |
| 15:42 |
Taoki |
sapier: I need to check if the player has the camera_eye bool enabled. But I might be able to do the check where the function is called rather than in it... and just pass a boolean to that function. Not really sure how to do it |
| 15:43 |
Taoki |
sapier: Already tested that too, works perfectly well at least. Kinda funny the current code gets the setting each frame, but it's where the offset itself should also be added |
| 15:43 |
sapier |
you return from taht function immediatly if camera_override_eye is false why even call it in this case? |
| 15:44 |
Taoki |
... right. I'll fix that right away and amend the commit |
| 15:45 |
sapier |
take your time there might be other issues ... well 379 is a matter of taste I don't have time to test it live right now maybe I see issues where none are |
| 15:45 |
|
sapier left #minetest-dev |
| 15:46 |
Taoki |
OK. I looked and as far as I know it doesn't conflict anything currently in master at least. The offset should be applied just in the right spot |
| 15:50 |
|
BrandonReese joined #minetest-dev |
| 16:01 |
|
rubenwardy joined #minetest-dev |
| 16:01 |
|
tomreyn joined #minetest-dev |
| 16:02 |
|
Shardvex joined #minetest-dev |
| 16:05 |
|
Shardvex joined #minetest-dev |
| 16:21 |
|
BlockMen joined #minetest-dev |
| 16:23 |
BlockMen |
Taoki, instead of "invalidating" my 3rd person patch you could make it compatible and allow camera change only when not in third person view (which make IMO more sense) |
| 16:24 |
Calinou |
camera change? |
| 16:24 |
Calinou |
(please avoid senseless restrictions whenever possible) |
| 16:24 |
Calinou |
(Minetest isn't about random restrictions) |
| 16:25 |
proller |
http://threejs.org/examples/webgl_geometry_minecraft_ao.html |
| 16:26 |
Calinou |
Painterly: how to make something beautiful look ugly |
| 16:31 |
BlockMen |
senseless restrictions? third person view shouldnt be done serverside by lua... |
| 16:32 |
BlockMen |
s/done/controled |
| 16:33 |
|
Shardvex joined #minetest-dev |
| 16:35 |
Calinou |
indeed |
| 16:44 |
rubenwardy |
Minetest doesn't appear to scale images correctly in the inventory. |
| 16:44 |
rubenwardy |
I have three one pixel dots on an image, and in the inventory one is twice the size of the others |
| 16:46 |
sfan5 |
rubenwardy: Minetest does not resize images at all, Irrlicht does all this |
| 16:46 |
rubenwardy |
ok |
| 16:49 |
BlockMen |
sfan5, im fine with https://github.com/minetest/minetest_game/pull/250/files |
| 16:49 |
sfan5 |
thank you \o/ |
| 16:49 |
sfan5 |
now I need people to agree |
| 16:52 |
|
kaeza joined #minetest-dev |
| 16:57 |
BlockMen |
IMO we should have a maintainer for _game too |
| 16:58 |
proller |
PilzAdam ! |
| 16:58 |
sfan5 |
no |
| 16:59 |
sfan5 |
atleast not until he stops trying to hinder every (even small) changes |
| 16:59 |
* BlockMen |
agrees with sfan5 |
| 16:59 |
|
NakedFury joined #minetest-dev |
| 16:59 |
|
scientistnik joined #minetest-dev |
| 17:00 |
|
BrandonReese joined #minetest-dev |
| 17:01 |
CiaranG |
It would probably better to accept that minetest_game is going nowhere and implement a nice interface at world creation time to retrieve alternative games from a repository and select between them. |
| 17:02 |
sfan5 |
that may be good too |
| 17:03 |
BlockMen |
CiaranG, as long there are no "finished" games and/or a good system to choose games small changes like these shouldnt be blocked at all |
| 17:05 |
BlockMen |
and this half-dead-state is just annoying. either we should stop everything for _game or we should have a maintainer |
| 17:05 |
PilzAdam |
what about we simply fork minetest_game? |
| 17:06 |
proller |
already done - https://github.com/freeminer/default |
| 17:08 |
BlockMen |
btw, why are build, survival and common still present? since it has been droped it could be removed |
| 17:34 |
CiaranG |
BlockMen: But they are blocked. And because nobody has a vision of what minetest_game should be (or at least, nobody has the same one) it can never possibly go anywhere. |
| 17:35 |
CiaranG |
Also, this change is blocked and you think it should not be. It could just as easily be that a change was accepted which you thought shouldn't be accepted. |
| 17:36 |
CiaranG |
This could be fixed by people who actually have a vision of something taking control of a game and making it happen. Which, for it to be realisically useful to people, requires that easy access interface to external games adding in the main menu. |
| 17:39 |
|
scientistnik joined #minetest-dev |
| 17:42 |
BlockMen |
CiaranG, since MT is ment to be more engine for games than a finished game the easy way to acess (other) games is indeed necessary. But i think there must be a clear statement: Either the mt_game is droped from now and is officially dead, or it is maintained until the engine is ready for easy acess to games. |
| 17:43 |
BlockMen |
if it is clear that there is no way for a sane maintaining, then im all for droping it official |
| 17:43 |
proller |
but we have 0 ready other games |
| 17:43 |
CiaranG |
Or to put it another way - there are 27 minetest_game MRs rotting away. Perhaps there is someone that thinks all 27 should be accepted and someone else that thinks 0 should be accepted, but I'm pretty sure actually everybody thinks *some* of them (a different 'some' for each person) should be accepted. |
| 17:44 |
PilzAdam |
BlockMen, its dead, but it isnt dropped because of mod compatibility |
| 17:44 |
CiaranG |
BlockMen: you have a game on github that looks 'better' than minetest_game, to me, iirc |
| 17:44 |
|
Shardvex joined #minetest-dev |
| 17:45 |
BlockMen |
PilzAdam, then close every pull request, make a news post on forum and say clearly: "mt_game is not developed anymore. dont send pulls. thanks" |
| 17:45 |
PilzAdam |
I dont have the power to decide that |
| 17:46 |
BlockMen |
PilzAdam, then it should be discussed here on #dev to do something like that? |
| 17:47 |
BlockMen |
CiaranG, i think the right way is to offer games like mods. so not that 0-27 are delivered but that player can easily choose one |
| 17:48 |
CiaranG |
Yep, that's pretty much what I'm saying |
| 17:48 |
CiaranG |
You already get to choose between two games when you create a world. Both 'dead'. You should get to choose others as well. |
| 17:49 |
sfan5 |
I think minetest_game should be developed further |
| 17:49 |
sfan5 |
as long as we have no additional games coming with the releases we also need to add content to minetest_gamer |
| 17:49 |
sfan5 |
-r |
| 17:51 |
CiaranG |
So clone minetest_game, add the desert cobblestone, and anything else you like, and there's a new game (which you can then develop). What am I missing? |
| 17:52 |
BlockMen |
CiaranG, the point that we have still a zombie(-game) then |
| 17:53 |
BlockMen |
*official |
| 17:53 |
CiaranG |
It's good starting point/reference point/base for compatibility then |
| 17:54 |
sfan5 |
making minetest_game like a "better minimal" for a starting point for new games makes Minetest 100% dependent on other people doing things |
| 17:57 |
CiaranG |
Sounds better than doing nothing to me |
| 17:59 |
sfan5 |
I think there should still be new features to minetest_game |
| 17:59 |
sfan5 |
if we drop development of minetest_game we are only developing the engine |
| 18:00 |
sfan5 |
I don' think that is how stuff is supposed to work |
| 18:00 |
sfan5 |
+t |
| 18:00 |
BlockMen |
I think the most important is to have clear decisions. On the one hand it is said that _game is dead, on the other hand some pull get merged. |
| 18:02 |
sfan5 |
minetest_game was made out of the stuff in 0.3 and (IMO) should be developed like 0.3 by adding new stuff/changing things but NOT freezing it to make "starting point for other subgames" |
| 18:02 |
sfan5 |
also subgames in releases were planned for like 2 releases |
| 18:02 |
sfan5 |
do we have some yet? NO! |
| 18:02 |
sfan5 |
I think as long as we don't have at least 2 or 3 we should continue adding new stuff to minetest_game |
| 18:03 |
|
nore joined #minetest-dev |
| 18:03 |
* BlockMen |
agrees |
| 18:03 |
|
smoke_fumus joined #minetest-dev |
| 18:04 |
sfan5 |
nore: I suggest you to read the log and share your opionion about where were discussing |
| 18:05 |
nore |
sfan5, where from? |
| 18:05 |
Taoki |
BlockMen: I did it via serverside Lua so items and nodes can change the player's camera, which has a lot of uses. It would be hard to own a different hard-coded 3rd person camera in the client |
| 18:06 |
sfan5 |
nore: http://irc.minetest.ru/minetest-dev/2014-04-10#i_3643216 should suffice |
| 18:06 |
nore |
but yes, I agree we should develop minetest_game more |
| 18:07 |
|
EvergreenTree joined #minetest-dev |
| 18:10 |
BlockMen |
Taoki, a third person view should not be handled by server. the player/client should always be able to activate it (and without waiting for server responses) |
| 18:11 |
Taoki |
BlockMen: My mod wasn't intended specifically for allowing a third person camera, but to allow special nodes to set the camera. It only has a side effect that it can be used to set the camera to 3rd person view. |
| 18:11 |
Taoki |
Problem is, a normal client-side third person view and that might be hard to both have |
| 18:11 |
BlockMen |
and ofc it can work. just check if the third person view is active, e.g. here https://github.com/minetest/minetest/pull/1215/files#diff-e2b656616d911eb8d3605c2ef99f50bbR303 |
| 18:12 |
BlockMen |
and if its active then just not override, the values are stored anywhere and can be used when switching in first person view |
| 18:12 |
Taoki |
Well, the Lua camera can override either client-side camera setting I guess... still not sure what best way is |
| 18:12 |
Taoki |
No, the Lua camera must have priority over client camera setting |
| 18:13 |
BlockMen |
No, always client |
| 18:13 |
BlockMen |
servers shouldnt be able to restriced the use of third person |
| 18:13 |
Taoki |
That would break many things. Beds, vehicles, or anything else that would set the camera |
| 18:14 |
Taoki |
Think about this: If a server offers both large and small player models, both would have a different 1st person AND 3rd person camera position. You wouldn't want the third person camera to be near the ground for a giant, so you only see the feet |
| 18:15 |
Taoki |
Also, servers won't be able to restrict it if we add a way to use it under builtin. Waiting for server response... well you wait for that to see your inventory sometimes, it's not something that must be that instant |
| 18:16 |
BlockMen |
so because we have lags we should add more? |
| 18:16 |
BlockMen |
and ok, eye height should have priority |
| 18:17 |
Taoki |
Eye height is just camera position... adding it as a separate value wouldn't make sense since we can also set camera position directly. |
| 18:18 |
Taoki |
Also, another reason why Lua camera offset must always have priority: One of many ideas of using this is to have computers connected to CCTV cameras. When you click the computer node, your camera jumps to the camera node, which can be placed on a wall |
| 18:18 |
Taoki |
If you're using a separate client-side 3rd person mode, this wouldn't work because that has priority |
| 18:18 |
|
us`0gb joined #minetest-dev |
| 18:19 |
Taoki |
Being able to make CCTV cameras that clicking nodes will make you watch reqiures offsetting the camera's position / rotation / fov with priority over anything |
| 18:21 |
BlockMen |
eye height should be send as seperate value to make both modes possible. that way you can have 3rd person view for smaller/taller player models and allow overriting camera pos if in 1st person view |
| 18:21 |
BlockMen |
im all against a lua controled camera mode that can block third person view |
| 18:21 |
Taoki |
Eye height should apply to both 1st and 3rd person views. And having them separate would be doing the same thing twice IMO |
| 18:22 |
Taoki |
I understand If one is added in builtin all servers will have it. Only thing that can interrupt it are nodes taking control of the camera, like if you sit in a vehicle |
| 18:22 |
Taoki |
Unless a server admin adds bad mods to his server, his fault then |
| 18:23 |
Taoki |
Nothing should be using this function constantly, enough to block the player's camera or annoy him. The function should only be used for vehicles, beds, cameras / controlled turrets, etc |
| 18:24 |
BlockMen |
this is an unnecessary restricting of clients. the pros of your changes can be useable anyway but the user should always be able to switch to 3rd person if he wants to |
| 18:25 |
Taoki |
The user will if this is added under builtin. Which I might do next after the code is in |
| 18:26 |
Taoki |
There won't be any difference then practically. Except a quarter second delay because the server has to respond. Worth having a scriptable camera IMO |
| 18:27 |
|
Shardvex joined #minetest-dev |
| 18:27 |
Taoki |
Since again... if someone permanently switches to 3rd person view they wouldn't be able to use cameras / turrets any more, if we did it that way |
| 18:28 |
|
john_minetest joined #minetest-dev |
| 18:29 |
BlockMen |
so because you/the modder doesnt want someone to switch to 3rd pv he shouldnt be able to? |
| 18:30 |
Taoki |
No one's blocking anyone from switching |
| 18:30 |
sfan5 |
since BlockMen asked for my comment: I agree with Taoki |
| 18:30 |
Taoki |
There's no "doesn't want". The function can be used or not be used |
| 18:31 |
Taoki |
The only thing a modder can (or rather should) do is have sitting in a vehicle trigger this function to offset the camera. When not sitting in a vehicle though, nothing should touch the camera, and you can use either |
| 18:32 |
Taoki |
Same with beds. When you sit in a bed, your camera would be changed again. When not sitting in a bed however, you can use any you like |
| 18:32 |
Taoki |
Either 1st or 3rd person |
| 18:32 |
BlockMen |
should not means it is possible...and that is bad IMO |
| 18:33 |
Taoki |
john_minetest: That would be a bit harder to do with this mod |
| 18:33 |
Taoki |
But a way to toggle should be put in builtin Lua scripts |
| 18:33 |
Taoki |
I might do that later myself |
| 18:33 |
sfan5 |
idea: merge all pull requests for _game that do not introduce entirely new content (e.g. workbenches) and keep doing that |
| 18:34 |
Taoki |
john_minetest: Like I said previously. Imagine someone uses this to create a giant player model... like 5 times bigger than a normal player. You'd want both the 1st person and 3rd person camera to be much higher, even if you can toggle and use each of the two. |
| 18:34 |
Taoki |
Same way you can change the player's bounding box size |
| 18:36 |
Taoki |
john_minetest: That's me after I pull request anything :P |
| 18:37 |
BlockMen |
that would all be possible within a hard coded 3rd person mode... |
| 18:39 |
Taoki |
It would be harder to work with and more tangled I think. Since the Lua function can use both 1st person and 3rd person cameras in a lot of ways, and should always have priority |
| 18:39 |
Taoki |
We'd have to see what other devs say, I dunno |
| 18:39 |
Taoki |
No, config is bad. The offset must be in Lua so it can be used by mods |
| 18:40 |
Taoki |
You can't select player models of multiple sizes then, where each offsets the camera accordingly |
| 18:41 |
BlockMen |
and since mods can control the camera you cant hinder them to prevent switching to 3rd person view. builtin (except the mm) is also serverside |
| 18:41 |
Taoki |
Imagine someone makes a mod that lets you play as a mouse, a person, and a dragon. All 3 have different camera position offsets in X Y Z axes, for oth 1st person and 3rd person views |
| 18:45 |
Calinou |
I suggested eye height/collision radius tweakability in an issue already |
| 18:45 |
Taoki |
Calinou: Changing the bounding box of a player should be since long possible. This makes eye height possible too |
| 18:46 |
Taoki |
BTW, it's not just eye *height*. Some models might require a back / forth offset too... like for ferals, since you don't want the camera over their back |
| 18:46 |
Calinou |
https://github.com/minetest/minetest/issues/1179 |
| 18:46 |
Calinou |
yeah, that |
| 18:46 |
Calinou |
but eye height is very, very easy to do |
| 18:47 |
Taoki |
So this would require another function on top of this to send the eye offset as a vector. Whereas the scripted camera would have its other uses too. Same thing would be kinda done multiple times |
| 18:47 |
Taoki |
I might think of a way to trigger a 3rd person view locally too, but that would make things more complicated |
| 18:48 |
BlockMen |
celeron55, why do you say something like that private and not here to be readable by all? |
| 18:48 |
BlockMen |
^->#minetest |
| 18:49 |
Taoki |
Personally, I think it's more important to have a camera that can be scripted by various nodes and objects rather than a 3rd person camera right away. We'll see what everyone says though |
| 18:50 |
BlockMen |
Taoki, no its kinda easy. just check if third person view is active here https://github.com/minetest/minetest/pull/1215/files#diff-e2b656616d911eb8d3605c2ef99f50bbR305 |
| 18:52 |
sfan5 |
BlockMen: I asked him directly |
| 18:52 |
Taoki |
Also, a question about a different issue if any developer knows: Where were the lines of code responsible with sending client / server position and rotation updates? Like the server code which sends movement updates for players and entities, as well as the client one that sends player movement to the server |
| 18:53 |
sfan5 |
Taoki: tried "grep" yet? |
| 18:53 |
Taoki |
I have grep, but don't always have the right words to search for :P |
| 18:54 |
Taoki |
There's like thousands of lines with the word "position" or "update" in them |
| 18:54 |
sfan5 |
well |
| 18:54 |
sfan5 |
sending updated to client is done in AsyncRunStep in server.cpp |
| 18:55 |
BlockMen |
Taok, server: https://github.com/minetest/minetest/blob/master/src/server.cpp#L655 |
| 18:55 |
BlockMen |
client, idk |
| 18:55 |
Taoki |
thanks |
| 18:56 |
BlockMen |
sfan5, for a question like that a public answer would be nice anyway |
| 18:57 |
sfan5 |
BlockMen: there is not much more relevant stuff celer*n55 said |
| 19:07 |
Taoki |
Hmm... still can't find where the timer regarding how frequently to send player position to clients is |
| 19:07 |
Taoki |
There was an update interval... 0.05 seconds long ago or something |
| 19:08 |
Taoki |
To limit how many packets the server sends to update player position |
| 19:08 |
celeron55 |
BlockMen: what |
| 19:09 |
celeron55 |
BlockMen: i say where i am asked; what do you expect |
| 19:09 |
celeron55 |
i assumed sfan5 wanted to keep it private because he asked it in private |
| 19:10 |
sfan5 |
it was intending to keep it private |
| 19:10 |
celeron55 |
also i didn't say anything new |
| 19:10 |
sfan5 |
but since some people asked and it was nothing that is strictly private |
| 19:10 |
sfan5 |
.. |
| 19:12 |
sfan5 |
why do we have a macro for PLAYERNAME_SIZE when the password is hard-coded to be written at data[23]? |
| 19:12 |
BlockMen |
celeron55, i dont "expect" you to answer here but i think it is a nice additions to discussion. how a private chat is handled is always up to the participated ppl ofc |
| 19:13 |
|
sapier joined #minetest-dev |
| 19:17 |
sapier |
For what I understand 3d person view object linking camera offset and the new camera offset are (at least partial) overlaping features. Imho we should check twice not to add different things to do same thing. A better aproach would be a closed solution handling all of those things (if possible) |
| 19:19 |
Taoki |
What's object linking? Never even heard of it |
| 19:19 |
BlockMen |
sapier, you read the log? |
| 19:19 |
iqualfragile |
what are the requirements for a map generator to be included in the engine? |
| 19:19 |
sapier |
only the non game related parts (hope I didn't miss something mixed in there) |
| 19:20 |
sapier |
taoki you can link objects (player as well as entities are objects) ... and you can specify a camera offset to the linked entity |
| 19:20 |
sapier |
that's used for vehicles right now |
| 19:20 |
Taoki |
Is such a code in mester? I didn't see it |
| 19:20 |
Taoki |
And that makes little sense |
| 19:20 |
sapier |
i don't think there are fixed requirements .. maybe except of not requireing changes all over minetest code |
| 19:21 |
sapier |
it does |
| 19:21 |
BlockMen |
sapier, ok. then you know that i think that the best solution would be a combination |
| 19:21 |
sapier |
ostrich riding, helicopters, boats all of those mods use the linking/offset feature |
| 19:21 |
Taoki |
The only linking I'm aware of is the set_attachment system I added when I did model support |
| 19:22 |
Taoki |
That's in master? |
| 19:22 |
Taoki |
And you specify a camera offset? |
| 19:22 |
sapier |
yes and it's still buggy taoki ;-) ... you've been the one not fixing the bugs for so long? ;-) |
| 19:22 |
Taoki |
I didn't add that |
| 19:22 |
Taoki |
And don't understand why anyone else would have |
| 19:22 |
|
john_minetest left #minetest-dev |
| 19:22 |
sfan5 |
iqualfragile: the devs accept it |
| 19:22 |
|
restcoser joined #minetest-dev |
| 19:22 |
sapier |
well it's in and there's missing doc for some params and some (minor) bugs are left too |
| 19:23 |
Taoki |
The camera offset shouldn't conflict with it |
| 19:23 |
iqualfragile |
sfan5: oh, thats totally great |
| 19:23 |
sapier |
it still may be a way to achiev same thing as camera offset |
| 19:24 |
sapier |
If it's been you who s responsible for the link mess I suggest fixing the remaining issues with this one first ;-) |
| 19:24 |
Taoki |
No, I never added linking. At least not what I'm hearing here |
| 19:24 |
Taoki |
I only added support for entity on entity attachments, using Irrlicht's attachment system. |
| 19:25 |
Taoki |
I didn't even know of this entity linking thing, which sounds like the exact same thing |
| 19:25 |
sapier |
I think we're talking about same thing let me look for the api to be sure |
| 19:25 |
Taoki |
ok. Tell me what the function is, we can be sure then |
| 19:26 |
sapier |
set_attach(parent, bone, position, rotation) + set_detach |
| 19:26 |
Taoki |
Yes, that is the one I made. And I never added any camera offsetting in it |
| 19:26 |
Taoki |
You can attach a player to an entity, but it doesn't touch the camera... it simply attaches the player entity |
| 19:26 |
sapier |
wait maybe it's still wrong api |
| 19:27 |
sapier |
no it's correct api |
| 19:28 |
Taoki |
ok. Did anyone modify it and add camera offsetting separately? |
| 19:28 |
sapier |
it does touch camera |
| 19:28 |
Taoki |
Alright... if no one added a separate function for camera offset, there's none then |
| 19:28 |
sapier |
if you specify a position this does affect camera relative to attached entity .. which most of time is the vehicle |
| 19:28 |
Taoki |
And this won't conflict with it |
| 19:28 |
|
PilzAdam joined #minetest-dev |
| 19:29 |
sapier |
it does conflict |
| 19:29 |
sapier |
what's use for placing a camera outside of players head? |
| 19:29 |
sapier |
despite 3rd person view ;-) |
| 19:30 |
Taoki |
Firstly, the new function is unrelated to attachments. It can be used even if the player is sitting on something or not. Other than that, when I checked I thought the camera stays at the player's head even if he sits in a vehicle. Even if it moves however, this offset is applied on top of the result |
| 19:30 |
Taoki |
This lets you put the camera anywhere in any case |
| 19:30 |
Taoki |
On top of the default behavior... whatever that is when attachments are used |
| 19:31 |
sapier |
You haven't convinced me yet. I still don't understand the situation where this is really usefull and cannot be done by existing things |
| 19:31 |
Taoki |
So if people like the current behavior when eg: sitting in a helicopter, they don't need to use the new camera function. If not, the new camera function can be used to offset eye position to the right location |
| 19:32 |
|
_BrandonReese joined #minetest-dev |
| 19:33 |
sapier |
still for what is this feature NEEDED |
| 19:33 |
Taoki |
sapier: The function lets you offset the position and rotation of the camera. There's tons of useful situations. Big and small player models (this lets you position the center of vision at the proper height for each), beds (to make you look like you're laying down), cameras (click a node and your camera jumps to a CCTV camera placed on a wall), vehicles with their own 3rd person mod, etc |
| 19:34 |
Taoki |
Can even be used for cinematic caperas, so you always look from a node's perspective if you walk past it. Might be annoying so perhaps that it won't be used for |
| 19:34 |
|
nore joined #minetest-dev |
| 19:34 |
Taoki |
**cameras |
| 19:34 |
sapier |
on the other hand if server controls these features and some paramteters are set by client the actual result is unpredictable |
| 19:34 |
Taoki |
Oh, and turrets. The player can be several nodes away and controlling a turret installed somewhere. The camera can be positioned at the turret's location |
| 19:35 |
Taoki |
No camera parameters are set by client except hard-coded ones |
| 19:35 |
sapier |
isn't fov client specific? |
| 19:35 |
Taoki |
Except FOV, which this acts as a multiplier on. But eye offset cannot be configured |
| 19:35 |
Taoki |
Yeah, just FOV |
| 19:35 |
sapier |
well that's not "no" |
| 19:35 |
Taoki |
For example this can be used to zoom, for a sniper weapon |
| 19:36 |
Taoki |
Yeah, I meant there's no way to configure camera offset already... either server or client. FOV is just a setting, only exception I guess |
| 19:36 |
Taoki |
But it's relative |
| 19:36 |
sapier |
ok I think there are valid reasons to add it ... still the conflict to 3rd person view isn't solved |
| 19:37 |
Taoki |
Might detail more on these examples later if needed, but yeah |
| 19:37 |
BlockMen |
sapier, just apply the set values if not in 3rd person mode |
| 19:37 |
sapier |
that's one option the other variant is leaving 3rd person view once it's specified by server |
| 19:38 |
Taoki |
sapier: The one I gave earlier is: Imagine a server lets you play as a mouse, a human, or a dragon. For each of the three, you'd need a different camera position, BOTH in 1st person and 3rd person mode. One is very small, other is medium, other is large. Mouse and dragon are also ferals not bipedals, so the camera must be bumped forth |
| 19:39 |
BlockMen |
sapier, then the server could hinder you from 3rd pv |
| 19:39 |
sapier |
yes but your cctv is exactly opposit example it's crap to have pov withing ceiling if it should be a t a camera |
| 19:39 |
Taoki |
For this reason, having a separate hard-coded 3rd person mode might be complicated. |
| 19:40 |
Taoki |
sapier: CCTV would work too. When you click the monitor linked to a CCTV node, your camera is placed at the CCTV node's location, until you click again |
| 19:40 |
sapier |
exactly taoki, imho 3rd person view and your one should be merged to a combined solution |
| 19:40 |
* BlockMen |
agrees in general |
| 19:40 |
sapier |
nope if wont work taoki as if you're in 3rd person view your pov wouldn't be set to camera but to something top above camera which might or might not be a wall |
| 19:41 |
Taoki |
The other useful examples are beds. When you lie in bed, this will let you roll the camera 90*, giving a nice view of you laying down and seeing everything rotated 90*. Or being able to look up and down across the ceiling |
| 19:41 |
Taoki |
Ah... you mean checking if camera is in solid |
| 19:42 |
sapier |
don't get me wrong none of those issues are blockers as of "can't be fixed" you just have to fix them talking to blockmen and find a suitable way |
| 19:42 |
|
rsiska joined #minetest-dev |
| 19:42 |
sapier |
one possible option would be sending a flag "3rd person allowed" too |
| 19:43 |
sapier |
but that might not be best solution, guess blockmen knows way better then me where conflicts migth occur |
| 19:43 |
Taoki |
The problem is this: Normally, we could just make a Lua function which specifies eye offset as a vector for both 1st and 3rd person modes, then switching between the to is hard-coded in client. But I was hoping to make something which lets you do CCTV's and turrets too, and possibly more |
| 19:44 |
sapier |
I think you can do both if you do it right |
| 19:44 |
BlockMen |
indeed^ |
| 19:45 |
Taoki |
Actually though, my implementation is sort of a hack for CCTV too. Because you specify an offset to player's current camera. So when the player links to a CCTV, you set the camera as (player_position - CCTV_node_position), and the player must not move because the camera is still stuck to it |
| 19:45 |
BlockMen |
the main point is that taoki want the server be able to prevent 3rd pv and i dont want that |
| 19:45 |
sapier |
I sugges both of you working together as I fear non of those patches will have enough supporters to get merged if they can't provide the other ones features too |
| 19:45 |
Taoki |
BlockMen: Not prevent |
| 19:45 |
* Taoki |
sighs... you are right. Need to think well about this though |
| 19:46 |
Taoki |
BlockMen's patch is good too... seems quite well made. I didn't know of it befure I started working on mine BTW |
| 19:46 |
Taoki |
Hmm... |
| 19:47 |
Taoki |
I'm thinking of a different approach actually. One BlockMen could add to his code as new additions perhaps... |
| 19:47 |
sapier |
well taoki I'm sorry to tell but you'd just have to look for issues ;-) |
| 19:47 |
BlockMen |
Taoki, just for the protocoll: i like your patch, it has nice features. i only think that 3rd pv should be handled locally, always |
| 19:48 |
Taoki |
BlockMen: First of all, there's one thing I really care for: The ability to specify eye offset per-player from Lua. ot just height, but the offset as an entire vector... as some player model designs might require the camera to go in various locations. |
| 19:48 |
Taoki |
Now this could be done if your code would get a new Lua function, which lets you specifiy eye position per-player for BOTH 1st and 3rd person mode |
| 19:48 |
sapier |
maybe sending "camera position" + "3rd person offset" + "disallow 3rd person" as parameters would be a solution? |
| 19:49 |
Taoki |
something like player:set_eye_position({0,20,0}, {0,40,-20}), whereas the first is 1st person eye position and second is 3rd person. |
| 19:49 |
sapier |
this way 3rd person view is handled on client while server can control the offset e.g. for your dragons |
| 19:49 |
BlockMen |
Taoki, since the animations for 3rd pv are send to client you could send the eye offest too |
| 19:49 |
BlockMen |
*or as single function |
| 19:49 |
BlockMen |
even better |
| 19:49 |
Taoki |
BlockMen: What do you think about adding something like this to your code? player:set_eye_position({0,20,0}, {0,40,-20}) - This sets the eye position for both modes, and the client of course then toggles the camera |
| 19:50 |
Taoki |
This also lets vehicles offset 1st person and 3rd person cameras to fit them |
| 19:50 |
sapier |
did you think about just making eye offset a parameter of player object? |
| 19:50 |
Taoki |
That works too. Wouldn't it be sorta the same thing? |
| 19:51 |
Taoki |
As long as it's per-player and in Lua I don't mind either way |
| 19:51 |
BlockMen |
Taoki, i would be fine with that. |
| 19:51 |
Taoki |
Nice :) |
| 19:51 |
Taoki |
BlockMen: What about a rotation offset as well, like my code has? So laying in bed is possible. Or the camera can be tilted when you die. |
| 19:51 |
Taoki |
Though now I'm unsure if it's making the function confusing |
| 19:52 |
BlockMen |
Taoki, only in first person mode |
| 19:52 |
Taoki |
player:blablabla({1st_person_position}, {1st_person_rotation},{3rd_person_position},{3rd_person_rotation}) |
| 19:52 |
Taoki |
Ah... yes that sounds good |
| 19:52 |
Taoki |
In 3rd it shouldn't be needed, only position should matter there |
| 19:53 |
Taoki |
BlockMen: Then that leaves only the issue of turrets, CCTV, remote-controlled cars, and others i was dreaming could be done with this. This one might be tricky... and actually my code was doing it horribly too. |
| 19:54 |
Taoki |
So I'm actually thinking of another parameter or function, which would allow sticking the camera to another Lua entity which is loaded client-side, and which is not the player. Or a node, since CCTV cameras wouldn't be entities |
| 19:55 |
Taoki |
Again, both 1st and 3rd person modes can be used. Though 3rd person mode on a CCTV camera would be a bit silly, but I couldn't mind. On a RC vehicle both would make perfect sense |
| 19:56 |
Taoki |
Heh... mind-controlling mobs. This could be possible too... player hides in a cave and jumps into the body of a vombie :) |
| 19:56 |
BlockMen |
Taoki, i like the idea of a cleintside camera node/entity that could be controled by lua then |
| 19:56 |
BlockMen |
*clientside |
| 19:57 |
BlockMen |
*for CCTV |
| 19:57 |
Taoki |
Nice. Yeah this would actually make more sense than what I did. But also offer the features I really wanted this for |
| 19:57 |
sapier |
I suggest delaying this for another patch ;-) |
| 19:57 |
sapier |
this == client side camera entity attaching |
| 19:58 |
Taoki |
sapier: Lua parameters for 1st person and 3rd person position / rotation offset would be easy to add. But the attaching part can be delayed |
| 19:58 |
Taoki |
So I'd suggest the first, and delaying the second |
| 19:58 |
sapier |
that's what I meant |
| 19:58 |
BlockMen |
Taoki, so should i add offset(both) and rotation(1st) to my patch? |
| 19:58 |
Taoki |
BlockMen: Yes. Hold on I'll write an example idea quickly |
| 19:59 |
BlockMen |
or do you prefer to do that? |
| 19:59 |
BlockMen |
ah..to slowly |
| 19:59 |
Taoki |
BlockMen: The code is in your branch and you know it best. It's usually harder to work on top of another's code. You can however use anything I suggested in my branch |
| 20:00 |
BlockMen |
Taoki, ok ;) |
| 20:00 |
Taoki |
Anyway: player:set_camera_positions({x, y, z}, {x, y, z}, {x, y, z}). Where the 1st vector is first person position offset, the 2nd is first person rotation offset, and the 3rd is third person position offset |
| 20:01 |
Taoki |
or ({{x, y, z}, {x, y, z}}, {x, y, z}) might make more sense |
| 20:01 |
|
Shardvex joined #minetest-dev |
| 20:02 |
Taoki |
So it would be player:camera_thingie({1st_person_position_offset}, {1st_person_rotation_offset},{3rd_person_position_offset},{3rd_person_rotation_offset}) |
| 20:02 |
BlockMen |
why not two functions? so player:set_camera_rotation(...) and player:set_camera_offset(..., ...) ? |
| 20:02 |
Taoki |
Can work too yes |
| 20:03 |
BlockMen |
IMO its easier to use that way |
| 20:03 |
Taoki |
If it's two functions, we could even leave rotation offset for later... position offsets would probably matter most |
| 20:03 |
Taoki |
Rolling your head upside down when laying in bed isn't that urgent. Most ideas (cameras, turrets, vehicles, etc) only require position offset |
| 20:04 |
Taoki |
BlockMen: So at least for starters, it might be enough to only add a player:set_camera_offset({1st_person_position}, {3rd_person_position}) |
| 20:04 |
Taoki |
Sounds good to me :) |
| 20:05 |
* BlockMen |
agrees |
| 20:05 |
Taoki |
Also useful for beds and death already |
| 20:06 |
BlockMen |
i will add this tomorrow then |
| 20:06 |
Taoki |
Ok then. If you want to do it easily you can copy-paste from my branch and code, since this part exists exactly like this. Well for only one position but still |
| 20:08 |
Taoki |
If you'll work on it soon I can close my pull request for now at least, and add a note about this... so devs won't focus their attention on something that might be merged somewhere else |
| 20:10 |
BlockMen |
is genericobject not for all entities? i think adding it for player only is better. |
| 20:11 |
Taoki |
Yeah, should be for player only. I followed the example of set_physics when I made mine |
| 20:11 |
Taoki |
Ahhh... and I forgot about FOV :P I guess that will have to be a different function |
| 20:12 |
Taoki |
Wanted a way to chenge FOV via Lua... for stuff like higher FOV while sprinting (warning, Minecraft ripoff), lower FOV when underwater to simulate lens effect (shameless Minecraft idea again) or zoom on some weapons... like FPS games offer for the sniper |
| 20:15 |
BlockMen |
ah, ok. maybe its easier to write new function instead of copy,edit&paste ;) |
| 20:15 |
Taoki |
Yeah, if you'll use a different "path" in the lua code it's best to ignore mine completely |
| 20:17 |
sapier |
#1170 anyone against merging this one? |
| 20:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/1170 -- A few bind_address fixes by kahrl |
| 20:18 |
BlockMen |
sapier, i was wondering already that its not merged yet |
| 20:18 |
BlockMen |
= no |
| 20:21 |
Taoki |
BlockMen: Does your code have solid detection for 3rd person camera? So it won't go into the ceiling? Just curious |
| 20:22 |
BlockMen |
you mean that camera moves not into nodes? then yes |
| 20:22 |
Taoki |
Yeah, prevention for that |
| 20:22 |
BlockMen |
but ofc its not perfect yet and can be always improved |
| 20:22 |
Taoki |
Nice. Mine didn't have that, so it is another advantage |
| 20:23 |
|
AndChat-93396 joined #minetest-dev |
| 20:23 |
sapier |
ok merging 1170 now |
| 20:24 |
BlockMen |
4 months ago mine neither ;) |
| 20:25 |
|
EvergreenTree joined #minetest-dev |
| 20:26 |
proller |
every pull must be 3 minimum month old for merging |
| 20:26 |
proller |
1170 - only one month |
| 20:26 |
proller |
need wait 2 months.. |
| 20:27 |
sapier |
well proller if I wasn't the only one bothering to check and merge anything the last weeks it might get a little bit faster ;-) |
| 20:27 |
Taoki |
... why must a pull wait 3 months D: |
| 20:28 |
sapier |
if we get to fast freeminer looses it's reason to exist ;-) |
| 20:28 |
BlockMen |
Taoki, just a bad joke. |
| 20:28 |
BlockMen |
and bye |
| 20:28 |
Taoki |
Phew... I thought it was real xD |
| 20:28 |
Taoki |
later! |
| 20:28 |
sapier |
I don't believe this is gonna happen anytime soon :-) |
| 20:28 |
|
BlockMen left #minetest-dev |
| 20:32 |
sfan5 |
https://github.com/minetest/minetest/pull/1216 |
| 20:32 |
sfan5 |
^ comments please |
| 20:32 |
sfan5 |
I think I did not do it like it was supposed to be done |
| 20:36 |
sapier |
why do you create two shared buffers? |
| 20:37 |
sfan5 |
I need to use an ostringstream to be able to utilize serializeString |
| 20:37 |
sapier |
and I'd prefere this feature to be optional on client side |
| 20:37 |
sfan5 |
and I need a buffer to append the usernae + password |
| 20:38 |
sapier |
you create a sys string anyway so you can fetch it before and add that data |
| 20:38 |
sfan5 |
what do mean? |
| 20:39 |
sapier |
serializeString(porting::get_sysinfo()) does create a (temporary) string object anyway so why not std::string sysinfo = serializeString(porting::get_sysinfo()) right at beginning |
| 20:40 |
sfan5 |
how would that improve anything? |
| 20:40 |
sapier |
this way you coud check for "privacy" setting and sett the string to "" if user doesn't want to send os information |
| 20:40 |
sapier |
os isn't a minetest only information and there's no need to send it so imho there's no legit reason to force the user to send it |
| 20:44 |
sapier |
I understand server owners wanting to know it but if we do things like that we have to add a disclaimer "minetest may send information about your system to servers, if you don't agree quit immediatly" |
| 20:44 |
Taoki |
sapier: https://github.com/minetest/minetest_game/pull/234 Is this still worth looking into? I fixed an animation error on the player model some time ago... IIRC no reason not to put that in. |
| 20:45 |
Taoki |
Was a conflict with caped player model, but last I heard that was taken back |
| 20:45 |
sapier |
at least in germany server owner wouldn't be allowed to save that data at all |
| 20:45 |
Taoki |
Weit... I don't remember if Jordach did more fixes to the model actually |
| 20:45 |
sfan5 |
sapier: you wouldn't? | added a setting, better? |
| 20:46 |
Taoki |
Actually no... so yeah please look at that if you wish |
| 20:46 |
sapier |
no in germany you have to ask for permission to save personal data, as that data is linked to a player name you have to ask for permission |
| 20:46 |
sfan5 |
but you can save it without linking it to the player name |
| 20:46 |
sfan5 |
anyway |
| 20:46 |
sfan5 |
good night |
| 20:47 |
sapier |
no you can't as the data still is only available BECAUSE of a player name ... anonymization isn't enough you still have to ask |
| 20:47 |
sfan5 |
wut |
| 20:48 |
sapier |
you're not even allowed to gather those information if you don't ask |
| 20:48 |
sfan5 |
the minetest version is a thingy too |
| 20:48 |
sfan5 |
s/a thingy/sent/ |
| 20:48 |
sapier |
but the minetest version is a minetest only data ... and yes even that information is grey |
| 20:49 |
sapier |
and release builds don't send it |
| 20:49 |
sapier |
wait they do |
| 20:49 |
sfan5 |
so you are saying I can go to jail if I run my minetest server in verbose mode and don't delete the log? |
| 20:50 |
sapier |
grey because of "we might need to change protocol behaviour based uppon version" ... if we ever have reason to change behaviour because of os we did more then one mistake |
| 20:50 |
sfan5 |
also "available because of player name" does not make any sense to me |
| 20:50 |
sfan5 |
are you also telling me I need to ask visitors of my website first before tracking? |
| 20:51 |
sapier |
for what I know worst thing to happen is paying some money for each single case ... those laws arent enforced that strongly |
| 20:51 |
sapier |
if there's no player you don't have that information |
| 20:51 |
sfan5 |
I want to see a link to the actual law that states this |
| 20:51 |
sapier |
it's not information gathered from a anonymous service |
| 20:52 |
sfan5 |
a player != a player name |
| 20:52 |
sapier |
that law depends on what court you have |
| 20:52 |
sfan5 |
also saying if there is nobody there is no data to collect is pointless |
| 20:52 |
sfan5 |
wat |
| 20:52 |
sfan5 |
the court does not decide the law |
| 20:53 |
Taoki |
lol... German law preventing us from coding something in Minetest? When is real life stuff going to stop interering with internet stuff heh |
| 20:53 |
sapier |
in germany politicians write laws in this area that badly courts have to find out what they really mean first |
| 20:53 |
Taoki |
That's pretty crazy actually. Though if it's something related to privacy I can otherwise agree it might be best not to add it |
| 20:54 |
sapier |
by now none of those trials went to supreme court so there's no final decision made about how to interpret them |
| 20:54 |
sfan5 |
I'm 90% sure the german law does not state this |
| 20:54 |
sfan5 |
german websites would not be able to do tracking without asking their users first |
| 20:54 |
sfan5 |
google analytics would not even function |
| 20:54 |
sapier |
german law is quite strict if you wanna operate on "personal data" you have to ask for permission first |
| 20:55 |
sfan5 |
what is "personal data"? |
| 20:55 |
sapier |
google analytics is questionable in germany too |
| 20:55 |
sapier |
sfan5 exactly this question isn't decided right now |
| 20:55 |
|
cheapie joined #minetest-dev |
| 20:56 |
sapier |
some lawyers believe ga to be illegal in germany too but by now noone did issue a trial |
| 20:57 |
sapier |
imho minetest shouldn't tell any information about client system not required for minetest itself |
| 20:58 |
sfan5 |
are you seriously telling me my apache & nginx logs are illegal? |
| 20:58 |
sapier |
and client os is pure server owner curiosity. Any trustworthy software I know asks for permission |
| 20:58 |
sapier |
if you use them for anything else then fixing technical problems ... yes |
| 20:59 |
sfan5 |
so looking at them is illegal too? |
| 20:59 |
sapier |
if you don't have problems to fix ... most likely yes |
| 20:59 |
sfan5 |
the more you say the less I believe you |
| 21:00 |
sfan5 |
please provide a link to the law on https://dejure.org/ |
| 21:01 |
sapier |
I don't say anyone was ever jailed for this and your personal small server may have other reasons not to be illegal but for large companies evaluation of logfiles may be illegal |
| 21:01 |
|
Jordach_ joined #minetest-dev |
| 21:02 |
sapier |
sfan5 I'm not a lawyer to tell you paragraphs and it's not really readable there. As I said those laws are that bad courts are still argueing about how to interpret them |
| 21:02 |
sapier |
e.g. IP addresses are considered to be personal data by one court while another one decided they aren't personal data |
| 21:03 |
sfan5 |
sapier: what is not readable there? |
| 21:03 |
sfan5 |
IIRC you can find all german laws there |
| 21:03 |
sapier |
you wont find a sentence as "Webserver logs are illegal" in any of germanys laws |
| 21:03 |
|
EvergreenTree joined #minetest-dev |
| 21:04 |
sapier |
more something like "collection of personal data requires prior permission of owner" |
| 21:04 |
sfan5 |
that's not what I expect |
| 21:04 |
sfan5 |
yeah, where is that in the laws? |
| 21:04 |
sapier |
as I said I'm not a lawyer and I wont look thousands of pages for sure ;-) |
| 21:06 |
sfan5 |
heard of google? |
| 21:06 |
sfan5 |
google gave me this http://dejure.org/gesetze/BDSG/3.html |
| 21:06 |
sapier |
https://www.ldi.nrw.de/mainmenu_Datenschutz/Inhalt/FAQ/Vorraussetzungen.php that one might be most close to it ... freely translated "personal data may only be gathered, saved,transmitted, modified or used in any way if this is allowed by a law or permitted by affected person" |
| 21:07 |
sapier |
now you've just to look for all laws that might be reason for an exception ;-) |
| 21:07 |
sfan5 |
try a google search for "~sammlung ~persönliche ~daten site:dejure.org" |
| 21:07 |
sfan5 |
"Personenbezogene Daten sind Einzelangaben über persönliche oder sachliche Verhältnisse einer bestimmten oder bestimmbaren natürlichen Person (Betroffener)." |
| 21:08 |
sfan5 |
this does not sound like it includes IP addresses |
| 21:08 |
sapier |
username <-> os |
| 21:09 |
sapier |
as I said above "personal data" is not exactly defined that's why courts are still argueing ... I don't think there's much doubt a username is a personal data |
| 21:10 |
sapier |
ipv6 addresses may be personal data too ... e.g. you most likely will get same ipv6 address on your mobile phone everytime. mobile phones usually are used by a single person only |
| 21:11 |
sapier |
as even lawyers are still argueing about the exact meaning I'm quite sure we wont be able to solve this issue here |
| 21:12 |
sfan5 |
http://dejure.org/dienste/vernetzung/rechtsprechung?Gericht=VG%20D%FCsseldorf&Datum=17.07.2009&Aktenzeichen=27%20L%20990/09 |
| 21:14 |
sfan5 |
anyway |
| 21:14 |
sfan5 |
good night now |
| 21:21 |
|
proller joined #minetest-dev |
| 22:08 |
|
sapier left #minetest-dev |
| 22:20 |
|
iqualfragile joined #minetest-dev |
| 22:22 |
|
NakedFury joined #minetest-dev |
| 22:22 |
iqualfragile |
!tell sapier 142e2d3b74ad886eed83b0fc9d6cfea100dae10a most likely fucked up lots of stuff |
| 22:22 |
ShadowBot |
iqualfragile: O.K. |
| 22:24 |
iqualfragile |
!tell sapier or not, its incredibly slow, checking my server before filing a bug report |
| 22:24 |
ShadowBot |
iqualfragile: O.K. |
| 22:32 |
|
EvergreenTree joined #minetest-dev |
| 22:50 |
|
iqualfragile_ joined #minetest-dev |
| 23:20 |
|
us`0gb joined #minetest-dev |
| 23:43 |
|
NakedFury joined #minetest-dev |
