5 replies to this topic

[Smoketest]

First of all, thank you for these tools.

I found an issue right away when I tried running/installing the ARE checker.

The TP2 code responsible:

// ensures are regexp search doesn't die
COPY_EXISTING ~ar0087.are~ ~override/xr2400.are~
			  ~ar0087.are~ ~override/xr2600.are~

I've cleansed my install of unused areas, thanks to NI's help, so neither the XR* areas or the AR0087 area exist. I have them extracted to a special backup folder and removed from the KEY index so I don't have to deal with them in my general editing.

Now I may be the only person who has done this, which would be par for the course. Regardless, I suggest checking for the presence of XR* areas first, and for the presence of the area you want to override them with. In my case it was a simple matter of commenting out the two lines, after which the area checker ran beautifully.

The other checkers ran great. I see what you mean about Map Notes. Bioware apparently updates the offset in memory if the user adds new notes, but otherwise leaves it 'floating' so long as there are no notes present. NI is flexible in this regard by not showing map note structures if there aren't any. Your checker could do the same by checking the map note count first, and then only worrying about the offset if there are map notes present. As it stands, all reports for areas with no map notes are non-issues that clutter up the logs.

Thanks again, I'm off to read the logs and check files.

[CamDawg]

Smoketest, on Oct 3 2006, 03:46 PM, said:

I've cleansed my install of unused areas, thanks to NI's help, so neither the XR* areas or the AR0087 area exist. I have them extracted to a special backup folder and removed from the KEY index so I don't have to deal with them in my general editing.

Hadn't considered that; will do for the next version.

Smoketest, on Oct 3 2006, 03:46 PM, said:

The other checkers ran great. I see what you mean about Map Notes. Bioware apparently updates the offset in memory if the user adds new notes, but otherwise leaves it 'floating' so long as there are no notes present. NI is flexible in this regard by not showing map note structures if there aren't any. Your checker could do the same by checking the map note count first, and then only worrying about the offset if there are map notes present. As it stands, all reports for areas with no map notes are non-issues that clutter up the logs.

Originally, I did code it to only report the offset error if notes were present. In the end, I figured it would be more worthwhile to err on the side of caution. The map notes are something I'm considering adding to the Modder component of the Fixpack, so it may be moot in the near future.

[Smoketest]

Ah, I don't mind erring on the side of caution. I modified it locally so I don't have to see notices I'm not concerned with.

On that note, I slightly improved the ARE script check block. Please forgive my lack of experience with TP2 coding... most of my experience is with using WeiDU has a DLG editor.

	// area script
	SET "exists" = 0
	SET "unassigned" = 0
	SET "missing" = 0
	INNER_PATCH_FILE ~%SOURCE_RES%.bcs~ BEGIN
	  SET "exists" = 1
	END
	PATCH_IF (("%script%" STRING_EQUAL_CASE "%SOURCE_RES%") AND ("%exists%" = 0)) BEGIN
	  SET "missing" = 1
	END
	PATCH_IF (NOT ("%script%" STRING_EQUAL_CASE "%SOURCE_RES%") AND ("%exists%" = 1)) BEGIN
	  SET "unassigned" = 1
	END
	PATCH_IF ("%unassigned%" = 1) BEGIN
	  PATCH_PRINT "%SOURCE_FILE% error: Area Script exists but is unassigned (%SOURCE_RES%.bcs)"
	  INNER_ACTION BEGIN
		APPEND ~debugger.log~ "%SOURCE_FILE% error: Area Script exists but is unassigned (%SOURCE_RES%.bcs)"
	  END
	END
	PATCH_IF ("%missing%" = 1) BEGIN
	  PATCH_PRINT "%SOURCE_FILE% error: Area Script assigned but nonexistant (%SOURCE_RES%.bcs)"
	  INNER_ACTION BEGIN
		APPEND ~debugger.log~ "%SOURCE_FILE% error: Area Script assigned but nonexistant (%SOURCE_RES%.bcs)"
	  END
	END

This code reports errors only if:
- There is a script reference but no matching script file.
- An area's script file exists but is not referenced.

I followed the convention that area script files have the same resname as the areas they belong to, which is usually the case for Bioware data and the few NPC mods I've seen that provide new areas. This block allowed me to find that AR1107.ARE is using AR1102.ARE's script, rather than it's own unassigned AR1107.BCS script. This is the ranger cabin in Umar hills; 1102 is normal, 1107 is ranger stronghold.

It won't detect if an area is using another area's script so long as the script exists. For example, AR0517.ARE through AR0521.ARE all use AR0517.BCS. These are the trap rooms in the planar prison, and all AR0517.BCS does is display a string that you've been sucked into the room; it has no area-specific actions, and only one block.

It ignores empty references where no valid file exists, as these are not usually errors.

Do what you want with it. I know you're using the "fine-toothed comb" method so this probably isn't suitable. I originally set out to improve the error reports so they weren't so vague, but I ended up trimming down the number of "false positives" in the process.

[Smoketest]

With the above code I managed to get most of the ARE quirks taken care of. There are a few false positives in regard to missing transition areas and entrances, due to the game sometimes using a script to handle the actual transition, rather than the traditional references. For example, this is the case in AR0603 where the player is transported by script, instead of by area resref, to AR0700.

The ARE checker reported several actor script errors, and always on actors that had valid scripts assigned. All of the reports were false positives. I made modifications similar to the code I posted above for area script checking, and that got rid of the false positives but still reports missing scripts if any are referenced. (I'm not at home so I can't post the code snippet; I'm sure you can figure it out.)

I ran out of steam so I wasn't able to test beyond the ARE checker output. Though I don't mind the fine-toothed comb approach, I feel that some of these check blocks could be more robust. False positives like the one I mentioned in the first paragraph of this post are understandable because they are special situations.

[Altomar]

I got this error while using Area Checker

Quote

ERROR: BIFF [./DATA/PROGTEST.BIF] cannot be loaded: Unix.Unix_error(20, "stat", "./DATA/PROGTEST.BIF")
Stopping installation because of error.

ERROR Installing [Area Checker], rolling back to previous state
[G3_Debugging_Suite/backup/0/UNSETSTR.0] SET_STRING uninstall info not found
Will uninstall 1 files for [G3_DEBUGGING_SUITE/SETUP-G3_DEBUGGING_SUITE.TP2] component 0.
Restoring backed-up [G3_Debugging_Suite/backup/0/debugger.log]

if i try to open xr2400.are or xr2600.are with NI i got this message

Quote

Error reading XR2400.ARE
data/progtest.bif not found