Miloch

Do NPC Dwarves get the racial saving throw bonuses?

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.

Anybody know how many charges the paralyzation wands in the store have vs the one you find in the cave?

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 should note I just another bug, which I had earlier, in Sorcerous Sundries. I could not initiate a dialog with either of the two guys in there. This happened before, as well, before the whole wyvern thing, when Viconia couldn't talk to the shop owner. Eventually she could, after I switched control around to different characters or something and then she could talk to the shopkeeper. This time I was alone and my character couldn't talk to anybody in there. I left the store and then went back in and everything was fine.

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

Well I did some tests back in Ulgoth's Beard. Sure enough, a fireball wand penetrates a Minor Globe and does damage as if the Globe wasn't there. Apparently a fireball from the wand is being treated as higher than a 3rd level spell. An actual Fireball spell on the other hand does not penetrate the Globe.

 

It appears Wands are, for some reason, given a higher spell level than the spells they cast.

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

Recharging probably exists in BG1. The item format isn't that different between the two games.

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

Version 1.9: Happy 8th G3 Anniversary (24Sep11)

• Changed druids and fighter/druids to get scimitars instead of longswords if player chooses to use "large swords" with BG1-style proficiencies
  
• Reoptimized NPC WeiDU GROUPs
  
• Fixed monk off-hand bug
  
• Fixed Imoen BGT "equipment poverty" bug
  

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.

I mean, romance is the meaty part so many girls want, right?

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

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

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?

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:

@129530 = ~This component is only applicable to BG2 or BGT.~

@410100 = ~Change Anomen's knighthood reward/penalty~

@410101 = ~Wisdom +1 on passing (instead of set to 16)~

@410102 = ~Wisdom +1 on passing; Constitution +1 on failing~

@410103 = ~Wisdom +1 on passing; Wis -1 and Con +1 on failing~

@410104 = ~Wisdom +1 on passing; Wisdom -1 on failing~

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

I just remembered about this mod, and reading Andyr's last comments, the mod is supposedly done (other than voicing). Is releasing it out of the question? Would anyone share the beta/release candidate with me?

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:

It isn't possible to make "Githzerai" appear as his race on, for example, the character record on screen.

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

@400001 = "On initial joining only"

@400002 = "On initial joining and rejoining"

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

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

There's only (at best) 8 free flags on standard BG2, so space *is* at a premium.

Well, all the more reason to agree on standardised numerical values (and labels).

That's true. Okay, so CD_INN (?) and FL_STRONGHOLD it is.

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

OUTDOORS FL_INN would catch Miloch's Druid Resting Stop (hopefully with half-dryad half-nymph attendants)

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)

Edit: I notice there are two GLOBALs called before the CreateCreature command. I don't find them created or set anywhere. Are they created when called, or do I need to create the GLOBALs somewhere?

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.

Wallgroups are a complete PITA, so much so that I'm working on a large sub-topic devoted just to wallgroups and their problems.

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.

Is there any luck to see v1.4 in a public release?

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