Difference between revisions of "Talk:SDK Docs"

From Valve Developer Community
Jump to: navigation, search
(AI Category?)
m (AI Category?)
Line 86: Line 86:
It seems like it would be a good idea to add the AI section to this page.
It seems like it would be a good idea to add the AI section to this page.
: It's under programming. --[[user:TomEdwards|TomEdwards]] 11:30, 8 February 2010 (UTC)
: It's under programming. --[[user:TomEdwards|TomEdwards]] 11:30, 8 February 2010 (UTC)
:: So it is. --[[user:Lancelot|Lance]]

Revision as of 05:01, 10 February 2010


Error Nobody Seems to be Able To Help Me On!

So basically I keep getting this stupid error and nobody seems to know whats going on. Can someone help!? Like seriously It is really getting on my nerves because I spend weeks maybe months on maps and then they never compile! :/

Loading d:\program files (x86)\steam\steamapps\beano_weano\sourcesdk_content\cstrike\mapsrc\cs_test.bsp Error opening d:\program files (x86)\steam\steamapps\beano_weano\sourcesdk_content\cstrike\mapsrc\cs_test.bsp

Command: Copy File
Parameters: "D:\Program Files (x86)\Steam\steamapps\beano_weano\sourcesdk_content\cstrike\mapsrc\cs_test.bsp" "d:\program files (x86)\steam\steamapps\beano_weano\counter-strikesource\cstrike\maps\cs_test.bsp"

The command failed. Windows reported the error:

 "The system cannot find the file specified."

Whats up with that? can someone please help me?! :( thanks!

Keyvalues or SmartEdit text?

How should the keyvalues for entities be described? The options are the following:

1. SmartEdit text only: the keyvalues are listed and described using the smartedit text only. Example: A possible value for the npc_citizen keyvalue "Ammo To Resupply" is "Crossbow Bolt".

2. Actual keyvalue: they keyvalues are listed and described using the actual keyvalues only. Example: A possible value for the npc_citizen keyvalue "AmmoSupply" is "XBowBolt".

3. Both SmartEdit text and actual keyvalues: the keyvalues are listed and described using both systems. Example: A possible value for npc_citizen keyvalue "Ammo To Resupply (AmmoSupply)" is "Crossbow Bolt (XBowBolt)".

Previously, entries were generally a mixture of 1 and 3, with some keyvalues described using the smartedit text and then the "literal value" which was the actual keyvalue. These literal values are being removed as part of Tom's much-welcome cleanup of the entity entries. Using only 2 (the actual keyvalue) has led to some confusion, as in the recent back and forth edits of Env_hudhint.

Ideally, there would be a link on each page (view entry as SmartEdit text / view entry as Keyvalues) which would switch between the two. If this is too complicated, then perhaps we could have some other system which would describe the relationship between keyvalues and their SmartEdit counterparts? --Fitzroy doll 10:05, 20 July 2009 (UTC)

Thanks for the support. I spent an unhealthy amount of time editing yesterday. ;-) My reasoning for removing the raw keyvalue names is that they are only ever seen when writing an FGD or DATADESC; the only other (and the most important) time KVs crop up is in Hammer dialogues, where SmartEdit gives them friendly names. Even if you turn SmartEdit off for some reason, you can always turn it back on again. --TomEdwards 10:14, 20 July 2009 (UTC)
Okay fair enough. The raw keyvalues also come up in mods in which users can create edits to entity tables by hand, outside hammer (GMOD, SMOD, Obsidian Conflict, Synergy, etc.) or when viewing ent tables extracted from bsps for reference. But I suppose these are specialised circumstances, not directly related to the use of the SDK itself. Many existing entity entries will need a look with this new view in mind to make the policy consistent, and perhaps a notice should be placed in the Help:Contents section to inform future editors. --Fitzroy doll 10:36, 20 July 2009 (UTC)

TheFixer333 has added KV names directly after the friendly SmartEdit names here and here. I added the brackets myself so that the two names are more clearly separated, but I still don't think this is a good solution. If the reader isn't aware of the difference between raw and friendly names the inclusion of the former is confusing - especially when it means you end up with odd things like "Pitch Yaw Roll (angles) <angle>". It's a good job the friendly name isn't "angles" too!

Any inclusion of raw names needs to be done in such a way that it is initially hidden from view, as Fitzroy suggested. The people who need that information are just too few and far between to justify the complications caused to everyone else.

And to re-iterate what I explained to someone else, yes having a title on templates with a single entry takes up a lot of space, but it is necessary for consistency. There's nothing worse than scrolling down the list and seeing something that sits differently. Is it special? Is it a mistake? --TomEdwards 16:16, 27 July 2009 (UTC)

I agree that "SmartEdit (keyvalue)" is not an ideal solution, if for no other reason than that the format is inconsistently applied. For now the bracketed keyvalues should be removed. In the long term, I still hold out hope for a stylesheet-like switch that would mimic the SmartEdit on/off in Hammer.--Fitzroy doll 13:49, 28 July 2009 (UTC)

Retiring Template:EP1 add

I think we can assume that everyone is at least using the Ep1 codebase now. Retiring the template is easy: we just replace its contents with {{{1}}}.

Anyone feel that it still serves a purpose? --TomEdwards 08:54, 20 July 2009 (UTC)

Retired it. --TomEdwards 10:27, 22 July 2009 (UTC)

Note/Tip/Warning/Bug message wrap

See Template:Tip for my proposal. --TomEdwards 10:23, 20 July 2009 (UTC)

Seems reasonable. Will need to see it in context to see how well the decreased left hand margin will work. --JeffLane 21:05, 20 July 2009 (UTC)
There's a good comparison at Visibility optimization#Leaves. The margin change isn't a big deal: I chose an em value almost at random and just never bothered to get it any closer to the px equivalent. --TomEdwards 21:17, 20 July 2009 (UTC)
Extended it to the other templates. --TomEdwards 10:27, 22 July 2009 (UTC)

I changed the method by which the text was preventing from wrapping around, since it was causing problems when multiple floating images were present in an article. The new CSS works in everything except IE<8. --TomEdwards 11:22, 11 August 2009 (UTC)

New SDK Docs layout

Draft is at User:TomEdwards/SDK Docs draft. This version:

  • Reduces bumf before you reach the contents table to the essentials
  • Removes table items that are subcategories of other items (e.g. AI and VGUI)
  • Sorts categories by popularity (kind of)
  • Shortens category descriptions
  • Adds translation flags (they are misaligned because of the link back to my userpage)
  • Uses a nicer logo

--TomEdwards 11:15, 20 July 2009 (UTC)

Agreed, this could use an update. We'll use this version with some minor tweaks. --JeffLane 21:00, 20 July 2009 (UTC)
Fantastic, thanks. :-) --TomEdwards 17:18, 21 July 2009 (UTC)

Translation naming policy

It seems odd to me that we're forcing translated pages to be titled in English. I understand that it's important for admins to know what a page is about even if they don't read the language it's written in, but that could be achieved with redirects... --TomEdwards 17:18, 21 July 2009 (UTC)

We know this is not ideal, but this is unfortunately tied to a technical constraint. We've discovered on multiple occasions that page titles with Unicode encoding can get mangled during the backup and restore process. Besides that, creating redirects for every translated page does not sound like a very practical solution, as the page titles could easily get out of sync.
However, as a possible solution, I have altered the configuration so that the restrictions on the usage of {{DISPLAYTITLE}} are relaxed. This means that a template like Template:Wrongtitle could be constructed to display an entirely different display name on the page. The actual URL of the page remains the same, but the page header (and HTML page title) can be displayed in the localized language. It's also possible that this functionality could be added as a parameter (e.g. "displaytitle") to the existing language tags, as the location on the page is irrelevant and that would tie together the linking functions. The main downside for all this is that editors will still need to use the English page title in links. But for the reader, it is more of an end-to-end localization solution. I'm also not entirely sure if there could be any negative implications with the search engine (there may not be). The functionality should generally be avoided for other use, as there is a usability costs with mismatched display and URL naming, which is why the usage is restricted by default.--JeffLane 02:12, 22 July 2009 (UTC)
That works a treat Jeff. --TomEdwards 10:27, 22 July 2009 (UTC)
Only hitch is on-site search results. Do you think there's a solution? --TomEdwards 11:32, 22 July 2009 (UTC)

AI Category?

It seems like it would be a good idea to add the AI section to this page.

It's under programming. --TomEdwards 11:30, 8 February 2010 (UTC)
So it is. --Lance