My new "Made in Heaven" mods

[Bartimaeus]

1 minute ago, Angel said:

I've tested this here, the version of DS I use leaves the double entry for 115 alone.  Just as an extra precaution, I'll also add EXTRAPROFICIENCY1 to stats.ids if it is missing.

SR would still break it, but hey, if anyone's on an EE game and happens to install MIH_EQ before they install the couple of Polytweaks components affected by this (assuming they didn't also install SR in the meanwhile), they'd find that it automagically works!

[DavidW]

35 minutes ago, Bartimaeus said:

I think...from what I can tell, that the SR version of it has its own custom additions to Detectable Spells

Are you sure? It looks like the unaltered v3.95 (which, absolutely, was written by Ardanis). SR's code uses DS to load a custom table of spell changes, but that table is empty in any case so it doesn't matter.

Which macro is missing when you try SCS's version? I just tried installing it on a clean test mod (no other function libraries) and it seemed to work fine. 

[Bartimaeus]

1 hour ago, DavidW said:

Are you sure? It looks like the unaltered v3.95 (which, absolutely, was written by Ardanis). SR's code uses DS to load a custom table of spell changes, but that table is empty in any case so it doesn't matter.

Which macro is missing when you try SCS's version? I just tried installing it on a clean test mod (no other function libraries) and it seemed to work fine. 

Okay, that's a relief: that means there should be very little to fix. "ds_altered_spell" is what it said, IIRC. My assumption is that the ds.tph is probably called before the main component proper is installed, and then the rest of the main component does some additional stuff using some of the same macros that the ds.tph file defines, and presumably that macro has disappeared or been renamed since SR last updated DS. I can probably figure it out knowing that it's the same ds.tph.

Edited July 28, 2020 by Bartimaeus

[DavidW]

Oh - got it.

Yes, version 3.x has some functionality (installed via the ds_altered_spell function) intended to tell later mods how to allow for changes to spells when installing DS, and SR makes (a very small amount of) use of it. My view was that it wasn't really robust and changes would have to be allowed for explicitly to work, so I deprecated it in v4. I think the v4 DS should handle SR fine (well, at least as fine as the v3.9x DS) without that functionality.

I would just add 

DEFINE_ACTION_FUNCTION ds_altered_spell BEGIN END

somewhere, if you don't want to strip out the ds_altered_spell functions manually.

[Bartimaeus]

@DavidW

Gotcha. I was looking over the new ds.tph and it did seem like that functionality had been stripped out with nothing to really replace it. I'm all about removing things entirely rather than letting pointlessly confusing vestiges remain. Yoink! Now it installs fine, thanks! Whoops, actually, it failed at like the last second of installation while I was typing this up, let's see here...and it doesn't really say what went wrong in a way I can understand.

https://dl.dropboxusercontent.com/s/g1wnbfk5zmbhfnb/SETUP-SPELL_REV.DEBUG

I tried mucking around and seeing if it was something to do with the way SR was calling DS, but nothing I did made a difference - still kept getting this same "cannot convert resource_col" error over and over.

(e): It seems to be dying on every single table it's processing on line 12 - I removed the ds_simple from being processed, and it then died with the same error on the ds_142_variable table, and the same for the next one. Why, I don't know, since I haven't changed a danged thing.

(e): No, seriously, I removed every single part of this component from being installed except for:

/*------Spell Revisions------*/

BEGIN @9996
DESIGNATED 0
REQUIRE_PREDICATE (ENGINE_IS ~soa tob bgee bg2ee eet iwdee~) @8996 // ~This mod is designed for the Baldur's Gate II engine and will not function on other games.~

INCLUDE ~spell_rev/lib/ds.tph~

// Detectable Spells
LAF detectable_spells END

...and it's still dying from that error with just that.

Edited July 28, 2020 by Bartimaeus

[khelban12]

4 hours ago, Bartimaeus said:

I had tracked it down to SR's version being the one that's crapping out, it removed an entry that polytweak uses for no apparent reason (specifically, entry 115 EXTRAPROFICIENCY1, which normally gets appended with...uh...I think it was PROFICIENCYCLUB? When installing SR after, it strips the original EXTRAPROFICIENCY1 entry and only leaves the PROFICIENCYCLUB entry, causing errors for mods like polytweak that evaluate via the original entry). I repaired it for my install, but for anyone using both MIH_EQ and SR, the same would happen, so I'd like to fix it.

Thanks for the info, will do.

@Angel Don't think there are any conceptual incompatibilities between any of the components of MIH_EQ and SR/IR from what I saw anyways, but you might know better!

 

3 hours ago, DavidW said:

That makes sense. DS sorts stats.ids after appending all the new entries, but the sort used by DS 3.9x (the one in SR) is destructive, and ends up deleting duplicates. The version in SCS 33 (let's call it v.4.0) sorts nondestructively (iirc).

Due to some problems i had in the past with DS and mods, i keep locally all the versions i find and there are (at least) the following versions:

• v3.95 which is the "updated" version of the older DS code and comes with the majority of mods (atweaks, questpack, rr, etc). It removes all duplicate entries except 156-161 (SCRIPTINGSTATE1-6).
• v3.95_dw (found in ascension commit 092ac9d24c55). It correctly keeps all the duplicates but does not sort (the sort_ids function is disabled due to missing the function return_first_entry).
• v3.96 (found in ascension commit c24fe75c92f7. i haven't saved the SCS commit but in most cases ascension DS is copied from SCS of that time) and v3.97 (commit a1d4ec4cef29). These correctly keep all the duplicates and sort correctly. They also need AUTO_EVAL_STRINGS on the main tp2 in order to be used. The only difference with v3.97 is that it removes DMWW entries where all older versions keep them.
• v3.9X (found in ascension v2.0.4 commit 2fb5d79073e1). Vastly difference code than v3.97. It correctly keeps all duplicates and sorts correctly. It contains some extra duplicate entries that miss the WIZARD_ prefix (for exaple 178 RESIST_FEAR). This clears the IDS map very frequently and runs quite slower than the older versions.
• Newer SCS versions. I do not remember correctly but i think they behave exactly like v3.9X but also need some sfo libs in order to run.

Everything after v3.97 runs quite slower (i did a test run now and v3.97 ran in 3.5secs while v3.9x ran in 4.58secs. In a fully modded installation i think there was a big difference in time).

[DavidW]

Do you have AUTO_EVAL_STRINGS in your tp2 preamble?

[Angel]

12 minutes ago, DavidW said:

Do you have AUTO_EVAL_STRINGS in your tp2 preamble?

Yes, had it from practically day one.  Got tired of having to put EVAL everywhere.  And I don't think SFO will work without it, actually.  (The version I use is from SCS v30 or so, with a bunch of bug fixes and a few tweaks of my own.)

[Bartimaeus]

1 hour ago, DavidW said:

Do you have AUTO_EVAL_STRINGS in your tp2 preamble?

Hah, I was just looking at how MIH_EQ calls it and noticed it was missing that seconds before I heard the beep for a new post here. Setting that makes ds.tph work, but it breaks other parts of the mod, like this section:

COPY_EXISTING ~dvscrlmap.2da~ ~override~
    COUNT_2DA_COLS cols
    READ_2DA_ENTRIES_NOW ~r2en_schools~ cols
      FOR (row = 1; row < r2en_schools; row += 1) BEGIN
        READ_2DA_ENTRY_FORMER ~r2en_schools~ row 0 the_spell
        READ_2DA_ENTRY_FORMER ~r2en_schools~ row 1 the_scroll
        READ_2DA_ENTRY_FORMER ~r2en_schools~ row 2 the_school
        TEXT_SPRINT $d5_spell_scroll_school(~%the_spell%~ ~%the_scroll%~) ~%the_school%~
    END
BUT_ONLY

It's complaining about being able to read the "r2en_schools" variable. Presumably, I'm missing some sort of now-important contextual punctuation around these variables, but I'm not sure what. While I did read the description for AUTO_EVAL_STRINGS in the weidu_documentation and I think I understand what it means, I'm still not really grasping why it would break something like this. This sort of trash is why I'll never be a programmer - I have absolutely zero patience for this kind of tomfoolery, especially when the debugger can't tell me exactly what's wrong at a low enough level for me to understand with no prior understanding of the specific language, .

Edited July 28, 2020 by Bartimaeus

[Bartimaeus]

35 minutes ago, khelban12 said:

 

Due to some problems i had in the past with DS and mods, i keep locally all the versions i find and there are (at least) the following versions:

• v3.95 which is the "updated" version of the older DS code and comes with the majority of mods (atweaks, questpack, rr, etc). It removes all duplicate entries except 156-161 (SCRIPTINGSTATE1-6).
• v3.95_dw (found in ascension commit 092ac9d24c55). It correctly keeps all the duplicates but does not sort (the sort_ids function is disabled due to missing the function return_first_entry).
• v3.96 (found in ascension commit c24fe75c92f7. i haven't saved the SCS commit but in most cases ascension DS is copied from SCS of that time) and v3.97 (commit a1d4ec4cef29). These correctly keep all the duplicates and sort correctly. They also need AUTO_EVAL_STRINGS on the main tp2 in order to be used. The only difference with v3.97 is that it removes DMWW entries where all older versions keep them.
• v3.9X (found in ascension v2.0.4 commit 2fb5d79073e1). Vastly difference code than v3.97. It correctly keeps all duplicates and sorts correctly. It contains some extra duplicate entries that miss the WIZARD_ prefix (for exaple 178 RESIST_FEAR). This clears the IDS map very frequently and runs quite slower than the older versions.
• Newer SCS versions. I do not remember correctly but i think they behave exactly like v3.9X but also need some sfo libs in order to run.

Everything after v3.97 runs quite slower (i did a test run now and v3.97 ran in 3.5secs while v3.9x ran in 4.58secs. In a fully modded installation i think there was a big difference in time).

...RR has this same version of Detectable Spells? Well, that's just grand. So if not IR, then RR will do it instead. Great, .

[DavidW]

50 minutes ago, Angel said:

Yes, had it from practically day one.  Got tired of having to put EVAL everywhere.  And I don't think SFO will work without it, actually.  (The version I use is from SCS v30 or so, with a bunch of bug fixes and a few tweaks of my own.)

SFO definitely doesn't work without it, in that it does a sanity-check for it:

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Sanity check for AUTO_EVAL_STRINGS
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////

 OUTER_SPRINT var testers
 OUTER_SPRINT players var
 ACTION_IF !"%%players%%" STRING_EQUAL testers BEGIN
      FAIL "AUTO_EVAL_STRINGS is not set (you need to include it in your tp2 preamble to use SFO)"
 END

 

[DavidW]

As for the clash between SR and AUTO_EVAL_STRINGS... I guess in hindsight it was antisocial for me to code the latest ds.tph to assume it. I'll see if I can work out a version that doesn't require it (it may be difficult; I've been coding with AUTO_EVAL_STRINGS for seven years...)

[Angel]

And all this just because I needed one SSL script for one creature...  Oh well, at least it did help me improve my mod code and address a couple of issues I would have had to address before releasing the next version of E&Q anyway. ^^

[subtledoctor]

2 hours ago, Bartimaeus said:

It's complaining about being able to read the "r2en_schools" variable

That looks like something I added to SRv4b18 to auto-update scrolls to match their spells, or something. In general, my use of READ_2DA_ENTRIES_NOW can usually be tightened up. 

This conversation is almost entirely over my head; go ahead and tag me if there’s something I can do to improve the SR main branch unless you’re going yo do that yourself @Bartimaeus ). 

At risk of commenting about something I don’t understand, if integrating the new SCS version of DS is problematic, why not just make a small adjustment to the current version, commenting out the big that removes IDS duplicates?

[Bartimaeus]

6 hours ago, subtledoctor said:

That looks like something I added to SRv4b18 to auto-update scrolls to match their spells, or something. In general, my use of READ_2DA_ENTRIES_NOW can usually be tightened up. 

This conversation is almost entirely over my head; go ahead and tag me if there’s something I can do to improve the SR main branch unless you’re going yo do that yourself @Bartimaeus ). 

At risk of commenting about something I don’t understand, if integrating the new SCS version of DS is problematic, why not just make a small adjustment to the current version, commenting out the big that removes IDS duplicates?

Yeah, I was planning on mentioning something in the SR bugs thread as soon as it was actually figured out, .

I don't understand enough about the current version to probably do that, either. It's complicated code, and the versions in SR and SCS are very radically different from each other so it's difficult to analyze what changed to make it work correctly.

7 hours ago, Angel said:

And all this just because I needed one SSL script for one creature...  Oh well, at least it did help me improve my mod code and address a couple of issues I would have had to address before releasing the next version of E&Q anyway. ^^

Spamming the heck out of your thread. Whoops, haha.