Time Nick Message 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 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: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 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: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 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: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 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: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: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 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: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: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 * BlockMen agrees 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: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: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 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: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: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 sfan5 iqualfragile: the devs accept it 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: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: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 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 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: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 sapier ok merging 1170 now 20:24 BlockMen 4 months ago mine neither ;) 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: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: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: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: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 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.