found the issue https://github.com/PaperMC/docs/commit/d9eed6d8971931644c383bb088d946c2e53c701c
and now found the proper way to workaround it https://github.com/PaperMC/docs/commit/99a923805e7301c3e9b38dda66dfe788aab76b46
1 messages · Page 19 of 1
found the issue https://github.com/PaperMC/docs/commit/d9eed6d8971931644c383bb088d946c2e53c701c
and now found the proper way to workaround it https://github.com/PaperMC/docs/commit/99a923805e7301c3e9b38dda66dfe788aab76b46
by no means perfect, still want to add filtering by project facet
uuh, thats cool
Discord slash commands have gotten really cool
I've just started on this to go with (what for now will be very minimal) getting started developer docs. Would we want to recommend stuff like the run-paper or plugin-yml Gradle plugin? I'm a lot more hesitant on the second because that could be more confusing for new users and it's usefulness is arguable. But run-paper would be super great rather than telling people to copy over jars for testing or symlink or something hacky
Just not sure if that would be too opinionated, or if we want to recommend anything not official like that
Also, just to elaborate a bit going back to what was talked about above. I plan to mostly focus (and have all examples as) gradle kotlin dsl, with just very basic "maven exists" as a note for people who already use maven/don't like Gradle for whatever reason
In my opinion, if you write docs for paperweight userdev, then you definitely should write the same for run-paper, because it'll look actually like complete modding infrastructure setup but for plugins. Not sure about plugin-yml, because people don't like dsls
Was more talking about an example plugin there. I won't be talking about userdev beyond an it exists type thing here. Really just focusing on actual plugins just using API first
And tbh if you are using userdev, most people should be able to figure it out from the example repo
okay, I misunderstand something, sorry for that
Do you think it will be an improvement if the #paper-help mentioned in this section be s direct link to the channel? dis.gd/channelID or will that even work via browser
@young matrix
Oh didn't know that was a thing, that's cool
There are a few other places where that same thing is mentioned. I've been investigating the best way to implement placeholders. More for stuff like the java install guide so all of the 17s could be changed to 21s with one number, but also for stuff like that
Yeah I just got back from vacation. I will read it up and if I got a lot of things I will make suggestion on gh directly.


Anti Xray configuration guide: https://gist.github.com/stonar96/ba18568bd91e5afd590e8038d14e245e
BOOM
Nice looks clean
The comparison images look soooo cool
Wait, i'm new to Minecraft, but why can't server just not send the invisible blocks info to the client in the first place?
Wdym, which invisible blocks
Those that are not seen by the player
Yeah i see, but can't it just filter that out, at least clip the underground part off?
well, no
and what if you then break a block? lol
Like, theoratically you could
but, you've gotta calculate all that data depending on how far you wanna go
then theres the fact that air blocks in general in the current anti-xray system cause clients to crap the bed
then you're gonna expose ores xposed to caves anyways, which is still an issue in mode 1
(unless, expensive ray tracing or whatever)
Well, that makes sense.
honestly you could do that 
How many NASA computers do I need to run that
3 /srs
On a decent CPU I think it can handle up to 50 players per additional core (depending on settings). Afaik it has never been tested on large servers. However, it will probably also affect the main thread because of the move event (especially when third person ray tracing is enabled to calculate the third person camera positions) and the affect on garbage collection is unknown. Feel free to test and report.
how fast of a core though
Sorry, but this isn't the right place for discussing plugins, if you have further questions feel free to ask me in a DM.
Man your docs are looking sick!
thoughts on this vs. what it is currently? https://papermc.github.io/docs-previews/pull/48/ mainly talking about the sidebars. is it better or worse?
https://github.com/PaperMC/docs/pull/48 for full details. but no actual docs changes there
I think the current one is cleaner, but it's personal preference.
yeah idk, I think I prefer a more global one too
you also completely hid the intro page now, fwiw
since its top level
I do like the selected platform's categories being open by default tho
oh yeah, generally its not always visible what will expand and what not
would we maybe add little rotation arrows?
Hmm yeah I'll probably leave as is in that case. Part of what this would allow is better per project versioning (paper and velocity have different versioning schemes) should we want to version documentation. Same with localization. But that's a while off yet
paper would not need that, only velocity, its the only project we have that follows semver
I'd want it for paper for the config reorg and bringing worlds back in line with vanilla
I guess
Would be possible to do a shared sidebar but different versioning (more easily) if something like https://github.com/facebook/docusaurus/issues/6370 is implemented
Is possible now, but in a more hacky way
links to the github repos are a bit confusing for noobs
will be better putting on the main wiki page, like: source code
I think that's pretty clear, the goal is allowing people to navigate to each separate project isnt it?
No they mean the project name links to the GitHub page
Which looking again is a bit dumb and unclear
oh 
Could put the link in brackets next to the project name?
This menu makes me think there is only MAVEN & GRADLE AND JAVADOCS
that's a website issue, not really a docs issue
redoing the entire website is on the todo list
nice
do you plan translatable docs in crowdin?
no
PITA means what google says right?
pain in the ass
and yes is constantly changing, maybe when is "releases"
that was a metaphor
the joy is is that there is no real release cycle and no team of people sitting around the docs waiting to translate stuff as stuff changes
so it creates this fun issue where documentation can be wildly out of sync across languages
I will leave this offering: add one language like, to testing proposes and I would be responsible for translating it every change with pull requests.
the entire docs will need modifying for it
so is not easy as just add a button?
no
you basically need to place all text on the website inside of a special tag which the tool then tries to deal with
I understand, thank you for your time
I think that really the only thing that will need translation in the paper website is the message on the legacy paper download page where it recommends using deepl to translate the message... how am I going to know that I have to use a translator to translate from english if the text that tells me... is in english XD
Chrome translate lol
Who with brain cells uses chrome 
Literally everyone
Would be blunt to assume something else
Chrome's fine, but as a Firefox enjoyer, it would kinda hard to move.
I was just countering the really dum statement with an equally dum one
All browsers are breaking soon anyways, because of 3 digit version codes!
already happened with chrome
also funny that that includes wndows nt 10 when I got windows 11
guess cause of the deprecation of user agents in favor of client hints?
Ooo, what, it seems like I'm living under a rock. 
Did that 3 digit verion code actually had any bad effect?
bet they all already updated
not really. The tooling around it exists and is fine. It's really just a maintenance and a not right now question. The only place you'd need to do this is for non markdown pages, which we have very few of.
If it were to be done I'd really only see it happening if someone willing to put a decent bit of time into it like angw97 mentioned and with a small set of languages supported. But it's not something that will happen any time soon regardless. It's definitely not something I'd have any motivation to do for French, bar maybe a few more complex pages for testing
See how the jest docs do it https://jestjs.io/fr/docs/getting-started (edit this page at the bottom, or, modifier cette page)
But, jest is obviously a way larger project. Some changes would still need to be made to have it work like that, but not massive ones or ones that would make it harder for adding new docs (bar having to translate them)
You can also just have specific pages fall back to the default language should they be too outdated
If it is something we'd want in the future, I'd also want to implement versioning first as doing it the other way around sounds like a lot more work
Windows 11 is still 10.0 :p
The update guide should be linked on the downloads page
So it can be found easier by the casual server hoster
This guide, specifically. https://docs.papermc.io/paper/updating
Do we (and if we do how do we) want to include API usage guides in the docs ? The idea came up in a recent #paper-dev question about the PDC, which rn has my guide flying around on the spigot forums. The question hence becomes, should I port this to papers forums or should we have documentation on API classes/tools like the PDC (or others) on the docs
I think we’ve talked about it yes
More “integration” documentation. Javadocs are to unit tests as ___ is to integration tests.
here is how I have somewhat thought of doing it
paper/
├── getting started/
│ └── ...
├── How-to Guides/
│ └── ...
├── Reference/
│ └── ...
└── Developers/
├── Getting Started/
│ └── ...
└── API/
├── PDC
├── Events
├── Commands
├── Scheduler
└── ...
as its own section, with most still being focused on server owner stuff. but idk, its not my favourite
Can’t you do whole other sections of docs? Like a whole other top level thing?
So server users, and api users are totally separate
yeah, you could
but to do that I think https://github.com/PaperMC/docs/pull/48 would be somewhat necessary
to avoid having a super complex sidebar, split it out by project
or, rather this: https://papermc.github.io/docs-previews/pull/48/
each project would then have
paper
users
...
developers
...
velocity
users
...
developers
...
waterfall
users
...
developers
...
Like the docusaurus has links on the top bar that totally change the sidebar https://docusaurus.io
yes, that is similar to what I have above
they use two instances of the content-docs plugin (same as I have above) - but that comes with some caveats
as all the markdown infra is duplicated as well, so you can't super easily link between the two (you have to use the slug, not the markdown file)
but that's fine
idk, I kinda like that again. the split sidebar
it just seems unnecessarily large. when users are looking at one or the other most of the time
(either users or developers)
I suppose there are some cases where you want access to both at the same time, but I think most of the time it is one or the other
hmm, yeah
its kinda tough with the multiple projects though. not sure how that would work ui best ui wise
were you thinking having users and developers separated but still all three projects on the same sidebar? so two distinct categories?
well how I was thinking was two sidebars, Docs and API (names can change). Then in each of those you've got Paper, Velocity, and Waterfall (or less if not needed).
then inside each of those platforms you've got the documentation for each of those either user-facing or developer-facing
maybe Server Admin and Developer
so
___Docs____
Paper
paper user docs
Velocity
velocity user docs
Waterfall
waterfall user docs
___API___
Paper
paper api docs
Velocity
velocity api docs
but yeah, I guess that makes sense
idk if Waterfall or Velocity will have api docs, but have a paper header there incase they do
velocity already does, to a point
well then yeah, thats what I was imaginging
waterfall I have no intention of working on, but that still works with your org idea to skip one project
i'll mess about with it a bit
had a minute so made a concept of this https://github.com/PaperMC/docs/pull/50
so you just flipped the two top levels then?
added nav bar things for each platform, and then sub menus for admins vs developers?
yes
it feels super weird to navigate tbh though, a bit disorienting. hard to know where you are
yeah I'm getting that too
I think part of it is the dropdown menus on those items
what if those weren't drop downs, and were just links to a landing page for each platform
hmm, yeah
which sidebar would the landing page be linked to though?
or just no sidebar for those
idk, could it be a separate page with two big buttons? one for server admins, one for devs?
if you are doing this, I think maybe the better thing now is 3 sidebars, one for each platform, with a top level thing for Devs and Admins
that is kinda what I had started on earlier
would it be possible to split paper, velocity, and waterfall on the sidebar
right that's what I was saying @grizzled glacier
oh okay, but thats closed ?
could reopen it :p
where was the discussion about that?
let me find it
just makes more sense, why would I want to click on paper, then keep clicking next and end up reading about velocity lmao
was pretty brief #docs-website message
I was pretty much 50/50 on it when opening it, but starting to like it more now
it just makes more sense 🤷
also ignore the "PaperMC Docs" in the top right, was an issue I didn't see when merging. not intentional
I think its good. global doesnt make sense to me because there are few situations where one needs to navigate globally jumping from paper docs to waterfall to velocity in the same session
another idea could be a dropdown here about, to switch between developer/admin docs
would show what you're currently on, and then hovering would bring up the other
so 6 distinct sidebars, 3 navbar links
actually not sure how well that'd work, as it'd take you to the landing page for each. maybe better suited to docs with multiple versions of the same page (as in if the structure for paper/velocity docs were identical)
could it be like a slider or something, or like two buttons side by side?
well either that or just two top level sidebar entries per platform. whatever works best
Anything you seem fit sulu
Maybe just not more than X amount of entry so it’s more mobile friendly
not a huge fan of "Common"
maybe "PaperMC"? before I had PaperMC and common but just merged them now as it made sense
yeah idk what to call it, common just seems bad.
Also, the Getting Help sidebar entry, does it need to exist?
can you have external links in the top navbar?
also just noticed something else super annoying
slightly different size, didn't notice that. must have not always been like that
but yes, you can. maybe a dropdown
the discord is already linked there right?
yeah, can probably just delete Getting Help
can link to the forums somewhere, but I dont think its super important to link the the specific channels
yeah, can just add another icon link
need to redo those anyways. right now it is this beauty https://github.com/PaperMC/docs/blob/main/src/css/custom.css#L28-L57
is it intended that there is a "Velocity" category on the "Paper Developer" page? it seems a bit confusing
https://papermc.github.io/docs-previews/pull/50/dev/paper
has a velocity category in the left sidebar
oh yeah that. yes. that one I don't like though, #48 is the one I plan on going ahead with I think
that one feels super weird to navigate around
alright. yeah, its a bit weird indeed
not sure about the common category, if the updating java tutorial could be moved somewhere else it could be called PaperMC, because thats the only thing that does not really fit in
yeah, I'm not really sure I like the name common either. PaperMC might work.
was concerned that'd be confusing though as a lot of people don't know the difference between PaperMC and Paper in terms of naming
tho it might be a bit confusing if there is a PaperMC logo (for the main page) and a category called PaperMC at the top and they do different things
maybe Meta
that almost seems worse
iirc on the old docs it was called Site, but that didn't seem very clear to me. i guess compared to Common its descriptive
maybe get rid of the category completely and move art assets and contact to the footer?
hmm, yeah
^ i think the problem is its a few kinda unrelated things
art/contact us is about papermc org
the old docs solved this by having 3 1 or 2 article categories I think, don't really want to do that. but yeah they are a bit unrelated
maybe Extra
Misc?
is it possible to put the same page in both the velocity and the papermc sidebar? then the java tutorial could go there, the contact us/art assets can fit in the footer and the downloads api page is just a link to the swagger page anyways
yeah could do that. want to do more for the downloads api though, that is mostly just a placeholder
how about this: rename category to Misc or Extra (i like both of these) and then also put java update guide in sidebar of paper/velocity
yeah, that could work. Misc fits better imo
“Other”?
I think I like misc more. Not sure though
Also just found that GitHub pages doesn't support redirects, so time for ~30 html file client-side redirects I guess
I wonder if it would be possible to make the javadoc into a format like this: https://discord.js.org/#/docs/discord.js/stable/class/Activity That way it oculd be another tab on the docs
I don't think that would work well with the amount of classes Paper has (like, eh https://papermc.io/javadocs/paper/1.18/overview-tree.html)
Sorting them by their packages makes much more sense, and the tree is too deep to fit that into a sidebar
Yeah, other thing is everyone uses and is familiar with javados. I don't believe there is something as universal for js libs (correct me if I'm wrong). So definitely could be done but I'm not sure the work of writing a whole new docgen is worth it/feasible.
I’d like to write a guide for how to send a packet with protocollib would that be acceptable? like how to go from an idea, to sending the packet
Sounds like something for the protocol lib docs imo
We already had a discussion here about linking "industry standards" e.g. luckperms or protocol lib so getting to their docs if they are linked should be relatively easy
The documentation is not too clear about this, but I wanted to just make sure that I am correct in my thinking.
In the paper config there is a value generate-random-seeds-for-all. Would this value randomize the seed use for the seeds that you can define for each structure in spigot.yml? I would like to stop people from cracking my seed.
those only randomise the feature seeds iirc
(tho that is more of a question for #paper-help, this channel is mainly for building the documentation 😅)
Ah alright thank you!
@young matrix isn't it just back to the same thing with dropdowns in the navbar that are duplicated by the sidebar?
I thought that was the main thing driving the "odd navigation feeling" of a previous attempt
That was more at least for me all projects as part of one sidebar
But yes, it is a similar design
I guess I can remove the drop-down and just manually add cards to the landing page (only 2 per)
But looked more at implementing the full tree there and it doesn't really make sense/isn't feasible without reimplementing a bunch of stuff due to the order stuff is created (and has to be), the state isn't available
yeah so maybe only the top level stuff, and it'd be manual
it would be nice to have like 2 big buttons, "admin", and "devs" and then a group of smaller buttons for their sub categories, but eh
couldn't reproduce with any browser i tried in browserstack, probably a one-time visual thing?
yeah I dont think thats possible on a modern browser
Inb4 he’s got a few dead pixel on that exact spot 
pesky cosmic rays
convo in #paper-help probably warrants a quick explainer somewhere of the update folder
I know jmp has been pushing moving the update folder out of the plugin folder to avoid conflicts
but idk, you have the same problem with a plugin named bStats right?
the folder is there and has existed there for years, if you moved it you'd just need to change the default config in bukkit.yml but then you end up in this place where the majority of peoples update folder is plugins/update, and everybody elses is elsewhere, as well as the years of mentions around that feature oddly scattered around, etc
but, that feature hasn't exactly been doc'd well, in part it's mostly just been kinda left to rot as many people don't know about it and it was stupidly limited before
Hello! Is it permissible for me to use this code in my own documentation if I give credit?
https://github.com/PaperMC/docs
https://docusaurus.io - everything there is just minimal modification of the default template here
Thank you
Should PRs for the new docs be made before the paper pr is merged (like with the old docs) or after?
I'd kinda prefer after for small things, and if it's a new contributor doing it who doesn't do that I don't care about just writing docs myself.
If it's a completely new concept (as in, not a config option/etc.), before may be better.
I think after is fine given that sulu (still wants to maintain it and kept the similar style of writing)
Both because 1. I would prefer not to have a bunch of open prs waiting and 2. A lot of paper prs (especially features) will take a very long time to be merged/not merged at all. I'd rather people not have to spend extra time writing and making a PR for docs that may or may not ever be a thing
Obviously different for javadocs, and will be different when the config docs are autogenerated/nonexistent as well
I've changed it a bit and think I've fixed a lot of the weird feeling. still haven't updated the homepage, but disregarding that I think this is probably the way to go for future expansion
for reference https://docs.papermc.io vs https://papermc.github.io/docs-previews/pull/48
looking at it now, is there a way for the menu dropdowns to not appear if you are already on that page?
so like if you are on the Paper group, the dropdown on hover doesn't appear in effect duplicating stuff?
Yeah, I'll try that tonight.
did this. tbh feels a bit weird to me, but it does get rid of the duplication. what do you think? I'm really not sure. could go either way
They redirect currently, that'll be fixed in the future
But thanks for pointing out the read the docs site
Well #welcome was already updated with the repo. link. Guess the javadoc one was forgotten
They redirect to each other. Currently at least. jd.papermc.io has no landing page
This channel moved... 👀
hmm?
Why have you pinged me?
!kick 940264217343311912 random pings
:raised_hands: Kicked sanic#4096 (random pings) [2 total infractions] -- jmp#3822.
Lol okay
I did update paper, quickshop, antiaura, protection stones and added playtime and from now [server] greets every player every 5 minutes ... where can I turn it off?
you've likely got some sort of schedule set up in a panel/wrapper. but please head to #paper-help
I have to open a ticket
There are no tickets here
i have a problem
If you need help ask in #paper-help
Making docs the top-most channel might not have been the best idea
#paper-help probably should be…
that's better
Hey guys, how i can use PathFinder's entities api moveTo with locations with a distance more than 20 blocks?
actual method has that limit
This is for the Docs, ask API questions in #paper-dev
ohh sory
thoughts on something like this to give you a better idea of where you are? I've started to try to improve the usability of the split-projects branch
actually maybe having it on each is not the right way to go
maybe better(?)
the last one is better yes 
agreed
maybe a thinner bar as well
leads to this unfortunately. I guess can just have all of them at the same level and just add colour on select
you cant have the blue line sticking out from the left?
instead of it being inside the box, its outside
gotta be some css for that stuff
almost makes it look uglier
the extra space there, feels like everything is sticking out. maybe I can do half in half out or something
Very nice sulu
Is there any place where the Paper/Velocity environmental variables are documented? I have not been able to find anything in the documentation
no, I had made a PR for this on the old PaperDocs but dropped it and never redid it
it's something i'd want at some point if you'd be interested in adding it. that and system properties under Reference
someone tell me when 1.19 paper's gonna come out?
wrong channel and there's no eta but hopefully soon
you can test experimental builds in #❗ 1.19
wha
?kick @analog isle you've received an answer about 1.19 3 times now
:raised_hands: Kicked kshaurya731#0151 (you've received an answer about 1.19 3 times now) [2 total infractions] -- Michael#9600.
some people never learn
Unfortunately
oh, they are so ungrateful
And they never learn
this is so minor but its been driving my crazy. I almost thought I was insane at first. these little dots show up when hovering around the sidebar. whenever I go to open devtools it goes away. all I know is that it is caused by this commit https://github.com/PaperMC/docs/commit/e855396347222b60f206e402d55a56d1c9944c55. if anyone has any insight/fix that would be greatly appreciated
almost seems like a browser rendering bug but I doubt that a lot. probably just my bad css
wait hold on it actually does not happen on firefox, video was chrome
tried popping out dev tools? am sure you can do that
either that or expand the window
BIG thing that trips people up is that opening dev tools shrinks the width of the page, and so can shift stuff a bit
no its just moving the cursor makes them go away
they only come up in seemingly random cursor positions
o.O
anyways I've concluded its chrome-specific which makes me thing its not an issue with my css
doesn't happen on firefox or safari
those don't appear here
and its so minor, just very annoying
what os? and chrome or something else?
nvm i can see them when i emulate a nest hub screen in dev tools
lmao
that is barely even noticable yeah
like literally 1 pixel wide
I notice no such thing on Chrome 101.0.4951.64 on Linux
I've been working on the 1.19 config changes, think versioning the Paper section is the only real way to go due to the magnitude of changes. I anticipated this a few months ago, so already started on a branch that would allow per-project versioning. however, this requires some reorganization (internally effectively every project is its own docs content provider instance). what this means from a user perspective is a different sidebar for each project. This could be made the same with some mega hacks, but to be honest I like it more separate
very much WIP, but feedback appreciated https://split-projects.paperdocs.pages.dev
I like that. It’s still easy enough to switch the project, and since you usually only want to look at one of them at a time, you also get more space/less noise in the overview
Looking great
How do I switch version on a page?
Oh I see, I have to go back to main menu in the menu
(mobile)
Guess that's good enough since there is an alert on 1.18 to switch to 1.19
yeah the whole mobile sidebar experience is a bit clunky, but I'm not all too sure how to make it better
although the github/discord icons look super scuffed, that's an easier fix
but who is going to be reading these docs on mobile bar clicking one link/navigating within one project
It worked well enough tbh
a bit cursed patching compiled js but I think I'm almost happy with this now, the versioning
only yarn 3 iirc
didnt even know yarn 3 is a thing
I thought yarn 2 was just now a thing
2 was nov/dec 2019, 3 is early 2021+
Although 2 might have had patching too, I don't remember. 1 is classic while 2/3 are modern, all I'm decently sure about is that classic does not do it natively
did a dum https://github.com/PaperMC/docs/pull/64
My bad for not looking carefully/verifying
Well my bad for just being wrong. I’m not sure where I got the assumption that all vanilla maps operated the same way.
is there a todo issue for 1.19?

uh
there isn't one
or do we put that in the main tracking issue in the Paper repo?
docs don't have an issue for that, pretty sure progress hasn't actually started aside from the backend work to support multiple versions https://github.com/PaperMC/docs/commits/split-projects
oh you wanted a docs-specific 1.19 one
Yeah I just marked the pages that need updating
Am pretty much happy with that so will start on actually updating them today
something I'm not sure about is how we want to represent config keys post-migration. previously I'd just been separating with a ., as was done internally at the time but i'd like to move away from that as while it does make sense looking at it for me and others here, I'm not sure that it does for all server owners- that just beyond it being incorrect.
currently I've been doing "a, b, c" but I've also thought about [a, b, c] or similar. I don't really like either tbh
I mean, the structure is more nested now, how well do the docs represent that?
the config reference does not right now at all. I haven't gotten to that. more talking about referencing config keys elsewhere
but for right now my current early-stage idea is to have headers for each section and then a table for all keys in the section, as well as a table(?) of types at the top. each key gets a type and description
oh, I mean, .'s are generally the typical way to reference it everywhere else
whats wrong with "a.b.c"?
as much as it's semi meh, am not sure that there is much of a better alternative to jump away from that representation of stuff
I guess that a literal a.b.c is a valid key. . has no special meaning
but yeah, might just revert
as this is a bit ugly
are you planning to restructure the docs in a similar way to the config? e.g. with "chapters" for the individual settings that are related?
[] is probs what I'd favor towards if we couldn't ., but, I see no reason to switch vs the accepted norm
eventually I hope to phase out configuration reference in favour of comments in the config file + maybe something auto generated from that. the actual docs just being configuration highlights/guides. but for the moment yes
having an online reference you can link to is nice tho
but a chapter structure sounds good
just went with ., looks way nicer despite being meh
was thinking of doing something like this. thoughts?
also obviously not correct, there are some things blatantly wrong
looks a lot better than the current long list for sure
fixed the top table for better screenshot, content of that is still way off but just for example. in reality would only be for enums/etc.
main issue is big tables look bad when editing the file
unless you turn off word wrapping, which makes it both better and way worse because horizontal scrollbar
not quite sure what the best way to fix that is/what an ideal solution would even look like. mediawiki/rst also don't have a great way to handle this as far as I can tell
I am trying to run the docs locally, running yarn dev (installed from npm from nvm) however about 3 seconds into docusaurus watching for file changes it runs into a ```
[2] #
[2] # Fatal error in , line 0
[2] # Fatal JavaScript invalid size error 162925241
[2] #
[2] #
[2] #
[2] #FailureMessage Object: 0x7ffd01566870
Update node? 🤷♂️
I can actually reproduce that, just not locally
just tried it in a github codespace and it happened
in .yarnrc.yml try changing nodeLinker from pnpm to pnp
that fixed it for me in the codespace after going back through every commit
it doesn't seem to happen so soon though, only about 30 seconds in
odd, wonder what causes it. changed it due to it working out of the box with vscode/intellij while also not having the everything has access to everything deal with node-modules (at least to my understanding). I guess will change back
Well anyway it works for me, thank you 
okay, updated everything but config reference now
would like any feedback on https://docs-82hg1rmt1-papermc.vercel.app/paper/reference/global-configuration this page as I hope to do the same thing here on the per world config side, but that'll take a lot longer. not the content so much but organization/style
Can you give the description a min width? Then it's easier to read on mobile
The sidebar on the right side has a bit too much real estate
looks like the search function doesn't really work right now?
"PaperMC Documentation" appears to be the only thing that's in its database
Hmm you're right. Let me look into that
Wrong channel for asking this try #paper-help
fixed
I can confirm
which file has the bedrock breaking config?
should be a global config
Read the announcement. Also this is the docs channel not the support channel.
player-max-chunk-load-rate in global configs is nowhere in the docs
I've added that in https://github.com/PaperMC/docs/pull/66, although it'll take me a while before that is ready
might as well just copy/paste it over into current docs for now
fixed
what is the differences between chunks loaded per sec vs chunks processed per sec?
if i set the max load rate too low, will that affect their view distance?
former basically says how many can be shoved into the queue
latter says the capcity of the queue per player
I was wondering, is there anything documentation related on the Velocity side of things that is waiting to be ported from the old wiki?
I would love to do some PR'ing at some point.
everything from https://velocitypowered.com/wiki has been included. In the back of my mind I've thought about pulling all the stuff from https://docs.velocitypowered.com/en/latest/ and putting it up as an older version (like the how the paper section of the docs are versioned). However, I'm not familiar with velocity enough and haven't spent any time looking at the v1 docs to see how different they are OR if that would even be of benefit to anyone. It'd more just be for completeness and to get the v1 docs off of the first google result for "velocity proxy documentation"
Oh nice, great job sulu! I totally agree with you on getting the old doc out of the search results, people should read the new one instead.
where is paper.yml on 1.19?
Where did paper.yml go?
In 1.19, paper.yml has been split into two files, both in the config directory. In paper-global.yml you will find configuration that changes behavior of the whole server, and in paper-world-defaults you will find configuration that can be overridden on a per world basis. See https://docs.papermc.io/paper/per-world-configuration for more information on overrides. The function of server.properties, bukkit.yml, and spigot.yml remains unchanged for this time.
-Xmx controls the amount of heap memory assigned to the JVM, this does not include other memory used by java, or native memory used by other libraries such as netty (for networking) or SQLite. Please do not allocate all of your memory!
#paper-help, but why?
Creating ridiculous lag
I think that we need a page which goes into creative mode
Like, maybe just a page which has the word "don't".
what's wrong with creative mode?
it's a security nightmare
i thought people only gave it to admins anyways
people run entire servers based around creative
some have even ran creative mode servers ON servers with other standard survival worlds
which has caused fun issues when people abuse creative mode and send entities to another world
I think that some stuff of that has been mitigated over the years, but, a gamemode in which allows a client to, for the most part, say "hey, this is the item I have" is generally not a safe way to go about stuff
oh wait yeah i forgot about creative servers
must be why hypixel doesnt do actual creative mode on their housing server, just one where you have a server side menu to spawn items
Is there any way in bibliothek to get builds sorted by channel
also, it would be nice to have more than just a sentence in the docs https://docs.papermc.io/misc/downloads-api
I mean, the API docs do all the explaining that's needed
and idk what you mean by sorted by a channel, but, this is the wrong channel
which is the right channel to discuss this?
cant you just manually check if this was possible to be gotten from the creative menu, and if not dont respond to the packet or send another packet setting that item back to air
could the top bar be the same for docs.papermc.io, papermc.io and forums.papermc.io?
We can't manually check because theres literally 0 item tracking
you have no idea if that item came from the vanilla menu or if they just picked it up and moved it
Hello
in paper-world-defaults anti-xray has the max-block-height set to 64
do i make it go until 320 for full coverage?
I noticed there's an empty "Development Guide" section, is that something that's just been started or has it been like that for awhile?
That's new as of about a week and a half ago, but I've been out for that time since then and won't work on anything paper related for another week or two
So yes, it is empty. No, it won't be forever
Look at the velocity docs for an idea of what it might look like/the format
Itheres a plugin that stript NBT data from items that isnt whitelisted
Is there any official documentation for the 1.19 config files? I admin a server that's been running on PaperMC for quite a few years and has collected quite a few config changes, many of which I suspect were only temporary (e.g. use-optimized-ticklist). Some of them get copied over to the new format but not included in the new groupings and some seem to get dropped altogether. I'd like to use the reorganization as an opportunity to tidy them all up.
old and unused config will not get removed if you update from older versions. What you can do is backup your old config files and remove them to generate a new set with only the options currently availabe.
(I personally do it on every major version changes and this also gives me time to revisit certain optimization that I do that may no longer be required)
The config reference docs update to 1.19 isn't finished yet and it's not something I'll be able to work on at all for at least two weeks (if anyone else wants to take a look, feel free). I did update the per world config guide though. See https://github.com/PaperMC/docs/pull/66 for my current idea, but note unfinished
Ok, thanks guys, and thanks for all your efforts
howdy fellas
not completely sure if this is supposed to be a ref
just shooting it out there in case it is
docs look great btw, very readable
That was meant to be commented out, my mistake
Writing a proper guide for that going through a couple different strategies, especially talking about shared hosts is on my to-do list
But won't be working on anything paper related for a few weeks. If anyone wants to pr/push commenting that out/even just removing it, feel free. I won't do that and can't merge it right now either, but someone else can
done, hope it saves some time :p
well... https://pastes.dev/Koz9tKSpCH
just getting that error when I try to start locally
Yea, I keep getting that too
maybe I gotta play with node versions but something is clearly pissed
gonna re-clone now
did sulu move it back to pnp
Ah not yet, yea changing nodeLinker to pnp in the .yarnrc.yml fixed it for me
nah, recloning didnt work either
yarn build doesn't work either
am on 16.14 nodejs
well it requires >= 16.14
so...
this is making it kinda hard to add a new page...
oh I didnt see this, lemme try
😅
ok, so hows this? https://github.com/PaperMC/docs/pull/71
I think the docs are on a system that better supports redirects, so later if we need to change the url we can
Yea, I mean, it works
idk if it's reported, but, the version selector thingy on the docs doesn't seem to work
You'd need to elaborate. What page are you trying it on? What happens? It seems to work fine here
On some pages though it'll just stick you at the index root for that project (although at a different version) due to the same route not existing across versions
I see some keys being prefixed with misc. in 1.19 - is that correct or a bug with the config upgrader?
also does it somehow make sense to autogenerate the docs based on the code? I have seen this being done very successful with hashicorp (terraform, packer, other)
I was on the xray page and it didn't work with the version selector, I got the header, so, guess that needs fixing
It’s correct. There should be no top-level config options, only config sections.
this is the hope for some point in the future for config reference docs
new config system makes this a whole lot easier as well, but will still be a while
looked into it a bit, should be fixed
was actually already an open yarn pr, so could have been a lot quicker
Sulu, when you get a chance (idk if you are back doing stuff, but I’ve seen you more active today) can you take a look at just the placeholder config page? I’d like to get that in so we can add a paper.yml.txt file.
I don't see why not, seems fine
actually
I'd just rename the per world config guide to /configuration and add a redirect, as that's what I want it to be eventually anyways when I get to it. just one guide, not two. can add a note at the top linking to the forum post there instead
👍
I've got no idea, works on every device I've tried it on. fixed the issue on the few pages that it wouldn't work now as well
oh, do you use safari
works everywhere else
Apple moment
Was on vivaldi
Like, o could select 1.18, it showed me the outdated docts warning, but had the tweaks for seperate configs or something, I'll have a look when I'm at my desk, feeling kinda dizzy
On 1.19 I don't have a paper.yml file?
Wrong channel
Where did paper.yml go?
In 1.19, paper.yml has been split into two files, both in the config directory. In paper-global.yml you will find configuration that changes behavior of the whole server, and in paper-world-defaults you will find configuration that can be overridden on a per world basis. See https://docs.papermc.io/paper/per-world-configuration for more information on overrides. The function of server.properties, bukkit.yml, and spigot.yml remains unchanged for this time.
Oh sorry, but thanks you!
👋 is it undone, or the button just doesnt work?
basically nothing happens on click
its todo, ye
This is the channel for discussing our documentation. You probably want to ask in the paper help focused channel #paper-help