| Time |
Nick |
Message |
| 00:30 |
|
kilbith joined #minetest-dev |
| 01:19 |
|
kilbith_ joined #minetest-dev |
| 03:26 |
|
hlqkj1 joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 07:26 |
|
olliy joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 09:33 |
|
Dyedefra joined #minetest-dev |
| 09:54 |
|
hlqkj joined #minetest-dev |
| 09:54 |
|
calcul0n_ joined #minetest-dev |
| 10:09 |
|
hlqkj_ joined #minetest-dev |
| 10:22 |
|
Fixer joined #minetest-dev |
| 11:05 |
|
twoelk joined #minetest-dev |
| 11:05 |
sfan5 |
merging game#2850, game#2837 in 10m |
| 11:05 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2850 -- Fix wield image for coral and kelp nodes by An0n3m0us |
| 11:05 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2837 -- mtg_craftguide: Fix incorrect item tooltips by pauloue |
| 11:09 |
|
absurb joined #minetest-dev |
| 11:14 |
|
hlqkj1 joined #minetest-dev |
| 11:40 |
|
proller joined #minetest-dev |
| 12:17 |
|
tech_exorcist joined #minetest-dev |
| 13:36 |
|
calcul0n__ joined #minetest-dev |
| 13:40 |
|
ronoaldo joined #minetest-dev |
| 14:07 |
|
hlqkj1 joined #minetest-dev |
| 14:23 |
|
nore joined #minetest-dev |
| 14:25 |
|
I_am_6r1d joined #minetest-dev |
| 14:42 |
|
ronoaldo joined #minetest-dev |
| 15:02 |
|
Wuzzy joined #minetest-dev |
| 15:05 |
|
I_am_6r1d joined #minetest-dev |
| 15:26 |
|
hlqkj1_ joined #minetest-dev |
| 15:31 |
|
ronoaldo joined #minetest-dev |
| 16:39 |
|
eugenefil joined #minetest-dev |
| 16:41 |
|
I_am_Grid joined #minetest-dev |
| 16:48 |
|
I_am_6r1d joined #minetest-dev |
| 16:50 |
|
mizux joined #minetest-dev |
| 16:56 |
|
hlqkj joined #minetest-dev |
| 17:10 |
|
Taoki joined #minetest-dev |
| 18:13 |
|
proller joined #minetest-dev |
| 18:50 |
|
twoelk left #minetest-dev |
| 19:08 |
|
hlqkj joined #minetest-dev |
| 19:58 |
sfan5 |
#11078 |
| 19:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/11078 -- Mainmenu: Improve "Join Game" tab by sfan5 |
| 20:04 |
MTDiscord |
<Warr1024> You play on 127.0.0.1:30000? That's one of my favorites too. |
| 20:04 |
Krock |
!up 127.0.0.1 |
| 20:04 |
ShadowBot |
Krock: 127.0.0.1 port 30000 is up (191us) |
| 20:05 |
Krock |
Warr1024: I'm hosting. join now |
| 20:05 |
MTDiscord |
<Warr1024> Already did ... I don't see you on though. :-D |
| 20:07 |
Krock |
the PR looks good overall, although there's now some wasted space due to the public/favourite entries |
| 20:07 |
MTDiscord |
<Warr1024> Heh, the new layout is nice, but to get me to actually use the Join tab instead of a bunch of external launcher shortcuts, MT would have to give me the option to remember my password for each server... |
| 20:08 |
MTDiscord |
<Warr1024> The wasted space on the left seems to be compensated by better space use on the right, and if the "Favorites" list disappears if it's empty (i.e. new players) then you don't sacrifice much. |
| 20:08 |
MTDiscord |
<GreenXenith> I commented with public icon suggestions, and was about to edit to include ? but then realized people would probably fight over whether to use ? or ? :] |
| 20:09 |
Krock |
so an animated gif would solve it? |
| 20:09 |
MTDiscord |
<GreenXenith> Haha, yep |
| 20:09 |
MTDiscord |
<Warr1024> Make it rotate the wrong way just to troll people who are actually paying attention |
| 20:09 |
MTDiscord |
<appguru> Animated icons? Eww. |
| 20:10 |
MTDiscord |
<Warr1024> tbf the ... what, is that binoculars? seems a bit voyeuristic for "public servers"... |
| 20:10 |
MTDiscord |
<appguru> eeh, programmer art :P |
| 20:10 |
|
DS-minetest joined #minetest-dev |
| 20:11 |
MTDiscord |
<appguru> it wasn't thought out well by me |
| 20:11 |
MTDiscord |
<GreenXenith> Oh, haha, I didnt even realize it was binoculars. I couldn't see the black so I thought it was just two dots. |
| 20:11 |
MTDiscord |
<GreenXenith> for like p2p or something x) |
| 20:11 |
MTDiscord |
<Warr1024> Yeah, could be worse. I mean, no icon would also be an option; they'd be the only entries where the text is flush-left. Could maybe use a different background color for those entries (can you do that with formspecs?) |
| 20:11 |
MTDiscord |
<appguru> but I'm happy to see that my effort wasn't wasted :D |
| 20:11 |
sfan5 |
btw appguru I think you broke your old PR when merging |
| 20:11 |
MTDiscord |
<Warr1024> I mean, we could bikeshed the details forever, but the foundations seem solid enough as it is. |
| 20:11 |
sfan5 |
because the column options that define icons for the first column were absent |
| 20:12 |
MTDiscord |
<appguru> possible |
| 20:12 |
|
I_am_6r1d joined #minetest-dev |
| 20:12 |
sfan5 |
@GreenXenith where do you think I would find a suitable icon of ? that can be used in MT? |
| 20:13 |
MTDiscord |
<GreenXenith> Off the top of my head? No idea. Why, do you want to actually use it? |
| 20:13 |
sfan5 |
yes? |
| 20:13 |
MTDiscord |
<Warr1024> Get the abstract "globe with meridians" one instead of one that shows actual continents if you don't want to make unwanted geopolitical statements. |
| 20:14 |
MTDiscord |
<Warr1024> There are open-source emoji art projects like twemoji or emojitwo ... I'm not sure which ones have acceptable licenses. |
| 20:19 |
|
Andrey01 joined #minetest-dev |
| 20:20 |
sfan5 |
somewhat related thought: mods should be able to set what the server announces for creative_mode/pvp/damage_enabled |
| 20:20 |
sfan5 |
since the engine globals cannot accurately reflect whatever the game is doing |
| 20:20 |
MTDiscord |
<GreenXenith> does the icon license have to be CC0 or anything? |
| 20:21 |
sfan5 |
we have existing textures with CC-BY-SA and Apache 2 |
| 20:21 |
sfan5 |
CC0 is also okay surely |
| 20:22 |
MTDiscord |
<GreenXenith> https://icons8.com/icon/63766/globe unfortunately has an outline but it has both america and europe ... also ambiguous (unlisted) license |
| 20:25 |
MTDiscord |
<appguru> sfan5: Twemoji |
| 20:25 |
MTDiscord |
<appguru> https://twemoji.twitter.com/ |
| 20:26 |
|
I_am_6r1d joined #minetest-dev |
| 20:28 |
Andrey01 |
appguru: I`ve made the range of collision determination configurable, in any case if set it to 10.0 to all directions, there is no absolutely dropping the performance |
| 20:29 |
MTDiscord |
<appguru> Andrey01: Have you stress-tested it? Like, fired a million raycasts and benchmarked the time difference depending on collision range? |
| 20:29 |
Andrey01 |
the performance starts to drop fast somewhere from 20.0 range |
| 20:29 |
MTDiscord |
<GreenXenith> sfan5: Twemoji version: https://emojipedia-us.s3.dualstack.us-west-1.amazonaws.com/thumbs/160/twitter/281/globe-showing-europe-africa_1f30d.png |
| 20:29 |
MTDiscord |
<appguru> no |
| 20:29 |
sfan5 |
hm |
| 20:30 |
MTDiscord |
<GreenXenith> I'd just go with the ? tbh |
| 20:30 |
MTDiscord |
<GreenXenith> Feels more server-y anyway |
| 20:30 |
MTDiscord |
<appguru> yeah me too |
| 20:30 |
Krock |
but not all fonts support ? if you meant that |
| 20:30 |
MTDiscord |
<appguru> not the font one |
| 20:30 |
MTDiscord |
<GreenXenith> In Minetest it will be a png |
| 20:30 |
MTDiscord |
<appguru> ^ |
| 20:31 |
MTDiscord |
<appguru> Andrey01: Again, how are you testing? Only pointing at things? That shouldn't be anywhere near sluggish. |
| 20:31 |
MTDiscord |
<appguru> You have to consider servers like CTF where you have 10+ players constantly firing guns with ranges of hundreds of blocks |
| 20:31 |
|
Wuzzy joined #minetest-dev |
| 20:31 |
Andrey01 |
I test it with nodes |
| 20:32 |
MTDiscord |
<appguru> A single explosion already requires 1k+ raycasts |
| 20:32 |
MTDiscord |
<Warr1024> Is there some reason why extrude meshes are so heavily unoptimized, e.g. all the hidden surfaces between pixels being drawn? I assume people assume that you won't have thousands of those on-screen at a time, but that's not always the case... |
| 20:33 |
MTDiscord |
<appguru> Because extrude meshes aren't really generated per texture. |
| 20:33 |
MTDiscord |
<appguru> They are generated per resolution. |
| 20:33 |
MTDiscord |
<Warr1024> Ooooh.... |
| 20:33 |
MTDiscord |
<Warr1024> ouch, so that means that it's actually even more unoptimized than I thought because there are a ton of transparent surfaces I didn't even see :-) |
| 20:33 |
MTDiscord |
<appguru> Well, the GPU tends to deal with that quite fine |
| 20:34 |
MTDiscord |
<GreenXenith> There, 16x16 Twemoji globe with meridians. Just need attribution somewhere ;p |
| 20:34 |
MTDiscord |
<GreenXenith> https://cdn.discordapp.com/attachments/747163566800633906/821843858185781318/server_flags_public.png |
| 20:34 |
MTDiscord |
<Warr1024> Yeah, until it doesn't. |
| 20:34 |
MTDiscord |
<appguru> It can simply discard such transparent fragments. |
| 20:34 |
MTDiscord |
<appguru> If we're really in for the speed, we could already discard entire triangles in the vertex shader: https://community.khronos.org/t/how-do-i-discard-a-vertex-in-a-vertex-shader/52040 |
| 20:34 |
MTDiscord |
<Warr1024> I just noticed that if I clip into an extrude mesh so that the near clipping plane cuts off the outer surface, I can see a grid of internal surfaces in there... |
| 20:35 |
sfan5 |
I think irrlicht included a vertex minimization algorithm, could just run that on the generated mesh |
| 20:35 |
MTDiscord |
<appguru> I don't think we could |
| 20:36 |
MTDiscord |
<Warr1024> I guess though the question becomes though is there some reason we shouldn't generate a mesh per wield image? |
| 20:36 |
MTDiscord |
<appguru> In order to support all possible textures, an extrusion mesh for a texture has to be the way it currently is |
| 20:36 |
MTDiscord |
<appguru> Memory I'd say |
| 20:36 |
sfan5 |
uh huh, you're right |
| 20:36 |
MTDiscord |
<Warr1024> We burn memory by caching dynamic media forever. Are meshes that much worse? |
| 20:37 |
MTDiscord |
<appguru> We cache dynamic media forever? |
| 20:37 |
MTDiscord |
<Warr1024> Far as I can tell there are certain things we never expire. Images created using texture mods, dynamic_add_media or whatever it's called, etc. |
| 20:37 |
MTDiscord |
<appguru> texture mods don't expire |
| 20:37 |
sfan5 |
textures are not removed until exiting the game, regardless of where they came from |
| 20:38 |
MTDiscord |
<appguru> but dynamic_add_media can be overwritten |
| 20:38 |
MTDiscord |
<appguru> with something smaller |
| 20:38 |
MTDiscord |
<Warr1024> It's pretty easy for a server to DoS a client by filling up memory until they either start swapping out like mad or have to lean on the OOM killer; I've done it to myself plenty lately. |
| 20:38 |
sfan5 |
@appguru it can't |
| 20:38 |
MTDiscord |
<appguru> it can't? |
| 20:38 |
sfan5 |
you can only send a given filename once |
| 20:38 |
MTDiscord |
<appguru> oof |
| 20:38 |
MTDiscord |
<appguru> there goes my plans |
| 20:39 |
MTDiscord |
<Warr1024> in contrast, if we cache an extrude mesh forever for each image that's ever actually used to create a mesh, then it wouldn't use a LOT more memory than just having already cached the image in uncompressed form forever, I mean, unless somebody purposefully uses pathological geometry |
| 20:39 |
MTDiscord |
<Warr1024> we also only would have to cache based on transparency of the image, not necessarily the entire image |
| 20:39 |
MTDiscord |
<Warr1024> so e.g. things that differ only by color would still share meshes |
| 20:40 |
sfan5 |
how many item images match by their entire alpha plane? I doubt it's that many |
| 20:40 |
MTDiscord |
<Warr1024> I don't know how big of an impact it might have on render performance but it'd be nice to try and see if I can make my server's spawn area not drop framerate by 75% due to the items there. |
| 20:40 |
sfan5 |
you're right that the savings might be worth it however |
| 20:41 |
MTDiscord |
<appguru> hmmm |
| 20:41 |
MTDiscord |
<appguru> do we even have to cache the meshes? |
| 20:41 |
MTDiscord |
<Warr1024> I think you'd find a decent set of matching images. People like to add tools to games, but often they just use the same pick shape with different color materials... |
| 20:41 |
MTDiscord |
<appguru> couldn't we just cache the vertex indices for the resolution matching extrusion meshes? |
| 20:41 |
MTDiscord |
<Warr1024> Heh, I mean, actually expiring cached things like meshes, images, media, etc would be awesome :-D |
| 20:41 |
MTDiscord |
<Warr1024> I imagine there's probably some Irrlichty reason why it's harder than it sounds. |
| 20:41 |
MTDiscord |
<appguru> well we've forked Irrlicht :D |
| 20:41 |
sfan5 |
texture use is not refcounted |
| 20:42 |
sfan5 |
but that's more of a MT problem |
| 20:42 |
MTDiscord |
<Warr1024> Ah, I see |
| 20:43 |
MTDiscord |
<Warr1024> I sort of assumed there was some way to tell when a texture was actually being referenced in a scene or something, so you could just walk the scene every so often, set a "last used timestamp" on each texture, and then purge textures that have stamps too old. |
| 20:43 |
MTDiscord |
<Warr1024> you might take a hit rebuilding them if you're wrong about which ones, but if you're mostly right it shouldn't be much worse than you already get having to build dynamic media at mod request anyway... |
| 20:43 |
MTDiscord |
<appguru> but back to topic: as any extrusion mesh is a subset of the faces of the current extrusion mesh of the same resolution, caching just the indices should work, and save quite some memory - no need to copy same vertices, texcoords and normals |
| 20:44 |
MTDiscord |
<Warr1024> Oh, you mean have multiple meshes that share the same vertices and just use a subset? That does sound pretty nice. |
| 20:44 |
MTDiscord |
<appguru> yeah |
| 20:44 |
MTDiscord |
<appguru> that way, we could consider just leaving the extrusion meshes in VRAM |
| 20:45 |
MTDiscord |
<Warr1024> Heh, I hope I can get somebody who already knows this stuff interested in playing with the idea, but if I have to be the one to pursue it, it's not likely going to come together fast... |
| 20:45 |
sfan5 |
where did server_divider_incompatible.png come from? |
| 20:46 |
MTDiscord |
<appguru> my own work IIRC |
| 20:46 |
sfan5 |
great |
| 20:46 |
MTDiscord |
<appguru> if it's a plain red X at least |
| 20:49 |
Andrey01 |
appguru: ok, I give up my idea if it is really hacky and bad-considered |
| 20:51 |
MTDiscord |
<appguru> benchmark it, and see for yourself how range and performance are related |
| 20:51 |
Andrey01 |
but I don`t have any idea how to obtain that with R-trees how you suggested earlier because I am not so competent at all |
| 20:51 |
MTDiscord |
<appguru> it might be that I am wrong, and that range could be safely increased a bit without significant performance loss |
| 20:52 |
MTDiscord |
<appguru> TBF I don't see myself capable of implementing such a thing in C++ either |
| 20:55 |
sfan5 |
@GreenXenith I'd have preferred a colorful non-flat earth icon myself but I went with the one you suggested, thanks |
| 20:57 |
MTDiscord |
<Warr1024> There's a globe_americas and a globe_africa and a globe_asia emoji, but not a globe_antarctica one... |
| 20:58 |
MTDiscord |
<GreenXenith> well, heres a 16x16 flat earth. Dont know where to find a non-flat. |
| 20:58 |
MTDiscord |
<GreenXenith> https://cdn.discordapp.com/attachments/747163566800633906/821849923498410014/earth_africa.png |
| 20:58 |
sfan5 |
the samsung one looks really nice but not like we could use it |
| 20:58 |
MTDiscord |
<GreenXenith> Upside of the meridian globe is it doesnt matter if its flat or not because its so small anyway |
| 21:01 |
|
I_am_6r1d joined #minetest-dev |
| 21:05 |
|
v-rob joined #minetest-dev |
| 21:05 |
Andrey01 |
appguru: how I see from testing, the performance depends not only from set range, but still from player speed |
| 21:06 |
Andrey01 |
in any case FPS drops in few times when you move with fly e.g. |
| 21:07 |
Andrey01 |
so the adequate max value is 10 I suppose |
| 21:08 |
v-rob |
In Irrlicht, if I call createDevice twice to have two drivers alongside each other, will that open two windows? |
| 21:09 |
sfan5 |
I guess so |
| 21:09 |
Andrey01 |
so if you set the value is higher 10 and stay at place, FPS drops insignificantly even at high values |
| 21:10 |
v-rob |
I don't see any way in the API to not open a window. RenderingEngine uses createDevice for a null device, but drops it within the same function call. |
| 21:10 |
sfan5 |
do you want offscreen rendering or what? |
| 21:11 |
sfan5 |
because a null device would obviously not create a window |
| 21:13 |
v-rob |
I want to know the feasibility of using Burning's Video as a fallback for #10801 in case the platform doesn't support e.g. render textures or textures above a certain size, so there is at least a fallback, even if it's software. |
| 21:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/10801 -- Add CSM 2D Drawing API by v-rob |
| 21:17 |
v-rob |
If two devices work, then they can be used almost interchangeably, except for conversion code between the two formats. |
| 21:17 |
sfan5 |
hm |
| 21:18 |
|
proller joined #minetest-dev |
| 21:34 |
v-rob |
Well, the SDL 1.2 device only opens one window, but the rest seem to open multiple windows. I guess if I really want it, it'll need modifying in our fork. |
| 21:35 |
MTDiscord |
<Jordach> v-rob: does this drawing API support animating supplied meshes like b3d |
| 21:35 |
v-rob |
It doesn't support 3D at all yet. That's for the next PR. But yes, it will support animated meshes. |
| 21:36 |
MTDiscord |
<Jordach> because i need some way of animating a first person set of arms and current wieldmesh implementation leaves a lot to be desired |
| 21:38 |
MTDiscord |
<GreenXenith> Am I missing something or do overlay_tiles not support texture alpha |
| 21:39 |
v-rob |
Well, my PR wouldn't work well for that anyway because it's CSM only. A server-side API for client-side drawing would be... difficult |
| 21:40 |
MTDiscord |
<Jordach> actually no i was actually on planning on syncronising a lot of game state with the clients over CSM |
| 21:40 |
v-rob |
Ah |
| 21:40 |
MTDiscord |
<Jordach> since the Lua only runs per frame, i don't have to worry about server bandwidth |
| 21:41 |
MTDiscord |
<Jordach> but what i'd prefer most is clientside entities |
| 21:43 |
v-rob |
Client-side entities sounds doubtful without SSCSM |
| 21:44 |
v-rob |
I can get away with my PR because it's for the GUI :) |
| 21:46 |
v-rob |
Although it would be cool if it is used for dynamic textures/models or even text on nodes/entities in the future. |
| 21:46 |
MTDiscord |
<Jordach> i had an experimental test with CSM entities: they can still use the server's definitions |
| 21:47 |
MTDiscord |
<Jordach> it's that locally they have a differing on_step and don't appear to the server |
| 21:48 |
sfan5 |
wouldn't additional client-side prediction (Lua code) be more useful than fully client-side entities? |
| 21:49 |
v-rob |
If it were fully client-side, I think the place to draw the line would be Lua wrappers around irr::ISceneNode for visuals only |
| 21:50 |
v-rob |
Other entity features belong to the server |
| 21:54 |
v-rob |
Hmm, Minetest compiled as server uses Irrlicht for things like core::vector2d, right? Is that the only purpose it uses it for? |
| 21:56 |
sfan5 |
probably, but it could every type defined in header files |
| 21:56 |
sfan5 |
could use* |
| 21:56 |
v-rob |
Huh |
| 22:00 |
MTDiscord |
<Jordach> i need to use CSM entities to do things with custom framerate specific stuff |
| 22:02 |
MTDiscord |
<Jordach> most of you here probably realise how expensive HUD updates etc actually are on bandwidth |
| 22:02 |
MTDiscord |
<Jordach> it's not packet decoding i have issue with, it's the actual kilobytes of crap i need to resend |
| 22:05 |
v-rob |
Hold on, I don't quite understand what the HUD has to with client-side entities. They seem rather different |
| 22:06 |
MTDiscord |
<Jordach> i need basically programmable entities to handle scenarios client side |
| 22:06 |
MTDiscord |
<Jordach> because updating a cosmetic rotating physics object server side is expensive |
| 22:06 |
sfan5 |
sounds doable with "just" prediction as I suggested |
| 22:07 |
MTDiscord |
<Jordach> i mean completely desynchronised to the server |
| 22:07 |
MTDiscord |
<Jordach> it's that they provide visual feedback to the clients current state |
| 22:08 |
sfan5 |
I'm thinking you could create a completely static entity on the server and rotate them however you want on the client |
| 22:08 |
sfan5 |
but that might not work if you want only that client to see them |
| 22:08 |
MTDiscord |
<Jordach> unfortunately i don't want other clients to see it |
| 22:08 |
sfan5 |
s/might/will/ |
| 22:09 |
DS-minetest |
if your client side entities should only be seen by one player, and just for visual effects, it might be better to use a different concept than entities. maybe something like 3d hud meshes? |
| 22:09 |
MTDiscord |
<Jordach> i mean in world that can interact with the world |
| 22:09 |
MTDiscord |
<Jordach> think of a bouncing ball |
| 22:09 |
MTDiscord |
<Jordach> then imagine set_rotate every 1/30th or 1/60th of a second |
| 22:10 |
v-rob |
As I suggested, pure visual wrappers around ISceneNodes are probably better than client-side entities |
| 22:10 |
MTDiscord |
<Jordach> they're "entities" |
| 22:10 |
DS-minetest |
and why should you not be able to see other players' balls? |
| 22:10 |
MTDiscord |
<Jordach> because they're cosmetic visuals |
| 22:10 |
MTDiscord |
<Jordach> and aren't game critical |
| 22:10 |
MTDiscord |
<Jordach> just to improve visual appeal |
| 22:11 |
DS-minetest |
still, if it's an existing ball bouncing in the world, all players should be able to see the ball |
| 22:11 |
DS-minetest |
(and it should be the same ball for all players) |
| 22:11 |
MTDiscord |
<Jordach> if it was required for gameplay it would be seen by all |
| 22:11 |
MTDiscord |
<Jordach> if it was required for cosmetic non-important reasons, it should be clientside |
| 22:12 |
DS-minetest |
do you have an example for such a reason? |
| 22:13 |
MTDiscord |
<Jordach> things like spent casings, crumbling node effects with cubes etc |
| 22:13 |
v-rob |
Oh strange, the server has its own IrrlichtDevice. Heck, the server could actually run my drawing PR for render textures :P |
| 22:14 |
sfan5 |
uh |
| 22:14 |
sfan5 |
where do you see that? the server does not link to Irrlicht, it cannot have a device |
| 22:15 |
DS-minetest |
hm, but these sound more like 3d particles than actual fully-fledged entities |
| 22:15 |
v-rob |
Oh, never mind. I feel dumb now... |
| 22:15 |
MTDiscord |
<Jordach> yes and no |
| 22:15 |
MTDiscord |
<Jordach> i still need to be able to manage set_animation() at a distance as well |
| 22:20 |
|
ssieb joined #minetest-dev |
| 22:21 |
v-rob |
My 3D rendering followup PR will necessarily have SceneNodes, so theoretically, they could potentially be put into the Minetest world scene and manipulated every frame with minetest.register_on_predraw with little extra effort. No idea if they would interact weirdly with normal entities though. |
| 22:21 |
v-rob |
Whether or not that's a good idea needs thinking out |
| 22:21 |
MTDiscord |
<Jordach> are they world aligned to use the same pos co-ords |
| 22:21 |
v-rob |
Well, you'd have to multiply their positions and scales by BS |
| 22:22 |
v-rob |
Unless the Lua interface took care of that for you |
| 22:22 |
v-rob |
But visual_scale for entities already needs to be multiplied by 10 on the server anyway |
| 22:23 |
MTDiscord |
<Jordach> what i need is the "type" that entities are |
| 22:23 |
MTDiscord |
<Jordach> just more generic |
| 22:24 |
MTDiscord |
<Jordach> i want to say amorphous as in can fill any needed cosmetic role |
| 22:24 |
v-rob |
What do you mean by "type"? |
| 22:24 |
v-rob |
Well, that's what ISceneNode is for |
| 22:24 |
MTDiscord |
<Jordach> how would i build an interface for that in CSM Lua |
| 22:25 |
v-rob |
Not sure what you mean. Do you mean the Lua <-> C++ interface? |
| 22:25 |
MTDiscord |
<Jordach> yes |
| 22:25 |
v-rob |
That's what the 3D PR will be doing |
| 22:26 |
MTDiscord |
<Jordach> as long as i can keep it attached to the camera's eye position |
| 22:26 |
MTDiscord |
<Jordach> i'm happy |
| 22:27 |
v-rob |
All that would need to be done for that is something like `scene_node:set_pos(minetest.localplayer:get_pos())` every frame or whatever |
| 22:28 |
v-rob |
Still, like I said, I don't know the full ramifications of that idea |
| 22:29 |
MTDiscord |
<Jordach> entities as they are have a lot of potential |
| 22:30 |
hlqkj |
|
| 22:30 |
v-rob |
But putting them on the client poses other questions. For instance, a player walking on a client-side entity could trigger anti-cheat since the server doesn't know that the player is on an entity |
| 22:30 |
MTDiscord |
<Jordach> they can just have a "walkable" like flag |
| 22:30 |
MTDiscord |
<Jordach> that disables object/object collision |
| 22:30 |
MTDiscord |
<Jordach> just not object/node collisions |
| 22:31 |
v-rob |
Right, but that's only an example of what could be a problem. There could be plenty of others. |
| 22:32 |
MTDiscord |
<Jordach> as long as it doesn't interfere with server side authority |
| 22:33 |
MTDiscord |
<Jordach> then it should be harmless |
| 22:33 |
v-rob |
Hopefully |
| 22:51 |
|
T4im joined #minetest-dev |
| 23:17 |
|
T4im joined #minetest-dev |
| 23:45 |
|
T4im joined #minetest-dev |
| 23:46 |
|
kilbith joined #minetest-dev |
| 23:50 |
|
T4im joined #minetest-dev |
