21 replies to this topic

[OneEyedPhoenix]

I have had some difficulties with the assassins described in the code below (taken from baldur.bcs, and written by ScS mod), as I described here.
What happened was that only the first of the four assassins appeared. My current theory was that I was entering a building when the script fired, so that the script was interrupted. Later attempts at debugging also revealed that if I paused the game while the game was waiting for the script to fire (2-3 seconds lag) not all assassins would appear. The strange thing though was that even if all four assassins had not been created the globals (further down in the response block) were still set, effectively preventing the script from firing again. Question is, is there another way to script this, so that we would be sure that all four assassins were created correctly?

IF
Global("DMWWC3Assassin","GLOBAL",1)
AreaType(OUTDOOR)
!AreaType(CITY)
!AreaCheck("AR4700")
!AreaCheck("AR4701")
!AreaCheck("AR4800")
!AreaCheck("AR4801")
!AreaCheck("AR4900")
!AreaCheck("AR4901")
!AreaCheck("AR5100")
!AreaCheck("AR5101")!AreaCheck("AR5300")!AreaCheck("AR5301")!AreaCheck("AR5400")OR(3)GlobalTimerExpired("DMWWC3AssassinSpawn","GLOBAL")Dead("tranzig")Global("BanditEnemy","GLOBAL",1)THENRESPONSE #500ActionOverride(Player1,CreateCreatureOffScreen("DRAKAR",0)) // DrakarActionOverride(Player1,CreateCreatureOffScreen("HALACA",0)) // HalacanActionOverride(Player1,CreateCreatureOffScreen("MOLKAR",0)) // MolkarActionOverride(Player1,CreateCreatureOffScreen("MORVIN",0)) // MorvinSetGlobal("DMWWC3Assassin","GLOBAL",3)SetGlobalTimer("DMWWC3AssassinMiniSpawn","GLOBAL",ONE_DAY)SetGlobalTimer("DMWWC3AssassinSpawn","GLOBAL",FIVE_DAYS)

[Jarno Mikkola]

IF...RESPONSE #500

Bad idea. Just put it to #100 ...

[OneEyedPhoenix]

[quote name='Jarno Mikkola' post='463288' date='Sep 22 2009, 12:09 PM'][quote name='OneEyedPhoenix' post='463285' date='Sep 22 2009, 12:34 PM']

IF
...
RESPONSE #500[/codebox][/quote] Bad idea. Just put it to #100 ...
[/quote]


This is not all of the script. I think the #500 part is there to make it a 50-50 chance that either this party or the amazons spawn.
For completeness sake I will include rest of the script below:

[codebox]THEN
	RESPONSE #500
		ActionOverride(Player1,CreateCreatureOffScreen("DRAKAR",0)) // Drakar
		ActionOverride(Player1,CreateCreatureOffScreen("HALACA",0)) // Halacan
		ActionOverride(Player1,CreateCreatureOffScreen("MOLKAR",0)) // Molkar
		ActionOverride(Player1,CreateCreatureOffScreen("MORVIN",0)) // Morvin
		SetGlobal("DMWWC3Assassin","GLOBAL",3)
		SetGlobalTimer("DMWWC3AssassinMiniSpawn","GLOBAL",ONE_DAY)
		SetGlobalTimer("DMWWC3AssassinSpawn","GLOBAL",FIVE_DAYS)
	RESPONSE #500
		ActionOverride(Player1,CreateCreatureOffScreen("LAMALH",0)) // Lamalha
		ActionOverride(Player1,CreateCreatureOffScreen("TELKA",0)) // Telka
		ActionOverride(Player1,CreateCreatureOffScreen("ZEELA",0)) // Zeela
		ActionOverride(Player1,CreateCreatureOffScreen("MANEIR",0)) // Maneira
		ActionOverride(Player1,CreateCreatureOffScreen("NATALK9",0)) // Natalka
		ActionOverride(Player1,CreateCreatureOffScreen("ELKA9",0)) // Elka
		SetGlobal("DMWWC3Assassin","GLOBAL",2)
		SetGlobalTimer("DMWWC3AssassinMiniSpawn","GLOBAL",ONE_DAY)		SetGlobalTimer("DMWWC3AssassinSpawn","GLOBAL",FIVE_DAYS)END

[Jarno Mikkola]

500 is not 50...

[berelinde]

RESPONSE #100, RESPONSE #500, REPONSE #30, RESPONSE #1, RESPONSE #58937, it doesn't matter much, if it's the only reponse possible. It is only a "weight" relative to other possible actions in the block.

IF
  Triggers()
THEN
  RESPONSE #50
	 Actions()
END

This will always perform the actions regardless of the number value behind the #.

IF
  Triggers()
THEN
  RESPONSE #50
	RandomWalk()
  RESPONSE #50
	NoAction()
END

About half the time, the object running the script will walk around randomly and about half the time, it will stand there doing nothing. That is the only purpose of the numbers.

If you're extending the bottom of baldur.bcs, it's possible that the script is taking too long to get to your script block. This is highly probable on mega installs, since baldur.bcs can get very, very large... and not all mods are careful about coding it. All it takes is one person to add a True() trigger above your script and you'll never see it fire.

You're better off limiting the amount of script you add to the game script in the first place. Use area scripts if you can, or NPC scripts. If it's really essential that you extend the game script, keep your script blocks short, cleanly coded, and above all, bug free.

I seldom recommend extending the top of any script, but with baldur.bcs, you may have to.

Ah, this is from SCS. In that case, yeah, it really has to be added to baldur.bcs. DavidW has forgotten more about coding than I'll ever know, but if I had written that script, I wouldn't have made it so big. I would have spawned each creature in its own script block, with its own variable, and set the timers in yet another block.

[OneEyedPhoenix]

Alternately, I'm thinking that this script might work better if it only created the assassin that initiates dialog with the player and then make that dialog file create the rest.. Less chance of something going wrong then.

500 is not 50...

Nope, but the two options have equal weight, which makes it 50-50.

Edited by OneEyedPhoenix, 22 September 2009 - 04:38 AM.

[Cuv]

Question is, is there another way to script this, so that we would be sure that all four assassins were created correctly?

Of course Lots of ways. Here is one that will probably give you the least headache:

Just append the Baldur.bcs in a new block with your conditions... then have IT fire a quick cutscene script when the conditions are met to bring in your assassins. Make the CutsceneID for Player1... and just create the creatures. You can use head strings to verify they were created if you like... then remove those when the script works properly.

Just some advice: Keep it simple. Keep your conditions to a minimum. Have the cutscene script set an appropriate global so that it wont fire again.... or an incremental global if you need another encounter. The scripting guide is your friend.

IF
	Whatever + a "/MyConditions/" global at zero... + a "HereComeTheAssassins" global at zero
THEN
	RESPONSE #100
		SetGlobal("/MyConditions/","GLOBAL",1)
		ClearAllActions()
		StartCutSceneMode()
		StartCutScene("ScriptToBringInAssassins")
END

IF
	True()
THEN
	RESPONSE #100
		CutSceneId(Player1)
		SetGlobal("HereComeTheAssassins","GLOBAL",1)
								Create some creatures either near Player1... or split this block 50/50 for offscreen option
 		EndCutSceneMode()
END

Cuv

[GeN1e]

My only guess (rather wild, mind you) is that it uses ActionOverride(Player1,...), making it possible for a human to perform an action, interrupting the sequence.

[Miloch]

Adding to baldur.bcs is really quite nasty stuff, particularly on megamod installs. I don't know why this *has to* be added to baldur.bcs. If there are 5 or 10 areas where these assassins may show up, then extend those area scripts and set a variable when they're spawned. Hell, I don't care if there are 100 or 1000 such areas. Even Haiass extends a block to the bottom of every single area script in the game rather than add to baldur.bcs (yeah we might as well have extended baldur.bcs, but we didn't - just to show 'em! ).

[berelinde]

Even Haiass extends a block to the bottom of every single area script in the game rather than add to baldur.bcs

Not a bad way to do it, but you should make sure that the area script isn't buggy in the unmodified game. Some contain True() triggers or other "always run" triggers that will prevent scripts below it from ever firing.

Also, there are a couple of mods that add them to area scripts, with the same result. In this case, it's installation order dependant. To avoid this, several modders use EXTEND_TOP and add a Continue() to the end of each and every script block to account for any OnCreation() triggers.

[Cuv]

Adding to baldur.bcs is really quite nasty stuff, particularly on megamod installs. I don't know why this *has to* be added to baldur.bcs. If there are 5 or 10 areas where these assassins may show up, then extend those area scripts and set a variable when they're spawned.

Ah... I read the link and understand the problem now. You are 100% right Miloch Leave the Baldur.bcs alone.

Ya know... I had another thought about a possible resolution to this problem. I reviewed the conditions that phoenix listed... and the areas where it CANT happen are few. Anywhere outdoors except those few areas. How about this for a unique approach:

Append the scripts of a rabbit, squirrel or bird? They all have a RandomWalk() type script. The Squirrel uses this script: WDRUNSGT.bcs in BG1 and BG2. Birds use RANDFLY.bcs in BG1 and BG2. Some research will need to be done to see if at least one is present in the required outdoor areas, but the script check could be simple... IF 'global conditions', mark area with a global where the conditions are met... then use your ActionOverride to create the assassins near the Party. Or fire that cutscene I talked about. Just another idea.

There are simpler ways, to be sure. LOL, but this one could be fun. Good luck.

Cuv

[berelinde]

Never considered that approach. You'd just have to be careful to EXTEND_TOP in those cases, and make sure the same scripts aren't used by interior creatures.

[Miloch]

Append the scripts of a rabbit, squirrel or bird? They all have a RandomWalk() type script. The Squirrel uses this script: WDRUNSGT.bcs in BG1 and BG2. Birds use RANDFLY.bcs in BG1 and BG2.

An interesting idea. But I wouldn't bother EXTENDing them - at least wdrunsgt is used for other CREs. Just search for the first open script slot (obviously CREs like rabbits have at least one if not several open slots) and WRITE_ASCII a new script to it. The Aurora mod does this to randomise certain items.

@berelinde - haven't heard of a problem yet with EXTEND_BOTTOMing area scripts. Or at least, the only report of the spawn not working wouldn't've been helped by an EXTEND_TOP.

There's nothing wrong with Baldur.bcs unless you stick the superscripts or something in there.

And that is the problem. It's already bloated beyond usefulness in the typical megamod install, from people putting all sorts of talking weapons and other garbage in it.

[berelinde]

@berelinde - haven't heard of a problem yet with EXTEND_BOTTOMing area scripts. Or at least, the only report of the spawn not working wouldn't've been helped by an EXTEND_TOP.

Graveyard and Waukeen's Promenade are two that I can think of in 2 seconds or less. Originally, In Fading Promises I used EXTEND_BOTTOM in AR0800.bcs to spawn Aidan, but without the BG2 Fixpack, the original script is bugged, so Aidan never spawned. Unless I'm mistaken, I opted to steal code from the BG2 Fixpack with a check to see if it was installed already, rather than EXTEND_TOP because I figured that some other modder might appreciate the script getting fixed. This didn't work when I tried extending the top of AR0700.bcs, though, since I suspect it was some other mod causing the problem. I was forced to EXTEND_TOP of the area script in my Iron Modder X entry and it worked fine.

The AR0800.bcs one is documented on the Fading Promises forum and at PPG. Since I couldn't be bothered to find the mod that was breaking AR0700.bcs during a 4-hour contest and haven't had enough interest to find out since, that issue is not yet resolved.

There are probably other scripts affected, besides the two I listed above.

The problem of broken scripts is not confined to area scripts. Anomen.bcs contains a True() trigger in the unmodified game, which I discovered while working on Romantic Encounters.

[DavidWallace]

As a point of interest, I put the block in Baldur.bcs because that better respects the logic of the situation, which is that the assassins should spawn whenever the appropriate conditions are met, rather than spawn in one of some set of N areas. (To use an admittedly theoretical example, if someone else adds a new forest region to the game, the assassins should be able to spawn there.) I agree that in theory, since the assassins can only spawn in maybe half the areas in the game, there'd be a marginal speedup by patching all those area scripts instead of Baldur.bcs, but it's totally negligible and not worth confusing the logical structure of the code. (This kind of thing matters for debugging, changing things later, et al.)

I take the point about the fragility of the actual way they're spawned; I'll look into changing that.

[GeN1e]

Surely it's viable to use

COPY_EXISTING_REGEXP GLOB ~.*\.are~ ~override~
  READ_BYTE flag_offset flag
  PATCH_IF flag BOR 0bxxxxxxxx = 0bxxxxxxxx) BEGIN
	READ_ASCII script_offset script
	INNER_ACTION BEGIN
	  EXTEND_BOTTOM ~%script%.bcs~ ~assassins.baf~
	END
  END
BUT_ONLY

[DavidWallace]

Surely it's viable to use

COPY_EXISTING_REGEXP GLOB ~.*\.are~ ~override~
  READ_BYTE flag_offset flag
  PATCH_IF flag BOR 0bxxxxxxxx = 0bxxxxxxxx) BEGIN
	READ_ASCII script_offset script
	INNER_ACTION BEGIN
	  EXTEND_BOTTOM ~%script%.bcs~ ~assassins.baf~
	END
  END
BUT_ONLY

Well, there's a technicality because some areas don't have area scripts, so you'd need to create them. But obviously that could be incorporated. Beyond that, though, I just don't really see it as worthwhile. Keeping baldur.bcs clean is a good other-things-being-equal policy, but it's not worth fetishising. If some bit of code is going to make things run unacceptably slow, you don't solve that problem by putting it into half the area scripts rather than into the global script.

[Miloch]

The other problem with adding more stuff to baldur.bcs is that it doesn't distinguish between the BG1 and BG2 portions of the game. On BG2 and Tutu, this might be pretty trivial, but on BGT/BWP-type installs, there's no need to bog down the BG2 portion of the game with extra global scripting when your objective is to target just certain areas in the BG1 portion of the game (or so I'm guessing in this case anyhow).