DIY-manual discussion

[Jarno Mikkola]

(by reusing the random seed and controlling input factors). "Preserve" is only available if the mod has been installed in the past.

Could you make the random seed number to on display in the install debug file ? Cause 0ne could technically use the same randomization, if you just set the seed to that value in the .tp2 code... next time elsewhere. Yes, this is how evil we are now. Heh-eheheheheh.

[Gibson]

Thanks for the info!

Could you not achieve this by adding a small number of "easy" locations to a high tier?

Yes, I suppose this would work, the only caveat being you would know precisely those locations which "may" have a better item and precisely the item tier. Well, whoever edited the lists would, at least.

I can go into the technical bits if you want, but the short of it is that installing the mod with "preserve" will generate the same random results you got the last time you installed the mod (by reusing the random seed and controlling input factors). "Preserve" is only available if the mod has been installed in the past.

So it sounds like it behaves even worse (for my purposes) than I thought. To clarify, I have been using mode 2 exclusively (no BG2 engine) with good results, and in order to play anew with a fresh set of randomness, I would back up my current saves along with the current OVERRIDE directory and then reinstall the mod (with preserve=no), and create a new game. I had been wondering if instead I could just reinstall with preserve=yes and expect new randomization, but from your explanation it would seem that the result is not what I am looking for.

In that case, can you verify then if my method of save preservation is sufficient to be able to revert back to a prior save with different randomization (backing up saves and OVERRIDE directory)? I concluded this looking at the time stamps once the mod had run, but I did later notice the mod sticks some stuff in its own backup directory. Not sure if this would break anything the way I was doing it.

 

Couple more questions then:

Is it possible to add new tiers? Are tiers between BG1 and BG2 used/reserved (I think I saw a reference that 1-15 or so were used by BG2, and BG1 begins at 24)?

 

If so, how difficult would it be to add a feature that would allow the assignment of a "variable" in the location lists which would reference and target (for this specific item) a whole new tier/set of locations? I know it probably wouldn't be trivial but, would it even be possible? I am talking about mode 2 exclusively here.

 

I am also a programmer (albeit with no prior experience in IE modding), so technical information doesn't scare me away ... I have had a look at your tpa's in the LIB directory, but I don't really understand the language grammar - what language is that? I'm guessing those are for mode 1 randomization though?

 

Thanks again for the answers, and the fixes!

 

 

[Wisp]

Could you make the random seed number to on display in the install debug file ? Cause 0ne could technically use the same randomization, if you just set the seed to that value in the .tp2 code... next time elsewhere. Yes, this is how evil we are now. Heh-eheheheheh.

I could. But if you want to reuse the seed, there is exactly one supported method, and it's not what you are describing.

[Wisp]

In that case, can you verify then if my method of save preservation is sufficient to be able to revert back to a prior save with different randomization (backing up saves and OVERRIDE directory)? I concluded this looking at the time stamps once the mod had run, but I did later notice the mod sticks some stuff in its own backup directory. Not sure if this would break anything the way I was doing it.

Assuming you restore your override to the state it was in before you first installed Randomiser, it should work.

 

Is it possible to add new tiers? Are tiers between BG1 and BG2 used/reserved (I think I saw a reference that 1-15 or so were used by BG2, and BG1 begins at 24)?

Sure. So long as there are locations and items sharing the same tier identifier, it's a tier and the mod will include it. Tier identifiers can be alphanumerical and should not be limited to any particular sequence length (mode 2 only), so you could simply namespace your own tiers and avoid any conflicts.

 

If so, how difficult would it be to add a feature that would allow the assignment of a "variable" in the location lists which would reference and target (for this specific item) a whole new tier/set of locations? I know it probably wouldn't be trivial but, would it even be possible? I am talking about mode 2 exclusively here.

I have a hard time saying. It's been a long time since I worked on the core code. It sounds doable. There are already locations with hardcoded, custom behaviour (all the .fl ones). This should be rather similar. Implementing it might be as simple as reassinging the tier value, but you would probably also have to make sure the new tier has enough locations, and possibly do other things as well (and it's roughly here my recollection fails me).

 

I am also a programmer (albeit with no prior experience in IE modding), so technical information doesn't scare me away ... I have had a look at your tpa's in the LIB directory, but I don't really understand the language grammar - what language is that? I'm guessing those are for mode 1 randomization though?

The language is called TP2 and it's something that was written as a scripting language for WeiDU. It's pretty much imperative, with usual imperative semantics. There is the occasional inspiration from OCaml.

The lib directory concerns both modes. Which file belongs to what mode is probably easiest to follow from the TP2 file itself.

If you intend to work on Randomiser, I should warn you that the mod is long overdue for major refactoring. It was also my first larger project and it has grown far beyond the original design.

 

To complete my answer from yesterday. ARE, CRE, STO and .flg targets are fully reusable. ARE targets are recognised by their lack of file type, instead the target is the name of the area container (without spaces). BCS, DLG and targets that end in .fl are never reusable.

[Gibson]

What version of Near Infinity is recommended? I downloaded the old old official release because all the newer stuff said they may be unstable, but I'm wondering if I'm missing recent features? Plus I see there are about a dozen forks from the original. Which do you use?

Also, is there any decent way of determining area names? This would be a big help.

 

How does the engine handle modifications to the lists files if the randomizer is already installed? Does this require an uninstall->reinstall to avoid corruption? Perhaps this is the main reason for the "preserve" option? But even in that case, I'm uncertain about what happens if randomized items are added/removed from inclusion.

 

Also, how are stacks of items handled? I see in the comments in the lists for scrolls files some show x2 and x3. It must randomize each item in the stack separately? Does it randomly leave some?

 

When randomizing a weapon to a creature, how do you handle the case that the creature's original specializations don't match the new weapon (seeing as how I'm sure the creature will equip the better weapon)? Or have you designed the lists only to allow creatures to receive the same type weapons?

 

Haha, I keep editing this and adding new questions...

 

I'm seeing most references in the items lists that originate from an AREA referenced by an identifier - but not all. After thinking it through, aren't identifiers required for all area references, since there is no other way to refer to a particular container? If it is not given, how does the Randomiser know where the item is? Some further explanation on this would be helpful.

 

Is it a problem if there are more items than locations per tier (I already asked you about the inverse case), or will it just stick multiple items in some locations?

 

I'm not sure I'm going to tinker with the mod coding, but if so I have a lot of research to do before I even begin to feel qualified! The flexibility you designed into it allows much to be done in its current form; to tell the truth I honestly expected that the tiers were at least semi-hard coded and would require some kind of coding change. Kudos on that design, I shall have to experiment with that! =)

 

Again, thanks for the info.

[Gibson]

So I'm editing my lists files, and I run into an inconsistency. Perhaps you can help?

 

I'm wanting to add the carnival store that originally sells the magic amulets back into the location lists. I see the amulets were all given tiers and randomized accordingly, but no references were added back to that location. The store reference used in those cases is STO4906.STO - Which I assumed was also a reference to the area. But when I look at the areas in Near Infinity, AR4906 is a different tent. The merchant tents are 4907-4909. I'm asking, because in order to add the reference the location list file requires an area. So, what is correct? I will likely do some trial-and-error, I may figure it out on my own.

 

On a related note, I'm having trouble understanding how the .STO files are linked to the actual creatures .CRE files. I see no references that show creature X is really store Y. Can you clear this up?

 

Thanks!

 

[argent77]

You can safely use the latest releases of Near Infinity. The message "This version is possibly unstable and may contain incomplete features" is merely an indication that they are work in progress releases. The ancient versions of NI are probably even more buggy, contain much less features and don't support the Enhanced Edition games.

[Jarno Mikkola]

On a related note, I'm having trouble understanding how the .STO files are linked to the actual creatures .CRE files. I see no references that show creature X is really store Y. Can you clear this up?

I can try. This is because the stores are accessed through the creatures dialog file via StartStore - action. Example: StartStore("govwau01",LastTalkedToBy) // Waukeen's Temple, so for example the sto4906.sto might have been one of the others, you have to look up the .cre file to find the dialog file and then with that, figure out who starts what store.

[Gibson]

Okay, last message for the day ... I think.

 

I just tried running Randomiser with a custom tier as you described; it doesn't seem to be identifying it. I looked at the debug log and it shows all the usual tiers running, but not my added one. Is there any naming limitation? I used a 3 digit alphanum id, figured that would be fine. Or maybe parsing limitation?

 

Also, anothing weird thing - after starting the game with this last random run, all the healing potions have become unidentified for some strange reason. It could be related to the fact that in my custom tier I did reference a couple of healing potion items.

 

Hope I'm not too much trouble!

 

[Gibson]

I just tried running Randomiser with a custom tier as you described; it doesn't seem to be identifying it.

Figured it out ... I had added my custom tier to the mode2 specific lists files, apparently you can't do that. Moved it to mode1 and now it's recognizing it.

[Wisp]

What version of Near Infinity is recommended? I downloaded the old old official release because all the newer stuff said they may be unstable, but I'm wondering if I'm missing recent features? Plus I see there are about a dozen forks from the original. Which do you use?

I'd recommend Argent77's builds. A lot of good work has been done and they're actively supported.

 

Also, is there any decent way of determining area names? This would be a big help.

Check out the IESDP. There are area-name tables among the appendices.

 

How does the engine handle modifications to the lists files if the randomizer is already installed? Does this require an uninstall->reinstall to avoid corruption? Perhaps this is the main reason for the "preserve" option? But even in that case, I'm uncertain about what happens if randomized items are added/removed from inclusion.

No changes you make to the TP2 or the contents of the mod folder will affect the game unless you reinstall the mod. Those files are simply not involved in the game. Adding and removing items is fine, but is incompatible with "preserve".

 

Also, how are stacks of items handled? I see in the comments in the lists for scrolls files some show x2 and x3. It must randomize each item in the stack separately? Does it randomly leave some?

The intention is to randomise stacks as N separate items. Currently this works for store stacks, but a bug prevents it from working with area and creature stacks (a single item is randomised instead).

 

When randomizing a weapon to a creature, how do you handle the case that the creature's original specializations don't match the new weapon (seeing as how I'm sure the creature will equip the better weapon)? Or have you designed the lists only to allow creatures to receive the same type weapons?

Off-hand, I can't remember exactly. Item Randomiser's code for equipping or not equipping items is a bit complex. Weapons with which the creature is proficient are favoured, more strongly the more proficient the creature is (e.g., the other weapon has to be pretty godly before a Grandmaster sword-wielder considers using a weapon other than a sword). I think the non-proficiency weapon is not equipped unless the weapon's rank exceeds the penalties and then some.

 

I'm seeing most references in the items lists that originate from an AREA referenced by an identifier - but not all. After thinking it through, aren't identifiers required for all area references, since there is no other way to refer to a particular container? If it is not given, how does the Randomiser know where the item is? Some further explanation on this would be helpful.

I'm not sure what you are referring to. If this does not answer you question, an example would be helpful.

 

Items with "blank" as source are randomised unconditionally. Items with ARE, CRE and STO sources are only randomised if the mod can confirm that the item was removed from the named ARE, CRE or STO file. I am not sure I remember how DLG sources behave, but I think the mod confirms the presence of the item in the source file before the item is cleared for randomisation. Items with an .fl source has some hardcode involved, and it's possible they each behave differently (but they, too, are not randomised unless they can be confirmed as removed/present).

 

Non-x values in the Ident column associate items with locations. If the item with a given ident is not being randomised, the corresponding location will not be used either.

 

Is it a problem if there are more items than locations per tier (I already asked you about the inverse case), or will it just stick multiple items in some locations?

The mod automatically randomly upsamples the location list for that tier from the available selection of reusable locations. So no, it's not a problem, but you'll get greater item density.

 

I'm wanting to add the carnival store that originally sells the magic amulets back into the location lists. I see the amulets were all given tiers and randomized accordingly, but no references were added back to that location. The store reference used in those cases is STO4906.STO - Which I assumed was also a reference to the area. But when I look at the areas in Near Infinity, AR4906 is a different tent. The merchant tents are 4907-4909. I'm asking, because in order to add the reference the location list file requires an area. So, what is correct? I will likely do some trial-and-error, I may figure it out on my own.

Bioware moved stuff around and such. STO4906.STO was probably accessed from AR4906 earlier in development. Technically, you don't need the area for what you want to do. Simply add the STO file to the location list. The area field is more or less just an aid for humans for locations other than area containers (in mode 2; it's used for real in mode 1).

 

On a related note, I'm having trouble understanding how the .STO files are linked to the actual creatures .CRE files. I see no references that show creature X is really store Y. Can you clear this up?

Yeah, stores are accessed through a DLG. NI has a very useful feature under Find...->references to this file (on the file's Edit tab). To find out where a STO is used, you'd search for references to the STO among DLG files. Then you search for references to the DLG among CRE files, and then (maybe), references to the CRE among ARE and BCS files (creatures can either be used by the ARE directly, or created through script actions; you could also search among DLG files, since they, too, may contain script actions).

 

Also, anothing weird thing - after starting the game with this last random run, all the healing potions have become unidentified for some strange reason. It could be related to the fact that in my custom tier I did reference a couple of healing potion items.

I think that may be because the mod sets a lore value for randomised items missing one, and the code was never fitted for randomisation of potions. Scrolls probably have some exception in the code that should apply to potions as well.

 

Figured it out ... I had added my custom tier to the mode2 specific lists files, apparently you can't do that. Moved it to mode1 and now it's recognizing it.

Weird. Both kinds of lists should be treated by the same code. I guess I can have a look.

[Gibson]

Wow, trying to work with multiple layers of quotes is a nightmare! I give up.

Thanks for the additional info; here are a couple of followup clarifications:

 

How does the engine handle modifications to the lists files if the randomizer is already installed? Does this require an uninstall->reinstall to avoid corruption? Perhaps this is the main reason for the "preserve" option? But even in that case, I'm uncertain about what happens if randomized items are added/removed from inclusion.

No changes you make to the TP2 or the contents of the mod folder will affect the game unless you reinstall the mod. Those files are simply not involved in the game. Adding and removing items is fine, but is incompatible with "preserve".

 

I'm talking about a scenario like:

(1) install mod, play, save, etc

(2) modify the Randomiser list files, in the process removing some items and adding some others

(3) uninstall or reinstall the mod

 

Will the removed items be restored correctly? Will it attempt to "restore" the items that were just added? Or is the restoration process independent from the lists files?

Note, I'm not even talking about save game compatibility here, merely whether the original gamefiles will be restored properly.

 

 

I'm seeing most references in the items lists that originate from an AREA referenced by an identifier - but not all. After thinking it through, aren't identifiers required for all area references, since there is no other way to refer to a particular container? If it is not given, how does the Randomiser know where the item is? Some further explanation on this would be helpful.

I'm not sure what you are referring to. If this does not answer you question, an example would be helpful.

Items with "blank" as source are randomised unconditionally. Items with ARE, CRE and STO sources are only randomised if the mod can confirm that the item was removed from the named ARE, CRE or STO file. I am not sure I remember how DLG sources behave, but I think the mod confirms the presence of the item in the source file before the item is cleared for randomisation. Items with an .fl source has some hardcode involved, and it's possible they each behave differently (but they, too, are not randomised unless they can be confirmed as removed/present).

Non-x values in the Ident column associate items with locations. If the item with a given ident is not being randomised, the corresponding location will not be used either.

 

Okay, here's a fragment from the bg1item.2da file:

wand07   blank       ar3321.are   25   16    b9
sw1h02   blank       ar3301.are   25   17    x

The first item has an identifier, the second does not. Near Infinity shows me that both these locations have several containers. Why does the 2nd line work without having to specify the container of the item? Does the mod not require the container to be specified? Would this work if there were a second "sw1h02" item in the same location, perhaps in a different container? In that case, would it be required to specify the container?

 

 

I think that may be because the mod sets a lore value for randomised items missing one, and the code was never fitted for randomisation of potions. Scrolls probably have some exception in the code that should apply to potions as well.

 

Is this easily patched?

 

[Wisp]

I'm talking about a scenario like:

(1) install mod, play, save, etc

(2) modify the Randomiser list files, in the process removing some items and adding some others

(3) uninstall or reinstall the mod

 

Will the removed items be restored correctly? Will it attempt to "restore" the items that were just added? Or is the restoration process independent from the lists files?

Note, I'm not even talking about save game compatibility here, merely whether the original gamefiles will be restored properly.

Everything would be uninstalled correctly for either choice in 3. WeiDU handles that regardless of mod content. Everything and only that which was altered in installation will be uninstalled at uninstallation.

 

Okay, here's a fragment from the bg1item.2da file:

wand07   blank       ar3321.are   25   16    b9
sw1h02   blank       ar3301.are   25   17    x

The first item has an identifier, the second does not. Near Infinity shows me that both these locations have several containers. Why does the 2nd line work without having to specify the container of the item? Does the mod not require the container to be specified? Would this work if there were a second "sw1h02" item in the same location, perhaps in a different container? In that case, would it be required to specify the container?

 

Item lists only have to specify the source file. For areas, all containers are searched. If there are multiple instances of the same file, only the first encountered instance would be removed. If you wanted to only randomise one specific item from an area where there were several instances, the list format does not support that. You could do it with a hardcoded source entry. The Ident-value has nothing to do with this (it simply associates a line in an item list with a line in a location list).

 

 

I think that may be because the mod sets a lore value for randomised items missing one, and the code was never fitted for randomisation of potions. Scrolls probably have some exception in the code that should apply to potions as well.

Is this easily patched?

 

This should do it:

--- a/randomiser/lib/fixes.tpa
+++ b/randomiser/lib/fixes.tpa
@@ -218,7 +218,7 @@ ACTION_IF !MOD_IS_INSTALLED bg2_tweaks.tp2 3020 BEGIN //only do this if "identif
         READ_SHORT 0x42 lore  ELSE "-1"
         READ_BYTE  0x18 flags ELSE 0
         READ_SHORT 0x1c cat   ELSE 0
-        PATCH_IF lore = 0 AND (flags BAND 0b01000000) = 0b01000000 AND cat != 11 BEGIN
+        PATCH_IF lore = 0 AND (flags BAND 0b01000000) = 0b01000000 AND cat != 11 AND cat != 9 BEGIN
           WRITE_SHORT 0x42 price/250 < 90 AND (flags BAND 16) = 16 ? 90 : price/250 < 30 ? 30 : price/250
         END
       BUT_ONLY

[Gibson]

Thank you for those clarifications. I will try that patch out.