Time Nick Message 06:03 Zughy[m] can you please ban this guy? My mail has just got spammed with pretty pointless comments, and IIRC they also caused trouble on CDB and the forum in the last months 06:03 Zughy[m] https://github.com/minetest/minetest/issues/6733#issuecomment-1151764482 07:14 MTDiscord "they also caused trouble on CDB and the forum in the last months" can very much confirm this. he's also completely banned from the minetest discord 08:03 sfan5 tip to bystanders: don't derail the github issue further by making comments 08:32 nrz_ i'm sorry he is spamming you, but the proposal in terms of ui is pretty nice 08:33 nrz_ the last ones i mean 09:18 rubenwardy they're temp banned from the forum and CDB now 11:02 MTDiscord nrz_: Just to be clear: That proposal is by the one being spammed, not by the one spamming. 12:28 kilbith https://i.imgur.com/B7vWkz7.jpg 12:28 kilbith thoughts? 12:32 MTDiscord What would you guys think of a release party for MT 5.6? 12:32 MTDiscord I could host a server for it for a day 12:35 MTDiscord It would need planning 12:36 MTDiscord People could make mod suggestions and submit schematics 12:41 celeron55 kilbith: there probably needs to be a list of use cases that can be used to review whether a given api suggestion is good 12:42 celeron55 what would static do? 12:44 celeron55 also a camera kind of has two positions, a target position and the position the camera is at, and then if you want to rotate the camera then you need an up vector or a quaternion or something... which leads back to the use cases 12:58 kilbith celeron55> what would static do? 12:58 kilbith it's a locked camera for e.g. cutscenes 12:59 kilbith celeron55> also a camera kind of has two positions, a target position and the position 12:59 MTDiscord get rid of registering cameras 12:59 kilbith a target position will be normalized vector, I think 12:59 MTDiscord just do a set_camera which takes all your register params 12:59 kilbith s/a/the 12:59 MTDiscord kilbith: that'd be a look dir 13:00 MTDiscord cameras should also be attachable to objects etc. 13:00 MTDiscord in fact cameras should be a type of low-profile object 13:00 kilbith get rid of registering cameras 13:01 kilbith there needs to have a centralized place where HUD/GUI/ObjectRef access a global referential 13:01 kilbith you register a camera once, and you access it from anywhere 13:02 MTDiscord so you'd have (set|get)_position, (set|get)_rotation, (set|get|lock)_look_dir, (set|get)_fov(fov, interpolation) & (set|get)_attach for your camera object and player:get_camera() 13:02 MTDiscord kilbith: Then you also need unregistering 13:02 kilbith of course 13:03 MTDiscord You could alternatively also just serialize the camera for HUDs & formspecs 13:04 kilbith `static = false` would be limited by aabb the same way than GUIScene 13:05 kilbith celeron55: had to ask, camera position is not strictly world position, correct? 13:10 MTDiscord for a clean API it should be 13:10 MTDiscord but in Minetest internals it isn't 13:11 kilbith that's what I ask 13:11 kilbith and if yes, where is it exactly adapted 13:12 MTDiscord kilbith: Grep for "camera_offset" 13:14 erle well the offset needs to be there, right? 13:15 rubenwardy Feels like this should be based on entities, so that we can benefit from future improvement to entity interpolation/movement 13:15 kilbith so let's say a Camera object accessible from Lua? 13:17 erle i agree with the usefulness of cameras being accessible globally and being registered and unregistered 13:17 erle that way you can do some optimizations that you could not if it was not a global thing 13:17 erle like, 3 people looking at the same security camera 13:45 MTDiscord It's not worth it 13:45 MTDiscord The entire camera is only a couple bytes 13:46 erle well at some point you need to make sure the area is kept active or not 13:48 MTDiscord The clients do that 13:49 MTDiscord When a client receives a camera at a certain pos it'll have to request the area 13:50 erle if clients can request arbitrary area that is a prime denial of service opportunity 13:50 erle and remote viewing 13:50 erle i.e. coordinate leaks 13:51 erle luatic have you seen the video from fitmc about the NOCOM exploit? 13:56 MTDiscord erle: Yes, obviously, so the server will have to check whether it sent camera X to player Y 13:56 erle which becomes easier if you have a dedicated cam object right 14:01 sfan5 clients currently do not request any areas for viewing 14:02 sfan5 just as a fyi that it works pretty much inverse currently 14:11 erle sfan5 yeah so making a cam object and assigning it could just push the stuff to the client, or not? 17:20 Pexin how far away is arbitrary player vertical orientation and localized gravity points? 17:22 rubenwardy what 17:22 rubenwardy oh far away as in roadmap 17:22 rubenwardy it's not currently planned anywhere, and I don't remember an issue 17:22 rubenwardy but it's been discussed a few times casuallh 17:23 Pexin yeah I mean how difficult would it be to adapt the current codebase? 17:24 Pexin I know there's a "roll" value, but don't know which objects it applies to, but localized gravity seems tough 17:24 rubenwardy would probably take some work 17:25 rubenwardy for one, wouldn't it require moving away from AABB collisions to support rotating the player 17:25 Pexin also, slightly related, my understanding of the map format/loading is the map is optimized for mostly horizontal movement? 17:27 Pexin as for collisions, a simplistic way might be provide an alternate (configurable) option for collisions to be sphere-based 17:27 Pexin statically calculate the center of the mesh and the radius, you know 17:42 erle Pexin localized gravity points are pretty easy to implement. i did this once. 17:43 erle granted, the localized point was 0,0,0 17:43 erle because i played around with this mapgen from paramat (?) that generated a cube planet 17:43 erle and wanted to be in orbit 17:46 erle Pexin there are basically two things you can do for localized gravity. either you pick a suitable center of gravity for each object and apply forces towards that. super simple to implement, but physically wrong. you can see the downsides of it in kerbal space program, which only ever allows you to have one center of gravity, i.e. it has “spheres of influence” 17:47 erle Pexin the other approach is giving arbitrary objects attraction forces and then doing an n-body simulation like in this thing i made in 2010 http://daten.dieweltistgarnichtso.net/src/schwrkrft/test.html 17:47 Pexin or every center of gravity must be aggregated above some tole 17:48 Pexin ..tolerance 17:48 erle Pexin as you can see from the javascript, the calculations are really easy. you can also click the objects to focus them. 17:50 Pexin I guess it would need to just ignore sources outside a fixed radius, no matter how strong those sources may be 17:50 erle i believe that aggregation is not necessary, rather a mix of those approaches can work 17:51 erle a fixed radius would actually not be a good idea 17:51 Pexin but possibly necessary for something like MT 17:51 Pexin it's not like it doesn't already take shortcuts 17:52 erle no, you misunderstand 17:53 Pexin probably 17:53 Pexin also since this isn't strictly engine related (yet) ..maybe wrong channel, hm 17:53 erle what you want for simplification and a flexible API is *probably* just 1. a way to override the gravity vector for a player 2. a way to override which way is ”up” for the camera for a player. 17:54 erle IMO that's the only two things the engine is lacking here, everything else can be done in lua 17:54 erle such things would also allow you to create stuff like ”walking on walls” spiderman style things 17:55 Pexin not just players 17:55 erle and given the cuboid planet, you could just make sure that “down” is perpendicular to the object 17:55 erle oh right yeah 17:55 erle and that kind of thing does not need any n-body simulations 17:55 erle but you could have them 17:56 Pexin and I'm thinking more of spaceships 17:57 erle if you are thinking of spaceships, then you could have an n-body simulation 17:59 erle well, i have revised my opinion: i'd add: 1. a way to override the gravity vector for an entity/player and reset it to “natural”. 2. a way to override which way is ”up” for a player, regarding the camera or reset it to “natural”. 3. node properties that contain vectors for which way is up/down and where the gravity goes, which affect all objects that are in the “natural” state. 18:00 erle with the “which way is up” vector default being the opposite of the “gravity” vector by default, unless you simplyfy it to “which way is down” (which might be more desirable tbh) 18:00 Pexin for the spiderman thing, gravity isn't really needed, more a "sticky" property 18:01 erle not necessarily. on the cuboid planet you might want to “walk on walls” but still jumping should work like you want it. 18:01 erle otherwise you fall off 18:01 erle spiderman obv would fall off, bad example 18:04 erle Pexin well, what is keeping you from adding a property that overrides the gravity vector? 18:04 Pexin globally? 18:05 erle no, per player or object 18:06 erle oh wait lol 18:06 Pexin you mean like dynamically changing the vector each (client?)step based on direction of my self-defined source? 18:06 erle acceleration 18:06 erle yes 18:06 erle go look in clientenvironment.cpp or how it is called 18:07 erle you can prototype it the way you want 18:07 erle like i did 18:07 erle i can't find the code right now though, sorry 18:09 erle Pexin prototyping this with a fixed point source at 0,0,0 should not take you more than 20 to 30 minutes 18:12 MTDiscord erle: Isn't your attraction thingy basically O(n²) 18:13 MTDiscord I remember writing similar things in extracurriculars and they all where O(n²) 18:15 erle luatic i posted my javascript thingy only to show how easy it is to implement. surely you would not take the mass of a spaceship in orbit into account for the trajectory of a planet in a game 18:17 erle luatic as i said, the job of figuring out the gravity vectors can be left to a game 18:18 erle the engine just needs to provide a way to set gravity and camera (independently, if necessary – that's important) explicitly for an obejct and generally for a node/area (though keeping it on nodes is preferable IMO) 18:18 erle everything else can be built on that 18:19 erle by sidestepping the idea of gravity simulation entirely you get a great deal of simplification 19:10 Baytuch Good morning 20:58 celeron55 i agree camera objects make sense for cheat prevention, but also for interpolation. also they could probably be useful for having a portion of a world loaded, or making preloading of such less painful. that being said, otherwise i don't like persistent camera objects 20:58 celeron55 but me not liking them doesn't mean they wouldn't be necessary 22:41 sfan5 merging #12425 22:41 ShadowBot https://github.com/minetest/minetest/issues/12425 -- Fix LBM docs by TurkeyMcMac 23:35 erle wait, what is “activated”? 23:36 erle does the activated vs loaded difference explain why LBMs are unreliable?