| Time |
Nick |
Message |
| 02:41 |
|
behalebabo joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:20 |
|
calcul0n joined #minetest-dev |
| 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 |
<ROllerozxa> "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 |
| 10:32 |
|
HuguesRoss joined #minetest-dev |
| 10:35 |
|
proller joined #minetest-dev |
| 11:02 |
MTDiscord |
<luatic> nrz_: Just to be clear: That proposal is by the one being spammed, not by the one spamming. |
| 11:05 |
|
proller joined #minetest-dev |
| 12:24 |
|
kilbith joined #minetest-dev |
| 12:28 |
kilbith |
https://i.imgur.com/B7vWkz7.jpg |
| 12:28 |
kilbith |
thoughts? |
| 12:28 |
|
Fixer joined #minetest-dev |
| 12:32 |
MTDiscord |
<MisterE> What would you guys think of a release party for MT 5.6? |
| 12:32 |
MTDiscord |
<MisterE> I could host a server for it for a day |
| 12:35 |
MTDiscord |
<MisterE> It would need planning |
| 12:36 |
MTDiscord |
<MisterE> 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 |
<luatic> get rid of registering cameras |
| 12:59 |
kilbith |
a target position will be normalized vector, I think |
| 12:59 |
MTDiscord |
<luatic> just do a set_camera which takes all your register params |
| 12:59 |
kilbith |
s/a/the |
| 12:59 |
MTDiscord |
<luatic> kilbith: that'd be a look dir |
| 13:00 |
MTDiscord |
<luatic> cameras should also be attachable to objects etc. |
| 13:00 |
MTDiscord |
<luatic> in fact cameras should be a type of low-profile object |
| 13:00 |
kilbith |
<luatic> 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 |
<luatic> 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 |
<luatic> kilbith: Then you also need unregistering |
| 13:02 |
kilbith |
of course |
| 13:03 |
MTDiscord |
<luatic> 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:08 |
|
appguru joined #minetest-dev |
| 13:10 |
MTDiscord |
<luatic> for a clean API it should be |
| 13:10 |
MTDiscord |
<luatic> 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 |
<luatic> 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:20 |
|
Taoki joined #minetest-dev |
| 13:45 |
MTDiscord |
<luatic> It's not worth it |
| 13:45 |
MTDiscord |
<luatic> 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 |
<luatic> The clients do that |
| 13:49 |
MTDiscord |
<luatic> 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 |
<luatic> 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:06 |
|
nrz joined #minetest-dev |
| 14:11 |
erle |
sfan5 yeah so making a cam object and assigning it could just push the stuff to the client, or not? |
| 14:33 |
|
proller joined #minetest-dev |
| 15:16 |
|
proller joined #minetest-dev |
| 16:20 |
|
proller joined #minetest-dev |
| 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 |
|
appguru joined #minetest-dev |
| 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 |
<luatic> erle: Isn't your attraction thingy basically O(n²) |
| 18:13 |
MTDiscord |
<luatic> I remember writing similar things in extracurriculars and they all where O(n²) |
| 18:14 |
|
fluxionary joined #minetest-dev |
| 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 |
| 19:37 |
|
Fixer_ joined #minetest-dev |
| 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 |
| 21:44 |
|
kaeza joined #minetest-dev |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 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? |
| 23:41 |
|
kaeza joined #minetest-dev |
