[QUOTE=bigdogmat;51306910]In my opinion it looks ugly to have the other forms be there, it just doesn't look [i]correct[/i]. Even though it's be a bit more work to change the whole upper part, I think it'd be worth it.
Also, if it was changed to work that way, it'd make the page look cleaner overall, and take up less space.[/QUOTE]
FWIW the "less work" bit was just an afterthought, it's not a real factor when deciding. I just think it flows better - the one the reader is interested in is probably the most common one, and the others should come later. There's also the thing I mentioned before, where they all share the main description while the overloads only need to state the difference from the main form. Any other way, IMO, will just be a jumbled mess.
[QUOTE=NeatNit;51306618]Care to say why instead of just rating Disagree?
Edit: whoops, apparently automerge removes ratings.[/QUOTE]
Sorry, was going to reply once I got back on my computer. I feel like the separation by "other forms" or the previous mockup of putting the description in the header both look messy and unintuitive to the design of the rest of the site. I believe putting headers for each separate form, but having one description that details each construction form is more organised. So at the top, it says:
[code]Vector(number x=0, number y=0, number z=0)
Vector(string serialized)
Vector(Vector copy)[/code]
Okay, let's take this more seriously. Tell me which of these points you agree with. Some might be contradictory, some go without saying but are still important to keep in mind, and some are obviously wrong.
1. There should be a shared description for all forms.
2. There should be a shared parameters section for all forms.
3. There should be a shared return section for all forms.
4. There should be a shared examples section for all forms.
5. Each form should have its own description.
6. Each form should have its own parameters section.
7. Each form should have its own return section.
8. Each form should have its own examples section.
9. The 'function line' for all forms should appear at the top of the page.
10. The 'function line' for a form should appear immediately before its own description/parameters.
11. There should be one form that appears first, with its description, parameters and return values appearing exactly as they do for a single-form function.
12. Each form should be self-contained, i.e. not rely on anything outside of its own description and sections.
13. Information should not be repeated twice in the same article.
That’s all I can think of.
My list is:
[quote]1. There should be a shared description for all forms.
4. There should be a shared examples section for all forms.
5. Each form should have its own description. [i](to state the differences from the shared description)[/i]
6. Each form should have its own parameters section.
7. Each form should have its own return section.
10. The 'function line' for a form should appear immediately before its own description/parameters.
11. There should be one form that appears first, with its description, parameters and return values appearing exactly as they do for a single-form function.
13. Information should not be repeated twice in the same article.[/quote]
Which, produces the mock-up I made above.
[quote]4. There should be a shared examples section for all forms.
5. Each form should have its own description.
6. Each form should have its own parameters section.
7. Each form should have its own return section.
9. The 'function line' for all forms should appear at the top of the page.
10. The 'function line' for a form should appear immediately before its own description/parameters.
12. Each form should be self-contained, i.e. not rely on anything outside of its own description and sections.
13. Information should not be repeated twice in the same article.[/quote]
13 may contradict 7, although I remember some functions having different returns depending on the parameters given. Could be wrong.
My list is:
1
3 (I don't know any forms that have different returns so this shouldn't matter)
4 (Just include examples of all the different forms in the same section)
5 (Not necessarily a separate description section, but describe the different forms' properties in a new paragraph in the shared description)
6
9 (cleanest and most descriptive)
13
[QUOTE=code_gs;51312506]My list is:
3 (I don't know any forms that have different returns so this shouldn't matter)
[/QUOTE]
[img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/util/TraceLine]util.TraceLine[/url] returns a table or nil.
[QUOTE=NeatNit;51306618]Made a mock-up[/QUOTE]
How about this mock up:
[IMG]http://i.imgur.com/Pg8y6RW.png[/IMG]
Clicking on a form updates the page with its corresponding content.
IMO the wiki shouldn't rely on Javascript if at all avoidable. It's already bloated with JS.
[QUOTE=Shadow45;51314400]How about this mock up:
[IMG]http://i.imgur.com/Pg8y6RW.png[/IMG]
Clicking on a form updates the page with its corresponding content.[/QUOTE]
Yes but without the form expansion. Just the same style
[QUOTE=NeatNit;51314425]IMO the wiki shouldn't rely on Javascript if at all avoidable. It's already bloated with JS.[/QUOTE]
I couldn't agree more. Honestly I think as it is the Wiki is pretty painful to navigate. The search panel on the left is pretty good but pages themselves focus much more on flashy display than they do presenting content efficiently. Forcing content to be hidden until I click on the method I'm looking for would make it so much worse.
[QUOTE=Shadow45;51314400]How about this mock up:
[IMG]http://i.imgur.com/Pg8y6RW.png[/IMG]
Clicking on a form updates the page with its corresponding content.[/QUOTE]
[QUOTE=NeatNit;51314425]IMO the wiki shouldn't rely on Javascript if at all avoidable. It's already bloated with JS.[/QUOTE]
[QUOTE=Banana Lord.;51316188]I couldn't agree more. Honestly I think as it is the Wiki is pretty painful to navigate. The search panel on the left is pretty good but pages themselves focus much more on flashy display than they do presenting content efficiently. Forcing content to be hidden until I click on the method I'm looking for would make it so much worse.[/QUOTE]
I think you could use pure CSS to do the effect, but I agree with the sentiment. I wonder how people will choose which form should come first. Randomly? In order of addition to GLua? Most common first?
The second would require a historian and the third would probably be heavily debated.
[QUOTE=Apickx;51316318]I wonder how people will choose which form should come first. Randomly? In order of addition to GLua? Most common first?
The second would require a historian and the third would probably be heavily debated.[/QUOTE]
I say most common first, and I don't think it will be THAT heavily debated. Besides, that's what talk pages are for. Either way, it's still the most logical/helpful way to sort them. We shouldn't rule it out just because there would be a handful of cases with mild disagreement.
Back on point though, can anyone produce a mock-up for a flat page, i.e. no need to click anything to see everything? (I vote for basically my mock-up above but with the other forms being unfolded, but some of you took issue with that one)
Why does this entry still exist?
[img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/Entity/GetNWVarTable]Entity:GetNWVarTable[/url]
This function doesn't exist?
[QUOTE=markusmarkusz;51450427]Why does this entry still exist?
[img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/Entity/GetNWVarTable]Entity:GetNWVarTable[/url]
This function doesn't exist?[/QUOTE]
I'm not home and can't check right now, but if you're sure, you can simply edit the page (edit with form!) and add [b]{{Delete|Your reason for deletion}}[/b] to the beginning of the Description. Normal users like you and me can't delete pages, but we can mark them for deletion so that Robotboy655 will delete them when he sees them (usually pretty quickly).
[QUOTE=markusmarkusz;51450427]Why does this entry still exist?
[img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/Entity/GetNWVarTable]Entity:GetNWVarTable[/url]
This function doesn't exist?[/QUOTE]
I'm guessing it was switched out for the NW2 variant as Entity:GetNW2VarTable does exist.
[editline]30th November 2016[/editline]
To be completely honest the whole NW2 documentation is kind of fucked imo. Things like GetNW2VarTable exist but aren't documented, and then GetNWVarTable is documented but doesn't exist. And then you have things like GetNWVarProxy which only work for the NW2 system even though it doesn't have a 2 in the name.
[QUOTE=bigdogmat;51450595]I'm guessing it was switched out for the NW2 variant as Entity:GetNW2VarTable does exist.[/QUOTE]
I guess this function was removed because of [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/Global/BuildNetworkedVarsTable]BuildNetworkedVarsTable[/url]. But it can also be the way you said it.
[QUOTE=bigdogmat;51450595]To be completely honest the whole NW2 documentation is kind of fucked imo. Things like GetNW2VarTable exist but aren't documented, and then GetNWVarTable is documented but doesn't exist. And then you have things like GetNWVarProxy which only work for the NW2 system even though it doesn't have a 2 in the name.[/QUOTE]
Why does nobody document these functions?
I would document all NWVar and NW2Var functions, but would it be worth it?
[QUOTE=NeatNit;51450588]I'm not home and can't check right now, but if you're sure, you can simply edit the page (edit with form!) and add [b]{{Delete|Your reason for deletion}}[/b] to the beginning of the Description. Normal users like you and me can't delete pages, but we can mark them for deletion so that Robotboy655 will delete them when he sees them (usually pretty quickly).[/QUOTE]
Done.
I also did this for this page: [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/Entity/GetNetworkedVarTable]Entity:GetNetworkedVarTable[/url]
[QUOTE=markusmarkusz;51450847]Why does nobody document these functions?
I would document all NWVar and NW2Var functions, but would it be worth it?[/QUOTE]
It was decided by the devs that NW2 wouldn't be documented, because it's basically a fixed version of NW. The documentation would be completely identical to NW, sans any notes about the shitty behavior that NW2 came to fix.
Is it a good idea? I don't know. But it's Robotboy655's decision.
What we should be asking (and are constantly asking) is: why isn't the switch made already?
Now [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/Entity/GetNWVarTable]Entity:GetNWVarTable[/url] and [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/Entity/GetNetworkedVarTable]Entity:GetNetworkedVarTable[/url] are marked as Next Update changes. (Why is a deprecated function going to be added to the game?)
And what's about Set/GetNetworkedVar? Why were the pages removed even these function still exist?
[QUOTE=markusmarkusz;51452243]Now [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/Entity/GetNWVarTable]Entity:GetNWVarTable[/url] and [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/Entity/GetNetworkedVarTable]Entity:GetNetworkedVarTable[/url] are marked as Next Update changes. (Why is a deprecated function going to be added to the game?)[/quote]
I imagine because GetNetworked* functions are just aliases of the GetNW* functions, so if GetNWVarTable is added, then GetNetworkedVarTable will work as well.
[quote]And what's about Set/GetNetworkedVar? Why were the pages removed even these function still exist?[/QUOTE]
From what I can find they were old functions that were removed, for good reason, not sure why they exist now.
[img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/GM/ForceDermaSkin]GM:ForceDermaSkin[/url]
Using another example might be more appropriate, right? Someone just copied the code from the Base Gamemode.
Need some unbiased opinions. A few days ago I couldn't find the appropriate page so I made this page from scratch: [url]http://wiki.garrysmod.com/page/Structures/EntityDuplicationData[/url]
Then I found that it was already there (just not linked to in the pages I was looking at): [url]http://wiki.garrysmod.com/page/Structures/EntityCopyData[/url]
So obviously my new page needs to be deleted, but that doesn't mean it has to completely go to waste. Which parts did I write better? I can't objectively decide.
[QUOTE=NeatNit;51982872]Need some unbiased opinions. A few days ago I couldn't find the appropriate page so I made this page from scratch: [url]http://wiki.garrysmod.com/page/Structures/EntityDuplicationData[/url]
Then I found that it was already there (just not linked to in the pages I was looking at): [url]http://wiki.garrysmod.com/page/Structures/EntityCopyData[/url]
So obviously my new page needs to be deleted, but that doesn't mean it has to completely go to waste. Which parts did I write better? I can't objectively decide.[/QUOTE]
EntityDuplicationData is more fleshed out and descriptive.
Thanks. I finished it up and put it into EntityCopyData (overwriting what was there before).
:snip:
I'm working on making CamData, RenderCamData and ViewData take their content from one source, because they contain a lot of the same info. The 'how' is already done, I now only need to pick the best description for each field or rewrite some fields' descriptions.
If anyone wants to help, I would really appreciate it. I'm working on it in the Google Sheets sheet linked below.
[url]https://docs.google.com/spreadsheets/d/1gZq17YBBsW23fANAfkHZWENwUF_S0fXoMREsclumwK0/edit?usp=drivesdk[/url]
[QUOTE=NeatNit;51999339]I'm working on making CamData, RenderCamData and ViewData take their content from one source, because they contain a lot of the same info. The 'how' is already done, I now only need to pick the best description for each field or rewrite some fields' descriptions.
If anyone wants to help, I would really appreciate it. I'm working on it in the Google Sheets sheet linked below.
[url]https://docs.google.com/spreadsheets/d/1gZq17YBBsW23fANAfkHZWENwUF_S0fXoMREsclumwK0/edit?usp=drivesdk[/url][/QUOTE]
Devs, any chance to see the relevant source code where each of those 3 structures are used? I really don't want to reverse-engineer them, especially the more obscure fields of ViewData like dopostprocess, bloomtone and drawmonitors where I have no idea what to even look for. Not to mention there may very well be undocumented fields, like how ortho was undocumented in CamData before today.
[QUOTE=NeatNit;52000273]Devs, any chance to see the relevant source code where each of those 3 structures are used? I really don't want to reverse-engineer them, especially the more obscure fields of ViewData like dopostprocess, bloomtone and drawmonitors where I have no idea what to even look for. Not to mention there may very well be undocumented fields, like how ortho was undocumented in CamData before today.[/QUOTE]
Here's the main rendering code for GMaps.
[lua]
function PNL:RenderMap(w,h)
if not self:IsVisible() then return end
//Paint background
local c = gmaps.Null
render.Clear(c.r,c.g,c.b,c.a,true,true)
//Render world.
local zoom = self:GetZoom()
local x,y = 0,0
local aw,ah = self:GetAspectOffset()
for k,v in pairs(ents.GetAll()) do
if not v:IsWorld() then
v.GMapsNODraw = v:GetNoDraw()
v:SetNoDraw(true)
end
end
local campos = self:GetCamPos()
gmaps.Rendering = true
render.RenderView({
origin = campos, -- change to your liking
angles = Angle( 90, self:GetYaw(), 0 ), -- change to your liking
x = x,
y = y,
w = ScrW()+20,
h = ScrH()+20,
znear = self:GetZOff(),
zfar = 32000,
drawviewmodel = false,
drawmonitors = false,
drawhud = false,
ortho=true,
ortholeft=-zoom/2*aw,
orthotop=-zoom/2*ah,
orthoright=zoom/2*aw,
orthobottom=zoom/2*ah,
})
gmaps.Rendering = false
surface.SetDrawColor( 0,255,0,255 )
for k,v in pairs(ents.GetAll()) do
if not v:IsWorld() then
v:SetNoDraw(v.GMapsNODraw)
v.GMapsNODraw = nil
end
end
end
[/lua]
I can give you a copy of GMaps if you want the full source.
[QUOTE=bobbleheadbob;52000693]Here's the main rendering code for GMaps.
[lua]
function PNL:RenderMap(w,h)
if not self:IsVisible() then return end
//Paint background
local c = gmaps.Null
render.Clear(c.r,c.g,c.b,c.a,true,true)
//Render world.
local zoom = self:GetZoom()
local x,y = 0,0
local aw,ah = self:GetAspectOffset()
for k,v in pairs(ents.GetAll()) do
if not v:IsWorld() then
v.GMapsNODraw = v:GetNoDraw()
v:SetNoDraw(true)
end
end
local campos = self:GetCamPos()
gmaps.Rendering = true
render.RenderView({
origin = campos, -- change to your liking
angles = Angle( 90, self:GetYaw(), 0 ), -- change to your liking
x = x,
y = y,
w = ScrW()+20,
h = ScrH()+20,
znear = self:GetZOff(),
zfar = 32000,
drawviewmodel = false,
drawmonitors = false,
drawhud = false,
ortho=true,
ortholeft=-zoom/2*aw,
orthotop=-zoom/2*ah,
orthoright=zoom/2*aw,
orthobottom=zoom/2*ah,
})
gmaps.Rendering = false
surface.SetDrawColor( 0,255,0,255 )
for k,v in pairs(ents.GetAll()) do
if not v:IsWorld() then
v:SetNoDraw(v.GMapsNODraw)
v.GMapsNODraw = nil
end
end
end
[/lua]
I can give you a copy of GMaps if you want the full source.[/QUOTE]
Thanks a ton, but I don't think this helps much for the wiki. I want to confirm what each parameter ACTUALLY does, and describe it properly and fully. No amount of examples and results can guarantee that without looking at the source code, especially when it comes to parameters we never knew existed in the first place.
Could someone that understands the bit library make the description a little bit more in-depth for its methods? More specifically [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/bit/bor]bit.bor[/url] [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/bit/bnot]bit.bnot[/url] [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/bit/bxor]bit.bxor[/url] and [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/bit/band]bit.band[/url], which tells me (ignorant when it comes to this) nothing
Sorry, you need to Log In to post a reply to this thread.