Feedback talk:Joe Kimmes/Archive Jul-Sept 2010

Zealous Benediction and Hero AI

Hi, Joe!
I was doing some PvE yesterday, and I noticed that my monk heroes spend way too much energy. To fix this, I changed my hero from Word of Healing to Zealous Benediction in the hopes that it would be able to better manage. Unfortunately, I noticed two other things:

• Heroes don't only *use* ZB on targets above 50%, but they do this *on recharge*.
• Heroes spam Reversal of Fortune (a common energy killer).

On the bright side, we were taking enough damage that ZB on recharge triggered the conditional on and off, so things were okay in the long run.
But, for the sake of improvement, is there any way you could change the AI for ZB (and, to a lesser extent, WoH) so that heroes use them more effectively?
Further, if you could make heroes prioritize their more energy-efficient heals (i.e. less RoF/Patient spam), that would be awesome. :3
Thanks for taking a look at this! is for Raine, etc. 18:55, 10 July 2010 (UTC)

Skill efficiency is one of the trickiest things for the AI, since usually when the AI is coded the skill numbers aren't locked down, or the numbers have been rebalanced after the AI was written. But now that the War in Kryta is finished up, there may be some time to take a quick look at some of these AI cases. - Joe Kimmes 18:15, 12 July 2010 (UTC)

WiK Allies not spawning in North Kryta Province

Greetings, Joe! So, I'm not getting any War in Kryta ally spawns from any of the entrances into North Kryta Province after The Battle for Lion's Arch quest. I do have Shining Blade bounties in my quest log, so the WiK content should still be active. In fact, I'm getting ally spawns in every area EXCEPT NKP. Thanks! --Musha 04:05, 17 July 2010 (UTC)

Sounds like a holdover from the pre-final battle quest (allies don't spawn during that). I'll look into it, but in the meantime, please report this to QA so that they can verify it and be ready to test the fix. Thanks for your report! - Joe Kimmes 22:48, 20 July 2010 (UTC)

Awesome! Thanks, Joe! --Musha 15:00, 21 July 2010 (UTC)

Category:Quests with no data

Hey, Joe. I was wondering if you had any info about those quests as no one has ever seen them, but according to Anja Astor they are "linked from the game". Thanks in advance. - Reanimated X 14:58, 18 July 2010 (UTC)

I don't recognize all of them, but several of those are quests that were partially complete and never finalized for various reasons. I imagine they still exist in the master quest list, so the name might pop up somewhere in the data files. - Joe Kimmes 22:51, 20 July 2010 (UTC)

Thanks, Joe. - Reanimated X 23:16, 20 July 2010 (UTC)

Digit rounding

I almost forgot to post this but I was just wondering how Guild Wars deals with digit rounding? I posted the original question here: [1] but most of the data seems contradictory or outdated. So, do you have answers for us? Previously Unsigned

It's simple round to nearest. So .5 and up gets rounded up, everything else down. The problem you observed on the Of Enchanting talk page is that when multiple modificators apply, the value gets rounded in each step. In the case on the talk page it is as follows: 7s + 20% (Of Enchanting) + 37% (Blessed Aura) = ⌊8.4⌋s + 37% = 8s + 37% = ⌈10.96⌉s = 11s. poke | talk 22:43, 22 July 2010 (UTC)

Aegis only lasts for 4 seconds with 20% weapon mod and any Blessed Aura value of less than 25%. If the duration were rounded at both steps, Aegis would last 5 seconds at any Blessed Aura greater than or equal to 17%, regardless of the order applied. MA Anathe 02:55, 4 September 2010 (UTC)

Any time the enchantment mod comes into consideration, I'm leery. A 20% Ench mod isn't always 20%; I've noticed that it doesn't count as 20% if your character is wielding the weapon with the mod upon entering an area or after being resurrected until an enchantment (possibly any spell; I haven't tested it) is cast with a non-enchanting (or possibly any non-20% enchanting; or possibly a 20% enchanting weapon that they were not wielding at zone entry or res) weapon set first.

This also puts a hole in the digit-rounding theory or implies that the order of enchantment modifications can be changed by changing weapons. — Raine Valen 3:12, 4 Sep 2010 (UTC)

Further, there's been an observed bug regarding lengths of very short (monk?) enchantments, namely Patient Spirit; I'm not sure if a 4-second Aegis would also be subject to the same bug. — Raine Valen 3:15, 4 Sep 2010 (UTC)

Interesting, you're right. Blessed Aura at 20% doesn't cause Patient Spirit to extend to 3 seconds, yet 20% of Enchanting does. This bears further investigation. MA Anathe 03:29, 4 September 2010 (UTC)

Independent testing derived the following:

Of Enchanting will always extend enchantments by at least 1 second.

Enchant duration modifiers are multiplicative.

Enchantment extensions are applied separately.

Enchantment extending effects are applied in chronological order, beginning with the oldest active effect.

Rounding to the nearest integer occurs after all extension effects have been applied. (Note: Minimum extension effect is not rounding.)

The following defies explanation:

Aegis (PvP) with 1 second duration, 20% enchanting mod lasts for 2 seconds due to the Of Enchanting quirk.

Aegis (PvP) with 1 second duration, 20% enchanting mod, 28% Blessed Aura, Aura applied after weapon swap lasts for 3 seconds. This only makes sense if 1.2 is increased in all respects to 2, so that 2 * 1.28 = 2.56 rounded up to 3 seconds.

Aegis (PvP) with 1 second duration, 20% enchanting mod, 25% Blessed Aura, Aura applied after weapon swap lasts for 2 seconds. If the above explanation holds true, 2 * 1.25 = 2.5 should round up to 3 instead.

Cookies to whoever can solve this problem, or provide more such examples. Will begin working with Extend Enchantments and compiling more data. MA Anathe 23:35, 4 September 2010 (UTC)

Awesome work! If you post your data (e.g. in google docs), others will take a look, see if they spot other patterns (yeah, that would be PITA, to collate it all, so I well understand if that's more time than you want to invest). Thanks for doing the research, posting the results.  — Tennessee Ernie Ford (TEF) 00:43, 5 September 2010 (UTC)

Brute Force Timer

Hey, I have noticed that even successful login attempts cause the brute force timer to get activated. Easy way to reproduce it: Repeatedly log in and out until you get a delay and see the "Connecting..." window. Is this intended or merely an oversight/bug? --129.13.72.197 22:17, 25 July 2010 (UTC)

If you think about it, repeated logins are a little unusual even if they're successful, so I wouldn't be surprised if it's intentional. I didn't work on the systems involved personally though, so I can't give you a definitive answer. - Joe Kimmes 18:10, 26 July 2010 (UTC)

Screenshots, But Awesome

I've written a suggestion here, and it's been getting positive feedback so far. It's in regards to implementing a record and replay option to the Guild Wars client.
I'm curious about the technical aspect: would something like this be resource-intensive? Is it feasible?
If you get a chance to look at it, I'd very much appreciate a short answer. ♥ — Raine Valen 2:26, 4 Sep 2010 (UTC)

I'm not expert, but I think it would possible to let players record their own matches, but it might be stressful on the server since a player isn't usually aware of everything on the map at once (monsters aren't visible off the radar, for instance). Such a file would need to played back before an update, because I'm pretty sure the observer cache must be flushed whenever the game is updated -- I believe the observer mode is a working game controlled by recorded actions, not a video playback. As a result, it uses the skills available to all players, which means trying to playback a file after a major update would probably break things. On top of that, designing new interface tools for recording and then playing back these files would be a fair bit of work. Obviously Joe will have a more complete answer, but if I had to take a guess I'd say this would be a pretty huge project. You might be better off with Camtasia or something. Just select uncompressed so it doesn't turn it into blocks and you can hand-pick screenshots later. –Jette 03:12, 4 September 2010 (UTC)

Perhaps if we only allowed them to center on the player in question? This way, we can guarantee that there would be no additional server load, as the recording process could be done client-side.

The concern about updates is also a valid one. Unless a file were saved with the recording that also kept copies of the skills that were present at the time of the recording (or if the old versions of skills are archived on the server someplace), new builds of Guild Wars may, indeed, kill old recordings.

Designing "interface tools" need be no harder than putting a "record/don't record" toggle on the interface someplace, unless there were additional recording options. The mechanic for saving said recording would need to be added, though, but I believe that very few modifications would need to be made in order to derive this from the mechanic that saves recordings for obs mode.

Thank you for bringing your concerns up. ♥ — Raine Valen 3:22, 4 Sep 2010 (UTC)

Jette is correct about the largest problem - since Observer Mode works by recreating the game on the server, it's no more client-side than the normal game is. So, without letting you run a local server, it's pretty impractical to be saving/running that many obs games. - Joe Kimmes 18:34, 9 September 2010 (UTC)

Thanks tons!

I've got a couple more questions (which I hope you'll not mind answering!), just so that I may have a better understanding of the technological constraints that you would be operating under:

If the recorded game were stored client-side, could it be uploaded to the server prior to playback to decrease server-side storage space required at a given time?

• To further limit the server space consumption, you could limit playback to a certain number of observed games per guild at a time (considering that each guild could, theoretically, have 3 "unique" games stored at any given time simply from playing a GvG). Even further, these replay slots could potentially overwrite a guild's default saved games.
• Drawbacks include: possible security issues, additional server strain due to increased volume of obs traffic (more people would use this than people who GvG or observe GvG, I think), relatively long match lengths compared to GvG/HA matches requiring increased space, and, possibly, upload time.

On a related topic, is replaying a game in obs more resource-intensive than actually playing a game? That is, if a player is not playing a game and instead watching a game on obs (because they can't do both at once), would this create a net increase in server strain?

I apologize for my lack of technical knowledge in this field. :> — Raine Valen 5:41, 10 Sep 2010 (UTC)

Some of this will stray into the network coding, which isn't my area of expertise, so take my answers with a grain of salt:

Storing games client-side and uploading to the server: This doesn't really solve storage concerns, since the data has to be stored while it's being played - what if everyone wants to play their own replay at once? Additionally, you have the always-scary scenario of trusting a client's data - what if they upload a maliciously-altered replay? There are safeguards in place, of course, but it's still a tricky scenario for something as simple as a replay that causes a server crash. Also, as you bring up, upload times - this will not only affect watching the replay, but also potentially cause lag for players who are actually playing the game.

Limiting replays by guild: Again, this doesn't really affect the worst case for storage - there's no (known) limit on guild numbers, so what if every player has their own guild?

Resources for obs: Observer mode is not necessarily more or less intensive than playing the game - it varies according to how many players are watching the match and the match length/complexity. In general, I would assume that each Obs game is more expensive than an explorable area but less expensive than an outpost.

To reiterate another thing Jette pointed out - even simplifying this down to the barest amount possible, the amount of programmer time it would take to make the changes to obs mode/network code to support this is impractical with the team we have right now. - Joe Kimmes 18:38, 10 September 2010 (UTC)

What kind of an outpost? I assume an obs will take less resources than something like Kamadan or Kaineng, but what about someplace like Tombs (the outpost to the Proph "dungeon", an outpost of medium-ish popularity) or a dead guild hall? Best case scenario, obsing from a guild hall helps the servers a bit, and I'll start setting my obs to auto-watch things when I afk in the hall. -- Armond Warblade{{Bacon}} 01:19, 23 September 2010 (UTC)

It depends on your guild hall's traffic - in general though, if you're trying to minimize server use while AFKing your best bet is your guild hall or an empty outpost. - Joe Kimmes 21:36, 27 September 2010 (UTC)

Terrain/Object Collision in Guild Wars

Hi Joe! I re-watched the Making of Nightfall video today, and noticed the awesome Map Editor that the artists were using to model the collision meshes for terrain. Since I'm myself really interested in game programming, I'm wondering what exact technique Guild Wars uses for terrain collision. I've always wanted to know how it all works with bridges and so on where you can have multiple walkable planes horizontally. Guild Wars does use a very unusual system in that it's mostly 2D coordinate based, with multiple "levels" of height. At first I thought that it was simply a heightmap with a walkable/not-walkable flag per triangle, but after some corner-scraping tests this does not seem to be the case; and the video seems to suggest that there is a collision mesh modelled by hand.

Sorry if this is badly phrased but the 2 questions I'm having are essentially:

1. How does the game decide whether or not a position is walkable; and is that baked into the map, or does each mesh have its own collision mesh that gets loaded by the game when it loads that object? (I remember the wintersday map for Kamadan having collision around the Dwarf cage, even when the cage was not there anymore -> the collision is baked into the map?)

2. How is the height/"plane" represented?-67.159.44.134 22:21, 22 September 2010 (UTC)

Unfortunately I'm not the best person to ask (although perhaps the best among wiki posters), but I'll try to answer as much as I can. Collision data is baked into the maps, and largely constructed manually - there's a heightmap for walking on, and then individual collision ribbons walling off the areas. Bridges are their own scary special case, which I definitely don't understand well enough to explain. ;) - Joe Kimmes 22:33, 22 September 2010 (UTC)

With no offense to the guys who originally implemented the thing, GW is probably not the best place to learn about collision from, given how often you see weird stuff happen with it... remember the old bridge bug, where you could hit stuff on the bottom from on top? Bleck. I'm guessing somebody wrote the GW engine under the impression that true 3-d would never be needed, then an exec came into the office and said "hey, we changed our mind! we want bridges," and instead of re-writing THE ENTIRE PROGRAM from scratch, they gritted their teeth and made some sort of black-magic hack that would make any CS student queasy. –Jette 22:50, 22 September 2010 (UTC)

That would explain bridges being buggy... like characters disappearing, and some falling through to the bottom, being body blocked by a monster underneath etc etc... In the end, it was probably the best anyone can do with the program they had. --Lania 23:31, 22 September 2010 (UTC)

There's a lot of black magic solutions in the game industry, believe me. ;) - Joe Kimmes 21:38, 27 September 2010 (UTC)

Wow, thanks for the fast reply. So that's what I was seeing in the video, the collision ribbons! And it explains why edgy surfaces sometimes appear straight when you walk against them.

I have been walking around in my Guild Hall for the past 10 minutes, and noticed that when I am at the bottom of the stairs and then click just a little closer to the stairs, my character will not walk there. It seems I have to click far enough onto the stairs for my character to "move over" onto the "stair plane". I think that might be what's used for bridges; the terrain being divided into planes, that each have their own collision ribbons. I guess there might be some special "joint" ribbons, that can be traversed to walk onto a different plane.-67.159.44.134 23:40, 22 September 2010 (UTC)

Hmm! After further toying around, I might have found the reason why I could not walk over onto the bridge. It seems that the planes are overlapping; so when that I click on the bottom of the stairs, it tries to walk onto the ground plane, where the stair plane has already started and the ground plane is ribboned off. This seems to happen just about everywhere on walkable props, like on the round surface in the Great Temple of Balthazar.-67.159.44.134 00:19, 23 September 2010 (UTC)

Hehehe, what you see and what you touch are different things. If we could activate some kind of wireframe for the collision data, I bet maps would look reaaaaly weird. One of the funniest cases is in Arborstone. The first step of one of the stairs in there is taller than most characters, but you can walk up there anyways, jumping from the floor to the top of the first step in a split second. MithTalk 13:31, 28 September 2010 (UTC)