19 replies to this topic

[Seifer]

Not sure if the idea will take but it might make some sense to keep a list common mistakes people make. I'll start the list with my own lame mistake. Anyone else?

1) When spawning creatures, use the file NAME, not the Death Variable. Gets me everytime that one.

2) When APPENDing 2DA files in the tp2 file, the entry in the first column is the Death Variable and NOT a dialogue file name...

3) Make sure your CRE (for your NPC) has its enemy-ally attribute set to NEUTRAL. Also, make sure that the Export Allowed flag is NOT ticked.

4) Also, make sure that the area-script you're extending includes a variable that prevents the creature from spawning over and over and over again.

5) Never forget the tildes! (~~)

6) Save and update your information on a regular basis.

7) A note or two regarding Imoen: -
The post-Spellhold Immy's death variable is Imoen2, not Imoen!!! The .cre is IMOEN211 or IMOEN213.
SOA post-Spellhold Immy has no B file. TOB Immy does.
Please see note.

8) Creatures summoned by spell/items do not read with a valid Death Variable.

9) If your area scripts don't seem to be working it might need an entry in the MastArea.2da file. (Read up on this file!)

10) You CAN'T CREATE NEW CLASSES OR MULTI/DUAL CLASSES! However, you can SIMULATE them with kits and scripting.

11) If you're modding and testing one of the DPlayer scripts, make sure the AI is turned on.
- When making NPCs, make sure you've stripped the DPlayer scripts from the base .cre or you'll likely wind up with the multiplayer dialogs on join/part.

12) Watch for typos in BCS files. This is the bane of all scrpiters! An example, lifted from Blitz:

I wasted two hours messing with global variables and other scripts only to discover that the NPC wasn't spawning because of a "CreateCreature" name-typo.

13) When writing your scripts, keep in mind that summoned creatures don't have a DV (death variable).

14) If you are making many small changes to your code, don't forget to reinstall the mod before you test. - Thanks to Shed.

15) Remember to actually compile your dialogue files. Make's testing a lot easier...!

Edited by berelinde, 13 October 2007 - 02:56 PM.

[Seifer]

Updated. Keep 'em coming.

[Seifer]

Updated.

[Shed]

If you are making many small changes to your code, don't forget to reinstall the mod before you test .

[Seifer]

Updated.

[Seifer]

Here's a classic one - remember to actually compile your .d files.

A slight mishap I had earlier..!

[Ghreyfain]

7) A note or two regarding Imoen: -
The post-Spellhold Immy's .cre is Imoen2, not Imoen!!!

Should specify that it's her DV that's 'Imoen2', not her .cre. Her .cre files are in fact imoen211.cre and imoen213.cre.

[Shed]

True . Edited.

[berelinde]

7) A note or two regarding Imoen: -
The post-Spellhold Immy's death variable is Imoen2, not Imoen!!! The .cre is IMOEN211 or IMOEN213.
SOA post-Spellhold Immy has no B file. TOB Immy does.

This item has since been addressed by the BG2 Fixpack at G3.

The BG2 Fixpack gives Imoen a banter file, but if you want your mod to work just fine without requiring that the BG2 Fixpack be installed, you can add these lines to your tp2, taken from the BG2 Fixpack.

// Imoen gets her groove back. And her banter file.
ACTION_IF FILE_EXISTS_IN_GAME ~mel01.cre~ THEN BEGIN

  COPY_EXISTING ~interdia.2da~ ~override~
	SET_2DA_ENTRY 17 1 2 ~BIMOEN2~ // fixes ToB version
	BUT_ONLY_IF_IT_CHANGES

END ELSE BEGIN

  APPEND ~interdia.2da~ ~IMOEN	   BIMOEN2~ // fixes SoA version
	UNLESS ~BIMOEN2~

END

[Azkyroth]

Remembering that in the RES versions of the various spell scripting actions (or at least in ReallyForceSpellRES) the "target" and "spell" elements of the parameters are in the opposite order from the non-RES versions.

Putting entries in the TP2 for files you're going to make soon and then forgetting to remove them before attempting an install to test your dialogue and script compiling.

Forgetting that you have to quit WeiDU before changes in the TP2 will be loaded.

Forgetting that Infinity Explorer locks a bunch of files from editing for no apparent reason, and thus trying to do anything whatsoever with it open.

Edited by Azkyroth, 13 October 2007 - 07:06 PM.

[Azkyroth]

Also: remember to read error messages carefully, even if you think they're referring to an error you anticipated possibly occurring. Helps avoid going to excessive and futile lengths to fix an issue the compiler has with "bimoem2.dlg"

[@vGur]

ALSO, as i notice with help of Miloch and Guest (he didn't tell his name)

STARTING NAME WITH A NUMBER IS A REALLY BAD IDEA!

So 111111_ is bad , BUT _111111 is ok

Edited by @vGur, 09 October 2009 - 07:57 AM.

[GeN1e]

STARTING NAME WITH A NUMBER IS A REALLY BAD IDEA!

I suspect it's more due to possible prefix conflicts, not because it'll cause game to malfunction.

[Miloch]

Well normally it might work, but in this case it might be causing issues with variable evaluation or something.

[GeN1e]

Pardon my ignorance, but how exactly?

[Miloch]

Not sure - might want to look at the original post.

[@vGur]

When i try to find out what is wrong i created a copy of plat01 (in dltcp) and named it 1plat01 (w/o any evaluating) SO when i created it in game (via console) i only get 1 gp (2 for 2plat01 and so on)
AGAIN, starting item name with number is really bad idea.

Edited by @vGur, 10 October 2009 - 08:40 AM.

[Taimon]

From G3 / Random notes:

Two more "features":
If an item name starts with a digit, its treated as misc07 (gold). atol(name) is used as the stack amount. ("123ign" => misc07 with 123 stack amount)

You can set the stack amount with the item name. "scrl69*9" will give you 9 times scrl69.

[Bardess]

I remember this was useful knowledge back when I was a total noob and didn't know anything about programming:

When the compiler reports an error, but you can't figure out anything wrong with the line it pointed at, look above it.