Miloch

BG1 was very bad with this (though I thought there were existing bugfixes in Baldurdash or something for this). BG2 was a little better. However, IIRC dwarves only get the bonus vs. death/poison, not vs. wands or other stuff (like gnomes and halflings do). Note that wyverns have a save vs. wands of 6 and Hurgan one of 12. So yes, they'll be significantly harder to stun. They also are immune to hold and a bunch of other hold-like effects (having ring97 which is similar to Free Action) but not stun. The cave wand04 has 13 charges (you can see this yourself by using an editor like DLTCEP or Near Infinity on the area ar3601). If you sell it to a store, it should "recharge" it to 100 charges (this at least "works" in BG1 I think). I don't see anything that would cause this, unless you charmed them or something (something tells me you might have - to pick their pockets perhaps). The wand in question casts at level 4, so yes, that's accurate (and probably not a bug in my opinion). It is set in the Power field in the itm's effect - every item is set different. Note that it's more likely to help you than enemies, since few enemies are carrying around fireball wands. I'm not sure what Garan was doing with one, though he does have a fireball scroll (which casts at 3, the normal spell level).

In subtle ways, the engine is different though, and I seem to recall recharging is one of many things that doesn't work in BG1. Might even be a post about it in the workroom by devSin or someone with something more definite.

I'll attach the latest version here until someone at G3 uploads it to the proper place (*crickets chirping*). To run as an .exe, just rename it from .rar to .exe (it won't let me upload an .exe, but it's packaged as one).Edit: Version 1.9 is now uploaded at the official G3 download section.

Nonsense. They want goodies (i.e. quests) not romance (well, judging from my side of the coin anyway).

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. 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. 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).

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). 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 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?

You know you can upload your mod to SHS instead of linking it to an annoying adware server like filefront. Might get more response that way.

Thanks. Hopefully someone is around to upload the update .

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.

Need these new strings in French, Spanish and Polish: Also need this translated for the French readme: <strong>Change Anomen's knighthood reward/penalty</strong> - <em>Optional; BG2 and BGT only</em><br /> <ol> <li>Wisdom +1 on passing (instead of set to 16)</li> <li>Wisdom +1 on passing; Constitution +1 on failing</li> <li>Wisdom +1 on passing; Wis -1 and Con +1 on failing</li> <li>Wisdom +1 on passing; Wisdom -1 on failing</li> </ol> On passing his knighthood test, Anomen would normally get his wisdom set to 16, regardless of what it had been previously (normally 12). This component will augment his wisdom by 1 instead (if, for example, you want to increase his wisdom in the "Mod an <acronym title= "Non-Player Character">NPC</acronym>" component). You also have four choices to change his attributes if he fails the test.<br /> <br /> Edit: added fourth option (wis +1 bonus on passing, -1 malus on failing).

He did say it was essentially done and that Grim Squeaker was doing the voicing, so I'd be surprised if he didn't have a copy. Also: We can actually do this now with ToBEx (or even without it, with a small .exe patch).

I should (and did) edit the original post because the updated FAQ is actually here on the mod's project page. Mod NPCs were added a few releases ago - scroll down to "Q: What about NPCs added by mods?" to see the list. Also, see the original post for what to do to add an NPC.

Cheers. Just need Spanish now, unless the Spanish modding community wants me to translate it into Spanglish (somehow I doubt that).

I need two new strings in French, Polish and Spanish (blame Kulyok ): These are subcomponents to the existing component "Joinable NPCs more closely match the player character's experience" (@400000). (Is it just me or are they not making netbooks with tilde characters on the keyboards? Grrr...)

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).

Well, all the more reason to agree on standardised numerical values (and labels). I look at this and think it's messy already. There're only 8 flags available, so what's the point of having an array of different prefixes?Agreed, but what's the point of having prefixes at all for standard agreed-on IDS entries? Prefixes are for file resources so modders don't overwrite each other. If you're adding an entry to this without bothering to check what others have done first, it doesn't matter whether anyone's using prefixes or not. So why require more typing than necessary (granted, folks can also use numerical values but labels are easier to remember). Heh, something like that (possibly with a strange herb garden). But technically, it's not OUTDOORs but inside a rock (not subject to rain etc.). Maybe we need a WILDERNESS flag if there's really a need for it, being as how CITY apparently can't be used for city subareas (still not quite sure why not but I'll assume such a "fix" wouldn't exist without a need). Also, I wouldn't know what you would use to detect things like inn cellars either, (apparently they wouldn't be flagged as CITY, INN or DUNGEON) though I suppose they don't necessarily need to be detected. Edit: If there's going to be INN and SHOP (places where you can rent a bed and buy items) shouldn't there also be TAVERN and TEMPLE (places you can drink/hear rumours and get curing)? Keeping in mind the limited space, but those latter might actually need to be identified separately, no?

I guess ag2020 and ag4815 should be added to that list of inn areas for Aurora. I interpreted the original request as "any area where you can rent a bed" and forgot we also add inn cellars. So I suppose it depends on what you want to script in an inn whether those should be counted as inn areas. If I remember, I'll flag these areas with whatever value you agree on, though it doesn't hurt to have redundant flagging code in mods. But to that end, I think the area IDS numeric values should be fixed rather than dynamically determined. It's not like you're going to run out of values, even if people want to throw in some bizarre flags. Also if it matters, ag1111 and ag2020 are BG2 areas; ag3801 and ag4815 are in Tutu and BGT. Edit: also I should perhaps clarify the other areas' status as "inn"... ag3801 is a mad hermit's distillery where you can rent cots (possibly necessary after sampling his wares) and ag1111 is a druidess's retreat carved out of a rock where you can do the same. So again, depends on what you want to script there.

I don't know how "X#TT1Deactivate" gets set to 1 in the first place, if the problem is with the spawn deactivating immediately - you might have to post more code to analyse that.

I think I already mentioned the sunken house will be in the next version of Aurora (which already uses the Drakon Tavern and Belching Dragon cellar). The Lonely Peaks and additional Nashkel content are in the xvart expansion discussed in this thread. I guess that will end up in jastey's BGQE if she has time to update it. The gnoll interior is in an alpha mod called The Calling that CamDawg and SimDing0 worked on ages ago and we are looking at trying to get to a release (either on its own or possibly part of BGQE).

Using these in various mods (BG1, Tutu and BGT): FW0720 Drakon Tavern (interior character) FW3800 S. Beregost Road (sunken house) FW4400 Lonely Peaks (large peak interior, Hulrik's house, underground area) FW4800 Nashkel (windmill) FW4809 Belching Dragon (cellar, interior characters) FW5100 Gnoll Stronghold (interiors)

Game variables are assumed to be 0 if they haven't been set. All I can think is maybe the CRE isn't getting copied properly, or maybe BG1 doesn't like it for some reason, but I doubt it. Also, this code makes no sense at all to me: COPY_EXISTING ~ar2301.bcs~ ~override~ ~ar4809.bcs~ ~override~ ~ar0705.bcs~ ~override~ It does nothing, except possibly fail if the scripts don't exist. Whereas EXTEND_BOTTOM will automatically create the scripts if they don't exist, so you don't need the COPY_EXISTING. In BG1, the area scripts should be set in the .are files, so that shouldn't be a problem either.

It sounds like the "fix" is not to install this kit with the NWN-style HP (or similar) tweak.

Yeah, it's probably the worst thing about area editing. I keep meaning to try out jcompton's wallgroup automapper but thus far I've only worked with relatively small areas, so I've always figured it'll be easier to draw them from scratch (and still ends up being a PITA). I thought Avenger was maybe thinking of adding or supporting that auto-wallmapper through DLTCEP though.

The one I was talking about had 4 points (the one circled here): But are you saying I'd have to "ground" it with a couple more points or something? In that case it would overlap the wall below it. I probably wouldn't bother, since it seems to work just fine as a regular wall, but useful to note somewhere I suppose.

Well, almost a week ago, cmorgan said he could upload it by Wednesday...