Time |
Nick |
Message |
00:00 |
|
Taoki joined #minetest-dev |
00:04 |
|
Wuzzy joined #minetest-dev |
00:06 |
|
hecks joined #minetest-dev |
00:07 |
hecks |
hi, what does the content_cao.cpp / GenericCAO::getPosition() / if(m_matrixnode) block do? |
00:09 |
hecks |
I commented it out and it fixed #9139 , everything seems to work without it |
00:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/9139 -- Server receives an incorrect player position after attaching to an entity |
00:16 |
hecks |
https://github.com/minetest/minetest/blob/c1e01bc638637efa788b5698238a465406bc3f5e/src/client/content_cao.cpp#L412 |
00:18 |
hecks |
hm okay, so the detach point is now wrong if the "vehicle" moves, but the yanker is definitely fixed |
00:31 |
hecks |
ah, it's for moving the player with the parent, but it's also responsible for the bug somehow |
00:34 |
|
erlehmann joined #minetest-dev |
00:40 |
|
appguru1 joined #minetest-dev |
01:02 |
|
Lone_Wolf joined #minetest-dev |
01:11 |
|
benrob0329 joined #minetest-dev |
01:37 |
|
ANAND joined #minetest-dev |
01:48 |
|
appguru joined #minetest-dev |
01:49 |
appguru |
picked #9727 up again and implemented my APIs from the last post, will polish & push later |
01:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/9727 -- Implement generating & storing of inventory images by appgurueu |
01:49 |
|
paramat joined #minetest-dev |
01:53 |
paramat |
skyliner_369 please stop posting off-topic in this channel. this channel is very strictly for MTEngine and MTGame development only, not modding, advice or questions. if in doubt ask in the other channels. sorry to be strict but, we have to be |
01:55 |
|
oil_boi joined #minetest-dev |
02:15 |
|
Miner_48er joined #minetest-dev |
02:50 |
|
oil_boi joined #minetest-dev |
02:54 |
|
lisac joined #minetest-dev |
04:15 |
|
lisac joined #minetest-dev |
04:45 |
|
Lunatrius` joined #minetest-dev |
06:20 |
|
nerzhul joined #minetest-dev |
06:21 |
|
calcul0n joined #minetest-dev |
07:06 |
|
ANAND joined #minetest-dev |
07:26 |
|
NetherEran joined #minetest-dev |
07:36 |
|
erlehmann joined #minetest-dev |
08:00 |
|
Darcidride joined #minetest-dev |
08:00 |
|
ShadowNinja joined #minetest-dev |
08:00 |
|
Beton joined #minetest-dev |
09:14 |
|
search_social joined #minetest-dev |
10:00 |
|
YuGiOhJCJ joined #minetest-dev |
10:22 |
ANAND |
Core-dev inputs required: https://github.com/minetest/minetest/pull/7924#discussion_r436252386 |
10:41 |
|
Fixer joined #minetest-dev |
10:43 |
|
NetherEran joined #minetest-dev |
11:17 |
|
proller joined #minetest-dev |
11:44 |
Krock |
ANAND: three lines could be added to make it backwards compatible |
11:50 |
Krock |
other than and the possibly superfluous examples in the documentation, that the PR looks good. |
11:53 |
Krock |
ANAND: https://github.com/minetest/minetest/pull/7924/files#r436096986 |
12:18 |
nerzhul |
then, i'm lost, the event published to MT is exactly the same in wayland & X11 BUT mt (ingame) doesn't properly recognize keys. when i add some debug code i see that keycode is pushed to isKeyDown std::list, but on the future get it's not in the list, very disapointing |
12:29 |
Krock |
ANAND: I don't understand " and the example is required at all". Are you saying that the example is a requirement? |
12:38 |
|
NetherEran joined #minetest-dev |
12:56 |
|
Icedream joined #minetest-dev |
13:09 |
|
jas_ joined #minetest-dev |
13:09 |
jas_ |
#7924 |
13:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/7924 -- Allow binding dig, place actions to keys; remove LMB/RMB hardcoding by ClobberXD |
13:09 |
jas_ |
thanks for the approval rubenwardy. |
13:09 |
|
jas_ left #minetest-dev |
13:12 |
rubenwardy |
#10000 |
13:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/10000 -- Recalc mesh normals for CAOs by dcbrwn |
13:22 |
sfan5 |
now that's a good pr |
13:34 |
ANAND |
:tada: |
13:34 |
ANAND |
Krock: Sorry, I meant "not required at all" :) |
13:36 |
Krock |
ah okay. In this case it might be better to shorten it to a brief list. Also to keep the Lua API file a bit smaller in size |
13:37 |
ANAND |
Agreed |
13:41 |
|
Wuzzy joined #minetest-dev |
13:42 |
ANAND |
Shall I keep the joystick LMD/RMB unhardcoding (which I said I'll complete in 7924) for later? I haven't ever seen the joystick code, and it'll take me some time to get acquainted enough to work with it. |
13:42 |
ANAND |
Ideally, I'd prefer someone who's already familiar with joystick handling to take it up if possible. |
13:43 |
ANAND |
But if not, I can try. |
13:44 |
Krock |
joystick would fit better into another PR |
13:44 |
ANAND |
Ok, thanks |
13:46 |
ANAND |
The original control_bits docs was cluttered, IMO, and hence I added line-breaks for each bit. Shall I revert those changes? |
13:49 |
Krock |
up to you. fine either way |
13:53 |
ANAND |
I'll leave it modified then |
13:54 |
ANAND |
Krock: I've attended to both your requested changes (docs and rundata.punching) |
13:54 |
ANAND |
both of* |
13:56 |
|
Darcidride joined #minetest-dev |
13:56 |
|
erlehmann joined #minetest-dev |
13:58 |
ANAND |
Btw, did we come to a consensus regarding the breakage of `repeat_rightclick_interval` setting yet? |
14:06 |
Krock |
meh, probably fine. |
14:06 |
ANAND |
Ok, fine |
14:08 |
Krock |
ANAND: I cannot eat apples |
14:09 |
ANAND |
checking |
14:11 |
Krock |
also reported here https://github.com/minetest/minetest/pull/7924#issuecomment-640058175 |
14:15 |
rubenwardy |
lool |
14:16 |
rubenwardy |
my testing involved playing a game for a while, didn't test on_use |
14:17 |
Krock |
rubenwardy: how much do you know about Android development? I was told that this could be updated using a merge request https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/net.minetest.minetest.yml |
14:18 |
rubenwardy |
I was a professional Android dev for 10 months :D |
14:18 |
rubenwardy |
well, part time |
14:19 |
rubenwardy |
that doesn't look like Android, looks like f-droid specific confis |
14:20 |
Krock |
"yml" file. could be some sort of build configuration |
14:21 |
Krock |
looks like it also needs a versionCode bump from 24 to 26 in the source code |
14:22 |
rubenwardy |
we already done |
14:22 |
Krock |
nice |
14:22 |
rubenwardy |
it's done by the release script |
14:24 |
rubenwardy |
Meeting today? |
14:24 |
rubenwardy |
also, 5.3.0 freeze date decision |
14:25 |
Krock |
yes |
14:29 |
ANAND |
Wait, what? Talking about feature freeze already? |
14:29 |
ANAND |
I thought the 5.3.0 release was months later :O |
14:29 |
rubenwardy |
no, it was planned 1 or 2 months after 5.2.0 |
14:29 |
rubenwardy |
due to Android support |
14:30 |
ANAND |
Ahh, ok |
14:50 |
|
NetherEran joined #minetest-dev |
15:12 |
|
hecks joined #minetest-dev |
15:30 |
|
lisac joined #minetest-dev |
15:45 |
|
appguru joined #minetest-dev |
15:45 |
appguru |
Is there something like mod security for CSM? |
15:52 |
rubenwardy |
yes, it;s also much more restructive |
15:52 |
rubenwardy |
there's no whitelisted mods |
15:53 |
rubenwardy |
it also ignores secure.enable_security |
15:53 |
rubenwardy |
worth checking those things though |
15:55 |
appguru |
So where can clientmods write? |
15:55 |
rubenwardy |
no where |
15:55 |
appguru |
I have implemented the storing thing for my inventory image generation PR using CSM, but I want to "secure" it somehow. |
15:56 |
rubenwardy |
they have mod storage |
15:56 |
rubenwardy |
but can't directly read or write |
15:56 |
appguru |
:/ |
15:56 |
appguru |
So I'll guess this will be a bit harder than expected |
15:56 |
rubenwardy |
merging #9998 in 10 |
15:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/9998 -- Add HTTP API to main menu by rubenwardy |
15:56 |
rubenwardy |
sfan5, Krock: technically, we've never exceeded a merge time line |
15:57 |
rubenwardy |
we never say what base "10" is in |
15:57 |
rubenwardy |
merged an hour later? 10 is obviously base 60 |
15:57 |
appguru |
I think I'll just let 'em write to their mod folder |
15:57 |
sfan5 |
rubenwardy: hmmm |
15:57 |
rubenwardy |
CSMs don't have a mod folder at run time iirc, they're loaded into a virtual filesystem |
15:57 |
rubenwardy |
iric |
15:58 |
sfan5 |
correct |
16:02 |
appguru |
IRIP |
16:02 |
appguru |
Can I somehow determine the currently running CSM? |
16:04 |
appguru |
The engine usually does some register magic for mods but this doesn't seem to work for CSM |
17:00 |
Krock |
Today's meeting points: https://dev.minetest.net/Meetings <- nore, rubenwardy, sfan5, ( paramat ?) |
17:00 |
rubenwardy |
trivial bug fix: |
17:00 |
rubenwardy |
!title https://github.com/rubenwardy/minetest/commit/3c9d2cc8f608f500b11f65c5162381bf3ea48d4a |
17:00 |
ShadowBot |
rubenwardy: Use correct extension for ContentDB thumbnails · rubenwardy/minetest3c9d2cc · GitHub |
17:01 |
Krock |
lgtm |
17:01 |
rubenwardy |
merging in 10... |
17:01 |
rubenwardy |
(that helper function isn't technically correct if the filename doesn't contain a dot, but it will always contain a dot) |
17:01 |
Krock |
Meeting in 30 minutes, perhaps? |
17:02 |
|
Fixer joined #minetest-dev |
17:03 |
rubenwardy |
actually, merging a bit later |
17:03 |
rubenwardy |
afk |
17:03 |
rubenwardy |
30 minutes is fine |
17:04 |
rubenwardy |
I should probably refactor the CDB code in the main menu at some point, and separate the logic from the dialogs :? |
17:07 |
Krock |
if it's generic code, yes. else I don't see much need for such efforts |
17:11 |
sfan5 |
> Translations and minetest.conf.example need updating. Volunteers? |
17:11 |
sfan5 |
what does this mean? |
17:11 |
Krock |
well, so that translators get some time to translate the new strings until the next release happens |
17:12 |
sfan5 |
oh that |
17:12 |
Krock |
and minetest.conf.example can be done in the same step |
17:12 |
sfan5 |
that's usually done when freeze starts |
17:12 |
sfan5 |
and now that the wiki properly outlines the steps anyone could do that |
17:12 |
Krock |
then it'll serve as a reminder |
17:12 |
sfan5 |
(but I don't mind being the one to do it) |
17:14 |
appguru |
I currently have a working CSM store_texture(texture, path) function |
17:14 |
appguru |
Which I want to make "secure" - it shouldn't be able to write anywhere except for the CSM modpath |
17:21 |
Krock |
void ScriptApiSecurity::initializeSecurityClient() |
17:21 |
Krock |
s_security.cpp |
17:21 |
Krock |
for path protection, use bool ScriptApiSecurity::checkPath in your functions |
17:23 |
appguru |
Krock: this doesn't work for CSM |
17:23 |
Krock |
then you need to implement it |
17:24 |
appguru |
Yeah but I have little clue |
17:24 |
sfan5 |
the fundamental issue is that CSM should have no direct disk access at all |
17:25 |
appguru |
It is not direct |
17:25 |
appguru |
It's just retrieving textures from the TextureSource & storing 'em |
17:26 |
appguru |
But still, I'd like to keep those stored textures where they belong |
17:26 |
Krock |
or get the hash of the media and copy the cached files over |
17:30 |
Krock |
>> Meeting check-in goes here |
17:31 |
Krock |
rubenwardy: you might want to push your CDB patch |
17:32 |
rubenwardy |
pushing |
17:32 |
rubenwardy |
done |
17:33 |
Krock |
> Allow or deny UTF-8 characters in the source code |
17:33 |
Krock |
This is about a potential change of the code stylig rules |
17:33 |
Krock |
if characters should be allowed - which ones? |
17:36 |
Krock |
> Do not use characters in C++ files from outside the ASCII character set. |
17:36 |
Krock |
I'd suggest "Prefer ASCII characters as long it does not compromise readability.". |
17:40 |
Krock |
objections? |
17:43 |
appguru |
Imma reopen my revert PR then huh |
17:44 |
appguru |
#9828 |
17:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/9828 -- Revert "Replace non-ASCII characters in gameui debug display code" by appgurueu |
17:44 |
appguru |
I'd say: |
17:44 |
appguru |
- extended ASCII should always be allowed |
17:45 |
sfan5 |
what exactly is "extended ascii"? |
17:45 |
appguru |
8-bit ASCII |
17:45 |
appguru |
https://en.wikipedia.org/wiki/Extended_ASCII |
17:45 |
appguru |
It contains "°" for example |
17:46 |
sfan5 |
so ISO 8859-1? |
17:47 |
appguru |
Yeah, aka Latin-1 |
17:47 |
appguru |
Although there appear to be small differences from what the wiki article says |
17:47 |
|
NetherEran joined #minetest-dev |
17:49 |
sfan5 |
There are many extended ASCII encodings (more than 220 DOS and Windows codepages). EBCDIC ("the other" major 8-bit character code) likewise developed many extended variants (more than 186 EBCDIC codepages) over the decades. |
17:49 |
sfan5 |
"""small""" differences |
17:50 |
sfan5 |
but since source files are not encoded in latin-1 I don't think that proposal makes much sense |
17:52 |
sfan5 |
IMO it'd make more sense to allow all unicode (or the inverse: only ascii) |
17:52 |
appguru |
I'd allow all Unicode TBH |
17:52 |
appguru |
Except for some emoji poorly supported by fonts probably |
17:52 |
sfan5 |
unicode use could be restricted to the BMP to exclude e.g. emoji but it's not like anyone would use those anyway |
17:53 |
hecks |
Not every programming or terminal font has every character |
17:53 |
hecks |
and when trying to display one, programs will typically pick a fallback character from a different font, potentially ruining monospace |
17:53 |
appguru |
A "terminal font" should at the very least have full Latin-1 support. |
17:54 |
hecks |
They probably do; the situation is more sketchy with character sets like shift-jis |
17:54 |
appguru |
My terminal fonts usually even support color emoji, but that's on a different note. |
17:56 |
hecks |
"all unicode" involves not just emoji, but also RTL marks and zalgo |
17:57 |
hecks |
a better question is, what do you need unicode in code for? |
17:58 |
hecks |
unicode also has the wonderful property of having several ways to represent one character |
17:58 |
hecks |
which has security implications |
17:59 |
appguru |
We probably don't need Unicode to be fair. |
18:00 |
hecks |
you probably don't. |
18:00 |
jonadab |
I could see the argument for needing Unicode support in player names. |
18:00 |
hecks |
But this is about source code |
18:00 |
jonadab |
Right. |
18:00 |
appguru |
There was just a case where "°" was used for outputting degrees, and I think it should not have been changed to cryptic UTF-8 escape sequences (hence the PR) |
18:01 |
appguru |
Unicode in player names? What a nightmare. |
18:01 |
jonadab |
appguru: Yes. |
18:01 |
hecks |
and in source, just about the only legit use for unicode is to write people's names in comments correctly |
18:01 |
jonadab |
I'm not saying it should be implemented, only that I could see the argument someone might make for it. |
18:02 |
Krock |
so.. no changes so far? |
18:02 |
appguru |
Just merge my PR |
18:02 |
jonadab |
hecks: In comments, you can go ahead and use Unicode, and if the user's text editors supports it, fine, if not, oh well. It's a _comment_. |
18:02 |
jonadab |
The compiler doesn't have to care. |
18:02 |
appguru |
Unicode could allow using some neat symbols for certain messages |
18:03 |
jonadab |
Regarding the degree symbol, make it a #define DEGREE_SYMBOL or something. |
18:03 |
hecks |
The issue is that allowing unicode in source, and not rejecting it by policy, allows for sneaky underhanded code that looks fine on most fonts... maybe, potentially. |
18:03 |
jonadab |
To get the ugly escape sequence out of the part of the code people are looking at. |
18:03 |
Krock |
sfan5: so you're opposed changing the code style rules? |
18:03 |
appguru |
"⚠️ This would be a warning" |
18:03 |
jonadab |
hecks: Ah. |
18:04 |
appguru |
Latin-1 should be safe tho. |
18:04 |
hecks |
for example, j ~= ϳ but your font might display them as the same thing |
18:05 |
sfan5 |
Krock: not really but it's hard to define what exactly should be allowed |
18:05 |
Krock |
sfan5: exactly my thoughts, hence "ASCII as long readability is good, else UTF8" |
18:06 |
appguru |
By that criterion, my PR shoulda be merged :) |
18:06 |
Krock |
it would not be limited, but discouraged |
18:06 |
Krock |
zalgo text would be rejected ofc |
18:08 |
Krock |
rubenwardy: ? |
18:08 |
rubenwardy |
it should be very limited, and only used in string literals or comments |
18:09 |
rubenwardy |
° and … are two examples of unicode characters that are better raw |
18:16 |
Krock |
"Avoid non-ASCII characters in source files. Other UTF-8 characters may (only) be used in string literals and comments where ASCII would worsen readability. |
18:16 |
Krock |
" |
18:16 |
Krock |
^ how about this? |
18:17 |
sfan5 |
sounds good |
18:17 |
Krock |
any additions, rubenwardy ? |
18:18 |
Krock |
by the way "Do not use or, use ||." is really weird. which C(++) compiler accepts "or"? |
18:22 |
sfan5 |
I'd guess all of them |
18:23 |
Krock |
til |
18:24 |
Krock |
* Feature freeze date |
18:24 |
appguru |
2 more weeks please |
18:26 |
Krock |
I think it would make sense to browse through the PRs and issues to place milestones |
18:26 |
Krock |
and remove those that aren't necessary -> https://github.com/minetest/minetest/milestone/16 |
18:27 |
Krock |
The visuals and android fixes aside, there isn't too much that is necessary for the next release |
18:28 |
Krock |
#9807 is probably the most nasty among the bugs to fix |
18:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/9807 -- Bone animations broke between client versions |
18:29 |
sfan5 |
right so do we revert that commit? |
18:29 |
Krock |
that is https://github.com/minetest/minetest/commit/e1fc72c6f |
18:30 |
Krock |
question is whether the mods relied on the buggy behaviour, or whether it's now finally fixed properly |
18:30 |
Krock |
s/ or / and / |
18:31 |
sfan5 |
also regarding the milestone: the PRs I sorted into there are mostly ones that could easily go into 5.3 and I consider useful |
18:31 |
Krock |
alright |
18:33 |
Krock |
in the worst case we can revert the bone rotation commit, so we should be ready for a freeze in two or three weeks? |
18:33 |
appguru |
you could get #9903 merged - a single extra pair of eye is all it takes, it's really smol |
18:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/9903 -- Properly implement exposing the zoom key by appgurueu |
18:33 |
Krock |
rubenwardy: any preferred freeze date? early or late? |
18:33 |
|
Fixer_ joined #minetest-dev |
18:34 |
sfan5 |
I'd rather see a freeze in one or two weeks |
18:34 |
rubenwardy |
yeah |
18:35 |
sfan5 |
in fact it might be better to decide on a set date or it might get delayed again |
18:36 |
Krock |
so, next week, but spend a while on bugfixes? |
18:36 |
Krock |
basically as usualy |
18:37 |
Krock |
noted 13 Jun for planned freeze start |
18:37 |
appguru |
two weeks please |
18:38 |
Krock |
is #9592 related to the high packet sending count, sfan5 ? |
18:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/9592 -- Sometimes certain packets don't go from server to client |
18:38 |
sfan5 |
yes |
18:39 |
Krock |
okay, so not important for 5.3.0 |
18:39 |
sfan5 |
Krock: start freeze in 1 week, then 2 weeks bugfixes as usual I'd expect |
18:39 |
Krock |
bugfix time will vary as usual |
18:41 |
Krock |
* Wireframe glitch (graphics related) |
18:42 |
sfan5 |
was determined to be a driver bug |
18:42 |
Krock |
#9072 AMD messed up? All we can do is wait for it to be fixed |
18:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/9072 -- Faces show as if in wireframe mode if anti-aliasing enabled |
18:42 |
sfan5 |
and doesn't happen on default settings so no action IMO |
18:43 |
Krock |
indeed, disable antialias seems to work |
18:43 |
sfan5 |
more interesting would be #9008 but nobody knows anything about that |
18:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/9008 -- The skybox stopped working. I think an update on my computer may have messed something up. |
18:44 |
Krock |
perhaps transparency issues? |
18:44 |
Krock |
>mod containing a texture "hud_image.png" with a flat 90% transparency and |
18:44 |
Krock |
the author might need to look into this and troubleshoot their own system |
18:46 |
Krock |
and to come to an end, I might continue working on #9914 to split the Input and Output streams so it can be added somewhen |
18:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/9914 -- POC: Introduce SerializeStream helper class by SmallJoker |
18:46 |
Krock |
end of meeting. thanks for participating. |
19:03 |
|
reductum joined #minetest-dev |
19:03 |
sfan5 |
I guess the network logging could be improved regarding the desync thing |
19:08 |
Krock |
would be great |
19:08 |
hecks |
does anybody here know CAOs well? I'm trying to nail #9139 but the way CAOs handle position is a little confusing to me |
19:08 |
ShadowBot |
https://github.com/minetest/minetest/issues/9139 -- Server receives an incorrect player position after attaching to an entity |
19:08 |
Krock |
the server does not handle attachment positions well |
19:09 |
hecks |
the problem here is that getPosition reports the wrong value for one frame after attachment, and it's the client's fault |
19:09 |
hecks |
and it has something to do with that matrixnode, that's the code path that causes it |
19:10 |
Krock |
have a look at Camera::update and the world offset (200m steps) |
19:10 |
sfan5 |
random idea: call m_matrixnode->animate() (since that's one of the things that run before/during rendering) |
19:10 |
hecks |
sfan5: at the top of getPosition? |
19:10 |
hecks |
or, well, in that block |
19:11 |
Krock |
hecks: could you please provide a minimal testing mod for this? |
19:11 |
sfan5 |
why not after initializing the matrix node? |
19:11 |
sfan5 |
but try both places just in case |
19:14 |
hecks |
Krock: added a testing mod to the issue |
19:15 |
Krock |
thanks |
19:19 |
hecks |
sfan5: m_matrixnode does not have animate(), it's a dummy transform |
19:20 |
sfan5 |
oh |
19:20 |
sfan5 |
well then |
19:31 |
sfan5 |
Krock: do you have any opinion or thoughts on player transfer distance being higher than object transfer distance? On servers I have observed that carts disappear when far enough even while a player is still sitting in them (they then appear to be flying) |
19:32 |
Krock |
does not matter |
19:32 |
Krock |
fixed in 5.2.0-dev or so |
19:32 |
Krock |
well, they no longer teleport after detaching |
19:33 |
Krock |
they look like they're flying but what do you want to do instead? |
19:33 |
sfan5 |
why is object transfer distance smaller than player transfer distance? |
19:34 |
sfan5 |
or are player object messages in fact sent to everyone in the server even if in 30000 nodes distance? |
19:34 |
Krock |
players might want to find each other easier on servers |
19:34 |
hecks |
player transfer is infinite on some servers, isn't it? |
19:34 |
sfan5 |
infinite is the default yes |
19:34 |
Krock |
player object messages are handled like other object messages |
19:34 |
hecks |
maybe for mixed object/player hierarchies, use the maximum of the two distances? |
19:35 |
Krock |
except that the add/remove from the scene packets have different ranges |
19:35 |
sfan5 |
hecks: sounds like a workable idea |
19:35 |
sfan5 |
so does that mean players stop updating when they leave the object send range? |
19:36 |
sfan5 |
I think I should just read the code... |
19:36 |
Krock |
sorry? players are removed from the scene if they're out of range |
19:36 |
Krock |
it's like an entity is killed and removed |
19:37 |
sfan5 |
then my question is how large is that range? because evidently entities "unload" (referring to client-side) before players do |
19:37 |
Krock |
entities unload when the server tells the client to do that AFAIK |
19:38 |
Krock |
the server is in full control of what's visible by players |
19:38 |
Krock |
s/players/clients/ |
19:38 |
Krock |
and for out of range objects, no position updates are sent (obviously= |
19:38 |
Krock |
serverenvironment.cpp or so |
19:39 |
Krock |
also clientiface.cpp for some of the object id caching |
19:43 |
sfan5 |
https://github.com/minetest/minetest/blob/master/src/server.cpp#L1892 |
19:43 |
Krock |
FWIW, sending only nametags for further away players would also work well, but is a bit more complicated to implement |
19:43 |
Krock |
m_env->getRemovedActiveObjects |
19:44 |
Krock |
SendActiveObjectRemoveAdd only keeps track of the client-visible entities |
19:45 |
Krock |
ah. clientiface only provides the variable (plus container) |
19:45 |
sfan5 |
so with default settings you have the following values in that function: radius = 4*16, is_transfer_limited = false, player_transfer_dist = 0, player_radius = 0, my_radius >= 4 * 16 |
19:46 |
sfan5 |
https://github.com/minetest/minetest/blob/master/src/server/activeobjectmgr.cpp#L155 |
19:46 |
sfan5 |
and as seen here this translates to unlimited transfer distance for players |
19:47 |
Krock |
are your questions a follow-up of an issue, or just casually asking? |
19:48 |
sfan5 |
something I happened to notice, no existing issue |
19:48 |
Krock |
ah okay. I did not miss anything in this case :) |
19:48 |
sfan5 |
...and since this code only checks the known_by set https://github.com/minetest/minetest/blob/master/src/server.cpp#L755 |
19:48 |
sfan5 |
...this must mean even players 30000 nodes away will get any and all object messages |
19:48 |
Krock |
and it's known as soon it's added in getAddedActiveObjectsAroundPos |
19:48 |
sfan5 |
right? |
19:49 |
Krock |
buffered_messages are all object update messages, and there they are filtered per-player |
19:50 |
Krock |
if an object is out of range of a player, it's removed from m_known_objects and messages are no longer sent |
19:50 |
hecks |
okay, it's not the camera offset |
19:50 |
hecks |
the matrixnode itself is in the wrong place for a frame |
19:51 |
Krock |
player 30000 nodes away will not get any and all object messages. |
19:51 |
sfan5 |
okay that was worded badly |
19:51 |
Krock |
hecks: does that mean the matrixnode calculation happens at the end of a step rather than the beginning? |
19:51 |
sfan5 |
a player 30000 nodes away will not get any and all player object messages |
19:52 |
hecks |
maybe, also the wrong matrixnode position is, unsurprisingly, 0,0,0 |
19:52 |
Krock |
I hope it's clear what I meant :3 |
19:53 |
sfan5 |
a I messed it up again |
19:53 |
sfan5 |
"a player 30000 nodes away will get any and all player object messages" is the conclusion I get from the code |
19:53 |
sfan5 |
(changed will not -> will) |
19:54 |
sfan5 |
this is bad for performance but also makes sense, the player object is what makes the client display a nametag |
19:55 |
hecks |
okay, so this 0,0,0 position is in fact the attachment position |
19:56 |
hecks |
attachment at 0,1,0 produced 0,0.1,0 which makes sense in minetest's weird coords |
19:58 |
hecks |
https://github.com/minetest/minetest/blob/master/src/client/content_cao.cpp#L1464 |
19:58 |
hecks |
this would be where it gets parented |
20:15 |
hecks |
alright, got a possible fix |
20:15 |
Krock |
will merge #9906 in 10 minutes |
20:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/9906 -- Restore visual_scale support for nodeboxes (and allfaces) by numberZero |
20:16 |
hecks |
bleh, never mind |
20:17 |
Krock |
for #10000: does it suffice to spawn an entity that uses this mesh? https://github.com/minetest/minetest/issues/9985#issuecomment-638375144 |
20:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/10000 -- Recalc mesh normals for CAOs by dcbrwn |
20:17 |
hecks |
possibly, but I'd use both .x and a .b3d for testing |
20:18 |
Krock |
.x would be the uploaded file there and .b3d some mobs or player model |
20:18 |
Krock |
though latter do not have normals backed in |
20:18 |
hecks |
pretty much |
20:19 |
hecks |
but since this is about normal generation, you'd have to use specifically a mesh known to not have them |
20:19 |
Krock |
you'd have to test both to ensure nothing breks |
20:20 |
hecks |
do you want an .x with normals? |
20:20 |
Krock |
would be amazing if you could share such a model |
20:21 |
|
_Zaizen_ joined #minetest-dev |
20:21 |
PGimeno |
does anti-cheat roll back player rotation as well as position? |
20:21 |
sfan5 |
there is an example model inthe issue |
20:22 |
sfan5 |
PGimeno: it might reset it but not roll it back to previous values |
20:22 |
PGimeno |
hmm ok, never mind then |
20:23 |
Krock |
only positions are affected |
20:25 |
PGimeno |
hecks: maybe this helps understanding the matrix node? https://github.com/minetest/minetest/pull/8019#issuecomment-460072630 |
20:25 |
Krock |
merging.... |
20:28 |
|
Zughy joined #minetest-dev |
20:30 |
|
Miner_48er joined #minetest-dev |
20:35 |
hecks |
I have anticheat off for this |
20:35 |
hecks |
this is purely a client problem |
20:43 |
hecks |
okay so it's the parent's position that's wrong |
20:43 |
hecks |
and only if the parent is fresh |
20:46 |
hecks |
Reusing the same object doesn't seem to break it |
21:18 |
hecks |
goodness, there's layers to this bug |
21:19 |
hecks |
I managed to get it to update its position but now the camera offset is missing during that frame |
21:19 |
|
fluxflux joined #minetest-dev |
21:41 |
hecks |
nah, the camera offset is in fact applied *twice* |
21:54 |
|
benrob0329 joined #minetest-dev |
22:05 |
sfan5 |
merging game#2691 in 10m |
22:05 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2691 -- creative: Update for compatibility with minetest.creative_is_enabled by sfan5 |