Getting rid of a character that has no DV

[jastey]

devSin: Well, I was dreaming about keeping the statement "can be installed and played any time in the game" true, at least for BG1, where the area scripts are already assigned.

I didn't really understand your comment about "nearest". I can understand what you mean, but how exactly works "See()"? If I put "See(Player1)" into my script, it works, even if Player1 might not be the nearest character to the creature running the script. If I have sufficient "See()" conditions, it shoud pick the right one, or not? (I want to eliminate children (that sounds )where I spawn adults, and man where I spawn a woman.)

 

igi: harhar. (Btw., FotD does it (still), NTotSC does it (well, that's a non-WeiDU mod anyway.))

[Rabain]

I think there should be some kind of general consensus that any creature without a DV gets a DV that corresponds to the cre filename.

 

This way everyone knows what it is going to be and can code for it.

[berelinde]

Hear, hear!

 

I think BG2 Fixpack does this for BG2, but not every installation can include BG2 Fixpack, for one reason or another.

 

When I added DVs to exsiting CRE's I've added them to correspond to their creature codes, specifically so that these would be obvious choices for other modders. I've done this in Gavin, and I added this to Crossmod Banter Pack to support the "bear banter" between Amber and Keto.

 

So yes, Rabain, I think this is an obvious choice.

[Rastor]

I think there should be some kind of general consensus that any creature without a DV gets a DV that corresponds to the cre filename.

 

This way everyone knows what it is going to be and can code for it.

 

G3 Fixpack does this, but not everyone uses that. It's not really necessary to always use this though as I illustrated earlier. That code does assign the filename (minus the .CRE) to the creature if it doesn't have a Death Variable, if it does (i.e. another modder decided to change it without adhering to the standard) then it will also accomodate that.

 

So, yes, the general consensus is that creatures without a death variable get one that correspond to their filename, but not every modder has obeyed this in the past so it's necessary to accomodate them.

[jastey]

Rastor: That's a very helpful piece of code you gave there (I think I understand just now what it actually does: taking the actual DV, if there is one)!

[Rabain]

Useful yes!

 

@Rastor: can you comment the code you posted for those of us who don't read all that %source...% mumbo so well?

[devSin]

devSin: Well, I was dreaming about keeping the statement "can be installed and played any time in the game" true, at least for BG1, where the area scripts are already assigned.

Good point, yes. In this case, what you're trying to do won't be very simple (if the player has visited this area, the actor is already stored in the ARE file, and any changes you make to its script name at this point won't affect the saved game).

 

I didn't really understand your comment about "nearest". I can understand what you mean, but how exactly works "See()"? If I put "See(Player1)" into my script, it works, even if Player1 might not be the nearest character to the creature running the script. If I have sufficient "See()" conditions, it shoud pick the right one, or not? (I want to eliminate children (that sounds )where I spawn adults, and man where I spawn a woman.)

There are different types of objects. The point there is not that See() can only look at the closest object, but that object specs ([EA.blah.blah]) will only return the nearest living object of that type that the script runner can normally see (it works with Detect(), so the object can be invisible, and in BG2, it will return invisible creatures if the script runner has the see invisible effect). Something like See([128.1.155]) will only ever return the nearest neutral humanoid innocent to the character running that script; if the trigger also has !Name("whatever",LastSeenBy()) and !Gender(LastSeenBy(),2), etc., it won't change the fact that the script runner is going to be looking at the same [128.1.155] creature every pass through the script (until the nearest object of that type dies, becomes invisible to the script runner, or until another object of that type moves closer).

 

In general, if you stick and invisible creature on the map and have it See([NEUTRAL.HUMANOID.HUMAN.INNOCENT.0.MALE.LAWFUL_NEUTRAL]), it's only ever going to see the closest NEUTRAL.HUMANOID.HUMAN.INNOCENT.0.MALE.LAWFUL_NEUTRAL (which may or may not be what you expect, depending on how many objects of that type are within visual range).

[Avenger]

Hehe, DevSin, i would go with patching the area (unschedule it).

That would change only a few bits and that would be the least intrusive.

 

[edit]

Ok, a valid concern would be what happens when the area was already saved.

[devSin]

Hehe, DevSin, i would go with patching the area (unschedule it).

Yeah, I'd choose the Specifics script option. Even unscheduled, it will stick around in the saved area, and that just feels ugly to me.

 

If it was truly something where you wanted compatibility with an in-progress game, I'd personally just find a way to live with the existing actors or find a different area that's already empty.

[jastey]

(I am trying to satisfy betatester's wishes, as I already either chose empty areas or thought the existing creatures woldn't disturb.)

 

Thank you for the explanation; actually I was thinking of giving my quest cre's script a block that checks for the See[..], and, since they usually have RandomWalk attached, that sounds as if it could work.

 

I also changed my strategy to assign those game cres a different dialogue, since their present is acceptable, only the things they say do not fit (a girl says "I want to mom" while she (my quest cre) is standing next to her.)

 

So, I will try using a script block that checks for See[WHATEVER.SECIFICATIONS.I.CAN.GET] and !See("myquestcres") in one of my quest cres, assign a new script to the game cres, that runs a local variable, that triggers a different (weighted) quest related dialogue. I hope that works. I'll have to test this crazyness..

 

This way it should work at any state in the game. What was your remark about the save game ("any changes you make to its script name at this point won't affect the saved game"), was it related to a tp2 change that wouldn't show if the player already visited the area, or was it related to my genius approach?

[devSin]

Actors are stored in the ARE file for loaded and saved areas, so if you change the script name of the CRE after the player has visited the area you're targeting (where you want to get rid of the existing actors), it won't affect the saved areas.

 

Why don't you just extend the dialogue file for the existing neutrals to run something more appropriate (weight your additions highest so they get checked first) if your quest NPCs have been spawned?

[jastey]

Because the cres are used in other game areas, too, where the quest-related dialogues might sound strange. Plus, I don't want to overwrite dialogues that other mods might introduce to the same cre that exists as a different character in another area... Why have things to be so complicated.

[devSin]

A See("MyQuestNPC") trigger for the dialogue states should work fine, and it will only run in areas where your quest NPC exists (unless it's a huge house, I guess, but then you could just switch to Exists()).

 

You wouldn't be overwriting the dialogue, just extending it with new states that will be checked first; coupled with the See() check, your states should only run in the area you want, and the old states (or any states anybody else added) would continue to run in other areas.

[jastey]

Integrating a "See()" check into the dialogue state, now, *that* is a cool idea.

This definitely would work. I knew I am complicating things, but I couldn't put my finger on it.

 

devSin, you rock.