argent77

Param6 is actually the time when a limited effect has been applied (in ticks).

If you call the weidu binary directly to install EET, you should also make sure that a .DEBUG file with the installation log is created. By default the log is only printed to standard output.

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.

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.

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.