| Time |
Nick |
Message |
| 00:00 |
pgimeno |
as for UTF-32 not being characters... well, there isn't an immediate relationship between UTF-32 length and displayed width, but certainly there is an immediate relationship between UTF-32 length and string length in codepoints. Rendering Unicode is a different matter, and that's why things like Pango exist. |
| 00:01 |
pgimeno |
hecks: I'm looking at the Blender page. Do Blender models appear mirrored with respect to their Minetest counterparts? |
| 00:02 |
hecks |
If your coordinate space is correct, they should not. |
| 00:03 |
hecks |
You need to export as Z forward Y up X right |
| 00:06 |
pgimeno |
if the handedness of the coordinate systems is different, it should |
| 00:06 |
hecks |
nothing should appear mirrored if the exporter converts the coordinate space correctly |
| 00:07 |
pgimeno |
does it? |
| 00:07 |
hecks |
my character's right hand in blender is still her right hand in minetest |
| 00:08 |
hecks |
if this is not the case, you messed up your settings or the exporter is buggy |
| 00:08 |
pgimeno |
maybe the page should specify that the converter should take care of this conversion |
| 00:08 |
hecks |
it does, in the coordinate space section |
| 00:08 |
hecks |
always export as lefthanded y-up |
| 00:09 |
pgimeno |
I'm asking because I didn't understand that from the page |
| 00:10 |
hecks |
if you just follow the instructions (model facing Y+ in blender, export as left-Y) it should all work |
| 00:11 |
pgimeno |
my suggestion is to change the phrasing of this sentence: "Be sure to export all your models in Lefthanded Y-up to avoid surprises." to: "Be sure to select Lefthanded Y-up in the exporter to avoid surprises." |
| 00:11 |
pgimeno |
I can do it if you agree |
| 00:12 |
hecks |
I guess, although I don't know how the B3D exporter calls this space, I don't use it |
| 00:13 |
pgimeno |
as phrased, it may be interpreted that it's your job to ensure that you're using the right coordinate system while modelling, and that's where I had trouble understanding and why I asked if you had to have your models mirrored |
| 00:13 |
hecks |
no, just set the export options properly |
| 00:13 |
hecks |
the original article had some weird advice about making the model face +x, i hope that's a mistake and not some weird b3d quirk |
| 00:14 |
hecks |
but a quick look at sam says it was a mistake |
| 00:14 |
hecks |
he's facing +y |
| 00:14 |
hecks |
he's also modeled in BS space which is disgusting |
| 00:15 |
hecks |
right, shit |
| 00:16 |
pgimeno |
ok, rephrased |
| 00:17 |
MTDiscord |
<Jordach> i didn't model it btw, just textured |
| 00:17 |
pgimeno |
BS is BS, the name says it all :) |
| 00:18 |
hecks |
how could we eliminate the need to use BS space while modeling entities? |
| 00:19 |
hecks |
currently you either have to model in 10x scale or inflate the visual_size |
| 00:19 |
pgimeno |
if it's a requirement for compatibility, we can't |
| 00:20 |
pgimeno |
there are a number of things that depend on BS=10, and that includes physics too |
| 00:20 |
hecks |
added a coordinate scale section |
| 00:20 |
pgimeno |
I'd like to get rid of everything BS related, maybe keep a COMPAT_MULTIPLIER applied to some stuff that requires it and that's all |
| 00:21 |
hecks |
the stupid thing is that node meshes do not need this scale |
| 00:21 |
hecks |
meaning if you want to use a mesh as both a node and an entity, whoops |
| 00:21 |
hecks |
you need visual_size = { x=10, y=10 } |
| 00:21 |
hecks |
and if that wasn't enough |
| 00:22 |
hecks |
say your entity is a skinned mesh - now if you want to give them a hat... |
| 00:22 |
hecks |
as a bone attachment that is |
| 00:22 |
hecks |
this hat can NOT be scaled 10x, it must actually be 1x |
| 00:22 |
hecks |
and then if you ever detach it, it'll shrink back to 0.1x and you'll have to inflate it again |
| 00:23 |
hecks |
it's a sordid mess and that's why i'm asking about some sort of deprecation path for it |
| 00:29 |
|
Extex joined #minetest-dev |
| 00:30 |
pgimeno |
hmm... new attachment API? |
| 00:30 |
hecks |
that wouldn't solve a thing, think about it |
| 00:30 |
hecks |
the attachment issue happens because you are forced to apply a scale to the first model |
| 00:30 |
hecks |
you either model both in 10x scale or deal with this crap |
| 00:31 |
pgimeno |
well, accompanied by some sort of declaration that a certain mesh is "new kind" |
| 00:31 |
pgimeno |
where "new kind" means not scaled 10x |
| 00:31 |
hecks |
in that case you don't need new attachment API, the flag would be enough |
| 00:32 |
hecks |
it would have to scale the actual model instead of the entity (big difference) |
| 00:32 |
hecks |
metric_scale = true; |
| 00:34 |
pgimeno |
right, so if a new attachment API is not necessary, such a flag for meshes (or a new drawtype) would suffice to solve that particular issue, right? |
| 00:34 |
hecks |
just a flag for CAOs |
| 00:35 |
hecks |
it would basically mean (after BS space is killed) that the BS emulation should not be applied to this CAO |
| 00:35 |
pgimeno |
yes |
| 00:36 |
hecks |
I don't think it'll be that difficult to destroy BS, I'll look into it sometime |
| 00:37 |
pgimeno |
yeah, my plan was, 1) create a COMPAT_MULTIPLIER, 2) change BS to 1, 3) replace BS in everything that breaks with COMPAT_MULTIPLIER |
| 00:37 |
pgimeno |
4) delete BS |
| 00:40 |
pgimeno |
but getting anything done without being in github takes a lot of patience and I don't have enough |
| 00:41 |
pgimeno |
also some luck that someone is willing to forward a PR with my code |
| 00:42 |
hecks |
I would just delete BS everywhere except I/O because that's the only place it matters |
| 00:42 |
hecks |
it only has a place in serialization and being emulated in script API, due to how floats work it's not useful anywhere else |
| 02:21 |
|
v-rob joined #minetest-dev |
| 02:59 |
|
specing_ joined #minetest-dev |
| 04:19 |
|
v-rob joined #minetest-dev |
| 06:07 |
|
v-rob joined #minetest-dev |
| 06:59 |
|
nrz joined #minetest-dev |
| 07:05 |
nrz |
websockets are tcp based and slow |
| 07:05 |
nrz |
i already show 4 years ago that a full switch to TCP just make client moves laggy |
| 07:06 |
nrz |
the ordering of the client moves are not adaptred for MMO games |
| 08:04 |
|
tech_exorcist joined #minetest-dev |
| 08:45 |
sfan5 |
not like you have an alternative if you want to port MT to the browser |
| 09:25 |
|
calcul0n__ joined #minetest-dev |
| 09:49 |
MTDiscord |
<Sublayer plank> how much left is there to remove from irrlicht now after #48? |
| 09:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/48 -- Install icon and .desktop file on Unix systems by jnumm |
| 09:49 |
MTDiscord |
<Sublayer plank> that's... not the right repo lol |
| 09:54 |
MTDiscord |
<y5nw> @__sub maybe it should be irrlicht#48 ? |
| 09:54 |
MTDiscord |
<appguru> yes |
| 09:54 |
MTDiscord |
<appguru> irrlicht#48 |
| 09:54 |
MTDiscord |
<appguru> looks like it hasn't been implemented yet |
| 09:58 |
sfan5 |
irr#48 |
| 09:58 |
ShadowBot |
https://github.com/minetest/irrlicht/issues/48 -- Delete unused features by hecktest |
| 10:28 |
|
longerstaff13 joined #minetest-dev |
| 10:53 |
|
entuland joined #minetest-dev |
| 11:03 |
nrz |
sfan5: i don't see the point to port MT to browser, it's as huge as rewrite the whole client in rust :D |
| 11:09 |
rubenwardy |
webassembly exists. It's probably as huge as adding Android support |
| 11:09 |
rubenwardy |
finicky build system and weird graphics |
| 11:12 |
nrz |
and redo the network layer to add compat on all servers ? and having nasty bugs/performance issue due to the fact anyone has not a up to date browser ? : |
| 11:12 |
rubenwardy |
you wouldn't change the network protocol at all, you'd use a websocket wrapper |
| 11:12 |
|
tech_exorcist_ joined #minetest-dev |
| 11:12 |
rubenwardy |
and yeah - it won't be the best experience, I'm against it |
| 11:26 |
|
tech_exorcist joined #minetest-dev |
| 11:29 |
sfan5 |
we already have "nasty bugs/performance issues" on android |
| 11:51 |
|
tech_exorcist joined #minetest-dev |
| 12:11 |
rubenwardy |
yeah true |
| 12:31 |
MTDiscord |
<Warr1024> TCP is no laggier than UDP. In my experience there is a very narrow band of network conditions under which TCP vs. UDP makes a difference. In better conditions they both work fine, in worse, neither has enough to work with. |
| 12:31 |
MTDiscord |
<Warr1024> I certainly wouldn't switch to websockets for everyone, but as a wrapper for web players it should be fine. |
| 13:00 |
sfan5 |
not really |
| 13:00 |
sfan5 |
UDP is exactly what you want for games because TCP stalling everything when one packet gets lost is not acceptable |
| 13:01 |
sfan5 |
(interactive games that is, you won't need it for chess) |
| 13:02 |
MTDiscord |
<Kimapr> but that one packet may likely be important, e.g. a node getting placed/dug |
| 13:04 |
sfan5 |
it's more likely not to be important, you send e.g. 30 movement packets a second and if one gets lost you just wait for the next |
| 13:09 |
Calinou |
people are essentially remaking HTTP on UDP these days with QUIC |
| 13:09 |
Calinou |
TCP is OpenGL whereas UDP is Vulkan :) |
| 13:10 |
Calinou |
for the web, you can get unreliable transfers with WebRTC but it's a pain to set up compared to WebSockets |
| 13:27 |
|
hecks joined #minetest-dev |
| 13:47 |
|
Fixer joined #minetest-dev |
| 13:52 |
MTDiscord |
<Warr1024> My point about TCP vs UDP is that the differences in practice are much smaller than you would think. UDP's advantage over TCP is really only when you have a network that just arbitrarily loses or reorders packets, but is otherwise fairly healhty which I just don't see much. Usually it seems like people are at the extremes. You have players on fiber who would get perfectly fine performance out of either. You have players on |
| 13:52 |
MTDiscord |
satellite for whom the experience is largely ruined either way. There's only a narrow band where the difference is actually important. |
| 13:52 |
hecks |
this "narrow band" is cell networks which are very common |
| 13:53 |
MTDiscord |
<Warr1024> Having used cell networks myself, I can say that that narrow band is PRESENT in cell networks, but cell networks themselves really cover the full range. |
| 13:54 |
MTDiscord |
<Warr1024> It's also highly dependent on the game. I think the engine should offer options for players without assuming that those options would be intolerable to them without knowing the game design. |
| 13:55 |
hecks |
i'm just saying that my internet can drop quite a few packets every now and then |
| 13:55 |
MTDiscord |
<Warr1024> I certainly wouldn't play CTF with a 150ms ping time, but NodeCore I've tested with ping times in the 1000+ range. |
| 13:56 |
MTDiscord |
<Warr1024> I would not make TCP or TCP-based protocols/wrappers the default, but I don't want to dismiss them as an option. There are a lot of places where streams can go that datagrams can't. |
| 13:56 |
MTDiscord |
<Warr1024> It MAY be something exernal to the project, like a proxy, but we MAY want to do it internally if e.g. we want to support something like play-on-web or something. |
| 13:57 |
sfan5 |
I'm not against a potential web client, but the advantages are UDP are real and not just in some "narrow cases" |
| 13:58 |
MTDiscord |
<Warr1024> There's a small community that seems to be growing of users hosting servers on the yggdrasil overlay network because they don't have enough control over their own NAT at the ISP level. That network actually tunnels everything over TCP/TLS. |
| 13:59 |
MTDiscord |
<Warr1024> Anyway, anecdotally I've never seen enough advantage to UDP that would suggest I should go out of my way and build my own reliability layer to use it over TCP, and I've never seen anything more than anecdotal or "it stands to reason" evidence to refute it. I would be more convinced it's worth real effort if I saw some real-world hard data. |
| 14:00 |
MTDiscord |
<Warr1024> We would face the same decision deciding between websockets and webRTC for a potential web client. |
| 14:01 |
sfan5 |
does webrtc even work for this? I know it does in theory but the primary usecase of it is something else |
| 14:02 |
MTDiscord |
<Warr1024> It's an interesting question. As far as I understand it though WebRTC is sort of a generic transport and it's not necessarily specific to media? I mean there's no reason why we couldn't lie to it and just say "oh yeah, this is totally a VOIP voice call, it's just a codec you're not familiar with, don't worry about it :-)" |
| 14:02 |
MTDiscord |
<Warr1024> I think it's mainly for client-to-client communication with the server acting as an introduction point, but there's no reason why an MT server can't be both a server and an endpoint, either. |
| 14:03 |
hecks |
irrlicht/#48 is ready, do we merge it? |
| 14:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/48 -- Install icon and .desktop file on Unix systems by jnumm |
| 14:03 |
MTDiscord |
<Warr1024> I think I poked around with it actually, just can' remember what the specific problem I was trying to solve was, and it seemed to have a lot of flex to it. |
| 14:03 |
hecks |
bad bot |
| 14:03 |
sfan5 |
https://github.com/kyren/webrtc-unreliable |
| 14:03 |
MTDiscord |
<Sublayer plank> irr#48 |
| 14:03 |
ShadowBot |
https://github.com/minetest/irrlicht/issues/48 -- Delete unused features by hecktest |
| 14:04 |
MTDiscord |
<Warr1024> Hmm, webrtc-unreliable looks pretty interesting. If there were an existing something we could adapt to use in MT then that would make me lean more seriously into the idea of using it... |
| 14:04 |
sfan5 |
do we have any mods that use BMP? |
| 14:05 |
sfan5 |
I'm somewhat inclined to keep it since it's just so simple |
| 14:05 |
hecks |
bmp is supported |
| 14:05 |
hecks |
i had to keep it for the null driver to work |
| 14:05 |
sfan5 |
"BMP is also enabled because the null video driver would not compile without it." oh missed that |
| 14:06 |
sfan5 |
software renderer still exists right? |
| 14:06 |
hecks |
it does not |
| 14:06 |
hecks |
some remnants of the software renderer still exist for CImage support |
| 14:06 |
hecks |
like image blitting and scaling |
| 14:07 |
sfan5 |
ah so that's why SoftwareDriver2_compile_config.h still exists |
| 14:07 |
hecks |
yup, that's a dep of CBlit |
| 14:08 |
MTDiscord |
<Sublayer plank> how much is there left that can be removed from irrlicht now? |
| 14:08 |
hecks |
quite a bit but i think i got all the low hanging fruit |
| 14:08 |
hecks |
so i'm making a cutoff point here |
| 14:09 |
hecks |
any further reductions will involve paying a little more attention when deleting code |
| 14:09 |
hecks |
this was a simple grep-delete-repeat |
| 14:09 |
sfan5 |
I'll go and test though I don't expect bugs |
| 14:10 |
sfan5 |
one more thing though >Also for merging later it'd be good if you could reauthor the commits so that Github can automatically match them to an account. |
| 14:10 |
hecks |
how do i do that |
| 14:10 |
sfan5 |
or did you want to squash it? |
| 14:10 |
sfan5 |
hmm good question |
| 14:10 |
hecks |
squash it if you want |
| 14:10 |
sfan5 |
no need to bother then |
| 14:10 |
hecks |
i added a comment in one commit about not squashing it but i don't think there's any danger there now |
| 14:10 |
hecks |
and if it breaks i know what to restore |
| 14:11 |
hecks |
it was when i deleted support for loading texture names parsed out of models |
| 14:12 |
hecks |
it turns out irrlicht is a relatively well organized pigsty after all, if this only took three days |
| 14:12 |
hecks |
it also seems to compile faster than minetest in general, we should be using incomplete class pointers more |
| 14:13 |
sfan5 |
pointers are bad in modern c++11 |
| 14:13 |
sfan5 |
s/11$// |
| 14:14 |
hecks |
well, just use incomplete types is what i mean |
| 14:14 |
sfan5 |
might also be because irrlicht uses -fno-rtti and -fno-execptions |
| 14:14 |
hecks |
more often than not headers do not need other headers |
| 14:15 |
hecks |
the thing is that rebuilding a simple change in irrlicht somehow doesn't trigger a cascade where half the objects need updating |
| 14:15 |
hecks |
while it's often the case in minetest |
| 14:15 |
hecks |
and i'm pretty sure it's thanks to incomplete declarations and possibly the widespread use of interfaces |
| 14:17 |
sfan5 |
okay stuff still works |
| 14:17 |
sfan5 |
merging irr#48 in 5m |
| 14:17 |
ShadowBot |
https://github.com/minetest/irrlicht/issues/48 -- Delete unused features by hecktest |
| 14:18 |
sfan5 |
the coolguy_opt.x mesh shows pretty tiny but I guess it doesn't matter |
| 14:19 |
hecks |
it's metric, not BS |
| 14:20 |
|
calcul0n_ joined #minetest-dev |
| 14:21 |
sfan5 |
wait actually let me fix that since it's so easy |
| 14:22 |
hecks |
just don't fix it by scaling the mesh node =] |
| 14:22 |
sfan5 |
I won't |
| 14:25 |
MTDiscord |
<Sublayer plank> should the outdated doxygen windows binary in scripts/doc/ be deleted? |
| 14:25 |
hecks |
not unless it's broken |
| 14:26 |
hecks |
as long as it works and produces the docs, who cares |
| 14:26 |
sfan5 |
there's more that could be thrown away, for example the entire tools folder |
| 14:26 |
sfan5 |
but it doesn't really mattert |
| 14:26 |
sfan5 |
-t |
| 14:26 |
hecks |
curiously there's a copy of the B3D exporter in the tools folder |
| 14:27 |
hecks |
if it's outdated, then maybe it should be killed to avoid confusion |
| 14:59 |
|
specing_ joined #minetest-dev |
| 15:07 |
|
olliy joined #minetest-dev |
| 15:47 |
hecks |
hmmmmm i'm getting some crashes online |
| 15:52 |
hecks |
it's not armor, it's not mobs... |
| 15:52 |
|
Extex joined #minetest-dev |
| 16:03 |
MTDiscord |
<Sublayer plank> is it maybe tga images? |
| 16:05 |
MTDiscord |
<Jordach> TGA is an outdated format that is better served by PNG |
| 16:05 |
MTDiscord |
<Sublayer plank> mcl2 uses it |
| 16:05 |
MTDiscord |
<Jordach> and? |
| 16:05 |
MTDiscord |
<Jordach> nobody cares about mcl |
| 16:05 |
hecks |
we don't even officially support TGA |
| 16:05 |
hecks |
lua_api.txt only mentiones png |
| 16:05 |
MTDiscord |
<Jordach> also that |
| 16:05 |
MTDiscord |
<Sublayer plank> true lol |
| 16:05 |
hecks |
so this would be a case of relying on undocumented behavior... |
| 16:05 |
MTDiscord |
<Jordach> TGA was useful back in the day since PNG wasn't around |
| 16:06 |
MTDiscord |
<Jordach> but PNG supports the exact same things and is easier to write libraries |
| 16:06 |
hecks |
i'll gdb this particular problem because a lot of servers seem to crash |
| 16:06 |
hecks |
something is telling me it's not a file format but some obscure SceneNode behavior i didn't account for |
| 16:06 |
hecks |
CTF crashes instantly for example |
| 16:07 |
MTDiscord |
<Jordach> just take your time |
| 16:07 |
MTDiscord |
<Jordach> however: -216,514 |
| 16:07 |
MTDiscord |
<Jordach> nice |
| 16:08 |
hecks |
oh ok, i'm just getting a segfault in a completely unrelated place before i even log in |
| 16:08 |
hecks |
thanks gdb |
| 16:09 |
hecks |
yeah wtf, i can't debug like this |
| 16:09 |
hecks |
at /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/include/c++/bits/stl_tree.h:798 |
| 16:10 |
|
beanzilla joined #minetest-dev |
| 16:14 |
hecks |
can somebody with a less retarded debugger test this |
| 16:15 |
sfan5 |
>Reason: We aren't accepting new players right now. Please try again another day or contact us on the forums |
| 16:15 |
sfan5 |
I would |
| 16:16 |
hecks |
that's on ctf? |
| 16:16 |
sfan5 |
it's what ctf.rubenwardy.com:30001 tells me |
| 16:16 |
hecks |
try the "Nyanachism" server, it crashes too (after a few seconds rather than instantly) |
| 16:17 |
sfan5 |
tried a different ctf server and here https://0x0.st/-VFf.txt |
| 16:17 |
sfan5 |
as one might guess this is the case: m_spritenode = (irr::scene::IBillboardSceneNode *) 0x0 |
| 16:17 |
rubenwardy |
CTF uses sprite entities |
| 16:18 |
hecks |
i didn't touch these |
| 16:19 |
hecks |
but okay, this doesn't look hard to fix |
| 16:19 |
sfan5 |
_IRR_COMPILE_WITH_BILLBOARD_SCENENODE_ is missing |
| 16:19 |
hecks |
hm? oh |
| 16:19 |
hecks |
i may have swept it up while cleaning up the config |
| 16:20 |
hecks |
i'll commit a fix in a minute |
| 16:25 |
hecks |
wow wtf |
| 16:25 |
hecks |
irrlicht uses crlf... |
| 16:25 |
sfan5 |
it does yes... |
| 16:26 |
rubenwardy |
also svn and sourceforge |
| 16:29 |
|
hecks left #minetest-dev |
| 16:29 |
|
hecks joined #minetest-dev |
| 16:36 |
pgimeno |
please normalize those |
| 16:37 |
pgimeno |
https://stackoverflow.com/questions/15641259/how-to-normalize-working-tree-line-endings-in-git |
| 16:41 |
pgimeno |
a repo should always use LF as line ending internally for text files, and convert on checkout |
| 16:43 |
sfan5 |
does that generate a big commit that removes and readds each line? |
| 16:44 |
MTDiscord |
<Sublayer plank> yeah it would |
| 16:44 |
hecks |
i say defer the renormalization until we start absorbing the remains |
| 16:46 |
sfan5 |
yes |
| 16:49 |
|
tech_exorcist joined #minetest-dev |
| 16:50 |
|
tech_exorcist_ joined #minetest-dev |
| 17:06 |
|
tech_exorcist joined #minetest-dev |
| 18:35 |
|
Jordach joined #minetest-dev |
| 18:56 |
|
v-rob joined #minetest-dev |
| 19:03 |
|
v_rob joined #minetest-dev |
| 19:10 |
rubenwardy |
I wonder if it's worth doing a much much simpler main menu redesign, without waiting for a new UI framework |
| 19:11 |
rubenwardy |
there's multiple issues to solve with a redesign - the look and feels, and the fact that it doesn't promote games/customisation especially well |
| 19:11 |
hecks |
could be, there are new formspec features to take advantage of |
| 19:14 |
celeron55_ |
well why not |
| 19:14 |
hecks |
any design in mind or does that need doing too |
| 19:15 |
|
vrob joined #minetest-dev |
| 19:15 |
hecks |
actually the tech doesn't matter that much |
| 19:17 |
hecks |
a good layout should work both with forms and with anything that would come after |
| 19:17 |
|
appguru joined #minetest-dev |
| 19:18 |
hecks |
so: games and customization as the main focus, anything else? |
| 19:18 |
rubenwardy |
I had a mainmenu design based on celeron55's mockups. It would start with a game selection screen. From there, you can either select a game, install a game from CDB, open settings, or join a server. When selecting a game, it would take you to a game-specific menu with singleplayer/multiplayer/content/etc |
| 19:18 |
rubenwardy |
The problem I found was that people were confused about the game vs engine difference |
| 19:18 |
rubenwardy |
you could join a server using Games > Online or Games > Minetest Game > Online for example |
| 19:18 |
hecks |
i would propose something less drastic, a reorganization of the scheme we have |
| 19:19 |
hecks |
where the tabs of the main menu and the game list are merged into one |
| 19:19 |
hecks |
and there is a landing page |
| 19:20 |
hecks |
all represented by icons |
| 19:20 |
hecks |
the game list portion of it becomes scrollable once it cannot fit |
| 19:20 |
hecks |
keeping it horizontal would give you more space |
| 19:24 |
rubenwardy |
I'm not quite sure what you mean |
| 19:24 |
rubenwardy |
here's my mock ups (warning, ugly - consider them to be a wireframe rather than an actual example) https://github.com/minetest/minetest/issues/6733#issuecomment-621970748 |
| 19:24 |
rubenwardy |
but yeah - by "worth doing a much much simpler main menu redesign" I meant compared to this or the alternatives |
| 19:25 |
rubenwardy |
I think just showing a choose game dialog as the first thing would improve visibility |
| 19:27 |
hecks |
https://a.uguu.se/PGcElo0IVGMt_layout.png |
| 19:27 |
hecks |
where landing page contains: a grid of recently used or installed games, labeled links to other tabs, version info, other links like website |
| 19:28 |
rubenwardy |
hmm, I can see that working |
| 19:29 |
rubenwardy |
yeah that sounds good. I suppose the default game formspec would be the Start Game tab? |
| 19:29 |
hecks |
the game formspec has a default but a game can have a menu/form.lua to redefine it |
| 19:29 |
hecks |
yup, that would be it |
| 19:29 |
hecks |
BUT |
| 19:29 |
hecks |
i would also like to suggest servers finally providing a game ID string to the master server |
| 19:29 |
rubenwardy |
they already do |
| 19:29 |
rubenwardy |
but we don't display it |
| 19:29 |
hecks |
that's great actually |
| 19:30 |
rubenwardy |
In my redesign, I wanted the server list in the game-specific menus to only show servers matching that game |
| 19:30 |
rubenwardy |
it's problematic for Minetest Game |
| 19:30 |
rubenwardy |
as so many are heavily modded |
| 19:30 |
hecks |
this is exactly what I was about to suggest |
| 19:30 |
rubenwardy |
but it's nice for eg: Mineclone2 / NodeCore |
| 19:31 |
MTDiscord |
<Kimapr> i think there are 6 nodecore servers currently |
| 19:31 |
hecks |
a button that takes you to a filtered and customized server browser |
| 19:31 |
hecks |
and then separately that "full server list" button that shows you all |
| 19:32 |
rubenwardy |
would that button take you to the full server list tab with a filter applied? |
| 19:32 |
rubenwardy |
or would it replace the game tab's content? |
| 19:32 |
rubenwardy |
or a dialog? |
| 19:32 |
hecks |
it could be either really |
| 19:32 |
rubenwardy |
I think the former is the simplest in terms of UX, probably |
| 19:32 |
hecks |
it could just take you to the full list and apply a filter, and this would be easy to implement |
| 19:32 |
rubenwardy |
former=full list tab with filter |
| 19:32 |
hecks |
but it wouldn't be impossible to let the game handle it too |
| 19:33 |
hecks |
same thing for content installation, though there is a snag here |
| 19:33 |
hecks |
do mods yet have a way to specify which game they're meant for? |
| 19:34 |
rubenwardy |
not yet |
| 19:34 |
rubenwardy |
the ContentDB installer allows you to specify a base game |
| 19:34 |
hecks |
that is a bummer |
| 19:34 |
hecks |
well uh wait |
| 19:34 |
hecks |
so the CDB entries do have it? |
| 19:34 |
rubenwardy |
not yet |
| 19:34 |
rubenwardy |
it's planned |
| 19:34 |
hecks |
because that's the only important bit; you could have a similar thing for content installation that would take you to a filtered view of the content DB |
| 19:34 |
hecks |
from the game page |
| 19:35 |
rubenwardy |
this is what happens when installing something from CDB with the wrong base game: https://rwdy.uk/5fNO1.png |
| 19:35 |
rubenwardy |
yeah, I planned to add that too as it makes sense |
| 19:36 |
hecks |
also a somewhat tangential question |
| 19:36 |
hecks |
if an mt installation is already able to manage its content by downloading and deleting mod and texture packages |
| 19:37 |
hecks |
wouldn't it be nice to have helpers for creating or forking new mods and games? |
| 19:37 |
rubenwardy |
as in, a command to make a mod template? |
| 19:38 |
hecks |
yes, a button to do that from cdb |
| 19:38 |
hecks |
or well, the content menu or whatever |
| 19:38 |
rubenwardy |
perhaps |
| 19:38 |
rubenwardy |
however, it's not like we have a Java API which needs loads of bootstrap to build using gradle |
| 19:38 |
rubenwardy |
and boilerplate to integrate with the API |
| 19:38 |
hecks |
no, but i think the forking part would be convenient |
| 19:39 |
hecks |
to make a quick and dirty patch to a mod without soiling your usual install of it |
| 19:39 |
MTDiscord |
<Warr1024> Forking would best be done on github/gitlab though. It seems complicated to have CDB involved in that process... |
| 19:39 |
hecks |
i only mean in the local sense |
| 19:39 |
hecks |
but uh, i don't know where i'm going with this actually |
| 19:40 |
hecks |
only that mt could technically have a built in project manager for mod development i guess |
| 19:40 |
rubenwardy |
I'm not sure what that would do tbh |
| 19:40 |
MTDiscord |
<Warr1024> If players want to hack up their local copy of a mod ... it might be useful to have MT know the difference between an altered copy and an original, for purposes of updates. |
| 19:40 |
MTDiscord |
<Warr1024> Beyond that, adding too many developer tools is kind of dangerous scope creep for MT. |
| 19:41 |
|
v-rob joined #minetest-dev |
| 19:41 |
hecks |
back to this layout thing then |
| 19:45 |
hecks |
oh right actually |
| 19:45 |
hecks |
i think this can just be fullscreen now |
| 19:45 |
hecks |
and any logo can be inside the big panel rather than above it |
| 19:53 |
hecks |
behold https://a.uguu.se/lKcCBZw6lVyN_landingpage.png |
| 19:57 |
MTDiscord |
<Jonathon> looks decent actually |
| 19:57 |
rubenwardy |
moving the icon tabs to the bottom like this would give a lot more space for games: https://user-images.githubusercontent.com/2122943/83007914-47084f00-a00c-11ea-9fb0-ba0b0c2a5ceb.png |
| 19:57 |
rubenwardy |
but yeah, I like the idea of a rich landing page |
| 19:57 |
hecks |
it would but..... that's basically what we have now |
| 19:57 |
hecks |
and |
| 19:58 |
hecks |
the idea is to explode the "single player" tab into individual game icons |
| 19:58 |
MTDiscord |
<GreenXenith> having it so far out of the way feels both out of place and doesnt make it very easy to notice |
| 19:58 |
MTDiscord |
<Warr1024> I'd change "get more shit at content db" to "get more crap at content db" so that it can be used in an elementary school setting, but other than that, ship it! |
| 19:58 |
rubenwardy |
I'm referring just to the icon bar at the bottom there, not the window contents |
| 19:59 |
rubenwardy |
but yeah, you're right that it puts some distance which isn't idea |
| 19:59 |
MTDiscord |
<GreenXenith> The icon bar is what im referring to as well |
| 19:59 |
hecks |
well this kinda is similar except i placed it on the top, i guess bottom is fine |
| 19:59 |
rubenwardy |
I gathered, Green |
| 19:59 |
hecks |
there's little difference but uh i guess it gives the logo some breathing room |
| 20:00 |
MTDiscord |
<Warr1024> I'm a bit curious about how the icon bar would be ordered in the event someone has a buttload of games installed. MRU maybe? |
| 20:00 |
MTDiscord |
<GreenXenith> shouldnt the game have control over where stuff goes |
| 20:00 |
rubenwardy |
unfortunately not with this design. They'd control their own page at most |
| 20:00 |
rubenwardy |
maybe they'd hack the global layout if the code isn't sandboxed |
| 20:00 |
MTDiscord |
<Warr1024> I'm okay with opening up main menu control to games gradually. We don't want to make them responsible for it all right away either. As long as we're moving in the right direction. |
| 20:01 |
MTDiscord |
<GreenXenith> thats fair |
| 20:01 |
MTDiscord |
<GreenXenith> choose something and go with it |
| 20:01 |
MTDiscord |
<GreenXenith> get it made and merged |
| 20:01 |
hecks |
it's fine for a game to only control the contents of its panel |
| 20:01 |
MTDiscord |
<Warr1024> It'd be better to get something small and mergeable and start to build momentum quickly instead of designing something too good too soon. |
| 20:01 |
hecks |
it should not touch the main bar |
| 20:01 |
hecks |
oh and |
| 20:01 |
rubenwardy |
the top icons bar is likely to be the first version, as we don't have the ability to pin stuff to the edges yet |
| 20:01 |
hecks |
contrary to that example posted i'd give more prominence to the global server browser |
| 20:01 |
MTDiscord |
<GreenXenith> I was mostly referring to the title, since the title is property of the game |
| 20:01 |
MTDiscord |
<Warr1024> Frankly if you can just make MTG not bundled and have a sane way to get to Content and pick your first game, then I'm already pretty happy :-) |
| 20:03 |
sfan5 |
"the game formspec has a default but a game can have a menu/form.lua to redefine it" I suggest postposting this since the mainmenu code isn't sandboxed so we can't "just" do this |
| 20:03 |
sfan5 |
oh ruben already mentioned |
| 20:03 |
hecks |
perfection https://a.uguu.se/3J0OWkCaMVnd_final.png |
| 20:03 |
sfan5 |
a menu redesign would be much worth it even without this |
| 20:03 |
rubenwardy |
"_final" |
| 20:03 |
hecks |
=] |
| 20:03 |
hecks |
i don't see how this could be improved further honestly |
| 20:04 |
sfan5 |
lens flare |
| 20:04 |
MTDiscord |
<Warr1024> more comic sans |
| 20:04 |
rubenwardy |
we need more blue |
| 20:04 |
rubenwardy |
err |
| 20:04 |
rubenwardy |
blur |
| 20:04 |
rubenwardy |
but blue is good too |
| 20:04 |
MTDiscord |
<Warr1024> blur only the blue parts |
| 20:05 |
MTDiscord |
<GreenXenith> bluer? blure |
| 20:05 |
v-rob |
Why are there two settings buttons? |
| 20:05 |
v-rob |
Just in case you get lost? |
| 20:05 |
rubenwardy |
my design aesthetic is just rounded corners and blurs https://renewedtab.com/ |
| 20:05 |
sfan5 |
presumably one goes to the settings tab |
| 20:05 |
sfan5 |
the other to adv.settings as it says |
| 20:05 |
sfan5 |
I fear making advanced settings more prominent will cause users to mess up more |
| 20:06 |
rubenwardy |
I don't think duplicate links like that is necessary, people will see the settings icon |
| 20:06 |
v-rob |
the "idk something" button should cause their computer to blue screen if they're using windows |
| 20:06 |
v-rob |
just for fun |
| 20:07 |
rubenwardy |
duplicating links indicates that something is important, and settings aren't that important |
| 20:08 |
MTDiscord |
<Warr1024> Where are the singleplayer worlds on that layout? |
| 20:08 |
rubenwardy |
when you click a game |
| 20:08 |
MTDiscord |
<Warr1024> OIC, so that's a pre-game landing page |
| 20:08 |
rubenwardy |
which are the orange icons in the icon bar |
| 20:08 |
rubenwardy |
yeah |
| 20:08 |
MTDiscord |
<Warr1024> and that bottom left crafting-grid button is the "Go back to the home screen" button? |
| 20:09 |
rubenwardy |
yeah |
| 20:09 |
MTDiscord |
<Warr1024> LGTM |
| 20:10 |
MTDiscord |
<Warr1024> Presumably there's nothing at all that's strictly necessary to go in the home screen, since all the important shit is in the bottom bar already. So we could probably get something out there given this design pretty quickly, and let the bikeshedding over the exact content happen AFTER we merge the important parts. |
| 20:11 |
rubenwardy |
the home screen will at least show Featured Games from ContentDB, allowing us to no longer bundle MTG |
| 20:11 |
rubenwardy |
as of yesterday, ContentDB now supports featured packages |
| 20:11 |
MTDiscord |
<GreenXenith> ok so PR when |
| 20:11 |
hecks |
here you go you meme goblins https://a.uguu.se/Hfp3p6UN4Fsv_perfection.png |
| 20:11 |
rubenwardy |
oh noes |
| 20:11 |
MTDiscord |
<GreenXenith> now it just needs deep fry and warp |
| 20:12 |
hecks |
i do not use cancer effects enough to know where they all are. sorry |
| 20:12 |
Krock |
needs a picture of a surprised/shouting kid |
| 20:12 |
hecks |
no i know |
| 20:14 |
hecks |
https://a.uguu.se/xRkCf4j1Vf3y_gonewrong.png |
| 20:15 |
MTDiscord |
<Warr1024> "We all agreed on a design direction, but unfortunately the work itself was derailed by memes" |
| 20:17 |
hecks |
well, if people keep adding bad lighting PRs everything will inevitably turn into free-smiley-de |
| 20:21 |
MTDiscord |
<GreenXenith> https://cdn.discordapp.com/attachments/747163566800633906/868226357220479086/myeyestheyburn.png |
| 20:23 |
v-rob |
With graphics designers like hecks, Minetest is doomed. |
| 20:23 |
MTDiscord |
<Warr1024> always has been |
| 20:23 |
v-rob |
good poit |
| 20:24 |
MTDiscord |
<GreenXenith> oh I forgot the fisheye filter |
| 20:24 |
MTDiscord |
<GreenXenith> oh well |
| 20:24 |
hecks |
let's stop here before someone takes it seriously |
| 20:25 |
MTDiscord |
<GreenXenith> lol |
| 20:25 |
hecks |
with this community, you never know |
| 20:26 |
MTDiscord |
<Sublayer plank> oh, that main menu concept was supposed to be a joke? |
| 20:27 |
hecks |
it is too late, here comes the PR with 20 upvotes |
| 20:31 |
v-rob |
Can we use RTTI in Minetest? |
| 20:31 |
v-rob |
I know Irrlicht can't |
| 20:32 |
rubenwardy |
https://github.com/minetest/contentdb/issues/321 |
| 20:39 |
sfan5 |
v-rob: yes |
| 20:39 |
v-rob |
cool |
| 20:40 |
sfan5 |
though perhaps the cargoculted android flags have -fno-rtti |
| 21:00 |
sfan5 |
reminder #11287 |
| 21:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/11287 -- Take advantage of IrrlichtMt target by JosiahWI |
| 21:01 |
sfan5 |
I think we'd do well tagging PRs with "Action / change needed" more consistently when unadressed review comments are left |
| 21:01 |
v-rob |
I wish I could review, but I know nothing of CMake |
| 21:02 |
sfan5 |
the cmake part isn't so important, more that you can still get mt + irrlichtmt running together in your setup whichever way you currently do it |
| 21:05 |
|
longerstaff13 joined #minetest-dev |
| 21:15 |
|
Evergreen joined #minetest-dev |
| 21:16 |
|
Jordach5 joined #minetest-dev |
| 21:35 |
|
appguru joined #minetest-dev |
| 22:11 |
sfan5 |
random reminder that debian has still not packaged Minetest 5.4.0 or 5.4.1 |
| 22:11 |
sfan5 |
(and with that ubuntu too) |
| 22:12 |
Pexin |
they expect you to use snap, right? |
| 22:12 |
sfan5 |
ubuntu maybe but not debian |
| 22:24 |
rubenwardy |
20.04 was before 5.4.0, so that's not surprising |
| 22:25 |
rubenwardy |
20.10 or 21.04 should have it though? |
| 22:25 |
sfan5 |
"not packaged" = not in repos even if you run unstable |
| 22:26 |
sfan5 |
I just read that Debian plans or Debian 11 next month, it will not have 5.4 |
| 22:26 |
sfan5 |
for* |
| 22:27 |
sfan5 |
and neither does 20.10 or 21.04 |
| 22:27 |
|
olliy joined #minetest-dev |
| 22:32 |
sfan5 |
We should recommend against installing distro versions |
| 22:33 |
sfan5 |
in fact I'm gonna PR that to the website repo tomorrow |
| 22:55 |
MTDiscord |
<josiah_wi> Who is the maintainer of the Debian Minetest package? Can we contact them? |
| 22:57 |
|
olliy joined #minetest-dev |
| 23:23 |
|
entuland joined #minetest-dev |
| 23:23 |
|
pgimeno joined #minetest-dev |
| 23:54 |
|
Alias2 joined #minetest-dev |
