ADD_AREA_TYPE !

[Guest]

Hello !

I was wondering about the number of mods using this function !

Actually there is

- EET add BG1AREA

- IWD_EET add IWDAREA

- Paladins of Faerun will use POFAREA

- NWNForBG will use NWNAREA

So since there is a limit to the number of AREA_TYPE than can be used...

The question is...

Is it okay to have these implemented this way for different mods ?

Maybe we can use the same for multiple mods like MODAREA  or else for PoF and NWNForBG...

It's better to have one for each so other things could be implemented but I wouldn't not monopolize ressouces if others need them.

Anyway it's something that could be changed easly if needed in the futur !

[argent77]

53 minutes ago, JohnBob said:

I was wondering about the number of mods using this function !

Test Your Mettle! uses RUBIKON (or A7_RUBIKON in future releases whenever I can find the time to wrap up the update). Removing it would complicate a lot of scripting quite a bit and requires the introduction of helper creatures to emulate certain spell effects with splprot filters. It would get ugly very quickly.

[Graion Dilach]

I'm not too worried on this one, it's still heavily underutilized. I'm also sure that a lot of the EET-compatible mods actually don't conform to using BG1AREA for their BG1 areas, but until I see actual code being broken on this, I don't want to go through the scene for this.

[Acifer]

Important topic, I wanted to create a thread on this in the near future, too.

It appears that eight additional area types can be added to AREATYPE.IDS via ADD_AREA_TYPE.

The fact that mods insert mod-only area-types seems not the best idea. To be honest, I would refrain from adding specific mod-area-types and keep the AREATYPE.IDS useful for the community.

My problem: I will be releasing mods with a lot of areas (+200) in the near future, and in order to keep the existing scripts of the original game running bug-free, I will probably have to integrate new area types for certain locations. Otherwise I would have to patch numerous NPC scripts and maybe the Baldur.bcs with countless (+100) !AreaCheck(xyz) in countless blocks.

My idea:
Add generic, so far missing area types that might be useful additions for all modders, not just one mod.

My suggestions:
1. areatype WILDERNESS (or WASTELAND): an area outdoor type, like areatype FOREST, but for areas so far away that no NPCs are spawned for quests (e.g. for Jaheira's quest).
2. an areatype EXTRAPLANAR for outside locations in the Multiverse
3. And, if I may have a wish: areatype UNDERDARK (underground, but no dungeon)

If there is another good way to patch the numerous scripts, I would of course be happy to use this alternative.

Edited November 2, 2023 by Acifer

[Graion Dilach]

I can only speak for EET, but I think BG1AREA was added as an alternative way to prevent leaking BG2 content into the BG1 maps. If you think that marker doesn't have a valid usecase here, I can look into filing PRs to phase it out, but I don't want to make such changes on my own iniative without a discussion first.

[Guest]

1 hour ago, argent77 said:

Test Your Mettle! uses RUBIKON (or A7_RUBIKON in future releases whenever I can find the time to wrap up the update). Removing it would complicate a lot of scripting quite a bit and requires the introduction of helper creatures to emulate certain spell effects with splprot filters. It would get ugly very quickly.

Alright, so there is already only three slot remaining...

1 hour ago, Acifer said:

Important topic, I wanted to create a thread on this in the near future, too.

It appears that eight additional area types can be added to AREATYPE.IDS via ADD_AREA_TYPE.

The fact that mods insert mod-only area-types seems not the best idea. To be honest, I would refrain from adding specific mod-area-types and keep the AREATYPE.IDS useful for the community.

My problem: I will be releasing mods with a lot of areas (+200) in the near future, and in order to keep the existing scripts of the original game running bug-free, I will probably have to integrate new area types for certain locations. Otherwise I would have to patch numerous NPC scripts and maybe the Baldur.bcs with countless (+100) !AreaCheck(xyz) in countless blocks.

My idea:
Add generic, so far missing area types that might be useful additions for all modders, not just one mod.

My suggestions:
1. areatype WILDERNESS (or WASTELAND): an area outdoor type, like areatype FOREST, but for areas so far away that no NPCs are spawned for quests (e.g. for Jaheira's quest).
2. an areatype EXTRAPLANAR for outside locations in the Multiverse
3. And, if I may have a wish: areatype UNDERDARK (underground, but no dungeon)

If there is another good way to patch the numerous scripts, I would of course be happy to use this alternative.

Yes, that's what I was afraid of !

About the raison for NWNforBG and PoF it's mainly for using it alongside with Argent77 function that prevent losing stronghold and missing events, so I think one AREATYPE could be created for such case since many mods can / should use it !

Maybe FARAWAY could be clair enough and used specificaly for this ?

1 hour ago, Graion Dilach said:

I can only speak for EET, but I think BG1AREA was added as an alternative way to prevent leaking BG2 content into the BG1 maps. If you think that marker doesn't have a valid usecase here, I can look into filing PRs to phase it out, but I don't want to make such changes on my own iniative without a discussion first.

I don't think it's a good idea to remove the BG1AREA flag because it's used to manage different day/night movies between BG1 and BG2.

IWD_EET use IWDAREA for several things too.

Argent77 need A7_RUBIKON for having script trigger so I guess it's mandatory too.

I f we add like I propose FARAWAY...

There are four remaining slots to apply your proposal @Acifer

Do you think it's enough ? Furthermore everybody think it's enough ?

 

---

 

This lead to a personnal question, how can we check if the AreaType we need is already implemented by another mod ?

Edited November 2, 2023 by JohnBob

[argent77]

35 minutes ago, Acifer said:

If there is another good way to patch the numerous scripts, I would of course be happy to use this alternative.

If area types are only used for scripting then using area-scope variables would provide the same effect and could even be used for more fine-grained checks. These variables could be added statically to the areas themselves like this:

COPY_EXISTING "ar9999.are" "override"
  LPF fj_are_structure
    INT_VAR
      fj_variable_value = 1
    STR_VAR
      fj_structure_type = "variable"
      fj_name           = "my_areatype_variable"
  END

and used in scripts or dialogs via Global("my_areatype_variable","MYAREA",1). Alternatively they can be set up in area scripts, which introduces a slight initialization delay though.

Unfortunately I can't think of any viable alternative for spell effect filtering via spellprot.2da, unless you count using helper creatures which is ugly and error-prone.

 

37 minutes ago, Acifer said:

My suggestions:
1. areatype WILDERNESS (or WASTELAND): an area outdoor type, like areatype FOREST, but for areas so far away that no NPCs are spawned for quests (e.g. for Jaheira's quest).
2. an areatype EXTRAPLANAR for outside locations in the Multiverse
3. And, if I may have a wish: areatype UNDERDARK (underground, but no dungeon)

Introducing some general-purpose area types sounds like a good idea to me. The EXTRAPLANAR type in conjunction with area-scope variables would allow my to replace my own area type in Test Your Mettle! without sacrificing functionality. I haven't looked into the other listed mods. But it's likely that they're using area types only for scripted checks as well, which could be replaced with variables just as easily.

I wouldn't add more than three or four entries, however, so that there is still room for a couple of more specific area types (like BG1AREA for EET). That would actually be a good candidate for the EE Fixpack.

[Guest]

It could be nice to have access to one AreaType for scripted checks too !

11 hours ago, argent77 said:

I haven't looked into the other listed mods. But it's likely that they're using area types only for scripted checks as well, which could be replaced with variables just as easily.

If I understand correctly you talk about add a variable like !Global("MyMod_Quest_Is_On","GLOBAL",1) that could be used like you do in TotLM ?

But for PoF it's not possible, I think, since we can do quests when we want (mostly) and we can come back to the main areas whenever we want (mostly) so it would requiere to add new variable to each areas scripts (291), I can imagine how to set the variable on for each, something like :

IF
	InMyArea([GOODCUTOFF])
THEN
	RESPONSE #100
		Global("MyMod_Quest_Is_On","GLOBAL",1)
END

But how can I deactivate the variable when leaving the areas ?

There is surely other ways...

Edited November 3, 2023 by JohnBob

[argent77]

1 minute ago, JohnBob said:

If I understand correctly you talk about add a variable like !Global("MyMod_Quest_Is_On","GLOBAL",1) that could be used like you do in Totlm ?

Yes, but on area-scope. That way each area provides their own variable that can be checked, which is basically the same as checking the area type. The scope placeholder "MYAREA" can be used to avoid typing the specific area as scope ("AR1000", ...).

For example, this check

IF
  AreaType(POFAREA)
THEN
  RESPONSE #100
    // ...
END

could be replaced by

IF
  Global("POFAREA","MYAREA",1)
THEN
  RESPONSE #100
    // ...
END

if the area-local variable "POFAREA" is defined and set to 1 in all relevant areas by the methods outlined in my previous comment. The same is true for dialog conditions.

[Guest]

Ok, I'm sorry but it's frequently really hard for me to understand basic stuff...

So if I do this... Does that sound right to you ?

MKDIR ~weidu_external/PoFQuestPack/Areas~

ACTION_BASH_FOR ~PoFQuestPack/Areas~ ~^.+$~ BEGIN

PRINT ~         ~
PRINT ~Start AREATYPE~
PRINT ~         ~

  COPY ~%BASH_FOR_FILESPEC%~ ~weidu_external/%BASH_FOR_FILESPEC%~
  LPF fj_are_structure
    INT_VAR
      fj_variable_value = 1
    STR_VAR
      fj_structure_type = "variable"
      fj_name           = "POFAREA"
  END
END


ACTION_IF (GAME_IS ~bg2 tob bgt bg2ee eet~ AND FILE_EXISTS_IN_GAME ~BALDUR.BCS~) BEGIN

  // Prevent specific events from triggering during PoF travels (Borrowed from TotLM by Argent77 )
  ACTION_DEFINE_ASSOCIATIVE_ARRAY area_checks BEGIN
    ~baldur~    => ~\(!Global("Chapter","GLOBAL",%bg2_chapter_4%)\)~
    ~aerie~     => ~\(!Global("Chapter","GLOBAL",%bg2_chapter_4%)\)~
    ~anomen~    => ~\(!Global("Chapter","GLOBAL",%bg2_chapter_4%)\)~
    ~cernd~     => ~\(!Global("Chapter","GLOBAL",%bg2_chapter_4%)\)~
    ~edwin~     => ~\(!Global("Chapter","GLOBAL",%bg2_chapter_4%)\)~
    ~jaheira~   => ~\(!Global("Chapter","GLOBAL",%bg2_chapter_4%)\)~
    ~jan~       => ~\(!Global("Chapter","GLOBAL",%bg2_chapter_4%)\)~
    ~keldorn~   => ~\(!Global("Chapter","GLOBAL",%bg2_chapter_4%)\)~
    ~korgan~    => ~\(!Global("Chapter","GLOBAL",%bg2_chapter_4%)\)~
    ~mazzy~     => ~\(!Global("Chapter","GLOBAL",%bg2_chapter_4%)\)~
    ~minsc~     => ~\(!Global("Chapter","GLOBAL",%bg2_chapter_4%)\)~
    ~nalia~     => ~\(!Global("Chapter","GLOBAL",%bg2_chapter_4%)\)~
    ~yoshimo~   => ~\(!Global("Chapter","GLOBAL",%bg2_chapter_4%)\)~
  END

  OUTER_TEXT_SPRINT bcs_quest_check ~!Global("POFAREA","MYAREA",1)~
  ACTION_PHP_EACH area_checks AS script => search BEGIN
    COPY_EXISTING ~%script%.bcs~ ~override~
      DECOMPILE_AND_PATCH BEGIN
        REPLACE_TEXTUALLY ~%search%~ ~%bcs_quest_check% \1~
      END
    BUT_ONLY IF_EXISTS
  END
END

I see the variable added in .are files but if I check for CLUAConsole:GetGlobal("POFAREA","MYAREA")

All I got is Global: POFAREA MYAREA so not sure everything go the way it should...

Edited November 3, 2023 by JohnBob

[argent77]

Yes, that looks good to me. You can use NI to check whether the variable has been added to the ARE files.

33 minutes ago, JohnBob said:

I see the variable added in .are files but if I check for CLUAConsole:GetGlobal("POFAREA","MYAREA")

All I got is Global: POFAREA MYAREA so not sure everything go the way it should...

CLUAConsole works a bit differently. You have to use the current area resref as scope name to return the value.

Edited November 2, 2023 by argent77

[Guest]

14 minutes ago, argent77 said:

You have to use the current area resref as scope name to return the value.

It really does make sense !

So yes it's ok, Global return to 1 in the given area, thanks for your patience and explanations !

 

This make room for some AREA_TYPE more generic. (6 slots)

So far only BG1AREA and IWDAREA remains (If you use EXTRAPLANAR instead of A7_RUBIKON)

 

[Galactygon]

There's absolutely nothing wrong with using a helper creature in this case - it's quite easy. You need the creature to recurringly (say once a second) cast a spell with a large radius projectile that bypasses solid obstacles (bit12 among the projectile explosion flags) to cover an area that sets a SPLSTATE for a very short while and you've got yourself covered. You don't even need scripting to do this. The only drawback is that the repeating opcode 272 doesn't fire during time stops and cutscenes but that's quite manageable without jumping through hoops.

I'd use custom areatypes very sparingly as a few community-wide agreed ones.

[igi]

There was a handy discussion in the Aran Whitehand forum which made some suggestions for area types (rather than "this area was added by mod x") - 

I believe the summary was:

256	SHOP		   Can buy/sell items
512	TEMPLE		 Can purchase healing spells
1024   TAVERN		 Can purchase drinks (rumours)
2048   INN			Can rent a bed
4096   STRONGHOLD	 Player stronghold
8192   EXTRAPLANAR	Outside the prime material plane
16384  -			  Unused
32768  -			  Unused

 

[zelazko]

https://gibberlings3.github.io/iesdp/files/ids/bgee/areatype.htm

What's the limit in areatype.ids? 14? 6 plus more? Default is 8.