Zelknolf Q&A

[Zelknolf]

Seems that some people are too bashful to start a Q&A thread like I said in yonder platform-- so here is a thread for posting questions.

[kid]

Where we draw the line between DMA calls and Tech calls?
Seems that many of the changes tech team is respobsible for are game play calls.

As an exaple I'll take the 24 game hours wait before rest after logging.
(I love it actualy. might do it a 18 hour wait as you just rested, on the other hand rest takes 2 mins or so 24 is also just as good, either way, not the point)
Was there a DMA ruling about it and I simply missed it, or is it not a DMA call to begin with?

I will say that there wasnt an change yet I didn't like,
everything done so far was awesome in all regards, im more curious about the decision making process when it comes to things of that nature.

Either way, thanks for the hard work so far.

[Zelknolf]

The short answer of it is that the boundaries are based on what Admin are willing to fight over. Curmudgeon didn't object, so it was a tech call.

For the long answer...
Division of power is something that's defined in the charter, though the charter is also something that gets argued over and reinterpreted over time, as any document of the sort does. We are, after all, a group of people, and even the sternest and most lawyerly language has to contend with interpretation (the theory being that we all agreed that the place would be run this way, but now we disagree on what we all agreed to). The passage in question reads as follows:

A. Lead Administrator—Oversight of Administration, Veto & Referral Authority, Election Oversight, and Public Relations. Also responsible for resolving disputes over domain classification of any particular issue.
B. DM Administrator—Oversight of DMs & Servers including Item Compliance, Global Plots & Quests, DM Approval & Discipline, among others.
C. Technical Administrator—ACR/HAK and other in-game coding, scripting, and software issues.
D. Infrastructure Administrator—Vault, IRC, FTP, & Website.
E. Player Administrator—Applications, Guilds, ALFA Player’s Manual, ALFA Representatives, Player Discipline, and Player Acceptance.

The assertion I have made as TA is that the only place where core rules are listed in that document is under ACR (that is, "ALFA Core Rules"-- a term that was well-established, contrasted with its splinter, the HCR "Hardcore Rules," within a couple months of the release of Neverwinter Nights), while the DMA has responsibilities for issues of content (that is: plots, quests, servers, items, DM teams).

There is, of course, precedent for as much-- the ALFA's Technical Administrators, historically, have unilaterally made changes to the game's behavior at foundational levels (the history would be: Murky -> Ronan -> Cipher -> Acadius -> Zelknolf); those first three fellows all exercised power in the same parts and lines as I do-- though I do note that I'm unique in the quantity and accessibility of documentation that I insist on (that is, tech under Cipher did this stuff too-- it's just that I'm telling everyone that I'm doing it).

I suppose I could have kept on with what those rare grumpy voices seem to be insisting, that everything should still go through Standards and DMA, but I don't think that would have been a very good idea. Standards isn't a group that was populated with people based on their ability to design or implement useful and meaningful changes-- but tech is; indeed, that's exactly what I evaluate on. Thus, I pushed to get issues of mechanics, in their design and implementation, back in tech's domain, and it simply became less of a fight once it was clear that we would just use the leeway to take better care of ALFA (as evidenced by recent core content releases) and to improve the working conditions of tech staff (as evidenced by pretty-solid retention of talent).


I do well-note your trying to sneak a familiar suggestion into the Q&A thread, too. Tisk tisk, I say-- you already sent that one down the proper channels.

[Dorn]

1) The thing I loved most about NWN1 and miss are the broad expanses of external areas allowing hours of adventuring in a single forest. What are the ways you can push the limits of our systems to achieve that (including your random placeable spawn area ideas....hmm, could you make a random generating cave system!!!!?? sorry, separate thread perhaps)?

2) Given the limited (and wonderful) tech resource pool, what is your focus for improvements and how to you determine what's best for alfa?
Ease of DMing (interface tools etc)
Features that improve character customisation (eg classes, feats, equipment, skills, spells, NEW ARMOR)
Features that bring NWN2 closer to DnD3.5 (nerfing clerics....the way you nerfed poor little bards your bastards!!! j/k, fixing feat bugs)
Features that promote underutilised skills and classes (make traps more commonplace and perhaps useable in discussion with DMA/PA I imagine)
Reduction of lag and server operation allowing more, More MORE! areas
Other stuff

3) As admin you're a leader in our community regardless of lawyering about boundaries of portfolios. Are there any systemic or directional changes in ALFA you'd like to see and why?


oh yea...thanks to you bas, foam, ronan, riot and the rest!!

[danielmn]

I am also interested in what you hope to see into the game within the next coming term. Given the awesome work of this past term, I am grinning to know what the top five works of the tech dept will be in the coming months!

[Swift]

When will instructional documentation start to improve with future releases? Documentation explaining what a feature is is great, but it serves little purpose if our DM teams can't implement those features without having to bother tech every step of the way.

For example, swimming was just added in 1.86, but there is nowhere that I can find that actually tells our server teams how to implement it. There is one thread in the HDM forums announcing it, but no instructions. Ditto the apparent 'do not modify' flag for items in relation to the tailor.

Mainly, I tire of hearing players complain about everything on BG being better when 3/4 of the time the other server teams have not got any easily available instructions on how to implement the cool stuff that is getting added with each release.

[Zelknolf]

All righty, I have some posts to chop up to answer the collected questions.

1) The thing I loved most about NWN1 and miss are the broad expanses of external areas allowing hours of adventuring in a single forest. What are the ways you can push the limits of our systems to achieve that (including your random placeable spawn area ideas....hmm, could you make a random generating cave system!!!!?? sorry, separate thread perhaps)?

Area instancing is the new frontier on this end-- nwn2server is simply more demanding on our host machines than nwn1 was, and is single-threaded (excepting some modifications we've made to allow some things to be pushed off to separate threads-- see IPC and batched / asynchronous queries-- but there are limits to what we can do that to) and exceptionally-large areas do bad things to us.

So, the good news is that we're trying to help you get some more mileage out of your areas, but the bad news is that needing to go through a few area transitions to have hours of adventure is just going to have to be a fact of life here.

2) Given the limited (and wonderful) tech resource pool, what is your focus for improvements and how to you determine what's best for alfa?
<remainder of passage snipped out>

I don't-- and can't-- focus any resources in our pool other than my own. I might be able to squeeze a couple projects out of our developers by leaning on them to do particular things, but that's going to produce burnout, and unhappy developers in the meantime. Fortunately, your typical developer has some pride in what he or she does, so it doesn't tend to take much more than information to get bugs that we made fixed-- but for new things and new features, the closest I come to pushing people (and, I think, the closest I should come-- for the health of the team and the community) is asking if they'd like to develop some things and negotiating with other admin to make that possible as needed.

Unfortunately, this makes very little that I can put on a bulleted list for what everyone else on the team is going to do, and they're stuck speaking for themselves.

However, I use Dan's related question to give an idea of what we've been poking at lately:

I am also interested in what you hope to see into the game within the next coming term. Given the awesome work of this past term, I am grinning to know what the top five works of the tech dept will be in the coming months!

I too am eager to know! Seriously, though, the AI rewrite has entered development, which we be fairly confident in a beta by 1.87 and a slow process of devouring the OE AI through 1.88/1.89, as we become more confident in its functionality: if successful, that will remove our restrictions on invisibility in CvE, make the flat-footedness fix more stable, make our spawns less farmable (in terms of rewards for killing weak mobs en masse and in terms of them being smart enough to run away and find their friends when grossly outclassed), add support for exotic monsters like dragons and beholders, and generally make the game a more plausible representation of Forgotten Realms.

One would also expect to see us bringing more information to DMs during play-- we currently burden our DMs with a lot of paperwork, and I am of the opinion that robots are better at paperwork than people (also, they don't mind doing the paperwork). I would generally say that anything we can reliably automate is something we should, and things we can't should at least have reports to make it easier; I don't know how much progress I'll make on that, but I'm at least hoping to figure out an expanding pane on the inventory report to examine items without actually being on the character's back examining-- I think we'll gain a lot of convenience and stability if we can sunset the DMFI tool.

We also keep having start-and-stop talks about the virtues of porting a lot of our spell-related functionality to C# -- and there are a lot of merits to doing so -- I can't really make promises there, because I don't know if it will ever actually happen. The incentive to do so is powerful, but the work to make it happen is also powerful. If successful, we'd see cleric domains fixed, multiple metamagics on a spell, and functional canonical wild magic.

Otherwise, I would point out that we put in a few relatively-bare systems that we'd expect to see mature over time. The biggest and best require a lot of consideration, and are easy to complicate, though, so I wouldn't be able to be sure how far, say, crafting will be able to automate, but we did intentionally design the core of the system to accept more kinds of crafting down the road, should we be able to agree on what that should involve.

3) As admin you're a leader in our community regardless of lawyering about boundaries of portfolios. Are there any systemic or directional changes in ALFA you'd like to see and why?

ALFA is growing, rapidly-- last month we posted record numbers in almost everything we use to measure in-game activity (alas-- unique GSID logins was higher during the Something Awful advertising blitz-- I hope we agree that such wasn't especially fruitful, and isn't much of a benchmark, though); the trouble is that ALFA is accustomed to being a smaller community. It's accustomed to being a bit more than half its current size, in fact, and we have a lot of antics going on that are fine ideas in small groups: when a community is primarily composed of a network of close friends, the question of who is whose pal is a significant concern in many matters of decision making, and issues of compatability with the games of others are easily brushed off as secondary. I don't think that's the case any more-- and I am inherently interested in growing ALFA: more players means a larger audience means developers feel more needed and fulfilled means happier tech admin. Trouble, of course, is that my influence there is minimal; that's just not the job I've had or the one I'm trying to get. I can try to persuade, sure, and I have some skill and expertise in pointing out how large and complex systems will fail when exposed to normal people (I do that professionally these days), but I'm just an opinion that happens to have a red name attached to it in most of these matters. I suppose I could also have an @ in chat, but that won't happen unless we become large enough that CP posts or something else so obviously objectionable that no one would mind the TA using her access to boot people.

When will instructional documentation start to improve with future releases? Documentation explaining what a feature is is great, but it serves little purpose if our DM teams can't implement those features without having to bother tech every step of the way.

Well, this is actually a challenge for tech, too. We want to have good documentation, because we want people to use our features: think of how ridiculous it would be to put all of the effort into developing something and then just burying it-- it's why I put so much effort into the usability of most things that I produce. It's why zSpawn opens itself, and the Player Report jumps into view with one keystroke, with big friendly buttons full of pictures on it, and things color-coded and put on tables and such. In the case of the tailors and swimming, we actually thought we had good documentation out there-- swimming has associated triggers with descriptive text on the resref, named in a very searchable way with plain-English variables on it. Tailors had an obvious plugin to find (which didn't get versioned, and thus didn't make the plugin package-- that was a rollout fumble) with a handy provided pre-tooled tailor: drop this in your module and watch it work (huzzah!) we'd thought.

Of course, it turns out the swimming package wasn't as discoverable as we'd like (whoops) and the vast majority of builders don't know how to set up NWNx4 (whoops) or MySQL (doublewhoops), so half of our instructions don't get seen, and the other half might as well be in Greek -- and I didn't hear about it until this week, with Curm telling me about all of these DMs who have no idea what's going on, himself included. I suppose the cliche answer is to say that we need better communication on all fronts-- but I don't think there's a consciously-malicious or intentionally-isolating party here. Nobody's saying "sucks to be you; we're not going to do anything about it," so I expect it will get better as we work out solutions to these problems-- as a rational person will note what the solution was last time and apply it in the future. It's less total work to get something right the first time, after all.

[Basilica]

Mainly, I tire of hearing players complain about everything on BG being better when 3/4 of the time the other server teams have not got any easily available instructions on how to implement the cool stuff that is getting added with each release.

BG has seen very active development recently. I think it is specifically worth mentioning that the BG administration and those developing the module have gone out of their way to maintain a continual and ongoing involvement with the tech department (even contributing to the ACR), and often participate in ongoing discussions with new tech/ACR work to a higher degree than those in the other live servers.

The BG team is also willing to do the work to take much more frequent updates to the scripting content in the ACR than the other server teams have committed to.

So on some level there is a "you get out what you put into it" factor at play here. The BG administrators are taking it upon themselves to ensure that they get early and ongoing exposure to new features which makes them inherently more equipped to take advantage of them, especially when the BG team helps the tech department test new features, for example.

I would encourage other server teams to consider making a similar investment if they can spare the development capacity (there is obviously a greater degree of time involved and some teams may want to spend more of that time managing other server activities, for example, which is up to the discretion of the team involved). Tech works to support all servers, but involving yourself in activities like helping to test new features means you get a great deal of hands on experience with the new things that we are cooking up. Tech typically won't go and roll out new code to servers outside of the normal release or break-fix process, for example; the BG team manages these interim updates themselves.


About the documentation angle. The tech department has made significant documentation contributions in recent memory; for example, creation of a standard configuration for new game server host machine (used on TSM and Amn), with a documented checklist on how to create a new environment; better documentation on the SSHFS host infrastructure; documentation and a checklist to follow for new releases (where previously we have sometimes more or less hacked it through doing one-off different things for different servers during rollouts); documentation on NWNX plugin configuration for servers, etc.

There is always more documentation to write and nobody will say that we are perfect or done yet. One of the big problems that we have is with finding documentation; much of it tends to happen in forum threads or other ad-hoc locations rather than in a central place. (The fact that while I can create wiki pages, I can't actually link them to the main technical documentation page, is one contributing factor!)

Writing good documentation takes a lot of work and time though. Sometimes things slip through the cracks or don't get done. The best thing that you can do here is to ask for help about how to use something, and in those cases we can work to improve the documentation where something was missing. Usually, developers are happy to see someone take interest in their work and to help out with someone that wants to get started using something that they have made.