| Time |
Nick |
Message |
| 00:50 |
|
ShadowBot joined #minetest-dev |
| 01:04 |
|
ShadowBot joined #minetest-dev |
| 02:53 |
|
v-rob joined #minetest-dev |
| 03:28 |
|
beanzilla joined #minetest-dev |
| 03:41 |
|
YuGiOhJCJ joined #minetest-dev |
| 03:53 |
|
fluxionary joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:08 |
|
fluxionary joined #minetest-dev |
| 04:18 |
|
Noisytoot joined #minetest-dev |
| 04:55 |
|
jonadab joined #minetest-dev |
| 05:02 |
|
fluxionary joined #minetest-dev |
| 05:02 |
|
MTDiscord joined #minetest-dev |
| 05:02 |
|
[MTMatrix] joined #minetest-dev |
| 05:02 |
|
sugarbeet joined #minetest-dev |
| 05:02 |
|
TheCoffeMaker joined #minetest-dev |
| 05:02 |
|
erle joined #minetest-dev |
| 05:02 |
|
fgaz_ joined #minetest-dev |
| 05:02 |
|
behalebabo joined #minetest-dev |
| 05:02 |
|
ShadowNinja joined #minetest-dev |
| 05:02 |
|
pgimeno joined #minetest-dev |
| 05:02 |
|
rubenwardy joined #minetest-dev |
| 05:02 |
|
MisterE123 joined #minetest-dev |
| 05:02 |
|
clavii joined #minetest-dev |
| 05:02 |
|
nore joined #minetest-dev |
| 05:02 |
|
dzho joined #minetest-dev |
| 05:02 |
|
pmp-p joined #minetest-dev |
| 05:03 |
|
[MTMatrix] joined #minetest-dev |
| 05:03 |
|
calcul0n joined #minetest-dev |
| 06:01 |
|
olliy1or joined #minetest-dev |
| 06:51 |
|
v-rob joined #minetest-dev |
| 08:29 |
|
calcul0n_ joined #minetest-dev |
| 08:45 |
|
calcul0n_ joined #minetest-dev |
| 09:09 |
|
yella joined #minetest-dev |
| 09:09 |
|
yella joined #minetest-dev |
| 09:19 |
|
yella joined #minetest-dev |
| 09:19 |
|
yella joined #minetest-dev |
| 09:38 |
|
appguru joined #minetest-dev |
| 09:57 |
|
appguru joined #minetest-dev |
| 12:43 |
ROllerozxa |
is renaming minetest still on the table? haven't heard much discussion about it in a while |
| 12:50 |
[MTMatrix] |
<Zughy> There is an internal discussion, yes |
| 12:54 |
ROllerozxa |
alright, that's understandable |
| 13:35 |
|
TheCoffeMaker joined #minetest-dev |
| 15:30 |
|
Desour joined #minetest-dev |
| 15:34 |
|
fluxionary joined #minetest-dev |
| 16:02 |
|
v-rob joined #minetest-dev |
| 16:24 |
|
olliy joined #minetest-dev |
| 16:53 |
|
tekakutli joined #minetest-dev |
| 17:12 |
erle |
getroffene hunde bellen https://github.com/minetest/minetest/issues/13795#issuecomment-1716093139 |
| 17:15 |
ROllerozxa |
yikes |
| 17:15 |
sfan5 |
wenn du denkst hier weitere kommentare abzulassen helfe deiner position dann nur zu |
| 17:16 |
sfan5 |
du hast aber recht, ich habe vergessen dich wieder in die ignorelist aufzunehmen |
| 17:16 |
erle |
i am not your enemy and i was not making fun of you in particular. i do think you didn't think it through, but closing and locking a proposal that is clearly performance-relevant because you are offended is not exactly helpful |
| 17:24 |
|
[MTMatrix] joined #minetest-dev |
| 17:31 |
[MTMatrix] |
<localhost> check dayoftime on global step is normal? Or minetest have alternative way? |
| 17:31 |
erle |
localhost depends on what you want to achieve and this is probably a topic for #minetest |
| 17:35 |
|
[MTMatrix] joined #minetest-dev |
| 17:37 |
[MTMatrix] |
<localhost> just set sky in skybox by time on every connected and joined players. sorry for offtopic |
| 17:37 |
sfan5 |
should I mark #13800 as blocker given #13550 is likely to be merged soon? |
| 17:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/13800 -- Migration path once MTG is no longer preinstalled |
| 17:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/13550 -- Improve UX when no game exists and drop `default_game` by rollerozxa |
| 17:41 |
rubenwardy |
It's not a blocked as the latter doesn't remove MTG |
| 17:42 |
sfan5 |
ah, true |
| 17:42 |
sfan5 |
do we plan to actually do that this release? |
| 17:42 |
rubenwardy |
that depends on when the release is |
| 17:42 |
rubenwardy |
I'd say |
| 17:44 |
sfan5 |
hmm |
| 17:45 |
|
[MTMatrix] joined #minetest-dev |
| 17:57 |
|
[MTMatrix] joined #minetest-dev |
| 17:59 |
|
v-rob joined #minetest-dev |
| 18:07 |
[MTMatrix] |
<Zughy> it's supposed to be in September, but frankly if we can delay it to remove MTG, I'm all for it |
| 18:08 |
rubenwardy |
we may need to release 5.7.1 very soon to avoid copyright issues |
| 18:08 |
|
[MTMatrix] joined #minetest-dev |
| 18:11 |
erle |
rubenwardy what's copyrighted? |
| 18:12 |
ROllerozxa |
I assume it's about the MTG water texture |
| 18:15 |
sfan5 |
well if anyone can work on #13800 or #13799 then we can remove mtg asa |
| 18:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/13800 -- Migration path once MTG is no longer preinstalled |
| 18:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/13799 -- Allow games to enforce lock-step upgrades with versions |
| 18:15 |
sfan5 |
p |
| 18:26 |
rubenwardy |
the second one is one my to-do list |
| 18:28 |
rubenwardy |
ContentDB allows you to do `min_minetest_version = 5.8` in game.conf to do version limits, would be nice to reuse that. The use of the version name rather than protocol may be an issue, probably should have made it an engine feature before putting it in CDB but alas |
| 18:29 |
rubenwardy |
so for Minetest Game you'd do `min_minetest_version = 5.8` and `max_minetest_version = 5.9-dev` I guess? The -dev there is a bit messy |
| 18:30 |
rubenwardy |
Perhaps you'd only set `min_minetest_version = 5.8` and you'd have support for update detection without entering CDB |
| 18:31 |
rubenwardy |
(I've been working on faster APIs that make it possible to quickly check for updates without loading the full package information) |
| 18:36 |
rubenwardy |
ah #10336 |
| 18:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/10336 -- Warnings when loading a mod incompatible with this version of minetest |
| 18:39 |
rubenwardy |
I went with MT version rather than protocol version as 1) it's more understandable 2) not all MT minor versions have distinct protocol versions. Note that CDB ignores the minor number |
| 18:39 |
rubenwardy |
*patch number |
| 18:41 |
rubenwardy |
So to support forks, we could have a concept of API version which happens to be the same as the Minetest version. So a fork could have version 1.1.1 or whatever but api version 5.8 |
| 18:45 |
[MTMatrix] |
<localhost> whoa! 5.9 soon? |
| 18:47 |
rubenwardy |
let's get 5.8 first |
| 18:54 |
erle |
rubenwardy i think feature detection is better than version detection. why not make the mods list features they need? |
| 18:54 |
erle |
rubenwardy is that too much? |
| 18:54 |
rubenwardy |
that would be very complicated |
| 18:55 |
erle |
i just thought that there is a feature table, so maybe … |
| 18:55 |
rubenwardy |
also the only way that would work is if we gave each mod its own Lua environment and only exposed features if the mod asks for it |
| 18:55 |
erle |
it does not make sense to use those things if the version does cover that though |
| 18:55 |
erle |
i see |
| 18:55 |
ROllerozxa |
btw #13550 should be ready for merge now |
| 18:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/13550 -- Improve UX when no game exists and drop `default_game` by rollerozxa |
| 19:06 |
|
tekakutli joined #minetest-dev |
| 19:10 |
|
Desour joined #minetest-dev |
| 19:41 |
|
appguru joined #minetest-dev |
| 20:01 |
[MTMatrix] |
<Zughy> about game#3061: can't you just use Soothing 32 as default? |
| 20:01 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/3061 -- MTG textures overhaul? |
| 20:03 |
[MTMatrix] |
<Zughy> or Mineclone 2 ones |
| 20:05 |
sfan5 |
making mtg looks like mcl2 wouldn't be good imo |
| 20:05 |
sfan5 |
rubenwardy: ideally only mtg ever uses this feature so I wouldn't worry too much about fork compat |
| 20:06 |
[MTMatrix] |
<Zughy> there's also RPG 16, which contrary to Soothing 32, supports all the MTG mods |
| 20:07 |
sfan5 |
AFAIK the only reason MTG does this anyway is because it does one or two things that aren't guaranteed to be portable across engine versions |
| 20:07 |
MTDiscord |
<warr1024> Soothing 32 is a really nice looking pack, but it makes a very bold aesthetic statement that a lot of existing content wouldn't be able to match. |
| 20:10 |
[MTMatrix] |
<Zughy> warr1024: I think that is better to have a sane default people can try to emulate, than a bad one teaching bad art |
| 20:10 |
sfan5 |
but MTG isn't supposed to be any kind of "default" ;) |
| 20:32 |
|
yella joined #minetest-dev |
| 20:32 |
|
yella joined #minetest-dev |
| 20:38 |
|
_yella_ joined #minetest-dev |
| 20:47 |
|
_yella_ joined #minetest-dev |
| 20:54 |
erle |
why was ”won't add” added to this if it was not discussed on its technical merits at all? https://github.com/minetest/minetest/issues/13795 |
| 20:54 |
erle |
i mean, would it still have been ”won't add” if i had been less of a little sarcastic bitch? |
| 20:57 |
[MTMatrix] |
<Zughy> next time you can avoid acting as a sarcastic bitch so you will know |
| 20:57 |
MTDiscord |
<warr1024> Adding semi-intelligent compression in various places independent of the type of media could actually be pretty nice. LZO or Zstd compression of network payloads, possibly compressing stuff that goes into the media file cache, etc. |
| 20:57 |
[MTMatrix] |
<Zughy> *little sarcastic bitch |
| 20:57 |
erle |
well, i want to tell everyone that i have been told that it is quite rude to point out when people say things that usually indicate they have not put thought into something, even if that assessment is correct (and obviously if it is not). i will try to avoid toing that. |
| 20:58 |
erle |
doing |
| 20:58 |
erle |
zughy i hope next time people can avoid dismissing solutions on a hunch though. |
| 20:58 |
erle |
Warr1024 i agree for obj files actually |
| 20:59 |
MTDiscord |
<warr1024> I haven't tested B3D but they might benefit too |
| 20:59 |
erle |
Warr1024 why don't you open a ticket about it, you are less obnoxious than me |
| 20:59 |
MTDiscord |
<warr1024> and .tr locale files a bit too |
| 20:59 |
ROllerozxa |
B3D and X could benefit from compression over the network too, yeah |
| 20:59 |
ROllerozxa |
(especially text format X models... *shudder*) |
| 20:59 |
erle |
the thing is, with TGA there are files that do not benefit from compression. is that the case with other formats as well? |
| 20:59 |
MTDiscord |
<warr1024> I was hoping for compression at a lower protocol layer too, though, e.g. to compress things like those "object properties" packets and such as well. |
| 21:00 |
erle |
because if that is the case you need introspection to see if the compression is a good idea or not. |
| 21:00 |
erle |
which is something the minetest engine, as far as i can tell, generally does not offer for file formats. |
| 21:00 |
ROllerozxa |
(zipping up mobs_mc_dragon.b3d, which is 670KiB, for testing shrinks it down into 50KiB) |
| 21:01 |
MTDiscord |
<warr1024> Generally the "smart" way to handle compression, assuming the CPU trade-off works out in general, is just to try to compress everything, and if it ends up larger (or you get any early indication it's not going to go well), you just send things uncompressed, and you have a "compressed" flag in the header so you can do that with as little overhead as possible. |
| 21:01 |
MTDiscord |
<warr1024> Compressing media files might be a separate layer to network compression, though, granted. |
| 21:01 |
erle |
for images, the classic gamedev example is a dirt texture that is bigger as a compressed PNG than a TGA because it has too much entropy |
| 21:02 |
erle |
ROllerozxa i have noticed several such models, usually they can be optimized in other ways too. i strongly suggest to open some files in mm3d and see if it can optimize the surfaces. |
| 21:02 |
MTDiscord |
<warr1024> Honestly, just allowing *.z or *.gz and transparently decompressing might be a big boon for media. IIRC there's a way to save PNG files uncompressed, and if you apply compression outside the PNG header, sometimes you can get some benefits even for a format that's supposed to handle compression internally. |
| 21:03 |
erle |
Warr1024 i must disappoint you, having a deflate stream with just literal blocks is one of the worst “uncompressed” formats. |
| 21:03 |
erle |
(that is what “uncompressed PNG” refers to i think) |
| 21:04 |
MTDiscord |
<warr1024> I've seen gzip squeeze a couple of bytes out of an already-compressed PNG anyway. When I'm doing web serving and can pre-compress things, I just throw everything through the compressor and see what comes out before deciding, rather than trying to rely on heuristics. If MT supported transparent decompression of all media, that could become an option for everything MT too. |
| 21:05 |
erle |
well, i already suggested just supporting .z, so i agree. i think heuristics are actually much harder to get right in the engine than in mods. |
| 21:05 |
MTDiscord |
<warr1024> The nice thing about "worst uncompressed formats" is that shoving them through a compressor can still yield surprisingly good results. |
| 21:06 |
MTDiscord |
<warr1024> Yeah, I think we don't even need to worry about heuristics if we just let mod creators decide on whether to compress or not by just providing either compressed or not files. |
| 21:06 |
erle |
yes, but i can not figure out any scenario in which a png.z would would be better than a tga.z (worse in terms of filesize, encoding & decoding speed) |
| 21:06 |
MTDiscord |
<warr1024> Tbh I think your requests to make TGA transfer more efficient would go a lot more smoothly if you just didn't mention TGA 😉 |
| 21:06 |
erle |
> I think we don't even need to worry about heuristics if we just let mod creators decide |
| 21:06 |
erle |
finally someone agrees with me |
| 21:07 |
erle |
Warr1024 so you making an issue for general handling of .z files? |
| 21:08 |
MTDiscord |
<warr1024> Given that .obj, .b3d, .x, and .tr already can benefit from compression, that might already be enough justification anyway without having to drag the more dramatically unpopular formats into the ring. |
| 21:09 |
erle |
i mean if you could just use minetest.compress() on some assets, i'm sure mods would be creative. (i strongly suggest to punch everyone in the face who suggests zstd support here though) |
| 21:09 |
[MTMatrix] |
<localhost> xz super compress, but too hard |
| 21:09 |
erle |
oh no |
| 21:09 |
MTDiscord |
<warr1024> xz is not a great format for this application |
| 21:10 |
MTDiscord |
<warr1024> it's very heavy and takes too long to warm up |
| 21:10 |
erle |
Warr1024 good luck dealing with the comments like “we should use something else than DEFLATE” |
| 21:10 |
erle |
bz2! :P |
| 21:10 |
[MTMatrix] |
<localhost> oops |
| 21:10 |
MTDiscord |
<warr1024> gz, z, lzo, snappy, or zstd are all possible candidates. gz, z, and sztd are also already used in the engine and already available to us. |
| 21:11 |
[MTMatrix] |
<localhost> what if uncompressed? Is too much large? :D |
| 21:11 |
erle |
i want to point out *again* that zstd lacks the dictionary support necessary for small payloads here |
| 21:11 |
MTDiscord |
<warr1024> bz2 is kind of a cool tech in its own way, too bad it's not so hot with files that aren't at least like in the 100kb range. |
| 21:11 |
erle |
in the minetest API |
| 21:11 |
[MTMatrix] |
<localhost> terabytes blocks :P |
| 21:11 |
[MTMatrix] |
<localhost> terabytes of blocks :P |
| 21:12 |
erle |
and that it's an easy footgun, but i disgress |
| 21:12 |
erle |
Warr1024, good luck anyway! |
| 21:12 |
MTDiscord |
<warr1024> Yeah, I dunno about how MT uses zstd, but I assume it must be offering at least some advantage over deflate for payloads in the mapblock-size range, else it'dn't've been used. |
| 21:13 |
erle |
as appguru explained: he saw the benchmarks for mapblocks and thought they applied to smaller stuff |
| 21:13 |
MTDiscord |
<warr1024> I think your feature request may have been too confusing if people were talking about adding compression. It sounds like both you and I are interpreting this feature as offering only decompression in the engine, and game/mod creators would be responsible for doing the compression themselves. |
| 21:13 |
erle |
yes |
| 21:13 |
erle |
and everyone immediately latches on “the engine should do this automatically instead” |
| 21:14 |
erle |
which is a *much* larger task and *much* harder to get right (and not very useful for my use case) |
| 21:14 |
MTDiscord |
<warr1024> Decompression only makes this a lot simpler and easier to implement than compression would, and the costs are negligible, since it wouldn't even change the behavior of existing stuff. |
| 21:14 |
MTDiscord |
<luatic> erle: wdym by "smaller stuff", schematics are often bigger than mapblocks (> 16³) |
| 21:14 |
erle |
luatic go benchmark it! |
| 21:14 |
MTDiscord |
<warr1024> schematics aren't sent as media, so wouldn't apply to this feature anyway |
| 21:15 |
erle |
Warr1024, the only thing you have to make sure is that a .z resource is sent raw to older clients. |
| 21:15 |
erle |
but that's easy obv |
| 21:15 |
MTDiscord |
<warr1024> Ideally, if we've already got the libraries in MT to support .gz, .z, and .zstd, we might as well just support them based on file extension and let creators pick whatever's appropriate on a file-by-file basis. Then we don't need to have the argument about what format is best. |
| 21:16 |
[MTMatrix] |
<localhost> schematics be like: I can save area -500,0,-500; 500,0,500 in WE, but I can't restore it - too large |
| 21:16 |
[MTMatrix] |
<localhost> schematics be like: I can save area -500,0,-500; 500,0,500 in WE for 10 secs, but I can't restore it - too large |
| 21:16 |
erle |
Warr1024, well, zstd *is* generally better, but minetest.compress() does not have dictionary support, which means you can't really outperform zlib meaningfully (except on encoding and decoding speed ig, you get 2 to 3 times) |
| 21:17 |
erle |
at least for small stuff |
| 21:17 |
erle |
and all the stuff we talk here is small |
| 21:17 |
erle |
like <100kb |
| 21:17 |
erle |
right? |
| 21:18 |
erle |
the encoding and decoding speed can probably be enough of an argument though |
| 21:18 |
MTDiscord |
<warr1024> Well, for dynamic stuff we might be limited to just zlib, but for creators pre-compressing stuff at build time e.g. to optimize mod download or server join times, they can just try each format and see. I already run basically all the media for all of my mods and games though a battery of stuff including zopfli compression of the deflate parts in all the PNG files, so now I'd be able to do that sort of thing with my OBJ files and such |
| 21:18 |
MTDiscord |
too... |
| 21:18 |
erle |
i agree |
| 21:19 |
erle |
Warr1024 ha, zopflipng! |
| 21:19 |
erle |
Warr1024 how large are your texture dimensions generally? |
| 21:19 |
[MTMatrix] |
<localhost> and imagine security issue as... blocks as zip bomb in dumped world 👀 |
| 21:19 |
erle |
localhost what do you mean |
| 21:20 |
erle |
there are already items that contain zipped info |
| 21:20 |
erle |
xmaps handheld items and displayed item entities for example contain a zipped TGA in their meta (for easy bookkeeping, garbage collection and so they work in map downloads) |
| 21:20 |
[MTMatrix] |
<localhost> nothing, i just make strange thinks |
| 21:21 |
erle |
and i am pretty sure if shulkers would use compression they could contain more stuff hehe |
| 21:21 |
erle |
bigger recursive shulkers pls |
| 21:21 |
MTDiscord |
<warr1024> I generally do 16px base textures in all my stuff. If people want higher res, that's what TPs are for. I would prefer the baseline to be as conservative as possible a burden on users, and those with capacity for more fancy can add that on as desired later. |
| 21:22 |
MTDiscord |
<warr1024> As for what I actually use to compress my pngs, I run them through optipng, then advpng (which uses zopfli) and then ECT (which has its own brute-force search that's apparently even more thorough). |
| 21:22 |
[MTMatrix] |
<localhost> also how I can ask the engine no generate empty space blocks? Except mg limit |
| 21:23 |
erle |
localhost what do you mean |
| 21:23 |
erle |
Warr1024 funny how you end up at better optimizers and i end up at “wait this is so small, i can zip up the pixels and call it a day” |
| 21:23 |
MTDiscord |
<warr1024> Mapgen limit is the only way you can ask the engine not to generate mapblocks, as far as I know. |
| 21:23 |
[MTMatrix] |
<localhost> Just a... no save air blocks in map.sqlite |
| 21:23 |
erle |
what |
| 21:24 |
MTDiscord |
<warr1024> Sounds like a #minetest question more than a #minetest-dev one. |
| 21:24 |
MTDiscord |
<luatic> localhost: what |
| 21:24 |
MTDiscord |
<luatic> air blocks will be very compact in map.sqlite due to run-length encoding |
| 21:24 |
erle |
localhost, do you actually know how to join another channel? |
| 21:25 |
erle |
you keep asking questions here |
| 21:25 |
erle |
maybe you need help |
| 21:25 |
erle |
do you? |
| 21:26 |
[MTMatrix] |
<localhost> Okay. Sorry for wrong select channel |
| 21:27 |
erle |
localhost have you joined the correct one or do you need help with that? |
| 21:27 |
erle |
ah you have |
| 21:27 |
erle |
good |
| 21:33 |
|
v-rob joined #minetest-dev |
| 21:46 |
MTDiscord |
<mistere_123> sfan5, or others who know minetest's mapgen implementation: If every server step, if forceload a block, then the next server step un-forceload it, and forceload it again (or, rarely, forceload a different block), is this going to cause lag/ put undue strain on the engine? If I'm just changing a table that the engine checks at its lesiure by doing that, it shouldnt be laggy, I would think. But if calling forceload_block actually |
| 21:46 |
MTDiscord |
actively does something, then it could cause lag |
| 21:47 |
MTDiscord |
<mistere_123> /s/if forceload/I forceload |
| 21:52 |
MTDiscord |
<mistere_123> The reason is that I want to let an entity manage itself by preventing itself from ever being deleted while it lives. |
| 21:52 |
MTDiscord |
<mistere_123> /s/deleted/unloaded |
| 21:55 |
MTDiscord |
<warr1024> Interesting ... I've had similar needs, but I avoided the "what if I un-force-load and re-force-load again" problem by just having my own layer of forceload management where I only pass changes down to the engine. It turned out to be necessary as I wanted to have my own limit budget, and I wanted a fair distribution of the available resource in cases where demand exceeded budget. |
| 22:02 |
sfan5 |
@mistere_123 un-forceloading a block should cause it to be unloaded eventually, how fast I would have to check |
| 22:02 |
sfan5 |
I think a better design would be to only un-forceload the block if you know that the entity is really not there anymore |
| 22:03 |
MTDiscord |
<mistere_123> ok. This entity will be moving around, so the block could change |
| 22:04 |
MTDiscord |
<warr1024> you might have to forceload the new block, then wait for it to actually become loaded, and then move into that block, and then remove the old forceload. |
| 22:05 |
MTDiscord |
<warr1024> If you want to be able to move into the new block using normal physics movement, you might have to make sure it's pre-loaded by "leading" in front of the entity's movement based on its velocity. That's still no guarantee though as it can take arbitrarily long to emerge an unloaded block. |
| 22:17 |
MTDiscord |
<mistere_123> I figured it out, I think. Details in discord dev so as not to clog irc with code |
| 22:34 |
|
panwolfram joined #minetest-dev |
| 23:11 |
[MTMatrix] |
<Zughy> What to do with #10166? It's the oldest PR and OP has no activities on Github in the last two years |
| 23:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/10166 -- Unittest/collision by scrain777 |
| 23:13 |
MTDiscord |
<wsor4035> rip |
| 23:13 |
MTDiscord |
<wsor4035> could rerequest a review from sfan5 |
| 23:14 |
MTDiscord |
<wsor4035> or put it in the next meeting notes if those are going to be a thing |
| 23:48 |
[MTMatrix] |
<Zughy> sfan5 already has to deal with dual weilding, definitely doesn't need this one too |
| 23:48 |
MTDiscord |
<wsor4035> mainly saying it because they already reviewed it |
