Why are 99% of the mods using that code instead of:
IF
Global("CheckSabrinaMatch","GLOBAL",0)
Global("SabrinaMatch","GLOBAL",0)
Gender("Player1",MALE)
THEN
RESPONSE #100
SetGlobal("CheckSabrinaMatch","GLOBAL",1)
SetGlobal("SabrinaMatch","GLOBAL",1)
SetGlobal("LoveTalk","LOCALS",1)
SetGlobal("SabrinaRomanceActive", 1)
RealSetTimer("SabrinaRomance", 1200)
EXIT
And lastly, why is there one CheckSabrinaMatch and one SabrinaMatch, shouldn't there only need to be one SabrinaMatch?
Basicaly, why can't you even use:
IF
Global("SabrinaMatch","GLOBAL",0)
Gender("Player1",MALE)
THEN
RESPONSE #100
SetGlobal("SabrinaMatch","GLOBAL",1)
SetGlobal("LoveTalk","LOCALS",1)
SetGlobal("SabrinaRomanceActive", 1)
RealSetTimer("SabrinaRomance", 1200)
EXIT
Thanks in Advance for clearyfing this.
Emzeror, there are a cople of points to make here - from a practical standpoint, the one that stands out is many mods are actually doing what you are saying and placing a good deal of conditions and setting many materials at once.
example: Dynaheir,
BG1NPC/* Set Romance Match */
IF %BGT_VAR%
Global("X#DynahMatch","GLOBAL",0)
InParty(Myself)
GlobalGT("X#DyFriendTalk","GLOBAL",1)
Gender(Player1,MALE)
!Global("P#BranwenRomanceActive","GLOBAL",2)
!Alignment(Player1,MASK_EVIL)
!Alignment(Player1,CHAOTIC_NEUTRAL)
OR(4)
Race(Player1,HUMAN)
Race(Player1,ELF)
Race(Player1,HALF_ELF)
Race(Player1,HALFORC)
ReputationGT(Player1,10)
CheckStatGT(Player1,9,INT)
CheckStatGT(Player1,9,WIS)
THEN
RESPONSE #100
SetGlobal("X#DynahMatch","GLOBAL",1)
ENDReasoning behind smaller evaluative blocks:
1. interruption of the script. Remember there are many different scripts running in a hierarchy at any given time. It is hard to imagine a long script block being interrupted, given the speed of computers, but it seems to have happened; testing indicates the most stable usage seems to be smaller targeted blocks that do limited actions, and then pass on the action to another block. This becomes much more important when folks start adding many mods - Saerileth is an example of a mod that begins to bog down materials with lots of item checks and long sequences that make it tough to play if you have many other mods installed (one of the reasons I play small, targeted installs).
Look at the BioWare™
BG2 cutscenes for a good example of this chaining of small blocks of actions together instead of building a huge block that might fail/get interrupted.
2. writing process. Most mods are constructed over time, and new ideas come and go from the writing. A new variable gats added, one gets taken away - in most projects out there, the long development time means revisions. many revisions means remembering what got set where... and what got unset. Easier to do if you are keeping small blocks well labled in the code.
3. code understanding. Some mods are built by folks who want to write and are not versed in conditional blocks or state weighted logical engine approaches (myself included - it is a long, hard road to understanding). We don't want to write what we don't understand, so we might build small blocks and make them play with eachother rather than going through tons of stuff in a big block that we have to untangle later.
4. simplicity. Less is more. and simple code is easy to search, fix, and maintain. And less to go wrong. Personally,
IF <<condition>> THEN RESPONSE #100 IncrementGlobal("MyGlobal","GLOBAL",1) END
is a solid, working approach, easily dealy with. I can set a single long block running, doing that action, and all will be well.
BUT I think it is just as easy and certainly easier to troubleshoot when everything is explicitly set>>
IF <<condition>> THEN RESPONSE #100 SetGlobal("MyGlobal","GLOBAL",4) END
Now I can textsearch for 3,4,5, and find out where I messed something up in advancing the global between dialogue and baf in a few seconds, instead of painfully revisiting all the code and rebuilding it in my mind. Simpler blocks means less to look at.
why is there one CheckSabrinaMatch and one SabrinaMatch
Nothing wrong with it at all; but having the independent variable set tells you that that particular block has evanuated, with a check in
NI or
DLTCEP. It targets an individual block very specifically.
For testing, I often put DisplayStringHead(Myself,~1~) on each block to run, advancing the number each block. It gives me an instant read of what block is misfiring. You can'tt do that with operating installs in the field, though, so the easiest way to do it is create either an advancing global that tracks the whole progression (if it is linear) or specific variables tioed to specific actions ("C-SheriHasJustKissedPC") that can be scanned for in
NI on an install in the field.
Whatever works for you and playtests out is great. The only big suggestion that has changed over the past few years about this kind of big block scripting is the change away from running all globals being set from .BCS in big huge chains of conditions "opening" a variable for a small amount of time, then "closing" it again in the same BCS. Instead, modern mods tend to use a 'ping-pong" effect between .bcs and .dlg where the script sets the variable and the dialogue closes it. Take a quick search for this, and you will find good conversations and a tutorial on it.
Edited by cmorgan, 23 February 2008 - 08:58 AM.
