| Time |
Nick |
Message |
| 00:36 |
|
AliasAlreadyTake joined #minetest-dev |
| 01:16 |
|
v-rob joined #minetest-dev |
| 01:50 |
|
behalebabo joined #minetest-dev |
| 02:50 |
|
v-rob joined #minetest-dev |
| 03:28 |
|
queria^clone joined #minetest-dev |
| 03:33 |
|
queria^clone joined #minetest-dev |
| 04:24 |
|
erlehmann joined #minetest-dev |
| 04:48 |
|
erlehmann joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:12 |
|
v-rob joined #minetest-dev |
| 05:23 |
|
rogerm[m] joined #minetest-dev |
| 06:17 |
|
v-rob joined #minetest-dev |
| 07:01 |
|
kilbith joined #minetest-dev |
| 07:19 |
|
Fleckenstein joined #minetest-dev |
| 07:29 |
|
Fleckenstein joined #minetest-dev |
| 07:32 |
|
Fleckenstein joined #minetest-dev |
| 07:36 |
|
Fleckenstein joined #minetest-dev |
| 08:50 |
|
olliy joined #minetest-dev |
| 09:11 |
|
calcul0n joined #minetest-dev |
| 10:13 |
|
Fixer joined #minetest-dev |
| 11:08 |
|
pgimeno joined #minetest-dev |
| 11:08 |
pgimeno |
#11784 |
| 11:08 |
ShadowBot |
https://github.com/minetest/minetest/issues/11784 -- Use virtual paths to specify exact mod to enable by rubenwardy |
| 11:09 |
rubenwardy |
Hi |
| 11:09 |
pgimeno |
o/ |
| 11:10 |
pgimeno |
I dropped by to post this link in case it's of interest, as I saw someone posting it elsewhere: https://zed0.co.uk/clang-format-configurator/ |
| 11:12 |
pgimeno |
I think clang-format was rejected as not suitable despite all configurability though |
| 11:16 |
pgimeno |
there have been a lot of changes in the mod loading area that make it diverge from the initial idea, so I gave up |
| 11:41 |
pgimeno |
+ * This intended to be used as an identifier for a modpath that tolerates file movement, |
| 11:41 |
pgimeno |
@rubenwardy in what sense does it tolerate file movement? as in, moving to another directory? |
| 11:44 |
pgimeno |
problem is, now you can have two mods with the same name in the same modpack or in the main mods directory, and there is no longer a way to distinguish them in order to select which specific one to load |
| 11:44 |
pgimeno |
except by directory |
| 11:45 |
pgimeno |
my patch tried to address that |
| 11:46 |
pgimeno |
it predated the setting of the modname via mod.conf; when that change was implemented is when I gave up |
| 11:54 |
pgimeno |
oh well, leaving again. I'm available via PM though. I'd appreciate if someone PMs me when/if the whining definitively stops sometime, but I take a look at the online logs from time to time to check. |
| 11:54 |
|
pgimeno left #minetest-dev |
| 12:33 |
|
Fixer joined #minetest-dev |
| 12:38 |
|
proller joined #minetest-dev |
| 13:14 |
rubenwardy |
hm, it looks like I can't build with RUN_IN_PLACE=0 |
| 13:16 |
rubenwardy |
will try cloning from scratch |
| 13:16 |
sfan5 |
wfm |
| 13:18 |
MTDiscord |
<josiah_wi> If there is anything I can do to help debug or fix it please let me know. |
| 13:23 |
|
olliy1or joined #minetest-dev |
| 13:34 |
|
olliy joined #minetest-dev |
| 13:47 |
|
olliy1or joined #minetest-dev |
| 14:55 |
|
kilbith joined #minetest-dev |
| 15:52 |
|
Krock joined #minetest-dev |
| 15:55 |
|
v-rob joined #minetest-dev |
| 16:32 |
|
appguru joined #minetest-dev |
| 16:51 |
|
olliy joined #minetest-dev |
| 16:55 |
|
v-rob joined #minetest-dev |
| 17:07 |
|
v_rob joined #minetest-dev |
| 17:08 |
|
BuckarooBanzai0 joined #minetest-dev |
| 17:08 |
|
nrz joined #minetest-dev |
| 17:11 |
|
kilbith_ joined #minetest-dev |
| 17:20 |
|
Noisytoot joined #minetest-dev |
| 17:22 |
|
Krock joined #minetest-dev |
| 17:24 |
|
Taoki joined #minetest-dev |
| 18:15 |
|
v_rob joined #minetest-dev |
| 18:49 |
|
fluxionary joined #minetest-dev |
| 18:53 |
|
proller joined #minetest-dev |
| 18:56 |
|
fluxionary joined #minetest-dev |
| 19:58 |
|
proller joined #minetest-dev |
| 20:08 |
|
Extex joined #minetest-dev |
| 20:20 |
MTDiscord |
<exe_virus> Hello, I'm having issues setting the default backend for a game with game.conf, looking at content/subgames.cpp, lines 358-360, it looks like SQLite3 is hardcoded. Is this the case? Why can't I set it to dummy via game.conf? |
| 20:20 |
MTDiscord |
<Sublayer plank> it is indeed hardcoded |
| 20:21 |
MTDiscord |
<Sublayer plank> I actually wanted to make a PR to make it configurable by a setting but I gave up since I didn't know how to manage what backends are available |
| 20:21 |
|
proller joined #minetest-dev |
| 20:24 |
MTDiscord |
<exe_virus> It's pretty straightforward to make it not hardcoded, I just need to ask the most recommended way to do so using the settings hierarchy system |
| 20:49 |
sfan5 |
I'd say games aren't "supposed" to touch those settings anyway |
| 20:50 |
MTDiscord |
<Jonathon> setting to dummy has a use. but otherwise i would agree |
| 20:53 |
sfan5 |
hm, true |
| 20:57 |
|
proller joined #minetest-dev |
| 21:09 |
|
MTDiscord joined #minetest-dev |
| 21:11 |
MTDiscord |
<exe_virus> Anyways, I can make the PR relatively easily, already tested it locally just gotta grab the backend="value" value, check that it's valid, set up a defaults.cpp value, and actually allow games to use game.conf. Based on my testing the game.conf value was not respected, but minetest.conf was after the change |
| 21:11 |
MTDiscord |
<exe_virus> is game.conf even being respected at all rn? |
| 21:12 |
MTDiscord |
<Warr1024> It feels like teleporting the player somewhere far away to load the new level would be better because you avoid the client side thinking it has the terrain already cached. Forgot to mention it but I ran into that a fair bit in Labyrinth. I'd start a new maze then fall through the floor before the new maze finished overwriting the old one. The ignores that are placed there if the area isn't cached are solid so you don't fall if the |
| 21:12 |
MTDiscord |
client doesn't think it has the area loaded. |
| 21:13 |
MTDiscord |
<exe_virus> Oh trust me I know about the issue, but that requires a prebuilt map. And it can't support infinite levels |
| 21:13 |
MTDiscord |
<exe_virus> And labyrinth is coded badly, I know that too |
| 21:13 |
MTDiscord |
<exe_virus> it could be improved greatly |
| 21:13 |
MTDiscord |
<Jonathon> game.conf is rather annoying as minetest.conf just writes all over when the user changes stuff, thus meaning your at players mercy as a game dev |
| 21:13 |
MTDiscord |
<exe_virus> but also, we miss physics packets a lot. I have to send multiple times sometimes to get MT to hear it |
| 21:14 |
MTDiscord |
<exe_virus> I agree on the minetest.conf breaking crap, but alas that's how it is. |
| 21:14 |
MTDiscord |
<exe_virus> technically I think we could override world.mt at mod load though |
| 21:14 |
MTDiscord |
<Warr1024> IIRC a lot of devs agree settings are a mess and there are open issues to try to get some sanity for them, but we can't agree on how to fix them, nor which settings should be controlled by what parties. |
| 21:15 |
MTDiscord |
<Warr1024> Players should have ultimate overriding control over the software running on their machines, but settings need to be robust enough that players don't feel required to change things themselves, and that changes made for needs specific to one world don't break settings for another. |
| 21:20 |
MTDiscord |
<exe_virus> why not minetest.conf -> game.conf ->world.conf? |
| 21:20 |
MTDiscord |
<exe_virus> well, defaults.cpp ->minetest.conf ->game.conf ->world.conf? |
| 21:21 |
MTDiscord |
<exe_virus> and then there's the issue that some of these aren't respected after startup. For example mouse_sensitivity is completely ignored after minetest starts |
| 21:22 |
MTDiscord |
<Warr1024> General to specific? I was actually thinking defaults -> game -> Minetest -> world based on order of chain of custody rather than structure. Core devs first, then game makers override those, then the player has final say. |
| 21:22 |
MTDiscord |
<exe_virus> game devs overriding core devs, we agree on that then? |
| 21:22 |
MTDiscord |
<Warr1024> That kind of variability is the kind of thing that causes bikeshedding and kills entire ideas even if we 90% agree ... |
| 21:23 |
MTDiscord |
<exe_virus> true, but I want game devs to be able to specify something more specific than minetest.conf |
| 21:23 |
MTDiscord |
<exe_virus> (lowest) defaults -> minetest.conf -> game.conf -> world.conf (highest) |
| 21:24 |
MTDiscord |
<Warr1024> But I think the idea that the engine is passed on to the game devs, who pass completed games onto players, and each gets to make decisions that override previous ones and the previous owners do not get the right to veto, makes sense to me. I mean I even have chat detection in my own game but it doesn't enforce anything. |
| 21:24 |
MTDiscord |
<exe_virus> yes, but allowing players to edit minetest.conf does make sense |
| 21:25 |
MTDiscord |
<exe_virus> plus what do you do about playing online? |
| 21:25 |
MTDiscord |
<exe_virus> there, you don't have access to world.conf |
| 21:25 |
MTDiscord |
<exe_virus> so game.conf would override your local minetest.conf |
| 21:25 |
MTDiscord |
<exe_virus> maybe a multiplayer.conf? |
| 21:26 |
MTDiscord |
<Warr1024> Your hierarchy actually does make more sense to me now, since minetest.conf has been abused enough by now that it's quite problematic if you end up with any settings in there intended for only a specific game... Having a general world conf would help a lot. |
| 21:26 |
sfan5 |
the current is: minetest.conf > game.conf > engine defaults |
| 21:26 |
MTDiscord |
<Warr1024> Per-server confs make sense for MP. By that point though I'd be tempted to just make a custom launcher that swaps around conf files... |
| 21:26 |
sfan5 |
(> as in bigger than) |
| 21:27 |
MTDiscord |
<exe_virus> Right, but game.conf is ignored for like 80% of settings |
| 21:27 |
sfan5 |
(also game.conf as in the minetest.conf in the game, nothing to do with game.conf) |
| 21:27 |
MTDiscord |
<exe_virus> Oh they're different |
| 21:27 |
MTDiscord |
<exe_virus> Crap |
| 21:27 |
MTDiscord |
<exe_virus> Gotta test it again, my b |
| 21:28 |
MTDiscord |
<exe_virus> Either way, sfan do you disagree with my general sentiment? (Also the multiplayer specific conf) |
| 21:29 |
sfan5 |
games trying to set client settings is where this falls apart, none of them will apply in multiplayer |
| 21:29 |
sfan5 |
at which point you run into the problem of "if games need to configure this, it should not be a setting" |
| 21:30 |
MTDiscord |
<Warr1024> One of the settings I really need to be able to set at the game level is gamma. Players need to be able to override (or apply modifiers to) it, but currently I need to instruct players to manually set it because many don't know it's a thing. |
| 21:31 |
MTDiscord |
<Warr1024> Gamma is currently the only effective way to increase light brightness without changing it's radius. |
| 21:35 |
MTDiscord |
<exe_virus> great example, have you seen my mesemon trial demo? It's the pokemon like thing in minetest where you are set to a locked view angle. That depends on setting mouse sensitivity to 0.0001 (wish I could do 0.0), and that's game specific |
| 21:35 |
MTDiscord |
<exe_virus> there's more I could give you, such as fonts, font size, etc. |
| 21:35 |
MTDiscord |
<exe_virus> inverted mouse (for flying sims) |
| 21:35 |
MTDiscord |
<exe_virus> etc. |
| 21:36 |
MTDiscord |
<exe_virus> in the case of multiplayer, why not let games change these kinds of settings for clients, as long as their minetest.conf locally doesn't override it? |
| 21:37 |
sfan5 |
that sounds great until you need to explain to the user that they can't play your game if they have a custom mouse sensitivity set |
| 21:38 |
sfan5 |
what I'm implying here is that if games need something then it needs a proper API |
| 21:42 |
MTDiscord |
<exe_virus> gotcha, well I could make a whole bunch of PR's for such things |
| 21:42 |
MTDiscord |
<exe_virus> but everyone knows that takes a long time |
| 21:45 |
sfan5 |
I think it'd be nice if for one release we dedicated effort to de-hardcode core things |
| 21:47 |
MTDiscord |
<Warr1024> I'd be down for APIs. Tbh some numerical things like gamma or control sensitivity and such make more sense as stacking modifiers, like being added to or multiplied by the value below that layer to get the result... |
| 21:50 |
MTDiscord |
<exe_virus> Yes stacking makes sense, but also direct sets. But yeah a focus on de-hard-coding would be awesome |
| 21:53 |
MTDiscord |
<exe_virus> Though it won't be ready for the game jam, which is a bummer. But oh well, that's what development is all about: working with what you got |
| 21:54 |
MTDiscord |
<MisterE> also the hardcoded player orientation and control scheme are some of my personal change wishes |
| 21:54 |
MTDiscord |
<exe_virus> Fair, yeah lots of those things. |
| 21:55 |
MTDiscord |
<MisterE> We can do more game jams :) |
