Missing area scripts prevent spawning

[Miloch]

Not sure if this has been raised on this forum yet, but we've been discussing at at G3 in this thread.  Although it came up in the context of BG1 NPC originally, it potentially affects any mods in EasyTutu or conventional Tutu where the .BCS is not assigned to an .ARE and where something is supposed to spawn.  The question is, where should a fix for this reside: core Tutu development, Tutufix or another mod/tweak pack?

[Bons]

While I would hope Tutu players would all install Tutufix, applying a BCS to areas without would be a grand thing to have in the core in terms of modding ease for quests and NPCs.

For example, Finch has to spawn in the main Beregost area and be moved to her start area because the Red Sheaf Inn does not have a default script. This also limited the locations I could use where the party might find books for her library quest. Adding the area script at the time of mod install can introduce problems where creatures/items are not spawned because the player has already visited those areas pre-mod install. Having the core install add a bcs to areas w/o would resolve this problem.

The main reason I would shy away from including such a feature in something like Tutufix or another mod package is the modder would have to rely/add checks to see if the player had yet another mod installed to take advantage of the feature.

[CamDawg]

You do have to exercise some caution, though. In BG2, applying a blanket patch like this ended up assigning a number of leftover BG area scripts to BG2 areas, so Fixpack only does this selectively instead in the modder component. While it's impossible a similar issue would affect Tutu, it is possible that several of those area scripts were removed for a reason.

All the more reason why we need a solid BG Fixpack that would handle this prior to any conversion.

[cmorgan]

Actually, CamDawg's reference is why I stopped my work of a blanket LIB that assigned all Tutu areas, even though it was 80% coded and I had done the area research. Unfortunately, I am unable to tell what Tutu area scripts are real, which are abandoned but have working code that will interfere with stuf, and which are duplicates; so instead of creating a blanket "assign all area script references", my workspace has a partial section of code that just covers areas which BG1 NPC actually uses.

I would be happy to provide that to any Tutu modder, by throwing the code up on G3's Development Wikki under the "common code" section, as soon as I get a chance to do some additional testing (all area script assignment contents but one are fully playtested). Other modders could add to the library as they confirm that assigning an area script reference actually does what it is supposed to do. I would suggest it be included in Tutufix, except that the reson we found out about the problem were folks not installing Tutufix...  but I can do the next best thing, and ask Macready to incorporate the materials into the  EasyTutu distribution. Even then, it would probably need to be included in each mod to cover folks using regular Tutu.

[Macready]

Hello -

What are we talking about here, exactly?  Situations where a given _AR*.BCS exists but isn't assigned in the ARE?  If so, I'd prefer to delete the appendix scripts.  If we are talking about areas that haven't used an area script in the past (and hence do not have an area script assigned), I've always regarded it as the responsibility of the mod to patch it into the ARE.  Is there a compelling argument against this?

[cmorgan]

What are we talking about here, exactly?  Situations where a given _AR*.BCS exists but isn't assigned in the ARE?  If so, I'd prefer to delete the appendix scripts. 

Yep - that's the situation. For us, a Mac install of conventional Tutu had Drizzt's area changes in Dynaheir's not working on some installs. Gorilym identified the culprit as the missing area BCS assignment - when he edited the savegame to assign the area script, all went perfectly.

The conversation went on from there. The most comprehensive "fix" would be to determine non-functional scripts and remove them, then patch in area script references; a mini version of BG2 Fixpack operations or your Spawn fixes, Macready -- but I think this might be safest as a fix individually applied by each mod based on the areas used by content. I am not sure a blanket fix is worth the effort, when modders can easily just add

Code: [Select]

/* patching area script */
COPY_EXISTING ~FW4300.ARE~ ~override~
  WRITE_ASCII 0x94 ~_AR4300~ #8 // area script
  BUT_ONLY_IF_IT_CHANGES
if they want to use an area and are not sure it has a script assigned.

[berelinde]

Thanks. I needed that. I'm using areas that I'm 99.9999% sure do not have associated scripts.

[Miloch]

I've always regarded it as the responsibility of the mod to patch it into the ARE.  Is there a compelling argument against this?

Adding the area script at the time of mod install can introduce problems where creatures/items are not spawned because the player has already visited those areas pre-mod install. Having the core install add a bcs to areas w/o would resolve this problem.

Of course, one could argue a player should start a new game (or revert to a save prior to visiting the area in question, if such exists) after installing any mods of this nature, but most players wouldn't want to be forced to do that.

[Macready]

Hello -

I've always regarded it as the responsibility of the mod to patch it into the ARE.  Is there a compelling argument against this?

Adding the area script at the time of mod install can introduce problems where creatures/items are not spawned because the player has already visited those areas pre-mod install. Having the core install add a bcs to areas w/o would resolve this problem.

Of course, one could argue a player should start a new game (or revert to a save prior to visiting the area in question, if such exists) after installing any mods of this nature, but most players wouldn't want to be forced to do that.

Thanks, I missed her points on my first pass.

I'll admit I'm not entirely convinced, because AREs are only one of the things cached in the SAV file.  Although you could in fact eliminate the issue Bons describes by assigning area scripts to the AREs in the base install, there are still other types of patching that are not going to work in terms of affecting a game in progress.  Applying a mod to a game in progress just isn't a good idea, IMO.

That said, it wouldn't be hard to do if people really want it.  And one thing I'd be in favor of is removing any unassigned area scripts from the distribution altogether.  The last thing I want to see is for someone to assign an area script, extend it, and inadvertently reintroduce some existing script code that was unassigned for a reason, as Cam points out.

[CamDawg]

I'll admit I'm not entirely convinced, because AREs are only one of the things cached in the SAV file.

True, though this is often the only reason why you would require a new game. Regardless of whether it's a good idea to install mods midgame, players are still going to do it.

That said, it wouldn't be hard to do if people really want it.  And one thing I'd be in favor of is removing any unassigned area scripts from the distribution altogether.  The last thing I want to see is for someone to assign an area script, extend it, and inadvertently reintroduce some existing script code that was unassigned for a reason, as Cam points out.

Yeah, my point here was basically "don't do it via regexp". Some scripts don't use the naming convention, others are unassigned for a reason, etc., etc.

After reading the thread, though, my larger concern is the difference between Win and OS X (Easy)Tutu. Tutu has an added burden of being a platform upon which other mods are built, which raises a different issue: most modders don't have access to multiple platforms hence we must work under the assumption that OS X files are the same as Windows. Regardless of whether this is because OS X and Windows BG are different or because the conversions themselves work slightly differently this is something that needs to be addressed.

[Macready]

Hello -

After reading the thread, though, my larger concern is the difference between Win and OS X (Easy)Tutu. Tutu has an added burden of being a platform upon which other mods are built, which raises a different issue: most modders don't have access to multiple platforms hence we must work under the assumption that OS X files are the same as Windows. Regardless of whether this is because OS X and Windows BG are different or because the conversions themselves work slightly differently this is something that needs to be addressed.

Well, Gorilym made some nice progress in this arena, as his Mac-ification of EasyTutu uses the exact same core package as WinEasyTutu, save for one small edit to CHITIN.KEY (an edit that won't dirty the pool for modders, AFAIK).

Of course, what does or doesn't happen with EasyTutu doesn't help people who either choose to or are forced to use the conventional Tutu distribution.  I myself have no desire or intention to address this issue in that context, though.

[cmorgan]

Well, if experienced folks want to tackle it, I can assist. I am dropping the  contents of

D:\BG1NPCWorking\BG1NPC\LIB\tutu_area_script_assign.tph

onto G3's wikki on the "common code" page for folks to play with. It basically in an independent library of all of the script areas assigned for The BG1 NPC Project, set up to run on both non-TOTSC and TOTSC installs via INCLUDE.

As for removing the area scripts that don't work, is that possible? I would hhink that the bif would rebuild them even if unused (I am woefully ignorant of this).

If someone wants it to play with, I do have a full list of areas, in rough form (though I am sure folks hcan do it easier than I had to, by opening the list in NI and DLTCEP and manually copying/retyping). I do not have what they are, just the raw numbers.

[Miloch]

Well, if experienced folks want to tackle it, I can assist. I am dropping the  contents of
D:\BG1NPCWorking\BG1NPC\LIB\tutu_area_script_assign.tph
onto G3's wikki on the "common code" page for folks to play with.

That's this, right?  Wasn't sure whether that was old or recently updated.

As for removing the area scripts that don't work, is that possible? I would hhink that the bif would rebuild them even if unused (I am woefully ignorant of this).

And I am even more ignorant.  Anyone know?

If someone wants it to play with, I do have a full list of areas, in rough form (though I am sure folks hcan do it easier than I had to, by opening the list in NI and DLTCEP and manually copying/retyping). I do not have what they are, just the raw numbers.

Well whatever you have might help, if you want to post it or if not, you have my e-mail.  Though I can't say I'd be of much help, but if someone can define some parameters of functional vs. non-functional scripts, I could take a stab at it.

[cmorgan]

yep, that is the updated library; before now, it was a pile of small snippets of code scattered over most of the tp2 and tied directly to related quests. I am happy to build a full library or coordinate, if it is of any use and someone can detail what it is we would be doing to create the same basic package for Tutu that exists in the BG2 FixPack "SuperHappyFunLuckyModdersPack" code

In fact, if there is anything else there that can be identified as useful for Tutu, I could get a head start for Macready on the integrated fixes so he doesn't have to single-handedly fight back the tides of darkness (though a mental Luke Skywalker image of Macready fighting off hordes of little binary code blocks in cockroach form is kinda funny ).

[Macready]

Hello -

Don't worry about this issue.  I'll make a pass at it -- it shouldn't take long.

I'll either do a new release (to address some recent bugs as well), or I'll add to hotfixes.

[Macready]

Hello -

346 areas in all that currently do not have area scipts assigned in the latest EasyTutu release.  Not a single one of them has an associated _AR*.BCS lying around waiting to cause trouble, either, which is good.

I'll go ahead and assign scripts to the AREs for the next release.

[cmorgan]

Macready, if you toss the materials anyplace, we could let the Tutu v4 folks have it set up as well - or do you mean that all aea scripts existing in Tutu can be assigned fine?

[Macready]

Hello -

Macready, if you toss the materials anyplace, we could let the Tutu v4 folks have it set up as well - or do you mean that all aea scripts existing in Tutu can be assigned fine?

I don't forsee any problem (e.g., reactivating dormant code) in assigning them -- there were no appendix _AR* scripts lying around in EasyTutu, and EasyTutu started as Tutu v4.

The work is already done in EasyTutu, aside from testing (which I don't imagine will amount to more than visiting one or two of the edited areas and saying, "seems fine to me").

[cmorgan]

cool - last confirmation, before I throw the whole thing as a common code tph -- what we are saying here is all EasyTutu areas are already patched to have the associations

• BG1 AR1234 converts to FW1234, and uses area script _AR1234.
• All unused area scripts were ignored or skipped in the orioginal conversion, so there are no "false" _AR####.BCS around to cause troubles.
• Modders who support Tutu v4 as well as EasyTutu should create a subdirectory "LIB", and copy the file on the common code tutu_area_script_assign.tph
  
• To activate the script assignment (it will silently skip doing anything to an EasyTutu install) add the following line into your tp2:

Code: [Select]

/* Tutu Area Script Assignment Patching */
ACTION_IF FILE_EXISTS_IN_GAME ~FW0100.are~ THEN BEGIN
  INCLUDE ~myModFolder\LIB\tutu_area_script_assign.tph~
END

• As for area scripts themselves, EXTEND_BOTTOM of EXTEND_TOP creates a new area script automatically if it cannot find the appropriately named file, so it is not necessary to actually build an area script independently; it is only necessary to tell Tutu v4 that the script could exist so it looks for _AR####.

I'm off to copy & paste from Miloch's area chart...


ok, it is up on the Wikki. Please check for stupidity on my part.


http://dev.gibberlings3.net/index.php/Common_Code_in_pure_tp2_form#Assignment_of_Area_Scripts_in_Tutu

[Miloch]

Looks good to me, though you may want to remove FW1010 Ice Island L2 as this is an area "restored" by BG1 Unfinished Business (and I would assume the Tutu version will deliver the proper script assignment ).  As a bit of side trivia, I noticed the possible reason why Bioware did not include this in BG1 is apparently they decided to use the same map without the ice in AR5506 Candlekeep Caverns, which appears to have been added quite late in the development process.

I hope the copying and pasting didn't take too long - had I known about it, I could've done it in a few seconds via blanket fill on my source spreadsheet.

[cmorgan]

Repaired dev wikki - nope; Crimson has "column mode" which speeds up things considerably - I could have asked you for the file and edited, but it was much easier to grab from the posts and edit directly. I will run a test install this afternoon while checking some other stuff, but that should let everyone with Tutu v4 match EasyTutu as far as assignemts, assuming Tutu modders include the tph

EDIT: y'know, it helps to explain to the computer that what you mean by ~FW0100~ is ~FW0100.ARE~...   wikki fixed.

[Macready]

Hello -

what we are saying here is all EasyTutu areas are already patched to have the associations

Yes, although I haven't released an update yet.  I'll see what more I can plod through in the next week or two, and package a release sometime before Christmas.  I'm heading into New York for a one-day developer conference this Tuesday...perhaps I'll bring along a laptop.  Might as well do something during the six frigging hours I'll be spending on trains that day.

• BG1 AR1234 converts to FW1234, and uses area script _AR1234.

Yes.

• All unused area scripts were ignored or skipped in the orioginal conversion, so there are no "false" _AR####.BCS around to cause troubles.

I found this to be true in the latest version of EasyTutu, at the very least.

• As for area scripts themselves, EXTEND_BOTTOM of EXTEND_TOP creates a new area script automatically if it cannot find the appropriately named file

I've always found this to be true, but then I've never used WeiDU in all its different flavors (e.g., alternate O/Ses).  bigg could probably give a definitive answer as to whether you can always count on this.

[Miloch]

...package a release sometime before Christmas.

Excellent news.

I'm heading into New York for a one-day developer conference this Tuesday...perhaps I'll bring along a laptop.  Might as well do something during the six frigging hours I'll be spending on trains that day.

Nooo!  Not Amtrak!  I got delayed on a train from NYC to Boston for four hours because of a bogus bomb threat.  Or for all I know, it wasn't bogus, but of course, I didn't find out what the problem was until much later.  Definitely glad I brought a laptop... the good thing is they have "quiet cars" with workstations.