Avenger

I'm responsible for the wand boom in high hedge. The original game had them flagged as 'infinite supply'. I brought that down to 10. Doesn't the original BG have infinite supply regardless of the flag?

It is likely the engine supports only single class hp's and calculates the rest automagically. BG2EE doesn't even have those extra tables.

Gender (gender_both) should definitely be set. But i think you must also use the solar/antisolar animation ID, which severely limits the usability.

0x0004 is the version number.

Does the "Special" parameter for opcode 319 refer to the field at 0x2c Avenger described as Param 2.5? Is the list of IDS files that can be referenced by this and other opcodes increased at all? Referencing kit.ids would be nice. To make sure I understand "Spell level set to 1 means only usable by", let's say there was an effect that specified Param2=7 (GENDER.IDS) and Param1=2 (FEMALE). With spell level set to 1, it would prevent non-female characters from using the item, but with spell level set to something else, it would prevent female characters from using it? Is there anything that could make an item usable by a kit but not its parent class? 9 - kit.ids (works with almost all ids targeting opcode, except protection from creature) Opcode 319 also works with name/scripting name.

I think the mirror image bit was also implemented.

Does the "Special" parameter for opcode 319 refer to the field at 0x2c Avenger described as Param 2.5? ... Yes, it is there so you don't have to make external eff files.

0x2c is a special field that is interpreted opcode specifically in a handful of opcodes. Think of it as a param #2.5 It exists in eff v1, so its use should have been encouraged more instead of param #3 which exists only in eff v2.

DLTCEP 7.7 supports the new EE engines (up to IWDEE) You can download the newest version from SourceForge.

Hovering wall description is not correct in the tutorial. The hovering wall polygon data is actually two separate data: 1. the first two points are a baseline 2. the rest of the points are the polygon So, it doesn't make sense to have less than 5 points in a hovering wall polygon (and less than 3 would cause assertion). (3 would make a point, 4 would make a line, 5 would make a triangle). There is also a rule about the order of the points (iirc, it is counterclockwise). But i think DLTCEP fixes them with the Order all button. So, a hovering wall can have a different baseline than its normal baseline (which is the first line of the polygon). This is used for arches where the baseline (the ground) is lower than the lowest line of the polygon.

1) Look at the image's name 2) ? 3) PROFIT!!! 2) find mapname.2da and resolve the strref

Just for your knowledge: i've added a 8 bit height map editor. It was added in a kind of haste, it can cause some problems if you click on the '8 bit' radiobutton and then save the area I still don't know what is the significance of 8 bit heightmaps, this change was more like a researching tool than a finished feature. For heightmap researchers: ar1300 (nalia's keep) in bg2 is the most interesting one some pst and how heightmaps iwd2 has no meaningful heightmaps at all, let alone 8 bits

Here is the first information that could come with the wikification much easier: I believe the description (some short name) of projectiles belongs to IESDP. We even name a lot of them, but they would clutter the various effect descriptions. These lists are different for each game, and some cause assertion failures on one game but work perfectly on another. So, a validated list might help modders greatly (assuming they create or port items or spells). Even the information on what projectiles are valid for one gametype is surely incomplete. ToSC - valid range: 0-0xcc ToB - valid range: 0-0x109 TOTLM - valid ranges:0-0x163 AND 0x1001-0x106c I didn't test vanilla BG/IWD/BG2, HoW/IWD2 and PST yet. In this case, even a small engine difference like between ToTLM and HoW may count.

Well, you failed There is no point in restarting the information gathering process from the beginning --> we need all the current data There is no point in restricting the possible sources of information --> we need an established place which interested people already know and would use The above points pretty much bar us from just starting a wiki out in the void. Is there any reason why a wiki couldn't be placed in the current IESDP site? As far as i see DevSin has problems with the wiki format? (the obscure site place is not a valid complain) Igi has problem with time?

The biggest benefit would be a bigger amount of data, IESDP is currently restricted to some select aspects of the engine. Also, updates would be more frequent.

about d: I would work on an iesdp wiki, but only after the initial iesdp data was imported. (if i'm a trusted person)

Most likely on teambg.eu you can find both of them

I guess it is only gui mods, and in case of bg1/pst mods that would add small areas

Most stuff will be smaller (like menus and such). The only good thing is that the game area will be expanded. For PST and BG1 this improves gameplay.

Yovaneth's complete area building tutorial. And here is the the update page.

I thought a little bit about compatibility with gemrb. I come to the conclusion that gemrb is more or less compatible with this stuff because it calculates those offsets hardcoded in the IE automagically. It just tries to fit the panes on the left/top/bottom/right side of the game screen, and what remains in the middle, will be the game area. DLTC alters the menu (left pane in the main game window), so it is not compatible, but would work. Btw, it is not dead, just sleeps (in a DLTC ftaghn kinda way).

I think the goal was to enlarge tha game screen, not to redesign all of the gui. The latter is also possible, but i don't think anyone will take the efforts. What would you put in the additional screen space anyway

Ahh, i didn't know you had to patch the .exe

It could be that it is incompatible with DLTC, as DLTC overwrites a few gui files. And i wonder if this will work with GemRB.