Yeahlight's Blog

Change in Direction II

2012-01-10T02:09:00.000-08:00

My estimation of a six to eight week removal from personal projects was a bit too conservative. Today marks the eighth week from my announcement and I believe I have another four to six weeks to go until I may safely invest time into other projects.

Change in Direction

2011-11-12T00:05:00.000-08:00

Myself and a few others are in the process of starting a business and a couple of those participating are leaving their current jobs. It is imperative that we do not fail, thus, to ensure that we hit the ground running, I am removing myself from all other projects for the next six to eight weeks.

EQClassic - Source Organization

2011-11-07T18:13:00.001-08:00

Shortly after making the appropriate changes for spawning our new pets, I have decided to dedicate some time (five to seven days) to clean up and reorganize our source. A majority of the source is poorly organized and I cannot stand to look at it anymore.

EQClassic - Spell System

2011-11-01T22:37:00.000-07:00

Roughly three weeks ago, I resumed my work on the spell system. I got distracted for seven days or so when I noticed bards were not functioning correctly, but my recent efforts have been focused around refactoring and finalizing the spell system.

The spell system is massive and I am confident that it will beat the size of any other system in the source (including NPC AI) 2:1 or more. The time sink in this area is sickening, but I am optimistic that spells will see their completion before the middle of December. The refactoring of the existing system is pretty much done (I occasionally come across something else that needs to be rewritten), so I have been free to move onto finishing our preliminary implementations of spell effects.

I am currently working on summoned pets and this is an area that will require some serious time. Tazadar started the work for pets back in 2009, but the current implementation is far from complete. Pets have special combat rules, special abilities and special attributes; all of which need to be thoroughly researched. Fortunately, I have invested serious time into a necromancer in the past, so I already posses an intimate understanding of pets. Although I am concerned about implementing pets correctly, I am not concerned about balancing them at this time. Balancing will come much later when the entire spell and combat systems are complete, so that we can look at the damage, mitigation and avoidance tables of all the entities in the game.

After pets, we have a handful of unimplemented spell types, but they are pretty trivial to implement, such as silence, destroy and translocation anchor. The only other significant time sink with spell effects remaining are illusions. Illusions themselves are pretty strait forward, but my concerns lie in temporary faction adjustments and armor textures. In fact, my favorite bug was the way armor textures were saved between illusions and I will replicate it. Basically, one could put on armor that looked great but would not be worn due to its less than desirable stats, chalk up a monster illusion, put their real armor back on, remove the illusion and they would come out donning the nice looking gear but possessing the stats from their current equipment.

Anyway, once the spell system sees its completion, I will finally step back into the combat system and ultimately arrive back to where it all started for me--NPC AI. This work will probably keep me busy through February.

EQClassic - Client Synchronization III

2011-10-07T01:36:00.000-07:00

I wrapped up client HP, mana, stamina (the yellow bar) and attribute (AC, ATK, STR - CHA, saves and weight) synchronization tonight. I am quite happy with the results and extremely satisfied with the low time impact (I thought this work was going to be a one hundred or more hour investment). I was able to breeze through this work quickly due to Harakiri's aid in formula discovery.

Just looking back on how things worked is hilarious. The previous approach was to simply force the server's levels of HP, mana and stamina onto the client with absolutely no regard for how the client natively functions. In fact, mana regeneration was roughly ten times faster than it should have been! The only EQEmu-based server I have ever played on is Shards of Dalaya, which also--at the time--forced server levels onto the client**, so it is probably safe to assume that current EQEmu protocol is to do the same.

This work emphasized the singlemost frustrating aspect of this project. It is difficult for the average player to distinguish a functional server (one that works, but is not accurate) from a great server, because all of the things they are concerned about are handled in the client and database. They do not care that they have too much mitigation AC, that their DoTs are generating too little hate, that their nukes are not resisted as often as they should be or that their client side penalties are not enforced on the server; all that they care about are the things they can see.

In any case, I will be resuming my work on finishing spell types and then I will transition into revamping my previous attempt at the combat system.

**How could I tell? Watch the HP regeneration in the inventory window. You will see the client fight the server for the correct amount of current HP, as the server is sending the client HP updates. The client should not be changing its current HP more than once every six seconds.

EQClassic - Client Synchronization II

2011-09-30T23:46:00.000-07:00

The HP synchronization is just about finished and I am pretty satisfied with the results. I am also just about finished with synchronizing the client's mana with the server, but I am hoping to find a new client routine to update its mana by some given amount instead of sending the client updates such as, "Hey, your new amount of mana is XXXX." The client refuses to update its own mana when a spell is complete, so it unfortunately seems to rely on the server for hard number updates.

Beyond these two attributes, I will also be looking into synchronizing AC, ATK, STR through CHA, saves and weight. I am not at all excited about the latter because weight has numerous effects within the client, such as affecting AGI (when overweight) and a monk's AC. This project may end up taking quite some time, but I am hoping to return to finish the remaining spell types soon.

EQClassic - Client HP Synchronization

2011-09-22T12:24:00.000-07:00

We have always had major issues with synchronizing the client's HP with the server and I have recently come to realize that--due to the sitting regeneration bonus--true synchronization is not possible. In the past, the server was responsible for keeping track of the client's HP, directly updating the client's HP and triggering the client's death routine, but this approach was problematic as the client's HP may have been well into the 100s when the server instructed it to die. Fortunately for us, the client sends the server its current HP level on each tic. This information was ignored in the past, as it seemed too convenient for someone to abuse, but it is entirely necessary for clients to function properly (the server will now have a rough estimate of client HP, which will be compared to the HP level sent in each update to detect any foul play).

The task at hand is to prevent the server from ever updating the client's HP directly (instructing the client to change their HP by some given amount instead of to some given amount, e.g., "You now have 250 less HP than before" vs. "You now have 1250 instead of 1500 HP") and to rely on the client to tell the server when they have perished. Shaman who love to cannibalize themselves down into the purple range will thank us!

Unfortunately, the client does not share the same level of care for its mana as it does its HP. If you played a caster on live (even up through the change that displayed your amount of mana in the UI), you should then be aware of the very obnoxious bug where it appeared you had sufficient mana to cast a spell, but the server disagreed and instructed the client to remove the mana you thought you had. The good news is that the client knows if it has the correct amount of mana to cast a spell, so perhaps it is possible to approach mana the same way we will now approach HP. This bug rarely affected casual players, but for those who sit on each and every tic to gain the meditation bonus, this was a common, annoying occurrence.

EQClassic - Zone Geometry Mapping III

2011-09-06T11:11:00.000-07:00

As it turns out, our new collision detection system does not offer any speedup** over the old, as EQEmu's segment / triangle collision routine is virtually the same as mine. Admittedly, I did not investigate their solution--I just assumed it was terrible. I am strictly speaking about the mathematics behind their collision detection and not the entire line of sight system, which has been greatly improved. There exist several opportunities for optimization, but it is not of interest at this time considering the average passive line of sight check is less than two microseconds (1.3E-6 seconds).

I am going to put the remainder of the zone explorer program (node placement) on hold, as this would require a significant investment in time. I am not convinced that it would as beneficial as its cost would suggest. I may add support to the zone explorer to read in node data and display it, though.

I believe I will be returning to spells (these are almost done) and then heading back to NPCs to rewrite the entire AI decision tree.

**With regards to the collision detection algorithm, but the new line of sight system is roughly three times faster.

EQClassic - Zone Geometry Mapping II

2011-08-31T09:21:00.000-07:00

I found a research paper today on an efficient vector tracing algorithm that does not require stepping to determine collisions with geometry in three dimensional space. Stepping is a technique which slowly extends a line from the origin point towards the destination, continuously gathering the list of nearby geometry and calculating the possibility of sharing the same physical space (forming a collision) with any of said geometry at the line's current location. It is a long and redundant process and the only way to ensure some manageable degree of accuracy is to keep the stepping increments small, thus, as the vector grows in size, so does the computational cost.

I implemented the proposed algorithm along with a visualization component in my zone explorer program this morning and it is obscenely fast and remarkably accurate. The most absurd part is that I am not even utilizing a tree to partition the zone's geometry list! The algorithm is so fast that it scans all 77,000 triangles in the Field of Bone for collisions before the zone explorer program drops a single frame. It will only get faster as I implement an octree to store the zone's geometry data. I cannot wait to benchmark this algorithm against our current line of sight solution (EQEMU's).

EQClassic - Zone Geometry Mapping

2011-08-24T17:48:00.000-07:00

I was reminded the other day that our zone geometry files are sometimes incomplete and contain holes (missing data). The new line of sight system I am envisioning (one loosely based on the watersheding technique) requires a complete zone geometry file. So, before I jump into implementing a new LoS system, I need to verify that our geometry files are indeed complete, which requires building a Direct3D application to load, view and patch a zone's geometry data.

I have never written a D3D application before and it seems to have a bit of a learning curve, but I am excited to learn something new. I am hoping that even if our zone geometry files are complete, I can expand this application to support laying pathing nodes and roam boxes.

EQClassic - Mob Position Updates II

2011-08-22T18:17:00.000-07:00

NPCs are now able to swim in the water, but the solution had nothing to do with proper movement deltas in spawn position updates. The solution required a special gravitational flag in the spawn packet PCs receive when an NPC first appears in the zone. For whatever reason, when a mob is a PC, this special flag is automatically assumed, yet requires definition when the spawn is an NPC.

Oh, well--problem solved! Back to working on the line of sight revamp.

EQClassic - Mob Position Updates

2011-08-20T05:30:00.000-07:00

Harakiri brought something to my attention the other day reminding me that our spawn position update routine is incomplete. I feel like we are pretty close to finalizing this area so it has stolen my attention from the line of sight revamp for now.

When the server wishes to let PCs know that a mob is on the move, the server sends out a spawn position update packet, which describes a mob's physical location in space (x, y and z coordinates), cardinal heading, velocity and deltas (x, y, z and heading). The deltas were not previously utilized for NPC movement because it appeared they were not necessary. The client exports the same packet with populated delta values to the server when the player moves, so we simply just pass this packet onto other clients in the zone, as we assumed the delta values were reserved for special PC movements (strafing, turning, jumping, etc.).

It did not occur to me until yesterday that the deltas are most likely responsible for describing a mob's movement in environments that affect velocity (e.g., ice and water). Surely enough, kiting an NPC in water produced a staggered path as the NPC was teleporting between locations as the client received additional updates. Introducing a second PC into the water produced a smooth, fluid path, which strongly suggests that in order to get NPCs to follow suit, we need to figure out how to calculate the delta values.

Early attempts to assign known, working delta values (those derived from PC movements) to NPC updates were unsuccessful. In fact, the only way I got NPCs to swim fluidly underwater is to assign them insanely high velocities, nearly twenty-fold their original. That may have been a decent fix if it were not for velocities capping at 128, which means faster NPCs (e.g., Shadow Men) would not be able to approach their true velocities under water.

EQClassic - Line of Sight

2011-08-06T10:02:00.000-07:00

I have resumed working on EQC again, but my work right now is purely conceptual (I will not be producing source revisions). More specifically, I am rethinking our line of sight (LoS) system and I am also investigating the possibility of preprocessing a zone's LoS data. I am not terribly optimistic about my success in the latter, as the number of possible line of sight calculations for a typical zone is roughly 1.6E18, but if I can successfully collapse a zone into two-dimensional space, then there exists some measurable chance of success.

Regardless if preprocessing the LoS data is feasible or not (I am strongly leaning towards 'not'), my primary interest is replacing the core of our LoS system. Right now, our LoS system is based on EQEmulator's approach, which steps along a vector between two points and checks for a collision with the zone's geometry data. This approach is functional, but it is slow and I am not convinced that it is precise enough to be reliable. I believe a more elegant, efficient solution exists.

EQClassic - Website Makeover

2011-07-27T13:47:00.000-07:00

I had some spotty, free time today, so I decided to catch up on a long list of revamps that the EQC website desperately needed. Updates include unifying of the overall headers and footers for each page; redesigning the roadmap and statistics pages to utilize accordion-style tabs; updating the roadmap with new content; creating a custom 404 page; redirecting banned IP ranges to the banned HTML page; utilizing remote auto-completion for the auditor registration system's username field; and general cleanup and reorganization on each page.

Man, I hate HTML!

Edit: I was also reminded today how slow the website is. I think it is time for a new host!

My Status

2011-07-15T20:59:00.000-07:00

I promise I will do my best to keep this blog updated as much as possible. I received a number of requests to blog my status over the years and I really never thought it my kind of thing, but I feel it is appropriate now, especially for those following my EQClassic project.

Speaking of which, I made an announcement several weeks back about my return to EQC, which was already delayed once by the process of moving out of my prior residence. A few days ago--just as I was ready to get back into the swing of things--I received word from a company about contracting / hiring me to rewrite their entire internet-marketing reporting dashboard. They were also very interested in a dormant software project of mine, which is an internet-marketing solution targeted specifically at car dealerships. This company wants to get things in motion on August 1st.

Prior to August 1st, I will be out of town for a week at a bioinformatics conference for which I am presenting two papers. Also, I am expected to learn any MVC-based framework of my choice before we get the ball rolling, plus I am currently rewriting and refactoring portions of my car dealership software.

The time I thought I was going to have to dedicated towards EQC has slipped through my hands again; however, once I am deep in this work (I suspect this will be around the first week of August), I am going to schedule time for EQC on a weekly basis that will only be invaded by emergencies. Even at my busiest, I would still like to get in at least ten hours of EQC related work per week.