So I’ve been going through Azeroth and adding lights to the various lamps, torches, etc scattered throughout (3.3.5) with LightAdder. This works great, but as some of you here are aware, M2s with lights added by LightAdder have a bug: their bounding boxes don’t match up to the sphere of light that the light(s) you added cast, meaning that all of the light the model is casting just disappears when the model isn’t in the player’s field of vision. This creates a distracting, unpleasant effect where lighting kinda pops in and out of existence as you walk along.

To fix this, as suggested, I tried grabbing 010 editor and editing my custom M2 files with a template. I’m able to modify the M2 fine and it saves alright, but after logging into the game I see no difference, even after changing values to extremes (100+).

So now I’m wondering if I’ve done something wrong. Am I editing the appropriate values? What is the range of numbers that I should be editing within — what units do these numbers represent? Is there a known mapping between M2 light distance values and M2 bounding box values?

Below is a screenshot of the values in question.

Blipper

Blipper is a Cocoa BLP viewer for OS X. It can view most common BLP types, perform some basic manipulations, and export BLPs to JPEG, TIFF, and PNG. Its BLP reading is provided by BLPCore.

Requirements

• OS X 10.9 or later (may run on OS X 10.

Todo

• Mouse coordinates
• Batch conversion mode
• BLP saving
• Writing changes back to BLPs

Download

• Blipper Repository
• Blipper (127KB)

We’re all too familiar with the typical “mountains” in WoW, which are less like mountains and more like unusually angular, pointy hills. This style works if it’s worked into the zone design well, but it’s kind of a letdown in some ways. Even areas that are supposed to be particularly “mountainesque” like Ironforge’s mountain and Blackrock Mountain suffer from this. Some of the areas in Pandaria come closest but are still lacking.

What I’m curious about is how possible it would be to create mountains that more closely resemble their real-life counterparts. In other words, they’d:

- Be far less steep, with climbable sides
- Be much larger, in some cases taking up an entire zone’s worth of terrain or more
- Have flora and fauna scattered up their sides
- Have visible climate changes with increasing elevation
- Have roads winding up and down their sides
- Have multiple caves and small clearings/flat areas on their sides
- Possibly be a member of other similarly-sized mountains to form a real mountain range

Is one attempting something like this likely to run into the limitations of WoW’s engine? What are the reasons for this style not being more common?

Here's a little something I've been thinking about. I don't know much about the limitations imposed by the WoW client or MMO server design in general, so that's why I'm running this by you guys. Please enlighten me as to if this is feasible or just plain stupid.

A big problem even for both official and private servers is how a single bug, a memory leak, or excessive load in one area can bring an entire continent (world server) down. What I'd like to know is why can't this be dealt with in the same way web servers like ngnix deal with it. To those unfamiliar, nginx uses a number of worker processes (defined in its config) that handle serving sites to viewers instead of dropping all responsibility on one process. This means that if something goes wrong and a worker crashes, the other workers can go on and a new worker can automatically be spawned to take the crashed worker's place. All continues smoothly and users never have a clue that there was ever a problem.

I am unsure of how Trinity is structured, but it seems to share the same problem that Blizzard's servers do; a tiny bug or memory leak can bring the a whole continent down.  As such, it might be beneficial for Trinity (or another emu) to adopt an adapted multi-process model… perhaps something like the image below.



Under this model, the server spins up at least one process for each zone. During times of high load (like city raids or world events), additional processes can be launched to meet demand. Zones with no players within viewing distance could have their worker process shut down or suspended, based on frequency of player visits. NPCs that traverse multiple zones would be the exception, carrying a special flag in the database and being handled by an ever-present global worker.

This setup would save resources, appropriating them to the areas they're most needed in. It also means that if someone runs across a bug that triggers a crash or memory leak, only that zone will go down while the rest of the continent is unaffected. Finally, it also allows for better scalability - worker processes could be spread across multiple virtual machines or servers, meaning that if a server's population starts pushing hardware limits one can balance its load across two or more machines instead of having to set up a second separate, empty server and redirect new players. On a smaller scale, it could also mean that you could get respectable performance cheaply through chaining together the old Pentium 4 boxes sitting in your closet.

Thoughts?

As practice for creating WoW modding tools, I'm trying to write a little DBC Editor, since it seemed like a simple task compared to reading and editing other file types.

So far I can read the file type, number of entries, and number of fields correctly (was much easier than I expected). How do I read each individual entry? The type, entry count, and field count are as simple as grabbing values at certain addresses (0-4, 4-8, and 8-12 to be exact), but how do you deal with strings at varying addresses?

I'm guessing I need to somehow predict the length of each string and then iterate through the data, keeping track of my position?

So I've been playing with noggit some more, trying to improve my terrain editing skills.

What's the best way to avoid lumpy terrain? If I use the method shown in some videos here (use large brush and slowly scale down) I always end up with lumpy terrain that's difficult to smooth back out.