| Time |
Nick |
Message |
| 00:07 |
|
specing_ joined #minetest-dev |
| 00:20 |
|
specing_ joined #minetest-dev |
| 02:11 |
|
Extex joined #minetest-dev |
| 02:27 |
|
celeron55 joined #minetest-dev |
| 03:44 |
|
Kimapr joined #minetest-dev |
| 04:41 |
|
AntumDeluge joined #minetest-dev |
| 06:36 |
|
Kimapr joined #minetest-dev |
| 07:05 |
|
nyje joined #minetest-dev |
| 07:19 |
|
nrz joined #minetest-dev |
| 07:19 |
|
nrz joined #minetest-dev |
| 07:20 |
|
nrz joined #minetest-dev |
| 07:21 |
|
nrz joined #minetest-dev |
| 07:22 |
|
nrz joined #minetest-dev |
| 07:23 |
|
nrz joined #minetest-dev |
| 07:24 |
|
nrz joined #minetest-dev |
| 07:26 |
|
nrz joined #minetest-dev |
| 07:29 |
|
nrz joined #minetest-dev |
| 07:34 |
|
nrz joined #minetest-dev |
| 07:50 |
|
nrz joined #minetest-dev |
| 07:52 |
nrz |
hello everyone ? i'm glad to see improvements on the irrlicht side. I think we have more to do, i really want to move generic MT things inside it ? |
| 07:53 |
|
Kimapr5 joined #minetest-dev |
| 07:56 |
|
calcul0n__ joined #minetest-dev |
| 08:02 |
|
Kimapr joined #minetest-dev |
| 08:05 |
|
nyje left #minetest-dev |
| 08:10 |
|
tech_exorcist joined #minetest-dev |
| 08:19 |
rubenwardy |
We should be removing from it, not adding to it |
| 08:19 |
rubenwardy |
Pure irrlicht stuff may make sense, but not generic Mt stuff |
| 08:20 |
nrz |
remove what from irrlicht ? irrlicht rendering itself ? |
| 08:20 |
nrz |
you clear irrlicht to absorb it in MT codebase ? |
| 08:20 |
nrz |
(that can be a solution) |
| 08:21 |
nrz |
moving stuff to irrlicht properly has an advantage, it may show us a pattern which may permit to remove our crap client irrlicht stuff and have generics to replace it with other engine if needed (but i think it's not required as now we have our fork) |
| 08:49 |
|
Kimapr joined #minetest-dev |
| 08:50 |
sfan5 |
reminder #11287 |
| 08:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/11287 -- Take advantage of IrrlichtMt target by JosiahWI |
| 08:55 |
celeron55 |
it works, right? |
| 08:57 |
celeron55 |
i did look at the code at some point and it was fine, if you're looking for a merge go-ahead i can give it |
| 08:57 |
nrz |
sfan5: german commit in the PR :p |
| 08:58 |
nrz |
approved |
| 08:59 |
celeron55 |
this could have a bit more guidance for installing irrlichtmt in the error messages |
| 09:00 |
sfan5 |
it works yes |
| 09:00 |
sfan5 |
I just don't want anyone surprised/unaware that they can't use point to irrmt via IRRLICHT_INCLUDE_DIR + IRRLICHT_LIBRARY anymore |
| 09:00 |
sfan5 |
s/use point/point/ |
| 09:01 |
celeron55 |
the test would be, pull minetest into somewhere, try to build it, it should tell you you can just pull irrlichtmt into lib/ and try building again |
| 09:01 |
celeron55 |
and you shouldn't have to go look for a guide to do that |
| 09:01 |
sfan5 |
that or the README should have a very prominent section (we can expect users to read that right?) |
| 09:01 |
celeron55 |
i think we can't |
| 09:02 |
celeron55 |
well |
| 09:02 |
celeron55 |
it could tell the user to go look in README |
| 09:04 |
celeron55 |
there's no reason to not make the build process as self-explanatory as possible |
| 09:04 |
sfan5 |
true |
| 09:04 |
celeron55 |
of course this can be a separate pull request but i'm not the one who made me look at the cmake error messages 8) |
| 09:22 |
|
Fixer joined #minetest-dev |
| 09:35 |
|
calcul0n_ joined #minetest-dev |
| 09:59 |
|
Alias joined #minetest-dev |
| 10:27 |
freshreplicant[m |
<MTDiscord "<Warr1024> I think MTG would not"> Bit late to this, but this idea makes a lot of sense. As much as a subset of creators are ready to see MTG go the way of the dodo, most players don't seem to be interested in that and aren't heeding it. If MTG must exist as a non-default option, then why not a maintained, more coherent one? Alternatively, if you can somehow bring the modders of the MTG ecosystem along with you, maybe |
| 10:27 |
freshreplicant[m |
it's time to give MTG the Caesar treatment ("Et tu, El Ceejo?") and invest in some semi-official capacity into another project that can act as a showcase for the engine. |
| 10:45 |
|
entuland joined #minetest-dev |
| 10:55 |
specing |
MTG sucks as a showcase |
| 10:58 |
|
longerstaff13 joined #minetest-dev |
| 11:30 |
|
behalebabo joined #minetest-dev |
| 12:19 |
|
specing_ joined #minetest-dev |
| 13:03 |
|
x2048 joined #minetest-dev |
| 13:19 |
|
x2048 left #minetest-dev |
| 14:25 |
freshreplicant[m |
It certainly does in its present form. Which is why I agreed with Warr's suggestion of creating an overhauled version (not necessarily as a showcase, but at least so MTG isn't a detriment to MT) or axing it and going for something that is actually a good showcase. |
| 14:29 |
|
hecks joined #minetest-dev |
| 14:31 |
hecks |
nrz: the plan is to absorb what remains of irrlicht after deleting enough |
| 14:32 |
hecks |
almost nothing in irrlicht is well designed, it's a liability |
| 14:32 |
hecks |
in the long run even the ISceneNode system may end up being removed |
| 14:36 |
hecks |
rather than abstract things away to make an engine switch easier, we should not be using an engine, we are making one |
| 14:38 |
|
Fixer joined #minetest-dev |
| 14:42 |
specing |
Maybe you should |
| 14:42 |
specing |
switch to a better engine |
| 14:44 |
MTDiscord |
<Sublayer plank> in that case, what would that engine be? |
| 14:52 |
hecks |
the minetest engine, of course =]] |
| 15:01 |
specing |
hecks: nah, I was told that Torque3D is the best, but has two problems: (1) can't run on potato (2) upstream has gone a bit proprietary |
| 15:01 |
hecks |
torque is garbage :o |
| 15:02 |
specing |
hecks: there's still other maintained ones to look at, like unvanquished's engine? |
| 15:02 |
hecks |
what do we need an engine for |
| 15:02 |
specing |
But I must admin that I'm not a first person game dev, so idk about these engines |
| 15:02 |
hecks |
here's the deal |
| 15:02 |
specing |
hecks: sharing of development burden |
| 15:02 |
hecks |
we already implement a lot of the things an engine usually does |
| 15:03 |
hecks |
we don't use irrlicht for most things |
| 15:03 |
hecks |
hence i was able to delete half of that thing without losing any features |
| 15:03 |
hecks |
we use irrlicht for: rendering, gui, i/o |
| 15:04 |
hecks |
and a lot of the problems that irrlicht has been causing us were in part due to the fact that it targets so many platforms |
| 15:04 |
hecks |
minetest's client environment is special in a lot of ways, we have a lot of domain specific knowledge that we can use to optimize things |
| 15:04 |
MTDiscord |
<Sublayer plank> doesn't minetest already target all the platforms irrlicht targets? windows, macos, linux, freebsd, android... |
| 15:04 |
hecks |
that a general purpose game engine can not do |
| 15:05 |
hecks |
I'm not talking about that |
| 15:05 |
MTDiscord |
<Sublayer plank> oh |
| 15:05 |
hecks |
I'm talking about irrlicht having a goddamn software renderer, D3D path, etc... not being GL only was tying our hands a lot |
| 15:05 |
hecks |
and a lot of the stupid things irrlicht does are a consequence of this too |
| 15:06 |
hecks |
minetest is an engine, it does not make sense to overlay it on top of another engine |
| 15:07 |
hecks |
c55 was just messing around in irrlicht one day and made it, and that's fine |
| 15:08 |
hecks |
it's an acceptable concession if you're working mostly alone |
| 15:08 |
hecks |
and don't know opengl |
| 15:10 |
hecks |
but minetest has grown into this monster of a platform since and there's now enough hands on the deck to do it right |
| 15:10 |
hecks |
meaning using sdl, opengl and various other libs rather than a general purpose game engine |
| 15:11 |
hecks |
among other things, mobile performance is crap because irrlicht is trying to use gles2 as if it were a software renderer |
| 15:13 |
celeron55 |
why is this still argued about |
| 15:13 |
hecks |
:o what? |
| 15:13 |
celeron55 |
hecks should be writing code, not responding to the same question over and over again |
| 15:13 |
hecks |
:DDDDD |
| 15:13 |
hecks |
right |
| 15:13 |
hecks |
back to butchering ivideodriver it is |
| 15:14 |
hecks |
celeron55 take a look at #11490 |
| 15:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/11490 -- Add engine design guidelines by hecktest |
| 15:14 |
celeron55 |
the only reason irrlicht wasn't gotten rid of is there wasn't enough expertise and time to do it |
| 15:14 |
celeron55 |
hecks seems to have both, and it would be a total waste not to use it |
| 15:15 |
hecks |
my time isn't infinite but i straight up need to do this |
| 15:16 |
celeron55 |
even if hecks disappeared after this, MT still would be in a better position: we'd have outdated opengl code, but unlike now it would be minimized inside the project, not maximized inside irrlicht, i.e. there would be a chance someone else could update it |
| 15:17 |
celeron55 |
irrlicht is dead, there's no question about that |
| 15:17 |
celeron55 |
and almost all 3d engine projects die at some point |
| 15:17 |
hecks |
if i disappeared *after* this you'd at least have: a smaller binary, and a somewhat good gl2 base |
| 15:19 |
hecks |
i'm not going to willingly disappear though because this is the upstream for my crappy MMO and i'm stuck with it |
| 15:21 |
hecks |
i give myself time until about october to have the new renderer up and running |
| 15:22 |
sfan5 |
I wonder if we want to delay 5.5 until it's done or hotfix (or disable) the shadow stuff so we can safely put out what is currently in master |
| 15:24 |
hecks |
i'm basically stuck in engine work so i'm a little indifferent, mibi is not live yet |
| 15:24 |
hecks |
but i'll be rebasing shadows on top of the new renderer at one point so maybe knowing that can help |
| 15:40 |
specing |
hecks | torque is garbage :o |
| 15:40 |
specing |
hecks: why? |
| 15:42 |
celeron55 |
why wouldn't it be, most of them are |
| 15:42 |
celeron55 |
because someone told you so? |
| 15:42 |
celeron55 |
that's the thickest nonsense i've heard today |
| 15:45 |
celeron55 |
it might be good for *something*, but being good for minetest is an impossible goal for a generic 3d engine |
| 15:46 |
celeron55 |
if i was working for microsoft with the task of slowing down MT development, i would do something like try to get MT to try to switch to another 3d engine |
| 15:50 |
specing |
right |
| 15:50 |
|
Extex joined #minetest-dev |
| 15:50 |
specing |
Duion of Uebergame told me that's its the best |
| 15:52 |
hecks |
i'll admit i straight up don't remember why i hate torque but i did install it once and hated it, even more so than irrlicht |
| 15:52 |
hecks |
this was quite a long time ago |
| 15:53 |
MTDiscord |
<Warr1024> If feels weird hearing people say that an engine should switch to a different engine |
| 15:53 |
hecks |
but basically none of these ancient engines are good, people have learned how to design engines since |
| 15:53 |
hecks |
and yes |
| 15:54 |
hecks |
the best engines are either proprietary sadly, or in-house things you've never heard of |
| 15:54 |
hecks |
my work on minetest will basically be a port of the latter |
| 15:56 |
MTDiscord |
<Benrob0329> Torque always looked interesting but like it needed a bit more work to modernize |
| 15:56 |
MTDiscord |
<Benrob0329> also, custom scripting language |
| 15:57 |
hecks |
i wrote a 3d engine as a backup plan in case minetest ends up being unsalvageable, a friend was writing his in the meantime and we ended up sharing notes a lot |
| 16:05 |
hecks |
anyway what i can tell you is that most available game engines are lagging behind in good practices and features, and the free software ones even more so |
| 16:17 |
hecks |
it would also be immensely stupid for a game engine to use an engine =] |
| 16:19 |
MTDiscord |
<Warr1024> I think Unity should consider switching to the Minetest engine XD |
| 16:23 |
MTDiscord |
<Sublayer plank> yeah! why shouldn't they? |
| 16:58 |
sfan5 |
merging #11128, #10876, #11287, #11478 in 10m |
| 16:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/11128 -- Improve documentation of tools by Wuzzy2 |
| 16:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/10876 -- ContentDB: Add reason to downloads by rubenwardy |
| 16:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/11287 -- Take advantage of IrrlichtMt target by JosiahWI |
| 16:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/11478 -- Add bold, italic and monospace font styling for HUD text elements by sfan5 |
| 17:08 |
|
kilbith joined #minetest-dev |
| 17:08 |
Krock |
⏰ |
| 17:09 |
kilbith |
sfan5: https://irc.minetest.net/minetest-dev/2021-07-26#i_5851738 |
| 17:10 |
sfan5 |
yes I know, will fix eventually |
| 17:10 |
Krock |
there's more somewhere in the sha code |
| 17:10 |
sfan5 |
yea I was planning to fix all warnings we currently have at once someday |
| 17:17 |
|
hecks joined #minetest-dev |
| 17:41 |
sfan5 |
hmm I think the buildbot no longer installs irrlicht dlls this way |
| 18:39 |
sfan5 |
pushing http://sprunge.us/PuhN2v?diff in a few min |
| 18:41 |
|
x2048 joined #minetest-dev |
| 18:43 |
|
x2048 joined #minetest-dev |
| 19:32 |
|
v-rob joined #minetest-dev |
| 19:32 |
v-rob |
Hey, can I have an opinion? On the C++ side, how should the new GUI store styling information? StyleSpec stores it as strings and then parses the string in a context-dependent way. However, the new GUI isn't string-based, but styling still could be context-dependent (especially if custom Lua elements ever were to exist) |
| 19:36 |
v-rob |
I can't just store JSON from the server verbatim if a real (SS)CSM Lua API is to exist for the GUI later on |
| 19:36 |
sfan5 |
what does "context-dependent" mean? just different enums? |
| 19:38 |
v-rob |
That is, it's pretty hard to know for certain what datatype a certain styling property is without limitations (especially custom Lua elements might interpret things however they like) |
| 19:38 |
v-rob |
Future-proofing is hard |
| 19:38 |
sfan5 |
don't elements have a persistent state they can use to store the style in parsed form? |
| 19:39 |
sfan5 |
then you'd keep the raw data around but only for purposes of element creation |
| 19:44 |
v-rob |
I can. It does kind of dash my hopes of keeping formspec element compatibility from contaminating the new elements without having to inherit a formspec element class from each new element class. |
| 19:51 |
v-rob |
Honestly, I want the new GUI to drop all formspec default styling (like the gradiented button panes) and give a blank slate that can be styled as wanted without having to unstyle everything first. |
| 19:55 |
celeron55 |
i think strings are a perfectly valid in-memory format for values, as long as the enclosing data structure is parsed into a proper container |
| 19:55 |
celeron55 |
if the string can contain a large parseable data structure, then it becomes a bit iffy |
| 19:56 |
celeron55 |
actually, then storing the parsed state of a json parser could make sense |
| 19:56 |
celeron55 |
if the required format for the data isn't known before use |
| 19:59 |
v-rob |
Then again, there's always performance to worry about, seeing as this would be read every frame |
| 19:59 |
v-rob |
I don't know if JSON state would be slow |
| 20:00 |
celeron55 |
depends on the json parser |
| 20:00 |
celeron55 |
the one we link to probably isn't the best |
| 20:00 |
celeron55 |
it just has the sexiest name |
| 20:01 |
celeron55 |
but anyway, if it's possible with reasonable effort, of course parse as much as possible into a fast data structure |
| 20:02 |
celeron55 |
can you think of an example where a simple one-level key-value store won't work for styling? |
| 20:05 |
celeron55 |
if i was implementing this i'd just do std::unordered_map<std::string, std::string> and hope for the best, but i'm lazy |
| 20:06 |
celeron55 |
especially if "custom lua elements" are going to be a thing |
| 20:06 |
v-rob |
I'm probably looking from this from the wrong angle. Perhaps a better angle than "how to store style info" is really "how to have formspec compat code without it making its way into the new elements without a whole new set of elements dedicated to formspecs" since that's how I got into thinking about styling. |
| 20:07 |
v-rob |
It's a problem I've never resolved from the start, and I suspect it's contaminated a lot of my designing |
| 20:07 |
celeron55 |
i guess you'll just have to have a bunch of compatibility code that convers the old stuff into new stuff |
| 20:07 |
celeron55 |
and have the new elements able to act like old ones given the right styles and parameters |
| 20:07 |
celeron55 |
that the compat code will apply to them |
| 20:08 |
celeron55 |
converts* |
| 20:08 |
v-rob |
I was hoping for a solution that keeps the formspec code entirely separate. But I guess that might not be very possible. |
| 20:09 |
celeron55 |
well that keeps it separate |
| 20:09 |
celeron55 |
it can literally be a conversion function that takes in a formspec element and puts out the new kind of element |
| 20:09 |
celeron55 |
in a different file, if you get anxiety otherwise |
| 20:10 |
celeron55 |
as long as the new elements can act like old ones given they are supplied certain parameters |
| 20:10 |
celeron55 |
and i don't mean a parameter like "old_style=true" |
| 20:11 |
celeron55 |
i mean a parameter like color=blue, if the old default was blue |
| 20:12 |
celeron55 |
this surely makes sense to at least someone here? |
| 20:13 |
v-rob |
No, I fully understand you, but I just didn't want things like "gradients=true" having to sit in the new elements for all time because of formspecs. Oh well, I guess there's not much for it. |
| 20:14 |
celeron55 |
well |
| 20:14 |
celeron55 |
the way around that is to change the default style and not support the old default style |
| 20:14 |
celeron55 |
i certainly am open to that |
| 20:14 |
v-rob |
Hmm |
| 20:15 |
v-rob |
I don't think anyone would miss the dark gray gradients :P |
| 20:15 |
celeron55 |
as long as the default style is consistent and somewhat similar to before it won't matter a lot what it is |
| 20:15 |
celeron55 |
pretty much any light on dark style could work |
| 20:16 |
celeron55 |
i'm sure even hecks would be fine with that |
| 20:16 |
hecks |
what's up |
| 20:16 |
celeron55 |
:D |
| 20:16 |
celeron55 |
there he is *points* |
| 20:17 |
hecks |
v-rob wants to break my forms? :DDD |
| 20:17 |
v-rob |
Yes, it's my secret plan |
| 20:17 |
hecks |
how about we don't overhaul gui without sscsm... |
| 20:17 |
hecks |
but ok, what were you guys talking about |
| 20:19 |
v-rob |
It was just a discussion on whether default formspec styling could be changed somewhat so as to not have to support the old styling in new GUI code. Like, getting rid of gradients on buttons. |
| 20:20 |
v-rob |
And, if you're fine with that, probably everybody would be |
| 20:20 |
hecks |
*default* does not concern me |
| 20:20 |
hecks |
however you might be approaching formspec emulation from the wrong angle |
| 20:21 |
v-rob |
What angle would you approach it from? |
| 20:21 |
hecks |
reimplemented as user elements entirely |
| 20:22 |
v-rob |
As in, inheriting a new class for each formspec element? |
| 20:22 |
hecks |
yup |
| 20:22 |
hecks |
of course entirely in lua |
| 20:22 |
|
Extex joined #minetest-dev |
| 20:23 |
v-rob |
Why in Lua specifically? |
| 20:24 |
hecks |
is it not the whole point of the new system? |
| 20:25 |
v-rob |
Well, I'd love absolutely everything to be in Lua, but it's not possible without security issues. So, most of the GUI has to be in C++, but with as many openings for Lua as possible |
| 20:26 |
hecks |
pardon me that i'm not actually that certain what the problems with our gui are |
| 20:27 |
hecks |
besides hud and forms not using the same api |
| 20:27 |
hecks |
as long as we do not have server sent code, we'll run into the same problems |
| 20:28 |
hecks |
people seem to go on a lot about how formspecs suck (i'm in the minority that doesn't mind them much) |
| 20:28 |
hecks |
but has anyone actually written down a list of why they suck? |
| 20:28 |
sfan5 |
1. awful text format |
| 20:28 |
v-rob |
2. awful event system |
| 20:29 |
v-rob |
3. non-dynamic in the least |
| 20:29 |
specing |
> hecks | pardon me that i'm not actually that certain what the problems with our gui ara |
| 20:29 |
specing |
It sucks |
| 20:29 |
v-rob |
4. inconsistent in absolutely everything except in being horrible |
| 20:29 |
specing |
Check out SpringRTS's lua GUI |
| 20:29 |
hecks |
well the low dynamicity of forms is a limitation of not being able to execute server sent code |
| 20:29 |
sfan5 |
hey at least the coordinates are no longer inconsistent ;) |
| 20:29 |
specing |
in SpringRTS, the entire goddamn GUI is in lua |
| 20:30 |
v-rob |
5. the backend is Irrlicht. Need more be said? |
| 20:30 |
hecks |
=] |
| 20:30 |
hecks |
oh right, you'd do me a big favor by using low level rendering to do your gui as opposed to irr gui features |
| 20:31 |
hecks |
text format: at least it's compact, it works as a transmission format |
| 20:31 |
v-rob |
JSON's much better, however, as an almost 1:1 translation can be done from Lua tables |
| 20:31 |
hecks |
awful event system: i'll agree this was a little wonky to wrap but it ended up working |
| 20:32 |
hecks |
actually why would we ever use json if we have a perfectly good lua parser and vm... |
| 20:32 |
v-rob |
Because no one's making SSCSM. |
| 20:32 |
specing |
I wish that whatever the new GUI system becomes, that it stays interactable in CSMs. Right now it is pretty simple to interact with CSMs |
| 20:32 |
specing |
v-rob: wrong |
| 20:32 |
specing |
luk3yx has a few |
| 20:32 |
hecks |
i mean, as a transmission format lua works even without sscsm, making a barebones sandbox is not that hard |
| 20:33 |
hecks |
sscsm is hard because of the apis you have to expose |
| 20:33 |
v-rob |
I mean, no one's implementing SSCSM in the engine |
| 20:33 |
hecks |
as a serialization format, it doesn't really matter, although |
| 20:33 |
hecks |
ideally forms should not be transmitted as text in the first place |
| 20:33 |
hecks |
same with texture modifiers |
| 20:34 |
hecks |
anyway a lot of the problems with forms seem more like api problems than a problem with the concept itself |
| 20:34 |
v-rob |
Yeah, mostly the new GUI is a) replacing Irrlicht's GUI and b) replacing the API, which amounts to basically everything |
| 20:35 |
hecks |
i wrapped them in an object oriented toolkit, i can even make my own elements from what's available and have clients sharing a form |
| 20:35 |
celeron55 |
the thing about SSCSM lua gui is, it doesn't need any security sensitive apis to be exposed from the engine |
| 20:35 |
sfan5 |
hecks: it's a bit annoying to have a serialization format that can trivially enter an infinite loop |
| 20:35 |
celeron55 |
literally a 2d drawing api and an input api |
| 20:35 |
hecks |
=] disallow loops |
| 20:35 |
sfan5 |
how? |
| 20:36 |
hecks |
yeah i get it |
| 20:36 |
celeron55 |
i think it's doable, even right now, if someone wants to |
| 20:36 |
v-rob |
Sure, a drawing and events API is possible. I've already done it |
| 20:36 |
v-rob |
(closed for a few reasons, however) |
| 20:37 |
hecks |
anyway for forms it would be smart to deconstruct what they are |
| 20:37 |
v-rob |
The security issues really lie in things like a SSCSM being able to overwrite the pause menu or something |
| 20:37 |
hecks |
forms consist of a gui markup language and response events |
| 20:37 |
hecks |
as long as there is no server sent code being executed, i fail to see issues with the concept by itself |
| 20:38 |
hecks |
other than it requiring programming skill to work with because it's pretty low level |
| 20:38 |
|
behalebabo joined #minetest-dev |
| 20:38 |
celeron55 |
v-rob: is overwriting the pause menu actually a security issue? |
| 20:38 |
hecks |
not if there's a panic button to disconnect from the server |
| 20:38 |
v-rob |
Some users don't know what alt-f4 is |
| 20:39 |
celeron55 |
well, i can think of some server literally displaying the main menu, and a user typing the password of another server there |
| 20:39 |
celeron55 |
a bit iffy |
| 20:39 |
hecks |
now we're talking... |
| 20:39 |
hecks |
how about a formspec mimicking the phone's interface... okay i'll stop |
| 20:39 |
celeron55 |
but i'm sure web browsers have lots of experience on something like this |
| 20:40 |
hecks |
this was an attack i heard of recently, with a fake address bar |
| 20:40 |
celeron55 |
well actually, i think displaying the main menu is ALREADY possible |
| 20:40 |
v-rob |
The new web browser: Minetest Explorer |
| 20:40 |
celeron55 |
and displaying a pause menu also is |
| 20:40 |
v-rob |
Well, not with clouds in the background |
| 20:40 |
celeron55 |
sure is |
| 20:40 |
hecks |
well, shit |
| 20:40 |
celeron55 |
just point the player to clouds |
| 20:40 |
hecks |
not a lot of people would notice |
| 20:41 |
celeron55 |
so, we already have this security issue |
| 20:41 |
celeron55 |
it's not a new issue for sscsm gui |
| 20:41 |
hecks |
time to redact the logs :DD |
| 20:41 |
celeron55 |
:D |
| 20:42 |
celeron55 |
fug :DDDD as we say in finland |
| 20:42 |
hecks |
ebin |
| 20:42 |
hecks |
well with sscsm you basically don't have to care what the communication format and api are |
| 20:43 |
hecks |
it's best realized in a low level way |
| 20:43 |
v-rob |
Games can't bind the Esc key (yet), so that exploit isn't perfect |
| 20:43 |
celeron55 |
well all this can be solved by including something in the engine pause and main menus that games can't easily mimick |
| 20:44 |
hecks |
well this esc thing was actually an annoyance for me... but i found a way to deal with it |
| 20:45 |
hecks |
the problem was "what if the player just closes this form" https://a.uguu.se/4kNAx2Ndorsp_close.png |
| 20:46 |
v-rob |
Just bind the "exit" event and reshow it |
| 20:46 |
hecks |
the solution ended up being that you can close it and look around and use the esc menu; it'll just be reopened when you press any button |
| 20:46 |
hecks |
that was a bit annoying because you couldn't leave the server if i did that |
| 20:46 |
rubenwardy |
[20:36] <+sfan5> what does "context-dependent" mean? just different enums? |
| 20:46 |
hecks |
well you could |
| 20:46 |
hecks |
you'd just have to spam esc until you managed to get the pause menu open, and that just didn't feel right |
| 20:46 |
v-rob |
True dat |
| 20:46 |
rubenwardy |
It's like settings - the key is parsed by the code in different ways |
| 20:46 |
hecks |
oh but thanks, i just realized a bug |
| 20:46 |
hecks |
i need to disable chat in this mode... |
| 20:47 |
hecks |
not like anyone can *hear* your yet-nameless character talking in their instance in the corner of the map, but still |
| 20:48 |
rubenwardy |
Honestly, formspec compatibility should just be done by keeping the old formspec code |
| 20:48 |
v-rob |
But then we're stuck with Irrlicht's GUI forever |
| 20:49 |
hecks |
why can't forms be rebased on top of the new gui? |
| 20:49 |
hecks |
at least rendering wise |
| 20:49 |
hecks |
it's not like we're allowed to lose any functionality |
| 20:50 |
v-rob |
Full circle: because I don't want current formspec styling to invade the new code |
| 20:50 |
v-rob |
I don't want a "gradient=true" styling option, for instance |
| 20:50 |
hecks |
so yeah, at the very least, do that subclass thing except forget the lua bit |
| 20:50 |
hecks |
it seems solvable with basic OOP |
| 20:51 |
hecks |
FormElement : public MtGuiElement |
| 20:51 |
hecks |
FormButton : public FormElement |
| 20:51 |
hecks |
etc |
| 20:51 |
rubenwardy |
Or you can translate formspecs to the new GUI |
| 20:51 |
rubenwardy |
So parse them and emit new GUI elements |
| 20:52 |
hecks |
that's basically the same thing |
| 20:52 |
rubenwardy |
You don't need to support border (=gradient) and such |
| 20:52 |
celeron55 |
i think v-rob should forget compatibility at this point and just design a good extendable system |
| 20:52 |
v-rob |
Sounds like a plan |
| 20:53 |
celeron55 |
then it should naturally be extendable to support the old stuff |
| 20:53 |
hecks |
the emulator can be figured out later |
| 20:53 |
celeron55 |
if it's extendable enough |
| 20:53 |
rubenwardy |
However, bear in mind that it will be hard to completely and reliably reproduce formspecs if rewriting the code |
| 20:53 |
celeron55 |
it doesn't matter, we're known to break stuff randomly |
| 20:53 |
v-rob |
Who said formspecs were reliable in the first place? |
| 20:53 |
hecks |
the code doesn't need to know anything about form specific options, it just needs to pass the duck test |
| 20:53 |
hecks |
even if you have to emulate one element using many |
| 20:53 |
celeron55 |
...i mean, it's going to be close enough |
| 20:53 |
hecks |
perhaps that's the missing hint |
| 20:53 |
rubenwardy |
So I'd suggest keeping the old code whilst deprecating formspecs, and then using a transpiler that isn't likely to give the exact same results |
| 20:54 |
v-rob |
Well, the old code won't go anywhere for a long time |
| 20:54 |
hecks |
sure, just prepare for a thousand edge cases from me |
| 20:54 |
v-rob |
You forget -- it's my secret plan to break your formspecs. Bwa ha ha! |
| 20:55 |
v-rob |
And, of everyone here, I think I know the formspec code the best |
| 20:55 |
hecks |
it's not like my gui system is very aware of forms, it's an implementation detail |
| 20:55 |
hecks |
i'll just hawk you for features until i can port everything |
| 20:56 |
v-rob |
I've sifted through nearly every line of the 4771-line guiFormSpecMenu.cpp |
| 20:56 |
hecks |
4771... |
| 20:56 |
v-rob |
It's waaaaaaay too big |
| 20:56 |
hecks |
still smaller than irrlicht's GL drivers |
| 20:56 |
v-rob |
We have a 1000 line max, but no one's gonna split up GUIFormSpecMenu |
| 20:57 |
hecks |
did you know that irrlicht just carries an enum and a string list of all the extensions in existence for no apparent reason... |
| 20:57 |
hecks |
including SUN extensions |
| 20:57 |
v-rob |
Sun, of all thing? Wow |
| 20:57 |
hecks |
SUN_multi_draw_elements or something like that |
| 20:57 |
hecks |
plus NV and ATI versions of everything side by side with the ARB version |
| 20:58 |
hecks |
but the real question is |
| 20:58 |
hecks |
who queries GL extension presence so often that they need enum performance? |
| 20:58 |
v-rob |
Once the new GUI is complete, I reserve the right to tear out GUIFormSpecMenu and all of its friends mercilessly. I think that's my privilege |
| 20:58 |
v-rob |
:D |
| 20:58 |
hecks |
what you're basically not allowed to do is change the coordinate system |
| 20:59 |
hecks |
though it would be best if the user could actually specify the units (wow!) |
| 21:00 |
hecks |
whether they want to treat the screen as an arrangement of tiles or a reference resolution of some sort |
| 21:00 |
v-rob |
I've already changed the entire coordinate system and kept backwards compatibility. It's the very first thing I ever did for MT. I don't think you have to worry about that |
| 21:00 |
hecks |
:o ok |
| 21:00 |
hecks |
basically uh |
| 21:00 |
v-rob |
(Trivia: It's the first time I ever did C++ either) |
| 21:00 |
hecks |
anybody with a brain already wraps formspecs in something |
| 21:00 |
hecks |
so it would be good if at least they could keep their layouts |
| 21:01 |
hecks |
and only change the implementation |
| 21:02 |
v-rob |
There may be a sizer for absolute layouts for easy formspec transitioning. However, it will be highly discouraged for any new GUIs |
| 21:02 |
v-rob |
Other sizers will be highly recommended. |
| 21:03 |
hecks |
as long as i don't have to crop elements or reserve empty space ever |
| 21:03 |
hecks |
those are no-go |
| 21:03 |
hecks |
autogenerated scrollbars are also considered harmful |
| 21:04 |
v-rob |
BTW: as an exercise, I made a basic mock-up of how one could design your GUI with sizers: <https://user-images.githubusercontent.com/31123645/126883250-67414ef6-5fbc-445e-8b90-fdf26c338d06.png> |
| 21:05 |
hecks |
have you considered that the right window must be 4 inventory cells wide |
| 21:06 |
hecks |
and that the compactness is intentional and desirable? |
| 21:06 |
hecks |
the only thing i would do if i could is |
| 21:06 |
hecks |
shift the left and right windows around depending on the screen aspect ratio |
| 21:06 |
hecks |
but never enough that they start eating the middle section's space |
| 21:06 |
hecks |
at that point i'd rather just scale everything |
| 21:07 |
hecks |
still, the creator form is low hanging fruit |
| 21:07 |
hecks |
https://a.uguu.se/U4XTKOjWAB5W_inv.png the inventory has zero dead space reserved |
| 21:07 |
v-rob |
Sizers don't make it difficult to not be compact. Just make the outermost sizer's dimensions maximums, or remove them altogether |
| 21:07 |
hecks |
but |
| 21:08 |
hecks |
you can't make that window wider than 4 cells because there would be ugly gaps around the inventory |
| 21:08 |
hecks |
you cannot make it more narrow because it would no longer fit |
| 21:08 |
hecks |
game GUIs generally don't stretch as much as HTML |
| 21:08 |
hecks |
i think you just don't play a lot of games |
| 21:09 |
v-rob |
Not everything in Minetest is a game GUI like yours. And some people like to translate |
| 21:09 |
v-rob |
Without scrollbars, like you |
| 21:10 |
hecks |
i just want the option to fix everything and scale uniformly |
| 21:10 |
hecks |
or fix entire chunks at least |
| 21:10 |
hecks |
but that's basically just for aspect ratio support (which is becoming less important as 4:3 screens are rare) |
| 21:10 |
nrz |
hecks, wrong, many AAA games are using cef3 which is chromium like rendering in games ? |
| 21:11 |
hecks |
i'd voice my opinion on libcef but this is a mostly SFW channel |
| 21:11 |
hecks |
they also used to literally use flash in the form of Scaleform |
| 21:12 |
hecks |
first, it doesn't matter what they use because they often fix the GUI layout a lot anyway |
| 21:13 |
v-rob |
How would your fixed layouts work for a HUD anyway? |
| 21:13 |
hecks |
anchors |
| 21:13 |
hecks |
groups would be fixed relative to one another but still be able to move with the screen corners |
| 21:14 |
hecks |
i think this is already possible in the hud system |
| 21:14 |
v-rob |
The HUD system uses percentages |
| 21:14 |
hecks |
since the position of an element is normalized device coordinates |
| 21:14 |
hecks |
and offsets can be expressed in pixels |
| 21:14 |
hecks |
then i can use the former to anchor to a corner and then use pixel offsets |
| 21:15 |
hecks |
and the DPI setting will scale it all correctly and it'll work in every aspect ratio =] |
| 21:15 |
hecks |
which is kind of how it works in unity and, well, it works |
| 21:15 |
hecks |
and this is how most game guis work |
| 21:16 |
hecks |
even the games that use floating windows a lot like various MMOs, they rarely flex anything inside the windows |
| 21:16 |
hecks |
basically for aesthetic reasons |
| 21:17 |
rubenwardy |
The point of sizers/layouters is to make it easier to make GUIs - you don't need to manually specify positions and sizes, you instead use elements to place children one on top of another, for example |
| 21:17 |
rubenwardy |
Responsiveness can also be supported by this, but only one benefit |
| 21:17 |
hecks |
i'm not opposed to anchors and hierarchy |
| 21:18 |
rubenwardy |
Layouters include linear (side by side), grid, and absolute (like formspecs) |
| 21:18 |
rubenwardy |
Also constraing |
| 21:18 |
rubenwardy |
Although that's not really needed |
| 21:18 |
hecks |
well then I'd end up using enough constraints that it would be indistinguishable from a fixed layout |
| 21:18 |
v-rob |
I want opinions: sfan5, celeron55, Krock: who prefers absolute fixed-size layouts over sizer-based layouts? |
| 21:19 |
hecks |
all i care about is relative fixing |
| 21:19 |
hecks |
that's a strawman too |
| 21:19 |
rubenwardy |
You could just use absolute layouters if that matches your workflow |
| 21:19 |
sfan5 |
'prefer to work with' or 'consider the superior solution'? |
| 21:19 |
v-rob |
Both |
| 21:20 |
sfan5 |
guess we need both fixed-size and sizer-based then |
| 21:20 |
hecks |
would diablo be that memorable without its cell inventory and basically pixel-perfect GUIs? |
| 21:20 |
nrz |
i agree |
| 21:21 |
rubenwardy |
I think sizer based is superior, but supporting absolute would be fine |
| 21:22 |
hecks |
as i've said i'm fine with aspect ratio correction, supporting a range from 4:3 to 16:9 by moving whole groups around |
| 21:22 |
hecks |
but as soon as either ratio is hit i want my gui to just shrink beyond that point |
| 21:22 |
hecks |
instead of cutting text off with ellipses or spawning scrollbars for it |
| 21:23 |
hecks |
and likewise i want perfect control over which part gets stretched out between the aspect ratios, instead of everything stretching sort of uniformly |
| 21:23 |
hecks |
because it's a game inventory screen, not a website |
| 21:23 |
v-rob |
Stretching some things but not others sounds like sizers... |
| 21:24 |
sfan5 |
sizers between fixed-size containers that is |
| 21:24 |
hecks |
yup |
| 21:24 |
hecks |
it could also be expressed as anchors |
| 21:26 |
hecks |
like here's one of my planned guis https://a.uguu.se/uFgYNb4uw6f3_skilltree.png |
| 21:27 |
hecks |
there's not a whole lot of opportunity to flexibly scale things in it |
| 21:27 |
hecks |
especially if i want to style it with artwork in this way |
| 21:35 |
|
kilbith joined #minetest-dev |
| 21:36 |
v-rob |
Well then, you can have your fixed layouts. I implement them under protest, however |
| 21:37 |
sfan5 |
people with existing layouts would have lots of issues if new formspecs don't support fixed sizes |
| 21:37 |
sfan5 |
weren't you planning for this? |
| 21:37 |
hecks |
I don't understand what's so evil about it... |
| 21:41 |
rubenwardy |
Not evil, just painful to calculate all the coordinates and write reusable components |
| 21:44 |
v-rob |
I don't want to provide pure fixed layouts because, since they are easier, people will use them, and then their stuff breaks easily because they can't support anything like translations or different user preferences. |
| 21:44 |
v-rob |
Changing a font should never be a breaking change, and yet fixed layouts make it so. That's ludicrous. |
| 21:44 |
rubenwardy |
I'm not sure they're necessarily easier though |
| 21:45 |
v-rob |
Easier to get started with and easier to understand |
| 21:45 |
rubenwardy |
They shouldn't be easier, our API would be bad in that case |
| 21:45 |
v-rob |
Not easier in the long run |
| 21:47 |
v-rob |
That is, it's easy to understand "put this element at (X, Y)" than "put this element in some flexible container", so people gravitate towards it. I used to do it myself a long time ago with desktop toolkits. |
| 21:47 |
hecks |
the mistake is letting the user decide the font instead of letting the server send it |
| 21:48 |
rubenwardy |
Accessibility |
| 21:48 |
hecks |
unity used to have a desktop-like GUI system, everyone thought it was shit and they switched to an anchor based one |
| 21:50 |
hecks |
they thought they were being clever with skins and styling and sizing and layout groups... |
| 21:57 |
Calinou |
in an era of hiDPI and ultrawide monitors, we should definitely design something scalable |
| 21:57 |
Calinou |
especially if you want to improve the Android situation :) |
| 22:07 |
|
hecks joined #minetest-dev |
| 22:07 |
hecks |
if you want to improve the android situation, fix their controls |
| 22:07 |
hecks |
and we have a DPI setting already |
| 22:07 |
hecks |
in fact it's the best way to scale anything and works with even my "evil" fixed GUIs |
| 22:08 |
hecks |
https://user-images.githubusercontent.com/42101236/126729643-8362bdc2-20ba-481d-8ba5-75a1e5fedcfb.png |
| 22:09 |
hecks |
so saying my forms don't scale is a strawman unfortunately |
| 22:09 |
hecks |
what they can't do is fit all aspect ratios, but letterboxing 4:3 is fine really |
| 22:11 |
sfan5 |
<hecks> and we have a DPI setting already < it's almost always ignored |
| 22:11 |
sfan5 |
because it's only a fallback when MT doesn't know how to retrieve the dpi |
| 22:11 |
sfan5 |
which is approximately never |
| 22:21 |
MTDiscord |
<Jordach> btw |
| 22:21 |
MTDiscord |
<Jordach> DPI is wrong on macOS and is actually 96 on any standard VESA compliant display |
| 22:21 |
MTDiscord |
<Jordach> like windows it was never 72 |
| 22:29 |
|
Extex joined #minetest-dev |
| 23:11 |
hecks |
the default should probably just be 96, that's what screens actually use don't they |
| 23:12 |
hecks |
sfan5: we need a percentage DPI scale setting on top of it |
| 23:13 |
hecks |
because changing the DPI OS wide to make things bigger when you want to is a bit of a hassle |
| 23:16 |
MTDiscord |
<Jordach> can we like just move to 96 dpi globally and use npow2 scaling |
| 23:18 |
hecks |
yes |
| 23:18 |
hecks |
96 is actually the setting where a 16px font is 16 pixels (wow!) |
| 23:19 |
hecks |
and uhh |
| 23:19 |
hecks |
not npow2 scaling, integer scaling |
| 23:19 |
hecks |
x3 is fine |
| 23:19 |
hecks |
if the idea is to avoid misscaling sprites |
| 23:19 |
MTDiscord |
<Jordach> you knew what i meant |
| 23:19 |
hecks |
sure |
| 23:19 |
MTDiscord |
<Jordach> scaling that doesn't introduce the heinous irrlicht scaling |
| 23:20 |
hecks |
it's not irrlicht's fault, it's an inherent problem with scaling sprites |
| 23:20 |
MTDiscord |
<Jordach> inventory slots are known to smush textures |
| 23:20 |
hecks |
but |
| 23:20 |
hecks |
inventory slots are another problem |
| 23:20 |
hecks |
and i'd like to see it resolved one day |
| 23:20 |
hecks |
this is the one place i haven't been able to eliminate shitty scaling from |
| 23:21 |
hecks |
i ended up sizing my item sprites 24x24 because that looks good in the hotbar |
| 23:21 |
hecks |
but |
| 23:21 |
hecks |
they are actually slightly off in the inventory |
| 23:21 |
hecks |
https://a.uguu.se/oHCfxCfitcgp_compare.jpg just barely |
| 23:22 |
MTDiscord |
<Jordach> use the tried and tested ellen ripley method: nuke it from orbit |
| 23:22 |
hecks |
i mean it looks like we ought to scale it down a little in the inventory |
| 23:22 |
hecks |
bring it down a size |
| 23:22 |
hecks |
a few pixels whatever |
| 23:22 |
hecks |
but |
| 23:22 |
hecks |
i sure hope doing that wouldn't break some weird default that minetest_game happens to work on or something... |
| 23:23 |
MTDiscord |
<Jordach> what |
| 23:24 |
MTDiscord |
<Jordach> 's minetest game |
| 23:24 |
hecks |
:DDD |
| 23:24 |
hecks |
i would go and test it at 72 dpi but i literally can't set it |
| 23:24 |
hecks |
on windows |
| 23:24 |
hecks |
like maybe it works at 72 with 16x16 sprites on both? is somebody who actually coded this in the room? |
| 23:25 |
MTDiscord |
<Jordach> and right now i need to swap KVM to give the author of 11287 a very good ribbing |
| 23:27 |
hecks |
oh uhhh i don't know about any of this build stuff =] |
| 23:27 |
hecks |
i just run whatever sfan spoonfeeds me |
| 23:38 |
hecks |
the hotbar graphic is also messed up now that i look at it |
| 23:42 |
hecks |
oh this is also kinda ridiculous |
| 23:42 |
hecks |
https://a.uguu.se/qPEJAhIlkjrS_wat.gif |
| 23:42 |
hecks |
so this is the power of sizers... |
| 23:49 |
|
AliasAlreadyTake joined #minetest-dev |
