461 replies to this topic

[The Imp]

The complete area file naming sceme can be found here. So the BGT is the only exception, to the rule, where BG1EE uses the BG1 area names, while Tutu uses the BG1 namings, except prefixes of the FW's instead of AR's, and EET uses them too, but now with BG, instead of the AR ...

[Henanigan]

The issue that Jastey pointed out has been addressed and is no longer present.

Edited by Henanigan, 14 June 2021 - 03:51 AM.

[The Imp]

... it and deleted the tpa files that apparently were offensive to imps.

No, it was not. If you go and recheck the original posts, it was NOT me who opposed the files content, but someone else:

... this is bound to lead to errors/problems/ wrong versions being packed in the future...

... just so you know.

I can see it now, you have read my intentions wrong. But that's on you.

[Henanigan]

Yeah, the mod does not intergrate the common EET/BGT lib that does this in other mods, in far more elegant way...

The imp wrote this in reply to Jastey. Her concern was that I renamed mod-internal files for the EET install but didn't restore the BGT file names back.
I skipped this step at first because I didn't think it necessary. I've implemented it now in any case.
As far as I can see, though, the reference to "the common EET/BGT lib that does this in other mods, in far more elegant way" has no relevance to Jastey's concern since I could have skipped the restoration step using whatever lib.

Jastey mentioned copying files to override. I had another look at how the BGEESpawn mod does this, since it uses a very similar setup (vtx and nfp files):

ACTION_BASH_FOR ~bgeespawn/info~ ~.*.nfp~ BEGIN
COPY ~%BASH_FOR_FILESPEC%~ ~%BASH_FOR_DIRECTORY%~
  SPRINT source "%SOURCE_RES%"
  PATCH_IF (GAME_IS ~eet~) BEGIN
    INNER_PATCH_SAVE area_name "%SOURCE_RES%" BEGIN
      REPLACE_TEXTUALLY "^AR" "BG"
    END
  END ELSE BEGIN
    SPRINT area_name "%SOURCE_RES%"
  END

It does not copy files to override either. Of course, since BGEESpawn is for BGEE and EET only, a simple prefix substitution is sufficient here. For BGT, I suggested using an associative array instead. Regardless, though, it seemed to me that *copying* (rather than renaming) the mod-internal files would not make much sense in this case. Wouldn't we end up with redundant files that introduce a possible source of error?

For patching the ARE files, the mod uses code ”copied directly from BGT-Tweaks code (ascension64)” (quoted from tp2 file). Since it's not necessary to fiddle with this code in order to make the mod work with EET (which is what I set out to do), I didn't. (To be clear, copying/deleting files rather than renaming them implies updating this part of the code as well.)

All in all, renaming the files (and then renaming them back) seemed safer to me, and again if there are drawbacks I'm all ears.

resources can be renamed while being copied to the override etc. Please work with temporary folders that can/will be deleted after installation

If in this particular case copying (to override?) and then deleting files genuinely is a better way than renaming them, I'd like to learn why, as I can't see it.

The imp butted in again, pointing to the complete set of area codes this time:

The complete area file naming sceme can be found here. So the BGT is the only exception, to the rule, where BG1EE uses the BG1 area names, while Tutu uses the BG1 namings, except prefixes of the FW's instead of AR's, and EET uses them too, but now with BG, instead of the AR ...

Well, duh. This is an extract from a standard cpmvars EET/BGT lib used by several mods:

OUTER_SPRINT "Undercity" "AR7223"
OUTER_SPRINT "WSewers" "AR7324"
OUTER_SPRINT "CentralSewers" "AR7325"
OUTER_SPRINT "ESewers" "AR7326"
OUTER_SPRINT "FishingVillage" "AR8300"
OUTER_SPRINT "CloakwoodDruids" "AR8400"

And this is an extract from my tp2 file:

OUTER_SPRINT "Undercity" "AR7223"
OUTER_SPRINT "WSewers" "AR7324"
OUTER_SPRINT "CentralSewers" "AR7325"
OUTER_SPRINT "ESewers" "AR7326"
OUTER_SPRINT "FishingVillage" "AR8300"
OUTER_SPRINT "CloakwoodDruids" "AR8400"

Yes... it's the same information. The difference is that the lib covers more areas, as well as dreams, chapters, banterfiles... stuff that's not relevant to this mod. I took the parts needed for updating the mod to work with EET. The imp knew this, of course; he had looked at the code. Why then post as if the naming scheme was news to anyone? The imp had this explanation to offer:

Did you learn something from it, and perhaps gave you some motivation ? Good. See, evil spells live, in reverse.

<facepalm> To respond anyway: No, 'evil spells' do not boost people's motivation. 'Evil spells' are more likely to misdirect and obstruct, and to foul the atmosphere in general.
I guess the imp was successful though.
Edit: Link outdated

Edited by Henanigan, 05 July 2021 - 11:35 AM.

[jastey]

Sorry if my suggestions caused confusion. The main thing important to me would be that the mod package is ready to be installed again after it was deinstalled, and not changed in a non-reproducible way. How this is achieved or where to files are copied is not really important.

[Henanigan]

Sorry if my suggestions caused confusion. The main thing important to me would be that the mod package is ready to be installed again after it was deinstalled, and not changed in a non-reproducible way. How this is achieved or where to files are copied is not really important.

Thanks for your reply! Deinstalling and then reinstalling the mod should work fine now.

[The Imp]

in this particular case copying (to override?) and then deleting files genuinely is a better way than renaming them, I'd like to learn why, as I can't see it.

Well, duh. This is an extract from a standard cpmvars EET/BGT lib used by several mods:

That code(the library data) in question is only loaded via GAME_IS ~EET~ condition, and if that is false, another GAME_IS condition is/can_be tried and there it might succeed, and this is where the elegance comes from. As the same mod can be made compatible with BGTutu, BGT(-weidu), BG1EE, BG2EE, EET etc. iterations, all in one smooth go.

You do know that those lib's exist as well in other weidu mods ?

[Henanigan]

in this particular case copying (to override?) and then deleting files genuinely is a better way than renaming them, I'd like to learn why, as I can't see it.

Well, duh. This is an extract from a standard cpmvars EET/BGT lib used by several mods:

That code(the library data) in question is only loaded via GAME_IS ~EET~ condition, and if that is false, another GAME_IS condition is/can_be tried and there it might succeed, and this is where the elegance comes from. As the same mod can be made compatible with BGTutu, BGT(-weidu), BG1EE, BG2EE, EET etc. iterations, all in one smooth go.

You do know that those lib's exist as well in other weidu mods ?

That's why my tp2 uses the GAME_IS condition. You wrote that you had looked at the code, so you must be aware of this. Thanks for calling my code elegant.

Putting you on ignore from now on.

[The Imp]

But your code does nothing to the other game_is'es.

As for example, you can use one library to create a wolf in a EET game of a map, another library to create the same wolf in the other game, and further one ... and so you don't haver to code the same freaking thing to EET, BG1EE, BGTutu and BGT-weidu, for example. This mod being the topic title: "BGSpawn".

Edited by The Imp, 01 July 2021 - 10:17 AM.

[Henanigan]

But your code does nothing to the other game_is'es.

The original mod supports BGT only. My version adds EET support. Standalone games not supported. Clearly stated upthread.
My code has (working) GAME_IS checks for BGT and EET, and that's all it needs for obvious reasons.

So, I've been trolled into replying to you again, but I really want to believe that you're trying to be helpful or constructive in some weird way.

Edit: Also, the scripts using cpmvars wouldn't work on BGT anymore without the GAME_IS ~bgt~ checks, so it's simply not true that the 'code does nothing.' While I was typing the above, the imp added:

As for example, you can use one library to create a wolf in a EET game of a map, another library to create the same wolf in the other game, and further one ... and so you don't haver to code the same freaking thing to EET, BG1EE, BGTutu and BGT-weidu, for example. This mod being the topic title: "BGSpawn".

The BGEESpawn is "far far far away from the original BGSpawn" like someone wrote upthread. Are you saying that in your opinion, a mod called 'BGSpawn' should support the classic games only? Why, when it could just as easily support both BGT and EET? I'm not removing BGT support.

Edited by Henanigan, 01 July 2021 - 01:11 PM.

[The Imp]

No, what I am suggesting is that the mod could feature code that generally extreamly good for the moding community, such as the suggested cpmvars.tpa, that is generally associated with the multiple games, which is supplied by the original author of that mod(in this case, the file can be found in EET/other/cpmvars/eet_cpmvars.tpa ).

There's such a file for the BGT-weidu, BG1EE, and BGTutu too(and you can find them in EET noless).

[Henanigan]

No, what I am suggesting is that the mod could feature code that generally extreamly good for the moding community, such as the suggested cpmvars.tpa

You know, from memory, and just as an example, this mod uses WOLF01, a CRE that does not exist in BGEE. So, in order to make the mod standalone BG(EE) compatible, I'd either need to port WOLF01 over, or use some fancy lib that takes care of the WOLF.CRE <-> WOLF01.CRE switch. For a moment I thought you were arguing that such a lib exists. But since all you're talking about is the cpmvars lib that I have mentioned myself several times:

 

I've already responded to this, but to repeat myself: This mod doesn't need all the contents of that file (chapters,etc). It doesn't even need the complete list of areas. I put in the relevant areas only. Obviously, this could be changed to include a reference to the tpa you mentioned, but it would not add anything to the code except by carrying useless garbage around. I don't see the point.

 

It's not like I'm reinventing the wheel here, either: I'm using exactly that information you're referring to, just stripped down to what this mod needs. This reminds me of someone at another forum arguing that the complete list of IWD2 areas might be a poor answer if somebody's asking for only those areas that are specifically town areas. Maybe you read that argument?
 

[Henanigan]

Addendum:

I don't see the point.

Not that I'd mind it if someone else changed it that way. Just explaining why I didn't.

There are other things that may need changing as well, such as adding PI support (as a Linux user, I wouldn't be able to test that).

Not that anyone needs my permission for this

[ALIEN]

@Henanigan I can add PI support. Where I can download your latest updated version?

[Henanigan]

@Henanigan I can add PI support. Where I can download your latest updated version?

The link in post #445 should be the latest version. Thanks!

[ALIEN]

There is a new release of BGSpawn, it seems that it was more than only PI support   I'm posting full changelog with updates since 1.12 version:

 

1.3.3: Graion Dilach

- Fix: Dying spawned Amnian soldiers preventing mine entrance.

 

1.3.2: Graion Dilach

- Fix: Substitute the remaining few BGT area names on EET.

- Fix: Don't use BGT creature names where EET and BGT names differ.

- Fix: Random Encounter component no longer breaks Dorn's fixed encounter.

1.3.1: Graion Dilach

- Fix: Move area list definition to the ALWAYS block to ensure substitution when a spawnprobability component is installed.

1.3.0: AL|EN:

- replaced ACTION_READLN with SUBCOMPONENT to not halt installation

- added DESIGNATED numbers

- added globally unique LABEL's

1.2.1: AL|EN

- cosmetic changes to file and folder names

- updated links

- updated readme

- updated changelog

- fixed chinese language encoding

- restored correct chinese translation descriptions in tp2 file

- use %MOD_FOLDER% everywhere except for currently bugged LANGUAGE

- added code to handle non-fixpacked BG2 installation

- added PI metadata

1.2.0: Henanigan

- BiG World Fixpack v19 patch incorporated

- EET support added (cpmvars; file renaming as necessary at install time, restored afterwards)

- Language setup updated for EE ('setup' / 'game' tra files; iconv added for UTF8

- Adjustable spawnpoint probability added (with a nod to the bgeespawn project)

- AUTHOR replaced by SUPPORT in tp2 file

 

https://github.com/S...releases/latest

https://lynxlynx.inf...BGSpawn&pkg=zip

https://lynxlynx.inf...Spawn&pkg=iemod

 

@Gwendolyne or @Jastey can you update SHS Download section with the links when you will have a moment of free time?

 

Edited by ALIEN, 04 February 2023 - 07:38 AM.

[Henanigan]

Thanks Alien!

Edited by Henanigan, 18 July 2021 - 03:49 AM.

[melkor_morgoth75]

Hi all,
 
I dont know where to post so I try here
 
I've been out for years, back as I was curious about the modding community and how BG (BGEE, etc) is going.
 
I noticed my mod has been recoded and adapted for EET which is great, I wish I gave my permission anyway to do that.
 
Regardless, I give the permission now ... I'm happy this is still alive and enjoyed by the community.
 
Cheers to everyone!
mm75
 
PS: may I kindly have access to the "hidden" forum of BGSpawn mod?

Edited by skellytz, 24 March 2023 - 09:18 PM.
double posting

[ALIEN]

Welcome back melkor_morgoth75   Nice to hear that you are happy about the updates for you mod, much appreciate! 

 

For accessing hidden forum , you need to contact @Gwendolyne or @Jastey.

[melkor_morgoth75]

Welcome back melkor_morgoth75   Nice to hear that you are happy about the updates for you mod, much appreciate! 

 

For accessing hidden forum , you need to contact @Gwendolyne or @Jastey.

 

Thanks a lot Alien

 

mm75