Is it possible to remove a lock or change difficulty

[devSin]

Doors are objects, not files. Make sure you're using the door's actual script name (the door "name," the very first string in the structure) and not the door ID or its name in the WED file.

 

You create items in containers with ActionOverride() (or from the container script, if it's running one). ActionOverride("Container1",CreateItem("MISC07",23,0,0)).

 

When a script name has spaces, you can omit them (the engine *should* treat "Container 1" and "Container1" the same).

[berelinde]

Doors are objects, not files. Make sure you're using the door's actual script name (the door "name," the very first string in the structure) and not the door ID or its name in the WED file.

 

Damn. The first line in NI is Door1007. Oh, well, problem solved. Thank you for your very patient help.

 

You create items in containers with ActionOverride() (or from the container script, if it's running one). ActionOverride("Container1",CreateItem("MISC07",23,0,0)).

 

Wow. That's really cool. I've been avoiding adding objects to containers because I thought they had to be added using a lot of WRITE_ASCII stuff that you and Nythrun understand but I don't. And it's likely to be useful, too. Thanks!

[Miloch]

Damn. The first line in NI is Door1007. Oh, well, problem solved.

So you got it working? I thought it was Exit1007, though maybe that is the link between the two areas (and not the door itself).

You create items in containers with ActionOverride() (or from the container script, if it's running one). ActionOverride("Container1",CreateItem("MISC07",23,0,0)).

Will that work if someone has already visited the area or opened the container in question? I've been doing it via a bunch of funny-looking TP2 patching (or I should say, Ascension64 has been doing it for the mod I'm working on, since that kind of code looks like Linear A to me).

[berelinde]

I think you'd put that in the area script. If you were smart, you'd put some global on it so it would do it once and then never again (or you'd probably get a wicked stutter).

 

The area script would place the items the first time the area was visited after the installation of the mod.

 

The stuff that works only if the area has never been visited is the tp2 stuff.

[Nythrun]

It'd work fine Area's you've visited and joinable NPCs are about the only "external" files that are added to a save.

 

IF
 Global("SomeGlobal","GLOBAL",0)
THEN
 RESPONSE #100
CreateItem("MISC07",Myself,23,0,0)
SetGlobal("SomeGlobal","GLOBAL",1)
END

 

Would be all you'd really need in the container script (obviously, you'd want to keep the number of added globals to a minimum, but that's not too difficult )

[devSin]

Area definitions, creature definitions for actors in visited areas, and store files are the only things saved in the SAV file. PCs are predetermined fairly early on (the game will always pick the cheapest possible version of the CRE for that character and inject it into the game when you start a new game), but I think you may still be able to modify them after a game has been started as long as the character hasn't yet been in the party, and the world map is saved.

 

Everything else is fair game (scripts, dialogues, items, spells, etc., but you have to create a new instance of the resource if the game is running when you modify them). Note that some things can change when a player has been through an area (traps could have been triggered or disarmed, a script or dialogue could have disabled containers or ambient sounds, etc.).

[berelinde]

Would be all you'd really need in the container script (obviously, you'd want to keep the number of added globals to a minimum, but that's not too difficult )

 

It seems to be for me. I've been having so much flakiness with LOCALS that I've pretty much had to abandon their use except for things that happen within the same script or dialog file.

 

That, and every time there's an interjection, another one gets added, and all the timers... it adds up very quickly.

 

What happens when there's too many?

[devSin]

You'll probably never hit that limit, whatever it is. The engine can parse a *lot* of effects (and LOCALS are simply attached effects).

 

Note that you should only use LOCALS with creature scripts (scripts intended to be run on actor objects). The engine can't store LOCALS variables on other object types. Other than that, you shouldn't really be experiencing too much flakiness over other scopes.

[Guest Guest]

What happens when there's too many?

 

The modder starts forgetting what variable maps to what

 

What sort of LOCALS are flaking?

[berelinde]

This was never working:

 

In B!GAVIND.bcs

 

IF
 OR(14)
AreaCheck("FW2200") //on a map with water that isn't the ocean or ToSC
AreaCheck("FW2100")
AreaCheck("FW1600")
AreaCheck("FW1700")
AreaCheck("FW1400")
AreaCheck("FW2400")
AreaCheck("FW5300")
AreaCheck("FW5200")
AreaCheck("FW4200")
AreaCheck("FW4600")
AreaCheck("FW4300")
AreaCheck("FW3800")
AreaCheck("FW0400")
AreaCheck("FW0900")
 TimeGT(13) //going to sleep in the afternoon
 TimeLT(21)
 Global("B!GavinRomanceMatch","GLOBAL",1)
 Global("B!GavinRomanceActive","GLOBAL",1)
 GlobalGT("B!GavinFlirtLate","GLOBAL",3) //only after initiating PID sever times *after* second PID menu change
 !Global("B!GavinWoman","GLOBAL",1) //not while wearing girdle of m/f
 !Global("B!DisableFlirts","GLOBAL",1) //player hasn't turned off flirting via PID
 Global("B!GavinLaundry","LOCALS",0) 
 InParty(Myself)
THEN
 RESPONSE #100
SetGlobal("B!GavinLaundry","LOCALS",1)
PlaySong(0)
PlaySound("BGAV_SS")
StartDialogNoSet(Player1)
END

 

Changing the LOCALS to GLOBAL makes it happen in the same area, with all other things being equal.

 

But I'm using LOCALS very successfully in the concurrency counter and in some of the quest NPC scripts. It seems like I only hit problems when a LOCALS should trigger a dialog and fails to.

 

I keep a list of globals. Avoids confusion.

 

When I started writing Gavin, I wanted to keep things as flexible as possible. I wanted the pc to be able to delay conversations if they happened at a bad time, or to tell him to just shut up for a while without ending either the friendship or the relationship forever, or be able to restart a broken romance. I wanted him to be able to track pc behavior and respond appropriately. All these things take variables. Since the pc also has the ability to kick him out of the party, rejoin him, and carry on as if nothing had happened, most of the behavior modification variables need to be GLOBAL.

[pro5]

That may be a bit offtopic, but that last script's trigger is very speed-inefficient. I've been noticing such things since I had to investigate SCS scripts in attempt for optimization.

 

That OR(14) block is slow, because engine will have to check each condition until either one of them evaluates to true or all turn out to be false. Therefore, you may want to move it further to the bottom in trigger list, so that we use every opportunity NOT to check it if we don't really need to.

 

Whatever trigger you have it at the top of your trigger block, is going to be checked/evaluated dozens of times per second (at AI update rate) all the time while Gavin is in party.

 

If I was doing optimization for this script, I'd rearrange triggers this way:

IF
 Global("B!GavinLaundry","LOCALS",0) // don't need to go further if we've already done this before
 GlobalGT("B!GavinFlirtLate","GLOBAL",3) //only after initiating PID sever times *after* second PID menu change
 TimeGT(13) //going to sleep in the afternoon
 TimeLT(21)
 Global("B!GavinRomanceActive","GLOBAL",1)
 !Global("B!DisableFlirts","GLOBAL",1) //player hasn't turned off flirting via PID
 OR(14)
AreaCheck("FW2200") //on a map with water that isn't the ocean or ToSC
AreaCheck("FW2100")
AreaCheck("FW1600")
AreaCheck("FW1700")
AreaCheck("FW1400")
AreaCheck("FW2400")
AreaCheck("FW5300")
AreaCheck("FW5200")
AreaCheck("FW4200")
AreaCheck("FW4600")
AreaCheck("FW4300")
AreaCheck("FW3800")
AreaCheck("FW0400")
AreaCheck("FW0900")
 Global("B!GavinRomanceMatch","GLOBAL",1)
 !Global("B!GavinWoman","GLOBAL",1) //not while wearing girdle of m/f
 InParty(Myself)
THEN

 

It doesn't matter much on its own, but when you have dozens of mods installed and each adds scripts like this - you get stutter (especially if one of those mods is, say, SCS with its 250kb mage script).

[berelinde]

Ah. I see I'm going to be reworking an awful lot of scripts. But that's all right. Moving stuff within blocks is just cutting and pasting.

 

Gavin's script file is large. No sense making it slower than it has to be.

[devSin]

I'd personally rearrange it so that the simple let's-compare-numbers triggers are first. That would be InParty(Myself) TimeGT(13) TimeLT(21) ...

 

If all of those areas are outdoors, you can also stick a AreaType(OUTDOOR) before the big OR() block for that extra millisecond improvement when you're not actually in an outdoor area.

 

Try to set your LOCALS later (right before your StartDialogueNoSet() or Interact()) instead of doing it first thing in the block.