| Time |
Nick |
Message |
| 01:20 |
|
twoelk left #minetest-dev |
| 01:31 |
|
ronoaldo joined #minetest-dev |
| 03:23 |
|
MTDiscord2 joined #minetest-dev |
| 03:33 |
|
MTDiscord3 joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 06:48 |
|
olliy joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:02 |
|
hlqkj joined #minetest-dev |
| 11:31 |
|
proller joined #minetest-dev |
| 11:50 |
|
calcul0n_ joined #minetest-dev |
| 12:22 |
|
tech_exorcist joined #minetest-dev |
| 12:33 |
MTDiscord |
<Warr1024> Are people already aware of the attachment regressions that happened sometime after 5.3, or do I need to file a bug for them? I tried searching GH and didn't find anything, but I also know that I'm bad at guessing the correct search terms... |
| 12:34 |
sfan5 |
first time I hear of anything like that |
| 12:35 |
MTDiscord |
<Warr1024> IIRC I first observed the bug in 5.0: when a player with attached entities traveled outside your loaded area, then back in, entities attached to their body became detached and would remain hovering at the place where they became loaded instead of following in around that player's body. |
| 12:36 |
MTDiscord |
<Warr1024> They were finally fixed in like 5.1 or 5.2 by hecks who had to do some kind of ridiculous exhaustive search of parameters for the things because attachment behavior is apparently insanely fragile... |
| 12:36 |
sfan5 |
oh that, don't think that's new |
| 12:37 |
MTDiscord |
<Warr1024> Er, no wait, maybe hecks fixed the jiggling attachments bug, and maybe it was SmallJoker who fixed the coming undone bug? |
| 12:37 |
sfan5 |
possibly |
| 12:38 |
MTDiscord |
<Warr1024> Either way, it was working perfectly in at least 5.3, and I think it was very good (minor/cosmetic issues only) in 5.1 and 5.2. Now it's back to sometimes-entirely-broken in at least the last version of 5.5-dev before the irrlicht fork hit, since I can no longer build MT as-is and haven't had time to go through the work of setting up w/ the new irrlicht yet. |
| 12:39 |
MTDiscord |
<Warr1024> I think it MAY be broken in 5.4-release, but it's one of those annoying heisenbugs that only breaks when not being observed by somebody who can actually do anything about it. |
| 12:57 |
|
absurb joined #minetest-dev |
| 13:26 |
|
Lunatrius` joined #minetest-dev |
| 13:31 |
|
celeron55_ joined #minetest-dev |
| 13:31 |
|
celeron55_ joined #minetest-dev |
| 13:38 |
|
amk joined #minetest-dev |
| 13:42 |
|
ircSparky joined #minetest-dev |
| 13:42 |
|
ircSparky joined #minetest-dev |
| 13:42 |
|
ssieb joined #minetest-dev |
| 14:10 |
|
Fixer joined #minetest-dev |
| 14:46 |
|
calcul0n__ joined #minetest-dev |
| 14:54 |
|
I_am_6r1d joined #minetest-dev |
| 15:21 |
MTDiscord |
<Jordach> Yeah nah I’ve been seeing that too |
| 15:23 |
MTDiscord |
<Jordach> Worked fine between 5.4 |
| 15:24 |
MTDiscord |
<Jordach> However I have a feeling it’s active object range sending having fun |
| 15:39 |
|
hlqkj joined #minetest-dev |
| 15:39 |
|
twoelk joined #minetest-dev |
| 16:19 |
|
ircSparky_ joined #minetest-dev |
| 16:19 |
|
calcul0n_ joined #minetest-dev |
| 16:53 |
MTDiscord |
<nerzhul> interesting, there is ugly warnings on irrlicht strings |
| 16:53 |
Pexin |
I have fairly technical question about the UnknownKeycode exception currently defined entirely in keycode.cpp |
| 16:53 |
Pexin |
I can move the class declaration to the .h file, OR I can add try+catch inside the existing keyname_to_keycode() which may slow input processing on touchscreens. |
| 16:53 |
Pexin |
Anyone know if there's a particular reason it isn't declared in .h already? |
| 16:57 |
MTDiscord |
<nerzhul> it's not in header in order to prevent exposure, originally, i think |
| 16:58 |
Pexin |
exposure from..? |
| 17:00 |
MTDiscord |
<nerzhul> other c++ code |
| 17:00 |
MTDiscord |
<nerzhul> sfan5: nice with irrlicht 1.9 fork used all my keys are working properly in inputs ? |
| 17:00 |
Pexin |
like to prevent a name conflict? |
| 17:00 |
MTDiscord |
<nerzhul> nop, to prevent direct use |
| 17:01 |
MTDiscord |
<nerzhul> it's just a way to hide objects to prevent using it in wrong places in code |
| 17:01 |
Pexin |
well I need to use it, so I dont know whether to make it publically accessible or risk (possibly) bogging down touchscreen users |
| 17:02 |
Pexin |
well, or i could just write an extra wrapper function |
| 17:09 |
|
hlqkj_ joined #minetest-dev |
| 17:17 |
sfan5 |
moving the exception to the header file should be fine |
| 17:17 |
Pexin |
sfan5: ok, thanks |
| 17:20 |
MTDiscord |
<nerzhul> sfan5: i'm looking if we can put all irrlicht_changes folder inside irrlicht direct |
| 17:20 |
MTDiscord |
<nerzhul> it sounds possible but some parts are tied to minetest utils. Which mean we may push utils to irrlicht, for some functions |
| 17:21 |
MTDiscord |
<nerzhul> EnrichedString is the one blocking me currently. I'm thinking about changing it to an interface |
| 17:21 |
MTDiscord |
<nerzhul> this will be the proper thing i think |
| 17:21 |
sfan5 |
since many are tied with MT I don't think it makes sense to move all of them |
| 17:22 |
MTDiscord |
<nerzhul> no, but CGUITTFont is clearly a good candidate |
| 17:22 |
MTDiscord |
<nerzhul> i'm thinking about MT generics, not the MT specifics |
| 17:22 |
MTDiscord |
<nerzhul> i mean for example no interest to push rendering logic etc ? |
| 17:30 |
MTDiscord |
<nerzhul> hmm it should be trickier haha |
| 17:30 |
MTDiscord |
<nerzhul> will retry with more vanilla export then |
| 17:35 |
MTDiscord |
<nerzhul> sfan5: how we ask users on devel branch to update ? they must update both irrlicht & minetest at the same time right ? if they forgot one it's not fine, right ? |
| 17:36 |
sfan5 |
during development users should just do both |
| 17:36 |
MTDiscord |
<nerzhul> okay perfect, here is one trivial one: https://github.com/minetest/irrlicht/pull/20 |
| 17:36 |
sfan5 |
when it comes to releasing we can bump the revision number in irrlicht and check that inside mt |
| 17:37 |
MTDiscord |
<nerzhul> its friend is there: https://github.com/minetest/minetest/pull/11090 |
| 17:37 |
MTDiscord |
<nerzhul> this file can be safely owned by irrlicht ? |
| 17:40 |
MTDiscord |
<nerzhul> ah yeah obviously without merging irrlicht the minetest build fail ? |
| 17:44 |
MTDiscord |
<nerzhul> merging #11089 |
| 17:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/11089 -- Drop old text input workarounds by sfan5 |
| 18:36 |
sfan5 |
ty |
| 20:13 |
|
Seirdy joined #minetest-dev |
| 20:33 |
Krock |
*ahem* will merge #11007, #11017, #11038 and #11064 in 10 minutes |
| 20:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/11007 -- Scale mouse/joystick sensitivity depending on FOV by ryvnf |
| 20:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/11017 -- Check for duplicate login in TOSERVER_INIT handler by EliasFleckenstein03 |
| 20:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/11038 -- Builtin: Italian translation by Zughy |
| 20:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/11064 -- Builtin: Make join/leave messages, and /profiler messages translatable by Wuzzy2 |
| 20:42 |
Krock |
merging |
| 20:43 |
Krock |
nerzhul: duplicate in "TOSERVER_INIT" was possible because the other check was performed much later |
| 20:46 |
Krock |
done |
| 21:13 |
Pexin |
should I be worried that github threw a list of failed checks at me when i submitted my PR? that can't be normal, right? |
| 21:14 |
sfan5 |
yes |
| 22:10 |
|
ircSparky__ joined #minetest-dev |
| 22:10 |
|
hlqkj_ joined #minetest-dev |
| 22:11 |
|
ivanb joined #minetest-dev |
| 22:11 |
|
MTDiscord1 joined #minetest-dev |
| 22:13 |
|
Edgy14 joined #minetest-dev |
| 22:32 |
|
Taoki joined #minetest-dev |
| 22:56 |
|
twoelk joined #minetest-dev |
| 23:01 |
|
proller joined #minetest-dev |
| 23:45 |
|
twoelk left #minetest-dev |
| 23:48 |
|
I_am_6r1d joined #minetest-dev |
