argent77

1. Try SpellRES("c#brxxxx",Myself) or ApplySpellRES("c#brxxxx",Myself) if you want it applied instantly.
2. Only for EE games: try SpellCastOnMeRES("c#brxxxx","c#grey") - Returns true only if cast in the last script round. Another option would be using spell states: Add a spell state to the spell in question (opcode 328) and check it via CheckSpellState("c#grey",MY_SPELL_STATE). It has the advantage that the spell state can be checked as long as the spell is active.

No need to add entries to SPELL.IDS. This is only really needed if you want spells to be available at spell selection (e.g. during character creation or for sorcerers at level up).

The error sounds more like your installation contains corrupted or missing files, or maybe a previous mod in the installation list made some incompatible changes. Are you able to open AR0011.ARE in Near Infinity?

Edit: If your BG:SoD game is from either GOG or Steam, make sure you have correctly merged the DLC (either use modmerge/DLC Merger manually or let BWS use DLC Merger automatically). Unpacking the SoD DLC manually doesn't work.

Try this:

AreaCheckObject("bd0120","bdporios")

Should return True if both the area "bd0120" and creature in that area "bdporios" exist; they are SoD specific (the starting area). If SoD is not installed neither of them will exist and the trigger should return False (and the script compiler may throw warnings that resources don't exist).

It didn't work in my tests. From what I've seen in existing scripts, this trigger is only used to check for creatures in the same area.

An idea that *might* work (haven't tested yet):

- spawn a SoD-specific creature (preferably one without assigned scripts)

- use ActionOverride to execute a simple script action from the spawned creature (e.g. setting a variable)

- despawn the creature

- check if the variable has been set

Well, unfixpacked BG2 would allow half-orcs to wear the item. So I guess it was only added as a precaution.

That two initial read operations are not strictly needed, because WeiDU automatically reads the content into the variable THIS for each write operation.

The logic of the write operations looks correct though. With the hint from above and the use of some helpful WeiDU constants it would result in:

COPY_EXISTING ~misc5x.itm~ ~override~
  WRITE_BYTE 0x1e ((THIS BOR BIT3) BAND BNOT BIT2)
  WRITE_BYTE 0x21 (THIS BOR BIT7)
 BUT_ONLY

Or combined into a single write operation:

COPY_EXISTING ~misc5x.itm~ ~override~
  WRITE_LONG 0x1e ((THIS BOR BIT3 BOR BIT31) BAND BNOT BIT2)
 BUT_ONLY

You can optionally replace BOR by |, BAND by & and BNOT by ` (back quote sign) to reduce code length.

Btw, the code makes "...Neutral" and "Half-Orc" unusable and "Good" usable. And yes, NPC-specific restrictions in EE games are only tied to creature (script) name. Alignment, race, etc. doesn't matter.

It should be enough to set the "# charges" to the total number of charges and "When drained" to "Item vanishes" in the ability header.

Well, I solved it by coding a WeiDU BAM generator to generate the desired BAM V1 file with alpha palette.

I still hope BAM V2 will be more widely supported in future EE patches. It looks like this format can currently only be used in UI related contexts.

I changed pretty much every flag, including bit 15. Except when bit 13 (WBM) was enabled the map always crashed. Enabling bit 13 simply ignored the BAM resource. (And bit 14 is still a big mystery.)

BAM V2 is needed because of alpha transparency. Unfortunately there is no BAM editor available yet that supports alpha channel in BAM V1 palettes, NI included.

If nothing else works I can probably use raw pvrz files (each BAM sequence consists of only a single frame). But that would require to create several dozens of files in place of a single BAM with several dozens of sequences. Not something I'd like to use if there is another way.

I have a BAM V2 file that I want to use as background animation for a couple of maps (in BG2EE). Unfortunately I can't get it to work. The game is always crashing whenever I try to enter the map. Changing flags or setting width/height fields doesn't fix it. Is this format even supported?

To me "vanilla game" simply means "unmodded game", regardless of the game being enhanced or not. I'm using the terms "classic" (or "legacy") and "enhanced" (or simply "EE") to distinguish between original Bioware/Black Isle products and new Beamdog releases.

Just one side note, Beamdog has repeatedly stated that the currently available SoD (which is still on 2.3) is not fully compatible with (beta) patch 2.5. This will most likely also apply to EET installations. It might be that EET won't be fully playable yet.

It certainly wouldn't hurt to add such a fix to existing fixpacks (if there is one for EE games). However, there is still time until final patch 2.5 is released. Maybe Beamdog will clean up the game resources before the final patch is out.

@argent77

Still one more question. Would applying your patch on a pre-2.5beta version of the area file have any effect or would it just do nothing?

This mod simply fixes an inconsistency in the actor structures of ARE files. It should be useful even outside of EET preparation, in case other mods don't properly check consistency of these structures.

To the fix itself: Several actor structures are erroneously marked as having attached CRE files (as it is common only for ARE files in save games), including a valid-looking offset but CRE size of zero. This specific combination apparently leads EET to the conclusion to parse the non-existing CRE data without doing an additional size check. This mod makes both flag and offset/size fields consistent.

Actually, the erronerous actor flag was already present in BGEE v2.3, but both CRE offset and size fields were set to zero. A similar consistency issue can be found in BD7210.ARE and OH3100.ARE.

I have already uploaded an updated version. See original post above.

Good question. I've installed EET after fixing the ARE file manually. The mod has been created afterwards. I'll do another installation with the mod installed and see what'll happen.

Sure, here it is: SETUP-EET.zip

I was curious myself and installed EET on the latest 2.5 patches. My installation failed on this particular ARE file as well. I was able to track the issue to several invalid or conflicting actor definitions within the ARE file that EET seems to choke on.

I have created a small mod that fixes these inconsistencies: EET-ARE_fix-v2.zip

Run this mod on BG1EE before starting the EET installation.

EET will still finish with a couple of warnings, which may or may not affect gameplay in some way.

Edit: Uploaded a fixed version that doesn't produce log entries.

Colors are defined by their RGB values (each component in the range of [0..255]). I don't remember exactly which RGB values I've used for the example screenshot above (for the solid area some light green with a bit of blue mixed in and a bluish/cyan color value for the fog edges).

Some additions: Fog is a weather effect, so it does work only correctly if the map is added to MASTAREA.2DA. The fog effect itself needs some space to develop properly, so the map should not be too small. I wanted to use it in a smaller dungeon map, where fog should simulate poisonous fumes emanating from a portal. But it's difficult to make it look right, since dispersion starts too late.

Some bits from my own observations:

FOGAREA.2DA: Both ALPHA and CONTRAST appear to define visibility of generated fog. (OUTER/INNER)_(RED/GREEN/BLUE) can be used to define fog color (edges and inner area). RED and BLUE columns for both types are mixed up though. RED is actually BLUE and vice versa. PRE_DISPERSE_SECONDS is probably the delay before the stream of fog particles starts to disperse.

FOGPT.2DA: AMOUNT seems to be the amount of fog particles generated per time frame. DURATION defines the duration of the fog generator before it stops producing fog particles. X and Y can be used to define the location of the fog generator. I don't know if there is a way to define more than one fog generator per map. Adding multiple lines for the same area doesn't work. U_VEC and V_VEC define speed and direction of the fog particles, U for horizontal direction, V for vertical direction.

Both files support area-specific definitions by putting the respective area code in the first column.

Screenshot from ToB starting area (green fog with bluish edges, generated over one of the stone faces on the map):

I'd like to experiment a bit with fog effects in one of my mods. Apparently both FOGAREA.2DA and FOGPT.2DA can be used to influence fog behavior and appearance.

FOGAREA.2DA (SoD):

2DA V1.0
-1
          ALPHA   CONTRAST  OUTER_RED   OUTER_GREEN   OUTER_BLUE  INNER_RED   INNER_GREEN   INNER_BLUE  PRE_DISPERSE_SECONDS
1         0.75    120       211         211           211         211         211           211
2         0.10    100         0           0           205         224         255           255
3         0.10    100       238         232           170         238         232           170
4         0.10    100       238         232           170         238         232           170      
BD0120    0.25    100         0           0             0         255         255           240         60
BD1200    0.10     70         0           0           205         224         255           255         60
BD3000    0.25     80       210         180           140         210         180           140         60
BD4000    0.10     70       210         180           140         139          69            19         60
BD4400    0.49    110        35          15            15          65          45            45         60  
BD4500    0.49    110        35          15            15          65          45            45         60
BD4700    0.25     80        45          15            15          45          45            45         90
BD5100    0.20     50       176         224           230         175         238           238         60
BD6100    0.90    100       238         232           170         238         232           170         10

And FOGPT.2DA (SoD):

2DA V1.0
-1
    AMOUNT  DURATION  X     Y     U_VEC   V_VEC      
1   35      800       4473   583  -30.0    15.0  
2    5      400       3611  1637   -3.0     0.0 
3   70      400       2560  1920  -20.0   -15.0
4   15      400       1070   960   -1.0    -1.0

Does anyone have more detailed knowledge about what each parameter does mean? Are there more options to influence fog? (Avenger, CamDawg?)

In the Enhanced Editions it will apply a yellow/brown-ish tint to the map background, animations and creatures (including present party members). It's a good effect for dream or flashback sequences.

Example:

It works in BG:EE 2.5.15.1!

Using a helper creature works well enough for now. There is a random delay between using the item and the helper creature script being fired, but it's small enough to be tolerable. I'll switch over using splprot effects when the area type check has been fixed.

I... think there is a bug with the area type check

That's too bad. It means I have to keep using the helper creature for a while.

Not in my case. In addition to "Outdoors" I'm using a custom area type (added via areatype.ids) that has to be checked too. Using splprot.2da area type check would be perfect for my needs, if I could figure out how to make it work.