| Time |
Nick |
Message |
| 00:05 |
|
DI3HARD139 joined #minetest-dev |
| 00:10 |
|
Tmanyo joined #minetest-dev |
| 01:24 |
|
octacian joined #minetest-dev |
| 01:46 |
Zeno` |
merging #5130 |
| 01:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/5130 -- Re-add halo highlight by juhdanad |
| 01:49 |
|
Tmanyo joined #minetest-dev |
| 02:45 |
|
Derr joined #minetest-dev |
| 02:47 |
Derr |
I'm thinking about creating my first mod, a flower seed mod. Has a flower seed mod already been created? |
| 02:51 |
|
Miner_48er joined #minetest-dev |
| 02:54 |
Derr |
I was wanting one flower seed that would grow randomly into any type of flower |
| 03:01 |
rubenwardy |
Derr, #minetest is for mod discussion |
| 03:48 |
|
paramat joined #minetest-dev |
| 04:02 |
paramat |
wut? .. no way we can have another release soon, for many reasons |
| 04:04 |
thePalindrome |
Sure we can, just switch the versioning to be dates |
| 04:04 |
thePalindrome |
"Minetest-2017-01-29" "Minetest-2017-01-30" etc :P |
| 04:04 |
thePalindrome |
we can release every day :D |
| 04:04 |
rubenwardy |
it's a little early. I say we wait until March/April (3/4 months) |
| 04:22 |
|
Hunterz joined #minetest-dev |
| 04:24 |
paramat |
'a little' is quite an understatement |
| 04:28 |
Zeno` |
release already? |
| 04:28 |
Zeno` |
we haven't done anything yet lol |
| 04:29 |
paramat |
i've only just recovered from the last release :] |
| 04:29 |
paramat |
some are suggesting more frequent releases, 6 months is ok but 3/4 months is too frequent |
| 04:29 |
Zeno` |
I dunno... even MArch/April seems too soon to me |
| 04:29 |
Zeno` |
yeah |
| 04:30 |
paramat |
some reasons: |
| 04:31 |
paramat |
preparing for release takes a month and is very busy, exhausting and stressful, more frequent releases means a higher proportion of dev time is busy, exhausting, stressful |
| 04:32 |
thePalindrome |
Very much so |
| 04:33 |
thePalindrome |
I personally enjoy the "git", or "nightly" versionining |
| 04:33 |
Zeno` |
we're already nearly in march |
| 04:33 |
thePalindrome |
Where if you *really* want to, there is a pseudo-version to serve as a static commit |
| 04:34 |
paramat |
after a release devs are exhausted and need / deserve a month of holiday / relaxing / taking it easy, maybe some take a break. then we need to feel next release is a decent enough time away to not start worrying about it |
| 04:36 |
paramat |
so, 1 month relax, 1 month release preparation takes 2 months out of the cycle, there needs to be a decent time between to think, discuss, code, review, bugfix big new features |
| 04:36 |
paramat |
i would say 4 months minimum |
| 04:37 |
paramat |
so i would see 6 month cycle about right as a minimum |
| 04:37 |
Zeno` |
6 is better :( |
| 04:37 |
Zeno` |
4 months we have no time to properly debug the more complex PRs |
| 04:37 |
paramat |
yeah |
| 04:37 |
Zeno` |
i.e. give server ops a chance to field test them |
| 04:41 |
paramat |
software that updates too often is annoying anyway, feature creep, updating mods etc. |
| 04:44 |
paramat |
er well i mean MT specifically |
| 04:46 |
sofar |
the only way to make releases less work is to do them more often (not less often) |
| 04:46 |
sofar |
automate the shit out of it |
| 04:46 |
sofar |
this is how we do two full distro releases of clearlinux every day at my work |
| 04:49 |
paramat |
our releases need to be stable and bugtested, peopple can always use dev for daily versions (and do) |
| 04:49 |
paramat |
(people) |
| 04:52 |
sofar |
automating all the mechanical parts should be done though |
| 04:53 |
paramat |
yeah |
| 05:01 |
|
Derr left #minetest-dev |
| 06:06 |
|
nrzkt joined #minetest-dev |
| 06:12 |
|
Hunterz joined #minetest-dev |
| 06:59 |
nore |
#5143 |
| 06:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/5143 -- Fix anticheat resetting client position after the client is teleported. by Ekdohibs |
| 07:03 |
|
McNuggets[m] joined #minetest-dev |
| 07:05 |
|
McNuggets[m] left #minetest-dev |
| 07:18 |
nrzkt |
merging #5141 |
| 07:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/5141 -- Use fabs() instead of abs() by juhdanad |
| 07:24 |
nore |
nrzkt: hm, are newlines before & after functions even in headers, and even if there are no newlines between functions for the rest of the class? |
| 07:25 |
nore |
(I can add them of course) |
| 07:25 |
nrzkt |
when function has only 1 line it's not necessary, but when you inline it in three line it's desirable |
| 07:26 |
nore |
ok, should I also add newlines between the other functions of the class? |
| 07:31 |
nrzkt |
no |
| 07:31 |
nrzkt |
not your pr |
| 07:31 |
nore |
well, anyway, this is the second commit |
| 07:31 |
nore |
decide what you like best, I'll do it |
| 07:35 |
|
rom1504 joined #minetest-dev |
| 07:47 |
nrzkt |
it's good n,oer :) |
| 07:47 |
nrzkt |
nore, |
| 07:51 |
nore |
hmm, travis build is still unreliably failing |
| 07:52 |
nore |
looks like the network has problems |
| 08:10 |
|
Guest93432 joined #minetest-dev |
| 08:32 |
|
nrzkt joined #minetest-dev |
| 08:42 |
|
Darcidride joined #minetest-dev |
| 08:45 |
|
nrzkt joined #minetest-dev |
| 10:48 |
|
juhdanad joined #minetest-dev |
| 10:52 |
|
YuGiOhJCJ joined #minetest-dev |
| 10:54 |
|
Fixer joined #minetest-dev |
| 10:58 |
|
Guest93432 joined #minetest-dev |
| 11:09 |
|
DFeniks joined #minetest-dev |
| 11:25 |
|
nrzkt joined #minetest-dev |
| 11:41 |
|
Darcidride joined #minetest-dev |
| 11:55 |
|
Darcidride joined #minetest-dev |
| 12:07 |
|
proller joined #minetest-dev |
| 12:30 |
|
proller joined #minetest-dev |
| 12:37 |
red-001 |
I think I just found a great way to test how minetest responds to a bad connection https://jagt.github.io/clumsy/ |
| 12:39 |
red-001 |
tamper seems to be the only one that crashes mt |
| 12:46 |
|
Taoki joined #minetest-dev |
| 12:49 |
|
paramat joined #minetest-dev |
| 12:50 |
paramat |
please can anyone review / approve #5109 ? simple and well tested |
| 12:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/5109 -- OpenAL sound: Use a simpler distance model by paramat |
| 13:15 |
red-001 |
is player breath fully serversided now? |
| 13:16 |
sfan5 |
yes |
| 13:17 |
red-001 |
I suppose that means it can be marked as such in #2370 ? |
| 13:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/2370 -- [roadmap] Minetest 0.5.0 objectives |
| 13:17 |
nrzkt |
red-001: the cheat is fixed, for health it's a little bit more difficult, in the health PR i solved everything except collision which is a little bit more anoying (falling damages) |
| 13:22 |
|
lisac joined #minetest-dev |
| 13:27 |
|
juhdanad joined #minetest-dev |
| 13:43 |
|
Guest75671 joined #minetest-dev |
| 13:56 |
red-001 |
so for when is next release planned for? |
| 13:57 |
nrzkt |
we didn't found a solution, i will open an issue to permit to solve that, invoking all active coredevs |
| 13:59 |
juhdanad |
Why should the next release be soon? |
| 13:59 |
nrzkt |
not soon, but less far than previous interval (9 months) |
| 13:59 |
nrzkt |
4-5 months can be quite good |
| 13:59 |
nrzkt |
we have sufficient things in this release to permit a shorter cycle |
| 14:00 |
|
Player_2 joined #minetest-dev |
| 14:03 |
|
blaze joined #minetest-dev |
| 14:11 |
paramat |
see http://irc.minetest.net/minetest-dev/2017-01-30#i_4799743 for why a short cycle is not good. 6 months seems ok, that would be midsummer / midwinter (solstice) |
| 14:12 |
paramat |
devs don't want to think about release yet, we're still recovering from the last one :] |
| 14:16 |
VanessaE |
6 months between releases is too long |
| 14:25 |
red-001 |
#5078 anyone? |
| 14:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/5078 -- Remove guest nicknames by red-001 |
| 14:26 |
red-001 |
if it's not going to be merged then generating guest nicks should be fixed |
| 14:26 |
red-001 |
it's not ok that users have no idea why the server is kicking them |
| 14:27 |
VanessaE |
remove guest nicks. period. |
| 14:28 |
|
proller joined #minetest-dev |
| 14:29 |
nrzkt |
paramat: #5145 |
| 14:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/5145 -- Scheduling 0.4.16 |
| 14:29 |
nrzkt |
VanessaE: maybe but as paramat said, freeze needs some energy, because we don't have too many hands, else we should have a devel branch + master |
| 14:30 |
nrzkt |
nore, Zeno`, sfan5: ^ |
| 14:31 |
nrzkt |
sofar, ShadowNinja: ^ |
| 14:31 |
VanessaE |
my point is to skip the freeze and so on |
| 14:31 |
nrzkt |
no |
| 14:31 |
VanessaE |
if sfan5 can make a dev build in 10 mins or whatever, you can make a release without all the mishegas |
| 14:31 |
VanessaE |
no one said it has to be a "full" release. |
| 14:31 |
VanessaE |
just a snapshot |
| 14:31 |
nrzkt |
for a snapshot release take travis artifacts |
| 14:31 |
red-001 |
yeah nicknames are hardly a confusing part of minetest, if anything the way to enable mods is more confusing |
| 14:32 |
VanessaE |
nrzkt: the point is, you guys have to declare it "official" and be ready to make another snapshot if something's badly broken |
| 14:33 |
nrzkt |
official = responsibility on snapshot, whereas a snapshot is a alpha or beta release |
| 14:34 |
VanessaE |
no |
| 14:34 |
paramat |
releases have to be bugtested and high quality, people can use any commit of 0.4.15dev already if they want, that's no different to a snapshot release |
| 14:34 |
VanessaE |
"official" in this case just means "don't consider it an unofficial dev release made by some J. Random Forum User" :) |
| 14:34 |
VanessaE |
see where I'm going with that? |
| 14:34 |
nrzkt |
VanessaE: hopefuly there are some forkers which sells our product on android fo rthis :p |
| 14:35 |
VanessaE |
heh |
| 14:37 |
|
Taoki joined #minetest-dev |
| 14:39 |
paramat |
it's simple, i declare today's commit official! now just compile it and use it. what you're asking for is what people already do when they use 0.4.15dev |
| 14:39 |
VanessaE |
nono |
| 14:40 |
VanessaE |
now YOU just compile it and make a link to it on the main website :) |
| 14:40 |
nrzkt |
VanessaE: no |
| 14:40 |
VanessaE |
call it "latest official development build" or something |
| 14:40 |
nrzkt |
no, we don't have time to maintain that |
| 14:40 |
VanessaE |
no one says it has to supersede 0.3.15 |
| 14:40 |
VanessaE |
maintain what? |
| 14:40 |
VanessaE |
it takes like 5 minutes |
| 14:40 |
nrzkt |
no |
| 14:40 |
VanessaE |
I'm talking no maintenance |
| 14:41 |
nrzkt |
10 min compilation per platform + upload + publication ~ 2h |
| 14:41 |
VanessaE |
snapshot, compile, link, tell users "use at your own risk" or something |
| 14:41 |
paramat |
do we really need an issue for this? it's a bit early, i'm still exhausted from the last release |
| 14:41 |
VanessaE |
ok fine, 10 per platform AUTOMATED |
| 14:41 |
VanessaE |
jeez |
| 14:41 |
nrzkt |
VanessaE, celeron55: give rights to VanessaE (joke) |
| 14:41 |
VanessaE |
no. :P |
| 14:41 |
VanessaE |
I don't do windows |
| 14:42 |
paramat |
just use the daily builds made by trusted devs |
| 14:42 |
red-001 |
couldn't travis be made upload the builds it makes? |
| 14:42 |
nrzkt |
red-001: i hope it can build artifacts like gitlab |
| 14:43 |
VanessaE |
in the time we spent discussing this, it could have already been done :) |
| 14:43 |
red-001 |
that or someone could setup some sort of autobuild |
| 14:45 |
red-001 |
https://docs.travis-ci.com/user/deployment/releases/ |
| 14:46 |
paramat |
this makes no sense, just use a daily build, what you ask for is already done and available |
| 14:47 |
VanessaE |
if I were concerned for myself I'd just build it and be done with it, but I'm talking about my users here. |
| 14:47 |
VanessaE |
(and indeed I already do that) |
| 14:47 |
VanessaE |
but you can't expect Windows users to reach for daily builds. the best option for them is a snapshot made when the engine seems stable enough to do so |
| 14:47 |
red-001 |
looks like this is easy to do: https://docs.travis-ci.com/user/deployment/ |
| 14:47 |
VanessaE |
(which is thankfully 99% of the time) |
| 14:48 |
red-001 |
just have daily build |
| 14:48 |
red-001 |
and make them public |
| 14:48 |
red-001 |
of course still have releases |
| 14:49 |
VanessaE |
make them public and make them *sanctioned by the core devs* |
| 14:49 |
VanessaE |
the whole point is that a user should not look at one of these builds and think "ok this is some lame user-produced dev build that will probably break my machine" |
| 14:50 |
VanessaE |
but rather "this build is newer than 0.4.xx and is probably safe to use" |
| 14:51 |
Warr1024 |
it would also be nice to have an established standard for how often those nightlies are made (i.e. nightly, at least) |
| 14:52 |
red-001 |
could we have a vote on #5078? |
| 14:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/5078 -- Remove guest nicknames by red-001 |
| 14:52 |
VanessaE |
I don't advocate nightlies, just "seems stable enough to let users get feature X" |
| 14:53 |
Warr1024 |
I don't advocate nightlies, either; I'd rather just produce a build any time there's (1) a new commit, and (2) a build server not otherwise occupied. |
| 14:54 |
Warr1024 |
if features aren't stable enough to try out, then they probably shouldn't be committed into the mainline. |
| 14:54 |
VanessaE |
that much is true |
| 14:54 |
VanessaE |
(and usually is the case) |
| 14:56 |
nrzkt |
your users doesn't need snapshots. It's for experienced users. |
| 14:57 |
nrzkt |
do you use firefox nightly build and linux kernel RC 1 ? |
| 14:57 |
VanessaE |
I do not, but then again how often is firefox or chrome updated? every few weeks or so |
| 14:57 |
Warr1024 |
if it took 6 months for firefox to cut a new release, I probably would. |
| 14:58 |
VanessaE |
firefox/chrome is a terrible comparison if you're trying to avoid the idea of rapid releases :) |
| 14:58 |
red-001 |
I use firefox dev |
| 14:58 |
Warr1024 |
6 months is probably the upper bound for a release cycle, and Firefox has complexity about on par with an operating system, so they might be okay at that point. |
| 15:00 |
Warr1024 |
If making a release is such a painful process, then maybe the solution isn't so much making fewer releases as it is trying to fix the release process. |
| 15:01 |
VanessaE |
exactly. |
| 15:01 |
VanessaE |
making a release ought not take more effort than "make-release.sh" :P |
| 15:01 |
VanessaE |
(ok aside from the feature freeze and bug fixes that go in during that time, but that's not any more work than at any other time is it?) |
| 15:01 |
nrzkt |
in fact VanessaE it's not our problem if you use hardware node coloring and users doesn't have a compatible client |
| 15:02 |
VanessaE |
nrzkt: it's the users' problem if they won't update. |
| 15:02 |
nrzkt |
you break your user's experience, it's your problem as you are admin of your servers |
| 15:02 |
VanessaE |
but it's you guys' problem for making it *difficult to update* |
| 15:02 |
nrzkt |
this feature is not released, it's your problem |
| 15:02 |
Warr1024 |
it's not like (1) you have to freeze the whole tree to do testing (that's what branches are for), or that (2) development code is really untested. |
| 15:03 |
nrzkt |
it's in the current master branch, but client release is our responsibility and we don't trigger a release, then you are aware that the users cannot see it. We will not release it just because you make it available before the software was released officially |
| 15:04 |
nrzkt |
servers owners are responsible of their server part and user's experience, they know the client is not released, and they know without client release some features should wait a little bit |
| 15:06 |
paramat |
MT dev is never 'stable enough' during dev, it's either a full bugtested release or an unstable dev version, there's no inbetween state and any effort to obtain an inbetween state disrupts dev. i can understand players and server admin being impatient but that's too bad, either wait or use a daily build from someone you trust |
| 15:06 |
|
STHGOM joined #minetest-dev |
| 15:07 |
Warr1024 |
what is a "full bugtested" release? |
| 15:07 |
nrzkt |
in fact paramat it's just a full reviewed branch, not full tested as unit tests doesn't and can't currently cover 100% of our code |
| 15:07 |
Warr1024 |
do you have some kind of exhaustive test process you run before an official release? |
| 15:07 |
VanessaE |
well I give up. |
| 15:08 |
juhdanad |
Warr1024: before a release is out, there is one month of bugfixes. |
| 15:08 |
nrzkt |
feature freeze is the release candidat, this is the version experienced end users can use to help us to track bugs |
| 15:08 |
Warr1024 |
holy shit, that's a lot of bugs. |
| 15:09 |
paramat |
the release process could have more automation yes, but the stress and hard work of preparation and bugfixing is unavoidable. if you're not a core dev you do not know what it's like |
| 15:09 |
nrzkt |
Warr1024: one month of possible bugfixes |
| 15:09 |
Warr1024 |
what do you do with that month if you're lean on bugs? |
| 15:11 |
paramat |
well freeze is usually 2 weeks |
| 15:12 |
paramat |
but before that we have to sort out our priorities, work like crazy to get the features ready |
| 15:14 |
paramat |
so you have to start working towards the freeze point around a month before it |
| 15:18 |
|
Lunatrius` joined #minetest-dev |
| 15:35 |
|
Lunatrius joined #minetest-dev |
| 15:35 |
|
octacian joined #minetest-dev |
| 15:35 |
|
octacian joined #minetest-dev |
| 15:36 |
|
AnotherBrick joined #minetest-dev |
| 15:43 |
celeron55 |
the only way to achieve "in-between" releases is if non-developers start releasing them just based on some git versions |
| 15:43 |
red-001 |
huh minetest particles are a lot more complicated then I though |
| 15:43 |
VanessaE |
celeron55: which is already the case. |
| 15:43 |
VanessaE |
sfan5 makes frequent builds, but users don't see them as official enough to be worth the "risk". |
| 15:43 |
celeron55 |
the problem with that is that it's still not possible to have eg. proper dev-to-dev protocol compatibility |
| 15:44 |
celeron55 |
because doing it would just destroy the possibility to even develop stuff |
| 15:44 |
celeron55 |
so they inherently have the possibility of being broken |
| 15:46 |
celeron55 |
the way i would look at this is that the current half-a-year release cycle is probably the fastest that developers are comfortable with using current tools |
| 15:46 |
celeron55 |
if somebody wants a faster cycle, then make tools that make developers comfortable with such |
| 15:46 |
celeron55 |
eg. tools that make bugs appear faster |
| 15:47 |
celeron55 |
tools that allow measuring performance |
| 15:47 |
celeron55 |
stuff like that |
| 15:47 |
celeron55 |
tools that allow testing protocol, map and mod compatibility |
| 15:48 |
sfan5 |
proper dev-to-dev protocol compatibility is certainly possible |
| 15:48 |
sfan5 |
however it makes development much more cumbersome |
| 15:49 |
celeron55 |
in practice it's not |
| 15:54 |
|
nrzkt joined #minetest-dev |
| 15:56 |
|
YuGiOhJCJ joined #minetest-dev |
| 15:57 |
|
Darcidride joined #minetest-dev |
| 16:15 |
|
Hunterz joined #minetest-dev |
| 16:23 |
|
paramat joined #minetest-dev |
| 16:23 |
STHGOM |
noob question: #define CLIENT_PROTOCOL_VERSION_MIN 27 <--- is the # a comment? |
| 16:24 |
|
numZero joined #minetest-dev |
| 16:24 |
STHGOM |
oop |
| 16:25 |
VanessaE |
no, it's a C++ command |
| 16:25 |
VanessaE |
(well some other languages also) |
| 16:25 |
STHGOM |
ok, thanks |
| 16:26 |
paramat |
i'd like to merge #5045 #5138 #5143 in a moment. nore is 5143 ready to go? |
| 16:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/5045 -- Add "multiply" texture modifier which uses multiplication method for colorizing textures by sapier |
| 16:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/5138 -- Plantlike visual scale: Send sqrt(visual_scale) to old clients by paramat |
| 16:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/5143 -- Fix anticheat resetting client position after the client is teleported. by Ekdohibs |
| 16:26 |
|
Fixer_ joined #minetest-dev |
| 16:27 |
paramat |
just wondering if 5143 should have a little more time |
| 16:27 |
paramat |
yeah i'll merge the first 2 |
| 16:31 |
|
STHGOM joined #minetest-dev |
| 16:40 |
|
troller joined #minetest-dev |
| 16:41 |
paramat |
now merging the first 2 |
| 16:42 |
|
STHGOM joined #minetest-dev |
| 16:49 |
paramat |
merged |
| 16:59 |
|
juhdanad joined #minetest-dev |
| 17:03 |
juhdanad |
>proper dev-to-dev protocol compatibility is certainly possible< Do you mean that dev-to-dev compatibility is not necessary? |
| 17:05 |
sfan5 |
it's good practice not to break dev-to-dev compat completely |
| 17:05 |
sfan5 |
however there is no rule to enforce compat |
| 17:12 |
|
lisac joined #minetest-dev |
| 17:12 |
|
Miner_48er joined #minetest-dev |
| 17:17 |
sofar |
paramat: 5143 is :+1: from me |
| 17:22 |
red-001 |
could a issue be opened with a list of things that should be added for CSM? |
| 17:23 |
red-001 |
and make it a milestone or something |
| 17:23 |
paramat |
ok |
| 17:32 |
|
Darcidride joined #minetest-dev |
| 17:40 |
|
nrzkt joined #minetest-dev |
| 17:49 |
|
STHGOM joined #minetest-dev |
| 17:49 |
|
numzero joined #minetest-dev |
| 17:52 |
|
fwhcat joined #minetest-dev |
| 17:58 |
red-001 |
is using default arguments allowed by the code style guidelines/ oldest c++ standard supported? |
| 17:58 |
nrzkt |
you mean in cpp class definition ? |
| 17:59 |
sfan5 |
i'm pretty sure default args are supported in c++ since practically always |
| 17:59 |
red-001 |
so it's ok to use them? |
| 18:00 |
nrzkt |
red-001, you mean void toto(int a = 3) ? |
| 18:00 |
red-001 |
yeah |
| 18:00 |
nrzkt |
no problem to use it it's already done |
| 18:01 |
red-001 |
oh ok I just noticed it seemed to be used quite rarely in the code |
| 18:02 |
nrzkt |
because it's rearely needed in fact |
| 18:10 |
sfan5 |
^ |
| 18:16 |
|
troller joined #minetest-dev |
| 18:25 |
|
Krock joined #minetest-dev |
| 18:26 |
paramat |
#5148 |
| 18:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/5148 -- Mgvalleys: Fix missing decorations at horizontal chunk borders by paramat |
| 18:36 |
|
STHGOM joined #minetest-dev |
| 18:36 |
|
STHGOM joined #minetest-dev |
| 18:40 |
|
STHGOM joined #minetest-dev |
| 18:42 |
|
STHGOM joined #minetest-dev |
| 18:42 |
|
STHGOM joined #minetest-dev |
| 19:33 |
|
Warr1024 joined #minetest-dev |
| 19:34 |
|
Warr1024 joined #minetest-dev |
| 19:45 |
red-001 |
#5149 |
| 19:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/5149 -- [CSM] Add `get_node` and `get_node_or_nil` by red-001 |
| 19:47 |
nrzkt |
red-001, you are so fast |
| 19:47 |
nrzkt |
i'm working on mod storage |
| 19:48 |
juhdanad |
The development has been faster since the CSM branch opened. |
| 19:49 |
nrzkt |
CSM only red-001 and me are working on it fully, and mainly it's porting server side code to client |
| 19:49 |
|
STHGOM joined #minetest-dev |
| 19:51 |
red-001 |
well we are starting to run out of easy to port stuff |
| 19:55 |
juhdanad |
Then comes the good part! (solving exciting programming problems) |
| 19:57 |
red-001 |
well if you have time you are welcome to make a PR to the CSM branch |
| 19:58 |
red-001 |
it would be good to get more people working on it |
| 19:59 |
red-001 |
nrzkt, maybe there should be a general todo list for csm? |
| 19:59 |
juhdanad |
I don't really like Lua (I don't know the types...) |
| 19:59 |
nrzkt |
red-001, it's in 5088 |
| 19:59 |
nrzkt |
it seems your follow it, i suspect :) |
| 19:59 |
red-001 |
isn't that just for merging the PR? |
| 19:59 |
nrzkt |
juhdanad, i prefer C++ too but it's required |
| 20:00 |
red-001 |
there seems to be quite a bit thats not there |
| 20:00 |
nrzkt |
red-001, yeah, but it's the first PR roadmap, after merge we should add another branch maybe to continue working |
| 20:00 |
nrzkt |
and it's the main discussion process, if many users talk onto it to add new ideas i can add a future list |
| 20:00 |
nrzkt |
having all information on it can be more useful than multiple PR non updated |
| 20:01 |
red-001 |
ohh so csm is going to be developed parallel to master? |
| 20:01 |
|
STHGOM joined #minetest-dev |
| 20:01 |
nrzkt |
atm yes, 0.4.16 should be released without it as it seems |
| 20:05 |
nrzkt |
i have the first pass for modstorage |
| 20:05 |
red-001 |
nice |
| 20:06 |
red-001 |
nrzkt, released without the server side of csm or all of it? |
| 20:07 |
nrzkt |
i'm doing it full server side |
| 20:07 |
nrzkt |
it works perfect, it just needs a proper persistent storage now |
| 20:09 |
|
STHGOM joined #minetest-dev |
| 20:09 |
|
STHGOM joined #minetest-dev |
| 20:10 |
|
proller joined #minetest-dev |
| 20:22 |
nrzkt |
update #5131, now we have private mod storages |
| 20:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/5131 -- Add ModStorage Lua API by nerzhul |
| 20:22 |
nrzkt |
only persistence is missing |
| 20:27 |
|
proller joined #minetest-dev |
| 20:40 |
|
STHGOM joined #minetest-dev |
| 20:40 |
|
STHGOM joined #minetest-dev |
| 20:43 |
|
STHGOM_ joined #minetest-dev |
| 20:46 |
sofar |
since it's key-value based, are you going to do a json type thing like player attributes? |
| 20:46 |
sofar |
the problem I see is with mods putting in binary data |
| 20:47 |
|
STHGOM_ joined #minetest-dev |
| 20:47 |
Fixer |
don't forget that problem regarding keys/other labeling |
| 20:47 |
sofar |
you'd end up using e.g. dbm/gdbm |
| 20:48 |
sofar |
what problem? |
| 20:49 |
sofar |
Fixer: oh, itemstack meta |
| 20:49 |
Fixer |
yes |
| 20:49 |
sofar |
Fixer: that's entirely unrelated |
| 20:49 |
Fixer |
ok |
| 21:00 |
red-001 |
nrzkt, could you add global storage? |
| 21:10 |
|
Fixer joined #minetest-dev |
| 21:14 |
sofar |
for mods? why would you? |
| 21:19 |
|
STHGOM joined #minetest-dev |
| 21:19 |
|
STHGOM joined #minetest-dev |
| 21:24 |
sofar |
nrzkt: red-001: thinking aloud about that problem |
| 21:24 |
sofar |
I don't think you want to |
| 21:24 |
sofar |
if mods expose an API to modify their local storage, then great, let other mods have access to it |
| 21:25 |
sofar |
but I like to write my mods in a way that when I do want other mods to access certain functions, I clearly only give access out to those parts |
| 21:25 |
sofar |
e.g. I'll keep most of my data `local` |
| 21:28 |
red-001 |
i was thinking of a separate global storage |
| 21:29 |
red-001 |
so there is mod storage for every mod and one global storage for every world |
| 21:31 |
sofar |
I fail to see, outside of mods, who would use that |
| 21:32 |
|
Taoki joined #minetest-dev |
| 21:33 |
|
STHGOM joined #minetest-dev |
| 21:49 |
nrzkt |
i agree with sofar |
| 21:57 |
red-001 |
well I suppose you are right there isn't that much use for it |
| 21:58 |
sofar |
well my point is that -per definition- there are no uses for it |
| 21:58 |
sofar |
everything is a mod |
| 21:58 |
sofar |
there are no users outside of mods |
| 21:58 |
sofar |
the only reason to consider it would be to have some 'shared' storage |
| 21:58 |
sofar |
but tbh, I don't think that is a good idea |
| 21:59 |
sofar |
let me rephrase: that's a terrible idea :) |
| 22:01 |
nrzkt |
sofar, i don't think so, i think mods should expose an API to use their internal storage if needed |
| 22:01 |
sofar |
exactly my point |
| 22:01 |
nrzkt |
sofar, are you okay with API exposed by #5131 ? |
| 22:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/5131 -- Add ModStorage Lua API by nerzhul |
| 22:02 |
sofar |
actually, can I comment? |
| 22:03 |
sofar |
so if mod A calls an API function in mod B |
| 22:03 |
sofar |
and B uses minetest.store_data() in that call |
| 22:03 |
nrzkt |
refresh the PR |
| 22:03 |
nrzkt |
store_data doesn't exist anymor |
| 22:03 |
sofar |
ahhh |
| 22:04 |
nrzkt |
now mods should call at loading time minetest.get_mod_storage() to get their private storage |
| 22:04 |
nrzkt |
and after: storage:set(k,v) and storage:get(k) |
| 22:04 |
sofar |
oh, you didn't squash |
| 22:04 |
sofar |
yes! that's what I expected to see |
| 22:04 |
nrzkt |
no, you are right, as i rewrote everything i should do it |
| 22:05 |
|
STHGOM joined #minetest-dev |
| 22:05 |
|
STHGOM joined #minetest-dev |
| 22:06 |
nrzkt |
it's now squashed, not problem |
| 22:06 |
nrzkt |
sofar, how do we store values ? a file per mod in a specific folder specified by configuration ? |
| 22:07 |
sofar |
well |
| 22:07 |
sofar |
there's only ever 1 store per mod, right? |
| 22:07 |
nrzkt |
yes |
| 22:07 |
sofar |
so I would do a mod_storage folder |
| 22:07 |
sofar |
and then underneath there 1 file per mod |
| 22:08 |
nrzkt |
in world_dir for server side then |
| 22:08 |
sofar |
correct |
| 22:08 |
nrzkt |
perfect |
| 22:08 |
sofar |
what about the format of the store? |
| 22:08 |
sofar |
json? can that handle arbitrary data values? |
| 22:08 |
nrzkt |
yes, like we do with player:set_attribute: ) |
| 22:09 |
sofar |
if that is safe for binary data then I'm OK |
| 22:09 |
sofar |
does it handle arrays and hashes properly? |
| 22:09 |
sofar |
can I insert nested tables? |
| 22:09 |
nrzkt |
as it seems there is no problem |
| 22:10 |
nrzkt |
as all my tests in player:set_attribute permit to set every type into string and next json |
| 22:10 |
nrzkt |
json with a single k,v level, we don't need to rewrite all as a pure json, it's useless, right ? |
| 22:12 |
sofar |
can I set a value to mintest.write_json({x = 1, y = { a = 3, b = 4}}) |
| 22:12 |
nrzkt |
you can to use write_json serializer to convert lua to json ? |
| 22:12 |
sofar |
or, can I set a value to {x = 1, y = { a = 3, b = 4}} ? |
| 22:13 |
sofar |
e.g. pass a table as value? |
| 22:13 |
sofar |
it's ok if I have to serialize it first |
| 22:13 |
sofar |
just should be documented |
| 22:13 |
nrzkt |
with player extra attributes it's possible, the object is converted as a string and the string is back converted to object by lua it's implicit |
| 22:14 |
nrzkt |
i think this can be used there, and also we should be careful about this serialization t oavoid performance penalty |
| 22:15 |
sofar |
yes, if we avoid internal serialization it's better |
| 22:15 |
sofar |
let the mods handle dangerous data themselves first |
| 22:16 |
nrzkt |
yes |
| 22:24 |
sofar |
this way, one day we'll get modifyable labels on itemstacks, too ;) |
| 22:27 |
|
STHGOM joined #minetest-dev |
| 22:27 |
|
STHGOM joined #minetest-dev |
| 22:38 |
|
STHGOM_ joined #minetest-dev |
| 22:41 |
nore |
ah, about #5143: I'm nit sure whether I should add some code as well to prevent incorrect on_cheat being reported because the client had lag, what do you think? |
| 22:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/5143 -- Fix anticheat resetting client position after the client is teleported. by Ekdohibs |
| 22:41 |
|
proller joined #minetest-dev |
| 22:42 |
red-001 |
I would say so as mods might use on_cheat to punish players |
| 22:59 |
|
proller joined #minetest-dev |
| 23:22 |
|
STHGOM joined #minetest-dev |
| 23:25 |
|
DI3HARD139 joined #minetest-dev |
| 23:26 |
|
STHGOM joined #minetest-dev |
| 23:26 |
|
STHGOM joined #minetest-dev |
| 23:28 |
|
STHGOM_ joined #minetest-dev |
| 23:28 |
|
kaeza joined #minetest-dev |
| 23:32 |
|
STHGOM joined #minetest-dev |
| 23:53 |
|
STHGOM_ joined #minetest-dev |
| 23:54 |
|
ircSparky__ joined #minetest-dev |
