In the future, you can just post the page address and it will auto-embed.
can probably delete those link buttons.
I am not that sure about removing them. There is more than 1 forum on the internet that might use gmod wiki and standard "bb codes".
Maybe annoy garry to fix it here then. I'm not very sure about the new system. It was more fun when you could edit quotes and links and formatting wasn't displayed on screen
an alternate link specifically for facepunch or garry providing support for it on this forum is what i imagine will happen in the future (or it'll die to make way FOR THE RISE OF S&BOX)
Theoretically the link for facepunch would just be the regular page URL. No need to make a button for that.
It would be better just to format it from the regular link on the new forums imo.
This auto-embed thing really doesn't tell me very much information
Panel
Ah yes panel that really narrows down the point of the link without me clicking it
Here's an idea: make the function name in the page title link to the page itself, then using clipboard-polyfill, make the "link here" button copy the title DOM element. Result should look like this: Entity:EnableMatrix
One more thing, took my a while to figure this out. The z-index of heading elements is -1, and I have no idea why. It makes the link part of the title unclickable. Intriguingly, this comes immediately after the above error. Full snippet (of chrome-prettified minified CSS):
body {
margin: 0 auto;
background-color: #fff;
background-image: url(" '/skins/garrysmod/bg.png' ") /* first issue */
}
h1,h2,h3,h1 a,h2 a,h3 a {
font-family: oleo script;
font-weight: 400!important;
font-smooth: always;
-webkit-font-smoothing: antialiased;
text-shadow: 0 0 3px rgba( 255,255,255,.5 );
z-index: -1 /* second issue */
}
How about making a github repo of wiki.garrysmod.com with the actual web content of it? Some people will dedicate their time to make this wiki better
What's stopping you from making this wiki better now?
Is there a way to blacklist pages from showing up in categories? http://wiki.garrysmod.com/page/Help:Editing shows up in the tag category pages because it uses examples on that page.
It seems putting = in a {{StructureField}} causes the field to disappear, don't know if it's a MediaWiki bug or not. See in this change.
I have returned from my slumber!
Known issue, use {{eq}} in place of an equals mark.
I fixed this by adding a parameter to the {{Deprecated}} template: see the diff. The category is gone, but the sidebar hasn't updated yet - it's been over 12 hours, how often does it update?
Same fix as above should be applied, I'll do it soon maybe.
Two more things I want to bring up:
derma.DefineControl vs vgui.Register - the difference between them, if any, should be clarified.
GM:PostReloadToolsMenu and others like it should be SANDBOX hooks. Also mentioned there, a hook that's never called or used in vanilla gmod, and so arguably doesn't exist.
PostReloadToolsMenu is in GM:* hooks because it DOES exist in the base gamemode. It is run from the clean up library, which is not sandbox exclusive.
If the hook is never run, is it really part of GM? More importantly, in which list do users expect to find this hook? To me it seems pretty much exclusive to sandbox.
Although a PostReloadToolsMenu hook exists in the cleanup lib, it's still never called outside of Sandbox. It's just gamemode-specific code in a default module.
This is fixed now: diff
The spawn menu hooks seem pretty inconsistent. SANDBOX/SpawnMenuOpen is marked as Sandbox only but exists in the base gamemode. There's also some documented returns that don't actually do anything. I'll try to clean this up.
If I wanted to document that various gui elements create other gui elements (e.x., a dframe creates 3 dbuttons for minimize, maximize, close) and that they can be acessed via .btnMinim .btnMaxim and .btnClose respectively; where should I put that? Under structures? Somewhere under Lua Reference?
We'd probably need a better format for class and library variables before mass documenting stuff like that. You also really shouldn't be using variable names directly like that tho, even tho there isn't an alternative most of the time.
If they shouldn't be used, what's the correct way to move & resize elements so they match up with visuals when creating a derma skin?
There's also the select function which allows you to select single values from a vararg return.
local h = select(2, panel:GetSize())
I added a template for notes about bugs: Template:Bug
Currently it's red. This is CSS that Rubat added a while ago that was just never used until now. However, I expected it to be green, that way the Note, Warning and Bug templates match the colors of Server, Client and Menu.
Here's a comparison:
https://files.facepunch.com/forum/upload/767/f6a35032-ad88-4bd9-80db-82ae4630b2cf/image.png
Opinions? Rate agree for green and disagree for red. The colors match!
Trying to add an optional issue number argument to the Bug template, testing here: http://wiki.garrysmod.com/page/User:NeatNit/Bug
Needs extra CSS to look good, I can't style the <a> tag directly.
I don't think the issue number should be in the left side of the thing, especially if you want to change the color of the link. Orange color doesn't fit it at all as well, it has very low contrast to the background.
I see what you were going for, but I feel like it should be more like this:
https://files.facepunch.com/forum/upload/1804/8cbffc88-d1de-486a-8eca-d4a46d983e40/image.png
It's more readable this way and it preserves the wiki color for links.
Alright, fair enough. There's a very minor styling issue with that that really bugs me, but it actually affects all tables on the wiki and should be solved easily with a few lines of CSS.
The short version is that the following CSS fixes it:
table.gmodwiki_note p:first-child {
margin-top: 0px;
}
table.gmodwiki_note p:last-child {
margin-bottom: 0px;
}
The long version is: the first line of a table block in MediaWiki for some reason doesn't get a <p> tag. This causes a couple of issues, one of which is that the first linebreak behavior is inconsistent with other places in the wiki and another is that the bottom margin is visibly larger than the top margin.
Example: the following wiki code:
{{Bug|Line 1
Line 2
Line 3
Paragraph 2}}
Becomes:
https://files.facepunch.com/forum/upload/767/e7dcc07d-ecbb-4005-82a8-fbbaedbec2b6/image.png
The way I propose to fix it is to make the template apply the first (buggy) linebreak automatically, resulting in:
https://files.facepunch.com/forum/upload/767/873265ba-9ff6-468e-97ac-08b0fe24a79f/image.png
And also applying the CSS I posted above, which finally looks correct:
https://files.facepunch.com/forum/upload/767/1d0b3ce8-afde-4b45-a575-bad497d87f60/image.png
This fix can also then be applied to Note and Warning.
We've already applied an identical fix to Structure tables, like ViewData Structure where the CSS is:
table.wikitable p:first-child {
margin-top: 0px;
}
table.wikitable p:last-child {
margin-bottom: 0px;
}
This was apparently about 2 years ago according to the edit history: Template:StructureField&action=history
I guess I went a bit off-topic :P
I started adding bug tags to pages - got through the #3000+ issues on the issues repo and all pull requests. I was surprisingly able to verify most of the bugs reported but I'm sure that'll change as I get to older issue reports.
The empty space at the top and bottom is fixed by the CSS in my post above. But the space between the issue number and the description is just a normal paragraph separator. Do you think it's too much?
I noticed that in some cases, when the bug is related to a particular argument or stuff like that, you disabled the category. I don't fully agree with that - I think if there's a bug on the page, it should be in the category. The Category=No option is pretty much just for the help page and the template page itself, in my eyes.
But honestly I haven't decided yet if the category is useful at all. And if it is, it should probably be renamed to "Pages with Bugs" (since the page itself isn't about a bug). You can find all pages that used the template via Special:WhatLinksHere, so the category is a little redundant... But it does make a somewhat nicer-looking list.
Fantastic job overall, where do you get the patience to do this?
Sorry, you need to Log In to post a reply to this thread.