Talk:Scripting Tutorial: My Second Script

From the Oblivion ConstructionSet Wiki
Revision as of 00:48, 20 June 2009 by imported>DragoonWraith (→‎More section requests)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Featured Nomination Discussion[edit source]

Great introduction to scripting - agreed?
Dragoon Wraith TALK 18:07, 24 March 2008 (EDT)

I think you shoud've made this featured a long time ago. Go ahead and make it featured already!
--DrPhil 18:30, 3 April 2009 (EDT)
Agreed
--Grosie 15:48, 12 May 2009 (EDT)
Good enough for me! Done!
Dragoon Wraith TALK 07:58, 13 May 2009 (EDT)
Great ! Though I would prefer if the article was renamed to something more general.
shadeMe TALK 18:27, 13 May 2009 (EDT)

Minor Correction[edit source]

1st) thanks for this great tutorial! Really well made!

2nd) in case of a a wrong answer the controlvar has to be reset to "0" not to "-1". I already corrected it in your last code-example. --Jeepcreep 15:32, 30 May 2006 (EDT)

for the sake of consistency: changed it in the previous code snippets as well. N.B.: Setting the controlvar to "-1" prevents to OnActivate from ever succeeding. The if-condition "==" could've been changed to "<" but then you're explanation regarding the double-equal sign would've been inconsistent. Hope this is ok. --Jeepcreep 15:40, 30 May 2006 (EDT)

Have you tested it? If so, does it still work? TheImperialDragon 16:24, 30 May 2006 (EDT)
I've tested it and it only works that way anyhow. The first version simply does not produce the desired result: setting the controlvar to -1 after a wrong answer won't get you in the If-block of the OnActive-block again (as it tested for "controlvar == 0"), resulting in the cupboard actually not responding at all, you had two chances: either give the correct answer and open it and be happy or give the wrong answer, be punished and never be able to open it anyway.... --Jeepcreep 16:34, 30 May 2006 (EDT)


Yeah, but isn't that the way it's supposed to work? I copied this from the article itself.

What do we want?[edit source]

"Before we really start writing our tutorial script we should decide what we want it to do! For this tutorial we are going to make a Riddle Cupboard: The cupboard will ask a riddle and only the right answer will open the cupboard. If the player provides the wrong answer, a trap will go off, hurting the player, and the cupboard can't be opened. That’s a fairly complex undertaking, but we will take it step by step and see that it's not so bad after all."


So I assume after one wrong answer, it is supposed to be sealed forever, unless the player reloads a save game. TheImperialDragon 16:45, 30 May 2006 (EDT)
Hrm.. haven't seen it that way - but you might be right indeed. Well in that case, I'll just change it back to the old values then. However, this does not make too much sense, this double-punishes the player, first with a lightning bolt, then with forever sealing the chest not giving him any chance of rethink his/her error.. but if that's the way it's supposed to be, then so shall it be :) nevermind --Jeepcreep 16:54, 30 May 2006 (EDT)

Hey, that's by me[edit source]

Hadn't noticed this had made it here. Neat :) And great job converting it for Oblivion, I actually learned a couple of things myself :) --GhanBuriGhan 12:56, 28 July 2006 (EDT)

Section request[edit source]

Firstly, nice job! I wondered if you wouldn't mind adding a section on the script compiler (interpretor) quirks and general things to use or watch out for? To get you started, and by way of example:

  1. Uses of space, comma and parenthesis. Arguments to commands have to be separated by spaces or/and commas. Commas are treated as spaces and are not necessary. You cannot use spaces in math expressions without parenthesis. For example, set x to a + b is not compiled correctly but set x to a+b and set x to (a + b) are. Note: set x to a-b is not compiled but set x to (a)-b is fine. (Compiler glitch.) Spaces around logical evaluators are optional, i.e. a==1 and a == 1 are equivalent(?).
  2. Use of ';' for comments and debugging.
  3. Use of Message for debugging.
  4. Matching Begin with End in blocks, and not confusing with endif.

Compiler glitches to watch for - i.e. things that the compiler doesn't pick up that will break your code!

  1. Extra arguments to functions: example if a == 3 garbage - the extra garbage is/maybe ignorred. Similarly when functions are used as arguments, e.g. set a to b*3 GetContainer garbage.
  2. Mismatched if/else/elseif/endif statements. e.g. if...endif...endif. Some of these types of error will get picked up but some wont.
  3. Buggy lazy logic. e.g. for if x == 4 && y == IsInCombat. Sometimes a set of conditions on one line do not get compiled correctly. Often best to use nested if blocks instead. Very hard to know when this has or is going to happen.

If this stuff has been covered already then feel free to remove or move this from the discussion. Instead please add a link or links to the relevent articles in your article. GuidoBot 19:24, 19 October 2006 (EDT)

More section requests[edit source]

I have checked the performance of scripts. It seems that every part of the condition is executed EVERY TIME! Please, add a note that "nested IF's could improve performance and the top-most checks should be least time consuming.

My test script source had "If(x==#)&&(x==#)&&...&&(x==#) where # was either 0 or 1 and number of conditions was quite large (as well as executed objects in-game and repeats of the script). Results:

(1) If(false)

(2) If(true)

(3) If(false)&&(false)&&...&&(false)

(4) If(true)&&(true)&&...&&(true)

(1) and (2) are fast

(3) and (4) are slow

It tells that no matter what you would do the conditions are always executed (in many scripting languages only the first false condition would be executed) and nested IF's should be used. My further tests confirmed that.

Hmm. Doesn't seem fitting for a beginner's tutorial. However, you are right - that should be on the Wiki, because we don't want people re-inventing the wheel. Cuz, uh... we knew that.
It's worth noting that in terms of reality within Oblivion, script performance is a rather negligible concern. There are very few cases where a script will impact performance in any way that is noticeable, compared to the impact of graphics rendering. That's where the bottle-neck is, and considering that, script performance doesn't even register. Just so you know.
Dragoon Wraith TALK 01:48, 20 June 2009 (EDT)