Garry's Mod Wiki Discussion

[Rubat]

Now who is going to remove the Bug tags if and when they are fixed since there's no backwards references from git to wiki

[NeatNit]

Uhh...

I'll see if I can figure out a way to get a usable automatic list of but tags by their issue number, that should at least do the hunting for us.

[c👌de_g🎷]

I only did it for pages that shouldn't be listed in the category because they contain much more info than what the bug applies to (enums and structs). All function pages are listed regardless if the tag applies to an argument or not.

[NeatNit]

Okay, I've looked into this and the only thing I can think of is: we make the template automatically add to a category like Category:Bugs/Issue/1234 (where 1234 is the issue number). These categories will not exist and will appear red, however we can see them in Wanted categories and add them. I can make a copy-paste-able template to add a basic description to the category, make it hidden, make it a subcategory of Category:Bugs (that way there'd be a list there) and add a link to the issue on GitHub.

This is not an ideal solution, but unfortunately I couldn't find a better one in MediaWiki.

[Rubat]

That sounds terrible.

I guess the search feature can be used, but that still would require to manually search the issue id every time one is closed.
http://wiki.garrysmod.com/page/Special:Search?search=3029&fulltext=Search

[NeatNit]

Hold on, maybe Semantic MediaWiki has a trick up its sleeve...

[NeatNit]

So, update:

Template usage and look hasn't changed (why should it? that's right, it shouldn't. keep using it), but now it sets properties for the issue/request/PR ID. Rubat helped me name them (read: Rubat named them, I was going to call them stupid things). Links to lists of those are in the Category page and the Template page, and here:
List of issues by ID: Issue Tracker ID
List of requests by ID: Request Tracker ID
List of pull requests by ID: Pull Request ID

I considered changing them from IDs to URLs, like this: Property but I figured it would be kind of annoying, make it harder to see the number, and doesn't gain much usability (you can click the page and then the issue link within it, so it's just one extra click). So I think sticking with ID is just fine.

I wasn't able to sort the property pages by number - this is probably because a page can have more than one issue, and the property pages shouldn't list the same page twice in list - but there may be a way to create a dynamic query page to do that or something nicer. I'll look deeper into it tomorrow.

[NeatNit]

Getting closer to a nice list, testing here. At the moment it doesn't like pages that have more than one issue.

[NeatNit]

Okay. I gave up on list of issues, list of requests and list of pull requests - all my research seemed to indicate that this isn't possible.

Instead I found perhaps a better way to make a list: Category:Bugs

It also shows pages that aren't in the category, if they have an issue/request/PR attached.

[c👌de_g🎷]

That's good enough imo - doesn't have to look pretty as long as there is some two-way reference linking issues to bugs.

Got through #2000+ now.

[NeatNit]

I thought it looked pretty

[c👌de_g🎷]

It's prettier than the property pages at least 😬

[c👌de_g🎷]

Got through all of the issues! I still have a few more reports I need to reproduce before I add them to a wiki page but no stone has been left unturned.

[NeatNit]

Incredible.

[NeatNit]

GM/ShouldCollide has the bug:
This hook can cause all physics to break under certain conditions.
Issue Tracker: #642

I don't think this is a real bug, since it sounds to me like exactly the thing the Warning says:
This hook must return the same value consistently for the same pair of entities. If an entity changed in such a way that its collision rules change, you must call Entity:CollisionRulesChanged on that entity immediately - not in this hook.

[Rubat]

I agree about gross gamemode convenience functions that arent hooks yet documented as such, not sure what to do about them, can't get rid of em that's for sure.

[NeatNit]

Create this library/global function.
Deprecate the GM function, make it be a mirror of the global one (function(...) return SetTeam(...) end, so that if someone detours SetTeam it will apply to this too), leave it that way for the foreseeable future.
Make the OnPlayerChangedTeam hook be called by the engine from Player:SetTeam rather than from Lua, thus turning it into a proper hook and making it reliably be called whenever a player changes team regardless of how it happened (with the minor caveat that the GM function is no longer guaranteed to run, as with all hooks).

I don't see any obvious flaws with this approach..

[c👌de_g🎷]

It can break under other conditions which is the bug, those are just the documented ones.

[c👌de_g🎷]

Maybe a "Fixed" parameter should be added to bug tags to have some indication they are fixed next update? These look really messy:
Panel/DoModal
Vector/WithinAABox

[NeatNit]

No problem adding it, but how do you want it to look in the end? Can you draw a mock-up? (don't hold back, any change is possible, including changing the colors)

[c👌de_g🎷]

How about changing the solid red "Bug" background with half red, half blue square? Can't make a mockup at the moment but it'd have something like this:

https://pbs.twimg.com/profile_images/721628638131585024/BJnSaYYZ.jpg

Having it marked as "Fixed" should also add the page to the Next Update category,

[NeatNit]

How about we compromise and I get my green colored tags for the fixed bugs? Honestly I can't imagine your suggestion looking too good.

I'm more interested in what arguments the template should have and how it should display them. Right now I'm thinking:

{{Bug|whatever|Fixed=}}

This would indicate that the default message would be displayed, let's say like this:

https://files.facepunch.com/forum/upload/767/751d053f-6fa2-4150-bcfa-9d2d1afdbfa8/image.png

(the default message will be easy to change in the template, didn't bother making a link in the mock-up)

and you would be able specify a custom description:

{{Bug|whatever|Fixed=custom note regarding the next update}}

https://files.facepunch.com/forum/upload/767/b4225f44-7e81-4ad4-b70c-ab5585c6cc77/image.png

What do you think?

[NeatNit]

Apologies for the delay, I've now done this.

The template page's examples still need to be updated (they're currently half-assed just for testing), and the Help page too, but I really have to go. Can you do them @c👌de_g🎷 ?

[Rubat]

So I have been thinking about Panel documentation and I think we should list all the hooks used by the panels on their page as PANEL/Whatever links, not as their own pages.

The reason being this being that people may want to use hooks like the mouse events or think/performlayout on dlabel/dbutton for example and if they are overridden, they will break functionality of dlabel/dbutton.

This reason should also probably be stated near the list somewhere.

Any thoughts on this?

[Rubat]

So there have been quite a lot of changes to the wiki today:

All panel pages now show inherited methods/hooks from their parent (automatic),. as well as all used/overridden default hooks.
Example: http://wiki.garrysmod.com/page/Category:DButton

https://files.facepunch.com/forum/upload/1804/4bb33774-8518-4fc2-ad2f-c0b8ab4e33d2/image.png

Now this is not perfect, and they are in an awkward place right now, so don't go rushing editing all panel pages to add the hooks they override just yet in case we need to change something.

We are also thinking about moving all panel pages ( and maybe other pages ) from Category:Whatever to some other format. The only result this will have is nicer page formatting for the list of pages in the category.

Implemented a template for simple true/false actions for return values:

https://files.facepunch.com/forum/upload/1804/750562d6-ce71-4e37-9b52-e976e1f5b5a3/image.png

Not 100% happy how it turned out so I want feedback.

Fixed tabs in Preferences:

https://files.facepunch.com/forum/upload/1804/31b11ff0-c1e1-4779-a583-73b951bf1c5d/image.png

And there are some other minor changes in CSS

[c👌de_g🎷]

Could the same kind of structure be done for players, vehicles, etc. and their inherited entity functions?

[Rubat]

I am not too sure how that would work for those classes

[NeatNit]

It can work the exact same way. Preferably, they'd be moved over to the main namespace too (Category:Entity -> Entity), but either way, they currently work pretty much exactly like panel classes.

[c👌de_g🎷]

I'm thinking about adding a "Related pages" section to some wiki pages, much like Wikipedia or other MediaWiki sites in order to link directly related functions. For example, Getters and Setters would link to each other (Entity:GetColor->Entity:SetColor), functionality-related methods would link to each other (Entity:PhysicsInit->Entity:PhysicsInitConvex, Entity:PhysicsInit*), and functions that work in the same domain would link to each other (Entity:GetNWVar->Entity:NetworkVar, Entity:GetDTVar, etc.).

What do y'all think?

[Rubat]

We already do that for some pages by just having links to those pages.