Vault now supports HTML5 desktop notifications. These are little popups that newer browsers show; you might know them from GMail or similar. This is why the Vault will ask you for permission to "Show Notifications". (If you accidentally click on Deny, you'll have to manually allow it again for our domain somewhere buried in the browser settings for this to work.)
TheYou can toggle it in the Account menu at the top right, where the sound notifications are as well. The idea is so you can simply leave the Vault open in a background tab and not bother with our crufty XMPP bot. I might add the same to FWN later.
I've tested it on current Firefox and Chrome and called it a day.
This should be pretty self-explainatory:
/** * Creates a parametrised polymorph effect. * * Implementation details: This operation is currently not atomic; it needs to be applied BEFORE * creating any other custom polymorph effects. This may change in the future, so the call semantics * remain as they are. */ effect EffectPolymorphCustom(int appearanceType, int racialType, int portraitId = -1, int str = -1, int con = -1, int dex = -1, int acBonus = 0, int hpBonus = 0, int spell1 = -1, int spell2 = -1, int spell3 = -1, string portrait = "", string equipped = "", string crWeapon1 = "", string crWeapon2 = "", string crWeapon3 = "", string hideItem = "", bool locked = false); /** * Allow/disallow the given creature to use items while polymorphed. * * Implementation details: This just sets an lvar, and as such will apply to ALL * polymorph states this creature enters. Semantics of this call will change. */ void SetCreatureAllowPolymorphUseItem(object creature, bool allowed);
The API really isn't as clean as I want it to be, but it'll do for now. I really need to stop adding bells and whistles and get back to the encounter/spawning system. *snooze*
Looking at the D&D dragon disciple, I always wondered what this class is even supposed to be. Browsing the internet for some insights, nobody really knew and it was considered a waste of levels by all sane beings. Even when viewed from a fluff perspective, it never really offered much atmosphere. Even worse, the standard NWN implementation does not even offer the same amount of features as the SRD variant would normally offer and limits players to the red dragon variant.
It was time to fix this class
Knowing that pathfinder always knows how to fix D&D issues, it was my first source in getting some insights how they approached the dragon disciple. In the pathfinder world, the dragon disciple clearly is a melee combat oriented class with a continuing arcane caster level progression. It has the best hit die possible (d12), extra combat feats and a powerful breath weapon (1d10 per level, 1 use/level). Even better, he can transform into a dragon later on! Great concept!
So what changes make sense for our dragon disciple?
First of all, the dragon disciple is a melee combat oriented class, so I removed the staged d6, d8 and d10 hit die that made no sense at all and replaced it with a d12, just like dragons. I also replaced the breath weapon with the pathfinder variant. The NWN breath weapon had a static DC of 19, worked only once per day and had an underwhelming damage that was no danger to any character or monster of the same level. The damage is now changed to 1d10/level, usage is 1 per level and the DC is 10 + level + CON modifier (same as dragons). So now the dragon disciple has a serious weapon at his disposal that exceeds even the damage of a fireball!
Second, I added the feats from the pathfinder draconic bloodline extra feat list. Blind sense with blind fighting is now easily possible.
The third was to compensate the missing arcane caster progression. This is something not done well in NWN and so I scrapped the whole requirement to be a spontaneous caster. To compensate even more, I increased the skill points from 2 to 4. Also, the whole immunity thing comes too abrupt in D&D and the other 9 levels, the dragon disciple does not even get a small resistance so I decided to change the immunity too. A dragon disciple now receives a percentual damage immunity, 10% per level, resulting in a 100% energy immunity at level 10.
Bloodlines
The most annoying thing with the NWN dragon disciple was, that it was actually only a red dragon disciple. There was no option to be a silver, black or blue dragon disciple. The new implementation will allow this. The player has to decide what bloodline the disciple belongs to which then in turn determines the energy type and immunity. This is a tricky one because NWN does not allow feats to be chosen only once. A feat gets available and stays there, for the rest of the character's progression which is not what we want since this would mean a character can choose multiple bloodlines. So the actual decision for the bloodline has to be made outside the character progression screen via scripting.
What about dragon shape?
Pathfinder gives a dragon disciple the ability to change into a dragon for a certain time. Will this come next? Maybe, this is not decided yet but will be after a first evaluation how the new dragon disciple fares.
3.5 Armor values are pretty weird. I mean, just look at it! Some of them are just plain useless even in P&P; and most are not available in NWN as-is anyways, for example, the differentiation between a +6 Splint and a +6 Banded.
So the Silver Marches Rule Kobolds decided to rework them, and here is what they came up with.
Armor
ACP = AC - 2
ASF = AC * 5
AC | MaxDex | ACP | ASF% | ASF% (Bards) | |
---|---|---|---|---|---|
Clothing | 0 | - | - | - | - |
Light | 1 | 8 | - | 5 | - |
Light | 2 | 7 | - | 10 | - |
Light | 3 | 6 | 1 | 15 | - |
Medium | 4 | 5 | 2 | 20 | 20 |
Medium | 5 | 4 | 3 | 25 | 25 |
Heavy | 6 | 3 | 4 | 30 | 30 |
Heavy | 7 | 2 | 5 | 35 | 35 |
Heavy | 8 | 1 | 6 | 40 | 40 |
Shields
ACP = AC
ASF = AC * 10
AC | ACP | ASF% | |
---|---|---|---|
Light (incl. Buckler) | 1 | 1 | 10 |
Heavy | 2 | 2 | 20 |
Tower | 4 | 4 | 40 |
The keen observer will notice that tower shields are now AC4 instead of AC3.
We hope this clears things up a lot, and will make calculating things in your head simpler too. Our resident Drow has been volunteered for sacrificial testing. Happy bashing.
I've added some tweaks and patches to the server so that shield, armour and weapon proficiencies are handled as they are written in the 3.5 SRD (or Pathfinder, where it makes sense).
Proficiencies
Armour and shield proficiencies have been softened; meaning anyone can equip any defensive gear now. Doing so with things you have no proficiency for (as in, the feats) with will apply the penalties transparently that one would expeect:
A character who is wearing armor with which she is not proficient applies its armor check penalty to attack rolls and to all skill checks that involve moving, including Ride.
When you are using a shield with which you are not proficient, you take the shield’s armor check penalty on attack rolls and on all skill checks that involve moving, including Ride checks.
Haha-sidenote: Funnily enough, hooking CNWSCreatureStats::GetSkillRank(*this, uint8 skill, *versus, bool a3)
, completely ignoring a3, and expecting everything to go smoothly was a bit naive in hindsight. Turns out that is actually ranks_only
just like the script call advertises, and the Save-to-servervault method actually calls this too .. Oh well, restore from backup .. When called with false it actually returns all the feat-modifiers and properties anyways, so might as well inject myself there and no harm was done.
As well, wielding a tower shield will provide you with a fancy -2 penalty on AB; which is something NWN did not do before. A very minor issue.
The same goes for weapons you are not versed with; however, here the penalty is a tough -4 to AB:
When using a weapon with which you are not proficient, you take a –4 penalty on attack rolls.
Right now, that penalty applies whenever you wield a weapon you are a noob with; no matter if offhand or mainhand (but only once, you know where to send the money!). Not too sure what to do about that, since AB would have to be hooked separately for each hand I think, and I didn't find the right place. I suspect it doesn't actually exist, and I furthermore suspect it doesn't actually matter in real-life. Might be better off if I had chosen to use engine effects, but that would have been cludgy at best. Right now I'm feeling pretty good just ignoring it!
duplicates some fields provides data to all provides data to some AI-related methods makes a copy for sending to clients does magic, and once that was hooked just so (AB 180/175/170/165 sounds about right, right? Right?) it worked. I'm pretty sure the whole thing breaks if a DM does #set bab something something but don't tell anyone. The worst part was actually finding the places where the UI is updated (you know, the charsheet!). Turns out, there is some mysterious method pair CNWSCreatureStats::UpdateCombatInformation and CNWSCreatureStats::UpdateLastStatsObject that
Special Attacks
Special attacks are all attacks that are inserted into the combat round - like TripKnockdown, Disarm, Stunning Fist, Critical Strike, and so on. I've hooked those as well, so that one can run arbitary effects instead of the hardcoded ones. Right now, the only fix applied is to reduce stun duration for Stunning Fist to one round (was three!), and completely disable Disarm and TripKnockdown, because frankly they suck donkey. There was talk about reworking all those feats into PW-compatible Combat Maneuvers inspired by Pathfinder. Real Soon Now.
Bards
In the same vein, I've deleted the shoddy scripts that used to apply a -20% ASF on light armour worn by bards, and made it into a core override instead to GetASF (actually, I am mid-method hooking Get2DAFloat inside of CNWSCreature::ComputeArmourClass (sic), but who cares about that, right?). So yeah, this is now handled natively as well, making it much more robust (and transparent) to the user. Someone just needs to go and edit the TLK entries for light armour to show that fact to attentive readers.
In any case, This is in line with our aim in getting rid of all the NWN-isms that don't make much sense in a persistent world setting.
Witch Casterlevels
The Witch PRC outlined (okay, it was more than an outline I guess!) in a previous blahg post required some intrinsic tweaks, so that the taken Witch class levels are added onto the Druid class levels for the purpose of spell CL/DC calculation. That has been done as well, and should work transparently with no script-side monkeypatching required. The same mechanism can be used to augment any non-spellbook caster PRC to provide full CL progression for it's base classes, but for now, it's just the Witch. Drawback right now is that it only makes sense build on the Druid class; and a multiclass character cannot pick onto which base class the Witch should gloop on.
Technical Background
All of this code goes into a custom NWNX plugin that will eventually be published for other PWs. Goal is to provide a drop-in plugin that just 3.5ifies your server, with no scripting necessary. The actual code is in our silm-specific NWNX plugin (and 3.5ify-plugin here), and will eventually be bumped onto Github as well (another long-waiting thing to be pushed is nwnx_redis ..). So that this doesn't conflict with other plugins that might conceivably hook these methods (although I can't think of one offhand!), I might have to introduce some new core events in nwnx2. We'll see.
Pointy thing
). Better not mess with that one!
Also, I made a new rapier, in the style of older sideswords (or so I've been told). Design target was a character of mine, aiming for a really elegant-but-sinister look, but I suppose it would look just as fierce in the hands of a drow (although it might be too big for them
One of the oldest and most used areas in the earlier days, still on silbermarken.de, were the great forests taken directly from the setting. The more important one was Arn Forest, the largest set of maps we had back then - I think it was more than 40 maps, all 10x10 tiles. Real centre of player activity for elves, druids and other nature types. Alchemist gathering place too, for a while. Banditry happened in there, goblins attacked the elven tree settlement, and at some point its western flanks were set on fire, causing a lot of characters normally at odds with each other to work together to stop the fire. Fond memories there.
Well, the playerbase has changed - though activity flared up again thanks to Vashandos rangers and the keep they built, most activity really shifted towards the Fork again, with the Arn Forest being a fondly remembered but rarely visited backdrop - mostly travelled through to get to Arnkeep or for the odd character living in the woods. For myself, at least, it didn't help much either that the classic NWN forest tileset was fairly bland in appearance. I mean, we didn't even have altitude variation, and it certainly did not feel like a northern pine forest to me. I visited it truly rarely, the last years.
Rebuilding
Part of our rebuilding effort was doing the wilderlands - the 'Realmspeak' word for the wilderness - better justice, trying to create outdoor maps closer to what the area should look like in-setting. So, after the most important map updates - i.e., those people were using on a regular basis - we eventually pondered what we would be doing with our woodlands to the east - especially since we had to put Arnkeep nearby somewhere. Can't have that without the accompanying forest. And there was a player with a tower in those woods, second-home at the Fork nonwithstanding. Still, second-rate would not do, so we checked out some tilesets.
I'll say it right here - the only tileset that was ever truly an option was Mountainous Forest by Baba Yaga, and expanded on by Zwerkules. I was quite skeptical even there since it's quite lacking in building options, and doesn't even have water terrain aside from your normal stream - two items that are rather compulsory for our past history in those woods. Other tilesets had those, but, no or lousy pines.
In the end, I just tried it out. And damn, am I happy I did. Honestly, it looks awesome. With just a bit of terrain variation and lighting play, you can create dense and thick pine forest without too much repetition, and with our weather system providing fog, you can and will get lost in those ancient deep forests. The terrain groups and features may be limited, but together with some placeable work, you can do far more than I had initially feared.
So far, the Arn Forest consists of four 30x30 maps, with quite a bit more to come - just to cover the most important areas, such as Quintars tower, the ranger camp, and the river leading to Arnkeep.
Watcher's Rise
This is actually a new place that didn't exist in earlier iterations of the forest. It features a stone platform with four great dwarven statues, all set on a stony crag rising up over the trees. A leftover of Old Delzoun, the great dwarven realm that ruled about all the place over a millenia ago.
I'm pondering to add a bit of dwarven ruins underneath it, too - probably once I get around expanding the Fardrimm (a dwarven tunnel network, similar to the Deep Roads of Dragon Age if you're familiar with that) into that direction.
It's a pretty cool landmark, all in all. Could see folks meeting there simply for it being a good point of reference.
River Icespear
The Icespear is actually coming down from the Nether Mountains near the Fork, and then flows west - we invented our own little spin-off going east instead, towards Arnkeep. Should probably give it a new name. As it is, it goes through three forestmaps (two of which are mapped so far) and then stops right at the walls of Arnkeep, large enough to accomodate river barges.
As mentioned before, the tileset only supports small streams - completely unsuitable to the large river I had in mind. So, being as lazy as I am,I dug a trench, removed the trees inside with an overuse of the clearing feature, and filled it with placeable water.
Funny how well lazy ideas work at times. Since it's normal terrain down there too, you can even walk around in the riverbed if one wants to roleplay some swimming. Doesn't look any worse than actual watertiles in most cases - the only issue I found was that certain lighting effects can look a bit odd if you're standing just at the boundary between two connecting water placeables; but since they are four tiles (40 metres!) long, that doesn't happen all that often. Well, that, and it not really showing on the minimap.
Buildings
As said, the tileset doesn't really have much in the way of buildings. Two tower variants and a tree hut with two terrain variants. And by 'hut' I really mean a tree trunk with a door and windows. We have a ton of building placeables, but being placeables they don't have door nodes. Still, they can be used now and then - say, a log-cabin like addition to the side of Quintars tower, with the tileset tower holding the door node, or by fiddling with one of the NWN2 Mulsantir houses to place it ontop of the tree hut exactly right for the placeable doorway to align with the hut door node. That fussing about with placeables actually makes me wonder - why not just add invisible door nodes to normal tiles, then put placeables on top? Hmm!
This mulsantir house is actually in Ghostwood, not Arn Forest, and features in the only Ghostwood map that exists so far - I'll write more about that particular spookywood in a later blog. Consider this a sneak-peak.
Arnkeep
Arnkeep was actually simpler than I thought. It's not directly inside the forest, so I fell back to good olde CompleteRC, and finally got the opportunity to play around with those city and castle construction tiles. Doing quite well for a first draft, even though there is something wrong with the door node on the castle gates. For some reason, it freezes loading screens upon entering the area - but only when I place it within a certain distance of the rest of the castle on it's hill. Anywhere else, it works. Heh.
No matter, I'll keep the gates open for now - as they'll usually be for roleplaying, anyway - and bug niv to fix it at some later point. After all, there is a lot of work to be done still with this initial draft, and I have haven't even started with the insides yet! First will be new, more rustic textures for the castle itself, for certain, and the little village nearby - simple folk producing charcoal, which, together with the iron mined one Arn Forest map to the east, is used to make steel at the keep, and later shipped to the Fork. On that - I need movable river barges!
So much for the first few Arn Forest maps. I'll be doing some brief military service starting thursday, so expect a new blog post or content in general from me either far off until March if I'm busy, or pretty damn soon and/or often if I'm not. I really have no idea yet.
So, let's talk about adding new spellcaster classes to NWN.
It doesn't work. Not easily anyway. Most of the stuff is hardcoded right into the game, no matter how often you set that spellcaster flag in classes.2da to true, and no matter how many spellgain tables you define. There's a few ways to work around, with feats, subradial spells and so on, or with all the heavy scripting the Player Resource Compendium employs, but it's clunky, I tell you - no fancy, easy spellhandling like with the existing classes, suitable at best for a secondary caster with limited spellcasting - say, if we ever get around to implement a proper assassin or blackguard.
It's pretty much why I built my witch character as a druid. It was close enough to what I wanted. But, alas, it was not perfect. So, how to get a set of nifty witch abilities while avoiding the entire "make a new spellcaster base class" issue? The answer will be obvious to those of you playing any of the P&P 3.x derivates - a prestige class. Easy solution, right?
Except not. NWN has a funny way of handling spellcaster progression in it's prestige classes, so, I started experimenting and taking notes. I took the Champion of Torm, and gave it full progression, arcane and divine, and removed the prerequisites. As expected, I did gain new spells per day, and even access to new spell levels precisely as I should, no matter the class, just as if I had taken levels in whatever base class I started out with.
That was pretty much where it stopped working right, however.
First off, the most glaring issue with all classes - it does not advance caster level. So even though you might cast the same number of spells as a pure-classed wizard; if you are a Wizard 5 / Loremaster 10, your Chain Lightning spell stops at 5d6 compared to your Wiz15 buddy's 15d6, and your roll for dispel and spell resistance checks is at a meager +5 instead of +15. In other words, in many cases you effectively neuter yourself.
The second issue - not for everyone, but just as or even more showstopping: Spells Known. While a PrC can advance your spells per day, it does not, in fact, grant you new spells to fill those slots. For divine casters, this is a non-issue - they know all spells on their lists right from the start. Wizards do not gain their two free spells per level, but could at least learn new ones via means of scrolls. Sorcerers and bards? Nada. You do not learn new spells through prestige classes, ever. As a sorcerer 5 / prc 5, you might have fifth level slots - but you know only second level spells, exactly the same as any other fifth level sorcerer.
In other words: I found that PrCs as-is are not worth it at all for bards and sorcerers, and are only of marginal use to everyone else, at least if you want to play a primary spellcaster.
That is, until niv told me that he could probably get the caster level progression working.
Making a Witch
So, a druid-based caster PrC with actual caster level progression? It's a divine class, so getting new spells isn't an issue. What's to stop me, then? All I need is, effectively, there, or at least possible.
Still, it took me a while to really get along to it. Started writing down some random thoughts a good six months ago, and every now and then between other things. Nothing in engine, all in a shiny, SRD like google-documents table. Read through various other sources for inspiration. The Pathfinder Witch for instance is pretty cool, and has been part of the character's inspiration in the first place. Elsewhere, too - monster abilities, other games, books, whatever I could think of. Eventually, I cut most of the random ideas away and reduced it to something that seemed well suited to replace the normal druid progression early on - and grant a new or improved ability every level, too.
So, three days ago or so, I actually started putting that fancy document into NWN. Lots of 2da work there - classes.2da first, of course. One long line handling things from it's hit dice or skillpoints over references to other assorted tables to NWNs weird calculation method for challenge rating. I mean, what is the point of setting the CR gain for each individual level? No matter, the hardest part about that line was finding an appropriate icon - a thing we have many of, luckily. Check silm_icon.hak if interested.
Thus, the class was theoretically in the game. Without any text labels, let alone abilities, and probably making the game crash due to a lack of related data. So, I copied a few other tables - the wizard saving throw table, the druid class and bonus feat table, and of course a table for the prestige class prerequisites, and renamed the class designator to 'witch'.
Prerequisites first - after some back and forth about what was even possible within NWN limitations I flat out required druid levels, and 5 ranks of survival. That way, you'd need to be a second level druid to get access to the prestige class, which was my intent. Aside from some odd multiclass combinations, this pretty much ensures it being an alternate for the druid only, and replaces most druid abilities with witch abilities. The PrC has 18 levels, and then goes into epic, granting a bonus feat every third one.
So, now I have a prestige class requiring essentially druid 2, and granting... still druid abilities, but with a worse base attack. Need to edit cls_feat_witch.2da for that. That, however, references feats, it does not define them. Thus I need to add my abilities to feats.2da, and there, reference a new line from spells.2da for all the active feats, create a spellscript for those feats, create feat duplicates for those changing with level in uses per day and define each one's succeeding feat, and when all's done, list them to be granted on the appropriate level in cls_feat_witch.2da. Oh, and remove all those druid and epic druid feats from it, too. And on top of that, I need to add tlk-entries, often two or per line in classes.2da, feats.2da and spells.2da, and reference them by line number in those files.
Witch Spells!
Well, at least most of that was tedious, but easy. Spells needed some fiddling to get their casting behaviour right, and it took me a while to get appropriate sound effects - the Cackle ability even actually cackles, with different voice sets for male and female. With that done, and about an hour of icon-delving, I moved on to spellscripts - first to test the 2da entries by means of the usual Hello World stuff, then for real. Making Curse of the Witch was easy - it's only a variant of Bestow Curse after all, though there I already realised that I needed my own functions for the caster level and saving throw DC since I was casting via feat, not druid spells, which will be handled by niv's adjustments to GetCasterLevel() later on. So, extra mini-library to be included. Easy.
Then I tried to quickly modify the Entangle script for my Vile Roots variant which does roughly the same as the spell, just with a difference in save DC. Easy - or is it?
I tell you, that spellscript is a mess. Or rather, those spellscripts, because due to it being an AoE, it actually has a spell script fired on cast as well as a onHeartbeat and onExit script for the AoE - and it would have had an onEnter script too had it been done properly. There are multiple variables declared that later remain unused, the comments sometimes speak of completely different terms than what's actually there, and the actual entanglement is deeply hidden inside a ridiculously multi-layered maze of while()'s and if()'s - and in dissecting that maze, I found that the NWN variant of Entangle works completely different from the D&D 3.5 Entangle spell too.
After much back and forth, I finally decided to nearly completely redesign the spell itself, and the scripts. A generic script containing ApplyEntangle() and RemoveEntangle() that I could use for the normal spell, too, and four new scripts for my Vile Roots, handling caster level and save DCs separately. Upside: I get to bypass another NWN issue with area spells. Since GetSpellSaveDC() always applies to the last spell the AoE creator cast, casting Entangle and then, say Flame Strike actually causes saves required by Entangle after the second spell to use that spell's save DC instead of its own. Vile Roots uses the scaling DC from my witch abilities, and passes that number onto ApplyEntangle(). Bit trickier to fix for Entangle itself, but I get around to fixing that spell once I'm certain my own works perfectly.
My other active engine spell feats were, again, fairly easy - Eternal Slumber is just a single target sleep after all, and Cackle throws a fear effect on every hostile creature within range - I blatantly stole most of that code from Fear and Wail of the Banshee.
So, after some more local testing, the class was pretty much done, with the majority of the work done in maybe seven or eight hours of work. That's... not too bad actually. Granted, a lot of abilities are for roleplaying use only and have no NWN engine effect, but still.
What now?
The PrC is online. Rebuilt my character, and aside an already corrected oversight with the class skills, seems to work as intended. The GetCasterLevel() fix is there too, though niv still has to look into a few spells using core libraries - don't really want to recompile every core script to make it work. Most however work, in most respects. Spell resistance and dispel checks are a hassle. At that, I might still need to write my own resist function for the feat-based spells unless he manages to get that factored in correctly.
If all works well, I'll look into adapting the original Entangle too, and maybe add active spell scripts to the Tongue of the Wild and On Wings of Black abilities. Certainly gained some insight into all those .2da files too, and I already have a few other ideas. Maybe finally make some assassin or blackguard spellcasting, as hinted earlier? Shouldn't be too difficult once we get all the save, resist and caster level stuff out of the way. For the divine side of spellcasters, it's very doable. For the non-magical ones, sure.
Still sucks for the arcanists, though. Maybe one day.
I'll have the class details up on the web page soon, too, for all those who are interested.
Edit: Class Writeup is online: Witch of the Wilds
Added a feat that allows darkvision toggling; which can be quickslotted or radial-toggled like any other state.
Adding this feat was a bit fiddly. For icons to appear in the radial menu, they must be added to the cls_feat_*
lists - all of them. Due to this, the icon may appear multiple times in the class radial menu. This is something to be fixed clientside (NWNCX) in the future and cannot be helped at this time. While ugly, I don't think it's a big deal, as it only affects multiclassed characters and is hidden out of the way nearly all of the time.
As well, darkvision is now done solely through a visual effect - the engine effect itself (that the hardcoded feat grants) has been reverted to normal human vision. The upside of this is that darkvision got much slicker. It will no longer jump into normal vision as soon as a dynamic light source gets near enough; the player has control on when to enable it, as well as some scripted triggers that toggle it for you automatically (i,.e. when night falls). The downside is that possessed creatures may need additional tweaks to make it work well.
Please keep in mind though that this is a OOC-only feature for design aesthetics/personal preference. Most creatures do not actually have the ability to turn off their darkvision at will!
Winters are dark, in case you were wondering. As of now, there is a experimental patch online that tweaks light values to be more in line what the SRD claims darkvision, low-light vision and human vision is like.
Things may seem very dark at the start; however, that is intended. The baseline I chose was for areas with no light at all - a moonless, colourless, lightless void. Humans see about 1 meter, low-light is two, with a nice hue to it; and darkvision is blue-ish (to simulate greyscale which cannot be done with the nwn1 lighting engine)! There is only one type of darkvision for now, and as a compromise I've set it at about 90ft (2-ish tiles) to accomodate both the 60ies and 120ies.
Having a proper zero-baseline means that area creators have a much wider creativity range with area lighting, and the weather system can adjust area lighting to match moon phaseeventually; but this will also mean that torches and other light sources are actually much more useful because noone likes to run into things. Please don't tweak area lighting yet to accomodate the new lighting scheme. It is experimental, after all.
As a side-effect, Ultravision (that garish pink effect) is now gone and replaced with the exact same visuals as darkvision itself, so the spell works again as intended by Ao. Or something.
For the curious, the patch in question is fx_light_clr.mdl
in silm_merge.hak
.
I've added Zwerkules' excellent Keep Interior tileset as silm_t_keep.hak
. That's basically the reason everyone needs to fetch 80 28MB of data. So there.
The plan is to build the (eastern) arn keep (Arn Keep? Arn keep? Arnkeep? Arnold's Feasthall?) with it, but I'm sure there will be many more usecases for it and it is very pretty!
In the somewhat-near future, I'll be copying all tileset distro haks to match the new naming scheme, silm_t_*.hak
. To make this a no-op bandwidth-wise I will need to patch the updater to detect file renames (there's a rsync patch for it, which needs testing ..). Example: mountainousforest.hak -> silm_t_mtnforest.hak
. I will obviously not be deleting the source files, since I must assume people might have them around for other reasons; even if that means that some people might have data twice.
Reasoning being that there is just too much hassle keeping track of upstream changes, and silm updates will break/overwrite distro haks that people might want to pin to other versions. There will be a separate post about this, including a list of to-be-duped files in case people want to delete stuff manually ..
Also in the box, a AC3 leather/hide variant of the pretty chain mail 113.
Very small update: Some new city textures ( ), that properly reflect a "more nordic" feel of the place. Thatched roofs, weather-beaten wood walls and stone foundations built to be sturdy and easily heated. I think it looks awesome!
Next up is grass and forest/foliage textures.
Side node: Garbled textures are apparently a result of RLE compression inside .tga files, that Photoshop handles fine but the bioware dds compression tool not. The workaround is to load it in GIMP instead, and re-save RLE without compression checked.
Some more text on how the weather system actually work, and having the system just basically finished, what's already all wrong with it. Writing this to focus my mind more than anything, and get things in order.
As mentioned in a previous issue, weather is generated by badly mangling some sine-based functions, where 2PI is equivalent to one day. This means I can query the function with simply a float describing the day of year (with fractions being hour/minute), and then with the right set of additionals and modificators, get some fancy curves that actually look like good weather at first glance, with daily highs, lows, jitter.
Many modifiers can be adjusted at runtime on a per-climate and per-area basis, so you can tweak the curves until they look just right (and there are very simplistic debug tools available to help with this) for the climate zone you want to model - for example, in visual terms, make the temperature curve more shallow (less difference between summer/winter), move it on the Y axis to make it warmer/colder in general, make daily jitter larger/smaller (more/less temperature difference between day and night), and so on. Same goes for humidity, which (as of now) mostly affects fog and type of precipitation, and precipitation, which affects precipitation (who'd have thunk it!).
float weather_func_temperature(struct Climate climate, float day_of_year) { /* monthly curve */ float tyearly = (2 * PI * day_of_year / WEATHER_DAYS_PER_YEAR - 1.8); /* daily low/high for each day */ float mdaily = rcos(2 * PI * day_of_year + PI) * climate.adjust_factor_day; /* jitter that makes spring/fall have wider ranges */ float tseasons = (rsin(day_of_year / 2) / 12); return climate.base_temperature + mdaily + 2 * climate.adjust_factor_month * rsin(tyearly + tseasons); }
freeze all closed bodies of water if it was cold for at least 30 days are now possible! Yay! (Btw, water freezing works by caching the tile info from the source .are file in FWN and then spawning actual ice plates where water is, hiding the edges beneath the embankments. Works amazingly well, too.) This is not actually implemented yet, as it is tightly hooked into the dynamic snow system, which tends to lag out clients. **oops**
.. at least if you aren't looking altogether too close, which you won't be while playing (I hope). Needless to say, this won't stand up to a discerning weather connoisseur. Whatever! I can now also pretty cheaply generate averages over the past few days, calculate the discrete integration of humidity/precipitation to find the amount of rain we saw, and so on; meaning weather cases like
So, what's wrong? Or, to be more positive, what's actually todo before I will be happy?
Weather States
Right now, the weather state (something like "Dense Fog") is a function of humidity and precipitation. temperature only factors in as a decision if precipitation consists of snow, or of rain. I want to rework this into a more granular approach, where temperature affects the consistency of weather more than just "it snows if it's colder than 0C". This requires some more thought and fiddling, and probably factoring in some historical data as well.
Fog density/colour scaling
Fog density already scales really well with humidity, but colour is another matter entirely. Colours are kind of hardcoded right now, but they really should be configurable per-climate (snowy fog in the desert, really?) Either way, this needs some more experimentation - what kind of fog needs what kind of placeable and vertex fog (to make it look nice). Morning fog should probably have less vertex and more "cloudy" to make it look crisper - stronger colours - like mornings tend to be. I've already spent too much time on this .. but it's fun.
Desert Climate
Deserts are really arid and hot places, at least the one found close by to where I model stuff. Right now, this is just handled in a special case in code, where when there is no humidity at all, it gets different names and visual effects. I really wish there were sand storms, but seeing we don't even have any desert areas attached to the supermap yet, this is kind of in the dont-bother-about-it category.
Wind
There isn't any. But then again, I can't actually influence the area windyou know, the wavy grass bits at runtime unless I hook it (and I don't think it will be sent to clients even if I do), so the only wind that would be of use were one that would go into the weather model itself in order to make it more accurate. Right now, wind is just a property of precipitation, just like barometric pressure is. Again, this works okay-ish as a approximation I think so away it goes into the dont-bother bucket.
Climate Transitions
If you walk from a one climate zone into a bordering climate zone, you might expect a gradual transition in weather conditions (or you pull the good ole' you pass through a cavern/mountain trick). What you get instead is a transition that, in the usual case, has a temperature differential of 30 degees or more. Seeing as I do not intend to model actual hurricanes anytime soon, I should probably do something about that. Right now, you can give individual supermap tweaks to areas, like scaling temperature lower and lower as you come closer to the next climate zone, but that's obviously not optimal since it does not take actual current values into account, meaning you will still get potentially huge differentials even if you are really tricksy about it.
Ambient System
Ambient emotes like You feel warmer, when standing near a fire. Body temperature tracking, factoring in worn armour parts (hah, as if that will ever happen). Not too sure where to take this, if anywhere. Doesn't feel like it would add much value right now, but you never know until you try, right?
Indoor Weather
Sound effects, fog wafting in through the cracks, warmth/chill emotes. Wandering lightshafts through windows (see prev. posting). Also: Guidelines for indoor lighting setting, and adjusting them at runtime.
Alright, so I re-did the algorithm a bit. I'm still not 100% happy about the way weather states turned out, because they're pretty temperature-indifferent except +/-, but that's something for the future. Enough fiddling for now.
There are some new visual effects (okay, one ..). Some fog placeables that have absolutely atrocious alpha issues (I need to find/make a proper fog texture and not abuse dark smoke with a Lighten filter). Consider this a proof of concept? The downside is obviously that the fog just fades after 50 meters or so. On the plus side, there's problably going to be zombies in the future!
Next up: Fireflies! You'd be amazed how little firefies would like the climate the Fork is situated in .. so unless some kind of dire winter firefly of doom rears up, they will only show up in the warm, humid spring months until it gets too hot for them to actually exist. And maybe forests. Hmm.
Also interiors weather feedback. I want wandering light shafts for windows as the sun/moon crosses the sky, but to have them I first need to know WHERE the windows are, what floor they are on, if they are obstructed, and so on. I'm thinking manual waypoints for builders, unless I come with a better way to figure this out. A whitelist of placeables? A nice/horrible side effect would be the ability to enter/exit buildings through windows. Take that as you will!
And how about sound effects? You can already see the exterior weather description in interiors, but maybe some rain sounds as long as it, well, rains?
Working on the weather replacement. Again. I'm basically ditching the old system, which was based on the reference tables from The Silver Marches sourcebook. While they might well be a good fit for P&P campaigns, some shortcomings quickly become apparent when using them to roll daily weather - there is no continuity. One day fog, next day snow at -30, day after it's +30 but has fog, and then who knows, probably drizzle with a chance of owlbear.
The past few days I kept the old system attached (actually via redis in an external process since I've ditched nwnx_ruby in the server itself for stability reasons), and was hoping to tweak the probability tables until it looked about right, but that really didn't work out. It wasn't too good in the first place and just being lazy isn't an excuse. So, replacement time!
Right now, there's a very experimental (what isn't?) rewrite deployed that does away with predefined weather states, probability tables and whatnot, and instead simply functions temperature, humidity and a rather arbitarily-named item called precipitation chance - in lieu of modeling actual barometic pressure - based on time of day, day, month, year, and climate zone (think "valleys", "high north", and so on). You can think of it as a few sin()ish-looking lines on a graph, plotted and read as time goes on.
With this, and some tweaking, I can get pretty good-looking smooth changes, as the ingame time progresses - no more insta-fog (even though that was kind of funny). You will actually be able to watch the temperature change in .1 increments as the day/night progresses.
Anyways, working with these factors, I can scale fog distance, fog amount, arbitary effects (like ground fog placeables) and then extrapolate various weather states - for example: Is temp < 0f and precipchance > 0.5? Rain, otherwise Snow. That's just the basics, there is so much work to be done on this still. Sidenote/interesting: Also an option now is to use the current temperature in scripted applications, like weather protection clothing, warming your hands at braziers, and so on. While I'm not a huge fan of hardlimiting engine effects, some ambient/fluff might not be a bad thing.
The downside is that there aren't any override states yet, meaning it cannot be overriden on a per-climate or per-area basis. Suspiciously absent as well is any kind of feedback progression; meaning that 3 days of snow will not result in 30cm of snow. YET.
Prettify (Or: Why do I need to download more crap?)
Why go the distance and then not make it pretty? To that end, I'm planning on adding more weather effects. That probably means making custom cloud, fog, and light VFXes (or placeables) that can be spawned by the weather system. Also means I need to finally prettify and finalise the scripted snow placeables that used to be so bad for the server that it would not even send all of them to clients (SetStatic() anyone?).
Another thing is semi-custom skyboxes. I want to find the best that fit our setting. Our current selection is underwhelming both in quantity and quality. I've had a brief look at the Community Skybox Pack but to be frank, so far I'm not too impressed. They're mostly space-y and futuristic, or simple-looking landscapes from what looks like a very cheap terrain generator. Maybe check out TerraGen and make our own? Or, to put a twist on it, find really beautifully drawn fantasy landscapes and put them in? I'm open for suggestions on that front.
Only took three months! But ATs are now auto-generated from the scripted supermap (see
). Builders do not need to do any additional work to use them - they will be created/updated when the supermap changes and players (re)-enter affected areas.On a sidenote, FWN now supports directly importing .erf and .mod files. This brings FWN one step closer to the eventual smooth workflow envisioned. It's possible now to lock some areas, download the lockbox .mod, edit it in the toolset, save and re-upload simply by drag & drop.
Please note that support for this is kind of experimental, so don't go uplading your complete builder's module yet. For now, to avoid problems, only refs currently locked by YOU are added to your index.