Jump to content

Detectable Spells re-sorts STATS.IDS?


subtledoctor

Recommended Posts

 

 

there is a function in Detectable Spells that sorts stats.ids into order

 

Whatever is the point of re-sorting STATS.IDS? Seems likey to only create problems, with very little benefit.
Ask whoever wrote that bit of DS. (But: readability, Id imagine.)

That's a terrible reason. Who needs to read that file?

 

Am I being paranoid? The situation I'm concerned about is something like:

- A completely hypothetical (cough) mod gives an extra 1/2 APR if you have specialization in Single-Weapon Style.

- It does so by applying an EFF that grants +1/2 APR while equipped; that 177 effect is preceded by a 318 effect which makes you immune to the EFF as long as your SWS stat is less than 2.

- Another mod comes along and changes the order of entries in STATS.IDS, moving the SWS stat to a different place in the table

- Now the 318 effect no longer points to SWS, but to some other stat?

 

EDIT - hm, I see the the IDS file has a numbered index in the 1st column. So I guess 318 and similar effects look at that index number, and not at the table row number? In which case all is well.

Link to comment

In my defense:

 

1) I did end up giving such credit at the end of the post.

 

2) Some tables (EDIT - 2da tables at any rate) have index numbers and others don't and instead rely on the row #; which ones and why are not obvious to a casual observer.

 

3) At the time DS was written, the engine did not contain any effects that reference STATS.IDS indices; opcodes 318, 324, and 326 were added in EE v1.4. It is entirely reasonable to think the writers of that DS function did not take into account an issue that would only manifest 10 years later.

Edited by subtledoctor
Link to comment

In my defense:

 

1) I did end up giving such credit at the end of the post.

I wasn't very serious.

 

2) Some tables (EDIT - 2da tables at any rate) have index numbers and others don't and instead rely on the row #; which ones and why are not obvious to a casual observer.

Yeah, it's 2da only. 2da and ids files play completely different roles in the game architecture, despite the formal similarities. If you look at a bunch of them, you'll see that 2da entries have lots of different sizes and entry formats. But ids files are invariably 2-column lists with a number in the first column and text in the second. The number is all the engine cares about; the text is just a way of identifying the number in a human-readable way.

 

3) At the time DS was written, the engine did not contain any effects that reference STATS.IDS indices; opcodes 318, 324, and 326 were added in EE v1.4. It is entirely reasonable to think the writers of that DS function did not take into account an issue that would only manifest 10 years later.

Not quite: (i) the latest (pre-SCSv32) version of DS is from 2016ish, and takes extensive account of EE (I think Ardanis wrote it as part of the Siege of Dragonspear writing process); (ii) 233 and 282 reference STATS.IDS indices (that's how DS worked, in the pre-ToBEx/pre-EE era). (EDIT - or maybe you mean only EE opcodes have effects that *depend* on stats entries? That's probably right, but presumably if reordering stats.ids had problematic consequences, it would have had them for 233/282 too.) Edited by DavidW
Link to comment

As far as IDS files are concerned, the order of entries is irrelevant. Unlike 2DAs, they exist purely for user's convenience when compiling scripts, and might as well have been empty.
I'm pretty sure the sorting algorithm was first introduced by David when he updated DS to meet SCS' demands about ten years ago. That version still had inherited some compatibility issues, which I needed to resolve for SR+SCS installations and which brought me to update DS to v3.
While I suspect SCS' version didn't actually *need* readability of stats.ids, with the advent of ToBEx and its 200+ extended stats there came a potential problem of multiple ToBEx mods adding their own custom stats with possible conflicts. Since maintaining yet another community list of things hardly seemed like a good choice, I wrote a function to dynamically add new stat entries into the first unoccupied slot - much like ADD_SPELL works nowadays, - and for that purpose sorting entries beforehand was actually useful. Though I'm pretty sure one could do with unsorted mess as well, it just seemed extra work when the file was already being sorted even before I jumped in for maintenance.

 

 

 


In my defense:

1) I did end up giving such credit at the end of the post.

2) Some tables (EDIT - 2da tables at any rate) have index numbers and others don't and instead rely on the row #; which ones and why are not obvious to a casual observer.

3) At the time DS was written, the engine did not contain any effects that reference STATS.IDS indices; opcodes 318, 324, and 326 were added in EE v1.4. It is entirely reasonable to think the writers of that DS function did not take into account an issue that would only manifest 10 years later.

318, 324 and 326 only reference either a row in SPLPROT.2DA, or an index in specified IDS. The former does depend on the order of rows, the latter doesn't. Edited by Ardanis
Link to comment

I'm pretty sure the sorting algorithm was first introduced by David when he updated DS to meet SCS' demands about ten years ago.

I could believe it. It's entertaining if so (and reassuring: that means there isn't a secret need to eliminate duplicate entries that I didn't know about!)

 

I absolutely agree about dynamically adding entries; of course, it's only an option now that EE and ToBEx have opened up the space of options. (The motivation for the old community lists was that space was so tight in the tiny set of available unused proficiencies and scripting states.) I do the same in SCS for new splprot entries.

Link to comment

Actually, I now definitely remember you've been reading stats.ids as array (?) and then using 1-200 range to append a blank file. That is, completely destroying any 200+ stat added for ToBEx :D

// Detectable Spells v3.1
//
// Assembled by Ardanis/GeN1e, using DavidW's version (SCS) as a base
//
// Changes from previous version (SCS):
// - if Khelben's Warding Whip is broken, we first will attempt to repair it
// - removing older Ascension version of DS is less destructive
// - patching STATS.IDS is compatible with ToBEx

 

Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...