Minetest logo

IRC log for #minetest-dev, 2021-08-17

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:49 v-rob joined #minetest-dev
01:19 lhofhansl joined #minetest-dev
01:25 v_rob joined #minetest-dev
01:27 vrob joined #minetest-dev
02:16 vrob joined #minetest-dev
04:00 MTDiscord joined #minetest-dev
04:02 vrob joined #minetest-dev
04:10 lhofhansl joined #minetest-dev
05:25 YuGiOhJCJ joined #minetest-dev
05:46 hecks joined #minetest-dev
05:47 hecks What would happen if one were to make the server "forget" a dynamically added asset immediately after broadcasting it to existing clients?
05:48 MTDiscord <GreenXenith> The server would probably let you send it again, but I dont think it would override the texture on already-connected clients
05:48 MTDiscord <GreenXenith> New clients would have the new texture though
05:49 hecks someone told me they're running a patch like this on their server and I wonder if there's any downsides to this
05:49 hecks they specifically edited the c++ code to remove the asset immediately after broadcast
05:49 hecks so that supposedly it isn't sent to new clients
05:49 MTDiscord <GreenXenith> Huh, that sounds like a downside to me
05:49 hecks they're using it for temp audio broadcast messages
05:49 hecks so it makes sense but
05:49 MTDiscord <GreenXenith> Ah, that is a decent usecase
05:49 hecks i wonder if the guy is forgetting something
05:50 hecks if not then maybe this could be a flag for dynamic add
05:50 MTDiscord <GreenXenith> Ideally youd just make the asset overridable on the serverside
05:50 MTDiscord <GreenXenith> with some way to clear it too
05:50 MTDiscord <GreenXenith> Immediate forgetting would then be doable with 2loc
05:50 hecks or just that, make the removal part of the lua API if the server is capable of this
05:50 vrob joined #minetest-dev
05:51 hecks i'll try to nudge the guy into completing that as a PR if this works
05:51 hecks that would solve one of the big logical problems with dynamic media
05:52 MTDiscord <GreenXenith> something like minetest.dynamic_add_media("bla"); minetest.dynamic_remove_media("bla"); to achieve what he's already doing
05:52 hecks yeah we don't have a remove yet do we
05:52 MTDiscord <GreenXenith> We do not
05:52 hecks might be worth just making that
05:52 MTDiscord <GreenXenith> with just a remove function you can both clear and override media
05:52 hecks the next logical problem to solve would be the broadcast thing; it should be possible to only add media for specific clients
05:52 MTDiscord <GreenXenith> The only remaining thing is updating the client
05:53 hecks since we already have a callback for a client
05:53 MTDiscord <GreenXenith> Would it be trivial to make the client dynamically unload media when remove is called?
05:53 hecks hmm
05:53 hecks you mean to forget it in ram?
05:53 hecks not trivial but not difficult i think
05:53 celeron55_ how the server is supposed to work is if you add dynamic media, clients coming afterwards would also get it, but in that case they don't and you have to manually make sure to not make them try to use the media that doesn't exist for them
05:53 hecks just a new packet or packet option
05:53 MTDiscord <GreenXenith> Whatever works as long as I can call remove and add again to replace an asset on the client
05:54 celeron55_ if it's single use then that isn't a problem
05:54 hecks yeah this is for ephemeral assets
05:54 hecks if you had removal and masking API, the burden would be on the modder to make sure illogical situations don't happen
05:55 hecks that is, that a client is not asked to use media they do not currently have in their set
05:55 hecks and with masking, it should implicitly be possible to send two clients two different versions of an asset
06:44 vrob joined #minetest-dev
07:13 calcul0n joined #minetest-dev
07:20 olliy joined #minetest-dev
08:21 appguru joined #minetest-dev
08:35 hecks_ joined #minetest-dev
08:48 entuland joined #minetest-dev
09:09 Fixer joined #minetest-dev
09:11 hecks joined #minetest-dev
09:33 sfan5 hecks: there's no downside to this, allowing this was planned from the beginning
09:33 hecks oh alright
09:37 sfan5 since 5.5 probably won't be soon I think I can get to implementing the dynamic_add_media v2 API in time
09:53 MTDiscord joined #minetest-dev
09:54 MTDiscord <IhrFussel> The server hecks was talking about was likely mine and what I can tell so far is that I can send the exact same file over and over again since I tell clients to not cache it and also delete it from the server cache the moment I send it so older clients will never know about those sent files when they connect
09:55 hecks hi fussel :o
09:56 hecks if this works, would you mind making a PR that makes forgetting media an actual lua API? that shouldn't be hard
09:56 hecks and it would make dynamic media actually viable for things
09:58 MTDiscord <IhrFussel> Sorry I never learned how to make PRs or use all the git stuff in general but the change was super simple http://sprunge.us/QQW3PK?diff
09:59 MTDiscord <IhrFussel> But that change also means that this behavior is hardcoded now
10:00 MTDiscord <IhrFussel> So I opted for entirely removing the ability to tell clients to cache dynamic sent stuff
10:01 MTDiscord <IhrFussel> sfan5 made that btw ^
10:03 MTDiscord <IhrFussel> It being an optional flag for dynamic_add_media() would be way better...also the option to send it to only 1 player and probably even a timestamp of sorts that tells the client to delete it from memory after X seconds
10:04 MTDiscord <IhrFussel> Or (if possible) right after listening to/viewing it
10:04 sfan5 deleting already used things from memory ha some bigger implicaitons #11531
10:05 ShadowBot https://github.com/minetest/minetest/issues/11531 -- Tile image cache (in RAM) should be reference-counted
10:05 sfan5 not so much a problem for sounds but for textures
10:08 MTDiscord <IhrFussel> I also wonder if dynamic media gets deleted from RAM the moment you leave the server OR (even worse) only when you exit MT
10:09 MTDiscord <IhrFussel> I recall there being a memory leak in the past when connecting to multiple servers and only going back to the main menu (it kept certain data in memory) and if this still exists it would be bad
10:20 behalebabo joined #minetest-dev
10:33 behalebabo joined #minetest-dev
10:38 specing_ joined #minetest-dev
12:32 calcul0n_ joined #minetest-dev
12:42 behalebabo joined #minetest-dev
12:52 behalebabo joined #minetest-dev
13:12 Kimapr joined #minetest-dev
13:30 MTDiscord <Warr1024> I just opened #11547.  It looks like something I MIGHT be able to try implementing myself, but that depends a lot on how wrong my assumption is that I understand what I'm reading in the code.
13:30 ShadowBot https://github.com/minetest/minetest/issues/11547 -- Screenshot Oversampling
13:31 MTDiscord <Warr1024> It came about from a discussion with rubenwardy about how to make high-res screenshot capabilities accessible to everyone in order to meet some demands for screenshot quality on ContentDB, and the multi-tile approach at least seemed promising.
13:32 MTDiscord <Warr1024> Anyway, I wanted to open up a public discussion about it rather than taking it on myself, partly because I think it may turn out that I'm not the right person to do this properly.
13:35 MTDiscord <Warr1024> What is the etiquette about slapping Supported by Core Dev on a thing that I myself opened?  Am I conflict-of-interest-ed out from doing that, or should I just do it since I obviously already support it else I'dn't've filed it in the first place...
13:42 sfan5 latter
13:48 behalebabo joined #minetest-dev
14:19 longerstaff13 joined #minetest-dev
14:29 Fixer joined #minetest-dev
15:09 Taoki joined #minetest-dev
15:20 Taoki joined #minetest-dev
15:39 nrz sfan5, you mean if we register a media later it will be pushed to clients ?
15:40 nrz it can be nice, except on android which is pretty slow compared to desktop
15:43 rubenwardy nrz: Minetest has dynamic media as of 5.3 (?), you can push media to clients after loading
15:43 Extex joined #minetest-dev
16:21 nrz oops 😄 i'm late
16:21 nrz then what is the new feature ?
16:24 Desour joined #minetest-dev
16:35 LW joined #minetest-dev
16:53 MTDiscord <IhrFussel> We were talking about a better implementation of it...right now it pushes the media to every supported client and there is also no way to specify whether or not the media should be added to the cache and also no way to tell the clients to delete it after pushing
16:55 MTDiscord <Warr1024> I'd love to see loaded media automatically GC'd when not used anymore, especially stuff made using texturemods.  It's very easy to accidentally memory-leak clients into oblivion with server mods, even given the sanest possible implementation for the given functionality.
16:56 MTDiscord <Warr1024> A good example: a skybox that has a starscape that's not random, but where the stars have specific positions based on predictable factors, i.e. allowing players to use astronomical tools to determine useful information about the world.  Interesting gameplay, but murder on the image cache, the way skyboxes need to be drawn right now.
16:56 MTDiscord <IhrFussel> Also right now it tries to push the media even for 5.2 clients which don't support it so there is no 100% way to actually check whether or not all players received it
16:57 MTDiscord <Warr1024> Yeah, you can tell if they did receive it but you'll never know if they will never receive it; they could just be taking arbitrarily long.
16:58 rubenwardy joined #minetest-dev
16:58 Desour well, you could use minetest.get_player_information to check whether the client supports it
16:58 MTDiscord <IhrFussel> What I mean is that the callback even gets called for 5.2 clients which cannot ever receive the media
16:59 MTDiscord <Warr1024> For my own purposes, I'd be inclined to use [png:, at least for images only, since at least that doesn't necessarily send data to every client immediately ... but that still doesn't solve the memory leak problem either.
16:59 MTDiscord <IhrFussel> sfan likely forgot that 5.2 already used protocol version 39
16:59 MTDiscord <Warr1024> The callback is not supposed to be called for clients that are not capable of receiving and loading the media; that sounds like a bug.
16:59 MTDiscord <Warr1024> It should try to send to them but fail to ever call the callback
16:59 Desour oh, the protocol version wasn't bumped?
17:00 MTDiscord <Warr1024> Death, taxes, and forgetting to bump protocol version.
17:00 sfan5 I don't remember why it wasn't but that cannot be fixed now or ever
17:00 MTDiscord <IhrFussel> The protocol version stayed the same for 3 releases
17:00 sfan5 probably because the initial implementation never had the callback
17:00 sfan5 so it wasn't important to know
17:00 Desour imo it makes more sense to also call the callback for older clients. the callback function might do other stuff
17:00 MTDiscord <Warr1024> There is no non-idiotic way to tell if clients actually support things.
17:01 MTDiscord <IhrFussel> The callback could just contain a bool for whether or not the client supports it
17:01 MTDiscord <Warr1024> We have opened discussion about how to ensure that modders have a way to determine if clients support things, the conclusion of the discussion was that bumping the protocol version at least once each release was the way to do it, and then we completely ignored that conclusion for all subsequent work.
17:02 MTDiscord <IhrFussel> Well many pushed for 'minetest.features' but AFAIK you cannot check the features of a connected client
17:02 MTDiscord <Warr1024> There are actually a bunch of new features that games with sane releng processes cannot use because of this.
17:03 sfan5 formspec version was bumped last version so you can still tell clients apart IIRC
17:03 MTDiscord <Warr1024> minetest.features is a train wreck too.  For instance, it can tell you something like whether the entity attachment feature exists but not whether it actually works yet.
17:03 MTDiscord <Warr1024> Well, that's a bad example because the answer for that is apparently always false.
17:03 sfan5 what is a better example then?
17:04 MTDiscord <Warr1024> but if you need to differentiate between, say, ent attachments that like 50% work and ones that like 90% work, you're SOL.
17:04 MTDiscord <Warr1024> This is why mods need to know what release version the client is running.
17:04 MTDiscord <Warr1024> If the client can send us a protocol version then they can send us a more fine-grained version and let server mods decide how much of it they can trust.
17:05 MTDiscord <IhrFussel> We have some funny minetest.features entries like 'pathfinder_works = true'
17:05 MTDiscord <Warr1024> Yeah, except that we'd need stuff like entity_attach_works, entity_attach_works_really, entity_attach_works_this_time_i_am_certain, etc.
17:06 MTDiscord <Warr1024> That specific subsystem has been broken, fixed, had regressions, been partially fixed, etc. through basically every release since at least 0.4.17, I think.
17:07 MTDiscord <Warr1024> Just tell the modders what version the client says it is and let the modders take responsibility for what to do with this information.  I don't care if it's via a proto version bump or just an extra get_client_version_string thing.
17:07 MTDiscord <IhrFussel> I think the main reason devs didn't want to make the exact version available was cause of forks? But other than Multicraft there are hardly any forks that use a completely different versioning scheme
17:08 MTDiscord <Warr1024> Forks are irrelevant; that's between the fork maintainer and the modders
17:08 MTDiscord <Warr1024> The MT core devs cannot accept responsibility for what forks do or do not do
17:08 MTDiscord <Warr1024> if a fork advertises a weird version, or one that collides with an official MT version, then that's between the fork maintainer and any mods that are deceived by that version and thus creates a worse experience for the user.
17:09 sfan5 forks are irrelevant therefore we should make forking as awful as possible?
17:09 MTDiscord <Warr1024> I don't see how this makes forking awful
17:10 sfan5 you don't see how forking is made awful when mods check the client version for the most trivial things and probably refuse to work if it looks funny?
17:10 MTDiscord <Warr1024> We are not trying to encourage or specifically support forks, that's out of our scope of concern.  If forks want to work with MT stuff then they're welcome to support the protocols.
17:10 sfan5 we are not?
17:10 sfan5 regardless this whole thing was already discussed, it's not happening
17:10 MTDiscord <Warr1024> Are you saying that we're avoiding allowing mod authors to sanely tell what features the client supports because to do so would be unfair to forks, and it's more important to be fair to forks than to our own modders?
17:11 sfan5 no, you interpreted that
17:11 MTDiscord <Warr1024> I suppose when it comes to being fork-friendly, you can't get more friendly than making forks MANDATORY in order to be able to sanely offer clients new features.
17:12 sfan5 being against exposing the client versions which makes forking awful does not imply that I'm against other solutions for this
17:13 MTDiscord <Warr1024> The situation as it stands right now is modders need to completely avoid using new features until nobody runs versions of MT that don't support them and can't be differentiated from versions that do, or else they'll get users complaining "X doesn't work" or "Y looks wrong" and be forced to say "you need to upgrade.  I'd love to be able to use a fallback or give you a warning about this, but my hands are tied."
17:14 MTDiscord <IhrFussel> A relatively simple 'solution' might be to send the minetest.features of the clients to servers...I mean it#s just  a few bytes no?
17:14 MTDiscord <Warr1024> You're against the only known solution.  If somebody has a less awful solution then I'm happy to consider it.  Since none has been forthcoming this entire time, we should proceed with the least-awful solution, at least considering that it's at least less awful than the non-solution we have.
17:14 sfan5 client versions strings is the only solution? you just named a second one yourself 5 minutes ago
17:15 MTDiscord <Warr1024> The cheapest solution was just a mandatory protocol version bump.  Essentially just because the wire format hasn't changed doesn't mean the interpretation hasn't changed, which is why we ratified the proto bump option at the time.
17:15 MTDiscord <Warr1024> #10933
17:15 ShadowBot https://github.com/minetest/minetest/issues/10933 -- Bump protocol version
17:16 sfan5 "Formspec version was bumped during 5.4.0 (b1ff04e) so identification is already possible and bumping the protocol unnecessary."
17:16 sfan5 oh look what I said 10 minutes ago
17:16 sfan5 looks like this whole issue doesn't exist
17:16 MTDiscord <Warr1024> Are we seriously going to have to argue about the policy EVERY release?
17:16 MTDiscord <IhrFussel> But this is still true for 5.2 and 5.3 then
17:17 MTDiscord <Warr1024> I'm not asking for 5.2 or 5.3 or 5.4.  I want us to do this for each future release.  We need to bump at least SOME thing.
17:17 MTDiscord <IhrFussel> Or just 5.2*
17:17 MTDiscord <Warr1024> It would be very much preferable if we could just bump ONE thing, instead of forcing mods to have to check a complex table of features and versions to figure out whether they're dealing with a particular release before or after a certain PR was merged
17:18 MTDiscord <Warr1024> Not being fork-hostile makes sense to me.  Unfortunately, not being modder-hostile ALSO makes sense to me so I just can't understand this decision.
17:18 MTDiscord <Warr1024> Especially since modders are essentially our intended users.
17:19 sfan5 so telling apart 5.3 and 5.4 wasn't the issue?
17:20 sfan5 weren't you just saying you not being able to do that is a problem?
17:20 MTDiscord <Warr1024> I don't know, maybe at the time it was.  The underlying problem still remains though, even if 5.4 had a workaround.
17:22 MTDiscord <Warr1024> What I need to be able to do is tell with reasonable reliability which release a client is running, or at least what official release equivalent they think they are compatible with.  I need a system for doing this that will apply to each future release as it is released.  I want to solve this ONCE and then just maintain the solution, rather than have to re-solve the problem each time.
17:22 MTDiscord <Warr1024> 5.3 to 5.4 is not the problem, it was an example of the problem
17:22 MTDiscord <Warr1024> 5.2 vs 5.3 is also an example of the problem, but as far as I can tell water under the bridge at the point the issue was raised.
17:23 MTDiscord <Warr1024> That's fine with me, because as long as all FUTURE versions can be managed, I will eventually end-of-support older versions anyway and differentiating between unsupported versions and other unsupported versions is not crucial to me.
17:24 MTDiscord <Warr1024> Each time a new MTE is released, I shift an old version off my support queue.  When 5.5 comes out, I will deprecate support for 5.3 in my mods.  I'll have to use a hack this time, of checking multiple versions of things, to tell the clients apart, but at least I'll be able to tell.
17:24 MTDiscord <Warr1024> When 5.6 comes out though, how can I be sure that I'll be able to tell 5.5 from 5.4?  When 5.7 comes out, how will I tell 5.5 from 5.6?
17:25 sfan5 ok so here's the thing which has been bothering the whole time:
17:25 sfan5 writing walls of text here will not make what you want magically come into existence, open an issue so it can be properly discussed
17:25 sfan5 (by more than 2 people that is)
17:26 MTDiscord <Warr1024> I thought we already had an issue for this.  Ruben's issue was the only one I found so far though, and it looks like he narrowed the scope down to the point where it basically accomplished nothing.
17:27 sfan5 "bump the proto ver each version" was written down by ruben after the first issue
17:27 MTDiscord <Warr1024> @rubywarden do you recall if there was another issue thread for the "bump protocol version at least once each release" somewhere?
17:28 sfan5 but the agreement that was there looked more like "let's do something" and not "let's do this specifically to me"
17:28 MTDiscord <Warr1024> I'm fine with a "let's do something" approach as long as we can agree on some "something"
17:28 sfan5 you mean #10368 right?
17:28 ShadowBot https://github.com/minetest/minetest/issues/10368 -- Increment formspec/protocol version at every release to indicate client version
17:29 MTDiscord <Warr1024> https://github.com/minetest/minetest/issues/10368#issuecomment-687886947 seemed to represent the consensus
17:29 MTDiscord <Warr1024> At least it was proposed by ruben and supported by paramat at the time
17:30 sfan5 is that both or one of them?
17:30 sfan5 (the versions)
17:31 MTDiscord <Warr1024> Part of the problem might be just that if there exists some "before each release" checklist, this policy change did not get merged into it at the time.  If such a thing exists then it seems like we can do a PR for this and go through the normal approval process...
17:31 sfan5 the release checklist is on the wiki, it did get added
17:31 MTDiscord <Warr1024> The "bump at least one version" thing doesn't thrill me but I'd consider it acceptable.  The "bump at least the protocol version, and maybe also the formspec version" kind of approach I think would make things a lot simpler for modders, but I'm not willing to die on that hill.
17:32 MTDiscord <Warr1024> Okay, ugh, the wiki...
17:32 MTDiscord <Warr1024> so how safe is it to assume that this will actually be done in 5.5?
17:32 sfan5 it literally was done for 5.4
17:33 sfan5 so I still do not understand why you making such a turmoil about this
17:33 sfan5 ...and considering the consensus is more or less that it would be reasonable to do it for 5.5 too
17:33 MTDiscord <Warr1024> It looks like the dev wiki has a "pending discussion" on it, but the discussion was closed on the GH side ... so where is it pending now?
17:33 sfan5 nowher
17:33 sfan5 e
17:34 MTDiscord <Warr1024> This bothers me because I thought the problem was fixed but apparently it's actually not.
17:35 MTDiscord <Warr1024> It seems like we need to either (1) remove the "pending discussion" thing on the dev wiki, or (2) open the discussion up somewhere.  Which one should we do?
17:35 sfan5 1 in any case
17:35 sfan5 I think it's worth quickly discussing what the consensus actually is too
17:36 MTDiscord <Warr1024> Here, or on a GH issue?  Does it need to be limited to core devs or something (e.g. like this is just a "ratification" process) or open to public comment (which it seems like we've already had quite a lot of though)
17:37 sfan5 here is not gonna work out because there's only you and me here (right now)
17:37 sfan5 there's no formal process so just open an issue, ping cordevs and make clear that one should be agreed upon
17:37 sfan5 perhaps even list thus far proposed options
17:37 MTDiscord <Warr1024> open a fresh issue, or reopen the old one where it seems the discussion hadn't fully concluded?
17:38 sfan5 idk, whichever
17:38 MTDiscord <Warr1024> Fresh seems like it'd be messy, but at least it'd clear out some of the existing drama...
17:39 MTDiscord <Warr1024> I can do a fresh one.  Do I just ping like a "core devs" role or something?  I'm not very familiar with the hub parts of github...
17:41 sfan5 there's such a role in fact but I'd just ping the people I know who are likely to respond
17:42 MTDiscord <Warr1024> Okay, you, ruben, and myself ... should I just pluck out people who responded to one of the issue threads before?
17:42 sfan5 sure
17:42 Krock yes
17:44 MTDiscord <Warr1024> Alright, thanks.  This sort of meta-issue has been a bit of a mess but hopefully we'll be able to get it all tidied up once and for all.
17:50 Krock is github not working properly? tab size shows as 2, rather than 4 as configured in .editorconfig
17:50 Krock interestingly limited to PRs
17:51 Krock interestingly limited to my PR
17:52 Desour not limited to you. #11538 also suffers this
17:52 ShadowBot https://github.com/minetest/minetest/issues/11538 -- Use utf-8 for the irrlicht clipboard by Desour
17:54 sfan5 when was remote media added? before 5.0 right?
17:54 rubenwardy yeah
17:55 sfan5 thanks
18:00 vrob Tab size used to show up to me as two spaces for the first indent, four afterwards, but now it's two everywhere.
18:00 Desour joined #minetest-dev
18:01 vrob Never mind, it's only two in PR diffs. Normal files show up as four for me
18:01 Krock will push https://krock-works.uk.to/u/patches/0001-Fix-inconsistent-integer-comparison-warnings.patch in 10 minutes
18:01 vrob Odd, all the same
18:01 Krock unless someone has more of them to fix
18:02 Krock yes. broken github.
18:02 vrob Crud, adding `?ts=2` to the URL makes tabs ONE space
18:04 sfan5 Krock: lgtm
18:04 sfan5 consider checking CI output to see if there are more
18:04 sfan5 but I don't think there were
18:08 Krock there's a bunch of SRP false-positives
18:10 Krock pushing
18:10 Krock done
18:13 sfan5 Krock: for #11548: that's not the problem at all, the client does this right
18:13 ShadowBot https://github.com/minetest/minetest/issues/11548 -- HUD: Do not assume int values on unknown HUD types by SmallJoker
18:14 sfan5 https://github.com/minetest/minetest/blob/6e8aebf4327ed43ade17cbe8e6cf652edc099651/src/script/common/c_content.cpp#L1999-L2000
18:14 calcul0n joined #minetest-dev
18:14 sfan5 the server will fall back to the default type (number) if it gets an unknown string passed
18:15 sfan5 (server = 5.4.0, client = whatever version)
18:16 Krock oh!
18:16 kilbith joined #minetest-dev
18:17 Krock that code would be for unknown server-side values
18:19 Krock isn't it also a problem when an additional field is added?
18:19 Krock hmm
18:19 sfan5 the code that processes the client even ends up in a per-type switch IIRC
18:19 sfan5 so that should be safe
18:20 Krock right. game.cpp
18:23 Krock what's expected in the error case? warning? silent ignore?
18:24 Krock unique warning perhaps
18:24 sfan5 warn would be useful imo
18:27 Alias joined #minetest-dev
19:14 Krock alright. PR updated.
19:14 Krock should be OK (TM)
19:51 entuland_ joined #minetest-dev
20:17 v_rob joined #minetest-dev
20:17 vrob joined #minetest-dev
20:40 sfan5 rejoice, I decided to work on dynamic_add_media v2 today and finished it
20:41 rubenwardy :O
20:42 MTDiscord <GreenXenith> PR when
20:52 sfan5 now
20:52 sfan5 took about 10 hours minus lunch, dinner and other short downtimes
20:54 MTDiscord <GreenXenith> If I enable ephemeral, can I send the same file twice?
20:55 sfan5 no
20:55 sfan5 the opposite, this is only allowed with to_player
20:55 MTDiscord <GreenXenith> "this" being, sending the same file twice?
20:55 sfan5 yes
20:55 sfan5 I assume you mean sending the same file with the same name and contents to different players
20:56 MTDiscord <GreenXenith> Well, mostly same name
20:56 MTDiscord <GreenXenith> For instance, to update an existing texture
20:56 sfan5 a file with the same name can never be sent to the same client twice (this includes media sent at startup)
20:57 sfan5 if you have some way to use a different texture (like on an entity) there's no restrictions
20:58 MTDiscord <GreenXenith> so to get the same result, id enable ephemeral and just increment the name whenever I want to update it?
20:58 sfan5 yes
20:58 sfan5 that works whether you set ephermal or not
20:59 MTDiscord <GreenXenith> @Warr1024 this solves the memory issue with your dynamic skybox, yes? (once you can drop support for earlier versions)
20:59 sfan5 though it's obviously a good idea as you won't ever be needing the thing again
20:59 sfan5 well nah
20:59 sfan5 the client still keeps all textures it has ever received in memory
20:59 sfan5 #11531 for that
20:59 ShadowBot https://github.com/minetest/minetest/issues/11531 -- Tile image cache (in RAM) should be reference-counted
20:59 MTDiscord <GreenXenith> Meh, true
21:00 rubenwardy so, will the only difference on old clients be that they still store the texture in the cache folder
21:00 MTDiscord <GreenXenith> This still at least reduces the memory usage for Warr's dynamic skybox
21:00 MTDiscord <GreenXenith> Since he has skyboxes per-player
21:01 MTDiscord <GreenXenith> So now he wont have to send every player updated skyboxes that they dont need
21:01 sfan5 rubenwardy: elaborate
21:02 MTDiscord <GreenXenith> Oh, and its also helpful that we have minetest.encode_png now, that will make using this much easier
21:03 MTDiscord <Warr1024> I'm using texturemods right now, and those are generated per-player on the client side anyway, so I'm already fine.
21:03 MTDiscord <GreenXenith> Ahh, true
21:03 MTDiscord <GreenXenith> My bad
21:03 MTDiscord <Warr1024> I expect that texturemods would be the way I'd do it anyway, so really it's only the GC that I'd need.
21:04 MTDiscord <Warr1024> I'm not sure if I'd have a use-case for pre-baking images as a png server-side or anything in this case.
21:04 rubenwardy Presumably `to_player` will work with 5.4.0 clients, as the server can just not tell the client about the texture. Would the only feature difference be that 5.4.0 clients will still store in cache/?
21:04 sfan5 non-caching will also work on 5.4
21:04 MTDiscord <GreenXenith> How?
21:04 rubenwardy forwards compat?! :O
21:05 MTDiscord <Warr1024> I could imagine myself using dynamic media for sounds, but I'd kinda rather have "audio texturemods" anyway :-D
21:05 sfan5 the 5.4 code is forward compatible by including a boolean in the packet indicating cache state, the 5.4 server only ever sends true
21:06 MTDiscord <GreenXenith> Huh, interesting. Y'all practically planned for this.
21:06 MTDiscord <GreenXenith> (Well, chances are you actually did)
21:51 v-rob joined #minetest-dev
22:36 specing_ joined #minetest-dev
22:42 Desour joined #minetest-dev
22:54 v-rob joined #minetest-dev
23:04 entuland joined #minetest-dev
23:06 v_rob joined #minetest-dev
23:24 AliasAlreadyTake joined #minetest-dev
23:28 MTDiscord <IhrFussel> This is exactly what I'm using right now on my 5.4 server to prevent any kind of client caching...I set that bool to false
23:29 MTDiscord <IhrFussel> And this allows me sending the exact same file infinite times too
23:30 MTDiscord <IhrFussel> Which is wasteful right now of course but it works
23:35 entuland joined #minetest-dev
23:51 entuland joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext