Talk:Portal:Scripting

Scripting Portal

This is awesome. Just sayin'.
Dragoon Wraith TALK 20:05, 14 January 2008 (EST)

Trying a few things, that's it for tonight, feel free to make your own changes (anyone).

--Qazaaq 20:08, 14 January 2008 (EST)

A few thoughts: I kind-of preferred the editable boxes to the templates. Should the 'What you can do?' list be on the portal, or should it be on a separate page (and a link on the portal)? It would be great if we could have a 'Scripting Dump' category where every page believed to contain scripting information can be placed. This would help immensely when reorganizing the Scripting category.--Haama 17:34, 16 January 2008 (EST)

With the templates I tried to remove the information from the page that wouldn't need frequent updating. I guess I wasn't really thinking, because the to do list is exactly the opposite. I moved it back.

--Qazaaq 18:40, 16 January 2008 (EST)

No Fluff Scripting Portal

Moved from the Community Portal. --Wrye 21:30, 29 June 2008 (EDT)

I'm creating a no fluff scripting portal. This is sort of public sandbox. If it's well received, this could take the place of the current portal. --Wrye

Done. Check it out. --Wrye 02:18, 1 June 2008 (EDT)

Personally, I think the scripting Portal needs something like this. The Portal design used for other things doesn't seem to work well with Scripting (or maybe at all) - Seems that too often, there's not really places for things.

That said, the Portal design does do well in visual flair (not insignificant; it does draw a users attention to the fact that it is a special page) and in compactness (perhaps not a good thing however). I also think that there some things which would make sense to have on the side, perhaps... I will look into the page more in-depth, and I may try some changes.

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

Scripting needs to be re-done in general, no face lifts are going to fix that. Both ways are good, and have their own advantages (Portal probably better for those just getting into scripting, NF for vets). Hmm... two suggestions

1. Make a NF page that is automatically created from the portal information. Essentially this would be a list form of the portal instead of boxes. Maybe we could find a way to include the description somewhere on the page in a "No include" section.
2. Make a navigation map as DW did for Functions.--Haama 17:12, 2 June 2008 (EDT)

Re Visual Flair: Portals (e.g. Portal:Arts are graphically designed to be eye candy - they're meant to draw in casual browsers, i.e. people who are just poking around. But the eclectic design ends up being vary counter to people who are more focussed, and are looking for particular information (i.e. the vast majority of CS Wiki users).

In contrast, see a typical information hierarchy at UESP:

• Main Page (Main Page. Portalish, except for simple index on left side of screen.)
• Oblivion (Index page. Oblivion users likely bookmark this instead of main page.)
• Oblivion Quests (Index page)
• DB Quests (Content page)

So assuming that user starts at oblivion page, then they've got just two index pages before they hit conten page (Dark Brotherhood). This sort of hierarchy makes it very easy to find info. Note that UESP also provide the bread crumb trails (links at top right of page) that serve the dual purpose of letting you know where you are in the hierarchy and allowing you to go back up the hierarchy easily.

Note in particular that UESP doesn't have a site map (i.e. nothing like Functions Navigation Map). The information hierarchy is clear and simple enough that it doesn't need one. (I should mention, that this sort of simplicity and easy navigation did not just happen accidentally. :)) If you're having to do a site map like that, then you know that the information hierarchy is out of control.

IMO, CSWiki does not have enough casual users to cater to. Unlike browsing an encyclopedia, modding is a complicated dedicated process. Users of this wiki arent' casual browsers, they're people looking to find specific information. The site should make that as easy as possible.

And while you might say "support both", there are two costs for doing that: 1) doing both means doubling the amount of maintenance work in order to maintain both pages, and 2) doing both adds more index pages -- which leads to users getting lost in the thicket of index pages.

Re automatic generation of ScriptingNF: The whole point of such pages (as opposed to Category pages), is that you can't generate them automatically. To get a really useful index page, someone has to go through, figure out: how to divide up the page, what pages to put where, which pages to ignore or downplay, what sort of list to use, what to indent and where, when to add some descriptive text and what. The process of doing typically also leads to some article cleanup (proding, renaming, deprecating, etc.). Doing something like this is like organizing a room. Once in a while you make a grand effort. After that you do incremental additions/changes, and then maybe after a year or so, another grand cleanup. The grand cleanup is a bit of work, but it pays off by providing very easy access to information.

Re Function categorization: Bash will be able to generate categorized pages once more category info has been entered. I think that these will be able to take the place of the most of the pages like CS 1.0 Actor functions, and therefore, those categories can be eliminated. (Here the reason for elimination is to get cut down on the bewildering thicket of index/category pages.)

Summary: My recommendations.

• Replace current scripting portal with ScriptingNF.
• Decategorize pages. In particular, discard most of the function categories.
• Introduce bread crumb/topic trails to clarify the information hieararchy.

--Wrye 19:59, 2 June 2008 (EDT)

Update: I've gone ahead and done the replacement as suggested above. If this sticks as worth keeping, then the old ScriptingNF page can be deleted. --Wrye 21:30, 29 June 2008 (EDT)

Script Question

I hope this is in the right place... but long story short, I want to make a Necromancer companion that can resurrect himself if he dies. The thing is, I want for him to wait until after all combat ends for him to resurrect. Is there any way I can do this? Thanks!

Rethinking it, I think it would be best for some kind person to fill in the blanks, so I can copy and paste. It looks right now,

"scn NecromancerCScript

begin OnDeath

Necromancer.Resurrect

Message "Necromancer has died. Due to being immortal, he will resurrect shortly."

end" --Arch-Mage Matt 21:54, 4 August 2010 (EDT)

To post code on the Wiki, either encase it in <pre></pre> tags, or start each line with a space (including blanks), like I've done here with yours:

scn NecromancerCScript

begin OnDeath

  Necromancer.Resurrect

  Message "Necromancer has died. Due to being immortal, he will resurrect shortly."

end

Also, indenting is always a good idea. Anyway, to give you a very general answer to this, my approach would be to use an invisible, persistent activator to cast a silent, invisible scripted spell when he dies, and to continue to do so every few seconds until everything hit by the spell returns false on a GetCombatTarget == player check (i.e. there are no actors in range that are considered to be in combat with the player). Once that happens, you can freely resurrect the guy. If you need more specific instruction than that, I suggest that you start a thread on the Forums - while we're happy to help here with general scripting questions, walking you through an entire script would be a little much for this page. Feel free to link to any thread you start, though, and I'll take a look at it. I think this is a really cool idea and I don't think I've heard of any companion with this feature.

Dragoon Wraith TALK 00:17, 5 August 2010 (EDT)