Community Portal

This is the primary discussion forum for the CS Wiki. Decisions made by the editors here on the Wiki will be posted here, as well as links to on-going discussions. Please be sure to use Signatures and Indentation appropriately in discussions - if you are unsure of proper style, please see our Welcome to Wiki Syntax guide. This is not the place to ask general mod related questions, those belong on the Forums.

Discussion Subpages
Active Discussions

• General Cohesion Initiative
• User Defined Functions

Old Discussions

Signatures	Vandalism after Recaptcha
Where to put something?	Navigation Suggestion about Functions
Wiki Updates, August 7, 2007	Questions on the Wiki
Debate on Discussions	Article vs Discussion Distinctions
Terminology Discussion	Trivial, Homeless, Uncertain Facts Page
Bot for Scripts	General Organization
Move?	Community Sheriff
OBSE Plugin Functions	Article Tags
Scripting Section Hierarchy	Navigation Suggestion
AFD and Redirects	Second Revitalization
Magic Function Subcategorization	User CSS Enabled
Questions on (advanced?) wiki syntax	Function Info Template category
Search Changes?	Redirects & Nominated Articles
New Utility Mod - Should I put the docs here?	Script editor wiki links
That Spam Bot

Finally Fixed the Project:Copyrights Link

The Project:Copyrights link on the Edit page is finally fixed, as a side-effect of fixing the project namespace. Very happy to see that. I went through and moved all the old project pages that I could find over to the new namespace, and I added a few more links. Very good stuff.
Dragoon Wraith TALK 01:51, 10 June 2008 (EDT)

Architecture Changes

The name of the Wiki (e.g. {{SITENAME}}) has mercifully been changed to omit the trailing space that confused everyone: "the Oblivion ConstructionSet Wiki". Further, the "Project" namespace alias has been changed from "The Elder Scrolls Construction Set Wiki " (ugh) to "CSwiki" (much nicer).

Further, subpaging has been enabled on the (Main) namespace, and presumably on the Help, Category, and Project/CSwiki namespaces. I've only tested Main, but I see no reason why those would be enabled on Main and not on the other namespaces that I requested.

Portals and Features have been added to the Navigation box. Looking at it now, seems a little large, but I also like having access to them anywhere. Opinions on this are welcome.
Dragoon Wraith TALK 15:37, 3 June 2008 (EDT)

Pretty nice, will have to play with the subpaging a bit. That reminds me, did TS7 ever have luck installing LaTeX? The Parser stuff is working nicely, but last I tried (month or two ago) the Latex stuff wasn't.--Haama 15:57, 3 June 2008 (EDT)

I know he tried and had difficulty on it. I believe he asked (and I mentioned here) us to test it, so presumably he assumes that it does work. If it does not, we should let him know that.

Dragoon Wraith TALK 12:10, 3 June 2008 (EDT)

Umm... not in so many words? Ok, I'll look at what I tried, maybe now that I understand it a bit more I can give it a better shot, and report back here.--Haama 19:05, 3 June 2008 (EDT)

Huh? Not following you.

Dragoon Wraith TALK 19:17, 3 June 2008 (EDT)

"Parser extension should be added, TS7 says we should test it to make sure it works. The LaTeX stuff is giving him trouble, but he's still working on it."

Dragoon Wraith TALK 16:36, 27 March 2008 (EDT)

My impression was that it wasn't supposed to be working (yet). Anyway, took this code directly from the help site

<math>\left ( \frac{1}{2} \right )</math>
<math>\sqrt{2}</math>

gives

$\left({\frac {1}{2}}\right)$
${\sqrt {2}}$

--Haama 19:26, 3 June 2008 (EDT)

Will ask.

Dragoon Wraith TALK 09:40, 4 June 2008 (EDT)

Cleaned up Hosted Images

Just went through the image log, added {{afd}} to the ones that have no business on the Wiki. Leaving a note here so that if anyone decides to do so again at a future date, they know they only have to go through the ones after this date.
Dragoon Wraith TALK 08:19, 6 April 2008 (EDT)

Toolbox for Tutorials

I think it would be a good idea to add a toolbox on tutorial pages with the tools used in that tutorial. That way we can standardize all the "Tools Needed" and "Requirements" sections in each tutorial. On the Wiki pages of the tools we can add some installation instructions, trial programs and alternatives. Next to the TOC would be a good spot, it's only a list with links so there's not a lot of space required. Here's an example of what I mean:

I didn't want to go ahead and start adding this to the tutorials right away (first want to finish the help section anyway), but I thought I'd put it up here and see what you think.
--Qazaaq 09:50, 14 March 2008 (EDT)

Looks good to me, I say go for it when you get the chance.

Dragoon Wraith TALK 06:51, 14 March 2008 (EDT)

Very good idea - I wonder if we should do a similar bit for the scripting tutorials and list all of the "See Also", functions used, Standardized Snippets, and articles up top?--Haama 11:41, 15 March 2008 (EDT)

Brilliant idea, as I hate when tutorials suddenly say: now open this program, A program I don't have, it's too far into the tutorial for me to stop!

anyway I'd love to help you add them! --Oblivious12123 07:36, 29 December 2009 (EST)

New Administration Noticeboard

Sheriff action requests and requests of Bethesda should now go here.
Dragoon Wraith TALK 11:56, 7 March 2008 (EST)

Pseudo-Code Examples on Function Pages?

A user on the ESF suggested having pseudo-code examples for functions, for the sake of novices who have difficulty understanding the more technical syntax section or are still new at reading code. On the one hand, I think pseudo-code is great for explaining things, especially to novices, but on the other hand I will worry that it will lead to clutter. So, do people think that adding pseudo-code examples to the function pages is a good idea? Should it be for all of them, or just ones that are particularly confusing? Thoughts on this would be appreciated.
Dragoon Wraith TALK 07:44, 7 March 2008 (EST)

There are some functions that need a tutorial/overhead explanation (i.e., Messagebox Tutorial). From the ESF thread, the GetNthActive... functions need one. Looping apparently needs a better one? And from another thread the Input functions need one (though, apparently, it will be moot by v15 :) ).--Haama 11:01, 7 March 2008 (EST)

Functions in scripts category/pages

There's a category (set of pages?) that lists the vanilla scripts with certain functions. I imagine that all of these were determined with v1.0 and there have been some changes since then. This thread, for instance, points out one such instance where the function doesn't seem to be there (whether it ever was there).

It looks like these functions are easy enough to find (Find Text), and I imagine there are differences between the versions. So, should we delete the category/pages?--Haama 14:00, 15 February 2008 (EST)

Deleting Questions

I started the process - it doesn't seem to be as daunting as I thought it would be (hooray for Category:Request an Article). Anyway, should we make the decisions on where to put the question (delete, request, etc.) on our own or wait for a second vote?--Haama 18:17, 19 February 2008 (EST)

You can also use the {{Missing}} tag. Might be useful for questions that aren't formatted like proper requests (as described in the Request an Article page).

Dragoon Wraith TALK 18:52, 19 February 2008 (EST)

Good point, but not the main question :P I was thinking that the first person could make the suggested move (tag or category) and the second could remove the Questions category.--Haama 20:06, 19 February 2008 (EST)

Progress

Through the H's. Didn't mess with these questions:

• Articles for Troubleshooting
  1. Can_I_remove_NPCs_pickpocketing_others_messagebox
  2. Cs_saved_as_tes_file
  3. Help_none_of_my_changes_in_the_construction_set_show_up_in_game
  4. How_can_I_fix_an_aquired_Crash
• Interesting info
  1. Effect_Shaders_on_Mounted_Actors
  2. How_would_I_create_a_statue?
• Tutorial comments
  1. How_to_avoid_Bed-Furnituremarker-Warp
• Should be on the wiki - quick answer?
  1. How_do_I_Use_One_AI_Package_On_Multiple_NPC's
  2. How_do_I_change_the_PC's_starting_location
  3. How_do_I_script_a_spell_to_summon_a_creature
  4. How_do_I_stop_faction_members_from_attacking_eachother (maybe troubleshooting)

Further Progress

I've done the rest, now we only have to do the answered questions?

• Troubleshooting
  1. I cant save my mod (not answered yet)
  2. Invalid cell coordinate (not answered yet)
• Interesting info
  1. Rotate Entire Area
  2. Shaders on weapons or armor
  3. Talking Creatures?
  4. Variables In Companion Script Reset After Closing Oblivion Gate
     • Info already in Troubleshooting and added to Cell Reset
• Should be on the Wiki
  1. Mods Without Master File
  2. Levels of AI Processing
  3. NPC Find Player
  4. Stop NPCs from attacking aggressor
  5. Sound preview not working
  6. Shaders Leaking?
  7. Weapon reach

"Answered" Section

Everything in the Answered section, in theory, "isn't of real importance to the public" - I vote for whole-sale deletion of everything in the category. I recommend that people go through, give things a cursory glance to make sure that it actually isn't anything useful, and if not, yeah, we can just ditch all of it.
Dragoon Wraith TALK 15:58, 24 February 2008 (EST)

2nd vote. Treat it like we did the questions and list which ones might be useful and why?--Haama 16:35, 24 February 2008 (EST)

Yes, but I expect that most will not be.

Dragoon Wraith TALK 17:27, 24 February 2008 (EST)

We should go through the category briefly, look at the titles and open anything that could be interesting. There are 269 answered questions and most can be skipped by looking at the title, this shouldn't take very long.

Before deleting the category and the pages within we have to make sure none of them are also in the solutions category. Shall we call this decided then?

--Qazaaq 19:05, 24 February 2008 (EST)

There's only like three of us here, anyway. If we've all commented, I'm going for it.

Gstaff probably won't be around to delete them for a while yet, anyway, so we don't have to worry about losing anything if I make a mistake.

Dragoon Wraith TALK 00:58, 25 February 2008 (EST)

Progress

Well, I've done the Answers starting with A, B, and C. There are 216 answers left to go through. I'll continue working my way through those. There were a few that I didn't delete, which I placed in appropriate request places (either request an article or interesting discussion tags).
Dragoon Wraith TALK 00:28, 29 February 2008 (EST)

Uploading test mods

I'd like to upload a test mod for the Variables category. I'm hoping that this will make it easier for others to run duplicate and counter tests, as well as lend a bit more legitimacy to the wiki. It will require OBSE and Pluggy to make testing easier and to have a text file with the results. Format will be along the lines of

Global Float tests
Test 1a: aaaFValue = 8388606 (exp: 8388606)
Test 1b: aaaFValue = 8388607 (exp: 8388607)
Test 1c: aaaFValue = 8388608 (exp: 8388608)
Test 2a: aaaFValue = 16777215 (exp: 16777215)
Test 2b: aaaFValue = 16777216 (exp: 16777216)
Test 2c: aaaFValue = 16777216 (exp: 16777217)
Test 3a: aaaFValue = 33554432 (exp: 33554431)
Test 3b: aaaFValue = 33554432 (exp: 33554432)
Test 3c: aaaFValue = 33554432 (exp: 33554433)
Test 4a: aaaFValue = -2147483648 (exp: 2147483646)
Test 4b: aaaFValue = -2147483648 (exp: 2147483647)
Test 4c: aaaFValue = -2147483648 (exp: 2147483648)
Test 5a: aaaFValue = -2147483648 (exp: 440359962751356)
Test 5b: aaaFValue = -2147483648 (exp: 440359962751357)
Test 6a: aaaFValue = -2147483648 (exp: 44035996275135651)
Test 6b: aaaFValue = -2147483648 (exp: 44035996275135652)

--Haama 23:43, 5 April 2008 (EDT)

Last I checked, the Upload thing only accepts images. Otherwise, I'd be all for it. Perhaps e-mail Gstaff about it?

Dragoon Wraith TALK 03:08, 21 April 2008 (EDT)

Finally got a chance/reason to test this - we can't upload .esp files... Not sure if it's worth bugging GStaff and <sp?>TS37<sp?>, though. Almost a roll of the dice whether it'd be a better way to get people to upload their test mods.--Haama 17:18, 2 June 2008 (EDT)

There is a way of putting .rar files into the .jpg image and then upload it to be downloaded and extracted. ill get back to you on this one.--blindobi

Wrye Changes

Okay, I'm sure that this stuff has been talked about before. For sure there was a major effort at putting together portals. But I'm not sure that was a good idea. To some degree it seems that we're now lost in a plethora of index pages (portals + categories + sub-categories). Kind of a lot.

And I've never been very happy with the combination of articles and categories -- you just end up with a mess (IMO). (In contrast, I think that something like this is better: Modding@UESP -- a nice long list with short descriptions which I can easily scan up and down. In other words, it's better to have less index pages with more links on them.) But not to spend too much time arguing.

Sorry if that sounded like a rant, I know you all have worked hard on this, but it's still fairly hard to find your way around and figure out where to add new material.

So, I've done a couple of things. If these go over well, then I'll do some more if I have time (what I actually wanted to do was write an article on standardizing menu behavior -- but I couldn't find a good place to put it -- where it was likely to be found). Anyway, the two things that I've done are essentially both article/category splitting efforts (see first two sections below):

Cheers! --Wrye 04:16, 31 May 2008 (EDT)

Glossary

This is a conversion of the Category:Glossary page to single page article. I copied most definitions to it, while expanding some. I have intentionally left some articles out which didn't really seem to belong on a category page. If this page is well received, then the old article pages that have been completely included should be deleted as should the Category:Glossary category itself. --Wrye 04:16, 31 May 2008 (EDT)

I haven't seen any objections, so I'm preceding with Prodding old category entries. --Wrye 20:17, 5 June 2008 (EDT)

Here's what I'm doing:

• I'm prodding all small pages that have been fully incorporated into the new Glossary. And I'm changing other pages that formerly pointed to these pages to point to Glossary instead.
• If an article is too long to fully incorporate into the Glossary, then:
• If glossary has a short entry, then the the short glossary entry will have a "See" link to the main article. Links to the full article will be left pointing to the full article.
• I'm removing the full pages from the glosssary category. If they're full, then they're not "Glossary" entries. After all, many pages on the wiki define stuff. If one started including "all pages that define stuff" in the Glossary, then the glossary category would contain 1/3 of the pages on the site. Which would be redundant -- after all defining stuff is a lot of what a wiki does.

--Wrye 21:31, 5 June 2008 (EDT)

It looks good, very good. I wasn't too sure at first, but I think you're right, this does look better.

Dragoon Wraith TALK 11:14, 6 June 2008 (EDT)

Data Files

Category:Data Files - I've removed the article type text off this page into several articles TES Files (actually a major rewrite) and Windows Vista. I've also added a new article: Esp vs. Esm. I've then gone back and changed Category:Data Files to be just an manual index page. At which point I hit the "too many index pages" and "category pages should not be treated like articles" problem. So I figured I had done enough damage and stopped. :evil:

One point here is that the TES Files page is a good introduction to very basic issues in modding. Moderately thorough and not too technical (unlike e.g. the Modding Terminology page, which is a bit thick.) IMO, TES Files probably should be linked to directly from Getting Started or something like that. But I looked at the HTML code and went "eep". So I left it alone. (And again, enough damage already.) --Wrye 04:16, 31 May 2008 (EDT)

I haven't had a chance to read everything here, but I agree that the TES Files page ought to be on Getting Started, and will put it there. But where did you run into ugly HTML? The only pages with that are the Portals and the Main Page... (I used tables for formatting, a major no-no in this Web 2.0 world of ours)

Dragoon Wraith TALK 11:33, 1 June 2008 (EDT)

Complicated Html -- just the portal pages. --Wrye 18:00, 1 June 2008 (EDT)

New Templates

I've added link templates: Template:PES and Template:Tesnexus. Idea is to make adding such download links easier. These turned out to be useful at UESP after a while. --Wrye 18:18, 31 May 2008 (EDT)

I've added a Prod (Proposed for Deletion) templage: Template:Prod. --Wrye 20:06, 31 May 2008 (EDT)

So, Prod or our current method - mark it as deleted and if it needs an explanation put it in the talk page?--Haama 12:44, 2 June 2008 (EDT) Discussion is below in the "Deleting Articles" section.--Haama 14:21, 2 June 2008 (EDT)

I've combined the link templates into one modular (hopefully for other sites as well) template.--Haama 17:03, 2 June 2008 (EDT)

Okay, but {{PES|1234|Some Mod}} is shorter (and thus easier to create and edit) than {{Mod Link|PES|1234|Some Mod}}. --17:21, 2 June 2008 (EDT)

I'm with Wrye on that one.

Dragoon Wraith TALK 17:53, 2 June 2008 (EDT)

True, but this is easier for us to keep track of - one page instead of several. Either way.--Haama 17:55, 2 June 2008 (EDT)

Oh, right, back to the original reason - do we really need a "Link Templates" category?--Haama 17:58, 2 June 2008 (EDT)

The individual link templates could all use the general link template, that way it's short to use in an article and easy to maintain/change because it's all on one page. Everybody happy, except Elric and Monica maybe, because we don't have a link template for ElricM.com yet.

--Qazaaq 18:09, 2 June 2008 (EDT)

Not sure I follow - it's possible to have multiple templates on one template page?--Haama 18:42, 2 June 2008 (EDT)

No, what I meant was having a PES link template like Wrye made: {{PES|3508|Cobl}}, with this on the template page: {{Mod Link|PES|{{{1}}}|{{{2}}}}}, using the multiple link template you made. And a TESNexus template like this: {{TESNexus|id|name}}, with this on it's template page: {{Mod Link|TESNexus|{{{1}}}|{{{2}}}}}, also using your multiple link template. I assume that works.

--Qazaaq 18:52, 2 June 2008 (EDT)

Keep in the mind that the server has to dynamically process all templates each time the page is generated. More complicated templates means more cpu consumption. There are some compensations (e.g. for non-logged in users the wiki may be using page caching, which cuts down on processing requirements).

At this time this is probably not an huge problem, but consider: Fallout is coming. If that has a construction set, then it will be docced on same server as this one. And will be heavily hit when fallout comes out. Best to establish good policies now rather than have to reverse them later when/if the server gets crushed. (Don't want bethsoft turning off the CS Wiki server because it's eating too much cpu. :)) --Wrye 19:07, 2 June 2008 (EDT)

So, that would still require creating each template - the only real difference is whether the link is on one page or copy/pasted between each page. The latter is easier for new people to add - ehh... don't really feel strongly one way or the other.--Haama 21:33, 2 June 2008 (EDT)

Message Spam Consolidation

I've cleaned up Message Spam (formerly Avoiding Message Spam) and integrated Preventing messages (which I've now Prod'ed). I've also gone through to individual pages and removed redundant "how to avoid message spam" from them (instead, linking to updated page). Observation on this is that some info is common and should not be repeated on multiple pages. --Wrye 20:10, 31 May 2008 (EDT)

Appreciate the clean-up and agreed on the links - how did you find the places to replace the links? Something like that has long been on my "wish I had the time" list, but you seem to have done it rather quickly.

Dragoon Wraith TALK 11:35, 1 June 2008 (EDT)

Finding usage... I think that I just replaced the on five or so relevant command pages (equipItem, unequipItem, etc.). I may have also searched on "message spam" and looked at the pages that linked to those pages. --Wrye 18:03, 1 June 2008 (EDT)

No Fluff Scripting Portal

Moved to Talk:Portal:Scripting. --Wrye 21:31, 29 June 2008 (EDT)

How do we like it?

Would comments be more appropriate here or on the scripting portal talk page?--Haama 13:56, 8 July 2008 (EDT)

Comments on scripting portal talk page would probably be better. You might want to PM me too if you want my attention. 96% retirement means I start ignoring stuff (like my my watchlist on the CS wiki :D). --Wrye 18:17, 13 July 2008 (EDT)

Deleting Articles

I'm using the Prod (Propose for Deletion) template a lot.

• Tutorials - There seem to be way too many tutorials. Especially tutorials which are: incomplete, erroneous, bylined, chatty, poorly written, not useful. (The chatty tutorials are really getting on my nerves.) I'm prodding those that don't look useful.
• Usage Pages - At some point someone went through and documented where functions were used in various scripts. Which is completely pointless since the same info is more readily available through use of the Text Search command. I've prod'ed one of these pages (AddSpell Reference), but really all such pages ought to be summarily deleted.

--Wrye 21:50, 31 May 2008 (EDT)

Excuse me - where is this Text Search command located ?? Answer : Edit>Find Text - see hereUDUN 10:05, 11 October 2008 (EDT)

Agreed on both counts. The reason such has not already been done is because while many tutorials are poorly written or incomplete, most would be valuable written correctly. So we mark them with the delusion that we'll get back to them, fix them and/or finish them. Of course, that hasn't happened.

As for the function references, yeah, I don't know who did that or why. Seemed like an awfully large amount of work to just throw out; someone might have found it useful, was my feeling on it. But if no one finds it useful, it could be deleted.

By the way, first off, we had {{afd}}, which you could have co-opted for this had you wanted, further, while it is probably not a large concern, GStaff does delete everything in the Articles for Deletion category without checking what is on them. So if these are only proposed for deletion, that may not be the right place for them, as they could be deleted without input from anyone else.

On the other hand, GStaff doesn't come by all that often, so the risk is pretty low.

Dragoon Wraith TALK 11:44, 1 June 2008 (EDT)

Afd? Oops. Missed that. Hmm... Could two stage it. Afd for "this really should be deleted" and "prod" for "think this should be deleted, but maybe wait for some vetos." --Wrye 18:12, 1 June 2008 (EDT)

Agreed. I'm making a pfd category.

Dragoon Wraith TALK 18:43, 1 June 2008 (EDT)

I've added a timer to Prod so the article will automatically be added to the Articles for Deletion after 14 days. I still need to make the template page itself display the correct info (instead of afd...) (fixed--Haama 15:09, 2 June 2008 (EDT)), but it works. I also placed a countdown at the bottom of the template. Is 14 days long enough, too long?--Haama 14:25, 2 June 2008 (EDT)

Two weeks sounds quite perfect, actually. Could you add a variable that can be set, with a default of 14 days, though? That might be useful.

Dragoon Wraith TALK 17:01, 2 June 2008 (EDT)

Cool. Sounds perfect. 14 days seems like a good default to me. --Wrye 17:25, 2 June 2008 (EDT)

I can add a variable, not sure how to make a default - let me check.--Haama 17:19, 2 June 2008 (EDT)

Done - I added some extra stuff so it'll say "tomorrow", "later today" when appropriate.--Haama 17:56, 2 June 2008 (EDT)

Oops, the tag didn't quite work as expected before. It would "reset" itself on the 1st of each month, didn't notice because I made the template on the first of June... Should be fixed now.--Haama 14:43, 19 July 2008 (EDT)

Deprecated Articles

I've also established a category and a template for Category:Deprecated Articles (and {{Deprecated Article}}). This is for articles that are deprecated for some reason (erroneous, undesirable, outdated, etc.), but which we don't want to delete for some reason (historical, contains some useful info, etc.) --Wrye 18:12, 1 June 2008 (EDT)

Colons and Namespaces

When definining new pages under a namespace (e.g. Category or Template), you should not include a space after the colon. E.g. a name should be Category:Something, not "Category: Something". The main reason for this is that "Category: Something" doesn't define a category named "Something", it defines a category named " Something" - i.e. the name starts with a space instead of "S". This will cause problems when the page is alphabetically sorted. It's also likely to cause various other minor problems with current or future versions of wiki software. (If you'll poke around Wikipedia or UESP, you'll see that colons are not followed by spaces.)

Some background. MediaWiki divides articles into different namespaces, e.g. Category, Template, MediaWiki, etc. Each primary namespace has a second talk namespace associated with it. With one exception, these second namespaces are always the base namespace + " Talk" e.g. "Category Talk", "Template Talk", etc. The exception is the main namespace which has no name, and the corresponding main talk space, which is simply "Talk" instead of " Talk".

Namespaces are defined at a low configuration level of the wiki. I.e. you can't just create a new one by including a colon in the name. E.g. if you create a page named "Foo:Bar", then:

• if there's a namespace named "Foo", then this will become an page named "Bar" in the "Foo" namespace, but...
• but if there're not a "Foo" namespace", then this will become an page with the name "Foo:Bar" in the main namespace.

Again, if you created a page name "Foo: Bar", then this would become a page with the name " Bar" (leading space) in the "Foo" namespace.

There's another feature of MediaWiki which is (partially) active here: Subpaging. If you define a page with a '/' in the title, e.g. "Foo/Bar" and if the page "Foo" exists, then Foo/Bar is considered to be a subpage of "Foo". A practical result of this is that a backlink will appear on the subpage (e.g. User:Wrye/Demo). Well, should appear. For some reason the backlink is appearing user space pages, but not in main namespace pages (I imagine that backpage linking needs to be activated for the main namespace).

Hence:

• Don't use colons in the names of articles. Colons should only be used to designate namespaces.
• When creating pages in namespaces, don't put a space between the colon and the next word.
• When desiring to create page hierarchy, use '/' to define subpages.
• Ask GStaff to turn subpaging on for main namespace.

--Wrye 19:17, 1 June 2008 (EDT)

Will e-mail GStaff about sub-paging.

Also, stylistically, it is favorable (at least in my opinion) to include the space in links. You can do this with actual namespaces (Category:, Talk:, Help:), but not with 'pseudo' namespaces (Portal:, most notably). So [[:Category: Getting Started]] will work perfectly, and not cause the problems Wrye has mentioned above, while [[Portal: Scripting]] will not. Obviously the exception is when you are using a link to create a new page.

Dragoon Wraith TALK 21:09, 1 June 2008 (EDT)

Testing: 1) Category:Proposed for Deletion and 2) Category: Proposed for Deletion (second one has leading space). If you mouse over these, you'll see that auto-generated link has no space after the colon. Similarly if you try to create a page where the name (after the namespace) starts with a space, the space will be removed.

Apparently the wiki software automatically corrects the page name, both while creating and while linking to remove the space. Which is convenient, but I would regard that as the wiki software fixing a user error. If you'll check Wikipedia (e.g. Wikipedia:Categorization), it never uses "Foo: Bar", but rather always uses "Foo:Bar" in the text of the link. So for MediaWiki based wikis, the stylistic standard is that links that display the namespace should not include a space after the colon. --Wrye 00:32, 2 June 2008 (EDT)

Subpaging has been enabled on the Main namespace. I also requested the Category, Help, and Project namespaces, but I have not tested these as of yet.

Dragoon Wraith TALK 15:32, 3 June 2008 (EDT)

Cool. Yep, works now. E.g. MessageBox_Tutorial/Centralized_Decision_Catching. --Wrye 17:30, 3 June 2008 (EDT)

Yes, very cool - that was the original intent. I'm removing the bits and pieces from the Scripting Tutorial category. I guess the same needs to be done with the Kits tutorial.--Haama 19:03, 3 June 2008 (EDT)

Function Listing

Reorganized the function listing.

• All functions are now listed in a new raw format at Raw Function List. This listing has fields for: function name; source (e.g. CS, CS 1.2, OBSE 10, OBSE 14, Pluggy 42, etc.); type (Math, AI, etc.); Description.
• To add new functions, edit the raw format page to new functions, etc. Then extract that list to a txt file on your machine, run a Wrye Bash command line command, and voila, it generates several processed files which can be pasted onto various pages.
• Auto-Generated Text:
  • All Functions
  • CS Functions
  • OBSE Functions
  • Pluggy Functions
  • TSFC Functions

What's Not Done

• I have not yet created an "Organized by type" page, but that would be easy - once the type info is entered into the raw data - right now, it's (mostly) not. If someone can take on that chore, I'll add some more code to the bash function and generate the page.
• Currently the auto-gen function is now dumping type info. That could be changed easily though. (I'm a little concerned about cluttering the page, but putting it in a column between function name and description would probably work well.
• Still need to release the Wrye Bash update.

Advantages

• All function information is entered in place (Raw Function List).
• Function data can include source version number, function type and brief description.
• Auto-generated pages are easier to read and search. In particular, a given set of info (e.g. All function, or all OBSE functions) is not spread across several pages.
• No need to have separate categories for separate version releases. Version info is shown for each function (so long as the data is entered). As I think we're seeing the separate categories approach is not scaling well for continued releases of OBSE. (And it's so unworkable for Pluggy that it hasn't even been attempted.)

Disadvantages

• A little more work than just assigning a category.
• Need to use Wrye Bash to do auto-generation.

Suggested

If this is well received, then I would suggest discarding at least some of the current function categorization. Maybe discard a lot of it. E.g. an OBSE function might be categorized under "Function" and "OBSE" and that's it (NOT OBSE 12, OBSE 13, etc.)

Style Sheet

By the way, I've updated the Wiki_User_Style/Liquid_Design.css page. If you've imported that, you should see the functions appear in a graphically attractive table.

PS: We really ought to get commonly shared style stuff copied to MediaWiki:Monobook.css.

--Wrye 05:40, 2 June 2008 (EDT)

Looks great, Wrye. Agreed that version categories for OBSE are unnecessary - the Function Types categories are still useful, IMO (in that I actually use them constantly for my own work, so I am very strongly opposed to deleting them).

As for style changes, changing things in Monobook.css wouldn't help, the Wiki uses ESstyle.css. Unless I'm misunderstanding you.

As for changing the default CSS files, yes, but first... There is something of an issue with the Liquid Design in that you cannot use a Scroll Wheel if the mouse is positioned over the 'fixed' elements on the left. Without these elements, however, the black borders do not work.

Changes to the HTML would be necessary to fix that, and I'm not sure that Bethesda would be willing to do that. Which makes it difficult to propose changes to them.

Things like tab-highlighting, my code-box stretching fix, and your Table changes might be possible to have added to the default style. I'll look into breaking those out of the unified code and proposing that to Bethesda.

Dragoon Wraith TALK 10:19, 2 June 2008 (EDT)

Haven't had a chance to look at this, but as a quick vote - I prefer the version categories as it makes it easier to determine at a "glance" which version is necessary for a script. The OBSE team tends to add in groups, so you can get a gross idea of what group they added by looking at them all (which wouldn't be easy in list format).--Haama 17:15, 2 June 2008 (EDT)

I'm not sure exactly which info you're looking for. If say, you're looking at the function page and you want to know which version of OBSE introduced it, then you don't need a category for that. I'm thinking that an OBSE Function template with appropriate fields would allow entry of this info in an easy standard way. Something like {{OBSE|14|AI}} could be used to generate the categories, and a standard header with OBSE version and function type info. (Of course, such a template can also sidestep the category issue since it can be used to autogenerate categories.) --Wrye 20:12, 2 June 2008 (EDT)

Regarding the scrolling that's broken on the liquid user style, I've had the chance to look at that and it turns out it can be solved by using monobook as base instead of esstyle. I've been a bit short on time lately, but I'll see about finishing that this week. You'll have to change your style to monobook in preferences to work, but that shouldn't be much of a challenge if you've imported the user style on your css page already.

I don't think it's a good idea to add something to the liquid user style, we should either change the name or make new pages to import for changes like this. Maybe we should make a general user style page where we can define new CSS classes and id's for pages like this and inform users to import that separately with liquid user style to import that separately.

--Qazaaq 18:24, 2 June 2008 (EDT)

Problem is that most users will likely miss it. (I didn't even know about Liquid Design until a few days ago.) I think that best thing to do is make changes in liquid design and then push (appropriate elements) down into ESStyles.css if they're well received. (Hmm... Why do you think it's a bad idea to push stuff into Liquid Design?) --Wrye 20:12, 2 June 2008 (EDT)

How do we like it?

It's been up for a while now - thoughts? Personally, I prefer the old functions list - you could see more on the page, the names 99% of the time give the description.

Also, now that I've tried to not use the OBSE version categories I know why I liked them - When a new version of OBSE I tend to play with the functions, all around the same time. When I need a function, I remember that I played with it recently, or which version it was, before I remember what type of functions it was. So, yes, I still like the version categories.--Haama 13:38, 8 July 2008 (EDT)

COBL (and other mod mentions)

COBL, especially recently, has been geared more towards modders - complete with "functions" (activators), containers, systems, etc. for modder use. I've noticed Wrye has placed COBL tidbits on pages where it helps, but is that what we want to do? They usually take a line or two, so they haven't been too bad. However, there are other ways to handle it - don't put it there, have only a "See Also", etc. I lean towards a "See Also" link, mainly because the modder will need to go through other decisions then simply "Oh, here's an easier way to do it" (erm... and to centralize the COBL info so upgrades won't require 2 different wikis to update?), and if it would be better for links to multiple mods.--Haama 13:00, 2 June 2008 (EDT)

Inline mentions with links are acceptable as long as they are mostly pointing it out, not, say, suggesting it, I suppose. To make it clear that this is a significant choice a modder must make (sadly, adoption of COBL has not been nearly as high as one might hope), I think it is important to have things on a separate page.

I have not checked the individual mentions themselves, so I can't comment on those.

The only mention I am currently aware of is in the Kill function page, which mentions the mod that lets the player ignore the Dark Brotherhood. Actually, with SetPlayerProjectile, the Kill page perhaps should be updated with information on it... I'll look into that when I get home from work.

Dragoon Wraith TALK 17:00, 2 June 2008 (EDT)

Searching... There are five mentions so far. (BTW, there's also the ESM Math Library. Although Cobl is eyeing it hungrily. Might be useful to include in Cobl for modders who don't want to use OBSE math functions.) :))

Anyway, I would argue that Cobl, much like OBSE, is a utility that enables modders to do things. Hence it's appropriate to document here. The main reason not to document it here is that its documentation home is on UESP. However, I think that there a number of places where it's going to crop up almost unavoidably, especially for Advanced How Tos. E.g. Adaptive Mods, Walking Through Inventory Items, etc. An expansion to modding etiquette would also likely mention it, since Cobl provides mechanisms for solving several compatibility problems. --Wrye 20:28, 2 June 2008 (EDT)

COBL is somewhat odd in that it is simultaneously a mod and a utility. Many users do use COBL just for COBL, as I understand things, but then it's also useful for modders for a great variety of reasons.

The point is that we do not need the full documentation of COBL here - just the general purpose utility functions of COBL.

But I agree with the comparison to OBSE. COBL is a very similar utility and there is no reason not to treat it the same way. Ideally, COBL would be part of a default installation, something everyone uses. Considering that it is a relatively simple install (compared to OBSE, even, which is in itself quite simple), this should be possible, but we need to kind of get it out there, I think.

(side note: Something like COBL should be started immediately upon the release of TES V)

Wrye, I think it kind of goes without saying that you're kinda on point here. I know that you are quite busy, and I certainly don't want to intrude on that, but if it is to be done, it may have to be by you. I certainly don't know enough about COBL to write it up.

Dragoon Wraith TALK 21:26, 2 June 2008 (EDT)

'See Also' Sections

I find these links incredibly useful but many pages are lacking them, or lacking the obvious ones that would go with those pages. I have been adding them haphazardly to pages that I often view, but it would be good if it were general practice when adding new pages to add the appropriate See Also links to those pages.
--Quetzilla 13:28, 14 July 2008 (EDT)

I agree, but new pages are often added by people that are unfamiliar with the Wiki. It's hard to add see also links if you don't know what's available. This also counts for internal links, see the active discussion: Community Portal/General Cohesion Initiative.

--Qazaaq 07:47, 18 July 2008 (EDT)

Revamp of the 'Categories' links

I was looking at Haama's new Category for the Projectile functions in 0015 and it struck me that in some cases we're going about categories the wrong way. Currently you have to click a link at the bottom to get directed to a category page, but in many cases where the number of functions in a category is small it would be better if the category list was included inline via a template -- similar to the thing at the bottom of this page (not the best example but hard to find one not on a long page). That way the user can see related functions visually, and we could do away with a lot of the See Also sections (which are a pain to create individually anyway). Thoughts?
--quetzilla 11:50, 23 August 2008 (EDT)

I've made an example template for the Projectile Functions to show what I mean. Can something like that be auto generated from the categories pages? Either way I think it looks good, but I'm still a wiki noob :P.

--quetzilla 12:46, 23 August 2008 (EDT)

Absolutely agreed. This doesn't make the categories redundant, but we should also include these things on the bottom of various pages. Good idea quetzilla!

--Qazaaq 13:16, 23 August 2008 (EDT)

I think it would be too many links - you almost always want a part of the category, not the whole category. Also, the See Also section isn't so bad and, like the rest of it, just requires a bit of cut and paste.

One similar issue, though - would it be helpful to write a "category" template that would automatically include each level of function categories (i.e., Functions, Magic Functions, Magic Functions (OBSE))?--Haama 13:21, 23 August 2008 (EDT)

I suppose listing an entire category is too much, but listing related functions makes the Wiki easier to navigate. This is different from the See Also section as this will only list pages in the same (unexisting smaller) category. I'm not talking about listing the categories we have now, but listing all Model/Icon/Biped path functions under those functions, that kind of thing. That way we can display this information in an organized way without making splitting up the categories too much.

--Qazaaq 13:43, 23 August 2008 (EDT)

Yes, I don't mean the whole category when there are like 20-40 functions, but for groups like the projectile functions it makes it so much easier to see what's related to the function you are looking at, giving you an idea of what you can DO with the functions rather than just what the functions are. I don't know if we have the ability to show/hide stuff like the example on wikipedia, but I think templates like the sample one would be much easier to maintain than see also links, when the function is in a group. You could still use the See Also links when a function has something to do with a function/article outside of it's category.

One good example here is the GetArrowProjectileXXX functions. Just from looking at those pages it would not be immediately clear that there are 5 other similar and related functions, and without the template the only way to illustrate that is to go in and place See Also links on all 8 pages.

--quetzilla 14:22, 23 August 2008 (EDT)

Create templates as you find convenient, but I don't think it should be a general rule or would be a good idea for most functions.

For example, DW linked GetArrowProjectilePoison with GetArrowProjectileEnchantment and GetArrowProjectileBowEnchantment because they all relate to the extra effects that an arrow can have. These 2 are important to know, and should have large, flashing neon signs pointing at them. There are still 6 other projectile functions, some are usually useful (GetProjectileType, GetProjectileSource) and some not at all or only in specific situations (i.e., SetPlayerProjectile). These other 6 would only dilute the importance of the first 2, as you would have 8 functions to look through instead of 2. It can quickly spiral out of control, as well - should we include some/most/all magic functions on the GetMagicProjectileSpell article?

Ok, that was enough of a warning - go for it. Place the templates in a common category (maybe "Function Groups") so we can find them, others can use them, etc. I'll look up some more on the templates - it would be cool if we could hide/show them (and maybe even auto-populate the template onto the necessary functions).

--Haama 15:22, 23 August 2008 (EDT)

I see that point. So how about this, See Also links for the functions specifically important to the function in question, and below that a template table of generally similar functions. That way we can easily slap the template on to similar functions (the more links per page the better, imho), and then individuals can add specifically important stuff for each function.

I'll have a hand at it and see how it turns out -- will be easy to undo since it will basically be 1-2 lines per page max.

--quetzilla 16:23, 23 August 2008 (EDT)

I'd prefer not to make any rules about what should go into See Also and what can be in a table at the bottom of the page. Let's just see how it goes.

--Qazaaq 17:06, 23 August 2008 (EDT)

Meant it more as a suggestion...

--quetzilla 17:55, 23 August 2008 (EDT)

Then I misunderstood. I don't think we should remove the functions from the See Also list if they're also included in the template table. I guess that's what you're suggesting, so I agree.

--Qazaaq 18:02, 23 August 2008 (EDT)

Found two different templates that claim to show/hide

1. Template:Hide
2. Template:Show hide box

Brain's a bit tired and fried at the moment, so I'll check them out after dinner. If anyone else wants to look, I suggest Google to wiki trees...
--Haama 19:13, 23 August 2008 (EDT)

The TOC box already show/hides... do we not have the code for that?

--quetzilla 21:26, 23 August 2008 (EDT)

Looking through the links, they suggest a Navbox... these are freakin' awesome. Qzilla, if you follow the templates to [1] and edit that page you'll see the bottom box of your link is a Navbox, so this is what we're looking for. Now if we can just get it to work.

--Haama 23:24, 23 August 2008 (EDT)

Tried the three different templates in the Sandbox - None of them worked. I just stumbled onto Collapsable Tables - might work but that's it for me for tonight.

--Haama 23:58, 23 August 2008 (EDT)

The show/hide thing won't work because it depends on JavaScript from this page: MediaWiki:Common.js, which is empty as you can see. We can't edit it. Of course we can request it, but is that necessary? I mean, the templates will work without show/hide if we copy them and I don't consider showing and hiding very important.

Something to look into is user specific JavaScript, like user styles: Special:MyPage/esstyle.js. If it works we can test things there and eventually ask GStaff for the changes to MediaWiki:Common.js.

The NavBox looks good, that's what we need here, but there are a lot of other Wikipedia templates embedded in that template. I think it's easier to recreate a similar template locally.

--Qazaaq 08:55, 24 August 2008 (EDT)

Already asked about UserJS when I asked for UserCSS. That would be a definite 'no, absolutely not.' Much more likely for them to incorporate things into Common.js. Though I suppose if you want to research the potential risks/rewards of UserJS and present it to them, you might have a chance - I just kind of asked, without making much argument for it. You're welcome to try if you like.

Qazaaq and Haama, do you guys have Gstaff's e-mail address?

Dragoon Wraith TALK 11:36, 24 August 2008 (EDT)

Navbox is looking good, Qazaaq. DW - yep, I still have the addresss, but no - I can't see the template code on the Diablo wiki.

--Haama 17:07, 25 August 2008 (EDT)

Oh, I missed this. Yes I have his address, I think he sent both of us an e-mail before making us sheriff. But anyone can e-mail him through his profile at the forums.

As I said, I don't consider JavaScript very important. Why do you need a hide button on something that's on the bottom of the page? I could imagine you'd want to hide a very long ToC at the beginning of the page, but something at the bottom?

I'm quite pleased with how the Navbox looks now and I don't think it needs any additional functions. At least not for how it's used now.

--Qazaaq 17:24, 25 August 2008 (EDT)

On "Hide" - sounds good.

On Gstaff's e-mail: also good.

On permissions at the BB - drr. They're kind of control freaks. Some of it makes sense, other things I wish they'd change. Aaannnyyway, I put a copy of it at User:DragoonWraith/Template:Categorize.

Dragoon Wraith TALK 17:33, 25 August 2008 (EDT)

Hide - ideally it would be nice, and I would love to see people connect any set of functions they wish, give it a good title, and add it to the appropriate function pages/templates. Realistically, there isn't enough input to expect this. Might be nice for big categories, but not really necessary.
--Haama 00:04, 26 August 2008 (EDT)

Categories, smategories

Categories on this Wiki have been screwed up ever since Bethesda released it to the public. This has always been the case. Wrye's been crusading against it for a long time, and from some experiences I've had working on a brand-new Wiki, he's absolutely right. Categories are poorly used on this Wiki and it makes things very confusing for new users. Unfortunately, it will be exceedingly difficult to change anything at this point. Maybe if we had started from the get-go, but even then I'm not sure it would help.

By the way, at some point I intend to bring over some of the things I learned from that Wiki, including two Templates I made that I think make categorization and navigation much easier. If anyone would like to look at that Wiki, check here.
Dragoon Wraith TALK 15:09, 23 August 2008 (EDT)

You mean this - I was wondering how to do that :)

--Haama 15:25, 23 August 2008 (EDT)

That and this, really. Mostly, it's just a matter of using template arguments. The source code should be visible even for non-members, I think... If not, I can move anything from there over to here.

Dragoon Wraith TALK 16:44, 23 August 2008 (EDT)

Very nice, but I have to ask: Where can we use this? You're not suggesting we categorize the functions again, are you?

--Qazaaq 17:06, 23 August 2008 (EDT)

No, but the Categorize tag could be used to make doing something like that much easier. In case at any point we want to recategorize.

The Bc template would probably be more useful. In reality for most of this Wiki, the categories perform the same operation - you can click the categories that an article is part of to "go back" and you click on categories contained within an article to "go forward". This is kind of a bastardization of the Wiki software, though, and is not intuitive for new users.

What I'm really suggesting is that I wish we, or Bethesda, really, had organized things differently in the beginning. But all of us, Bethesda included, were complete Wiki newbs when this started (and in reality, we still are, from what I've seen on Wikipedia - they have an extremely fluid system, even if it is abused by their own form of bureaucracy), and that didn't happen. Now, changing everything is a massively difficult proposition...

I wonder how flexible Wiki bots are, and whether or not we can use them here. That's something I've been meaning to look into, but haven't gotten around to. There are a number of reasons I'd like to do that...

Dragoon Wraith TALK 18:05, 23 August 2008 (EDT)

I think that's what we all wish. The template thing you made there is perfect, if we had something like that here two years ago, when we first started with the OBSE functions, things would look very different.

Wikibots is something to look into, that's the only thing we can do here really. Manually changing things is not a realistic option.

--Qazaaq 18:35, 23 August 2008 (EDT)

Did some testing with the Python bot today and it seems to be working. You can set the minimum time the bot waits between saving pages, but if we're going to replace a lot we should probably notify GStaff.

I'm surprised by how easy it is to set it up, and that it works without safety. You can easily do a lot of damage with this thing...

--Qazaaq 07:37, 26 August 2008 (EDT)

Bethesda thread upload?

1. Do we want to place threads on the wiki, in case they become old and destroyed?
2. If so, how? The short and simple download the x version (word or html) and upload doesn't really work.

--Haama 10:07, 22 November 2008 (EST)

My concern initially would be permissions, but...

Why doesn't the "Download HTML version" work? I mean, sure, it won't be as simple as straight-up copy'n'paste from the file to a Wiki page, but it probably shouldn't be that hard.

I'll try tinkering with it. Gotcha thread, yeah?

Dragoon Wraith TALK 16:05, 22 November 2008 (EST)

How is this? (be sure to add the import to your style sheet and clear your cache)

Dragoon Wraith TALK 17:12, 22 November 2008 (EST)

Looks good, did you change any of the HTML?

--Qazaaq 11:00, 23 November 2008 (EST)

Generally, no, just copied and pasted the entire '<div id="print">' block. I did change the coding for the top of it, for the link to the original thread, but that's minor. The code of every post remains the same.

Unfortunately, there is no (easy) way to support the emoticons or "snapback" tags. Other than that, though, it looks pretty good to me.

Dragoon Wraith TALK 12:30, 23 November 2008 (EST)

It doesn't bother me much. Its an just an archive, if it's readable and easy to update it's good enough. Good job!

Maybe a template could handle the text at the top. That would be something to think about before copying more threads.

--Qazaaq 17:36, 23 November 2008 (EST)

Or even an explanation of what to change, if it's pretty easy. Still haven't had a chance to look at it (had to handle some COBL stuff) - should be able to check tomorrow. Nights
--Haama 03:00, 24 November 2008 (EST)

OK, process:

• Go to any thread, click Options, click Print This Topic
• The printer-friendly version of the thread will load. In your browser, use the View Source command (View -> Page Source in Firefox; something similar in other browsers)
• In the print-friendly page's source, you'll see some code, a comment about how it was generated by IPB, and then an ungodly amount of style changes. Scroll down a lot to the end of the style changes (marked by </style>), then after some JavaScript (<script>...</script>), the header section ends (</head>) and the body section begins (<body>).
• Just inside the <body> tag, there is a tag that reads <div id="print">. This div does not get closed until the very end of this thread (with a corresponding </div>), just before the </body> tag. Copy the entire <div id="print"> block (or, in other words, the entire contents of the body section), and paste it into a Wiki page.
• The top of the thread has a single <h1>, <h2>, and <h3> each, used for "Printable version of the Topic", "Click here to see the original topic", and the thread title, respectively. These three should probably be changed to something more appropriate.
• __NOEDITSECTION__ is recommended.

There should be a template to throw on the top warning people not to edit the page; as an archive it should not be touched. It shouldn't be locked, though, so new posts can be added to the archive relatively easily (maybe lock the page after the thread itself has been locked, or pruned? At any rate, I think that should satisfy permission concerns. I don't really have time to work on that at the moment, though. For now, the template should also have the information that I tossed in the box on my test page, about the CSS. I will speak to Gstaff about possibly getting it added to the global esstyle.css once I get some feedback from you guys (don't want to bug him about adding it if we're going to want to change it).

Dragoon Wraith TALK 13:02, 24 November 2008 (EST)

Oh, by the way, apparently when you use the Print Friendly version, it replaces all hyperlinks with just the URL (I suppose this makes some sense when you want to print the thread, but the fact that it also does the same when you download the HTML version of the thread is silly), which is kind of a bummer. Fixing that would only be possible manually, I think, which is unfortunate.

Dragoon Wraith TALK 13:11, 24 November 2008 (EST)

Need working examples:

wish you all would make scripts people actually use every day while modding, instead of these useless scripts that One person in TwoComeCarry Eygpt need's , and he probablly has not played the game in over a year.

sample example scripts like:

1. Player is in combat, (need to script to get creature info, and number attacking. )
2. How to stop combat, and script creature dispositions to level where can have dialog.
3. identify creatures and script mod there animations.
4. Tell people where the script need to be attached, Object, Quest, Spell, what ever.
5. 3 lines of a script with out any understanding of where the variables came from is a joke..

if( Dogbugger.GetWithTheProgram && FroggyPoot.LostHisWay) != I'mLost 
  dosomethingstupid
endif

does not really help Oblivion starting Code Monkeys much.

I try to scearch this Wiki for good examples, and mostly all I get are Partial script pieces that don't work, or crash My Game, and leave me more confused than I was.

why has sO much time been spent on sOo little real help.

we need examples that work, and have enough code to know that you actually tested them, and that we can use to get them working.

I have found some things in here that were very useful, but for the most part it is like a 5 year old receipt from Wally world. --Taglag 19:43, 25 April 2009 (EDT)

I understand your frustration; most examples explain syntax, not semantics. Adding semantic examples would greatly increase the usefulness of the function pages, but someone will have to come up with those. There's shortage of editors and an extraordinarily large number of functions. Unless you are willing to sacrifice a large amount of your time I don't see this happening. To learn how to script I'd recommend following the tutorials, looking through the useful code section and asking for help on the Forums instead.

Last, but not least, please sign your comments with ~~~~ or the signature button in the edit bar. I've done this for the comment you posted already. (It's also custom to indent once more than the person you're responding to, as I've done here.)

--Qazaaq 17:00, 25 April 2009 (EDT)

Please, please, please, don't start paragraphs with spaces. That initiates code boxes and makes your comments nigh-impossible to read. I've removed them.

Secondly, please, use proper English grammar and spelling. We're volunteers here, and decyphering what you've written is not in our job descriptions. If you want help, make it easy for the people you are asking to understand what you are saying.

Thirdly, the game itself comes with hundreds of scripts. These should provide all the examples that you need. If you're looking for something that does a basic task, look up a script from a quest that you know does that. If you are looking for how a particular function is used, check Edit->Find Text to search for scripts where that function gets used.

Fourth, I just want to echo everything Qazaaq said, and recommend that you follow his advice.

Dragoon Wraith TALK 21:57, 25 April 2009 (EDT)

Template: Wiki Contributor added

I added a new template to the list of Templates:Wiki Contributor. Wiki Contributors are users who contribute to this Wiki and help other users by fulfilling request about page updates if they need updating, new articles if necessary, etc. (if those users lack the skill to do so themselves).
--Darkness X 12:22, 4 May 2010 (EDT)

Template layout

I suggest changing the layout of the Article Tag Templates by adding an appropriate image to those templates and changing the layout into this template's layout. All templates should have an identical layout so they could be recognized quickly. I changed the Errors Template to let you know what I mean:

--Darkness X 16:35, 6 May 2010 (EDT)

That's a good idea, but I'd suggest moving the title next to the icon.

or centering the title, like the featured template.

I moved this to the CP as other editors (by this I mean DragoonWraith, but others are welcome to join in!) may have an opinion about this.

--Qazaaq 04:47, 7 May 2010 (EDT)

Your first idea looks good! I'm going to change the layout of all the Article Tag Templates for now (until a final conclusion has been made), I'll update the templates later if changes have been made ...

I also have some experience with GIMP so I could create icons maching the CS Wiki style if you want me to do so (like I did with the bot template)?

--Darkness X 11:16, 7 May 2010 (EDT)

That would be great! You're doing an amazing job organizing bits of the wiki, thanks!

--Qazaaq 05:33, 8 May 2010 (EDT)

More Templates?

I found some interesting templates on the UESP Wiki recently. User Box Templates: templates that show personal information about a user: age, birthday, country, gender, etc...

Could this be used on this Wiki? The actual question is: do users really want to use those templates? Do they want to reveal that kind of personal information? Is this a good idea?
--Darkness X ^Talk 15:45, 14 May 2010 (EDT)

New tutorial?

I've just created a scripting tutorial, possible to see here. Since I can't even find an option to create new page on this Wiki (usually I only need to type something in Search and then choose Create New Page...), I'm leaving this to be checked by more experienced users. It's useful, not useful, needs some improvement? I'll be happy for information. - ZuTheSkunk 10:41, 1 June 2010 (EDT)

To create a new page you can search for the title. If you search for help for example, the first line reads: You searched for help

Just click the red word help and you'll be directed to the help page, which doesn't contain any content yet. You can also fill in the title in the addressbar of your browser. To create a page with the title help you'd type this: http://cs.elderscrolls.com/constwiki/index.php/help. Note that you won't be editing the page immediately with this method, you need to click the edit button first.

I don't have time to read the entire tutorial, but what I've seen looks ok. We'd be happy to have it on the Wiki.

--Qazaaq 14:28, 1 June 2010 (EDT)

Objects with tilde in their names

I don't know where to ask about it, so I'll ask it here.

I've been recently wondering about vanilla objects that has tilde ("~") in their names. This character is not shown in-game, and from what I've been able to guess, he's some sort of forced carriage return or splitting of the name field. The example of item with tilde in his name is "Cursed Viper~Bane Cuirass" with ID "SEEnchEbonyCuirassResistPoison" (it is from SI, but there are also ones from stock OB). Is it mentioned somewhere on the site? If not, then maybe someone should check it further and add such mention? - ZuTheSkunk 03:40, 6 June 2010 (EDT)

About removing bylines on mainspace articles

I don't think waiting any longer than we already have would make removing bylines any more appropriate. In two months we have given the original authors 5 years to respond; that should be plenty of time for anyone to formulate a response. I can't recall any author who has responded to this message.

However, the byline notice does not specifically warn against removal. It merely says: "Current rules do not allow bylines in mainspace articles" and calls for the original author to "comment on this in the Talk page.".

Despite this I'm not opposed to the removal of bylines from all mainspace articles. Even though we did not specifically warn against removing them at some point none of the authors have responded. That signifies nothing but disinterest, in their articles, or the byline policy.
--Qazaaq 16:57, 20 June 2012 (EDT)

On occasion, I was inclined to edit a bylined article, but was inhibited by the "courtesy is expected" text, which, in my dictionary, reads "don't touch it".

I am in favor of removing the byline and the byline notice. We could add a note to the respective talk page mentioning the original author and thank him/her for the contribution.

We must consider, also, that, being that old, many are pretty much deprecated (e.g. Linked List Tutorial and Activation Functions) while others are full of broken links (e.g. 3ds Max: Tileset)

QQuix 19:08, 20 June 2012 (EDT)

OK, a few points to consider, mostly historical in nature.

1. "Courtesy is expected" does not mean and was not intended to mean "don't touch it" – it means literally that you should respect the original author if he or she can be found. I wrote that tag originally, so I would know. In fact, we were hoping that the line would, itself, encourage authors to edit the article, since it explicitly said that they could even though it was bylined. Bylines, prior to the warning being added to the page, struck many as claiming ownership, which is not (and never has been) allowed on this Wiki.
2. While I agree that authors have had a very long time to respond, the fact of the matter is that there was never a systematic attempt to contact them, and as a result, there may be authors who have not been ignoring the notice for five years – they have been unaware of it for five years. Which is not the same thing, and moreover copyright definitely does not expire in five years even if you ignore it.
3. While the authors do not have copyright on their contributions here, they may have contributed believing that they did due to a lack of clarity here at the time. The original decision with respect to bylines was that we would give those contributors the benefit of a "courtesy copyright" insofar as they could choose to remove the page in its entirety if they did not agree with the new enforcement of the rules. Note that contributors do not generally have the right to remove their work once submitted to the Wiki.
4. We have long had a policy (sadly undocumented, most likely) of removing bylines when they are no longer accurate, i.e. that one author is not the only significant contributor to a page because later editors have (courteously) updated and improved upon it. Since this is exactly what we want people to do, it makes sense in that case to remove the byline.
5. Deprecated or simply poor articles should be deleted or rewritten, no matter who wrote them originally or what name they may have appended to them. In such cases, a rewrite would certainly qualify for byline removal under the fourth point (such a rewrite is sufficient but definitely not necessary for byline removal).
6. Dev_akm's FAQ was originally made an exception to all of the rules regarding article ownership. As a mirror of the forum thread, it actually was "his" as opposed to being a publicly-editable page. There was a brief attempt to mirror more threads in a similar fashion, which would have had similar rules, but that (as far as I am aware) never went beyond my playing with some stylesheets and templates.

OK, all that done with, I'd generally say that I'm not sure that the original decision was the right one (even though I agreed with it at the time). The fact of the matter is, authors never had any rights to what they submitted to this Wiki. While the Wiki tolerated the appearance of people taking ownership of articles (i.e. bylines), no attempt to actually exercise that ownership would have been permitted (though, to my knowledge, no such attempt was ever made, though I recall at least one contributor who stated he would have attempted it if someone had tried to edit "his" articles).

The submission page has always said

Please note that all contributions to The Elder Scrolls Construction Set Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see CSwiki:Copyrights for details). Do not submit copyrighted work without permission!

(Note the red link on CSwiki:Copyrights for the source of the original problem. This was rectified at the same time these decisions were made, which is why I faked the red link in the quote – the project namespace wasn't "CSwiki" either it was some ungodly long string.)

In all honesty, there was never a good reason to expect that bylines were OK or that articles could be owned – it simply happened that some people did it and no one stopped them, and it became something that some contributors took for granted and never read the warning in the submission window.

But it's been five years, and that's an awful lot of courtesy to extend to people who were effectively breaking the rules, for all they were most likely unaware and also were contributing to the Wiki.

So, in short, I am in favor of removing the bylines and the warnings and being done with this whole fiasco.

Dragoon Wraith TALK 21:13, 20 June 2012 (EDT)

Just throwing in my hat with the rest you guys' - In favor of removing the bylines.
shadeMe ^TALK 07:22, 21 June 2012 (EDT)