Avenger

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.

Opcode 319 is a new opcode used to restrict items to specific IDS values:

 

Opcode #319 Usability
Spell level set to 1 means only usable by
Parameter #1: IDS Entry
Parameter #2: IDS File
Special: STRREF displayed in the item description.

 

It also has a secondary use where it can be used to restrict items to a specific NPC--using the name STRREF in parameter1, death variable in the resource field, and parameter2 to 10.

 

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.

2 EA.ids

3 General.ids

4 Race.ids

5 Class.ids

6 Specific.ids

7 Gender.ids

8 Align.ids

 

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.

BGEE has that new flag on effects, bit 25 among the save-type flags, 'ignore difficulty' isn't it? Are there any more that I don't remember/is not aware of?

I think the mirror image bit was also implemented.

Opcode 319 is a new opcode used to restrict items to specific IDS values:

 

Opcode #319 Usability
Spell level set to 1 means only usable by
Parameter #1: IDS Entry
Parameter #2: IDS File
Special: STRREF displayed in the item description.

 

It also has a secondary use where it can be used to restrict items to a specific NPC--using the name STRREF in parameter1, death variable in the resource field, and parameter2 to 10.

 

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.

Could you give me the area code for ##3 and 4, so I can have a closer look?

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.

Not to be an ass, but if you want a wiki, make one. Otherwise, STOP COMPLAINING.

 

I don't like wikis. I would much rather discovery and documentation come about through discussion and forcing igi to review everything than shadow-posting on a dumb random webpage that nobody will ever find.

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?

I'm unsure what you mean about wikification, or rather how it can make IESDP easier to use. Global search function is hardly vital, as most everything can be tracked from the main page.

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.

Does this mean I could possibly run the icewindale series on mac OS X using the windows files?

Sure, why not

The cvs is updated daily, i have no idea when will be the next windows release.

I want the next release to contain basic melee combat. (no projectiles, no magic).

Once that's done, and the most glaring bugs are fixed, we'll make a windows binary release.