User talk:Laisren

Welcome to the Wiki! On your user page you stated there are two skins available, but actually there are three. User CSS is enabled so you can make your own skin (limited to editing the CSS), there's a variation of the esstyle with a liquid layout available here. This skin allows you to view the Wiki in full screen and also works on a smaller resolution than the original, up to 800x600.

There's always a lot to do on the Wiki, so if you're interested in helping out feel free to ask. Besides editing actual Wiki pages the Community Portal has a few discussions going on and opinions are always most welcome.
--Qazaaq 18:27, 7 March 2008 (EST)

Qazaaq - Thanks for the info, and the tips on contributing!! Best regards, - Laisren

Linking Categories

Hey, there. It's basically:

[[:Category: Category Name|Display Name]]

Example:

• Link to the Functions Category
• Category: Functions

--Speedo 12:13, 23 March 2008 (EDT)

You can find more information on Wiki syntax here.

Dragoon Wraith TALK 19:27, 23 March 2008 (EDT)

Thanks, Speedo.
Good link, Dragoon - too bad that info isn't on [1], eh? I admit I was being a little lazy in not searching for the sytax while mid-edit... I think the presentation of the link worked okay anyway though. Any chance we could occassionally use that format/ consider it acceptable in some cases? --Laisren 19:34, 23 March 2008 (EDT) p.s. Where to grab the 'Oblivion' and/or 'Daedric Runes' fonts for Windows? Sounds cool... :-)

The link you posted actually does have a link to the one I posted. I agree that that page needs a lot of work, it's high on the list of priorities right now (actually, I think it, and the other Help pages, are number 1 for Qazaaq and myself right now).

Anyway, the best place to get the fonts is here. Lots of information about it, too.

Dragoon Wraith TALK 03:33, 25 March 2008 (EDT)

re: link to link... Sorry; I was being glib. I was just sort of suggesting having the Editing info on the Editing help page itself--in a wink-wink-note-that-I'm-not-fixing-it-myself sort of way. But I did want to reassure you that I got that the info could be found. Updating the Help pages just isn't that exciting, I know... :-) --Laisren

Consistency

The changes on the SetScale were, for the most part, fine (and we could use a different template). However, I rolled it back as it was far too different from the other function pages. Generally and as of now, optional flags are marked with italics. For the most part, this is so we can cheat a bit and copy&paste directly from the OBSE command documentation when they update. As their updates usually include ~50 functions and there are already 100s of functions this can't really be changed. Anyway, a new template would need to be discussed first (and should include the ref vs. rec decision mentioned on the reference variable page).

Also, console information is not included (except for some very early articles) as you can't do it from the CS :) and it wouldn't help with modding too much. There might be some need for it in the debug category - maybe an article to summarize how you can use most functions in the console - but not on the function pages themselves. The ones that have the console info are either very old (from early 2006) or have some quirks.--Haama 03:22, 25 March 2008 (EDT)

Just by way of a quick reply:

• consistency is all well and good, but why throw out useful information in the name of consistency? Wouldn't it be better to be occassionally inconsistent if it improved the level on information available to visitors? I'm just saying that I understand your motivations, but was a _full_ rollback necessary?
• The 'template' comment I made in the edit summary was a bit of a red-herring; or at least more a thought than an actual proposal. Of course it would have to be discussed, and some sort of global application would be more work than ... well, you know.
• I respecfully disagree that Console info 'wouldn't help with modding too much' (I'm assuming you mean that in a global-wiki way)... I think we can assume the whole point of the Console was to let users debug their own mods, or experiment with mod ideas 'real-time', etc. (i.e. its primary function wasn't to just let users just cheat...). I see you do mention possibly including info in a 'debug' category, but it seems to me there's a LOT of potential overlap, as functions called as commands should work the same way, right?
• Oh, plus, I expect others would be using the commands at the console in the same way I'm using them: to gain a better understanding of thier effects, for later application in scripts... (i.e. as a learning tool).

Whaddya think? Am I convincing you that more detailed Function info would be useful? :-) --Laisren 05:05, 25 March 2008 (EDT)

On SetScale - your format for the parameter seems to me to take up more space than necessary, and it seems as if the same information could be added with Notes or simply in the description. That said, I have updated the page somewhat to add a bit more information to the Syntax version; this is in line with other functions on the site.

As someone who has done some significant web design, I can say quite unequivocally that exceedingly little comes before consistency. Consistency builds a feel for a site, and that is what allows users to become comfortable with the site and navigate it easily. The Wiki has a fair amount of trouble in this regard already - which makes sense, considering what a Wiki is. One of the primary duties of editors is to maintain as much consistency as possible. This is very important - yes, I agree with Haama's decision to revert your edits until such a time as that information could be added without disrupting the consistency of the site. It was not the information you provided, but the striking break from the usual form. There may be functions that deserve something special (CloneForm maybe, MessageBox probably), but SetScale is definitely not one.

As for changing the format used on all functions, there are over 600 of them. Even if you offered to go through them yourself, I would hesitate to recommend that since the time it would take would be immense and in the meantime things would be quite messy. We learned this lesson when we changed the organization of the scripting functions - and there were between 150 and 200 functions fewer then. And that project only involved copy'n'pasting - this would involve actual thought and effort on each page. The mess would be less, but one person doing this could take months, and that's not something I'm very much interested in seeing.

Even with it done, you would be considerably increasing the amount of time it takes the Wiki to add new OBSE functions, and that is something I consider to be a major problem.

And if your thought was to get more people involved, sir, I wish you luck. If you succeed, please explain how - I've been trying to get people involved in the Wiki for well over a year now, and so far I've only gotten maybe half a dozen to come at all, and only two were active more than a week. I'd love to see it happen, but the unfortunate reality is that it almost certainly won't.

At any rate, if you do feel strongly about this and want to make this a wider debate, I recommend that you bring it up on the Community Portal. If there is a strong community consensus on this, I will do what I can to help make it happen.

Anyway, regardless, the information was good. I appreciate the effort, and I commend you on your work. Please, please, please, don't take it personally when your edits and contributions get edited, even removed. This is not a personal thing. This is because this is a community run thing, and sometimes the community needs to move a little slower than someone's unilateral decision. On the other hand, I very much want to emphasize that we are not chastising you or scolding you or anything - I, for one, am ecstatic that you took the initiative to go ahead and do that, and I encourage you to do so in the future. Just don't take it personally if not everyone agrees with your decisions, or even if most don't agree with your decisions. Even if your new and improved parameter format does not get used, that edit did get SetScale improved, and that would not have happened otherwise.

There is one other note I'd like to bring up here - I am very much concerned by the small note you left on the bottom of the page regarding "ShareAlike" attribution - I don't know what license terms you are referring to, but I can tell you that unless they were the ones Bethesda has set for this Wiki, they don't apply and are invalid. Anything you add to this Wiki is considered the public property of the Oblivion modding community, to do with as it sees fit, and you waive any and all rights you have to it once you save your edit. The only thing you are entitled to is the History page recording your contribution, and that is all you will be allowed to have. No one on the Wiki has the right to their name on a page (actually, I will amend that; only dev_akm has that right, and only for the Oblivion Modding FAQ, granted by the special case scenario of the Wiki mirroring his pinned Forum thread), though in some cases names appear for the sake of fair credit, when the original author does not submit the information themselves. Further, no one has any right to "control" over their article - no one can prevent their contributions from being edited, nor can they later decide to remove their contributions. They belong to the Wiki, and there is no changing that. If this is in any way disagreeable, I'm afraid you'll need to find somewhere else to post.

Regarding Console Functions, they are unquestionably used for modding and debugging. Only, I'm not sure what you're going for with the Command Documentation section - I don't see it as a terribly useful list as it stands. I can't think of terribly many functions that don't work from the Console - really there are generally only the Console Functions which do not (without OBSE) work in script. If there are functions that do not work, or do not work the same, from the Console, that list would likely be more useful - but it seems to me that adding that information to the functions themselves would make more sense.

The Console Commands page should be moved to the Console Functions category - I know it's the wrong term considered outside of Oblivion script, but the distinction has never been made here and has so lost its meaning - which was not terribly significant within Oblivion anyway. Having two pages over a semantical disagreement like that seems silly. Also note the Commands section, which very much does not follow the usual definition of "Command" as you gave it on the Console Commands Talk page. That was set up by Bethesda, and I think now is too late to change them - though I suppose they could be, if you can give some convincing reasons why they should be. I'm somewhat divided by adding the Commands term to the Glossary that way - on the one hand, it seems like it should just be a redirect, on the other the Glossary could use a term like that. Ehh... I think it can stay, it's useful to have the term in the Glossary where people can find it. I'm very much open to discussion on that, though.

As far as console functions being used for debugging, that's without doubt. I don't think Haama was suggesting otherwise, but I will let him speak for himself.

At any rate, I think that's enough of this for now. The main points here are that consistency is extremely important, bylines are not allowed and nor are special licensing on your contributions, and that we probably need to talk about this Console thing some more. In addition, I would like to point out that you've added a number of great things to the Wiki, and I am very glad for having you here - and I hope you do not find this rather minor conflict to be too onerous. We very much would like to have you here.

Dragoon Wraith TALK 05:55, 25 March 2008 (EDT)

Okay, here's another attempt at providing a greater level of detail for parameters for your/everyone's consideration: SetOwnership. I've tried to a) retain, for the most part, the existing layout, and b) stear away from any console specifity. However, I think it actually takes up even more room trying to work without a table. I added this new example in the hopes it might provide some additional illumination on why a greater level of detail / specificity on the syntax might be needed... (And when you have more detail, that's where things like headings and Table of contents come in...) Things that were/are missing, on this example page and others:

• what syntax, specifically, can be used for each parameter?
• Shouldn't the leading object reference be included with the syntax?
• Are specific parameter types listed somewhere? If so, we should be able to link to them on the Function pages....
• etc.

I'm actually trying to work out a way to link to existing terminology references within the description pages, as I think it would naturally make the use of the terminology (here on the wiki) more consistent. Thanks for considering, --Laisren 06:15, 25 March 2008 (EDT)

Dragoon wrote:

As for changing the format used on all functions, there are over 600 of them. Even if you offered to go through them yourself, I would hesitate to recommend that since the time it would take would be immense and in the meantime things would be quite messy. We learned this lesson when we changed the organization of the scripting functions - and there were between 150 and 200 functions fewer then. And that project only involved copy'n'pasting - this would involve actual thought and effort on each page. The mess would be less, but one person doing this could take months, and that's not something I'm very much interested in seeing.

Acknowledged, loud and clear! I'd take back the words 'possible template idea' if I could. I should re-state my main point again though:

seems like, for a wiki, the importing of the basic reference pages should be considered a starting point. That is, it forms the skeleton on which more info is added. And the existing structure shouldn't act as a straight-jacket against adding new & useful information. IMHO. --Laisren 06:22, 25 March 2008 (EDT)

Hi, I missed this discussion before editing SetOwnership. Thanks for clarifying the params; on the other hand, probably not necessary to include info about proper use of dot syntax as it applies to every reference function. Pages on basic parameter types sounds like a decent idea. Also, welcome to the wiki. Scruggs 11:39, 25 March 2008 (EDT)

OK, I feel like crap because it's much too early in the morning and I woke up parched, with a horribly congested nose and with eyes that just won't seem to stop watering up... I just got up to get some milk and I figured I'd hit the ol' Refresh button while drinking it, then I'm going back to sleep... so I haven't read most of what you posted; I will later. But I would comment on SetOwnership, which I took a (very brief) look at - much better. I think that works out a lot better than the table. I'm not really sure that that information is necessary, but at least if some pages have it and other don't it won't be terribly jarring; stands to reason that some would need extra detail and some won't. Definitely a step in the right direction...

I'll respond to the rest of your post after I get some more sleep.

Dragoon Wraith TALK 11:55, 25 March 2008 (EDT)

A few things to reply to, so

Console commands and the scripting/functions category - I wasn't saying that console commands are useless, just that they're useless for scripting - using them in the scripting window has a different result and syntax from the console, and I think having both on one page would only confuse people. As DW pointed out, though, the bigger issue is

Generalizing - If a piece of info can be generalized it should be given it's own page and linked to. For instance, the fact that a ref is assumed for a console command when you click on an object is true for all functions. If you place the info on a page and link to it, as you suggest here, that would be great. But placing the info on each page makes clean-up near impossible. A better example of the problem would be AddItem, RemoveItem, EquipItem, and UnEquipItem - they all include info on using the double-message trick to get rid of the spam. When OBSE v15 comes out, all of them will need to be updated to mention that you can use new functions to get rid of the spam. It would be better to have them all on one place, so we (including you) can update easily and without missing a page.

Hierarchy and finding the info - You'll also notice that there's some info on console commands on the AddItem page. (It's still there because it's an old page and we do some modding every now and then ;).) If someone wants to know why their commands aren't working, they would have to stumble upon the page to find the info. It would be better to have a console overview article and point it out there. (We haven't because it hasn't really crossed our minds, and in a sense it would be need to be part of a larger hierarchy overhaul - but in this case the bandaid shouldn't hurt).

Specifics on SetOwnership - The reference field's optionality is a bit ambiguous. For spells (and console), the self-reference is assumed so you don't need to type it out, however the field is still, in a sense, required. Or at least, it's not optional in the same way other function flags are optional (especially compared to other functions like CreatureHasNoHead). I think we should leave it un-italized, for that reason (if you look at the history, I had to think about it for SetScale too). We've been doing syntax details already with pluggy functions like CopyArray, but with a slightly different setup. It does give a different feel and flow, so take a look and let us know what you think. Reference - I don't think it's limited to items, but again we take directly from the OSBE site so the syntax would be

item:ref

or to match Wrye's suggestions

itemRef:rec

As for parameter types - it would be a good idea.

Second Title - I don't think a second title is needed (i.e., SetOwnership function underneath SetOwnership). This is personal taste, so that's just my vote.--Haama 13:14, 25 March 2008 (EDT)