26 replies to this topic

[King Diamond]

Subj (with a grammar mistake ).

Let's take as an example STATS.IDS

It contains textual abbreviations for several numeric codes that can be used in some script functions. As a result - you just can make your script coding USER FRIENDLY, nothing more.

But as a programmer myself I see that something is missing in all that scheme taking in account that new mods can (and DO) add new entries in that IDS.

It has absolutely no sense for me because before adding of some new working code (as far as I understand a CODE has a meaning for the engine) you have to force a game engine 'to LEARN' that new code, to learn how to process it and what to do if it found it in a script (not synbolic script but already COMPILED).

So, I've definitely missed something in that scheme and can't find a trace on how the game engine resolves newly added codes/names. Plz somebody tell me - how does it work?

P.S. LEVELDRAIN constant with a code 200. Present in ToB, Ascension versions of STATS.IDS but in BP's one it has a code 134. In use EVERYWHERE, in all game configs. So how will engine react if it'll find it in script?
And the most important thing: who/what and where will set PC's state to LEVELDRAIN value? (spells/effect parameter..? can't find anything...)

Edited by King Diamond, 01 March 2005 - 03:39 AM.

[igi]

You can't add *new* data to all the .IDS files.
You can only add data the engine already knows about, but isn't listed in the IDS files.

[King Diamond]

You can't add *new* data to all the .IDS files.
You can only add data the engine already knows about, but isn't listed in the IDS files.

How about modifying existing entries? Changing existing codes (as for LEVELDRAIN from 200 to 134) should confuse the engine and break everything then...

[igi]

The names in stats.ids are only used when compiling scripts, as a convinience - you write in your script LEVELDRAIN, and the compiler reads the ids, and converts your identifier into the assosicated number.

If you've changed stat 100 to be LEVELDRAIN, instead of stat 200, the compiler will insert the wrong number, so your script will check the wrong thing, but the engine itself doesn't care.

NB. This is all my own opinion. I didnt write the engine, it could be working things out be solar alignment for all I know People also say dialogs work differently. Whatever.

[CamDawg]

Dialogs work differently only in that they're not compiled and check IDS files on the fly. For example, if I use InParty in a script, compile it, then change InParty to another opcode in the IDS files, my compiled script will continue to use the old opcode. If I have a dialogue with an InParty check and then I change InParty opcode in the IDS files, the dialogue will use the new opcode.

You can not add new opcodes--there are some ToB triggers and actions that work in SoA and therefore could be added, but these are not "new." You can add duplicate entries for the same opcode (IsValidForPartyDialog, IsValidForPartyDialogue, IfValidForPartyDialog, and IfValidForPartyDialogue for example).

There are a few exceptions. Where IDS files list compiler translations instead of opcodes, you can do some ninjary. You can add entries for GTIMES.ids, for example, to make it more friendly to script compilation (code stolen from devSin):

APPEND ~GTIMES.IDS~ ~5 ONE_MINUTE~ UNLESS ~^5\b~
APPEND ~GTIMES.IDS~ ~10 TWO_MINUTES~ UNLESS ~^10\b~
APPEND ~GTIMES.IDS~ ~15 THREE_MINUTES~ UNLESS ~^15\b~
APPEND ~GTIMES.IDS~ ~20 FOUR_MINUTES~ UNLESS ~^20\b~
APPEND ~GTIMES.IDS~ ~25 FIVE_MINUTES~ UNLESS ~^25\b~
APPEND ~GTIMES.IDS~ ~30 SIX_MINUTES~ UNLESS ~^30\b~
// etc

[King Diamond]

The names in stats.ids are only used when compiling scripts, as a convinience - you write in your script LEVELDRAIN, and the compiler reads the ids, and converts your identifier into the assosicated number.

If you've changed stat 100 to be LEVELDRAIN, instead of stat 200, the compiler will insert the wrong number, so your script will check the wrong thing, but the engine itself doesn't care.

Exactly. But what's the reason to change something in IDS at all? I mean - original opcodes changing (see LEVELDRAIN above 200->134)... Of course, compiler will insert wrong code and engine will check PC's stat with numeric code 134 (which is originally something like EXTRAPROFICIENCY20, not LEVELDRAIN). But script's source code is perfectly says: check for LEVELDRAIN, that absolutely foolls everybody (script author in the fist place)... Script logic is absolutely broken in such way....

So, I'm asking: what the hell all those .IDS modifications (read - original codes changes) about? And corresponding compatibility/incompatibility discussions...

HORRED! ANSWER ME!!!!! What the hell have you done with BP?
And you're telling that f.e. Ascension is somehow incompatible with BP. May be BP is incompatible with ToB at all with IDS mixing (I'm sure of it now )????

As far as I could understand: changing original IDS entries (using different opcodes for the same symbolic names) is absolutely prohibited.
It's possible to 'reveal' previously 'undocumented' entries (if somebody 'decifer' them) though....

Edited by King Diamond, 01 March 2005 - 06:00 AM.

[igi]

It sounds like you're after a specific answer, probably relating to BP. Since I've never played it, nor looked at it's files, I cant really answer well enough.

[Seifer]

Is this related to BP? If not, I'd want to move it to the general forums.

Seif

[King Diamond]

Is this related to BP?  If not, I'd want to move it to the general forums.

Seif

Related. I want to know why Horred made all those modification, specifically for BP.... I think that was a wrong step and have to be corrected in the new version....
And this could affect the new mod incorporation as well...

Edited by King Diamond, 01 March 2005 - 06:28 AM.

[Isaya]

STATS.IDS may be an exception here (being moderately easy to modifiy without the game engine internal knowledge). I think this dates back to the detectable spell package. From what I understood, these people modifed spells to change a stat when the spell is cast so that other characters can check through script the stat of the character who cast the spell in order to find out which spell was used (the way you can determine from the graphic effect that a mage has cast stoneskin or another protective spell).
As some values of stat are not used by the engine, you are somehow free to use these values as you like. This may explain why the values used by Horred are somehow different from those used for Ascension (using the original detectable spells). If I remember correctly, Horred thought that some of detectable spells detections were cheating on the player and decided to rewrite it in a non-cheesy way.
You'll probably find some information on that if you get hold of the detectable spells package (original one or Horred's one for BP, available from the Yahoo group maybe).

Edited by Isaya, 01 March 2005 - 02:43 PM.

[horred the plague]

That was me.

King Diamond, that STAT.IDS is the key to the AI in BP. The entries I converted were carefully documented and tested by Avenger (maker of DLTCEP) and I. Several spells have special effects added to them to set these values on casters, victims, beneficiaries, etc. For an amount of time that equals the spell duration. Spells like Dispel Magic reset the values of certain spells (like Stoneskins, Minor Globes, etc--the particulars that they dispel).

What is the advantage of "all this madness". Spells and spell effects are now detectable in scripts--many dozen that were not so, formerly. You can consequently script somebody's reaction according to this data. This obviously makes opponents for more intelligent, and dynamic. If you want a full documented version of my changes to STATS.IDS, download the BP Detectable Stats package from my BP Yahoo site. It will explain more, I think.

And why did I change 200 to 134? Because 200 was tested as non-functional! That IDS file you refer to came out from the modders of the day. (I believe the scripting pinoeer Kensai Ryu was the original maker of that IDS file). Even Bioware did not know everything that STATS.IDS was set up for by the engine programmers. I confirmed this with David Gaider, when he gave me permission to add Ascension directly into BP (I'd still have a copy of the email, if TeamBG hadn't shut down). He also gave me permission to make whatever changes and improvements I felt necessary. And, after testing several of the slots from the STATS.IDS files, I found that several that were in use (by Ascension, and many other modders even to date) were either disfunctional or "quirky". One of them, 167 if I remember, would cause the foot circle animation to disappear if set to 1 by the ModifyProficiencies effect in a spell. Modify Proficiencies is how you set values in STATS.IDS; you could use SetScriptingState for some--but it turns out many of the available ones were the quirky slots I mentioned earlier! (Quirky slots correspond DIRECTLY to effects opcodes, by the way...) NTM--zero started at where SCRIPTINGSTATE1 is right now, and could only be set up to 35. Scripting States above 35 did avbsolutely NOTHING. Do the math--156 plus 35 is what? Less than 200. I left that 199 STONESKINSGOLEM in there "just for the halibut"--it's not harming thing, it's not doing anything, I saw no use for it elsewhere (every valid slot is filled now). A check for LEVELDRAIN, however, was a valuable check. So, I moved it to a working slot.

I'm sure you can see the uses of adding spells to SPELLS.IDS. It's not necessary--you can also refer to the spell by SpellRes--but it looks "prettier" this way. ;D Kits.IDS? Those changes are linked to documented hexidecimal opstrings as well. The ones Bioware released didn't work. That's okay--they weren't even using them in their AI, hehe.

Using the KIT.IDS entire as they stand in BP (and TS, and NeJ) is what actually gives an outside chance of making the TDD kits work as they are written. If you look closely, I make some of those kits function by combination of spells, scripts, and even IDS entries and script-activated effects (vvc's also). Shining example of the new KITS.IDS in action: look for the Anti-paladin code in the top of BALDUR.BCS.


Need a good example of STATS.IDS in action? Open up GPMAGE1.BCS, and see what I did there. You'll see a lot of other modified IDS (IDentifierS) at work there too. Doing things that would be utterly impossible without them.

Edited by horred the plague, 01 March 2005 - 03:20 PM.

[King Diamond]

King Diamond, that STAT.IDS is the key to the AI in BP. The entries I converted

Thanx a lot for such detailed explanation. It clears many for me... :thumb:

[SimDing0]

Out of interest, Horred, do you recall exactly what was broken with the original Detectable Spells? It'd be nice to get that fixed up if there are problems with it.

[horred the plague]

Out of interest, Horred, do you recall exactly what was broken with the original Detectable Spells? It'd be nice to get that fixed up if there are problems with it.

All I can really say, Sim, is to look at which entries I used. I used every one that worked, and did so without noticeable side effects. There were scripting states available from 0 to 35, but over 32 had manifested effects attached. The other spots I left empty in between also had these. (Like the foot circle removal I mentioned earlier).

I truthfully suggest using mine as a base, and just take out the TDD stuff. You can add what you want in its place, if you so desire.

[SimDing0]

I'm just surprised people have been playing Ascension for years without noticing that foot circles tend to disappear randomly. I'll compare the versions at some point, thanks. (As a side effect, this'd probably help out in making various mods BP-compatible if they're updated to a fixed system.)

[Sir BillyBob]

Sim, the foot circles can disappear for other reasons (namely BAM animations - any IWD fireplace animation) so it may be that players just got used to it disappearing at times, if they ever noticed at all.

[SimDing0]

I can't say I've ever noticed foot circles disappearing in vanilla BG2 (save on the Spore Colony and Ankheg animations), but okay, that could be it. Foot Circle Removal is a pretty nasty effect though, so I'll definitely take a look into this.

[hlidskialf]

I can't say I've ever noticed foot circles disappearing in vanilla BG2 (save on the Spore Colony and Ankheg animations), but okay, that could be it. Foot Circle Removal is a pretty nasty effect though, so I'll definitely take a look into this.

IIRC, there was only one or maybe two of the foot circle issues. Besides the main culprit of some just not working, there was also a series of false readings generated because some of the entries would return true if certain proficiencies were on the character. I may have even saved the thread from TeamBG that detailed all this but I won't be able to look until my laptop's back up and running. Anyways Sim, check the Prof. angle for conflicts as well, it might give you a head start.