Modder Discussion: Additional AreaType() Flagging for Mods

[CamDawg]

Hey - CamDawg in BG1NPC has been doing this, just FYI:

I've obviously been at this too long, as I don't remember this at all. This was probably just lifted from BG2FP/WeiDU bitwise docs at some point.

 

(My fave wtf moment so far since I've returned was finding that I missed free beer in the WeiDU docs.)

[Miloch]

My fave wtf moment so far since I've returned was finding that I missed free beer in the WeiDU docs.

I thought there was actually an offer, then I looked it up... that reference (to Weimer) has been there for ages, hasn't it?

IF ~AreaType(FL_TAVERN)~ THEN RESPOND ~Well, do you want to go get a drink, listen around, dance to the music, or take a walk on the streets? We can't rent a bed here, more's the pity.~

I'm guessing this would also have to check for !INN to be a valid comment. I believe the flags would be combineable, meaning something could be an inn, a tavern, a shop and/or even a temple. So if you want to check for all establishments that serve drinks, just a TAVERN check would suffice. If you want all places where you can rent a bed and get a drink, you'd have to check both INN and TAVERN (I think).

[Miloch]

To revisit this, I don't know if there was ever a solid consensus on area type flags, but I'll throw something out there. I'm all for the simplest solution. Being as there are only perhaps 8 flags available anyway, I say we just APPEND/UNLESS areatype.ids with the actual values, rather than relying on ADD_AREA_TYPE which could result in duplicate area types or at any rate, differing values for the same areatypes depending on mod order etc. Also, agreeing on established values means you can just COPY ~mymod/areas~ ~override~ without further patching, unless you have text or other writes to do (which won't always be necessary).

 

So here's what I would suggest for areatype.ids, based on the requirements in this thread.

Existing area types:
1	  OUTDOOR		Subject to weather?
2	  DAYNIGHT	   Subject to hour-based light levels
4	  WEATHER		Redundant with OUTDOOR?
8	  CITY		   Outdoor urban area (triggers AREA_CITY sounds)
16	 FOREST		 Triggers AREA_FOREST NPC sounds
32	 DUNGEON		Triggers AREA_DUNGEON NPC sounds
64	 EXTENDEDNIGHT  Different day/night maps
128	CANRESTOTHER   Can rest (camp) here

New proposed types:
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

Note that these bit values aren't exclusive - you could have an extraplanar inn/tavern in an outdoor forest if you really wanted to. I added that "extraplanar" flag as it strikes me as it could be useful for a number of scripting mods such as aTweaks (for example, fiends will have different behaviour and can die permanently on their home planes). Also, like Ardanis, I see no reason to use prefixes, as it just makes it more complex and more subject to possible duplicate entries.

 

This suggested implementation leaves 2 unused fields, which I think is fine if someone comes up with a future requirement. The only other one I can think of offhand is "CANT_TELEPORT" or something, meaning that potentially plot-breaking teleportation items or spells should not function in such areas. Aurora uses this already, but we do so via hardcoding the list of areas. A patch of the areatype field in all such areas and use of the CANT_TELEPORT flag in scripts would be more elegant.

 

One thing I'm not clear about is the difference between OUTDOOR and WEATHER flags - surely the former entails the latter, but does it have other purposes? I don't see any separate uses of a WEATHER flag in scripts so I have to wonder why there's another flag for it.

[Wisp]

I think you may be underestimating the complications involved here. But correct me if I'm wrong.

 

To have any meaning the area type needs to encompass a static list of areas. You will want to know where and when the area type you are using is true. Then, given different preferences and requirements and all that, I'd say it's a bit too optimistic to expect a single area type label (with an area list) to satisfy everyone. Assuming this sees use outside a handful of mods I wouldn't be surprised if we do have "duplicate" area types (e.g., two or more types for different types of inns).

 

Then we have strongholds. You have areas that dynamically become strongholds at some point during the game. I.e., the area type needs to be added via a script (prefixes). Then we have the strongholds you can lose without losing access to the area. Since you can't unset area types you need an even more convoluted solution (more prefixes) if you want the check to be false for a stronghold you've lost.

 

For reference, there are functional implementations of inn and stronghold types in aTweaks (atweaks/areatype/). They currently use my prefix and ADD_AREA_TYPE but changing that is trivial enough. I've been dragging my feet on the documentation, hence no publicity (which is just as well, seeing as how the discussion isn't over).

 

If we do ditch prefixes and ADD_AREA_TYPE, who gets to decide which areas are encompassed by each area type? What happens when someone disagrees? This scheme seems to be set up for schisms and broad categories of mod incompatibilities, as any mod that uses this scheme would be automatically incompatible with a mod that used any other scheme (again, assuming more than a handful of us make use of new area types).

 

If we use prefixes and ADD_AREA_TYPE, the worst-case scenario would be that some mod combinations are incompatible. But since ADD_AREA_TYPE is dynamic the only way to run into this incompatibility would be to install mods until the number of unclaimed area type slots was exceeded. You still get to choose which mods you want to combine.

 

P.S. EXTRAPLANAR would not be useful to aTweaks (aTweaks needs finer granularity) but thanks for the consideration.

[Miloch]

If we do ditch prefixes and ADD_AREA_TYPE, who gets to decide which areas are encompassed by each area type?

Ideally, something like the Fixpack for existing areas, whereas modders who add new areas can flag them right off the bat in the area files. And here's an advantage (for modders anyway) you may have overlooked - we can give those "unknown" bits in NI and DLTCEP useful labels (something impossible with ADD_AREA_TYPE).

What happens when someone disagrees?

Well, they can talk about it here or elsewhere (not sure if this is the best forum, but cmorgan was the first to bring it up - or maybe berelinde; hard to tell from that first post). With the exception of what you said about strongholds, those other types should be fairly straightforward yes/no questions, no?

If we use prefixes and ADD_AREA_TYPE, the worst-case scenario would be that some mod combinations are incompatible. But since ADD_AREA_TYPE is dynamic the only way to run into this incompatibility would be to install mods until the number of unclaimed area type slots was exceeded. You still get to choose which mods you want to combine.

That is a fairly bad case if you ask me. I don't see the need for any mod incompatibilities just on account of area types. I should say that I don't offhand plan to need any of this in any of my mods. However, I am hard-flagging my mod areas. I could use ADD_AREA_TYPE instead, but that seems suboptimal for reasons I mentioned. Aurora does use a CANT_TELEPORT but as I said, we currently hardcode the list of areas rather than use area flags. It works, but isn't that flexible for new mod areas.

 

One more thought - hitherto, I think we've only been talking about areaflag.ids and the area field at 0x48. If we need new area types, can we not also add to areatype.ids and use the field at 0x14? Right now that has:

0 NOSAVE
1 TUTORIALAREA

and also presumably

2 DEADMAGICZONE
3 DREAMAREA

Meaning we have 28 unused flags here. Probably not as dynamic as combinable bitfields in areaflag.ids but perhaps more appropriate for something like CANT_TELEPORT?

[Wisp]

Ideally, something like the Fixpack for existing areas, whereas modders who add new areas can flag them right off the bat in the area files. And here's an advantage (for modders anyway) you may have overlooked - we can give those "unknown" bits in NI and DLTCEP useful labels (something impossible with ADD_AREA_TYPE).

This doesn't belong in the Fixpack (and I can hear the objections already). I don't think the NI guys will include it either.

 

Additionally, maybe half of the areas that need to be flagged are from megamods and such, and we both know they'll never be updated on account of this. An includeable resource that makes one or more new area types available would be the way to go.

 

Personally I prefer ADD_AREA_TYPE because that way I don't feel I have to provide all the area types (the complete system). I can simply release the two area types I have and leave it at that. But if you, or someone else, provide the rest I guess I can go along with it.

 

Well, they can talk about it here or elsewhere (not sure if this is the best forum, but cmorgan was the first to bring it up - or maybe berelinde; hard to tell from that first post). With the exception of what you said about strongholds, those other types should be fairly straightforward yes/no questions, no?

[...]

That is a fairly bad case if you ask me. I don't see the need for any mod incompatibilities just on account of area types.

I can promise you it won't be that simple in practice. People are quarrelsome and don't agree. Your proposed system would be vulnerable to disagreements. If someone decided to launch a different scheme, it would pretty much be straight-off incompatible with yours, or any other static system. As such, any two mods that use different systems would be incompatible simply because they used different systems.

 

ADD_AREA_TYPE is less vulnerable to incompatibilities. You could have different-but-same area types, you just couldn't have more than 8 new ones installed at the same time. And unlike a static system that simply assumed that bit N was type X, ADD_AREA_TYPE would fail loudly once it hit an incompatibility (a static system would result in a lot of weird, silent errors on incompatibilities).

 

One more thought - hitherto, I think we've only been talking about areaflag.ids and the area field at 0x48. If we need new area types, can we not also add to areatype.ids and use the field at 0x14? Right now that has:

0 NOSAVE
1 TUTORIALAREA

and also presumably

2 DEADMAGICZONE
3 DREAMAREA

Meaning we have 28 unused flags here. Probably not as dynamic as combinable bitfields in areaflag.ids but perhaps more appropriate for something like CANT_TELEPORT?

It's

0x14 - areaflags.ids

0x48 - areatype.ids

Unlike areatype.ids, I don't think areaflags.ids is accessible from scripts.

[Miloch]

People are quarrelsome and don't agree. Your proposed system would be vulnerable to disagreements.

Nah. We latter-day modders are a benign, relaxed group. The days of ding0 and devSin are long gone . I've heard only crickets chirping since I made a proposal. Even your objections have nothing to do with the actual values proposed, just the way of adding them.

If someone decided to launch a different scheme, it would pretty much be straight-off incompatible with yours, or any other static system. As such, any two mods that use different systems would be incompatible simply because they used different systems.

True, which goes for dynamic systems as well, so why not make it static and less prone to guesswork? Assuming everyone can stick to one such system, and I think they can if they can stick to other standard IDS extensions. They've had since January (in this thread at least) to voice any input, and there are still at least a couple empty slots in case someone comes up with a new requirement.

Personally I prefer ADD_AREA_TYPE because that way I don't feel I have to provide all the area types (the complete system). I can simply release the two area types I have and leave it at that. But if you, or someone else, provide the rest I guess I can go along with it.

Ok then, why not just pick what you want from something like this?

APPEND ~areatype.ids~ ~256 SHOP~ UNLESS ~^256\|SHOP~
APPEND ~areatype.ids~ ~512 TEMPLE~ UNLESS ~^512\|TEMPLE~
APPEND ~areatype.ids~ ~1024 TAVERN~ UNLESS ~^1024\|TAVERN~
APPEND ~areatype.ids~ ~2048 INN~ UNLESS ~^2048\|INN~
APPEND ~areatype.ids~ ~4096 STRONGHOLD~ UNLESS ~^4096\|STRONGHOLD~
APPEND ~areatype.ids~ ~8192 EXTRAPLANAR~ UNLESS ~^8192\|EXTRAPLANAR~
APPEND ~areatype.ids~ ~16384 CANT_TELEPORT~ UNLESS ~^16384\|CANT_TELEPORT~

As for patching existing areas, why not leave that to someone who cares. Sounds like you don't, and I don't, apart from my own areas (and as for those I'm just being polite to those who plan to use this, as they shouldn't have to guess what my areas are).