| Time |
Nick |
Message |
| 00:01 |
|
Taoki joined #minetest-dev |
| 00:41 |
|
Soni joined #minetest-dev |
| 01:08 |
schwarzwald[m] |
https://github.com/guybrush77/rapidobj |
| 01:08 |
schwarzwald[m] |
Would it make sense to use this in IrrlichtMt? |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:54 |
|
calcul0n_ joined #minetest-dev |
| 06:47 |
nrz_ |
whereas it can be interesting, we are C++14 only |
| 09:35 |
|
appguru joined #minetest-dev |
| 10:08 |
MTDiscord |
<luatic> The subset of Wavefront OBJ we actually support is pretty small. It thus doesn't really make sense to drag in importers that implement plenty of features we don't need. I've attached the spec I inferred from reading the IrrlichtMT sources. |
| 10:08 |
MTDiscord |
<luatic> https://cdn.discordapp.com/attachments/747163566800633906/1026435448509300748/irr_obj_spec.md |
| 10:18 |
|
kilbith joined #minetest-dev |
| 10:50 |
|
troller joined #minetest-dev |
| 11:08 |
appguru |
(that spec is wrong btw regarding group names: they aren't entirely ignored - only the first name is considered) |
| 11:08 |
|
troller joined #minetest-dev |
| 11:13 |
sfan5 |
@x2048 only broken w/o shaders |
| 11:15 |
sfan5 |
GLES is broken in interesting ways https://0x0.st/oJ8w.png |
| 11:23 |
|
vampirefrog joined #minetest-dev |
| 11:23 |
kilbith |
the main scene is set in another scene, the wieldmesh |
| 11:24 |
kilbith |
quite interesting |
| 12:04 |
MTDiscord |
<Jonathon> @x2048 |
| 12:19 |
MTDiscord |
<savilli> Broken for me with undersampling = 2 and without shaders on nvidia and intel gpu |
| 12:20 |
MTDiscord |
<savilli> Looks like you need to test without shaders too |
| 13:21 |
pgimeno |
sfan5: any idea what shader is the culprit? |
| 13:22 |
pgimeno |
I mean for the "Irrlicht: GLSL shader failed to compile" error |
| 13:31 |
|
srifqi joined #minetest-dev |
| 13:31 |
MTDiscord |
<savilli> What if you set enable_bloom and enable_bloom_debug in your config? |
| 13:32 |
srifqi |
sfan5, is it the same as #12824? |
| 13:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/12824 -- Shaders won't compile on OpenGL ES 2.0+ after #12791 |
| 13:34 |
pgimeno |
ah there's a proposed patch already |
| 13:35 |
vampirefrog |
there's bloom now? |
| 13:36 |
vampirefrog |
okay bloomer |
| 13:45 |
|
Fixer joined #minetest-dev |
| 13:56 |
|
srifqi1 joined #minetest-dev |
| 15:06 |
sfan5 |
pgimeno: its almost surely the same issue as srifqi linked |
| 15:16 |
|
fluxionary joined #minetest-dev |
| 16:01 |
|
Taoki joined #minetest-dev |
| 16:03 |
|
jwmhjwmh joined #minetest-dev |
| 16:05 |
jwmhjwmh |
Merging #12830 and #12832 in 5m. |
| 16:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/12830 -- DevTest: Reject buggy "/hp inf" command by Wuzzy2 |
| 16:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/12832 -- Disable -ffinite-math-only by TurkeyMcMac |
| 16:06 |
pgimeno |
hold on please |
| 16:07 |
jwmhjwmh |
OK |
| 16:07 |
jwmhjwmh |
Do you need to review them? |
| 16:07 |
MTDiscord |
<luatic> inf or nan should be rejected at a different level |
| 16:07 |
MTDiscord |
<luatic> that is, the engine should refuse modders trying to set hp to inf or nan |
| 16:08 |
MTDiscord |
<luatic> (checking in the chatcommand probably still is a good idea to prevent a crash though) |
| 16:08 |
pgimeno |
ok, I was just looking up the reasoning for -ffinite-math-only, go ahead |
| 16:10 |
pgimeno |
@luatic yes but Desour has a point, that isinf() returns false with -ffinite-math-only |
| 16:11 |
MTDiscord |
<luatic> I was commenting on the first PR by Wuzzy |
| 16:11 |
MTDiscord |
<luatic> Which should still be merged, but the issues goes deeper and should be solved at a deeper level I suppose |
| 16:12 |
jwmhjwmh |
Casting from floating point to integer is par for the course in the Minetest API. |
| 16:12 |
jwmhjwmh |
I will merge the PRs then, thanks. |
| 16:13 |
pgimeno |
my point was that it can't be solved at the C++ level without a working isinf() |
| 16:38 |
|
kilbith joined #minetest-dev |
| 16:56 |
|
appguru joined #minetest-dev |
| 17:22 |
|
vampirefrog joined #minetest-dev |
| 18:19 |
|
Fixer joined #minetest-dev |
| 19:16 |
|
appguru joined #minetest-dev |
| 19:19 |
|
appguru joined #minetest-dev |
| 19:29 |
|
vampirefrog joined #minetest-dev |
| 19:41 |
celeron55 |
https://forum.minetest.net/viewtopic.php?p=414783 |
| 19:42 |
celeron55 |
this is interesting from a core dev and/or a distribution perspective |
| 19:43 |
celeron55 |
its license appears to respect MT (lgpl2.1) and it's multi platform. so it's worth following |
| 19:45 |
sfan5 |
where do the builds come from for platforms that aren't windows? |
| 19:48 |
celeron55 |
the posts give the impression that recluse4615 is building non-windows builds on WSL, but i have no idea |
| 19:50 |
celeron55 |
anyway, people might have to ready their opinions about having a launcher that's not implemented natively in MT, if that project gains contributors and gets fleshed out |
| 19:56 |
celeron55 |
the positive things are probably: it would allow people to contribute who know those technologies rather than C++ and Lua, and allows making a better launcher experience. the launcher is client-side only anyway so it doesn't need to be limited in any way |
| 19:57 |
celeron55 |
the negative side is: any work that's put into the launcher stays there only and can't be used elsewhere in MT, and some developers need to have the knowledge to use the different technologies |
| 19:58 |
celeron55 |
anyway, i'll be following it to see where it goes and what users think of it |
| 20:01 |
celeron55 |
it could be that the launcher portion should be made by a separate team anyway |
| 20:05 |
celeron55 |
just need to figure out where to find a team that would work enthusiastically for years to come... on a launcher, of all things |
| 20:07 |
|
Fixer joined #minetest-dev |
| 20:17 |
MTDiscord |
<Warr1024> As long as the launcher isn't mandatory (i.e. MT continues to maintain its own front-end) and there are no lock-in features, I don't see the downsides as being that big of a threat. |
| 20:18 |
MTDiscord |
<Warr1024> A big upside to 3rd party launchers is that it takes some pressure off of the core team of having to please every possible user. You can allow 3rd party launchers to fill in some niche cases and concentrate resources elsewhere (not that those resources aren't necessarily already elsewhere, but now it's sort of more okay if they are) |
| 20:18 |
|
vampirefrog joined #minetest-dev |
| 20:19 |
MTDiscord |
<Warr1024> If you're thinking of having an official launcher team, well, all you really have to do is officially endorse some existing launcher once it reaches the standards you have in mind. |
| 20:27 |
celeron55 |
that's probably the only way that can possibly work |
| 20:27 |
celeron55 |
that's why this is an interesting project |
| 20:27 |
celeron55 |
i'm not saying there's a definite or distinct _need_ for it, but it could address some long lasting complaints |
| 20:29 |
celeron55 |
and it is an unique opportunity because the interface from a launcher into MT is reasonably well defined |
| 20:29 |
celeron55 |
and fairly stable |
| 20:31 |
MTDiscord |
<Warr1024> With MT's --go command line parameter, it already has been pretty supportive of external "launcher" type solutions, including mine which just parses a file with a list of favorite servers and spits out *.desktop files :-) |
| 20:31 |
celeron55 |
as a bonus, a separate launcher can provide features that a launcher built into the MT executable probably will never do, like allowing switching between versions of MT |
| 20:32 |
celeron55 |
it seems like fertile enough ground for something generally useful to eventually pop up |
| 20:32 |
MTDiscord |
<Warr1024> Right, and auto-updating. Alerting the user an update is available is pretty reasonable for MT itself, but trying to actually update the local copy seems pretty hardcore can'o'worms. |
| 20:33 |
celeron55 |
well, it's all doable of course. but it may or may not make sense |
| 20:34 |
MTDiscord |
<Warr1024> Well, some things are just really messy, and it's nice to have somebody else be willing to deal with the mess instead :-D |
| 20:34 |
celeron55 |
we'll see |
| 20:38 |
celeron55 |
the technology used in this one (tauri + sveltekit) is kind of wild from a minimalist's perspective |
| 20:39 |
|
troller joined #minetest-dev |
| 20:46 |
|
Taoki_1 joined #minetest-dev |
| 21:12 |
|
Taoki joined #minetest-dev |
| 22:20 |
|
vampirefrog joined #minetest-dev |
| 22:34 |
|
diceLibrarian joined #minetest-dev |
| 22:34 |
|
panwolfram joined #minetest-dev |
| 22:57 |
|
olliy1or joined #minetest-dev |
