Being able to loot everything with one push of a button would save us fighters a whole ton o' mousing in the long run

Basically, the idea is to make a needle of a material that aligns itself to the Crystal, then mount it gyroscopically, allowing it to rotate in the X and Y directions (pitch and yaw in other words).  This would give you both a reference direction (i.e "in") and an idea of your elevation wrt the Crystal (which could also be done by a sextant, but this has the advantage of being one device instead of two).

It seems that quite a few people are going/have gone  over the way the economic balance in PS has oscillated back and forth between crafting and combat (as well as between various forms of crafting).  What is going on here is the process of balancing game is necessarily a closed loop (feedback) system.

In crude ASCII art:

Rules team makes balance change (input stimulus) -> Players go "wait, old way X no longer works" and start searching for a new way to do things -> player A finds new way Y and it starts to be adopted, causing the economic balance (output signal) to change -> Rules team finds out unexpected consequences of balance change they made, and makes another change, sending this whole cycle back to the beginning again

Or

value of economic balance inputs (npc prices, material rarities, drop frequencies) ------->  economy (players) -------> value of economic balance outputs (markers)
                              ^--------------------------------------------------------- Rules team (devs) <-----------------------------------------V


Due to the limitations of both the speed at which information travels through the economy and the ability of the Rules devs to react to changes, this is what is known as a band-limited system.  In other words, quick changes (economic "glitches"/abberations) are filtered out, while longer term trends are more likely to be identified and reacted upon, as those are more likely to indicate that something actually needs to be changed.

Now, lets take this fine feedback system of ours and subject it to a step input (say, tripling the NPC price for gold ingots, if you wish to use an example that extreme).  The response of the system is not exactly going to mimic the step that was put in, but will show two interrelated phenomena: ringing and overshoot (also known as hunting).  Basically, the output (game balance) is going to vary wildly for a little bit before settling down to a new stable state.  (Look at a plot of the sinc function if you want to see what I mean by these wild fluctuations, although I'm sure most of us who have been about for a while have experienced them already    )

Here's the thing about this problem: the faster the system gets relative to its inputs, the better the situation gets (the less ringing and overshoot you get).  While the player economy won't change in speed very much (unless the Groffel post is replaced with Megaras post  ) and nor will the Rules team  , there is one knob to turn, and that's how quckly Rules applies changes to the economy.  Going back to the earlier example, instead of tripling the price instantaneously, raising the price smoothly (or even in small jumps) over a few day period would create less ringing and overshoot, even for a large overall change in the input signal.   In other words, slowing down the input causes the problematic oscillations to become smaller in amplitude and (hopefully) less noticeable.

My 2 tria.

Linux and Mac people can safely ignore this.

The Windows installers for all the Crystal Blue releases stuffed their uninstall information into HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\PlaneShift\.  XFire needs to know the path to the game executable for each and every game (including our beloved PlaneShift) that it supports, so it looks in the Registry, in a place governed by its INI file (xfire_games.ini for those unfamiliar).  In PlaneShift's case, the aforementioned key (in fact, its UninstallString subkey) is what XFire picks that path up from.

Fast forward to Steel Blue.  When the first (0.4.00) Windows SB installer was made, somebody thought it was a bright idea to change the uninstall key to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\PlaneShift <insert PS version here>\.     This not only broke XFire support and continues to break it (and must be dealt with if we want XFire support again), but leaves garbage behind in the Registry whenever a new version (0.4.01 say) is installed atop an old one.

Summary: the 0.4.04 installer should change the uninstall key's name to not include the version number, unless there's an extremely good reason for it to be there.