28 replies to this topic

[Ascension64]

Taimon, on Jan 2 2009, 06:16 AM, said:

Spent quite some time with this interesting problem. I've attached my approach to solve it.
The tp2 was able to find a solution in about 5 iterations on my vanilla BGT install. (~ 5300 CREs)

Unfortunately, the code is a bit nasty and I did not include much (any?) debugging information.
But the general structure is similar to your approach.

Looks funky, and I think its shorter than mine. Would you mind summarising the major differences between yours and mine because I'll have to include something into the next Tweak Pack. I'm still thinking of only extending existing for the 5 script CREs and making all other CREs use new scripts so long as they don't share a script with the 5 script CREs that is already extended. Maybe that is what your code does.

[Taimon]

Ascension64, on Jan 1 2009, 10:54 PM, said:

Looks funky, and I think its shorter than mine. Would you mind summarising the major differences between yours and mine because I'll have to include something into the next Tweak Pack. I'm still thinking of only extending existing for the 5 script CREs and making all other CREs use new scripts so long as they don't share a script with the 5 script CREs that is already extended. Maybe that is what your code does.

That's exactly what it does.
The major difference is that I try to select the most specific script when extending to minimize conflicts.
If there are any conflicts, the problematic CRE is processed earlier in the next iteration.
I don't think the code is shorter or cleaner, but it might be able to find a better solution.

What isn't implemented is your removal of duplicated scripts (really necessary?) and the CRE blacklisting. (But I don't think that you'd have any problems in adding those.)

And I haven't tested this on a mega-install.

[Ascension64]

Taimon, on Jan 2 2009, 09:52 AM, said:

Ascension64, on Jan 1 2009, 10:54 PM, said:

Looks funky, and I think its shorter than mine. Would you mind summarising the major differences between yours and mine because I'll have to include something into the next Tweak Pack. I'm still thinking of only extending existing for the 5 script CREs and making all other CREs use new scripts so long as they don't share a script with the 5 script CREs that is already extended. Maybe that is what your code does.

That's exactly what it does.
The major difference is that I try to select the most specific script when extending to minimize conflicts.
If there are any conflicts, the problematic CRE is processed earlier in the next iteration.
I don't think the code is shorter or cleaner, but it might be able to find a better solution.

What isn't implemented is your removal of duplicated scripts (really necessary?) and the CRE blacklisting. (But I don't think that you'd have any problems in adding those.)

And I haven't tested this on a mega-install.

Yep, I noticed the script counts, though I don't know how much of an advantage it gives, although at a probabilistic level it makes sense.

One thing I can't find in your script is if a priority CRE with 5 scripts will be processed twice, because it will be part of borth five_scripts_cre and prio_cre. It won't have any real effect but to save processing time because the CRE will be detected to have been already extended.

Duplicated scripts automatically blacklist certain scripts from being used as a basis for extension, which probably isn't desirable, and also may cause in-game bugs by themselves, so it is more of a fix to the game itself by removing them. There certainly is no benefit in having two of the same script.

CRE blacklisting is necessary - simplifying the process and ensuring that what you don't need to patch irrelevant CREs (in this case, all BG2-specific CREs). The scripts themselves have an ENDOFBG1 check to prevent them activating in BG2 as well.

Edited by Ascension64, 01 January 2009 - 10:38 PM.

[Taimon]

Ascension64, on Jan 2 2009, 07:37 AM, said:

Yep, I noticed the script counts, though I don't know how much of an advantage it gives, although at a probabilistic level it makes sense.

The downside is, that it takes rather long.

Quote

One thing I can't find in your script is if a priority CRE with 5 scripts will be processed twice, because it will be part of borth five_scripts_cre and prio_cre. It won't have any real effect but to save processing time because the CRE will be detected to have been already extended.

The script itself isn't optimized in any way. There are more parts where a CRE is processed more than once.
Will check if there is any notable speedup if I skip already processed CREs.

Quote

CRE blacklisting is necessary - simplifying the process and ensuring that what you don't need to patch irrelevant CREs (in this case, all BG2-specific CREs). The scripts themselves have an ENDOFBG1 check to prevent them activating in BG2 as well.

Yes, I know it's necessary. I was only curious if the script can handle all CREs in a BGT install.
Could you attach your CREExcl.txt?

[Ascension64]

Yep, basically it is (!({all BG2 CREs} n {all BG1 CREs}) u {CHARBASE}), where {} specifies a set.

Attached Files

•  CREExcl.txt   34.53K   270 downloads

Edited by Ascension64, 02 January 2009 - 02:02 PM.

[Taimon]

I've added the missing parts (cre exclusion, script removal, skipping over already processed cres) and added some debugging output.
It needs your CREExcl.txt in the working directory.

Takes roughly two minutes on my really old pc.

Attached Files

•  test_a64_script.tp2   9.54K   235 downloads

[Ascension64]

Taimon, on Jan 3 2009, 11:49 PM, said:

I've added the missing parts (cre exclusion, script removal, skipping over already processed cres) and added some debugging output.
It needs your CREExcl.txt in the working directory.

Takes roughly two minutes on my really old pc.

Thanks. Will see what I can do with including this code in.

[Taimon]

Maybe someone from the megamod group could check if it installs fine on a large installation.

[Ascension64]

Taimon, on Jan 6 2009, 01:09 AM, said:

Maybe someone from the megamod group could check if it installs fine on a large installation.

erebusant tested my old code on his install (see pinned thread). It worked in 5 iterations, surprisingly, although the DEBUG shows that the installation took 990 seconds (16.5 minutes)! No doubt yours would install quicker.